Emon Tabrizi on SFTR

Data relating to SFTR can have a long way to travel before reaching its end destination. Data’s journey can start at Clearing House/Trading Venues/Internal Front office systems, before making its way to internal client data transformation systems (of which there may be multiple). Along the way it picks up static data before eventually finding its way to vendors whereby it faces the hurdle of strict data validation checks against specific vendor, trade repository and regulatory defined data schemas. The final stop on this journey is of course the Trade Repository where multiple reports are submitted and further reconciled. The errors for phase 1 participants can be seen at two of these stages and across multiple report types:

1. Vendor stage.

Errors appearing here are picked up from the inbound files sent from participants and are identified by the helpful exercises of UAT and bilateral testing. These errors are typically sub-divided according to the critically of the error. The most common critical errors tend to be:

Security related info

Whether it be ISIN, SEDOL or CUSIP, a security’s unique identifier is required in order to identify subsequent required fields relating to said security. If these are not readily available internally or externally (as is often the case with collateral baskets where data may be triparty inherited), many subsequent fields relating to the characteristics of that security fail. To make things more complicated these fields are often enriched by the vendor, adding an additional dependency.

Price related fields

There are many sub-components when it comes to price calculations/submissions. A price can be in different formats (depending on whether the instrument is equity, fixed income or commodity), haircuts may be applied, the price may be dirty or clean and the list goes on. With all these permutations and formatting necessities it can be easy to see why so many errors arise here.

Unique Transaction Identifier (UTI)

UTI waterfall logic based on who is set up as the provider of the UTI.

contractual (master) agreements

Data relating to underlying contractual (master) agreements or bespoke counterparty terms whereby the data is hard to source. These include agreement IDs, minimum notice periods or specific settlement provisions that are in place.

Margin Loan and Collateral Reuse aggregated position reports

Multiple errors arise due to the nature of submitting these reports at an aggregated position level. Various data points are squeezed onto 1 line, separated by ‘pipes’ ( | ), and must correlate in a specific order. With currencies, interest benchmarks (many of which are non-standard), short market values and outstanding margin loan values having to be perfectly aligned on the margin report it’s easy to see how vendors reject this data due to null values. The same case is seen with collateral reuse; the list of ISINs, and the Collateral Component Type fields must align. Internal testers must be scrupulous in ensuring the data matches that of client accounts, of which there may be many at sub-level.

Conditional logic when it comes to both trade based specific collateral and general collateral based on net exposure

Most collateral data related fields are specifically conditional on 1 or 2 fields that determine what type of collateral they are and whether they have net exposure. This conditionality creates a level of complexity, so that when the logic is not correctly applied for one of these 2 fields, at the intermediate vendor level this can result in having incorrect values in all its dependent fields.

2. Reporting stage

These are errors sent back from the Trade Repositories (known more widely as Acknowledges (“Acks”) and Non-Acknowledgements (“Nacks”). These tend to be related to:

Incorrect action types

Incorrect action types being submitted when married against various counterparty and UTI variation logic.  Action type errors are exacerbated by refreshing TR environments that lead to the clearing down of existing historic data. This can cause post trade events to be rejected due to their Action Type (MODI) being recognised by the system as incorrect – because of the clear-down, the system expects Action Type to be New Trade (NEWT) and hence it incorrectly marks any other Action Type as an error.

Invalid XMLS not complying with scheme validation rules

This is typically invalid content caused by conditionality. That is, if one field exists, another should not and vice versa .  Examples, aligned with the critical errors at inbound validation/vendor stage, are typically around price, monetary values and quantity.

Field parameter errors

Here we see errors pertaining to fields that must be less than or equal to others – these errors typically relate to date and time related fields which are aggravated by lifecycle events.

The myriad of invalid and null values forming these common types or error messages seen in end to end testing must be caveated by the usual testing challenges faced by many and may not necessarily reflect on go live matching/exception rates. Typical troubleshooting includes delays between deploying UAT development to production, environmental connectivity issues, and conflicting release schedules for the aforementioned routes on the data journey.  That said, prior and continued ambiguity in terms of optional vs mandatory SFTR fields and general requirements have caused the need for extended testing and allow more room for error. With more non-financial participants soon to face the  challenge of testing, and with the phased approach of reconcilable fields, it is easy to see how pairing and matching rates may be lower than expected – hence the  importance of key exception management software and stringent operational controls to remediate post Day 1.

Share this:

Share on linkedin
Share on twitter
Share on facebook

Related

It’s an attitude.

Have you got what it takes to join the JDX team?

Discover more.