Article
EMIR UTIs – Part 2: Everything you always wanted to know, but were too afraid to ask

By Tony Russell, Commerzbank

In our previous article, we looked at why a UTI is required and at what proposals exist to standardise this across the market.  Here, we consider what that means in practice:

Generally, for a sell-side institution, the ISDA proposal boils down to:

• If a counterparty UTI should be used, capture it when available to override own UTI – this is unlikely to be automated
• Communicate UTI to counterparty through as many means as possible, in particular on the confirmation.

A buy-side institution will, therefore, usually receive UTIs from a 3^rd party or the sell-side (assuming all sell-side institutions follow the ISDA proposal).  If it trades with another buy-side institution, it could follow the ISDA tie-break rules to determine who generates the UTI.  Note that, if it is going to generate the UTI, it will need to communicate that UTI to its counterparty, chiefly using the confirmation.

Manual capture of a UTI is to be avoided where possible – for material volumes of trades it will require additional headcount and keying in up to 52 seemingly random characters will be highly error-prone.  The seemingly obvious choice – always generate the UTI – has issues of its own, such as how will you communicate it to your counterparty where they send the trade confirmation to you, and what will you do when your counterparty also wants to generate its own UTI to send to you?

Ultimately, debate over who sends and who receives a UTI simply attempts to shift the problem onto someone else – we need to aim to get as many UTIs fed in automatically to reduce the overall burden.  Maximising usage of existing market infrastructure, such as ECNs or MarkitWire, will help, however, for some asset classes and products it simply does not exist yet.  No doubt new infrastructure will be developed, e.g., TriOptima’s recently announced UTI matching solution.  But not everyone uses TriOptima.

In practice, handling UTIs will be a large task.  At Commerzbank, we found we have around 25 3^rd party UTI generators (shown on the diagram in blue), whose interfaces need to be enhanced to capture the UTI automatically.  We then need to amend a further 9 deal-capture systems (pale orange) in order to store the UTIs in 8 position-keeping systems (yellow).  The position-keeping systems also need to be able to generate our own UTIs for any trade which does not already have one.  These systems between them then feed our reporting systems (red), as well as confirmation systems, collateral management systems and various others (dark orange), to include the UTI on any communication of a trade to a counterparty.

Issues

There are a number of issues outstanding regarding UTIs, including:

• FX swaps – DFA required these to be reported as 2 separate legs (2 USIs), whereas for EMIR they must be reported as a single trade (1 UTI) – how could we then have a single unique ID on a dual-reportable trade?
• Complex trades and strategies – it’s not clear how to report these – do we report them as a single trade with a single UTI, which would omit many relevant details from the report, or as multiple component trades with multiple UTIs?
• How do we agree UTIs for those backloaded trades that require them?

All of the above are still open to interpretation – so how do you get the same interpretation as your counterparties?

Implications for you

Clearly, with the EMIR reporting start date now confirmed as 12 February 2014, it is essential to decide your approach for handling UTIs as soon as possible.  It may be an option to delegate reporting to your counterparties, thus avoiding the need to worry about UTIs, although you should still store the UTIs your counterparties use.

Key challenges:

• Will you follow one or both of the aforementioned proposals?
• Will you adopt a bilateral agreement with each of your counterparties?  What if they won’t all agree to your proposal – will you end up with multiple bilateral agreements?
• Where you generate the UTI, how will you ensure it is globally unique?  And how can you communicate it to your counterparty in a timely manner?  Large sell-side counterparties will likely report trades regardless of whether a UTI arrives in time or not, so if your counterparty reports without a UTI or doesn’t report by T+1 because it hasn’t received your UTI, you will have a reconciliation break to deal with
• Where you receive the UTI, can you capture it automatically?  If not, will you be able to cope with the volume and operational risk of manual capture?
• How will you agree UTIs when backloading open trades?

The effort to handle UTIs in Commerzbank, as can be seen from this diagram, is quite large – over 20 systems requiring changes, which need to be tested front to back with 25 sources.

Commerzbank is well under way with this but, with just 3 months before go-live, if you haven’t started yet, you need to get cracking on your solution now.