Page Comparison

I. Use Case Description

Use Case Name

Counterparty exposure in a derivatives trading network

Use Case Identifier

DER-EXPOSURE

Source

BE/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, as a minority stakeholder, or other owner, ... this 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

Identify any known boundaries and the intended scope of the use case

Priority

Of the three use cases we have to date, this is the top priority and required in order to implement the others

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.

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