Message Templates

Valuation Updates (VALU) - Best Practice

Status: Best Practice Finalised, Last Updated: 28/09/2021

Question:
What should be covered in a Valuation Update (VALU) and from which date should new transactions be captured within daily updates?

Best Practice:
Valuation Updates (VALU) should be reported daily by participants and each daily report should be submitted no later than the following business day. This report should reflect the market valuation used for collateral management purposes.

New transactions should be captured within daily valuation updates starting from the trade date of the event +1. (SFTR-447)

Modifications (MODI) and Corrections (CORR) - Full or Partial Datasets

Status: Best Practice Finalised, Last Updated: 26/04/2021

Question:
Where an amendment is made to a one or more fields using a MODI or CORR template, should all the data fields normally reported in the NEWT message be repeated or just those that have changed?

Best Practice:
All eligible, required, data fields should be populated when amending an SFT using a MODI or CORR template message, effectively re-stating all fields of the transactions.

See Guidelines Reporting under Articles 4 and 12 SFTR 06 January 2020 ESMA70-151-2838

74. In the case of amendments pertaining to the SFTs, both lifecycle events and corrections, counterparties should submit messages containing all applicable fields, including those which have not altered, still allowing for separate reporting between loan and collateral data. (SFTR-295)

Modification (MODI) - Triggers

Status: Best Practice Finalised, Last Updated: 26/04/2021

Question:
Is the general understanding that a change to any fields, regardless of whether it is transactional or reference data, would result in a MODI submission; or have any distinctions been made as to what will and will not trigger a report?

Best Practice:
Where any field required for a MODI template message, which has a dynamic data-point, changes; then users have an obligation to report this change. For example, if Field 2.09 (Master Agreement Type) changed from OSLA to GMSLA.

Given that the market value of an SFT will change on a daily basis, participants should be restating this by way of MODI every day when open, therefore any changes to reference data will also be consumed through this process and also updated accordingly. (SFTR-262)

Error (EROR) - Transactions Cancelled on Day of Booking

Status: Best Practice Finalised, Last Updated: 26/04/2021

Question:
Is there any definition around reporting of transactions that are subsequently cancelled same day, vs a transaction that was legitimately booked, but terminated later that day?

It is our understanding that the former would not be reported at end-of-day, whereas a NEWT and an ETRM would be reported for the latter scenario.

Is the common understanding that all instances of transactions should be reported, regardless of the motivation for terminating the trade? Or indeed the opposite, transactions are not reported if they are terminated same-day?

Best Practice:
In all cases, pending loans when cancelled should be reported as EROR messages; regardless of reason. It was opined that there are only two legitimate reasons to cancel a loan; genuine, bilateral, business reasons and unilateral operational reasons (erroneous trade entry, for example).

To send a different template for each would mean that vendors or proprietary system owners would have to build in additional logic, where none currently exists, to allow users to apply a reason as to why they were cancelling loans. The application of this selection process is dependent on human intervention and would almost certainly contain user error on numerous occasions.

The EROR template message should be used to report all loan cancellations and ISLA have given this feedback to ESMA in the formal Response Form to the Consultation Paper under Articles 4 and 12 SFTR: May 2020 and we have received no push-back to date. An ETRM will only be sent for the full and/or final partial return of a settled open-term loan.

See ESMA Guidelines Reporting under Articles 4 and 12 SFTR 06 January 2020 ESMA70-151-2838

60. Table 46 illustrates the population of reporting fields in case of a cancellation of a wrongly submitted entire report where the SFT never came into existence or was not subject to SFT reporting requirements, but which was reported to a TR by mistake. The level, i.e. transaction or position, at which the SFT is reported is irrelevant for this use case, as Field 2.99 (Level) is not applicable for this action type. (SFTR-243)