Transaction Reporting under SFTR - · PDF fileTransaction Reporting under SFTR ISLA Meeting...

Transaction Reporting under SFTR

ISLA Meeting – 10 March 2016

© 2016 Pirum Systems Limited, all rights reserved

What is SFTR?

Securities Financing Transactions Regulation (SFTR)

• The council of the EU formally adopted SFTR on 16 Nov 2015

• It provides a package of legislation aiming at improving transparency in the

SFTs market in the EU – Stock lending, Repo & Margin Lending

• A key requirement of SFTR is that counterparties to an SFT are required to

report details of the conclusion, modification and termination of all SFTs to

an EU registered trade repository, within one working day

• Reporting is required by all EU entities involved in any SFT as well as any EU

based branch of non-EU entities

• Two-sided reporting is required – The reported transaction must include a

unique transaction identifier (UTI) to enable the regulators to pair and de-

duplicate the transaction reports

• SFTR reporting standards will be based on EMIR where appropriate

• Live reporting is due to commence in early 2018

• Health warning: This presentation has NOT been put together by a lawyer!


What has to be reported?

Component Example Data Fields (not a complete list)

Event Type New / Modify / Cancel / Close

Transaction

Attributes

UTI, Trans.Type, Trade Date, Value Date, Term date, Principal / Agency Ind,

Special Terms: Evergreen, Extendible etc.

Parties LEI Codes: Borrower, Lender (Beneficial Owner), Reporting Party

Assets Lent Cash Value + Ccy, ISIN + Quantity / Nominal, Repo / Fee / Rebate Rate,

Fixed / Floating rates, Benchmark Rate + Spread / Cap / Floor

Collateral Cash Value + Ccy, ISIN + Quantity / Nominal, Haircut, Collateral Value,

Tri-party Agent Id

NB: Above is based on Level 1 text – More detail to come in Level 2 text

2. Collateral re-use: a) All collateral eligible for re-use b) Actual re-use

3. Cash collateral re-investment information

1. Stock loans / repos / buy-sell backs / margin lending + associated collateral:


Legal Entity Identifier (LEI)

What is a Legal Entity Identifier (LEI)?

• A unique standardised identifier which identifies every legal entity or structure,

in any jurisdiction, that is party to a financial transaction.

• An LEI code for a legal entity is similar to an ISIN code for a security.

• Use of LEIs to identify parties to each transaction is mandated for both

derivatives reporting under EMIR and SFT reporting under SFTR.

• LEIs are issued by Local Operating Units (LOUs). In the UK, LEIs are issued

by the LSE. The legal entity itself has to apply for its own LEI code.

• A consolidated database of all LEIs issued globally is freely available:

See https://www.gleif.org/en/lei-data/gleif-concatenated-file/lei-download#

• The LEI database includes for each legal entity:

• LEI code, Name, Address, Country / Region, Legal Form, Status

• Most securities lending counterparties will already have an LEI providing

they also participate in European derivatives transactions.

https://www.gleif.org/en/lei-data/gleif-concatenated-file/lei-download


Example LEI:Goldman Sachs International


Example LEI:CalPERS


Example LEI:The Bank of New York Mellon


System changes to support use of LEI codes

• Broker to Broker / Disclosed Lending

• Market participants need to record (or lookup) both parties’ LEI codes

• LEIs should be included on contract compare

• Undisclosed Agency Lending

• Lender should record the Borrower’s LEI

• Borrower should record the Agent Lender’s LEI

• Borrower and Agent Lender LEIs should be included on contract compare

• Lender should disclose the Beneficial Owner LEIs through ALD

• ALD

• Currently ALD uses DTCC Pseudo Tax IDs to identify beneficial owners

• ALD needs to change to include LEIs for beneficial owners


Unique Transaction Identifier (UTI)

What is a UTI?

• Unique Transaction Identifier – 52 characters (generator prefix + unique id)

• Used to pair transactions as part of two-sided reporting

• The identifier should be assigned in accordance with agreed industry

standard rules and used for reports throughout the lifetime of the transaction

• Inter-trade repository reconciliation uses UTI plus borrower / lender LEIs

• A street trade MUST be split as required so that a transaction with a UTI has

ONE Borrower and ONE Lender (i.e. Ben. owner, not Agent Lender)

Who creates the UTI?

• To be agreed by industry bodies. In the derivatives market, the UTI is

created as early as possible, preferably by centralised market infrastructure:

• Trading Platform, Compare Platform, CCP, Prime Broker


What does a UTI look like?

• Consists of prefix + suffix, up to 52 characters long in total:

• Up to 20 characters are the UTI generator’s unique prefix

• Up to 32 characters for the generator’s unique transaction id (suffix)

• Does NOT need to be padded to make it 52 characters long

• An example UTI:

• EO1PIRMA03FC2B59146

• This follows ESMA’s UTI generation guideline in their EMIR Q&A:• E01 is first part of the prefix (ESMA standard)

• PIRM is the Market Identification Code (MIC) for Pirum, used as part of the prefix

• A03FC2B59146 is Pirum’s unique identifier for a transaction, used as the suffix

• See https://www.esma.europa.eu/sites/default/files/library/2015/11/2015-1485_qa_xiv_on_emir_implementation_october_2015.pdf

for EMIR Q&A (TR Question 18 on page 75)

https://www.esma.europa.eu/sites/default/files/library/2015/11/2015-1485_qa_xiv_on_emir_implementation_october_2015.pdf


Who could generate the UTI?

Transaction Type Who could generate the UTI?

Stock Loan - Broker : Broker / Disclosed Lender : Broker

(Must be only ONE borrower and ONE lender on the trade)

Trading Platform or

Compare Platform

Stock Loan – Undisclosed Agent Lender : Broker

(Multiple Lenders –1 UTI per beneficial owner / trade)

ALD Hub or

Compare Platform (using ALD file)

Undisclosed Agency Lending: Change of beneficial owner

(Needs new UTI each time there is a new beneficial owner)

ALD Hub or

Compare Platform (using ALD file)

CCP Stock Loan – Lender : CCP, CCP : Borrower

(2 UTIs – One for each leg in and out of the CCP)

CCP (upon novation)

or Compare Platform

Loan consolidation, Re-bookings, Loan matching changes,

New loans resulting from corporate actions

Compare Platform

Loan returns – Very unlikely to need a separate UTI for these N/A


Compare

Platform

UTI Data FlowDisclosed Lender Trade

Disclosed Lender Trade (no ALD)

Lender

Trade

Repository

Compare Feed (inc UTIs) Compare Feed (inc UTIs)Borrower

1. UTI Feed1. UTI Feed

2. Transaction Reporting2. Transaction Reporting

A. Transaction ReportingA. Transaction Reporting

• Trading platform allocates UTIs to trades executed on platform

• Compare platform allocates UTIs to all trades without a pre-existing UTI

• Clients could either report themselves (using platform UTI feed)

OR engage the platform to do their reporting (no need for a UTI feed)


Compare

Platform

UTI Data FlowAgency Lending Trade

ALD Trade – Compare platform allocates the UTI

Lender

Trade

Repository

Compare Feed Compare FeedBorrower

1. UTI Feed1. UTI Feed

2. Transaction Reporting2. Transaction Reporting

A. Transaction ReportingA. Transaction Reporting

• The compare platform would merge the ALD file with contract compare so

that the UTIs are allocated at beneficial owner level per loan

• Changes to beneficial owners via ALD result in new UTIs being allocated

for new lenders and pre-existing UTIs closed as required

• Clients could either report themselves (using platform UTI feed)

OR engage the platform to do their reporting (no need for a UTI feed)

ALD FileALD File


Industry Decisions Needed on UTIs…

• Who will issue UTIs for broker : broker / disclosed lender trades?

• Trading platforms should issue UTIs for trades on platform

• Compare platforms should issue UTIs for all trades without an existing UTI

• What about trades which are off platform and not on contract compare?

• Who issues UTIs for undisclosed lending trades?

• Could in theory be ALD hub (DTCC) or compare platform

• ALD data should be merged with compare data before reporting, so it would

be simpler and more accurate for this to be done by the compare platforms

• Who issues UTIs for CCP trades?

• Following the derivatives model, UTIs would typically be issued by the CCP

• Could also be issued by the compare platform / flow provider into the CCP


SFTR Collateral Reporting

• Stock Loan collateral is likely to be reported at a position / ISIN level

• Under EMIR, collateral is reported with a portfolio code to link trades to

collateral. It isn’t clear yet whether linking will be required under SFTR

• Pooled collateral held for multiple beneficiaries:

• Collateral value may need to be split by beneficial owner

• If reporting by security, this could cause issues with fractional shares

• Collateral Re-use:

• Need to report whether collateral may be re-used or not

• Actual re-use also has to be reported – Potential identification issues

• Cash re-investment:

• Lenders must report the details of cash collateral re-investment


What do we need in regard to ALD?

• Changes we need to existing ALD process:

• DTCC ALD Hub to be modified to accept / use LEI codes in place of

pseudo DTCC tax identifiers

• Modifications need to cover all messages where DTCC tax id is

currently used – i.e. set-up messages and daily messages

• Lenders to modify their systems to hold LEI codes for beneficial

owners and to use these codes in ALD messaging

• Borrowers to modify their systems to receive LEI codes and use these

in place of pseudo DTCC tax ids

• We need to start planning this now! Alternative is that everyone internally

maps pseudo DTCC tax identifiers to LEI codes for reporting purposes

• LEIs will likely be needed for US ALD too? US will need to report to FSB.

• How do we engage DTCC and kick start the change process?


What’s else is needed for SFTR?

1. Market participants to upgrade existing SBL / Repo systems to allow:

• LEI codes to be assigned to all counterparties

• UTI references to be stored against each trade

• Special terms (e.g. Evergreen) to be stored against each transaction

2. Market infrastructure providers to assign UTIs and provide them in feeds:

• Trading platforms, Compare platforms, CCPs

3. Market participants to change incoming data feeds to populate UTI field and

outgoing data feeds to compare vendors to include LEI, UTI & special terms

4. Market participants to research and populate the new LEI data field for all

parties to SL / Repo trades

5. Agent lenders upgrade data feeds into ALD hubs to include LEI codes

6. Vendors / Market participants to implement reporting to trade repositories


And finally…

• Reporting is likely to include some data fields which do not currently exist in

many market participant’s systems – e.g. first callable date on evergreen trades

• In derivatives, they also have a UPI (Unique Product Identifier) which we could

usefully use together with a defined SFT taxonomy

• Some final thoughts for members to ponder…

• Have you budgeted / planned for this work yet?

• Has your SFTR reporting analysis work started yet?

• Are you talking to your IT team / tech vendors about SFTR?

• Is your trade, collateral and ALD data in a fit and clean state,

ready to be shown to regulators on a daily basis?

• What could be done now to help smooth SFTR implementation?

(Example: Add LEI codes for counterparties to contract compare)

Transaction Reporting under SFTR - · PDF fileTransaction Reporting under SFTR ISLA Meeting...

Documents

Transcript of Transaction Reporting under SFTR - · PDF fileTransaction Reporting under SFTR ISLA Meeting...