...
II. Use Case Summary | |
Goal | To provide greater accuracy, currency, harmonization, aggregation, more transparency, and higher quality in general across diverse derivatives reporting sources |
Requirements | To provide a standardized reporting capability for derivatives using a common financial language |
Scope | Reporting could be viewed from a number of perspectives: (1) a given institution might want to be able to create reports 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, to be able to analyze and report on the derivatives for which they receive reports and the counterparties to those reports, and (4) from the perspective of a regulator 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. 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 who need to understand the portfolios they manage, SDRs that consume reports provided to them, and regulators that need to analyze and oversee the market |
Description | Summarize the This use case , capturing the essential objectives (no longer than a page), including a quick overview, restated goals, and principal actor(s).
User stories, if applicable, and any narrative mapped from those user stories to usage scenarios should be included in the Usage Scenarios section, belowinvolves 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. |
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. |
Pre-conditions | Identify any assumptions about the state of the system that must be met for the trigger (below) to initiate the use case. Any assumptions about the state of other related systems can also be stated here. List all preconditions. |
Post-conditions | Provide any conditions that will be true of the state of the system after the use case has been completed. |
Triggers | Describe in detail the event or events that initiate the execution of this use case. Triggers can be external, temporal, or internal. They can be single events or a complex event that indicates that some set of conditions has been met. |
Performance Requirements | List any known performance-specific requirements – timing and sizing (volume, frequency, etc.), maintainability, reusability, other “-ilities”, etc. |
Assumptions |
|
Open Issues |
|
...