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 . The schema changes were discussed in the ISO 20022 working groups that ran from mid-May to end of June 2021. 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  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 .
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 does not appear feasible to submit corrections of only loan data or only collateral data independently as suggested by the note above: the validation rules require both loan and collateral fields within a correction message.
To allow more flexibility within the the correction reporting template, and limit to loan data report where only loan data were corrected, field 2.75 should be made optional or potentially some agreed default value within field 2.78 (Identification of a security number ‘ISIN ‘used as collateral) could be used to avoid reporting complex collateral data unnecessarily. Such a scenario already occurred where ESMA proposed to use a default ISIN such as EU000A1G0EB6 (European Financial Stability Facility) to accommodate the template limitation- (cf. ESMA SFTR Q&A question 5), for the reporting of zero collateral margin lending.
-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  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 . 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.
For modifications and corrections, this field cannot be modified if the event date is earlier than one working day preceding the day of reporting, placing additional pressure on participants to identify, remediate and report any incorrect submission or failed returns within a day after the maturity date.
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.