Top five changes in the final CFTC reporting Technical Specification
Last month the CFTC published what they and the industry are hoping is the final version of the Technical Specification for Parts 43 & 45 reporting under the ReWrite of the CFTC swap data reporting rules. Unless there is a delay (as is much rumoured and debated) this means it’s now only seven months until the May 2022 compliance date. Factor in Thanksgiving and the holiday season and that’s really not a long time assuming this really is the final version.
At Kaizen HQ we’ve been analysing the impact and here are the five most significant changes in this latest version.
1: Multiple validation changes
I’ll dispense with the obvious one first and get the low hanging fruit out of the way. There are many, many changes throughout this version of the technical spec. See the red-line version and it’s littered with changes. These range from non-substantive wording changes, to revised definitions, to tweaks to the field-by-field validations.
It would be impossible to cover them all here so instead I’ll just point out the obvious – the sheer number of changes is one of the main aspects for firms to deal with.
2: Short-form exit messages
The final tech spec has wisely concurred with a suggestion the SDRs and the industry were pushing for and added language to support so called short-form exit messages:
Nothing in this Technical Specification should be read to prohibit an SDR from limiting the number of data elements required to be submitted, to a subset of part 43 or 45 data elements, for Action Type TERM, PRTO, and EROR. Submission of all parts 43 and 45 data elements is mandatory for all other Action Types.
This is good progress because it simply makes sense that firms don’t need to worry about ensuring every single field is correct and contains an up-to-date value when they are trying to terminate a position or remove a position that was submitted in error.
I’m reporting Swap Creation data or Swap Continuation data on an open trade so I need to ensure the data is accurate and complete. Absolutely.
I’m terminating a position that no longer exists or worst case removing something that should never have been reported and I need to ensure every single field is accurate and complete. Not so much.
The action to remove or terminate is far more important here than a full representation of the trade so limiting the fields to a short-form subset that identifies the firms involved, submitter and the trade identifiers is a common sense practical approach.
3: Event Timestamp for Collateral Valuation dates
Again the Commission deserves credit for closing a gap that the industry was pushing for. In this case there is a requirement to submit Collateral Valuations (Action Type MARU – Margin Update) but the industry was pointing out there was no method to distinguish between submitting a MARU for the current date versus a correction of an older MARU for a previous reporting date.
The CFTC revised the tech spec to facilitate this but instead of adding a new specific ‘valuation date’ field they commandeered the definition of existing field Event Timestamp, by adding:
In the case of collateral update (Action type = ‘MARU’), this is the date for which the information contained in the report is provided. Time portion should be reported as “00:00:00”.
Whilst I applaud the CFTC for addressing the gap, their choice of mechanism feels a bit of a fudge. And given the global momentum towards harmonised standards it might have been better addressed by adopting a CDE-based field better aligned to this purpose.
Apart from global harmonisation alignment there are two main problems with this solution:
- Collateral Valuation Date is not an Event as per the CFTC definition of Event.
- The field is a Timestamp and not a Date so the guidance doubles down on the messy approach by suggesting firms add 00:00:00 as the timestamp part.
At Kaizen we often advise firms not to use default timestamps as it’s just not good practice and is often not compliant. So it’s pretty frustrating to see another regulator recommending the use of a dummy timestamp to circumvent a shortcoming in the way the regulator is using the field.
4: Upgrading Event Type
As well as aligning some of the Event Type codes to better align with CDE (TRDE deposed by TRAD for example), the CFTC has thrown in two new Event Types:
CORP = Corporate event
UPDT = Upgrade
CORP is alas more geared towards a Corporate Action affecting an equity instrument rather than a company soiree with free drinks, snacks and a bit of a skive away from your desk.
UPDT is therefore more interesting – especially as it unexpectedly spells Upgrade.
Upgrade: An upgrade of an outstanding transaction performed in order to ensure its conformity with the amended reporting requirements.
So this event type allows me to UPDT my pre-ReWrite reported swap transaction in order to Upgrade it to the latest data standards. OK that now makes a bit more sense and we’ve seen similar proposals in other jurisdictions.
But other jurisdictions such as ESMA for EMIR have gone further in terms of stating the expectations around how such an UPDT to the new standards should be used and crucially the expected timeline. Firms have 180 days from the implementation of the EMIR REFIT in Europe to bring any open transactions/positions into line with the new standards.
Without such explicit guidance from the CFTC, the reporting firms will need to discuss and decide upon the best way to tackle bringing all open swaps into line with the new standards. Big bang and update everything on day one versus track them and update those not updated via a natural lifecycle event submission over time. Although when you factor in the complexities arising from the CFTC rules around moving from USI to UTI, things start to get complicated pretty quickly. I suspect the SDRs are bracing themselves for really high volumes with lots of firms submitting an UPDT for everything on day 1 in order to just get it done.
5: Removal of the ‘no translation’ language
The following clause in section 1.2.1 has been struck out:
No translations or mappings are permitted, i.e., ‘Yes’ or ‘No’ should not be mapped to ‘True’ or ‘False’.
The regulators intentions here seem fairly clear and would point towards what has often been described as the ‘dumb trade repository’ model. The Trade Repository (TR) function is to accept data, store it and make it available to the regulators. The TR should not therefore map, convert, derive, enrich or invoke any other kinds of data alchemy that obfuscates the of the data the firms submitted versus the data the regulators then see.
This no translation language has proved controversial as it had been interpreted in some quarters as meaning the SDRs should not accept FpML submissions. Given that the ISO 20022 message schema is still a long way off being ready for CFTC reporting then this led to a debate around whether the firms that currently use FpML would need to migrate to CSV as a temporary solution until such a time as ISO messaging was implemented by the CFTC.
This in turn led to louder calls for a delay to the May 2022 compliance date for the CFTC ReWrite. Especially amongst the bigger Wall Street banks that tended historically to be the main users of FpML. The CFTC striking this language out of the latest Technical Specification is therefore likely to be welcomed by some firms. However the no mapping and no transformation concept still exists in the CFTC reporting legal texts so it will be interesting to see whether any more guidance or even a No Action Relief letter follows to further clarify this one.
Bonus item: final thoughts
This is the final version of the Part 43 and 45 Technical Specification. Or is it? I have no doubt that the CFTC intends and very much hopes that this is the final draft. But in my experience these things often need tweaked and revised when real world experience collides with theoretical rules.
The CFTC deserves credit for the thoughtful, collaborative and engaging approach it has taken in moving from principles-based reporting regulations to this far more prescriptive approach. It has moved slowly, consulted with its peers and the industry, and communicated well throughout. So I am not trying to be critical here when I say that the CFTC is learning one of the problems with prescribing this level of detail. The pesky questions and problems that arise!
You sit in meeting rooms and draft, redraft and fine tune the wording until it’s as clear as it can be. Multiple teams, committees and stakeholders all agree it’s as crystal clear as it’s possible to make it. You then release it into the big bad world and it turns out everyone’s a critic. There are questions aplenty and worse still some of them have a point. It’s unclear or in some cases plain wrong.
No disrespect whatsoever to the Commission but they are learning the hard way that this prescriptive stuff is hard. This stuff is hard to do and takes a lot of time and effort to get right. Kudos to the CFTC for the collaborative approach and along with ISDA, the SDRs and the reporting firms we’ll get there. Regardless of whether this version is final or not. Now, about that delay…
- For a conversation with Alan or one of our regulatory specialists about the above topics, please contact us.
