Frequently Asked Questions

  • Is it possible that the same UTI is created for two trades with different key data?
    In principal yes, but the likelihood is extremely low such that this possibility can be ignored. Also, in line with the ISDA protocol, UTIs should be added to the trade confirmation leading to reconciliation of any discrepancies between counterparties.  
     
  • What if there is a mistake in the key data such that our UTI has a different value than the UTI generated by our counterparty?
    This may happen, and it will probably happen in 1-2% of all cases, depending on the point in time when the UTI is generated. If this is detected, e.g., through eCM confirmation matching, any discrepancies should have been remedied. If it takes place before confirmation matching, confirmation matching may lead to a correction of data in this case the seller’s UTI will be disseminated through confirmation (after application of any amendments and upon successful matching) according to the ISDA protocol, this will be the case even if the UTI was generated using trade data which was subject to amendment in confirmation. It should not be assumed therefore that the UTI is equivalent to the original data used to generate it, as the data may be subsequently changed (as a result of confirmation or another lifecycle event resulting in trade detail amendment) whilst the UTI will always remain unchanged following successful confirmation.
     
  • Is the UTI safe? Can it be reverse engineered?
    The current UTI algorithm uses an open standard describing all the input fields and the hashing algorithm. The list of fields has been chosen balancing the uniqueness requirements versus the easiness to implement the generation process. Using static data for some of the input fields and applying common sense to some other fields could make it possible to apply a brute force reverse engineering mechanism to the UTIs. It remains therefore advisable to safeguard the confidentiality of UTIs and ensure they are only handled and exchanged using appropriately secured communication processes. Equias uses such secure channels for both electronic Confirmation Matching (eCM) and electronic Regulatory Reporting (eRR) in all directions: data exchange with traders and brokers as well as with trade repositories.
     
  • Can I use this technique for backloading?
    Yes, the approach is particularly relevant to resolving back loading issues related to the generation of matching UTIs for historic transactions. Under the assumption that historic trades are confirmed and therefore the likelihood for discrepancies is mostly avoided, you and your counterparty may independently create the same set of UTIs prior to back loading under EMIR and REMIT.
     
  • What does this service cost?
    Nothing. It is a free service provided by Equias.
     
  • Who is allowed to use this service?
    Everyone. It has been extended for assets classes such as FX and IRS since version 1.3 and would principally also work for others  – we only need to define standard values for the Product and PricerateReferenceCode fields.
     
  • My trade data is very sensitive, how safe is it?
    We process your data on-the-fly without storing anything on disk. If this is not save enough, you may locally use the Excel macro or use the reference implementation.
     
  • Has this been tested by someone?
    Yes, Centrica did some tests with counterparties and with more than 1.000 trades the hit rate (i.e. generating the same UTI value on both sides) was 99.7%.
     
  • Why do you add the index as the last step and not before hash creation?
    We believe that is is an important information for users to recognise if there are clone trades such that they can dedicate special attention to them. On the other hand, this doesn't disclose any sensitive trade details to a third party. And finally, the function that generates UTIs can easily recognise if an UTI has already been created for another clone trade with the same trade data.
     
  • How many clone trades can be indexed?
    So far, we have implemented indexing between 01 and 99. If there is a request to extend this range, we would continue countinlexically from "AA" to "ZZ" which would provide another 676 clone members.
  • Does the algorithm support formula swaps?
    Yes, since version 1.3 you may use your formula ID instead of the price/rate reference code for any commodity trade that uses float price information leg.
     
  • What is the risk of a UTI clash if clone trades are executed on different platforms?
    • Let's assume that a trade is executed bilaterally between two traders X and Y, they would both locally generate a USI XY01. Then the same trade is executed on broker B. B issues USI XY01 because B does not know about the “bilateral XY01”.
    • This problem occurs if two traders use different UTI assigning agencies and change them within a set of clone trades (jointly or unilaterally).
    • Another example:
      • CP X and CP Y do a trade through broker B, B issues UTI XY01 for this first trade in a clone set.
      • CP X uses the UTI created by the broker (XY01), CP Y creates an own UTI: also XY01 as this is the first case – everything fine so far!
      • Then a clone trade is created, B issues XY02 (as B knows about the previously created XY01) and X accepts it from the broker. But now CP Y does neither create an own one nor uses the UTI created by the broker (in the first case Y would see a uniqueness violation which would lead to an increment to XY02 if implemented correctly, in the second case B would increment the UTI anyway).
        • Instead, Y leaves the UTI element empty and lets Equias create the UTI through the eCM channel. As Equias does not know about the history, Equias would create a XY01 if Y is the seller and would even override X’s XY02 with a XY01.

    Can this be avoided? Is not realistic that traders change the UTI generation issuer within a day for the same set of clone trades. Therefore, traders MUST NOT change the UTI generating agent within a set of clone trades.
     

  • What other situations exists which may lead to a UTI clash?
    The following may happen: 

    • Two traders do exactly the same trade twice. However, trader X makes a mistake when entering the deal data for trade 2, i.e., the following is created
      • Trader X:
        • Deal 1: yxcvbnm01
        • Deal 2: qwertzu01
      • Trader Y:
        • Deal 1: yxcvbnm01
        • Deal 2: yxcvbnm02

At a later time, trader X corrects the deal data of deal 2 to yxcvbnm01 as the history of UTI creation for deal 1 is not available anymore.
Solution: UTI generating entities MUST keep track of previously created UTIs to detect clashes and to increment the UTI index if a clash occurs.

 

  • Which value to use for data elements “TotalVolume” and “Price” in case of a physical trade with a list of delivery time intervals?
    • for TotalVolume: calculate for each time interval the delivery hours,  summed up across all delivery time intervals.
    • For Price use the CpML TotalContractValue, it is calculated as defined in the CpML standard: for each time interval: delivery hours * hourly price, summed up across all delivery time intervals.

 

  • How do eCM and eRR react if there is no seller LEI available?
    • The UTI generator function (as published as reference code) always expects an LEI for Buyer and Seller. In case of eCM and eRR, fallback UTI generation is done on the CMS with an Equias namespace if a seller LEI in unavailable:
      • Prefix: characters 7-10 of the Equias LEI
      • Characters 11-42: a 32 character random value.

 

  • How is the update process for the UTI generator and for the static data code used?
    • Static data codes, specifically for price / rate reference code, are maintained by EFET and published here: http://staticdata.efet.org/view.aspx?d=IndexCommodity. Whenever we take over such extensions of static data, we will publish this in the UTI Generator change log. Any such updates apply for all UTI Generator channels (Web, Excel macro, Excel upload, Java reference code) at the same time to avoid inconsistencies.
    • Code updates / algorithm updates: The same applies here, we will announce an update date and adjust all channels at the same time.
    • Please send in your request for new static data to This email address is being protected from spambots. You need JavaScript enabled to view it.. The support team will analyse the request, ensure compatibility and compliance with existing static data and post it onto the static data webpage

 

  • How to cope with ESMA’s Q&A update of February 11th 2014, which partly also affects the UTI format and generation process?
    • As this is obviously too late to be addressed for go-live under EMIR, we suggest the following: for the time being, keep the UTI algorithm and format as it stand today. Equias will will publish an impact analysis based on the latest FAQs on the UTI generation and dissemination next week and then organise a conf call to discuss potential way(s) forward, including implementation timing and change management. After having discussed with ESMA how to further proceed here, Equias will announce an update date well in advance such that all users of the UTI Generator and Ponton can synchronise their switch-over to a new schema.

 

  • How to transfer a UTI to the CMS for eCM and how is a created UTI transfered back to the participant?
    • Trader --> eCM: The UTI is transfered to the eCM service using the CpML ECMEnvelope/EUReporting section.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ECMEnvelope xsi:noNamespaceSchemaLocation=http://www.efet.org/schemas/V4R2/EFET-ENV-V4R2.xsd xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <TradeConfirmation>
        <DocumentID>This email address is being protected from spambots. You need JavaScript enabled to view it.<DocumentID>
        <!-- content of a wellformend CNF -->
    </TradeConfirmation>
    <ECMAdditionalData>
        <ReferencedDocumentID>This email address is being protected from spambots. You need JavaScript enabled to view it.</ReferencedDocumentID>
        <CreationTimestamp>...</CreationTimestamp>
        <EUReporting>
            <UTI>...</UTI>
        </EUReporting>
    </ECMAdditionalData>
</ECMEnvelope>

    • eCM --> Trader: A UTI generated by the eCM or eRR service is sent back to the trader, using the eRR BoxResult:

<BoxResult>
   <DocumentType>CNF</DocumentType>
   <DocumentID>This email address is being protected from spambots. You need JavaScript enabled to view it.</DocumentID>
  <DocumentVersion>1</DocumentVersion>
   <ebXMLMessageId>CENTRAL_MATCHING</ebXMLMessageId>
   <State>MATCHED</State>
   <Timestamp>2013-11-12T10:29:27</Timestamp>
   <Counterparty>
      <DocumentID>This email address is being protected from spambots. You need JavaScript enabled to view it.</DocumentID>
      <DocumentVersion>1</DocumentVersion>
      <ebXMLMessageId>CENTRAL_MATCHING</ebXMLMessageId>
   </Counterparty>
   <EUReporting>
      <UTI>AYE8YOZQ4HXXXXXXXXXX</UTI>
   </EUReporting>
</BoxResult>

    • To use the abovementioned Envelope and eRR BoxResult with <EUReporting>, CMS users have to apply this patch for their UAT Ponton X/P installation:

http://ponton-consulting.de/downloads/xp/efet/hub/efet-dist-3.1-cms-test-ECM42-patch.zip

 

  • How to transfer a UTI to the CMS for eRR and back to the participant?
    • In case of eRR, the UTI is part of the reporting envelope: CpmlDocment/Reporting/Europe/EURegulatoryDetails/UTI
    • An eRR BoxResult providing a UTI back to the participant looks as follows:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<ERRBoxResult>
    <DocumentID>CPML_20131002_tradeid0001@party</DocumentID>
    <DocumentVersion>1</DocumentVersion>
    <Timestamp>2013-10-15T15:37:07.868+01:00</Timestamp>
    <EuropeResult>
        <Action>REPORTING</Action>
        <Result>OK</Result>
        <Regime>Emir</Regime>
        <Repository>UNAVISTA</Repository>
        <ReportingResult>
            <TradeID>tradeid0001</TradeID>
            <UTI>PARTY000000000000001</UTI>
        </ReportingResult>
    </EuropeResult>
</ERRBoxResult>

 

Main Menu