What is SFTR?

In the light of recent trends towards shadow banking the EU announced regulation to improve oversite of this practice.

Securities Financing Transactions Regulation (SFTR) is due to go live in its first phase on 29th July 2020.  This date has already changed from the proposed initial go-live of Q2 2020 which suggests that the industry is still not ready to adopt and report on these standards.

Firms had until 29 July 2019 to submit contributions under the consultation timeline, then there will be a period where the finalised guidance notes will be used to clarify some of the outstanding points the industry is waiting for.

---

What does this mean at a message validation level?

The reporting method for SFTR is based on ISO standards, with the main body of data likely to be required in XML format, but with the possibility of JSON (and/or other) formats for additional data. Firms helping participants report may choose to take either or both of these standards which means flexibility is a key requirement.

The validation rules that are attached to this legislation contain multiple cross-field checks in the ISO standards with the need to validate/enrich the data based on the LEI of the company which is usually performed by an API call to GLEIF.

These cross-field validations cannot be defined with the ISO schema (whether it’s XML or JSON) and therefore must either be written in code or via a graphical tool.  If you were to write code to perform these checks then your BAs will not be able to easily read what has been developed resulting in a delay in testing while the BA/Developer/Tester all perform their roles independently.

---

How Transformer helps with SFTR

The Transformer GUI allows all participants in the development lifecycle to use the same tool while developing a solution.

Schema Import

Initially, Transformer will import the SFTR schema in a few clicks of a mouse so you can then easily see the structure of the report you need to create.

To further aid readability, in the Transformer GUI, the mappings are presented using business-friendly field names rather than technical field tags (though these can easily be made visible if necessary).

Cross-field validations made easy

The powerful Transformer GUI allows the user to create complex cross-field validations using drag and drop without the need for coding or scripting.

Data enrichment/validation – LEI lookups

Users can easily create external calls to either in-house or external APIs to validate or enrich the data they have.  These calls are performed without the need for coding or scripting and can be re-used in multiple Validation Rules for ease of use and maintenance.

Testing Made Easy

A range of supporting functions are provided to help the user, including a ‘Where Used’ query that identifies where any chosen field appears in the mapping, and Transformer’s ‘Test-As-You-Build’ function which allows mappings to be tested line by line with a single click.

XML v JSON

Transformer users can create outputs in XML or JSON format from any message standard, via a simple configuration property. For example, Transformer’s ISO 20022 library allows the user to create ISO 20022-based messages in either XML or JSON.  There is no need to create two separate mappings (one for XML and one for JSON) – the user can make the same mapping produce either JSON or XML with a simple click.

Deploy Anywhere

A mapping created within Transformer is deployed as an API callable from Java, .NET, Camel, a web service, an Enterprise Service Bus or almost any messaging infrastructure.