I. Use Case Description | |
Use Case Name | Counterparty exposure in a derivatives trading network |
Use Case Identifier | DER-EXPOSURE |
Source | DER Content Team |
Point of Contact | |
SEC-Creation / Revision Date | 6/11/2019 |
Associated Documents | Requirements documentation, traceability matrix if applicable |
II. Use Case Summary | |
Goal | Counterparty exposure is one aspect of managing risk related to derivatives reporting, as one of many requirements related to regulatory reporting on risk. It involves knowing who your counterparties are and rolling up the risk across legal entities under various scenarios - based on parameters required for stress testing. Clearly organizations need to understand their counterparty exposure regardless of the reporting requirement. Companies have many subsidiaries and complex relationships, and understanding total exposure across legal entities can be difficult at best. The goal is to show how to use FIBO to demonstrate total exposure to a given counterparty. |
Requirements | Regulators are concerned with understanding the networks of counterparties, whereas in this case, typically an institution would act as one counterparty to the instruments on their books. Exposure, in this case, is intended to be from the perspective of a given counterparty, such as a majority stakeholder, minority stakeholder, or other owner, including a specific institution. Understanding exposure involves percent ownership, what the risk in a given subsidiary might be, what happens if the subsidiary goes under but the parent does not, backing / recourse behind such situations, etc. Another concern is to understand what is going on between counterparties, between traders, and so forth, where an institution or trader might be part of a network, especially in cases where a given trader uses multiple accounts to avoid certain reporting requirements, for example. Institutions need to understand the networks that their traders participate in as well, to make sure that they are not exceeding position limits or exposure requirements. They also need to understand counterparties from an ownership and control perspective to understand overall exposure to a higher-level organization. |
Scope | Counterparty exposure could be viewed from a number of perspectives, building on the reporting use case: (1) from the perspective of an institution, to be able to understand their exposure in aggregate, or with respect to a given counterparty including its ownership and control relations, or with respect to a given trader or group of traders, for derivatives (including futures and swaps, among others) and spot market instruments on their books, (2) similarly, from the perspective of a broker/dealer, to be able to understand their exposure in aggregate, or with respect to a given counterparty including its ownership and control relations, or with respect to a given trader or group of traders for the derivatives and spot market instruments they manage and/or own, 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 understand their clients' exposure in aggregate, or with respect to a given counterparty including its ownership and control relations, or with respect to a given trader or group of traders from which they receive counterparty information, and be able to spot issues in those networks and report them back to their clients and/or to the regulators in a timely way, (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 (1) to understand exposure in various networks of counterparties, including drilling down to the trader level, where those traders might be using multiple accounts across multiple institutions to spread their trades, whereby they may exceed position limits or other exposure requirements (whether or not they do so on purpose), and (2) to aggregate counterparty risk across groups of institutions, groups of traders, markets, and so forth. |
Priority | This use case follows from the regulatory reporting use case, but requires additional content in FIBO to support understanding exposure, and in particular, counterparty exposure. |
Stakeholders | Executives within financial control / risk, anyone within the risk organization responsible for identifying counterparty risk, chief risk officer and other C-level executives, board of directors, regulators ... |
Description | Summarize the 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, below. |
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.
IV. Basic Flow of Events
Narrative: Often referred to as the primary scenario or course of events, the basic flow defines the process/data/work flow that would be followed if the use case were to follow its main plot from start to end. Error states or alternate states that might occur as a matter of course in fulfilling the use case should be included under Alternate Flow of Events, below. The basic flow should provide any reviewer a quick overview of how an implementation is intended to work. A summary paragraph should be included that provides such an overview (which can include lists, conversational analysis that captures stakeholder interview information, etc.), followed by more detail expressed via the table structure.
In cases where the user scenarios are sufficiently different from one another, it may be helpful to describe the flow for each scenario independently, and then merge them together in a composite flow.
Basic / Normal Flow of Events | |||
Step | Actor (Person) | Actor (System) | Description |
|
|
| |
|
|
| |
|
|
| |
V. Alternate Flow of Events
Narrative: The alternate flow defines the process/data/work flow that would be followed if the use case enters an error or alternate state from the basic flow defined, above. A summary paragraph should be included that provides an overview of each alternate flow, followed by more detail expressed via the table structure.
Alternate Flow of Events | |||
Step | Actor (Person) | Actor (System) | Description |
|
|
| |
|
|
| |
|
|
| |
VI. Use Case and Activity Diagram(s)
Provide the primary use case diagram, including actors, and a high-level activity diagram to show the flow of primary events that include/surround the use case. Subordinate diagrams that map the flow for each usage scenario should be included as appropriate
VII. Competency Questions
- For a given portfolio, what is the exposure to each of the relevant counterparties involved in end-of-day positions?
- The risk may depend on the type of product, for example there are differing risks for certain commodities. It also depends on the time horizon, for example, when are certain payments due, what does the market look like for a particular product, etc.
- For foreign exchange, it could mean exposure to a single currency across counterparties or with respect to a certain set of counterparties.
- This may involve not only the risk to certain counterparties and how has that exposure been hedged in order to mitigate it.
- Thus this is sort of a matrix between products and counterparties, all products for one counterparty, all counterparties for one product, with respect to one product and one counterparty ...
- What is the counterparty exposure for a portfolio at any point in time (intra-day, end-of-month, etc.)?
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).
VIII. 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 |
|
|
Other Resources, Service, or Triggers (e.g., event notification services, application services, etc.)
Resource | Type | Description | Owner | Source | Access Policies & Usage |
(sensor or external service name) |
| Include a description of the resource as well as availability, if applicable | Primary owner of the service | Application or service URL; if subscription based, include subscription and any subscription owner |
|
|
|
|
|
|
|
IX. 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
X. 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.