SFTR validation rules and XML schemas changes: behind the scenes…

On 29 July 2021, one year after the Securities Financing Transactions Regulation (SFTR) went live, ESMA has published updated SFTR validation rules and XML reporting schemas.

ESMA has indicated that the validation rules will apply from 31 January 2022 along with most of the XML schema changes coming into force at the same time [1]. The schema changes were discussed in the ISO 20022 working groups that ran from mid-May to end of June 2021[2]. A further release is planned for 30 April 2022 covering reconciliation and rejection messages. Testing was initially targeted to start in second half of October 2021, however UAT is likely to start only early December as per TR implementation roadmap.

The proposals [3] aim to:

• achieve consistency between the validation rules, the ISO 20022 base messages and ESMA SFTR guidelines.
• implement improvements based on market feedbacks.
• align the technical message components of the base messages with EMIR base messages.
• introduce a new message for position reports sent by the TRs to supervisory authorities under ESMA’s new guidelines for the calculation of aggregated position in SFTs that were published on 25 May 2021. This build will only impact TRs.

The clock is ticking, in five months new rules will be in place while within the same timeframe, a lot of participants will be busy dealing with their data porting from Unavista to DTCC and Regis.  Trade repositories, data providers will be busy supporting this switch. TRs implementation approach will be key: most of the technical burden will lie with them, so their direct feedback and testing modalities will be critical, some changes are directly dependent on TR testing timeframe and the way they implement ESMA release.

In this article, we highlight some of the main challenges of this fifth SFTR validation rules and schemas release.

‘Behind the scenes’…

Some SFTR changes are invisible to end users with no obvious impact from a pure business perspective but create additional works.

The 31 changes to the SFTR validation rules are not overly complex. However, they cannot be considered in isolation from the XML schemas changes.

ISO 20022 XML schema changes could represent a fair amount of technical alignment and testing works: TRs, data-providers and reporting firms will have to align their builds and synchronise their testing. In addition, the lack of backward compatibility with no option to submit former XML schemas after the switch to the new schema version could add pressure as they limit some testing. replay functionalities and backdated remediation.

Below are two examples of changes not so visible to end users.

• Changing the name of counterparty data element in the XML schema (‘CtrPty’ instead of ‘CtrPtyData’) or adding an additional element in the party identification (‘Lgl’) will affect 12 different counterparty fields within the Transaction Report message alone. However, this change will allow to better align the technical message components of these SFTR messages with the CPMI-IOSCO Critical Data Elements and with EMIR messages.

• Another change is to align the XML schema and SFTR regulation for ‘Spread’ field, a number of basis points to be added or subtracted to floating rates for repos, securities lending, margin lending. Spread is limited to five numerical characters in the Level 2 text (Implementing Technical Standard or ITS). The ESMA XML schemas have been amended to align with this, the value has now a format (5.0) instead of (18,17) previously. That single change in spread format field will result in nine different XML XPaths amendments in the ISO schema.

It should be noted that in practice, spreads can be fractions of a basis point, as we have observed in our support to our clients. It will be key to populate spread-related fields accurately: reporting 12.5 bp won’t be possible, firms will have to send either 12 or 13 with no decimal value [4].

Main impacts…

The more visible amendments to the validation rules and the related schemas changes concern:

• Collateral data
• Counterparty-related data
• Trade characteristics (lending fee, rates, maturity date…)

1) The ‘Market value’ tag in the ISO 20022 schema now allows for negative signage for all action types and across all trade types. The main consequence of that is on Collateral market value (field 2.88) which can be negative so counterparties ‘report the amount of securities and the market value of those with a sign that reflects the state of each security from their own perspective’ as per ESMA guidelines. This means that for non-cash collateralized SFTs (repos, buy/sell-backs, margin lending, securities lending against non-cash collateral), the seller of collateral should provide a negative sign when reporting collateral quantity/ nominal amount and collateral market value. Those fields should normally be signed consistently according to the direction of the collateral or according to the counterparty side for trade-based collateralized SFTs. However, implementation of these new rules will depend on interpretation by the TRs and how they process potential contradictions between counterparty side (field 1.9) and signage of collateral quantity of nominal amount (2.83), collateral market value (2.88) and cash collateral amount (2.76). Inconsistencies may not trigger a straightforward message rejection (‘Nack’) as the dependencies between those fields are not stated in the validation rules. However, contradictory signage will impact reconciliation.

2) ‘Type of collateral component’ (2.75) and ‘Collateral basket identifier’ (2.96) are now mandatory alternatives in all cases: this does not resolve all the challenges, especially around corrections, and it could increase reconciliation breaks and rejections in some cases.

2.a) Collateral basket identifier ‘NTAV’ (‘Not Available’) value…

With the new rules, parties are likely to increase the reporting of ‘NTAV’ as a fallback within field 2.96, but for trade based collateralized SFTs, they will have to report the security collateral details at latest one day after the trade start date.

The market previously asked for those two fields 2.75 and 2.96 to be ‘decoupled’, as they were one of the top reconciliation breaks both in the EU and UK. Those fields were made optional in new reports, so most participants followed industry recommendations for securities lending to leave 2.96 and 2.75 blank for trades collateralized on a net-exposure basis. Now it will be necessary to reverse the build to populate ‘Collateral basket identifier’ as ‘NTAV’ on a new report when the details of the basket are not known at the point of trade, or else report field 2.75 ‘Type of collateral component’ with all the relevant subsequent details (ISIN, Security quality, Security type, classification of financial instrument code, etc).

The message will be rejected ‘If the Event date (field 2.3) is later than the Value date (field 2.13) +1. This does not apply to net collateral as there is no value date.

2.b) Challenges around corrections…

-When a firm needs to correct a field on the loan side, the validation rules make it mandatory to send a correction within the one day after value date window, populating field 2.75 ‘Type of collateral component’ with all relevant security-related details …

-The general information note “Report with action type “CORR” can contain only loan data (1.11-1.18, 2.1-2.73, 2.97-2.99) or only collateral data (1.1-1.3, 1.7, 1.8, 1.10, 1.11, 1.14, 1.18, 2.1, 2.3, 2.4, 2.9-2.11, 2.73-2.96, 2.98) or both, and should not be rejected as long as all requirements, as specified in the validation rules for the applicable fields, are fulfilled” may require further clarification as it contradicts the validation rules for corrections. In the scenario above, it can be interpreted that it is not mandatory to populate field 2.75 on a correction of loan data, that would be more convenient but requires further clarification versus the validation rules.

-It is still not possible to send a correction on net collateral SFTs (i.e., most of the securities lending trades) as the ‘Unique Trade Identifier’ (UTI) is mandatory on correction messages. Parties will have to send collateral updates (action type ‘COLU’) to work-around that limitation on corrections.

3 )‘Entity responsible for the report’ was added to all messages and the XML schema supports it. This will allow support multi-managed funds to be accurately identified (i.e. multiple asset managers executing trades on behalf of the same fund with the same counterparty and sending different collateral feeds).

However, until the ‘collateral key’ is made more granular, collateral reports will continue to over-write each other within the TR reconciliation process. The incorporation of ‘Entity responsible for the report’, ‘Triparty agent’, or ‘Agent lender’ into the collateral key for reconciliation will have to wait for future enhancements.

The inclusion of Entity responsible for the report field was also added in Error messages for margin and reuse messages with additional allowed LEI statuses (‘lapsed’ and ‘retired’). It will also allow ‘erroring’ a whole collateral re-use message at entity level.

4) The Value date of collateral becomes optional for collateral updates and corrections. This was one of the top reconciliation breaks so should be a relief for participants.

5) The rule that the LEI of the issuer ‘shall pertain to a legal entity and not a branch’ concerns collateral data for repos, buy/sell-backs, margin lending, and both loan and collateral data for securities lending. There could have been potentially more rejections if the LEI of the issuer is incorrectly identified as a branch: GLEIF golden LEI source has a flag to determine the category of the entity. However, although entities are encouraged to register the parent LEI when they reach out to their Local Operating Units [5] to register to GLEIF, that field seems optional. So further clarification as to what an empty field would mean would be helpful.

The LEI of a security issuer could be in the UK, hence optional until 10 October 2022 at the latest from an EU perspective.

However, worth noting that the last MIFIR Q&A states it is the LEI pertaining to the specific issuer of the financial instrument (including local branches) and not the LEI of the ultimate parent of the issuer that should be provided for MIFIR reference data. For SFTR, the LEI has to be the ultimate parent one and not the local branch. This appear to miss one of the objectives of the exercise, to align the technical components of the different schema messages?

6) The changes in the rules related to ‘Lending fee’ (field 2.67) and ’Fixed / Floating rebate rates’ (fields 2.58 & 2.59) in securities lending aim to better align with Financial Stability Board (FSB) guidance. Going forward, for rebates, only fields related to ‘rebate rates’ should be populated [6]. For cash pool and non-cash lending, only ‘lending fee’ will be populated and not rebate rate fields.

7) ‘Method used to provide collateral’ and ‘General collateral indicator’ will be mandatory if field 2.73 is true (i.e., for net collateralized trades). Previously, those fields were usually only populated in subsequent net collateral update messages and not in new reports, which caused reconciliation breaks. A side effect of those new validation rules is in cash pool securities lending, for which firms will have to populate default values unrelated to cash collateral.

9) Unique Trade Identifiers (UTI) become mandatory on collateral updates of margin loans.

10) Commodities were removed from the collateral data in the securities lending template: it will only apply to the loan side of commodity lending / borrowing. This alignment seems logical and does not have a massive impact given the low volume in this asset class.

11) ‘Nature’ and ‘sector of the reporting counterparty’ are now be mandatory in all message types

On the FCA side…

It looks unlikely FCA would publish its own set of XML schemas. Validation rules changes are likely to be analyzed on a case-by-case basis.

Industry associations have urged that the validation rule changes should be broadly in line with ESMA and with the same go-live date (31 January 2022). FCA release statement could be expected with their plans within the next few weeks as per ISLA feedback.

Changing the ISO 20022 XML schemas could have allowed for more flexibility. However, data harmonization seems to have been held back by difficulties in changing the regulatory texts. Implementation challenges will be on the testing side with required synchronization across participants while TR and vendor roadmap will be quite busy with some changes less visible to firms. Those changes could be considered moves towards further improvements for future releases or an SFTR ‘Refit’. The industry is currently analyzing the changes, the market will probably opine on the impacts around second week of September.

For more information, please contact us here.

[1] 31 January 2022 release: transactions, margin and reuse (ingestion and trade activity reports), trade state report – 30 April 2022 release: reconciliation reports schemas, missing collateral report, TR rejection messages.

[2] The XML schema messages published by ESMA are ‘derived’ from the ISO 20022 base XML messages. They are not subject to the evaluation and registration at the ISO committee level: ESMA policy questions and/or validation rules changes were not part of the discussions of the ISO 20022 SFTR working groups.

[3] From mid-May to end of June 2021, a series of meetings were organized by the SWIFT ISO 20022 committee to discuss circa 27 ISO schema changes initially proposed across all reports: nearly 50 different feedbacks were walked through in detail with ESMA, Trade Repositories, Trade associations and industry participants.

[4] ICMA recommendation: For spreads which are fractions of a basis point, the fractional part should be rounded up to the next basis point if the fraction is at least half of a basis point (0.5 bp) but should otherwise be rounded down to zero

[5] Reporting parties are required to report the jurisdiction (legal domicile) of the issuer of each security being given as collateral using the relevant ISO country. If the issuer is a subsidiary of another legal entity, field 2.92 should be the jurisdiction of the ultimate parent

[6] Cash rebate SBL : field 2.73 is populated with “false” and field 2.75 is populated with ‘CASH’, Cash pool SBL : field 2.73 is populated with True and 2.75 is populated with CASH, Non-cash SBL: field 2.75 is populated with SECU

[7] https://www.fca.org.uk/news/speeches/forward-look-regulation-uks-wholesale-financial-markets

About the author: Que-Phuong Dufournet-Tran

Que-Phuong is a Senior Regulatory Affairs Director in Trading Services & Analytics at IHS Markit, leading regulatory topics in relation with regulators and industry associations based in Paris, France. She is specialized in data management and previously worked in regulatory projects implementation with several financial institutions in Paris, Hong-Kong and London on SFTR, EMIR, MIFID, MAR. She is a member of the European Commission European financial data space expert group , the consultative group to the ESMA Secondary Markets Standing Committee and the ISO 20022 Derivatives SubSEG.