At Cappitech, one of the most difficult processes we solve with our EMIR Reporting technology is UTI matching. Standing for Unique Trade Identifier, a UTI is an alphanumeric identifier required for each trade transaction. For EMIR reporting, both counterparties to a transaction need to report the same UTI for their leg of the trade.
EMIR and double sided reporting
Unlike derivative reporting regulation in other regions, one of the factors that causes difficulty in compliance with EMIR reporting in the EU is that it is double sided. This means, both sides of a derivative trade need to report their side of the trade. In addition, the UTI must match for these reports (more on what is EMIR).
Who generates the UTI?
Currently existing is a hierarchal structure for who is responsible for generating the UTI. For centrally cleared products, the responsibility falls on the exchange or trading venue. For OTC, the sell-side dealer typically generates the UTI. The UTI is then obligated to be distributed in a timely fashion to the buyside participant.
For buyside firms handling their own EMIR reporting and not delegating it through their brokers, it requires them to receive the UTI code for them to be able to comply with the regulation. However, unlike execution reports which are sent immediately to customers, many banks and brokers take longer to create and distribute the underlying UTI they are using for reports. This difficulty in sourcing UTI information can make it very cumbersome for buyside firms to self-report.
UTI matching for buyside firms such as asset managers becomes especially difficult when aggregating trade details from numerous sellside broker partners.
At Cappitech, when encountering difficulties with UTI matching after aggregating data from numerous trade participants, we try to first figure out how a sellside firm is creating the UTI that they create. Often there is a logic that is based on a ticket number and company code that is the basis of he UTI.
In cases where a specific UTI construction logic is used, UTI matching becomes simpler as the alphanumeric identifier can be created with just the details of an execution report. However, not every firm uses a set logic for constructing their UTIs.
In regards to this problem, buyside groups have begun to lobby regulators and the financial industry to create specific standards around UTIs or to remove double sided reporting altogether.
The need for UTI standards has also begun to gain more traction among regulatory bodies. An example is the recent white paper co-published by the International Organization of Securities Commissions (IOSCO) and the Committee on Payments and Market Infrastructures (CPMI), a subgroup operating within the Bank of International Settlements (BIS).
IOSCO and CPMI white paper
Titled Harmonization of the Unique Transaction Identifier, the paper is directed towards financial lawmakers and explains current problems with UTIs and proposals of adopting globally harmonized rules around UTIs.
Areas where the white paper advocated for global standards for UTIs are responsibility of UTI generation and how UTIs handle life cycle events related to trades such as compression, cancelations and trade amendments.
The paper also covers ways to reduce confusions around the structure of the alphanumeric code used for each UTI. Advocated is the use of a company Legal Entity Identifier (LEI) as the base of each UTI.
Cappitech supports these initiatives
At Cappitech we are big believers in UTI standards. We also support initiatives to harmonize the formats accepted by the various trade repositories and ARMs to handle submission of EMIR and MiFID I/II reports.
Our belief is that the goal of regulators of increasing transparency of items such as trade execution quality under MiFID and derivative exposure under EMIR is impeded by the lack of standards.
Without harmonized report standards, regulators are forced to interpret different sets of data made available by TRs and ARMs. Also, financial firms themselves are forced to normalize data sets received from other companies when transacting between each other. This problem leads to increased trade data errors and resources spent inefficiently.