SFTR Reporting - Proven Solutions from Message Automation

Products


Solutions

Affirmation & Platform Connectivity

Clearing Connectivity

Inbound Clearing Reports


Collateral Messaging

Internal Trade Monitoring

Post Trade Control

for Derivatives


Control and harmonisation in action

HomeSolutionsProductsCase StudiesNews & EventsAbout UsContact
Collateral MessagingInbound Clearing ReportsClearing ConnectivityAffirmation & Platform ConnectivityInternal Trade MonitoringPost Trade Control

Solutions


Post Trade Control

Affirmation & Platform Connectivity

Clearing Connectivity

House Clearing/Broker Clearing

Client Clearing

Inbound Clearing Reports

Trade & Transaction Reporting

Jurisdictions (Dodd-Frank, EMIR, Asian, Canadian, etc.)

MiFID II Reporting

UpUpcoming Changes- SFTR/

DF SEC/EMIR revision

SFTR Reporting

Getting Value from Trade & Transaction Reporting Solutions

Product Identifiers

Position Verification

Collateral Messaging

Internal Trade Monitoring

Product Taxonomy


Have a Question?

To request information, a call back or a complimentary consultation with one of

our regulatory experts Click here



Quick Links


Solution OverviewMKT_3098_17_SFTR_Brochure.pdf


SFTR Reporting

The challenges around Article 4

Background

The Securities Financing Transactions Regulation represents a significant

change to the industry and the reporting obligation is expected to be

with us in Q2 2019, so focus is required by all market participants

early in 2018 if not already underway.

SFTR is part of the EU’s response to the financial crisis and reflects

Policy recommendations made by the Financial Stability Board (FSB)

as part of its examination of shadow banking. These recommendations

are outlined in the FSBs “Policy Framework addressing Shadow Banking

Risks in Securities Lending and Repos” published in August 2013.

ESMA has used the FSB recommendations as the foundation for SFTR

whilst following the rules and processes already contained within EMIR

for consistency.

Main Features of the New Regulation

The main features of reporting under SFTR are as follows:

However, as explained earlier, SFTs are not homogenous. Consequently, the lowest level of the waterfall differs depending on the SFT i.e. Securities lending will have the collateral provider generating the UTI, whilst the collateral taker would provide the UTI for a repo or buy/sell back.

Observations

It is clear that to comply with the new regulation, many firms will need to change their existing processes – SFTR is not just a reporting requirement from existing data.

Challenges are likely to include:

In all cases, we believe Message Automation is in a position to assist market participants

A truly STRATEGIC solution to Trade and Transaction Reporting providing Commercial and Operational Independence, Control and Transparency

Message Automation (MA) provides a proven technology solution that facilitates end-to-end trade and transaction reporting between multiple source systems and destinations, in both real time and batch. The solution covers reporting to a range of jurisdictions including Dodd Frank – CFTC, EMIR, MiFID I and II, Canadian, Swiss and key Asian jurisdictions from a single data layer, viewed through a user-configurable dashboard.

This range of coverage clearly sets us apart from our competitors but that is only one reason why our clients choose us

Independence

We are completely independent of all trade repositories, ARMs, APAs, and other market participants and we offer our clients the same independence. Our platform provides a single abstraction layer between multiple internal systems and multiple external destinations. This approach prevents our clients being inextricably linked to a single external provider, with the associated potential concerns of commercial inflexibility and unsatisfactory operational performance. With MA it is possible to use more than one destination for each jurisdiction concurrently, perhaps per asset class or purpose, and destinations can be changed at any time with minimal disruption.

Harmonising Fragmented Data

With 153 reportable fields, it is unlikely that most firms will have all the required data for SFTR in their source systems. Obtaining data such as cleared initial margin posted, variation margin posted, excess collateral, and making sure these numbers relate exclusively to SFT’s will be a time consuming task. Within our data model MA already harmonises margin and collateral data from over 50 CCPs globally. This is one of the many examples where MA can be used to help enrich the data to be sent to the trade repositories or a firm’s SFTR solution.

Operational Visibility

The operational overhead of understanding why trades are reportable or not reportable, dealing with responses from the TR, managing and categorising exceptions, and then ensuring completeness and accuracy of reporting is often overlooked until a firm has the reporting obligation and the additional workload. Our experience in multi-jurisdictional reporting has enabled us to design our system to cater for the operational requirements of reporting and proving the accuracy of the numbers being reported to both internal stakeholders and regulators.

Control

Using the proven MA software our clients gather all relevant data in one place before deciding ‘what should be sent where’ under configurable fully audited rules. Only data that needs to leave your organisation is released and the dashboard provides a full history including powerful data lineage functionality. This operational oversight of all of your reporting is of critical importance in staying compliant within the SFTR regulations, particularly when a number of third parties are offering reporting services for part of your trading book.


For any SFTR enquiries please contact:

- Dean.Bruyns@Broadridge.com

- Michael.Bondswell@Broadridge.com

Solution Overview

Please download our Solution Overview:

SFTR Reporting MKT_3098_17_SFTR_Brochure.pdf

Dashboard Screenshots – Data Lineage and Traceability

Full Audit Trail - From Source to TR Response

Traceability - Decision Rules

Traceability - Data Lineage