Use case: DER-Systemic Risk

I. Use Case Description
Use Case Name	Systemic risk in a derivatives trading network
Use Case Identifier	DER-SYS-RSK
Source	BE/DER Content Team
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	According to Investopedia, systemic risk is the possibility that an event at the company level could trigger severe instability or collapse an entire industry or economy. In 2008, financial institutions and regulatory authorities did not have clear visibility into the concentrations of risk across derivatives trading networks, across the financial system. This resulted in significant deleterious impacts on the financial system. The lack of transparency of data was a major factor. Before Dodd-Frank, the swaps market was very opaque, which allowed situations such as Lehman Brothers to occur. The CFTC and other agencies are attempting to ensure that such situations cannot recur, including but not limited to review of margins and collateral, stress testing, review of counterparty relationships to understand total exposure, all to avoid "too big to fail" cases. It's not only the swaps market that are of concern, but the futures, options, and other derivatives markets, across agencies, that are important to understand. Automation through graph technologies, ontologies such as FIBO, and other technologies such as machine learning are critical to connecting the different markets and understanding systemic risk. Learning algorithms are already used by the SEC and others to attempt to understand some starting points for areas of concern, rather than attempting to use brute force. Building on the standardized reporting and counterparty risk use cases, the goal of this use case is to take that work to the next level, and use the resulting model as the basis for understanding for higher levels of aggregation. If one firm fails, what is the exposure across counterparties to that firm, creating a domino effect, or transitive exposure. And, where other firms have hedged against certain exposures, and used 'insurance' to limit their risk, what are those relationships, and what does total exposure mean under such circumstances.
Requirements	In order to identify and link concentrations of risk across a derivatives trading network, at the lowest level we need the ability to create the data structures that include the characteristics of derivative instruments. At the next level above that, we need the ability to identify the cash flows and positions of the counterparties at given points in time. This is necessary to allow more accurate aggregations from lower to higher levels of abstraction, enabling analytics from various perspectives.
	Although it is possible that a given organization would like to understand systemic risk from their own perspective, the scope of this use case, which rolls up our standardized reporting and counterparty exposure use cases, is intended to be from the regulatory perspective. Counterparty exposure is one aspect of understanding systemic risk, but not the only one. We will limit the scope, in other words, to what can be determined from a combination of the standardized reporting and counterparty exposure use cases, as well as any additional information we can add to assist in understanding the behavior of the network. The focus here is not on generic systemic risk but on systemic risk from the perspective of derivatives – from the various positions on the books of various counterparties, the centrality of parties in the network given transitive closure over aggregate positions, and other information that can be simulated based on the information available in the graph.
Priority	Identify the priority of the use case (with respect to other use cases for the project)
Stakeholders	Identify all known stakeholders for the use case
Description	Take an aggregation that counterparty A has with counterparty B, and create a network of the various counterparties and ownership and control hierarchies, look at influence networks. Using FIBO we can more easily build such networks, look at concentrations at different levels of abstraction, and then run graph algorithms (eigenvectors) to determine influence and centrality across the network. The more influential nodes in the network would have a greater impact on risk in the network. Measures of risk including collateralization, liquidity, and others should also be examined through various algorithms that can be applied across the network and viewed from various aggregations, nodes, etc. 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. 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.