I. Use Case Description | |
Use Case Name | Unified Standard for Regulatory Reporting of Derivatives |
Use Case Identifier | DER-REPORTING |
Source | Derivatives FCT |
Point of Contact | |
SEC-Creation / Revision Date | 7/9/2019 |
Associated Documents | Requirements documentation, traceability matrix if applicable |
II. Use Case Summary | |
Goal | To provide greater accuracy, timeliness, harmonization, aggregation, more transparency, and higher quality in general across diverse derivatives reporting sources |
Requirements | To provide a more efficient, less expensive, and standardized reporting capability for derivatives using a common financial language |
Scope | Reporting could be viewed from a number of perspectives: (1) from the perspective of an institution, to be able to create accurate regulatory and internal reports in a timely way with respect to derivatives on their books, including counterparties to their portfolio(s), (2) from the perspective of a broker/dealer, to be able to analyze and report on the derivatives they manage and/or own, and the counterparties to those instruments, whether they are on their own books or those of their clients, (3) from the perspective of an SDR, exchange, clearing house, or other recipient, to receive reports that are provided in a common, standardized representation that makes them easier to ingest, and to be able to analyze and report on the derivatives for which they receive reports in an accurate and timely way, including analysis of the counterparties to the instruments included in those reports, and (4) from the perspective of a regulator or other organization receiving information from a variety of sources that are not aligned with one another, to have the ability to map that information to a common vocabulary to facilitate analysis and ultimately to have a common framework for reporting that would enable understanding as well as reporting from third parties. Some reports, such as end-of-day positions, exposure reports, and stress tests, are provided periodically to the regulators. The frequency depends on the kind of information reported. These reports have all different forms and formats that are not normalized, and the data is difficult to compare as a consequence. Note that as we move towards distributed ledger technology, having standard language for reporting purposes could extend to smart contracts which would be more effective than use of legacy approaches to such reporting. The content required for each of the kinds of reports we intend to cover is given under the usage scenarios section, below. |
Priority | This use case represents the most accessible of the DER use cases we have, given that we believe we have most of the concepts required to support this. Starting from an individual instrument, to ensure that we can report on a single instrument, then on counterparties to a single instrument, and then expanding from there, we can demonstrate value with what is currently available in FIBO DER. |
Stakeholders | Stakeholders include: internal front office, back office, and compliance teams that need to understand current positions at any point in time, broker/dealers and swap execution facilities who need to understand the portfolios they manage, SDRs, clearing houses, exchanges, and others that consume and aggregate reporting content provided to them, and regulators that need to analyze and oversee the market |
Description | This use case involves specifying the concepts and terminology required for reporting on derivatives, both generally, across all kinds of derivatives, and specific to the most common derivatives in the marketplace to facilitate reporting about them. The level of detail depends on the specific reporting requirements, outlined in the usage scenarios, below. Initial targets include swaps - interest rate and commodity swaps, options, futures and forwards, and various asset-backed securities. Note that transformations from/to the ESMA / ISO 20022 format in the EU (or at least, CPMI IOSCO), and to the CFTC format in the US, may be needed to support this kind of reporting, and possibly the ACTUS contract definitions of some of the terms of these contracts. These various formats all lead to some understanding of what terms should be included to identify derivative contracts and what variants should be included in order to provide basic coverage. |
Actors / Interfaces | List actors: people, systems, knowledge bases, repositories, and other data resources, services, sensors, or other “things” outside the system that either act on the system (primary actors) or are acted on by the system (secondary actors). Primary actors are those that invoke the use case and benefit from the result. Identify the primary actor and briefly describe role.
Any actor that is external to or outside the control of the use case owner should be further described under Resources, below. |
Assumptions |
|
Open Issues |
|
III. Usage Scenarios
Provide at least two usage scenarios that flesh out the requirements outlined in the summary, including identification of requirements specific to any envisioned ontology or semantically-driven service or application. Scenarios should be described as narrative, with supporting diagrams as appropriate. In an Agile process, every user story relevant to the use case should be included and elaborated/rolled up into one or more usage scenarios, with a clear mapping from the user story to the scenario it is integrated in or mapped to.
- Broker-dealer
- Regulator
- Counterparty
IV. Competency Questions
Provide at least 2 competency questions that you will ask of the vocabulary/ontology/knowledge base to implement this use case, including example answers to the questions.
Describe at least one way you expect to use the semantics and/or provenance to propose an answer to the questions. Include an initial description of why the semantics and/or provenance representation and reasoning provides an advantage over other obvious approaches to the problem. (optional – depending on the use case and need for supporting business case).
V. Resources
In order to support the capabilities described in this Use Case, a set of resources must be available and/or configured. These resources include the set of actors listed above, with additional detail, and any other ancillary systems, sensors, or services that are relevant to the problem/use case.
Knowledge Bases, Repositories, or other Data Sources
Data | Type | Characteristics | Description | Owner | Source | Access Policies & Usage |
(dataset or repository name) | (remote, local/in situ, etc.) | e.g. – no cloud cover | Short description of the dataset, possibly including rationale of the usage characteristics |
| Source (possibly a system, or remote site) for discovery and access |
|
|
|
|
|
|
|
|
External Ontologies, Vocabularies, or other Model Services
Resource | Language | Description | Owner | Source | Describes/Uses | Access Policies & Usage |
(ontology, vocabulary, or model name) | (ontology language and syntactic form, e.g., RDFS - N3) | If the service is one that runs a given ontology or model-based application at a given frequency, state that in addition to the basic description |
| Source (link to the registry or directly to the ontology, vocabulary, or model where that model is maintained, if available) | List of one or more data sources described by and/or used by the model |
|
|
VI. References and Bibliography
List all reference documents – policy documents, regulations, standards, de-facto standards, glossaries, dictionaries and thesauri, taxonomies, and any other reference materials considered relevant to the use case
VII. Notes
There is always some piece of information that is required that has no other place to go. This is the place for that information.