EMIR Trade Repositories (TRs) have now started giving reporting entities feedback on their pairing and matching status in the form of an end of day report in respect of the new EMIR Refit.
TRAction explores the process undertaken by the LSEG Regulatory Reporting TR.
What is pairing and matching?
Pairing is the process where the TR identifies and pairs the two sides of the same transaction using the following fields:
- Unique Transaction Identifier (UTI),
- Counterparty 1; and
- Counterparty 2.
Matching is the process the TR does (after successful pairing) to match certain fields of the 2 reported sides of a trade.
Once the trades are paired, you will be able to see the values your counterparty reported that didn’t match (see example below).
What are the relevant fields and do they need to match exactly?
Firstly, the TR doesn’t necessarily try to pair every trade. The pairing is only attempted if the field ‘Reporting obligation of counterparty 2’ is set to ‘TRUE’.
Secondly, whilst there is pairing between TRs in the same jurisdiction, there is currently no formal pairing across jurisdictions, i.e. a trade done by an EU investment firm with a UK investment firm will not be paired.
There are a total of 89 fields that are eligible for reconciliation but a lot of them are only relevant to certain asset classes or trading venues.
Some fields have reconciliation tolerances to allow for different timing and rounding and other factors that may result in a different value from each counterparty being ‘normal’.
| Fields | Comment on matching and tolerance |
|---|---|
| UTI | No tolerance / Exact Match required for Pairing |
| Counterparty 1 | Should be opposite to pair |
| Counterparty 2 | Should be opposite to pair |
| UPI | No tolerance / Exact Match required |
| Direction | No tolerance / Exact Match required |
| ISIN | No tolerance / Exact Match required |
| Venue of execution | No tolerance / Exact Match required |
| Confirmation timestamp | Exact Match not required |
| Clearing Obligation | Exact Match not required |
| Price | Exact Match not required |
| Notional amount of Leg1 | Exact Match not required |
| Notional amount of Leg2 | Exact Match not required |
Here is an example of the report showing the pairing status:
Explanation of the fields and values above:
| Field | Tag | Value | XML Format |
|---|---|---|---|
| Reporting type | RptgTp | Single-sided Dual-sided | SWOS TWOS |
| Pairing | Pairg | Paired Unpaired | PARD UNPR |
| Reconciliation | Rcncltn | Reconciled Unreconciled | RECO NREC |
| Valuation reconciliation | ValrnRcncltn | Reconciled Not reconciled Not applicable | RECO NREC NOAP |
| Revived | Rvvd | Yes No | true false |
| Further modifications | FrthrMod | Yes No | true false |
Here is an Example of the XML report showing the matching status of one of the paired trades above and the unmatched values:
In this particular example you can see that:
- the 2 parties to the trade have been reporting conflicting values for the “master agreement type” – the reporting party has reported it as “BIAG” and counterparty 2 has reported it as “ISDA”;
- the 2 parties also have a different value for “Platform ID” – “TRAL” vs “XOFF”; and
- counterparty 2 has also neglected to report the monetary value account currency – only counterparty 1 has reported the monetary value account currency being ‘GBP’.
If you are interested in learning more about how the pairing and matching reports may affect you, please reach out to our team at TRAction.
