Six months after the CFTC Rewrite go-live, the focus has shifted toward upcoming events on the regulatory reporting calendar. The very next event is the block/cap size change set for this December. Right after that, on the 29th of January 2024 is the introduction of the UPI (Unique Product Identifier) and the focus of this blog. (Commodities get a pass from the CFTC, likely until the mandate for ISO XML in 2025)
Once introduced, the UPI will supersede most current SDR product fields with a single identifier being submitted to represent the product attributes maintained by ANNA DSB in a centralized database. The UPI will fulfill a critical role in OTC derivatives reporting, replacing a range of product classification and identification approaches with a single identifier to facilitate analysis and aggregation.
There was a 60-day window for the CFTC Rewrite go-live to update open swaps. This time around, there is no such window. Reporting parties will have to update all their open swaps by the compliance date.
In this blog, we’re discussing some of the challenges reporting parties will need to overcome while adding UPI into their reporting workflow.
Coming off of the failure of some reporting parties to upgrade all of their open swaps during the 60-day window after the rewrite go-live, the CFTC has taken the position to require that updates to add UPIs to open swaps must occur by the compliance date, immediately elevating the day-one burden reporting parties face for UPI implementation for CFTC.
Connection to ANNA DSB
Reporting parties must ensure their systems can connect to ANNA DSB to generate or retrieve UPIs within the timeframe required for their reporting obligations. When new products are traded, due to the UPI being required on real-time reporting for the CFTC, reporting entities should put in place a practice to obtain the UPI prior to trading a new product in order to avoid late reporting. This is in contrast to the T+1 only reporting obligation in other reporting jurisdictions around the globe.
📝 Side note . . . EMIR brings its own challenges, dual-sided reporting obligations require additional coordination with the other counterparty to ensure that matching UPIs are reported.
Learning the UPI language
With connectivity in place, reporting parties will need to generate UPI attributes in the required input format to create or retrieve UPIs for reporting. Creating some attributes will require new internal product data to be processed. In addition to generating UPI attributes and connecting to retrieve or create UPIs, counterparties must ensure that UPI data is consistent with other product data elements reported independently. This has proved challenging in reference to the derivative ISIN since its introduction.
“Creating a UPI for a reporting party is a major lift, even with the current market solutions.” says Jonathan Thursby, CEO at KOR “At KOR, our structure was built with UPI in mind. Counterparties reporting with KOR today are set up to be compliant with the new UPI requirements.”
📝 Another EMIR side note . . . EMIR will require a range of product data contained in the UPI to be reported independently, such as contract type and CFI code. For the CFTC, most product data elements that are captured by the UPI, are not duplicated in the Technical Specifications. To complicate things further, EMIR continues to require the ISIN for OTC derivatives traded on UK/EU venues (ToTV), which will result in some trades with multi-jurisdictional obligations being reported with ISIN for EMIR and UPI for other regulations.
UPI at KOR
At KOR, we facilitate the transition to UPI with a forward-looking approach. Counterparties reporting with KOR already use the UPI product attributes to report in production today. Attributes currently reported directly correspond to the values required to create or retrieve the UPI. Unlike some other SDRs, KOR plans to allow, but not require, users to report and upgrade trades with UPIs well in advance of the compliance date so that KOR Clients will not have to migrate to submitting the UPI and upgrading all open swaps on the same weekend.
Taking it a step further, KOR offers a pre-validation workflow to get feedback on submissions – including the product fields – in advance to create the opportunity to correct prior to being rejected by the SDR. In transitioning to UPI for product identification, the additional control plays a vital role in compliance visibility and minimizing time spent rewinding the trade reporting flow during incident investigation.
👉 Did you know? We’re honored to be a member of the UPI Committee where we’re able to feed back our real-world insights. Much more to come from us on UPI, though be sure we’re on it!
Looking beyond the CFTC’s UPI implementation
For EMIR, ASIC, MAS, and JFSA reporting updates, the UPI has come into scope as part of each of their wide-ranging reporting updates. These regulations allow up to 6 months for reporting parties to upgrade open trades to new standards, including the UPI. Despite this period, any lifecycle events on open trades and any new trades must be reported in line with the new standards from day one, so the ability to create UPIs on any open trades may still be required immediately following the compliance date.
