I. Use Case Description
Use Case Name
Counterparty exposure in a derivatives trading network
Use Case Identifier
DER Content Team
Point of Contact
SEC-Creation / Revision Date
Requirements documentation, traceability matrix if applicable
II. Use Case Summary
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.
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.
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.
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.
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 ...
For the purposes of this use case, the following definitions apply:
The latter, financial exposure, is what we are talking about with regards to this use case, and includes obligations as well as investments (perhaps the definition should be amended to include that).
The use case that consists of analyzing, assessing or measuring “counterparty exposure”, is -- owing to the variety of dimensions and facets of both of the two primary domains that make up the topic (i.e., “counterparties” and “exposure”) – itself a potentially very robust and broad use case by virtue of the large number of cross-products of the dimensions and facets inherent with the combination of those two principle domains.
In order to better manage the elaboration of this use case, it would be useful to understand the types, and depth of detail, regarding the dimensions and facets that comprise “counterparty exposure”. Two approaches to the effective examination of counterparty exposure use case could be taken: (1) in which the number of factors and dimensions are purposely constrained in order to be able to feasibly consider a broad and inclusive treatment of counterparty exposure by limiting the depth of the classifications, or (2) a more narrowly scoped use case that would consider, in greater detail and depth, a specific example of counterparty exposure that would be limited to a particular type of counterparty and a particular type of exposure.
Given the definition of “counterparty exposure in a derivatives trading network”, this use case is perhaps best described as something between (1) and (2) above, having both some broader aspects as well some more narrow ones.
What are the appropriate dimensions and facets of the ‘counterparty’ domain to consider for this use case? These could perhaps be first grouped into what might be called ‘horizontal’ and ‘vertical’ dimensions: the ‘horizontal’ aspect pertaining to the classification of different types of counterparties, and the ‘vertical’ one that considers where in a hierarchy of related counterparties does a counterparty sit?
Given the ‘derivatives trading’ sector of the use case, the type of counterparties that would be relevant would consist primarily of “central banks”, “commercial banks”, “clearing organizations”, “municipal jurisdictions” and “private companies”, since any of those entities could be counterparties to derivative transactions. “Retail consumers” would not be included since derivative contracts almost never involve individuals. Furthermore, if the focus is truly on counterparty exposure (as in, risk), then one would conceivably omit regulatory reporting, as the focus and objective of regulatory reporting is primarily on systemic risk and financial system stability.
If we consider the ‘vertical’ (i.e., hierarchical or relationship) counterparty dimension, then the aggregation of counterparty exposure up organizational hierarchies (whether private or public) could conceivably bring some measure of counterparty exposure at an aggregate or systemic level into consideration. This is somewhat counter-intuitive, however, since a network or systemic measure of counterparty exposure is a very different type of metric than, say, the set of counterparty exposures of a single entity vis-a-vis its immediate counterparties.
When it comes to the “exposure” topic itself, the classification dimensions and facets become much more varied and numerous.
There is, of course, the exposure to a single derivative contract. Since derivative contracts are inherently customizable, there are also a substantial number of different derivative contract types. Furthermore, an entity can have many, many derivative contracts with another single entity (consider those between one large commercial bank and another large commercial bank).
And, as is the widespread practice in measures of exposures (and credit risk), factors such as the related industry sector, geopolitical domicile, currency, market reference rates, and/or interest reference rates that are contained in derivative contracts -- and, importantly, properties of the counterparty on the other side of the contract -- are all relevant to counterparty exposure.
Hence, “counterparty exposure in a derivatives trading network” is a fairly robust use case, even with limitations and restrictions.
Actors / Interfaces
Exposure by a single entity to a single counterparty broken down by the above factors is part of ‘counterparty exposure’, as are the totals of exposures in each of these factors aggregated across all counterparties.
Furthermore, each of those factors and facets constitute external dependencies that affect the performance, and risks, associated with a derivative contract, and which are not under the direct control of the institution
For derivative contracts that involve notional amounts (no exchange of principal), the exposure is in the form of what might occur if contractual cash flows are interrupted, or what the effect on net cash flows would be under different risk scenarios. For derivative contracts in which principal amounts are actually funded or obligated, the exposure is, of course, the amount of the principal that could either be lost or demanded.
The above subset of the “counterparty exposure in a derivatives trading network” is from the perspective of a single institution vis-à-vis its counterparties, and it does not really address the types of counterparty exposures that exist with, for example, central counterparty clearing (CCP), but it does include the type of counterparty exposure that, say, a government or municipality would have when engaging in a cross-currency swap for the purpose of restructuring or hedging public debt, for example, the counterparty exposure of the Greek central bank that resulted from the USD - Euro currency swap created for them, which resulted in financial as well as reputational exposure.
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
- 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.)?
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
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
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
There is always some piece of information that is required that has no other place to go. This is the place for that information.