UTI and UPI Post JFSA and EMIR REFIT Go-Live
Those who have been following Cappitech newsletters and working groups, will be aware of the work that we have been doing in assisting clients with Unique Transaction Identifier (UTI) sharing and Unique Product Identifier (UPI) enrichment.
Since the JFSA Rewrite and EMIR REFIT go-live, we have been assisting our clients with UTI retrieval through our Global UTI Connect module, so that corresponding UTIs can be captured correctly for their submissions.
From an onboarding perspective, it is pleasing to hear that clients valued our support in assisting them navigate through the forms and options required by the different jurisdictional trade repositories. Achieving smooth onboarding was key to getting testing underway as quickly as possible, so kudos to our global integration teams.
Since go-live, clients have noticed differences in some of the pairing field values such as, “Notional”, “Exchange Rate”, “Exchange Rate Basis”, “Option Type”, “Notional amount of Leg 2”. We have been able to show this side by side through a normalized view, so although they are different and within the clients’ tolerance appetite, they have been able to identify them and subsequently pair them either individually or in bulk.
We are still halfway in this journey as we look to further analyze client behavior to improve automation and additionally prepare for the upcoming allege files later this year from the FCA EMIR, ASIC, MAS and CFTC regimes. This will further facilitate clients in achieving global harmonization of UTIs. Feature-wise, we are aiming to provide updated visuals around pairing and UI features to help with UTI management, so please watch this space.
As we change the “T” to a “P” and move onto the topic of UPIs, here is the latest after working with clients post EMIR REFIT.
Some UPIs still do not exist — this could be due to the reliance on counterparties who have creation abilities within their ANNA DSB license. This is problematic as it prohibits clients who do not have this access from setting up new UPIs intraday. Some clients have opted to have either the standard or infrequent user type as it gives them contingency to create UPIs, so it is worth investigating a similar approach.
Field format discrepancies — certain regulatory fields have differences in what is required under EMIR and ANNA DSB. For example, the field “Name of the underlying index” under EMIR is free text up to 50 alphanumeric characters but ANNA DSB has its own taxonomy. Whilst this could be a simple mapping exercise conforming to ANNA DSB, many clients have stated that none of the prescribed values were applicable, resulting in a conflict – clients either need to report accurately under EMIR or may not be able to retrieve the corresponding UPI.
Asset class inconsistencies — Some product definitions are not applied across different asset classes. For example, in FX and equities, CFD is clearly defined but not quite as clear under commodities which has resulted in clients being unable to populate the attributes consistently.
Mandatory Field Inconsistencies — Under the ASIC rewrite, the “Settlement method” field has been decommissioned, but this field is still a mandatory attribute for correct UPI retrieval for most of the products. So, clients need to keep track of this field even though it is no longer required in the regulation.
ISO Standard Inconsistencies — This applies to CFI codes where ANNA DSB uses CFI (ISO 10962:2015) list as a reference list, while many clients use the CFI (ISO 10962:2021) list.
In conclusion, there are still some issues to iron out to ensure that UPI retrieval can be performed unambiguously and without issues. From there, it should be able to serve as a useful identifier for regulatory data aggregation and systemic risk monitoring as it was intended.
If your organization needs assistance in better understanding the impact of UTI and UPI on your reporting, please contact us at regreporting@spglobal.com for additional information.
