Exposure Analysis Explained

There are two main components to meaningful exposure analysis:

1. Considering the different roles a financial institution can play

2. Accurately reflecting the effect of notional-based derivatives holdings

These can be addressed separately as each piece provides valuable information on its own, but combining them tells a more complete story.

Roles

Companies and other legal entities can play multiple roles in relation to a transaction. One of the main roles for equity and fixed income securities is that of an issuer. Bankruptcy of an issuer can mean partial or full loss of capital invested in the security. This is commonly referred to as issuer exposure.

For over-the-counter (OTC) securities, the institution on the opposite side of a transaction is the counterparty. This is equivalent to the issuer relationship for equity or fixed income securities, as bankruptcy of a counterparty can also result in partial or full loss of capital invested in the trade. This is commonly referred to as counterparty exposure.

Institutions can also be brokers to settle trade proceeds and/or clearing brokers to settle variation margin. In the intertwined world of financial markets, the same institution can (and often does) play multiple roles for different securities held in the same fund. This makes it critical to have a holistic view of exposure reporting.

Example of Institution Playing Multiple Roles

In this example, a fund that invests in these securities has exposure to Financial Institution X in several forms. Some of that exposure is unlikely to be included in traditional analyses.

Managing Roles

It is important to understand how the various roles are managed in Eagle and where the data is available. Some fields are only available at the position level, while others are only available at the lot level. General Reporting does not support both types of data on the same report, and Eagle Enrichment is only available for position-level data.

Considering these constraints during initial configuration will help establish expectations for building reports. Multiple reports are required to reflect all the roles a financial institution can play.

Security Level (Issuers)

All issuers are set up using the Issuer Relationship architecture. There are several groups of screens used to manage issuers: Issuer Information, Issuer Cross Reference, Issuer Details, Issuer Ratings, Issuer Role Details, and Issuer Relationship. Issuer data is stored in Data Management using various dedicated tables in SECURITYDBO: ISSUER, ISSUER_DETAIL, ISSUER_ORGANIZATION, etc. Every issuer has a unique ISSUER_ID, but each issuer can be assigned to play multiple roles. Issuers are assigned to roles using Add Issuer Role Details.

For traditional securities, such as equities and fixed income, where the issuer exposure lies with a single organization across all trades, the exposure is captured at the security level using Issuer Name (2285) and Issuer ID (2299). These same fields are available at the security level for derivatives as well, but are often not used.

Note: it is important to maintain tight controls on your list of issuers to avoid duplication. Duplicate instances of the same issuer are likely to lead to inaccurate exposure reports, as all of the exposure to a given organization may not roll up correctly to the correct issuer.

Availability

Issuer Name is a security-level field available for the following security types: equities, fixed income, future contracts, option contracts, CDS and CDX. It is available in RDC for multi-leg swaps and can be added to Issue Viewer and/or SRM using Web Panel Designer. Additional information about issuers can be added using Add Issuer Role Details.

Issuer-level exposure reports can be built in General Reporting by grouping on security type and Issuer Name, assuming Issuer Name is populated on the security master. For securities where the exposure lies with the underlying issuer, or to view exposure to a particular underlying instrument, the Underlying Process functionality can be used within Field Attributes. This allows a position-level report in General Reporting to return the underlying security's Issuer Name. The Field Attribute should target SECURITYDBO.SECURITY_MASTER.ISSUER_NAME, with Underlying Process = Underlying and Underlying Type = Primary. Issuer Name must be populated on the underlying security.

Depending on your requirements, this can be used in conjunction with a regular Field Attribute for the parent security's Issuer Name. There are two options

• View both the parent and underlying Issuer Name on a single report

• Create two separate reports, one filtered for securities with an underlying issuer and another for securities without one, allowing exposure to be viewed at the ultimate issuer level

Trade Level (Brokers & Counterparties)

Brokers

There are two types of brokers available at the trade level for all security types:

• Broker (88): this is the executing broker, and is required on all trades

• Clearing Broker (1237): only required for trades where the security has Variation Margin (4533) = Yes

  • This can be used to capture the counterparty for trades that do not have the dedicated Counterparty Name (1173) and Counterparty ID (1144) fields (more details below)

  • There are benefits to using the Counterparty fields because they are incorporated into the Issuer Relationship architecture, but they are not available on all trade screens

  • If you are considering using Clearing Broker to capture the counterparty for some trades, it may be preferable to use it for all trades (even those with dedicated Counterparty fields) to ensure consistent reporting

Note: Broker and Clearing Broker are stored in the LOT_LEVEL_POSITION_DETAIL and TRADE tables.

Both lists are maintained using Codes/Code Categories and Code Values. You must make any additions before attempting to process a trade. The Code for brokers is BROKER CODES, and for clearing brokers it's CLEARING BROKER.

• It is important that each broker and clearing broker's Code Value Short Description be set up to exactly match the corresponding Issuer ID

  • For example, if Financial Institution X is set up with an Issuer ID of FIX, the Code Value Short Description should also be set to FIX

  • This is key to properly rolling up exposure to FIX across all the roles it plays

Counterparties

Fields to capture the counterparty of a particular trade are available on all swap trade screens. These use the same Issuer Relationship architecture as security-level issuers to streamline exposure reporting. Implementation does not require adding a new role; instead, simply set Counterparty (213) to Yes when using Add Issuer Information or Edit Issuer Information. When booking a swap trade, all issuers with Counterparty = Yes will be pulled into Counterparty Name (1173) and Counterparty ID (1144) on the swap trade screens. This allows you to identify issuers (counterparties) at the trade level rather than the security level, consistent with the way OTC derivatives are traded in the market.

Notes

• Counterparty Name and Counterparty ID are not currently available on other derivative trade screens (forwards, futures, and options)

• Counterparty is stored in the LOT_LEVEL_POSITION_DETAIL and TRADE tables

Derivatives

Most derivatives are based on notional value rather than true principal value like equities and fixed income, and many are structured to have zero net present value (NPV) at trade time. This results in market values (MVs) that are often vastly smaller than a security's notional value. The MVs flow through to exposure/holdings and performance reports in a way that is mathematically accurate, but it significantly understates the true exposure and misrepresents the true security-level performance. When building lot-level reports to reflect counterparty exposure for derivatives, the MV that is used for accounting will be reflected.

For single-leg derivatives such as future contracts, option contracts, and CDS/CDX, the solution is to include a security's notional in its MV, while creating a synthetic cash security that offsets the full notional value. For multi-leg derivatives such as interest rate swaps (IRS) and total return swaps (TRS), the solution is to move the MV from the contract to the receive leg (again including its notional), and use the the pay leg as the offset.

Manipulating values for synthetic cash and the legs of a swaps is accomplished using Eagle Enrichment. This is a standalone tool in Data Management that runs at the position level after the S2P push, once holdings and cash activity data have been populated. Running at the lot level is not supported. It can also be used for activity loaded directly into Data Management by clients who do not use Eagle Accounting, but the rules were built assuming data would be in the locations supplied by S2P. If you do not use Eagle Accounting, you must either ensure your data is loaded to the same locations, or adjust the rules to accommodate your unique data structure.

Instrument Engineering provides standard rules for future contracts, option contracts, and several flavors of swaps as part of the package content, and we are always working to add support for additional derivative types. The standard rules are attached to Instrument Engineering's best practices documents for each supported security. You are able to customize these rules and add your own if the package content does not meet your needs.

Eagle Enrichment

Eagle Enrichment can be implemented if exposure-based analyses are required, but it can only access and write position-level data (POSITION_DETAIL, for example); it cannot access or write lot-level data (LOT_LEVEL_POSITION_DETAIL). Lot-level data, which includes information enters at trade time, cannot be merged with position-level data using standard Eagle reporting at this time. This prevents you from using enriched data on lot-level counterparty reports. There are two options if notional-based analyses are required at the counterparty level:

• For all securities, populate Issuer (2299) with the institution that carries the counterparty exposure, then group enriched position-level reports by Issuer

• Run both the position- and lot-level reports, then cross-reference the enriched values from the position-level report to the lot-level counterparty report

Standard Eagle Enrichment rules for Eagle Accounting users are available for the following instrument types: futures, options, CDX, CDX, interest rate swaps (IRS, V15 R2.29), and total return swaps (TRS). The .egl rule files are available in the corresponding best practices for each of these instrument types. Data that is generated through Eagle Enrichment is stored under a separate source (EAGLE ENRICHMENT by default) that does not effect the raw accounting data. This alternate source can then be used for reporting.

Implementation

There are two options for modeling derivatives traded with multiple counterparties: security level and trade level. Consider the example of CDX.A traded with both Counterparty X and Counterparty Y.

• Security Level: in this model, a counterparty is viewed as a security-level attribute and you maintain a separate version of the security for each counterparty

  • Following the initial example:

    • Two separate security master files (SMFs) are set up for CDX.A, one with Issuer = Counterparty X and one with Issuer = Counterparty Y

  • This model allows both position- and lot-level exposure reporting, as the issuer will be the same across lots

    • Eagle Enrichment can be used for position-level reporting

• Trade Level: in this model, a counterparty is viewed as a trade-level attribute and you maintain a single version of the security regardless of how many counterparties it's traded against

  • Following the initial example:

    • A single SMF is set up for CDX.A

    • Issuer X and Issuer Y are set with Counterparty = Yes to make them available as counterparties

    • Counterparty is set to Counterparty X and Counterparty Y on their respective trades

  • This model requires lot-level exposure reporting, as counterparties will be different across lots

    • Eagle Enrichment cannot be used for lot-level reporting 

Exposure Reports

MV-Based

S2P can transfer data at both the position and lot levels to Data Management. This is controlled by STAR Data Filter (2283). Because some OTC securities can be traded with multiple counterparties, there may be requirements do MV-based exposure reporting at the lot level. However, Eagle Enrichment is only performed at the position level. You must build your exposure-based reports at the position level if you want to use Eagle Enrichent to calculate notional market values.

Note: S2P does not include CASH securities in the lot-level push. As such, any lot-level reports will be missing the cash position(s). If this a problem, a custom exporter can be implemented to copy CASH positions from the position-level tables to the lot-level tables.

General Reporting (Eagle OLAP)

OLAP reporting has rich features to create customized lot-level exposure reports. The table below contains some key Field Attributes that can be used for these reports, but you will likely want to add other fields to meet your specific needs. For step-by-step instructions on creating an OLAP report, please refer to the General Reporting Reference Guide 2015. Lot-level exposure reports cannot include data from Eagle Enrichment because it is only available at the position level.

Notional-Based

As discussed earlier, a derivative's MV is typically not a very accurate measure of the true exposure provided by the security. To build position-level notional-based exposure reports, you must implement Eagle Enrichment to generate notional market values for derivatives. One of the benefits is that data is published to the same locations as S2P, except under a different source (EAGLE ENRICHMENT). This means you do not necessarily need to change the Field Attributes used in your reports when doing notional-based analyses. Instead, you have two options:

1. Duplicate the MV-based report and change the Source Rule to only use the EAGLE ENRICHMENT source

   • With this method, any securities that are enriched will have null values on the report

   • You may also choose to run all of your holdings through Eagle Enrichment, which will copy over the the regular MVs to the EAGLE ENRICHMENT source for securities that do not not require a separate notional-based calculation

     • In this case you can have dedicated reports using the EAGLE ENRICHMENT source that still include data across all security types

2. Edit the existing Source Rule of your report to have EAGLE ENRICHMENT take priority

   • With this method, securities that were not enriched Eagle Enrichment will still show their original values on the report

   • This allows you to pull enriched data for some securities alongside original data for other securities

     • The downside is it may not be obvious when there was a problem with Eagle Enrichment based on looking at a report, because the original data will still be displayed even if a security was supposed to be enriched