Counterparty Table

Reporting Timestamp

Status: Best Practice Finalised, Last Updated: 18/02/2022

Field 1.01 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No

Description:
Date and time of submission of the report to the trade repository.

Best Practice:
Report in the format and Coordinated Universal
Time (UTC) time format YYYY-MM-DDThh:mm:ssZ

T – is used as time designator to indicate the start of the representation of the time of day in dateTime.

Z – is used as time-zone designator, immediately (without a space) following a data element expressing the time of day in Coordinated Universal Time (UTC)

Example: 2016-06-23T09:07:21-07:00 (SFTR-1)

Report Submitting Entity

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

Field 1.02 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No

Description:
Unique code identifying the entity which submits the report. In the case where submission of the report has been delegated to a third party or to the other counterparty, a unique code identifying that entity.

Best Practice:
This field shall contain a valid LEI recognised by GLEIF. The LEI shall pertain to a legal entity and not a branch. The status of the LEI for message template "EROR" is irrespective, but for all other message templates it can be either:

• Issued

• Pending Transfer

• Pending Archival

This field represents the entity who submitted the report and does not necessarily pertain to any counterparty to the transaction, although it can be equal to field 1.03 (Reporting Counterparty) if reporting is not delegated.
This entity could therefore be:

• a third-party service-provider to whom the Reporting Counterparty or Entity Responsible for the Report has outsourced the operation of reporting (Agent Lender or other), else;

• equal to Field 1.03 (Reporting Counterparty) where there is no delegation and Field 1.05 (Sector of the Reporting Counterparty) is not a UCITS management company or AIFM reporting on behalf of a UCITS or AIF; else

• equal to Field 1.10 (Entity Responsible for the Report) if that is not also the Reporting Counterparty, in which case it will be either a UCITS management company or AIFM reporting on behalf of a UCITS or AIF.

Where a trade is booked via an Agent Lender (Field 1.18), who is the appointed delegate, it will also be the Report Submitting Entity (1.2). (SFTR-4)

Reporting Counterparty

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

Field 1.03 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: No

Description:
Unique code identifying the reporting counterparty

Best Practice:
This field shall contain a valid LEI recognised by GLEIF. The LEI shall pertain to a legal entity and not a branch. The status of the LEI for message template "EROR" is irrespective, but for all other message templates it can be either:

• Issued

• Pending Transfer

• Pending Archival

In addition, for message template "ETRM", the status of the LEI could also be either:

• Lapsed

• Retired

There are three models that determine the population logic of this field, as follows:

• Agency facing the Beneficial Owner.

• Agency facing a Trust Bank facing the Beneficial Owner

• Principal

Therefore, when trading a position on behalf of a client this is the beneficial owner or trust bank of the trade, except where a lender or borrower takes on a principle position; in all models the reporting counterparty LEI reported in this field and the beneficiary to the contract is reported in Beneficiary (Field 1.13) and are always the same. (SFTR-5)

Nature of the Reporting Counterparty

Status: Best Practice Finalised, Last Updated: 25/05/2021

Field 1.04 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No

Description:
Indicates if the reporting counterparty is a financial or non-financial counterparty.

Best Practice:
Populate with 'F' or 'N' to indicate whether the nature of the reporting counterparty, to be financial counterparty (FCs) or non-financial counterparty (NFCs). For definitions, look to the Level 1 text in Article 3, paragraphs (3) and (4): Here

An NFC is further defined as a small financial entity (SME NFC) where an NFC does not exceed the two of following three limits:

• balance sheet total of EUR 20 million

• net annual turnover of EUR 40 million; and

• average number of employees of 250.

There is no requirement for NFCs to report under UK SFTR, therefore this field has been removed from the UK SFTR validation rules template. More information can be found here. (SFTR-6)

Sector of the Reporting Counterparty

Status: Best Practice Finalised, Last Updated: 17/05/2021

Field 1.05 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No

Description:
One or more codes that classify the nature of the Reporting Counterparty's business activities. If the reporting counterparty is a financial counterparty, all necessary codes included in the Taxonomy for financial counterparties and applying to that counterparty shall be reported. If the reporting counterparty is a non-financial counterparty, all necessary codes included in the Taxonomy for non-financial counterparties and applying to that counterparty shall be reported. Where more than one activity is reported, the codes shall be populated in order of the relative importance of the corresponding activities.

Best Practice:
If Field 1.04 (Nature Of The Reporting Counterparty) is populated with "F", at least one code pertaining to the classification of the financial counterparties shall be provided, of which there are 9 options (x4 alphabetical characters).

If Field 1.04 (Nature Of The Reporting Counterparty) is populated with "N", at least one code pertaining to the classification of the non-financial counterparties shall be provided, of which there are 14 options (x1 alphabetical characters). (SFTR-142)

Additional Sector Classification

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

Field 1.06 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No

Description:
In the case where the reporting counterparty is an Undertaking for Collective Investment in Transferable Securities (UCITS) or Alternative Investment Fund (AIF), a code that determines whether it is an Exchange-Traded Fund (ETF) or a Money Market Fund (MMF). In the case where the reporting counterparty is an Alternative Investment Fund (AIF) or a non-financial counterparty undertaking financial and insurance activities or real estate activities, a code that determines whether it is a Real Estate Investment Trust (REIT).

Best Practice:
If Field 1.05 (Sector Of The Reporting Counterparty) is populated with "K" or "L" or "AIFD" or "UCIT", at least one code pertaining to the classification of the additional sector of the financial counterparties shall be provided, of which there are 4 options (x4 alphabetical characters). (SFTR-8)

Branch of the Reporting Counterparty

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

Field 1.07 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No

Description:
When the Reporting Counterparty concludes an SFT through a branch office, the LEI of the branch. Until the LEI for branches is endorsed by ESMA, the code of the country where the branch is located shall be reported.

Best Practice:
Where the reporting counterparty concludes an SFT through a branch office, the ISO 3166-1 country code identifying the branch shall be populated, else leave blank. (SFTR-9)

Branch of the Other Counterparty

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

Field 1.08 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: Yes

Description:
When the Other Counterparty concludes an SFT through a branch office, the LEI of the branch. Until the LEI for branches is endorsed by ESMA, the code of the country where the branch is located shall be reported.

Best Practice:
Where the other counterparty concludes an SFT through a branch office, the ISO 3166-1 country code identifying the branch shall be populated, else leave blank. (SFTR-10)

Counterparty Side

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

Field 1.09 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: Yes

Description:
Identifies whether the reporting counterparty is a collateral provider or a collateral taker in accordance with the Article 4 of the [ITS]

Best Practice:
In all cases where the field is available on the message template, Field 1.09 (Counterparty Side) should be populated from the perspective of the direction of the collateral.

Collateral sent = GIVE
Collateral received = TAKE (SFTR-11)

Entity Responsible for the Report

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

Field 1.10 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No

Description:
In the case where a financial counterparty is responsible for reporting on behalf of the other counterparty in accordance with Article 4(3) of Regulation (EU) No 2365/2015, the unique code identifying that counterparty. In the case where a management company is responsible for reporting on behalf of an Undertaking for Collective Investment in Transferable Securities (UCITS) in accordance with Article 4(3) of Regulation (EU) No 2365/2015, the unique code identifying that management company. In the case where an Alternative Investment Fund Manager (AIFM) is responsible for reporting on behalf of an Alternative Investment Fund (AIF) in accordance with Article 4(3) of Regulation (EU) No 2365/2015, the unique code identifying that AIFM, in all other cases, the Reporting Counterparty, even where the responsible entity has outsourced reporting to another entity.

Best Practice:
This field shall contain a valid LEI recognised by GLEIF. The LEI shall pertain to a legal entity and not a branch. The status of the LEI for all message templates can be either:

• Issued

• Pending Transfer

• Pending Archival

Additionally, for message template 'ETRM', the status of the LEI can also be:

• Lapsed

• Retired

In all scenarios except two, including delegated reporting and agency or principal business models, the Entity Responsible for the Report (1.10) will always be equal to the Reporting Counterparty (1.03).

The two exceptions to this statement are under an Agency model where:
i. A management company is responsible for reporting on behalf of an UCITS fund in accordance with Article 4(3) of Regulation (EU) No 2365/2015 (Level I Text), the unique code identifying that management company, and:

ii. An AIFM is responsible for reporting on behalf of AIF in accordance with Article 4(3) of Regulation (EU) No 2365/2015 (Level I Text), the unique code identifying that AIFM. (SFTR-12)

Other Counterparty

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

Field 1.11 | Matching Date: 2020-04-01 | Tolerance: None | Agent Lender Data Provision: Yes

Description:
Unique code identifying the entity with which the reporting counterparty concluded the SFT. In case of a private individual a client code shall be used in a consistent manner.

Best Practice:
This field shall contain a valid LEI recognised by GLEIF. The LEI shall pertain to a legal entity and not a branch.

The LEI shall not pertain to a member of the European System of Central Banks (ESCB).

The status of the LEI for all message templates, except EROR, can be either:

• Issued

• Lapsed

• Pending Transfer

• Pending Archival

Additionally, for message template ETRM, the status of the LEI can also be:

• Retired

For action type EROR, this field shall contain an LEI included in the GLEIF database maintained by the Central Operating Unit, irrespective of the registration status of that LEI or up to 50 free-format, alphanumerical, characters. (SFTR-13)

Country of the Other Counterparty

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

Field 1.12 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: Yes

Description:
The code of country where the registered office of the other counterparty is located or country of residence in case that the other counterparty is a natural person.

Best Practice:
Populate using a valid ISO 3166, 2-digit, alphabetical, country code. Where Field 1.11 (Other Counterparty) has been populated with a valid LEI, this country code will equal the country of the registered office of the other counterparty. (SFTR-14)

Beneficiary

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

Field 1.13 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: Yes

Description:
If the beneficiary of the contract is not a counterparty to this contract, the reporting counterparty has to identify this beneficiary by a unique code or, in case of a private individual, by a client code used in a consistent manner as assigned by the legal entity used by the private individual.

Best Practice:
Where the beneficiary of the contract is not a counterparty to this contract, this field shall contain a valid LEI recognised by GLEIF. The LEI shall pertain to a legal entity and not a branch.

The status of the LEI for all message templates, can be either:

• Issued

• Lapsed

• Pending Transfer

• Pending Archival (SFTR-15)

Tri-Party Agent

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

Field 1.14 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No

Description:
Unique code identifying the third party to which the Reporting Counterparty has outsourced the post-trade processing of an SFT. When no tri-party agent is used, this information shall not be provided.

Best Practice:
Where a Triparty Agent is used, this field shall contain a valid LEI recognised by GLEIF. The LEI shall pertain to a legal entity and not a branch.

The status of the LEI for all message templates, can be either:

• Issued

• Lapsed

• Pending Transfer

• Pending Archival (SFTR-16)

Broker

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

Field 1.15 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No

Description:
The unique code of the entity that acts as intermediary for the reporting counterparty without becoming a counterparty to the SFT itself. For securities lending transactions, broker does not include the agent lender.

Best Practice:
Where a Broker is used, this field shall contain a valid LEI recognised by GLEIF. The LEI shall pertain to a legal entity and not a branch.

The status of the LEI for all message templates, can be either:

• Issued

• Lapsed

• Pending Transfer

• Pending Archival (SFTR-17)

Clearing Member

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

Field 1.16 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No

Description:
In the case where the trade is cleared, the responsible clearing member shall be identified in this field by a unique code

Best Practice:
Where an SFT is cleared and Field 2.5 (Cleared) equals "TRUE", this field represents the clearing member at the CCP therefore; the Agent Lender or the Principal and shall contain a valid LEI recognised by GLEIF. The LEI shall pertain to a legal entity and not a branch.

The status of the LEI for all message templates, can be either:

• Issued

• Lapsed

• Pending Transfer

• Pending Archival (SFTR-18)

CSD Participant or Indirect Participant

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

Field 1.17 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No

Description:
The unique code of the - CSD participant or indirect participant of the reporting counterparty In the case where both CSD participant and indirect participant are involved in the transaction, the indirect participant shall be identified in this field. This field is not applicable for commodities.

Best Practice:
For securities lending and borrowing SFTs, counterparties should mandatorily populate this field. It is flagged as optional, as it is not required for margin lending or commodities.

This field should be reported even if the SFT settles outside of a CSD. ESMA expects that the reporting counterparty should report this field using the following logic:

• Report its own LEI if it is settling directly at any CSD, i.e. it is a CSD participant;

• Report its own LEI if it is settling securities at any of the two ICSDs even where the ICSD is not the issuer CSD, i.e. it the counterparty is an ICSD participant;

• Report the LEI of its custodian bank irrespective of whether the custodian is using any sub-custodian or not. This includes scenarios when a counterparty uses an Agent Lender.

The counterparty should not report the LEI of the CSD in which they are either direct or indirect participants in the "CSD Participant" field.

Therefore, the population logic is as follows:

1) Principal Model - Equal to Field 1.13 (Beneficiary)
2) Agency Model - Equal to Field 1.18 (Agent Lender)

Where used, this field shall contain a valid LEI recognised by GLEIF. The LEI shall pertain to a legal entity and not a branch.

The status of the LEI for all message templates, can be either:

• Issued

• Lapsed

• Pending Transfer

• Pending Archival (SFTR-19)

Agent Lender

Status: Best Practice Finalised, Last Updated: 24/05/2021

Field 1.18 | Matching Date: n/a | Tolerance: n/a | Agent Lender Data Provision: No

Description:
The unique code of the agent lender involved in the securities lending transaction.

Best Practice:
Where an Agent Lender is used, this field shall contain a valid LEI recognised by GLEIF. The LEI shall pertain to a legal entity and not a branch.

The status of the LEI for all message templates, can be either:

• Issued

• Lapsed

• Pending Transfer

• Pending Archival

Known issue: Agent Lender (Field 1.02 & Field 1.18) not included in the TR's primary-key construction logic. This is an acute problem for some agent lenders who support beneficial owners who have multiple agents. One current workaround is to use the Report Submitting Entity (1.04) as one of the keys then the agent lenders populate this field with their own LEI (instead of the vendor submitting the report with their LEI).

Regarding use of an Asset Manager LEI in this field where the Asset Manager acts as the Agent Lender, see here. (SFTR-20)