Use case: DER-Standardized Reporting

I. Use Case Description
Use Case Name	Unified Standard for Regulatory Reporting of Derivatives
Use Case Identifier	DER-STD-REP
Source	Derivatives FCT
Point of Contact	David Newman
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 in an actionable way
Scope	Reporting, specifically limited to reporting on derivatives contracts (rather than stress tests or other kinds of regulatory reports) 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) (i.e., what is the best way for an institution to report on the derivative contracts on their books to a regulator), (2) from the perspective of a broker/dealer or swap execution facility, 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, and report on them to an SDR, (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	Actors include the stakeholders listed above, other market participants, systems that maintain derivatives data or other relevant consumer or producer of the data that performs any sort of reporting on it, and regulators that receive the reports described above.
Assumptions
Open Issues

III. Usage Scenarios

A. Reporting by institutions to SDRs:

Our initial usage scenario is more limited in scope than as described above, and covers reporting in the US (per CFTC regulations) and the EU on the swaps in their portfolios. Data to support this use case will include the data used for the Chicago demo, and will cover the content required by the CFTC per notices filed in the Federal Register, as well as the CPMI IOSCO critical data elements (CDE) for derivatives that accompanied the definition of the UPI and UTI. Note that the governance of the UPI and UTI will be handed off to the ROC by the FSB as the standardization process moves forward. The important thing for us from the perspective of this usage scenario is to have very good semantics for these critical data elements, rather than the artificial encoding/mapping used to create the product codes.

In this scenario, we will leverage the work done by the EBRDF effort for the Bank of England using the portfolio of swaps that they used as the basis for their work (see /wiki/spaces/FEIP/overview), which includes 100 example swaps that have various characteristics, including a master contract and two legs, which has been mapped to ACTUS already. The Mizuho sample data is available here - and ACTUS mapping is available here - .

Note that the data used for this pilot is limited to Interest Rate Swap contracts, and does not include other kinds of swaps. The CFTC breaks swaps down into 5 categories: (1) interest rate swaps, (2) credit default swaps, (3) commodities swaps, (4) foreign exchange swaps, and (5) equity swaps (asset classes). In FIBO, definitions for interest rate swaps and equity instruments (but not the swaps based on them), and Fx (but not the swaps based on Fx rates, which could involve, for example, a swap between spot and futures market rate), are in release, whereas CDS and commodities definitions are only provisional at this stage. This usage scenario focuses solely on interest rate swaps, for which we have sample dummy data to use as the basis for creating individuals.

IV. Competency Questions

How would a market participant map their source data on IR Swaps to a common format for standardized reporting to a regulator?
How would a market participant map their source data for any swap contract to this common format for standardized reporting to a regulator?

We will use the EBRDF data, just the IR Swap examples to ask and answer this question. Individual example line items from the sample data will be mapped to FIBO, and then organized according to the latest schema from the CFTC.

Next steps to answer question 2, once that effort has been completed, include expansion to cover all of the instrument types. Note that additional sample data will be needed to accomplish this.

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.