Introduction to OTC Clearing
The OTC clearing module (OC) helps the Temenos Transact system users:
- To understand the regulatory reporting of derivative contracts
- To understand the generation of base data required for reporting using the OC module
The intended audience of this module are as follows:
| Role | Function |
|---|---|
| Dealer | Executes derivative deals with a counterparty and records the deal details in the system, where the reporting data fields can be punched in. |
| Treasury Back Office Personnel | Ensures that the reporting of data fields has accurate information and generates a report on every reportable event. |
| Risk Manager | Ensures that the reporting data generated is accurate and according to the regulatory requirements. |
| IT Personnel of Bank or Financial Institution | Creates and maintains database file and associated mapping rules or logic. Dynamic changes to regulatory norms demand upkeep of the database and mapping rules. |
In 2009, G-20 leaders agreed that all future standardised OTC derivatives are to be traded on exchanges (or) electronic trading platforms (where it is appropriate) and cleared through Central Counter Parties (CCPs). The leaders also agreed to impose higher capital requirements on non-centrally cleared contracts and mandatory reporting of all OTC derivatives trades to trade repositories. These measures were aimed at combatting with credit risk in OTC trade world.
The EMIR regulation is the EU's response to fulfil the G-20 commitment in 2009 that all standardised OTC derivatives are to be cleared through CCPs by the middle of 2016. These OTC derivative contracts are to be reported to trade repositories starting early 2012.
One of the key elements for the introduction of the regulation is the reporting obligation for transaction details and respective valuations and collateralisation. Temenos Transact is enhanced with TAX Engine framework at the centre of the development to meet the reporting requirements. The OC module aims to build reporting capability in Temenos Transact.
The following flow chart gives an overview of the built solution:
The Over the Counter (OTC) clearing framework used for European Market Infrastructure Regulation (EMIR) reporting also covers Markets in Financial Instruments Directive (MiFID) II transaction reporting.
Product Configuration
This section describes the configuration options the system offers in OTC clearing module:
Parameterisation
The tables mentioned below are setup before the input of any transaction at the front office level. The source data for the bank and counterparty becomes available only after the following tables are updated.
Database Creation
TX.TXN.BASE.PARMS is part of Tax Engine Framework in Temenos Transact. This helps to create database files that store the reportable data. The user creates three such database files:
OC.TRADE.DATA
A database file created as OC.TRADE.DATA has all the regulatory reporting data fields and some additional control fields, which the bank or trade repository might require. The screenshots given below shows the sample OC.TRADE.DATA record:
OC.MIFID.DATA
This database file is introduced in TX.TXN.BASE.PARMS for MiFID II data storage. The screenshot given below shows the sample OC.MIFID.DATA record:
Mapping
Mapping rules are defined by using TX.TXN.BASE.MAPPING table in Tax Engine as mentioned below. The ID of the record should be in the following format:
- APPLICATION*OC.TRADE.DATA (for example, FOREX*OC.TRADE.DATA)
- Transaction reporting database (OC.TRADE.DATA) is the same for all OTC applications, and mapping records should be defined for every OTC application that are to be reported.
- Mapping record can be created or amended as required.
- OC.GEN.UNIQUE.ID routine is attached to generate unique ID every time on the ID field.
- Unique ID is in the format transaction reference, suffixed with unique time.
Field mapping can be of two types, linear and routine-based mapping.
- In linear mapping, one to one relationship exists between the source data and database fields.
- In Routine based mapping, logic is used to extract the data.
Product team releases sample mapping routines that are validated by the user based on the latest regulatory clarifications, as applicable for each reporting field. These routines are released as public to enable the user to maintain the same.
To know more on the creation of database files and mapping rules and routines, a separate implementation guide is available.
Sample mapping record for ND.DEAL.
Sample mapping record for OC.VAL.COLL.DATA.
Sample mapping record for OC.MIFID.DATA.
Reporting Data Fields on OTC Applications
The regulatory reporting data is divided into counterparty and common data. While the counterparty data is mostly sourced from the static tables, the common data is mostly from the trade template. Data pertaining to valuation and collateral are sourced from tables where the user maintains them.
OTC application templates such as FX, ND, FRA, SWAP and DX are added with the reporting fields to support the common data fields. These reporting fields are grouped under one tab titled Reporting in Model Bank configuration.
An illustration of the reporting data fields for plain vanilla NDF trade deal is given below. This sample shows the configuration done in Model Bank:
Values in some of the fields are system generated or defaulted and others are user input specific.
The Unique Txn Id field is system generated based on an API attached in OC.PARAMETER. The logic embedded in that is based on the ISDA guidance on UTI generation. The system populates the value only when the field is blank at the time of committing the transaction. The Action Type is an important field with the following optional values:
- N - New
- M - Modify
- E - Reverse and Error
- C - Cancellation
- Z - Compression Update
- V - Valuation Update
- O - Other
- R - Correction
- P - Position Component
- Null
Deal capture automatically updates the value as N, reversal updates as E, and modification that requires a reporting updates M. However, the user can change the values based on the requirement. When there is a change in the value during authorisation, the system identifies that the change that requires a reporting and consequently updates the database file.
The Over the Counter (OTC) Clearing framework used for European Market Infrastructure Regulation (EMIR) reporting also covers Markets in Financial Instruments Directive (MiFID) II transaction reporting. The new database file (OC.MIFID.DATA) is populated, when capturing or authorising a transaction through FOREX, ND.DEAL, FRA.DEAL, SWAP and DX.TRADE applications (if the conditions in TX.CONDITION are met). The Action Type field is not used for MiFID, instead it is replaced by MiFID Report Status field which accepts the following values:
- NEWT - New reports
- CANC - Cancellation reports
The MiFID Report Status field has NEWT value for each new transaction, which the user can change to CANC if cancellation is required for already generated reports. Once the transaction is authorised, the OC.MIFID.DATA database is populated for the deal (based on the mapping in TX.TXN.BASE.MAPPING).
Illustrating Model Parameters
The model parameters consists of the following:
| S.No | Parameters | Description |
|---|---|---|
| 1 | OC.PARAMETER
|
This table is used to store the static data of the Temenos Transact banks and other tables, which store the static data of the concerned parties such as Counterparty, Trade Repository, regulatory and so on. Below are the TXN records mapped in the TXN tables of Transaction and Collateral & Valuation enquiries:
|
In this topic