The CFTC has just published the latest revisions of the Technical Specifications for market participants provide instructions around swaps trade reporting under the amended CFTC rules and requirements (aka, the CFTC re-write). These changes have been awhile in the making with inter-SDRs, SDRs to CFTC, and ISDA feedback loops.  KOR is happy about and supportive of the changes which bring needed improvements to the completeness and accuracy of trade reporting.  While the changes show that CFTC is pragmatic and willing to act based on SDR and market participant feedback – they also highlight how a single regulator acting alone creates further divergence from global efforts to harmonize reporting through the work of the standardized bodies that are producing outputs like Critical Data Elements (CDE) and are now under the Regulatory Oversight Committee (ROC). 

For over a year, KOR Financial has lived, studied, and built an SDR designed specifically for the CFTC reporting re-write and is working with clients to integrate the new rules into their own systems all ahead of the December 5th 2022 no-action relief expiration. 

The latest round of redlines to the technical specification impacts 14 different fields – all of which will need to be implemented by reporting parties no later than the December 5th compliance backstop. Some of the changes are more subtle while others implicate greater impact to market participants. At KOR we are tracking four as the most crucial data element changes. 

Natural Persons now in more fields: 

Permitting Natural Person Identifier (NPID) in the Counterparty1 and Clearing Member fields is a positive change that reflects the evolving scope of markets reporting under Dodd-Frank. This change supports new and innovative clearing models such as retail crypto trading where both counterparties are individuals.  Originally, only LEI was allowed in the Counterparty1 and Clearing member fields. 

KOR endorses the allowance and already supports the related workflows of NPID through KOR SDR.  Missing, however, is an Identifier Source field we wanted to see included for both Counterparty1 and Clearing Member for consistency in validation and approach with Counterparty2 which has an associated ID source field. 

Side note – an unwanted consequence of these NPID changes and a trend we’ll likely see more of is that these changes are now out of sync with CDE. 

Call amount/put amount for options:  

The original rules required both call and put amounts on options, though the field is only FX-specific in the CDE definition.  We’re happy to see that now the validations require at least one to be populated rather than both, a good pragmatic approach. 

Central Counterparty now allowed on Intent to Clear messages: 

Another welcomed efficiency gain comes from allowing optional identification of the Central Counterparty (“CCP”) on trades intended for clearing.  This allows the SDR to communicate with the CCP directly when it sees original swaps trades that must be terminated by the CCP.  The simple change allows for an additional control mechanism backing the CCP’s requirement to properly terminate cleared trades.  Without it, the industry places sole reliance on the CCP to track and send to an SDR a termination for all inbound original trades for clearing.  Unfortunately, making the CCP field for ‘intended to clear’ trades optional rather than mandatory, does not go far enough to allow SDRs to reliably assist the CCP and puts the final onus back on counterparty1 of the original swap to ensure there aren’t any outstanding ‘zombie’ trades (trades that are really dead but they don’t know it yet). 

Portfolio Codes now optional on Transaction Messages: 

The prior requirement was for portfolio code to be mandatory on every reported transaction. This was problematic in that non-SD/MSPs would have to send a portfolio code on every transaction even though they didn’t have a collateral reporting obligation. Moreover, for SEF’s and DCM’s, reporting a transaction posed a greater challenge of scrambling to obtain collateral data from clients before being able to submit a new transaction record.  The change to make portfolio code optional on transaction messages was a needed revision.  

KOR Thoughts: 

These changes were needed because without them the CFTC re-write validations would prevent valid reporting.  We don’t mind bragging that implementing regulatory change is no sweat for KOR.  While CFTC extended the timeline based on industry feedback, our SDR already has all these latest changes in place and our clients are immediately compliant with version 3.1 of the technical specification.   

Admirably, the CFTC listened to the feedback provided by market participants and SDRs and then acted sensibly.  Progress does come incrementally and that’s okay.  What needs to be emphasized now is while these and other technical specification changes make sense today, any single jurisdiction advancements (like the CFTC) that stray from CDE guidance (even under good rationales) are going to slow global harmonization goals and timelines.  For now, we will have to wait for other regulators to observe these changes and adopt them as well if we hope for some degree of global data standards harmonization.  More on this in a future post.

Parts 43 and 45 CFTC Technical Specification version 3.1 can be found here