The UTI is essential for successful EMIR reporting – get it wrong and your reports won’t match. However, although it sounds simple, in practice there is a great deal of complexity. Anyone who needs to report under EMIR needs to determine their approach for handling UTIs as soon as possible in order to meet the reporting deadline of 12 February 2014 …
EMIR generally requires both parties to a trade to submit a report on that trade to a Trade Repository (TR), using a common Unique Trade Identifier (UTI). The TR(s) will then link the 2 reports together using that UTI to ensure they match. Therefore, both parties must agree a common UTI in order to make their respective reports, or they will have to deal with large numbers of TR reconciliation breaks.
This means adopting one (or more) of the following approaches:
- A 3rd party generates the UTI and communicates it to both parties
- The parties decide which of them should generate the UTI, then that party must communicate it to the other
- Both parties are able to generate the same UTI, based on data they both already know.
EMIR requires that the UTI be a globally unique string, of up to 52 alphanumeric characters (some symbols are also allowed). So, when a UTI is generated, some means of ensuring uniqueness is required, e.g., using a namespace (unique UTI prefix belonging to the generator) or using a large pseudo-random number such that the chances of a non-unique value being generated are very low.
A look at the proposals…
A number of proposals exist for how to meet the above requirements, notably ISDA’s proposal for OTC derivatives and FOA’s (Futures and Options Association’s) proposal for ETDs (now in the EACH (European Association of Clearing Houses) whitepaper).
ISDA’s proposal is a combination of approaches 1 and 2; where a suitable 3rd party already exists, such as an ECN or affirmation platform, both parties should use approach 1, otherwise they should use approach 2. The UTI is created by using a 10-digit prefix, equivalent to the DFA USI prefix, which is specific to the generating party; the rest of the UTI then needs to be unique within the generating party. For example, Commerzbank’s prefix would be 1030239971; the remainder of the UTI would consist of system mnemonics, trade IDs or other data which would be unique within Commerzbank.
ISDA further proposes that the rules for deciding which party should generate the UTI in approach 2 are the same as those used in determining the reporting party for DFA. This is necessary if a UTI is to have the same value as the USI (Unique Swap Id) used for reporting dual-reportable trades under DFA. Once that party has generated the UTI, the principal way of communicating it to the other party is on the trade confirmation.
FOA’s/EACH’s proposal for ETDs follows approach 3 – each party to the trade generates the UTI based on attributes of the trade that they both should know. If these attributes match, then the UTIs should match too and no additional communication between parties is required.
However, the above are still just proposals – the ESMA Q&A published on 11 November 2013 neither endorsed nor contradicted them – so there is nothing to compel anyone to adhere to them. Already we are seeing requests from counterparties to agree to bilateral arrangements – typically “please always use our UTI” – though obviously we can’t all do that!
If, or when, ESMA endorses a particular proposal, then it will be in everyone’s interest to adhere to it. There are drawbacks to the above proposals – it could be possible to identify the UTI generator; rules designed for the US would be applied to European parties who have no link to the US. But time is now short – without an endorsement, reporting parties need to decide their strategy soon.
In the absence of an endorsed option, following the above proposals is likely to be the best bet. Doing nothing is not recommended, as this will mean a last-minute rush to implement what could be complex changes, whilst attempting to negotiate bilateral agreements with each of your counterparties could be difficult.