...
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 | State any requirement(s)specific to this use case, including any capabilities from a business architecture or process model that the use case supports, any metrics or other reporting requirements, etc., including any reference identifier for the requirement(s), as applicable |
Scope | Identify any known boundaries and the intended scope of the use case |
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 | 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. |
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 |
|
...