Loading Counterparty and Collateral Details in the GUI
Below is an example of loading collateral details. The key things to note are:
- Each counterpaty is described in a row starting with the term 'Counterparty'.
- The row comprising 'Counterparty,IsInternal,ParentName,ReferenceEntity,ReferenceEntityType' is a header row.
- Each counterparty includes a reference entity field and reference entity type field. These fields are used to match the counterparty against the appropriate credit reference when calculating CVA.
- A counterparty has one or more pools. A pool is a portfolio based on legal agreements with the countperparty. A pool with a netting agreement will have CalcType = 'Netted'; a collateralised pool will have CalcType = 'Collateral'; and pools with no supporting agreement will have CalcType = "Economic Offset".
- Collateralised pools require some 21 fields to be populated, but the other two types of pool require only the first three fields.
- The row labelled "SelfReferenceEntity" is where the counterparty's own credit reference is listed. This reference may be by name or proxy. It is also where the lending and borrowing curves for FVA calculations are listed.
Note: In the figure below the headers have been split over several rows due to their length. The continuation rows are the indented ones. A header must not be split across rows in actual load files.
Collateral Agreements
In a collateral agreement (or CSA) cash is transferred between the counterparties on a daily basis to offset the exposure. There is a netting agreement in place that covers all of the trades in the Pool, so the “raw” exposure on a given path i at timestep t_j is computed as the sum of the trade mark to markets. However, collateral rules, as defined by the parameters in CollateralDetails are then applied in order to define a collateralised exposure. The collateralised exposures are then used to compute credit statistics rather than the raw exposures.
Collateral Fields Description
Note: The fields below follow a convention that the organisation is a "bank" dealing with a counterparty. Your organisation may not be a bank, but treat the bank fields as the ones pertaining to your organisation.
| Collateral Field Name | Description |
| CollateralMode | Simple: The simple collateral modelling approach does not take the CSA into account on a simulation path-by-path method, but rather makes a fairly crude correction to the overall exposure using the collateral rules and assuming a fixed window between a default on the valuation date and an assumed close-out date. Dynamical: The CSA impact on the exposure is implemented on a path-by-path basis in the simulation whereby the collateral rules and parameters are applied to the raw MtM in order to compute the collateralised exposure. The collateralised exposure then takes the place of the raw MtMs when calculating the credit statistics. Window: The Window model introduces a close-out window to the Dynamical model to model the “slippage” or market movement that can take place between the default event and the eventual winding up of positions, and the fact that collateral margining cannot be expected to take place after the default event. |
| CollateralType | This denotes the direction(s) of the CSA. The possible types are: UnilateralReceiver: In this case the organisation receives collateral from the counterparty when the organisation is ITM. If the organisation is OTM, any posted collateral is returned by the organisation but the organisation does not post collateral to the counterparty . UnilateralPayer: In this case the counterparty receives collateral from the organisation when the counterparty is ITM. If the counterparty is OTM, any posted collateral is returned by the counterparty but the counterparty does not post collateral to the organisation. Bilateral: In this case the ITM party receives collateral from the OTM party. |
| ManagingLocation | The geographical location of the CSA (legal jurisdiction). Used for upstream reporting. |
| Currency | The currency in which collateral must be posted. |
| CollateralHeld | The current collateral amount held by the organisation. A negative amount means that the organisation has posted collateral to the counterparty. |
| BankInitMarg | The minimum amount of collateral that must be posted if the organisation is OTM and is a collateral payer. |
| BankIndependentAmount | An amount added to the raw MtM if the organisation is OTM and must post collateral. |
| BankMinTrans | If the Theoretical Collateral Obligation changes from one timestep to the next then in principle a cash transfer must take place between the parties to bring the collateral posted/held in line with the Theoretical Collateral Obligation. However, if the difference doesn’t exceed a Minimum Transfer, then the transfer doesn’t take place and the collateral held/posted remains unchained. |
| BankThreshold | The Threshold is an barrier such that if a party is OTM and a collateral giver, collateral is posted only if the MtM exceeds the Threshold, and then only the amount in excess of the Threshold is posted. |
| BankRounding | A Rounding Amount (R) denotes a minimum quantum of collateral that can be posted. The Rounding is applied to the Net Collateral Obligation to arrive at a Theoretical Collateral Obligation. |
| CptyInitMarg | See BankInitMarg above. |
| CptyIndependentAmount | See BankIndependentAmount above. |
| CptyMinTrans | See BankMinTrans above. |
| CptyThreshold | See BankThreshold above. |
| CptyRounding | See BankRounding above. |
| Window | The frequency with which collateral must be checked and rebalanced throughout the exposure timeframe. |