EMIR Reporting Industry Best Practices Matrix February 2020

Legal Disclaimer
This document does not constitute legal, regulatory, accounting, tax or financial advice.
It reflects feedback received by ISDA, FIA, IA, GFXD, EFAMA, BVI and/or EVIA from swap
market participants (including both dealer and buy-side firms) who, as members of one
or more of the participating trade associations, participated in the Working Groups,
committees and member forums and it is not meant to be binding in any way. As with
all guidance and market information that ISDA, FIA, IA, GFXD, EFAMA, BVI and/or EVIA
disseminates, parties are free to choose alternate means of addressing the specific facts
of their situation. ISDA, FIA, IA, GFXD, EFAMA, BVI and EVIA assumes no responsibility
for any use of this document and undertakes no duty to update it to reflect future
regulatory or market developments. Each market participant should satisfy itself that
following or not following the EMIR Best Practices set out herein is appropriate to their
specific circumstances.
UNDER NO CIRCUMSTANCES SHALL ISDA, FIA, IA, GFXD, EFAMA, BVI AND/OR EVIA BE
LIABLE TO ANY PARTY, REGARDLESS OF THE FORM OF ACTION, ARISING FROM OR IN
CONNECTION WITH INFORMATION IN THIS DOCUMENT OR ANY PERSON'S USE OF THIS
DOCUMENT, OR FOR ANY DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL,
PUNITIVE OR ANY OTHER DAMAGES THAT MAY RESULT FROM THE USE OF THIS
DOCUMENT.
EMIR Regulatory Reporting Best Practices
Purpose
The EMIR Reporting Best Practices, for both over-the-counter derivative (OTC) and exchange traded derivative (ETD) reporting, is
relevant reporting Working Groups or Committees of each trade association. The working groups and committees comprised of a w
fields which would benefit from establishing best practices. These fields were identified by a combination of isolating the fields whic
scenario would benefit from additional guidance. The working groups / committees reviewed and agreed to the reporting best prac
these best practices is to provide an agreed and standardised market guide for firms to utilize in order to comply with EMIR OTC a
any determinations made within these EMIR best practices.
The trade associations participating in the establishment of these best practices are International Swaps and Derivatives Associati
Investment Funds Association (BVI), European Fund and Asset Management Association (EFAMA), and European Venues & Inter
Commentary
The best practice matrix has been established based on the EMIR validation table, (as published by ESMA), which contains the Re
The intention is for these EMIR Reporting Best Practices to be widely accepted as standard market practice which complements th
EMIR Q&A documents, and are designed to adhere to the published EMIR validation rules. The best practices have been shared w
reporting document which are endorsed by regulators. The best practices may be updated periodically, for example when an upda
time.
The Validation rules define fields as being either 'Mandatory', 'Conditional' or 'Optional'. These categories relate to the checks Trad
a field is identified as 'Optional', the field must be populated if it is relevant for the contract being reported, i.e. all fields are mandat
As well as the main 'Industry Best Practice matrix', additional best practices based on specific scenarios are captured with the tabs
For the avoidance of doubt, although they may be some overlap between the EMIR reporting requirements and the reporting requi
Contact details
Trade association Email address

ISDA ISDADataReporting@isda.org
FIA jgraham@fia.org
GFXD fwillis@gfma.org; aharvey@gfma.org
IA david.broadway@theia.org
BVI Felix.Ertl@bvi.de
EFAMA Vincent.Dessard@efama.org
EVIA amcdonald@evia.org.uk
d derivative (ETD) reporting, is a cross trade association initiative which has been established and agreed by market participants through a series of discus
d committees comprised of a wide array of market participants from buy and sell side institutions. The trade associations and their members identified the E
ation of isolating the fields which most commonly mismatch between reporting parties, and from suggestions put forward by member firms where a given fie
reed to the reporting best practices captured within the 'Industry Best Practice matrix' and the supporting best practice documents referred to within the ma
er to comply with EMIR OTC and ETD trade reporting requirements, and improve reporting effectiveness and accuracy. No firm is legally bound or compell
waps and Derivatives Association (ISDA), Futures Industry Association (FIA), the Global Foreign Exchange Division (GFXD) of GFMA, the Investment Asso
, and European Venues & Intermediaries Association (EVIA).
ESMA), which contains the Regulatory Technical Standards (RTS), the Implementation Technical Standards (ITS) and validation rules.
practice which complements the EMIR reporting RTS and ITS. Where possible these guidelines are designed to be consistent with other published reportin
t practices have been shared with ESMA and several NCAs to preview before being published, but for the avoidance of doubt, these best practices are not
lly, for example when an updated EMIR Q&A document is published or to add practices to further fields, but where possible the guidelines, once set, will re
ories relate to the checks Trade Repositories are to perform on a field and do not refer to whether the reporting party as the option to populate the field or n
orted, i.e. all fields are mandatory when they are relevant to the contract.
arios are captured with the tabs and/or via links within the main matrix.
ements and the reporting requirements of other global reporting regimes, these best practices are specific to EMIR reporting.
ticipants through a series of discussions held within the
and their members identified the EMIR trade reporting
by member firms where a given field, product or
ocuments referred to within the matrix. The intention of
No firm is legally bound or compelled in any way to follow
XD) of GFMA, the Investment Association (IA), German
alidation rules.
istent with other published reporting guidelines, such as

doubt, these best practices are not an official regulatory
ble the guidelines, once set, will remain consistent over
the option to populate the field or not. Specifically, where
ing.
"M" - Mandatory: the field is strictly required and validations of format and content are applied.
"C" - Conditionally mandatory: the field is required if the specific conditions set out in the validation rules are met. Format and
content validations
EMIR validation areESMA
table applied
"O" - Optional: the field shall be populated if applicable. Only format and content validations are applied when the field is populated.
"-" - Not relevant: the field shall be left blank
Validations
(published 03/04/2017)
Technical standards ESMA published updated on 20/12/2019. Amendments are marked in red font and are to Best Practice Links Comment
apply no later than 20 June 2020, but may be implemented by Trade Repositories prior to
that date.
Is itTrade level
Mandatory, IsPosition level
it Mandatory,
Conditional, Optional Conditional, Optional -Conditions Matching / Pairing
Table Item Section Field Details to be reported Format OTC ETD Justification for best practice where applicable
or Not relevant for a or Not relevant for a -Format and content field
N given
M E action
C R type?
Z V P N given
M E action
C R type?
Z V P
-Common input format: YYYY-MM-

DDThh:MM:SSZ
The reporting timestamp should be equal or
earlier than the timestamp of the receipt of
ISO 8601 date in the format and Coordinated
the report by the TR. The date part of the
1 1 Parties to the Reporting timestamp Date and time of reporting to the trade Universal MMMMMMMM MMMMM M timestamp cannot be earlier than the day N No best practice prepared for this field No best practice prepared for this field
contract repository Time (UTC) time format YYYY-MM-
preceding the date of the receipt of the
DDThh:mm:ssZ
report by the TR.
The receipt of the report should be
understood as the moment the report enters
a TR’s system
For action types "N", "M", "C", "R", "Z", "V"

and "P": this field shall contain a valid LEI
included in the GLEIF database maintained by
the Central Operating Unit.
The status of the LEI for all the above action
ISO 17442 Legal Entity Identifier (LEI) 20 types shall be "Issued", "Pending transfer" or
Parties to the Unique code identifying the reporting "Pending archival" and in addition for action
1 2 Reporting Counterparty ID alphanumerical character code. MMMMMMMM MMMMM M PAIRING FIELD No best practice prepared for this field No best practice prepared for this field
contract counterparty of the contract types "C" the status of the LEI could also be
"Lapsed" and "Retired".
For action type "E": 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.
Shall only contain one of the following

values: "LEI" or "CLC". 3 alphabetical
1 3 Parties to the Type of ID of the other Counterparty Type of the code used to identify the other “LEI” for ISO 17442 Legal Entity Identifier (LEI) M O O O O O O M M O O O O O characters. N No best practice prepared for this field No best practice prepared for this field
contract Counterparty “CLC” for Client code The value populated in this field when the
trade is reported for the first time, shall not
be modified in the subsequent reports.
For action types "N", "M","R", "Z", "V" and

"P": If field 1.3 is populated with "LEI", this
field shall be populated with a valid LEI
the Central Operating Unit.
For action types "N", "M","C", "R", "Z", "V"
and "P" The status of the LEI shall be
"Issued", "Lapsed", "Pending transfer" or
"Pending archival" .and in addition for action
Unique code identifying the other types "C" and "E" the status of the LEI could
counterparty of the contract. also be "Retired".
ISO 17442 Legal Entity Identifier (LEI) 20
Parties to the This field shall be filled from the For action type "E": This field shall contain an
1 4 ID of the other Counterparty alphanumerical character code. MMMMMMMM MMMMM M PAIRING FIELD No best practice prepared for this field No best practice prepared for this field
contract perspective of the reporting counterparty. Client code (up to 50 alphanumerical digits). LEI included in the GLEIF database
In case of a private individual a client code maintained by the Central Operating Unit,
shall be used in a consistent manner. irrespective of the registration status of that
LEI.
For action types "N", "M","R", "Z", "V" and
"P":
If field 1.3 is populated with "CLC". this field
shall contain up to 50 alphanumerical digits
where any character is allowed.
Fields 1.2 and 1.4 cannot contain the same
LEI, unless this corresponds to the LEI of the
CCP under field 2.37.
This field shall be populated with a valid ISO

3166 country code, 2 alphabetical characters
The code of country where the registered
If field 1.3 is populated with "LEI", the
1 5 Parties to the Country of the other Counterparty office of the other counterparty is located ISO 3166 - 2 character country code M O - - O - - M M O - - O - country code provided in this field shall N No best practice prepared for this field No best practice prepared for this field
contract or country of residence in case that the
pertain to the country of the registered office
other counterparty is a natural person. of the other counterparty as specified in the
LEI reference data.
Directive 2003/41/EC of the European
Parliament and of the Council
R = Reinsurance undertaking authorised in
accordance with Directive 2009/138/EC
U = Undertakings for the Collective
Investment in Transferable Securities (UCITS)
and its management company, authorised in
accordance with Directive 2009/65/EC of the
European Parliament and of the Council
Taxonomy for Non-Financial Counterparties.
The following categories correspond to the
Nature of the reporting counterparty's main sections of Statistical Classification of
company activities. economics activities in the European -If field 1.7 is populated with "F", this field
If the Reporting Counterparty is a Financial Community (NACE) as defined in Regulation shall be populated and shall contain only
Counterparty, this field shall contain all (EC) No 1893/2006 of the European following values: "A", "C", "F", "I", "L", "O",
necessary codes included in the Taxonomy Parliament and of the Council: "R", "U". Where more than one value is
for Financial Counterparties and applying 1 = Agriculture, forestry and fishing reported, they shall be separated with a dash
to that Counterparty. 2 = Mining and quarrying "-".
1 6 Parties to the Corporate sector of the reporting If the Reporting Counterparty is a Non- 3 =Manufacturing C O - - O - - C C O - - O - -If field 1.7 is populated with "N", this field N No best practice prepared for this field No best practice prepared for this field
contract counterparty Financial Counterparty, this field shall 4 = Electricity, gas, steam and air conditioning shall be populated and shall contain only
contain all necessary codes included in the supply following values: "1", "2," ..., "21". Where
Taxonomy for Non-Financial Counterparties 5 = Water supply, sewerage, waste more than one value is reported, they shall
and applying to that Counterparty. management and remediation activities be separated with a dash "-".
Where more than one activity is reported, 6 = Construction -If field 1.7 is populated with "C" or "O", this
the codes shall be populated in order of the 7 = Wholesale and retail trade, repair of field shall be left blank.
relative importance of the corresponding motor vehicles and motorcycles Up to 53 characters.
activities. 8 = Transportation and storage
9 = Accommodation and food service
activities
10 = Information and communication
11 = Financial and insurance activities
12 = Real estate activities
13 = Professional, scientific and technical
activities
14 = Administrative and support service
activities
15 = Public administration and defence;
compulsory social security
Indicate if the reporting counterparty is a
CCP, a financial, non-financial counterparty F = Financial Counterparty
or other type of counterparty in Shall contain only one of the following
1 7 Parties to the Nature of the reporting counterparty N = Non-Financial Counterparty M O - - O - - M M O - - O - N No best practice prepared for this field No best practice prepared for this field
accordance with point 5 of Article 1 or values: "F", "N", "C" or "O". 1 alphabetical
contract points 1, 8 and 9 of Article 2 of Regulation C = Central Counterparty character.
O = Other
(EU) No 648/2012 of the European
Parliament and of the Council.
Validations
that date.
Is itTrade level
it Mandatory,
N given
M E action
C R type?
Z V P N given
M E action
C R type?
Z V P
When populated, shall contain a valid LEI

In the case a broker acts as intermediary
for the reporting counterparty without included in the GLEIF database maintained by
Parties to the ISO 17442 Legal Entity Identifier (LEI) 20 the Central Operating Unit. The status of the
1 8 Broker ID becoming a counterparty himself, the O O - - O - - O O O - - O - N No best practice prepared for this field No best practice prepared for this field
contract reporting counterparty shall identify this alphanumerical character code LEI shall be "Issued", "Lapsed", "Pending
transfer" or "Pending archival".
broker by a unique code
In the case where the reporting When populated, shall contain a valid LEI
counterparty has delegated the submission
1 9 Parties to the Report submitting entity ID of the report to a third party or to the ISO 17442 Legal Entity Identifier (LEI) 20 O O - - O - - O O O - - O - the Central Operating Unit. The status of the N No best practice prepared for this field No best practice prepared for this field
contract other counterparty, this entity has to be alphanumerical character code
LEI shall be "Issued", "Pending transfer" or
identified in this field by a unique code.
Otherwise this field shall be left blank. "Pending archival".
In the case where the derivative contract is

cleared and the reporting When populated, shall contain a valid LEI For transaction-level reports and position-level reports,
this field shall only be populated in instances where the
counterparty is not a clearing member included in the GLEIF database maintained by
1 10 Parties to the Clearing member ID itself, the clearing member ISO 17442 Legal Entity Identifier (LEI) 20 O O - - O - - O O O - - O - the Central Operating Unit. The status of the N No best practice prepared for this field reporting party is not the clearing member. In this
contract alphanumerical character code scenario, the clearing member's LEI should be
through which the derivative contract is LEI shall be "Issued", "Lapsed", "Pending
populated in this field. If the reporting firm is the
cleared shall be identified transfer" or "Pending archival". clearing member, this field shall be left blank.
in this field by a unique code.
“LEI” for ISO 17442 Legal Entity Identifier

1 11 Parties to the Type of ID of the Beneficiary Type of the code used to identify the “LEI” for ISO 17442 Legal Entity Identifier (LEI) M O - - O - - M M O - - O - (LEI) N No best practice prepared for this field No best practice prepared for this field
contract Beneficiary “CLC” for Client code
“CLC” for Client code
The party subject to the rights and

obligations arising from the contract.
Where the transaction is executed via a
If field 1.11 is populated with "LEI" this field
structure, such as a trust or fund,
representing a number of beneficiaries, the shall be populated with a valid LEI included in
ISO 17442 Legal Entity Identifier (LEI) 20 the GLEIF database maintained by the
beneficiary should be identified as that
Parties to the structure. alphanumerical character code or up to 50 Central Operating Unit. The status of the LEI
1 12 Beneficiary ID alphanumerical character client code in the M O - - O - - M M O - - O - shall be "Issued", "Lapsed", "Pending N No best practice prepared for this field No best practice prepared for this field
contract Where the beneficiary of the contract is
case where the client is not eligible for a Legal transfer" or "Pending archival".
not a counterparty to this contract, the Entity Identifier If field 1.11 is populated with "CLC". this field
reporting counterparty has to identify this
shall contain up to 50 alphanumerical digits
beneficiary by an unique code or, in case of where any character is allowed.
a private individuals, by a client code used
in a consistent manner as assigned by the
legal entity used by the private individual.
Identifies whether the reporting

Parties to the counterparty has concluded the contract as P = Principal Shall contain only one of the following
1 13 Trading capacity principal on own account (on own behalf or M O - - O - - M O O - - O - N No best practice prepared for this field No best practice prepared for this field
contract A = Agent values: "P" or "A". 1 alphabetical character.
behalf of a client) or as agent for the
account of and on behalf of a client
B = Buyer
Parties to the Identifies whether the reporting Shall contain only one of the following
1 14 Counterparty side S = Seller M O - - O - - M M O - - O - Y No best practice prepared for this field No best practice prepared for this field
contract counterparty is a buyer or a seller values: "B" or "S". 1 alphabetical character.
Populated in accordance with Article 3a
Information on whether the contract is

objectively measurable as directly linked to If field 1.7 is populated with "N" and field
the reporting counterparty's commercial or
2.94 (Level) is populated with "T", this field
treasury financing activity, as referred to in shall be populated and shall contain only one
Parties to the Directly linked to commercial activity or Art. 10(3) of Regulation (EU) No 648/2012. Y = Yes
1 15 C O - - O - - C O O - - O - of the following values: "Y" or "N". 1 N No best practice prepared for this field No best practice prepared for this field
contract treasury financing This field shall be left blank in the case N = No
where the reporting counterparty is a alphabetical character.
If field 1.7 is populated with "F", "C" or "O",
financial counterparty, as referred to in
Article 2 (8) Regulation of (EU) No this field shall be left blank.
648/2012.
Information whether the reporting

counterparty is above the clearing If field 1.7 is populated with "N", this field
threshold referred to in Art. 10(3) of shall be populated and shall contain only one
1 16 Parties to the Clearing threshold Regulation (EU) No 648/2012. Y = Above the threshold C O - - O - - C C O - - O - of the following values: "Y" or "N". 1 N No best practice prepared for this field No best practice prepared for this field
contract This field shall be left blank in case the N = Below the threshold alphabetical character.
reporting counterparty is a financial If field 1.7 is populated with "F", "C" or "O",
counterparty, as referred to in Art. 2 (8) of this field shall be left blank.
Regulation (EU) No 648/2012.
Up to 20 numerical characters including

Mark to market valuation of the contract, decimals.
or mark to model valuation where The decimal mark is not counted as a At least one of the fields 1.17 or 1.21 has to
Parties to the be populated
1 17 Value of contract applicable under Article 11(2) of Regulation numerical character. If populated, it shall be O - - - - - C - O - - - - C N No best practice prepared for this field No best practice prepared for this field
contract (EU) No 648/2012. The CCP’s valuation to represented by a dot. Up to 20 numerical characters including up to
19 decimals
be used for a cleared trade The negative symbol, if populated, is not
counted as a numerical character.
If field 1.17 is populated, this field shall be

populated and shall contain ISO 4217
1 18 Parties to the Currency of the value The currency used for the valuation of the ISO 4217 Currency Code, 3 alphabetical C - - - - - C - C - - - - C N No best practice prepared for this field No best practice prepared for this field
Currency Code (official list only), 3
contract contract characters alphabetical characters.
Otherwise, the field shall be left blank.
Date and time of the last valuation. For If field 1.17 is populated, this field shall be
Parties to the mark-to-market valuation the date and ISO 8601 date in the UTC time format YYYY- populated in a common input format: YYYY- This field shall be left blank for transaction-level. Report OTC – Reporting entities generate the valuation amounts at different
1 19 Valuation timestamp C - - - - - C - C - - - - C N No best practice prepared for this field a default timestamp of '23:59:00' for position-level times, depending on their internal systems. Therefore, it is extremely
contract time of publishing of reference prices shall MM-DDThh:mm:ssZ MM-DDThh:mm:ssZ
reports difficult to match on the time element of this value.
be reported. Otherwise, the field shall be left blank.
If field 1.17 is populated and field 2.35 is

populated with "Y", this field shall be
populated with "C".
Parties to the Indicate whether valuation was performed M = Mark-to-market If field 1.17 is populated and field 2.35 is This field shall be left blank for transaction-level reports
1 20 Valuation type mark to market, mark to model or provided O = Mark-to-model C - - - - - C - C - - - - C N No best practice prepared for this field
contract populated with "N", this field shall be and position-level reports.
by the CCP C = CCP’s valuation. populated with ""M" or "O" . 1 alphabetical
character.
This field shall be left blank for transaction-level

U = uncollateralised At least one of the fields 1.17 or 1.21 has to reports. For position-level reporting, populating this
PC = partially collateralised be populated. field is subject to the transfer of collateral:
1 21 Parties to the Collateralisation Indicate whether a collateral agreement O - - - - - C O O - - - - C N
contract between the counterparties exists. OC = one way collateralised When populated, this field shall contain only - Client to CM is always one way collateralised
FC = fully collateralised one of the following values: "U", "PC", "OC" - CM to Client is always partially collateralised
Populated in accordance with Article 3b or "FC". Up to 2 alphabetical characters. - CM to CCP is always one way collateralised
- CCP to CM is always partially collateralised
Whether the collateralisation was

performed on a portfolio basis. If field 1.21 is populated with "PC", "OC" or
Parties to the Y = Yes "FC", this field shall be populated and shall This field shall be left blank for transaction-level reports
1 22 Collateral portfolio Portfolio means the collateral calculated on C O - - O - C C C O - - O C N
contract N = No contain only one of the following values: "Y" and populated with "Y" for position-level reports.
the basis of net positions resulting from a or "N". 1 alphabetical character.
set of contracts, rather than per trade.
Validations
that date.
Is itTrade level
it Mandatory,
N given
M E action
C R type?
Z V P N given
M E action
C R type?
Z V P
If field 1.22 is populated with "Y", this field

Up to 52 alphanumerical characters including shall be populated and shall contain up to 52
If collateral is reported on a portfolio basis,
four special characters : ". - _. " alphanumerical characters. Four special This field shall be left blank for transaction-level reports
1 23 Parties to the Collateral portfolio code the portfolio should be identified by a Special characters are not allowed at the C C - - C - C C C C - - C C characters are allowed ":", ".", "-", " _" . N and populated with the relevant collateral portfolio
contract unique code determined by the reporting
beginning and at the end of the code. No Special characters are not allowed at the code for position-level reports.
counterparty
space allowed. beginning or the end.
When populated:
Value of the initial margin posted by the Up to 20 numerical characters including up to
reporting counterparty to the other Up to 20 numerical characters including 19 decimals.
counterparty. decimals. The decimal mark is not counted as a
1 24 Parties to the Initial margin posted Where initial margin is posted on a The decimal mark is not counted as a O - - - - - O - O - - - - O numerical character. If populated, it shall be N No best practice prepared for this field
contract
portfolio basis, this field should include the numerical character. If populated, it shall be represented with a dot.
overall value of initial margin posted for represented by a dot. Negative values are not allowed.
the portfolio.

Parties to the Specify the currency of the initial margin ISO 4217 Currency Code, 3 alphabetical populated with ISO 4217 Currency Code
1 25 Currency of the initial margin posted C - - - - - C - C - - - - C N No best practice prepared for this field
contract posted characters (official list only), 3 alphabetical characters.
When populated:
Value of the variation margin posted, Up to 20 numerical characters including up to
including cash settled, by the reporting Up to 20 numerical characters including 19 decimals.
Parties to the counterparty to the other counterparty. decimals. The decimal mark is not counted as a
1 26 Variation margin posted Where variation margin is posted on a The decimal mark is not counted as a O - - - - - O - O - - - - O numerical character. If populated, it shall be N No best practice prepared for this field
contract
overall value of variation margin posted for represented by a dot. Negative values are not allowed.
the portfolio.

1 27 Parties to the Currency of the variation margins posted Specify the currency of variation margin ISO 4217 Currency Code, 3 alphabetical C - - - - - C - C - - - - C populated with ISO 4217 Currency Code N No best practice prepared for this field
When populated:
Value of the initial margin received by the Up to 20 numerical characters including up to OTC - ISDA have produced a document for the principles for Collateral
reporting counterparty from the other Up to 20 numerical characters including 19 decimals. See Comment •See EMIR reporting RTS-ITS
and Valuation
- collateral
reporting
and valuation
are found
fields
within
BESTthe
PRACTICE
'EMIR reporting
v6 RTS-ITS -
counterparty. decimals. The decimal mark is not counted as a collateral and valuation fields Best Practice'.
Parties to the
1 28 Initial margin received Where initial margin is received on a The decimal mark is not counted as a O - - - - - O - O - - - - O numerical character. If populated, it shall be N No best practice prepared for this field
contract
overall value of initial margin received for represented by a dot. Negative values are not allowed.
the portfolio.

1 29 Parties to the Currency of the initial margin received Specify the currency of the initial margin ISO 4217 Currency Code, 3 alphabetical C - - - - - C - C - - - - C populated with ISO 4217 Currency Code N No best practice prepared for this field
contract received characters (official list only), 3 alphabetical characters.
When populated:
Value of the variation margin received, Up to 20 numerical characters including up to
including cash settled, by the reporting Up to 20 numerical characters including 19 decimals.
counterparty from the other counterparty. decimals. The decimal mark is not counted as a
Parties to the
1 30 Variation margin received Where variation margin is received on a The decimal mark is not counted as a O - - - - - O - O - - - - O numerical character. If populated, it shall be N No best practice prepared for this field
contract portfolio basis, this field should include the numerical character. If populated, it shall be represented with a dot.
overall value of variation margin received represented by a dot. Negative values are not allowed.
for the portfolio.

1 31 Parties to the Currency of the variation margins received Specify the currency of the variation ISO 4217 Currency Code, 3 alphabetical C - - - - - C - C - - - - C populated with ISO 4217 Currency Code N No best practice prepared for this field
contract margin received characters (official list only), 3 alphabetical characters.
When populated:
Up to 20 numerical characters including up to
Up to 20 numerical characters including 19 decimals.
decimals. The decimal mark is not counted as a
1 32 Parties to the Excess collateral posted Value of collateral posted in excess of the O - - - - - O - O - - - - O N No best practice prepared for this field
The decimal mark is not counted as a numerical character. If populated, it shall be
contract required collateral numerical character. If populated, it shall be represented with a dot.
represented by a dot. Negative values are not allowed.

Parties to the Specify the currency of the excess collateral ISO 4217 Currency Code, 3 alphabetical populated with ISO 4217 Currency Code
1 33 Currency of the excess collateral posted C - - - - - C - C - - - - C N No best practice prepared for this field
When populated:
Up to 20 numerical characters including up to
Up to 20 numerical characters including 19 decimals.
decimals. The decimal mark is not counted as a
1 34 Parties to the Excess collateral received Value of collateral received in excess of the O - - - - - O - O - - - - O N No best practice prepared for this field
contract required collateral The decimal mark is not counted as a numerical character. If populated, it shall be
numerical character. If populated, it shall be represented with a dot.
represented by a dot. Negative values are not allowed.

Parties to the Specify the currency of the excess collateral ISO 4217 Currency Code, 3 alphabetical populated with ISO 4217 Currency Code
1 35 Currency of the excess collateral received C - - - - - C - C - - - - C N No best practice prepared for this field
contract received characters (official list only), 3 alphabetical characters.
CD = Financial contracts for difference

FR = Forward rate agreements
FU = Futures
Section 2a - FW = Forwards Shall only contain one of the following
2 1 Contract type Contract type Each reported contract shall be classified OP = Option M O - - O - - M M O - - O - values: "CD", "FR", "FU", "FW", "OP", "SB", Y No best practice prepared for this field No best practice prepared for this field
according to its type
SB = Spreadbet "SW" "ST" or "OT". 2 alphabetical characters.
SW = Swap
ST = Swaption
OT = Other
CO = Commodity and emission allowances Note: Reportable fields are not limited only to those
Validation rules do not prohibit fields which relate to a specific asset
CR = Credit Shall only contain one of the following applicable to the specified asset class, i.e. validation rules do This field will be populated with "CO", "CU", "EQ" or
2 2 Section 2a - Asset class Each reported contract shall be classified CU = Currency M O - - O - - M M O - - O - values: "CO", "CR", "CU", "EQ" or "IR". 2 Y not prevent firms from populating fields that fall under a "IR" and is subject to the CFI code populated in field 2.4 class in the 'Section' column from being populated for other asset
Contract type according to the asset class it is based on classes when applicable, e.g. FX fields to be populated for a cross
EQ = Equity alphabetical characters. different asset class (as per the 'Section' column) to the one below.
currency swap.
IR = Interest Rate specified in field 2.2.
Section 2b –
2 3 Contract Product classification type The type of relevant product classification C = CFI M O - - O - - M M O - - O - Until UPI is endorsed by ESMA, this field shall Y No best practice prepared for this field No best practice prepared for this field
U = UPI only contain "C". 1 alphabetical character.
information
Validations
that date.
Is itTrade level
it Mandatory,
N given
M E action
C R type?
Z V P N given
M E action
C R type?
Z V P
For products identified through

International Securities Identification If field 2.3 is populated wih "C", this field
shall be populated with CFI code composed
Number (ISIN) or Alternative Instrument
Identifier (AII), Classification of Financial of 6 characters and compliant with ISO 10962
Section 2b – Standard. At least the first 2 characters of
Instrument (CFI) code shall be specified. ISO 10692 CFI, 6 characters alphabetical code If there is an ISIN for the product, populate the field with the If there is an ISIN for the product, populate the field
2 4 Contract Product classification M O - - O - - M M O - - O - the CFI code and the character representing Y
information For products for which ISIN or AII are not Endorsed UPI asset class (if applicable for a given CFI code associated with that ISIN. with the CFI code associated with that ISIN.
available, endorsed Unique Product
instrument) shall be provided (ie. these
Identifier (UPI) shall be specified. Until UPI
is endorsed those products shall be characters cannot be "X", which represents
not applicable or undefined value).
classified with CFI code.
with (ii) code "XOFF", this field shall be

populated with "I".
-If field 2.15 is populated with MIC listed
in the MiFID Database that pertains to a
Regulated Market for which instrument
identifier specified in that database is AII, this
field shall be populated with "A".
-If field 2.15 is populated with (i) MIC
listed in the MiFID Database that pertains to
a Regulated Market for which instrument
identifier is not specified in that database, or
with (ii) MIC listed in the MiFID Database
that pertains to a MTF, or with (iii) MIC that
pertains to a trading venue in non-EEA
country, or with (iv) code "XXXX", this field
can be left blank.
After the date of application of [ MiFIR RTS
Section 2b – Specify the applicable identification: on reference data]], i.e. for the reports On transaction-level and position-level reports, this
2 5 Product identification type The type of relevant product identification I = ISIN C O - - O - - C C O - - O - where the date in the field 1.1 Reporting Y See 'Venue of Execution scenarios' tab for detailed best
Contract practices. field shall be populated with "I" for EEA Exchanges.
information A = AII timestamp is 03-01-2018 or later: For non-EEA Exchanges, this field shall be blank.
If field 2.15 is populated with (i) a MIC
that pertains to a trading venue in EEA
country or with (ii) a code "XOFF", this field
shall be populated with "I", unless:
- the date populated in the field 2.27
Maturity date is earlier than 03-01-2018,
or
- the date in the field 2.25 Execution
timestamp is 02-01-2018 and the date in the
field 1.1 Reporting timestamp is 03-01-2018,
in which cases this field can be
populated with "I" or "A".
Otherwise, (i.e. if the field 2.15 is not

populated with (i) a MIC that pertains to a
trading venue in EEA country or with (ii) a
code "XOFF") this field can be left blank.
The product shall be identified through ISIN

or AII. AII shall be used if a product is
traded in a trading venue classified as AII in
If field 2.5 is populated with "I" this field shall
the register published on ESMA's website contain 12 alphanumerical characters and a
and set up on the basis of information
For product identifier type I: ISO 6166 ISIN 12 check digit. On transaction-level and position-level reports, this
Section 2b – provided by competent authoriities
2 6 Contract Product identification pursuant to Article 13(2) of Commission character alphanumerical code C O - - O - - C C O - - O - If field 2.5 is populated with "A" this field Y See 'Venue of Execution scenarios' tab for detailed best field shall be populated with a valid ISIN for EEA
For product identifier type A: Complete AII shall contain up to 48 alphanumerical practices. Exchanges.
information Regulation (EC) No 1287/2006.
AII shall only be used until the date of code in accordance with Article 4(8) characters. Special signs "-" and "." are For non-EEA Exchanges, this field shall be blank.
allowed.
application of the delegated act adopted by
the Commission pursuant to Article 27(3) of
Regulation (EU) No 600/2014 of the
European Parliament and Council.
If field 2.2 (Asset class) is populated with

"EQ", this field shall be populated.
If field 2.2 is populated with "CR", one of the
Where field 2.2 'Asset class' is populated with "CO" or
fields 2.7 or 2.84 shall be populated.
"CU", populate this field with 'N/A'.
If field 2.2 is populated with "IR", at least one
I = ISIN of the following fields shall be populated: 2.7, As per EMIR Q&A, TR Question 28 – “When the underlying is an index,
When the Underlying is an Index:
Section 2b – A = AII 2.39, 2.55. When the Underlying is an Index, report a value of "X", "X" shall be populated in field 2.7 'Underlying Field 2.7 must always be populated with “X” irrespective of whether the
2 7 Contract Underlying identification type The type of relevant underlying identifier U = UPI C O - - O - - C C O - - O - If field 2.2 is populated with "CO" or "CU", Y index is identified with an ISIN or with the full name.”
regardless of whether an ISIN is available for the index. identification type' and a valid ISIN shall be populated
information B = Basket this field can be left blank.
X = Index When populated, this field shall contain one in field 2.8 'Underlying identification. TR Question 37 (d) also reiterates that an Index is reported as "X".
Where an ISIN is not available, "X" shall be populated in
of the following values: "I", "A", "U", "B", "X".
"NA" is accepted, when the actual value is field 2.7 and the Index name shall be populated in field
2.8.
not available.
Up to 2 alphabetical characters.

For underlying identification type I: ISO 6166 populated.
The direct underlying shall be identified by
using a unique identification for this ISIN 12 character alphanumerical code If field 2.7 is populated with "I", this field
For underlying identification type A: complete shall contain 12 alphanumerical characters
underlying based on its type.
AII shall only be used until the date of AII code in accordance with Article 4(8) and a check digit.
For underlying identification type U: UPI If field 2.7 is populated with "A", this field
application of the delegated act adopted by
For underlying identification type B: all shall contain up to 48 alphanumerical
Section 2b – the Commission pursuant to Article 27(3) of individual components identification through characters and the following two types of
2 8 Contract Underlying identification Regulation (EU) No 600/2014. C O - - O - - C C O - - O - Y No best practice prepared for this field No best practice prepared for this field
ISO 6166 ISIN or complete AII code in special characters "-" and "." are allowed.
information For Credit Default Swaps, the ISIN of the accordance with Article 4(8). Identifiers of If field 2.7 is populated with "B", this field
reference obligation should be provided.
individual components shall be separated shall contain only up to 6499 alphanumerical
In case of baskets composed, among
others, of financial instruments traded in a with a dash “-“. characters and the following two types of
For underlying identification type X: ISO 6166 special characters "-" and "." are allowed.
trading venue, only financial instruments
traded in a trading venue shall be specified. ISIN if available, otherwise full name of the "NA" is accepted, when the actual value is
index as assigned by the index provider not available.
Note. For FX Options, the FpML model determines the notional currency
based on whether the option is a Call or Put. i.e. if option is sold a Call,
Where there is more than one notional amount, sort the This field is dependent on the specific contract details then the notional amount will be in the Call currency, and therefore
The currency of the notional amount. currencies alphabetically by ISO 4217 standard and report
Section 2b – Shall be populated with ISO 4217 Currency and should not be ordered alphabetically. Notional 'National currency 1' would be the Call currency. Similarly, if sold a Put
2 9 Notional currency 1 In the case of an interest rate or currency ISO 4217 Currency Code, 3 alphabetical M O - - O - - M M O - - O - Y the first currency as Notional currency 1.
Contract derivative contract, this will be the notional characters Code (official list only), 3 alphabetical Currency 1 is directly linked with the Notional, which is option, FpML will show the notional in the Put currency, so 'Notional
information characters. directly linked to the price, which is directly linked to currency 1' would also be the Put currency.
currency of leg 1. Note: See exception for FX Options, where best practice for
FX Option contracts is under review. the specific contract details. Therefore, firms submitting by FpML cannot follow the best practice of
sorting currencies alphabetically when reporting FX Options.
A resolution to the best practice for FX Options is under review.
Note. For FX Options, the FpML model determines the notional currency
based on whether the option is a Call or Put. i.e. if option is sold a Call,
Where there is more than one notional amount, sort the then the notional amount will be in the Call currency, and therefore
The other currency of the notional amount. currencies alphabetically by ISO 4217 standard and report As set out in field 2.9, this field is dependent on the
Section 2b – When populated: 'National currency 1' would be the Call currency. Similarly, if sold a Put
2 10 Contract Notional currency 2 In the case of an interest rate or currency ISO 4217 Currency Code, 3 alphabetical O O - - O - - O O O - - O - ISO 4217 Currency Code (official list only), 3 Y the second currency as Notional currency 2. specific contract details. As such, Notional Currency 2 is option, FpML will show the notional in the Put currency, so 'Notional
derivative contract, this will be the notional characters the opposite currency (the base currency) to Notional
information alphabetical characters. currency 1' would also be the Put currency.
currency of leg 2. Note: See exception for FX Options, where best practice for currency 1.
FX Option contracts is under review. Therefore, firms submitting by FpML cannot follow the best practice of
sorting currencies alphabetically when reporting FX Options.
A resolution to the best practice for FX Options is under review.
Validations
that date.
Is itTrade level
it Mandatory,
N given
M E action
C R type?
Z V P N given
M E action
C R type?
Z V P
This field is only populated for transaction-level and

position-level reports if field 2.2 (Asset class) is
populated with "CU".
As per EMIR Q&A TR Answer 47, this field should be

FX products:
populated as the currency of the underlying to be For FX deliverable (physically settled) trades, this field is not directly
• FX deliverable (physically settled) trades, populate with the
Section 2b – When populated: first currency when sorted alphabetically by the ISO 4217 delivered in the case of a physically settled derivative or applicable, since both currencies in the trade are delivered. This field
ISO 4217 Currency Code, 3 alphabetical the settlement currency, if the derivative is to be cash should therefore be populated with the first currency when sorted
2 11 Contract Deliverable currency The currency to be delivered O O - - O - - O O O - - O - ISO 4217 Currency Code (official list only), 3 N standard.
information characters alphabetical characters. settled. alphabetically by the ISO 4217 standard.
For FX non-deliverable (cash settled) trades, this field should be used for
• FX non-deliverable (cash settled) trades, populate with the
The Delivery currency 2 field should be populated for the currency that will be delivered.
currency that will be delivered. those derivatives with an FX component for which two
currencies are delivered. If both Deliverable currency
and Delivery currency 2 are populated, the field
Deliverable currency should be populated with the first
currency sorted in alphabetical order.
Until global UTI is available and for action

types "N", "M","R", "Z", "V" and "P":
OTC - There is inconsistency between the ITS and Validation rules for
Up to 52 alphanumerical characters. special characters, i.e. the ITS lists a 'full stop' (".") twice, and the
Four special characters are allowed ":", ".",
validation rule includes a colon which is in addition to the ITS.
"-", " _" . Special characters not allowed at
Until global UTI is available, up to 52 the beginning or the end.
The CPMI IOSCO CDE for UTI does not use special characters and
alphanumerical character code including four Not allowed to change the content of this
Section 2c - Until global UTI is available, a Unique Trade special characters : ". - _." field once it is reported. • Avoid inclusion of special characters, i.e. only use For transaction-level reports, this field is populated advocates upper case only.
2 12 Details on the Trade ID MMMMMM C M MMMMM C PAIRING FIELD characters A-Z and 0-9. with the final version of the UTI as provided by the CCP
ID agreed with the other counterparty Special characters are not allowed at the The uniqueness of the Trade ID shall be
transaction • Report in UPPER case only in their end-of-day report. Additionally, reporting Trade ID in either upper case or lower case is
beginning and at the end of the code. No preserved at counterparties level, i.e. the applied inconsistently within the market, causes issues with pairing.
space allowed. combination of the fields Counterparty ID- ID
of the other counterparty-Trade ID shall be In order to increase pairing of Trade ID and avoid inconsistencies with
unique. The UTI shall not be case sensitive.
special characters, the best practice promotes a simplified Trade ID with
If field 2.93 is populated with "V" and field
1.22 is populated with "Y", this field can be no special characters and only upper case.
left blank.
Section 2c - A unique number for the group of reports Up to 52 alphanumerical characters where
2 13 Details on the Report tracking number which relate to the same execution of a An alphanumeric field up to 52 characters O O - - O - - M O O - - O - any character is allowed. N No best practice prepared for this field No best practice prepared for this field
transaction derivative contract
Identifier, internal to the reporting firm to

identify and link all the reports related to
the same derivative contract composed of
a combination of derivatitve contracts. The
code must be unique at the level of the
Section 2c - counterparty to the group of transaction Up to 35 alphanumerical characters. This fied
2 14 Details on the Complex trade component ID reports resulting from the derivative An alphanumeric field up to 35 characters O O - - O - - O O O - - O - shall only contain capital Latin letters and N No best practice prepared for this field No best practice prepared for this field
transaction contract. numbers.
Field applicable only when a firm executes
a derivative contract composed of two or
more derivatives contract and where this
contract cannot be adequately reported in
a single report.
Until the date of application of [ MiFIR RTS on

reference data]:
- MIC Code shall be validated against
MiFID Database of Regulated Markets and
MTFs. If it is a MIC code listed in the MiFID
Database, it shall be accepted.
- If the MIC is not listed in the MiFID
database, it shall be validated against the list
The venue of execution of the derivative of MIC codes maintained and updated by ISO
contract shall be identified by a unique and published at:
code for this venue. http://www.iso15022.org/MIC/homepageMI General principle:
If traded on a venue, report the MIC code of the venue.
Where a contract was concluded OTC and C.htm (column "MIC" in table "MICs List by
Section 2c - the respective instrument is admitted to ISO 10383 Market Identifier Code (MIC), 4 Country" of the respective Excel file). In case If trading on an SI, populate as “XOFF” or “XXXX” as For transaction-level and position-level reports, firms
alphanumerical characters in accordance with appropriate (do not report a MIC). For position level reporting, note Q&A TR 17(b) for trades executed at
2 15 Details on the Venue of execution trading or traded on a trading venue, MIC M - - - O - - M O - - - O - the MIC pertains to a venue in a non-EEA Y should populate this field with the relevant Segment
Article 4(b). different venues or both on and off exchange.
transaction code ‘ XOFF’ shall be used. country, the report shall be accepted. Best practice scenarios: MIC code.
Where a contract was concluded OTC and Otherwise the report shall be rejected.
See 'Venue of Execution scenarios' tab for detailed best
the respective instrument is not admitted practices.
to trading or traded on a trading venue, After the date of application of [ MiFIR RTS
MIC code ‘XXXX’ shall be used. on reference data]:
-This field shall be populated with a MIC
code included in the list maintained and
updated by ISO and published at:
http://www.iso15022.org/MIC/homepageMI
C.htm (column "MIC" in table "MICs List by
Country" of the respective Excel file).
The best practice depends on the type of transaction being

reported: EMIR RTS states "Y" is only to be populated for contracts that result
from a compression event.
• Termination as a result of a compression
• Action Type = “Z” Validation rules state this field is only applicable for Action Types "N",
• Compression = [blank] "R" and "P". Therefore, when a compression event results in a
• The early termination date will be reported modification (action type "M") or termination (action type "Z"), the
Compression field should be left blank.
• New trade as a result of a compression
Identify whether the contract results from
Section 2c - Y = contract results from compression This field shall contain only one of the • Action Type = “N” This field shall be populated with 'N' for transaction and Additionally, as per Validation rules, although a New Trade resulting
2 16 Details on the Compression a compression operation as defined in N = contract does not result from M - - - O - - M M - - - O - following values: "Y" or "N". 1 alphabetical Y • Compression = “Y” position-level reports. from a compression event is reported with Compression as "Y",
Article 2(1)(47) of Regulation (EU) No
transaction compression character. subsequent post trade events are to be reported with the Compression
600/2014.
• Modification as a result of a compression field left blank, i.e. the Compression value is not persisted for all post
• Action Type = “M” trade events.
• Compression = [blank]
• The new notional amount will be reported NB. Firms may want to verify with their Trade Repository whether the
Compression field can be left blank for action types "Z" and "M"
As per Q&A TR 17(c), "the compression field... is only without the submission being rejected and whether the Trade
intended for reporting at transaction level of OTC contracts Repository would accept a non-blank value for any action types other
not cleared by a CCP”. Therefore, all cleared contracts than "N", "R" or "P".
should only be populated with “N”.
Validations
that date.
Is itTrade level
it Mandatory,
N given
M E action
C R type?
Z V P N given
M E action
C R type?
Z V P
• See the 'PriceRate_Price Notation_Quantity' document for

best practices under each asset class. OTC - Commodities - Additional guidance required for how to report
Up to 20 numerical characters including Up to 20 numerical characters including up Price/rate Option and Forward products.
decimals. to 19 decimals. General principles:
The decimal mark is not counted as a The decimal mark is not counted as a '• “9999” only to be used where the price is not available, OTC - Additional guidance / rules required for currency order.
numerical character. If populated, it shall be numerical character. If populated, it shall be e.g. an average price which is only known at maturity.
Section 2c - The price per derivative excluding, where For transaction-level reports, this field shall contain the
2 17 Details on the Price / rate applicable, commission and accrued represented by a dot. M O - - O - - M O O - - O - represented with a dot. Y executed trade price. Position-level reports shall be Zero
See file 'PriceRate_Price Coupon Swap - This is a Rates contract where the fixed leg has a
Notation_Quantity'
The negative symbol, if populated, is not Negative values are allowed. The negative • FX Forward and NDF: Currency order for Exchange Rate – single known amount to be paid at the end of the trade (a bullet
transaction interest populated with the end-of-day settlement price.
counted as a numerical character. symbol, if populated, is not counted as a Guidance / rules are required on how to report the currency payment) and no fixed rate has been agreed. In order to capture this
In case the price is reported in percent numerical character. order. information within the reported data, the final known final amount is to
values, it should be expressed as percentage "999999999999999.99999" is accepted when be reported in the Price/rate field. This is generally agreed to be the
where 100% is represented as “100” the actual value is not available. • Zero coupon swaps: Populate with the final amount to be most suitable field to represent the final amount payable on the fixed
paid at maturity / bullet payment. leg.
• See the 'PriceRate_Price Notation_Quantity' document for

best practices under each asset class.
This field shall contain one of the following
values "U", "P" or "Y". 1 alphabetical
Section 2c - U = Units A price given in "basis points" should be reported as "P" Zero coupon swaps - The known final amount of the fixed leg is to be
2 18 character.
Details on the Price notation The manner in which the price is expressed P = Percentage M O - - O - - M O O - - O -
"X" is accepted when the actual value is not
Y (Percentage). The basis points would be converted into a No best practice prepared for this field See file 'PriceRate_Price
populated
Notation_Quantity'
in the Price/rate field, (comment for Price/rate field), so
transaction Y = Yield percentage; i.e. any price given in "basis points" should be consequently, the Price notation should be reported as "U" / Unit.
available and the field 2.17 is populated with
multiplied by 0.01 to convert to "percentage"/"P" in all cases.
"999999999999999.99999".
• Zero coupon swaps: Populate as "U"
If field 2.18 is populated with ‘U’ then the

field 2.19 shall be populated with ISO 4217
Section 2c - The currency in which the Price / rate is ISO 4217 Currency Code, 3 alphabetic Currency Code (official list only), 3 Directly linked to field 2.18. This field shall be
2 19 Details on the Currency of price C O - - O - - C C O - - O - Y No best practice prepared for this field populated with a valid currency code as set out in ISO
denominated characters alphabetical characters. If field 2.18 is
transaction 4217.
populated with ‘P’ or ‘Y’ it shall be left blank.
• Report the notional amount at the time of reporting.
• For the avoidance of doubt, a notional change is a

reportable event even when the change is a contractually
The reference amount from which -Up to 20 numerical characters including agreed event, e.g. an amortising or accreting notional.
decimals.
contractual payments are Up to 20 numerical characters including For Futures (where field 2.1 Contract type is populated
The decimal mark is not counted as a • Where there is more than one notional amount, e.g. FX
determined. In case of partial decimals. numerical character. If populated, it shall be products, sort the currencies alphabetically and report the with "FU", Notional is: trade price x number of lots x
Section 2c - terminations, amortisations and in case The decimal mark is not counted as a price multiplier. Zero coupon swaps - Where this is a final known amount to be paid on
2 20 represented with a dot. notional of the first currency.
Details on the Notional of contracts where the notional, due to the numerical character. If populated, it shall be M O - - O - - M M O - - O -
Negative values are allowed only when field
Y the fixed leg, and so there is no fixed rate or notional amount, the
transaction characteristics of the represented by a dot. For Options (where field 2.1 Contract type is populated notional amount of the floating leg is to be populated.
2.2 is populated with "CO". The negative • Amortizing, accreting and resets (on EQ) which change
contract, varies over time, it shall reflect The negative symbol, if populated, is not with "OP", Notional is: strike price x number of lots x
the remaining notional counted as a numerical character. symbol, if populated, is not counted as a notional amount should be reported as a Modification. price multiplier.
numerical character.
after the change took place.
• Notional changes which result from the compounding of
interest should not be reported.
• Zero coupon swaps: Populate with the notional of the

floating leg.
-Up to 20 numerical characters including up

Up to 20 numerical characters including to 19 decimals.
The number of units of the financial
Section 2c - instrument which are contained in a decimals. The decimal mark is not counted as a For FX products, this field should always be populated with
2 21 Details on the Price multiplier The decimal mark is not counted as a M O - - O - - M M O - - O - numerical character. If populated, it shall be Y This field should contain the contract size/lot size.
trading lot; for example, the number of “1”.
transaction numerical character. If populated, it shall be represented with a dot.
derivatives represented by the contract represented by a dot. Shall be populated with a positive value.
-Up to 20 numerical characters including up

to 19 decimals.
Number of contracts included in the report. Up to 20 numerical characters including The decimal mark is not counted as a For FX, Rates and Credit products, this field should always be OTC - the separate 'PriceRate Price Notation Quantity' best practice
Section 2c - For spread bets, the quantity shall be the decimals. numerical character. If populated, it shall be populate with “1”. This field shall be populated with the number of document is currently under review.
2 22 Details on the Quantity monetary value wagered per point The decimal mark is not counted as a M O - - O - - M M O - - O - represented with a dot. Y See file 'PriceRate_Price Notation_Quantity'
derivative contracts in the report.
transaction movement in the direct underlying numerical character. If populated, it shall be Shall be populated with a positive value. Zero For Equity and Commodity products see the 'PriceRate_Price OTC - Additional guidance required for Commodity Option and Forward
financial instrument. represented by a dot. is allowed only when field 2.94 is populated Notation_Quantity' best practice document. products.
with "P".
Up to 20 numerical characters including -Up to 20 numerical characters including up

decimals. to 19 decimals.
The negative symbol to be used to indicate The decimal mark is not counted as a When there is no fee, the field is left blank / null value, rather
• The value submitted for reporting should match the value on the
Section 2c - Amount of any up-front payment the that the payment was made, not received. numerical character. If populated, it shall be than populate with "0". trading platform and/or confirmation. Where there is a discrepancy,
2 23 Details on the Up-front payment The decimal mark is not counted as a O O - - O - - O O O - - O - represented with a dot. N No best practice prepared for this field
reporting counterparty made or received resolution of breaks should be discussed bilaterally between trade
transaction numerical character. If populated, it shall be Negative values are allowed. The negative When a premium is reported as Price/rate (field 2.17), the counterparties.
represented by a dot. symbol, if populated, is not counted as a Up-front payment field is left blank.
The negative symbol, if populated, is not numerical character.
FX products:
C (Cash): This should be used when the trade is non-

deliverable (the full amount of both notionals is not settled
by full exchange, rather the trade is settled by a single cash
flow). This is equivalent to “cash settlement” as defined in
the relevant product definitions published by the
International Swaps and Derivatives Association, Inc.
(“ISDA”), or “Non-Deliverable” as defined in the relevant
product definitions published by ISDA, the Emerging Markets
Section 2c - C = Cash Shall contain only one of the following Traders Association and The Foreign Exchange Committee
Indicates whether the contract is settled P = Physical
2 24 Details on the Delivery type M O - - O - - M M O - - O - values: "C", "P" or "O". 1 alphabetical Y (the “FX Definitions”). No best practice prepared for this field
physically or in cash O = Optional for counterparty or when
transaction determined by a third party character.
P (Physical): This should be used when the trade is
deliverable (settled by a full exchange of currencies). This is
equivalent to “Physical Settlement”, as defined in the
relevant product definitions published by ISDA, or
“Deliverable”, as defined in the FX Definitions.
O (Optional for counterparty): This should be used when the

counterparty has the right to select either cash or physical
delivery. For FX, this value is only applicable to certain
currency option transactions.
Validations
that date.
Is itTrade level
it Mandatory,
N given
M E action
C R type?
Z V P N given
M E action
C R type?
Z V P
General principle:
Date and time a transaction was originally executed, resulting
in the generation of a new UTI.
General principle wording is taken from CPMI-IOSCO CDE definition of
The Execution Timestamp remains unchanged throughout Execution timestamp.
the life of the contract and will only changes when the UTI
For transaction-level reports, this field shall be
changes / a new UTI is generated. populated with the timestamp provided by the CCP For cleared trades, it is understood that the intention of regulators is
(UTC). always to receive the MIC of the alpha trade, mechanically therefore
Section 2c - For the avoidance of doubt:
2 25 Details on the Execution timestamp Date and time when the contract was ISO 8601 date in the UTC time format YYYY- M O - - O - - M O O - - O - This field shall be populated in a common Y Novations – the novation timestamp forcing the presence of the instrument ISIN into the reporting.
executed MM-DDThh:mm:ssZ input format: YYYY-MM-DDThh:mm:ssZ. For give-ups, this field shall be populated with time of By extension this meant that the execution timestamp should also be
transaction Cleared trades – the Execution Timestamp of the alpha trade
is available, otherwise the clearing timestamp give-up rather than original execution time. that of the alpha trade.
The timestamp of the alpha trade is received in the clearing request
Amendments – persist the original Execution Timestamp, i.e.
For position reports, this field shall be left blank. message from the trading platforms or the middleware.
not the timestamp of the amendment event. If a CCP does not have an Execution timestamp of the alpha trade, only
Allocations – the Execution Date&Time of the original Block
then would they use the clearing timestamp.
trade.
See 'Execution Timestamp' tab for more best practice

scenarios.
• Where an Effective Date is specified in the terms of the

contract, report that date (i.e. the effective date represented
on the confirmation).
• If an effective date is not specified in the terms of the
contract, report the execution date (see best practice for
Execution Timestamp).
• Event and Product specific: While the RTS definition could be interpreted to mean the date the
contract was entered into (i.e. Trade Date) is to be reported, the best
• Amendments – persist the original Execution Timestamp,
practice is to report the Effective Date as agreed on the contract for the
i.e. do not reflect the timestamp of the amendment event. following reasons:
• Cleared trades – see best practice for Execution
Timestamp. o EMIR Q&A TR Question 48 asks “How should the Effective date… be
• Swaptions: Report the execution date of the contract,
Section 2c - reported if it is not specified as part of the terms of the contract?” . This
2 26 Date when obligations under the contract This field shall be populated in a common (note, the Effective Date of the underlyer is not to be used Current assumption is that this will always be the same
Details on the Effective date come into effect
ISO 8601 date in the format YYYY-MM-DD M O - - O - - M O O - - O -
input format: YYYY-MM-DD.
Y
for this field) as the trade date. implies that if the contract has an Effective Date, that is the date to
transaction report.
• Novations:
o For new trades (between Transferee/ Transferee1 and o The CPMI IOSCO definition for Effective Date is “Unadjusted date at
which obligations under the OTC derivative transaction come into effect,
Remaining Party/ Transferee 2), either:
as included in the confirmation.” Specifying that it is the date included in
(1) if the effective date of the trade is in the past, then report the confirmation validates it is the contractually agreed date to be
the Novation Date of the novation agreement, or
reported.
(2) if the effective date of the trade is a future date and is yet
to occur (i.e. a forward starting swap which has been
novated between the Trade Date and the Effective Date),
then report that future effective date of the trade.
o For partial or full novation between Remaining Party and
the Transferor, report the original Effective Date for the
transaction.
• Although an Optional field, if there is a Maturity Date for

the trade, this field must be reported.
• The unadjusted Maturity Date should be used, unless both

parties agree on reporting the adjusted date.
Original date of expiry of the reported When populated, shall be populated in a Reporting firms populate this field with the 'last trade
Section 2c - common input format: YYYY-MM-DD. • Where there is different Maturity Dates on the two legs,
2 27 contract. date' which conflicts with CCP's interpretation of this EMIR Q&A - TR Question 12.(c) - specifies the unadjusted Maturity date
Details on the Maturity date An early termination shall not be reported
ISO 8601 date in the format YYYY-MM-DD O O - - O - - O O O - - O - The value of this field shall be greater than or Y the Maturity Date reported should be the longest dated. field. CCPs populate this field with 'settlement date'. is to be reported.
transaction equal to the value of the field 2.26.
in this field. Regulatory guidance required.
FX products:
FX Options - populate with the option expiry date.
FX Forwards and Non-Deliverable Forwards (NDFs) - populate
with the valuation date of the trade, as defined in FX
Definitions.
When populated, shall be populated in a

common input format: YYYY-MM-DD.
The value of this field shall be greater than or
Section 2c - Termination date in the case of an early equal to the value of the date part of the Populate this field with the trade date to highlight that
2 28 Details on the Termination date ISO 8601 date in the format YYYY-MM-DD - - - M O M - M - - - M O - Y No best practice prepared for this field
termination of the reported contract. field 2.25. all ETD trades are compressed into a daily position.
transaction If fields 2.28 and 2.27 are both populated,
the value of this field shall be less than or
equal to the value of the field 2.27.
When populated shall be populated in a

Section 2c - Date of settlement of the underlying. The value of this field shall be greater than or This field will be populated with the maturity date (as RTS states “Date of settlement of the underlying”, but it is unclear how
2 29 Details on the Settlement date If more than one, further fields may be ISO 8601 date in the format YYYY-MM-DD O O - - O - - O O O - - O - N Best practice under review. See 'Comment' the definition of the 'underlyer' is to be applied across asset classes and
equal to the value of the date part of the populated in field 2.27).
transaction used. field 2.25. products. Additional clarification (potentially as a Q&A) required.
This field is repeatable.
Reference to any master agreement, if

existent (e.g. ISDA Master Agreement;
Section 2c - Master Power Purchase and Sale Free Text, field of up to 50 characters, Up to 50 alphanumerical characters where
2 30 Details on the Master Agreement type identifying the name of the Master O O - - O - - O O O - - O - N No best practice prepared for this field This field is left blank for ETD
Agreement; International ForEx Master any character is allowed.
transaction Agreement; European Master Agreement Agreement used, if any
or any local Master Agreements).

Section 2c - Reference to the year of the master populated in a common input format: YYYY.
2 31 Details on the Master Agreement version agreement version used for the reported ISO 8601 date in the format YYYY C O - - O - - O C O - - O - N No best practice prepared for this field 'This field is left blank for ETD
First two digits shall be "19" or "20".
transaction trade, if applicable (e.g. 1992, 2002, etc.) Otherwise, it shall be left bank.
Validations
that date.
Is itTrade level
it Mandatory,
N given
M E action
C R type?
Z V P N given
M E action
C R type?
Z V P
The timestamp is only reset when there is a new UTI, i.e. The original Confirmation timestamp is persisted for all post trade
events, unless such event results in a new contact / UTI.
once a confirmation timestamp has been reported, it is to be
persisted for the life of the contract.
Breaks can be caused by one party reporting the Confirmation
If field 2.33 is populated with "Y" or "E", this Timestamp of a post trade event, while the other persists the original
field shall be populated in a common input The value reported is the date and time the confirmation is datetime.
matched, not the time confirmations are sent.
format: YYYY-MM-DDThh:mm:ssZ. It was reasoned that the original timestamp should persist based on:
Section 2d - The value of this field shall be greater than or • The RTS definition's reference to Article 12 of Commission Delegated
Date and time of the confirmation, as set For electronic confirmations, the timestamp provided by the
2 32 Risk Confirmation timestamp ISO 8601 date in the UTC time format YYYY- C O - - O - - C O O - - O - equal to the value of the field 2.25 unless the Y This field shall remain blank for transaction and Regulation (EU) No 149/2013(3) which refers to 'Timely Confirmations'
out in Article 12 of Commission Delegated confirmation platform should be used.
mitigation / Regulation (EU) No 149/2013 MM-DDThh:mm:ssZ default date is used. position reports. in the context of 'date of execution' only.
Reporting "1900-01-01T00:00:00Z" is accepted when • The EMIR Q&A, OTC question 15 infers that Confirmation Timestamp is
Confirmation timestamp is only a matching field for
the actual value is not available. electronic confirmations (as verified with several TR's). only updated for the original submission, "The timely confirmation of
If field 2.33 is populated with "N", this field OTC derivative contracts applies wherever a new derivatives contract is
Therefore, although Confirmation timestamp is to be
shall be left blank. concluded"
populated when Confirmation Means is set to either "Y" or • In consideration to more standardisation between global reporting
"E", Confirmation timestamp will only be a matching field
regimes, the CPMI IOSCO CDE definition for Confirmed (2.18) refers to
when the value is "E". new transactions only.
Cleared trades = "E"
Non-cleared
• If Venue of Execution has a MIC, report as “N”
• Otherwise report “E” or “Y”. Note 1: Reason why cleared trades are reported as “E” is because CCPs
Therefore, when executed on an SI, the expectation is that confirm cleared trades with both parties to the alpha trade, and with TR
there will be a confirmation. Question 50 of the EMIR Q&A referring to derivatives “traded on a
trading venue”, i.e. referring to the original alpha trade and not the
Best practice definitions: cleared trade, it is logical to report cleared trades as “E”.
Section 2d -
Risk Whether the contract was electronically Y = Non-electronically confirmed Shall contain only one of the following • E (Electronically Confirmed): This should be used if the This field shall be populated with "N" in all cases. This
2 33 Confirmation means confirmed, non-electronically confirmed or N = Non-confirmed M O - - O - - M O O - - O - values: "Y", N" or "E". 1 alphabetical Y trade is Confirmed by means of matching electronic Note 2: Reasoning why an OTC non-cleared trade executed on a venue is
mitigation / aligns with EMIR TR Answer 50.
Reporting remains unconfirmed E = Electronically confirmed character. messages sent by each party to the other or by each party to reported as “N”, is because EMIR Q&A (TR Question 50) states that "N"
a third party system. Such electronic messaging systems is to be reported if the derivative “does not have to be confirmed”.
include, without limitation, SWIFT, CLS, DSMatch, Traiana, While a confirmation may still be issued for an OTC traded on a venue,
Markit and any other such systems used by or agreed to the trading venue will hold the details of the trade that both parties
between the parties hereto from time to time. agreed to and so a confirmation is not a necessary requirement.
• Y (Non-electronically Confirmed): This should be used if the

trade is Confirmed via a manual method, for example email,
fax or post.
The EMIR Q&A (TR Question 42) provides guidance on how to report for
• Report as "N" for all cleared trades, (per EMIR Q&A TR
transactions executed on a regulated market and for cleared trades (as
Question 42 (c2). The fields Cleared (2.35) is to be populated of May 2019).
with "Y".
OTC -
• Report as "X" if the product is not subject to mandatory
• The Q&A (TR 42.c(c2)) says to populate as "N" for all cleared trades.
If field 2.15 is not populated with a MIC code clearing, (unless or until the trade is cleared).
Indicates, whether the reported contract of a regulated market, or of a third-country
belongs to a class of OTC derivatives that • The Q&A has removed all reference to the value "X", but it remains a
market considered as equivalent to a • Report as "Y" if:
has been declared subject to the clearing regulated market, this field shall be (i) the product is subject to the clearing obligation, i.e. the permitted value within the Validation rules. Members propose to retain
Section 2e - obligation and both counterparties to the Y = Yes a scenario for reporting "X", where it will be used to represent products
2 34 Clearing obligation C O - - O - - C C O - - O - populated and shall contain one of the Y product is subject to mandatory clearing (as per the RTS This field shall always be left blank. •See 'EMIR Clearing product classes schedule and Clearing Obligation flag'
Clearing contract are subject to the clearing N = No which are not subject to mandatory clearing.
obligation under Regulation (EU) No following values "Y" or "N". official journal AND Once a trade reported as “X” is cleared, a value of “N” is to be reported.
'X' is accepted when the actual value is not (ii) both counterparties are subject to the clearing obligation,
648/2012, as of the time of execution of
the contract available. AND • The Q&A guidance and RTS read that the value "Y" is only reported if
1 alphabetical characters. (iii) has not yet been cleared, THEN
the contract AND the counterparties are subject to mandatory clearing,
Report as "Y".
BUT the trade has not yet been cleared.
• See 'EMIR Clearing product classes schedule and Clearing
Obligation flag' for additional best practice guidance for the ETD - The Q&A (TR 42.c(c1)) says to leave the field blank for transactions
executed on a regulated market.
products specified in the official journal).
2 35 Section 2e - Cleared Indicates, whether clearing has taken place Y = Yes M O - - O - - M M O - - O - Shall contain only one of the following values Y No best practice prepared for this field This field shall be populated with 'Y' in all cases.
Clearing N = No "Y" or "N". 1 alphabetical character.
If field 2.35 is populated with "Y", this field

shall be populated in a common input
format: YYYY-MM-DDThh:mm:ssZ. For transaction-level reports, this field shall be
Section 2e - ISO 8601 date in the UTC time format YYYY- populated with the same time as field 2.25 'Execution
2 36 Clearing timestamp Time and date when clearing took place C O - - O - - C O O - - O - The value of this field shall be greater than or Y No best practice prepared for this field
Clearing MM-DDThh:mm:ssZ equal to the value of the field 2.25. timestamp'. For position-level reports, a default
timestamp of "23:59:00" is populated in this field.
If field 2.35 is populated with "N", this field
shall be left blank.
If field 2.35 is populated with "Y" this field

shall be populated with a valid LEI included in
the GLEIF database maintained by the
In the case of a contract that has been
2 37 Section 2e - CCP cleared, the unique code for the CCP that ISO 17442 Legal Entity Identifier (LEI) C O - - O - - C C O - - O - Central Operating Unit. The status of the LEI Y No best practice prepared for this field No best practice prepared for this field
Clearing 20 alphanumerical character code. shall be "Issued", "Lapsed", "Pending
has cleared the contract.
transfer" or "Pending archival".
If field 2.35 is populated with "N", this field
shall be left blank.
If field 2.15 is not populated with a MIC code

of a regulated market or of a third-country
Indicates whether the contract was market considered as equivalent to a
Section 2e - entered into as an intragroup transaction, Y = Yes
2 38 Intragroup C O - - O - - C C O - - O - regulated market, this field shall be N No best practice prepared for this field No best practice prepared for this field
Clearing defined in Article 3 of Regulation (EU) No N = No populated and shall contain only one of the
648/2012
following values: "Y" or "N". 1 alphabetic
character.

"IR", at least one of the following fields shall
be populated: 2.7, 2.39, 2.55.
decimals expressed as percentage where Only one of the fields 2.39 and 2.55 can be
populated. Zero coupon swaps - This is a Rates contract where the fixed leg has a
100% is represented as “100”.
When populated, this field shall contain up to single known amount to be paid at the end of the trade (a bullet
2 39 Section 2f - Fixed rate of leg 1 An indication of the fixed rate leg 1 used, if The decimal mark is not counted as a C O - - O - - C C O - - O - 10 numerical characters including decimals. Y • Zero coupon swaps: Populate as "0" No best practice prepared for this field payment) and no fixed rate has been agreed. Although "0" (zero) is not
Interest Rates applicable numerical character. If populated, it shall be
The decimal mark is not counted as a an accurate reflection of the fixed rate, it is considered the best fit for
represented by a dot. numerical character. If populated, it shall be this product.
The negative symbol, if populated, is not
represented with a dot.
Negative values are allowed. The negative
symbol, if populated, is not counted as a
Validations
that date.
Is itTrade level
it Mandatory,
N given
M E action
C R type?
Z V P N given
M E action
C R type?
Z V P
'If field 2.2 (Asset class) is populated with "IR"

and field 2.1 (Contract type) is populated
with "SW" or "ST", one of the following fields
Up to 10 numerical characters including shall be populated: 2.40 or 2.58. The other
decimals expressed as percentage where field shall be left blank.
100% is represented as “100”. When populated, this field shall contain up to
Section 2f - An indication of the fixed rate leg 2 used, if The decimal mark is not counted as a 10 numerical characters including up to 9
2 40 Fixed rate of leg 2 C O - - O - - C C O - - O - Y No best practice prepared for this field No best practice prepared for this field
Interest Rates applicable numerical character. If populated, it shall be decimals.
represented by a dot. The decimal mark is not counted as a
The negative symbol, if populated, is not numerical character. If populated, it shall be
counted as a numerical character. represented with a dot.
If field 2.39 is populated, then this field shall

be populated and shall contain only
Numerator/Denominator where both,
The actual number of days in the relevant numerical characters or word "Actual" Due to restrictions in allowable values in the day count
2 41 Section 2f - Fixed rate day count leg 1 fixed rate leg 1 payer calculation period, if Numerator and Denominator are numerical C O - - O - - C C O - - O - followed by slash followed by numerical N fraction fields, see "Daycount Draft mapping" document for No best practice prepared for this field •See "Daycount Draft mapping"
Interest Rates characters or alphabetic expression ‘Actual’,
applicable characters or word "Actual". Up to 13 mappings to reportable values.
e.g. 30/360 or Actual/365
characters.
Otherwise the field shall be left blank.

be populated and shall contain only
The actual number of days in the relevant numerical characters or word "Actual"
2 42 Section 2f - Fixed rate day count leg 2 fixed rate leg 2 payer calculation period, if Numerator and Denominator are numerical C O - - O - - C C O - - O - followed by slash followed by numerical N No best practice prepared for this field No best practice prepared for this field
Interest Rates characters or alphabetic expression ‘Actual’,
applicable characters or word "Actual". Up to 13
e.g. 30/360 or Actual/365 characters.
The initial proposal for a Zero Coupon Swap was to report “0Y”, but this
value will not be accepted within the FpML framework. Therefore, a
Time period describing how often the
If field 2.39 is populated and field 2.1 is not best practice of “999Y” was proposed instead to distinguish a swap with
counterparties exchange payments, whereby populated with "FR", then this field shall be payment at maturity from a normal yearly coupon.
Time period describing frequency of the following abbreviations apply:
2 43 Section 2f - Fixed rate payment frequency leg 1 –time C O - - O - - C C O - - O - populated and shall contain only one of the N No best practice prepared for this field
payments for the fixed rate leg 1, if Y = Year
Interest Rates period applicable M = Month following values: "Y", "M", W" or "D". 1 MiFIR data reporting Q&A, section 13 'Reference Data for financial
alphabetic character. instruments’, covers a similar scenario and advises to report “0 ‘DAYS’”.
W = Week
D = Day Otherwise the field shall be left blank. This would translate to reporting "0D" for EMIR, but again with will not
be accepted within the FpML framework and so "999Y" remains the best
practice.
If field 2.39 is populated and field 2.1 is not

Integer multiplier of the time period • Fixed Rate time period :
Section 2f - Fixed rate payment frequency leg 1 – Multiplier of the time period describing describing how often the counterparties populated with "FR", then this field shall be
2 44 frequency of payments for the fixed rate C O - - O - - C C O - - O - populated and shall contain up to 3 N Zero Coupon swaps to submit "999Y". No best practice prepared for this field
Interest Rates multiplier exchange payments.
leg 1, if applicable numerical characters.
Up to 3 numerical characters. Otherwise the field shall be left blank. • The above should be generalised to any time period EMIR
fields, i.e. should be able to extend this best practice to any
EMIR field where the term is D W M Y in the RTS/ITS.
counterparties exchange payments, whereby
populated with "FR", then this field shall be
Section 2f - Fixed rate payment frequency leg 2 – time Time period describing frequency of the following abbreviations apply: populated and shall contain only one of the
2 45 payments for the fixed rate leg 2, if Y = Year C O - - O - - C C O - - O - N No best practice prepared for this field
Interest Rates period following values: "Y", "M", W" or "D". 1
applicable M = Month
W = Week alphabetic character.
D = Day

Multiplier of the time period describing Integer multiplier of the time period populated with "FR", then this field shall be
Section 2f - Fixed rate payment frequency leg 2 - describing how often the counterparties
2 46 frequency of payments for the fixed rate C O - - O - - C C O - - O - populated and shall contain up to 3 N No best practice prepared for this field
Interest Rates multiplier exchange payments.
leg 2, if applicable Up to 3 numerical characters. numerical characters.

Time period describing frequency of the following abbreviations apply: populated with "FR", then this field shall be
Section 2f - Floating rate payment frequency leg 1 – populated and shall contain only one of the
2 47 payments for the floating rate leg 1, if Y = Year C O - - O - - C C O - - O - N No best practice prepared for this field No best practice prepared for this field
Interest Rates time period following values: "Y", "M", W" or "D". 1
applicable M = Month alphabetic character.
W = Week
D = Day

Multiplier of the time period describing Integer multiplier of the time period populated with "FR", then this field shall be
Section 2f - Floating rate payment frequency leg 1 – describing how often the counterparties
2 48 frequency of payments for the floating rate C O - - O - - C C O - - O - populated and shall contain up to 3 N No best practice prepared for this field No best practice prepared for this field
Interest Rates multiplier leg 1, if applicable exchange payments. numerical characters.
Up to 3 numerical characters.

Time period describing frequency of the following abbreviations apply: populated with "FR", then this field shall be
Section 2f - Floating rate payment frequency leg 2 – populated and shall contain only one of the
2 49 payments for the floating rate leg 2, if Y = Year C O - - O - - C C O - - O - N No best practice prepared for this field No best practice prepared for this field
Interest Rates time period applicable M = Month following values: "Y", "M", W" or "D". 1
alphabetic character.
W = Week
D = Day
Integer multiplier of the time period If field 2.58 is populated and field 2.1 is not
Multiplier of the time period describing populated with "FR", then this field shall be The initial proposal for a Zero Coupon Swap was to report “0Y”, but this
2 50 Section 2f - Floating rate payment frequency leg 2 – describing how often the counterparties C O - - O - - C C O - - O - N No best practice prepared for this field No best practice prepared for this field value will not be accepted within the FpML framework. Therefore, a
frequency of payments for the floating rate populated and shall contain up to 3
Interest Rates multiplier leg 2, if applicable exchange payments. numerical characters. best practice of “999Y” was proposed instead to distinguish a swap with
Up to 3 numerical characters. payment at maturity from a normal yearly coupon.
MiFIR data reporting Q&A, section 13 'Reference Data for financial
instruments’, covers a similar scenario and advises to report “0 ‘DAYS’”.
This would translate to reporting "0D" for EMIR, but again with will not
Time period describing how often the be accepted within the FpML framework and so "999Y" remains the best
counterparties reset the floating rate, If field 2.55 is populated, then this field shall practice.
Section 2f - Floating rate reset frequency leg 1 – time Time period describing frequency of whereby the following abbreviations apply: be populated and shall contain only one of
2 51 Y = Year C O - - O - - C C O - - O - the following values: "Y", "M", W" or "D". 1 N No best practice prepared for this field No best practice prepared for this field
Interest Rates period floating rate leg 1 resets, if applicable
M = Month alphabetic character.
W = Week Otherwise the field shall be left blank.
D = Day
Integer multiplier of the time period If field 2.55 is populated, then this field shall
Section 2f - Floating rate reset frequency leg 1 - Multiplier of the time period describing describing how often the counterparties reset be populated and shall contain up to 3
2 52 frequency of floating rate leg 1 resets, if C O - - O - - C C O - - O - N No best practice prepared for this field No best practice prepared for this field
Interest Rates multiplier the floating rate. numerical characters.
applicable Up to 3 numerical characters. Otherwise the field shall be left blank.

counterparties reset the floating rate, If field 2.58 is populated, then this field shall
whereby the following abbreviations apply: be populated and shall contain only one of
2 53 Section 2f - Floating rate reset frequency leg 2- time Time period of frequency of floating rate C O - - O - - C C O - - O - N No best practice prepared for this field No best practice prepared for this field
Interest Rates period leg 2 resets, if applicable Y = Year the following values: "Y", "M", W" or "D". 1
M = Month alphabetic character.
D = Day
Multiplier of the time period describing Integer multiplier of the time period If field 2.58 is populated, then this field shall
Section 2f - Floating rate reset frequency leg 2 - describing how often the counterparties reset be populated and shall contain up to 3
2 54 frequency of floating rate leg 2 resets, if C O - - O - - C C O - - O - N No best practice prepared for this field No best practice prepared for this field
Interest Rates multiplier the floating rate. numerical characters.
applicable Up to 3 numerical characters. Otherwise the field shall be left blank.
Validations
that date.
Is itTrade level
it Mandatory,
N given
M E action
C R type?
Z V P N given
M E action
C R type?
Z V P
The name of the floating rate index

‘EONA’ - EONIA
‘EONS’ - EONIA SWAP
‘EURI’ - EURIBOR
‘EUUS’ – EURODOLLAR
‘EUCH’ - EuroSwiss
‘GCFR’ - GCF REPO
‘ISDA’ - ISDAFIX
’LIBI’ - LIBID
‘LIBO’ - LIBOR
‘MAAA’ – Muni AAA The floating rate of leg 1 and leg 2 must take either:
‘PFAN’ - Pfandbriefe (1) one of a set of "4 alphabetic character" codes provided by
‘TIBO’ - TIBOR If field 2.2 (Asset class) is populated with ESMA in the annex ITS as the name OR
‘STBO’ - STIBOR (2) if a relevant "4 alphabetic character" code is not included
"IR", at least one of the following fields shall
‘BBSW’ - BBSW in the INDEX list for the given floating rate, report the official
An indication of the interest rates used ‘JIBA’ - JIBAR be populated: 2.7, 2.39, 2.55. name as assigned by the index provider up to 25 As per EMIR Q&A, TR Question 53, the reference rate €STR is not
Only one of the fields 2.39 and 2.55 can be
2 55 Section 2f - Floating rate of leg 1 which are reset at predetermined intervals ‘BUBO’ - BUBOR C O - - O - - C C O - - O - N alphanumerical characters. No best practice prepared for this field currently an available value within the ITS, but is to be reported in the
Interest Rates by reference to a market reference rate, if ‘CDOR’ - CDOR populated. See file 'floating rate index documentation.v2'
free-text field as "ESTR", i.e. the 4-letter code assigned to €STR in the
When populated, this field shall contain up to
applicable ‘CIBO’ - CIBOR The reference rate €STR is to be reported as free-text as ISO 20022 standard.
25 alphanumerical characters where any
‘MOSP’ - MOSPRIM character is allowed. "ESTR".
‘NIBO’ - NIBOR
‘PRBO’ - PRIBOR See 'floating rate index documentation.v2' document for a
‘TLBO’ - TELBOR list of mappings between reference rates not included in the
‘WIBO’ – WIBOR Index list and the relevant value to be reported.
‘TREA’ – Treasury
‘SWAP’ – SWAP
‘FUSW’ – Future SWAP
Or up to 25 alphanumerical characters if the
reference rate is not included in the above list
Time period describing reference period,

whereby the following abbreviations apply:
be populated and shall contain only one of
2 56 Section 2f - Floating rate reference period leg 1 – time Time period describing the reference Y = Year C O - - O - - C C O - - O - the following values: "Y", "M", W" or "D". 1 N No best practice prepared for this field No best practice prepared for this field
Interest Rates period period for the floating rate of leg 1 M = Month
D = Day

Multiplier of the time period describing the Integer multiplier of the time period
2 57 Section 2f - Floating rate reference period leg 1 – reference period for the floating rate of leg The name of
describing thethe floating period.
reference rate index C O - - O - - C C O - - O - be populated and shall contain up to 3 N No best practice prepared for this field No best practice prepared for this field
Interest Rates multiplier ‘EONA’ numerical characters.
1 Up to 3 -numerical
EONIA characters.
‘EONS’ - EONIA SWAP Otherwise the field shall be left blank.
‘EURI’ - EURIBOR
‘EUUS’ – EURODOLLAR
‘EUCH’ - EuroSwiss
‘GCFR’ - GCF REPO
‘ISDA’ - ISDAFIX
’LIBI’ - LIBID
‘LIBO’ - LIBOR
‘MAAA’ – Muni AAA The floating rate of leg 1 and leg 2 must take either:
‘PFAN’ - Pfandbriefe (1) one of a set of "4 alphabetic character" codes provided by
‘TIBO’ - TIBOR If field 2.2 (Asset class) is populated with "IR" ESMA in the annex ITS as the name OR
‘STBO’ - STIBOR (2) if a relevant "4 alphabetic character" code is not included
and field 2.1 (Contract type) is populated
‘BBSW’ - BBSW in the INDEX list for the given floating rate, report the official
An indication of the interest rates used with "SW" or "ST", one of the following fields name as assigned by the index provider up to 25 As per EMIR Q&A, TR Question 53, the reference rate €STR is not
‘JIBA’ - JIBAR shall be populated: 2.40 or 2.58. The other
2 58 Section 2f - Floating rate of leg 2 which are reset at predetermined intervals ‘BUBO’ - BUBOR C O - - O - - C C O - - O - N alphanumerical characters. No best practice prepared for this field currently an available value within the ITS, but is to be reported in the
Interest Rates by reference to a market reference rate, if ‘CDOR’ - CDOR field shall be left blank. See file 'floating rate index documentation.v2'
free-text field as "ESTR", i.e. the 4-letter code assigned to €STR in the
When populated, this field shall contain up to
applicable ‘CIBO’ - CIBOR The reference rate €STR is to be reported as free-text as ISO 20022 standard.
25 alphanumerical characters where any
‘MOSP’ - MOSPRIM character is allowed. "ESTR".
‘NIBO’ - NIBOR
‘PRBO’ - PRIBOR See 'floating rate index documentation.v2' document for a
‘TLBO’ - TELBOR list of mappings between reference rates not included in the
‘WIBO’ – WIBOR Index list and the relevant value to be reported.
‘TREA’ – Treasury
‘SWAP’ – SWAP
‘FUSW’ – Future SWAP
Or up to 25 alphanumerical characters if the
reference rate is not included in the above list
Time period describing reference period,

whereby the following abbreviations apply:
Section 2f - Floating rate reference period leg 2 – time Time period describing the reference Y = Year be populated and shall contain only one of
2 59 C O - - O - - C C O - - O - the following values: "Y", "M", W" or "D". 1 N No best practice prepared for this field No best practice prepared for this field
Interest Rates period period for the floating rate of leg 2 M = Month
D = Day

Multiplier of the time period describing the Integer multiplier of the time period be populated and shall contain up to 3
2 60 Section 2f - Floating rate reference period leg 2 – C O - - O - - C C O - - O - N No best practice prepared for this field No best practice prepared for this field
Interest Rates multiplier reference period for the floating rate of leg describing the reference period. numerical characters.
2 Up to 3 numerical characters. Otherwise the field shall be left blank.
If populated this field shall contain ISO 4217

Section 2g – The cross currency, if different from the ISO 4217 Currency Code, 3 alphabetical Currency Code (official list only), 3
2 61 Foreign Delivery currency 2 C O - - O - - C C O - - O - N No best practice prepared for this field No best practice prepared for this field
currency of delivery character code alphabetical characters.
Exchange

"CU" then at least one field out of fields 2.62
and 2.63 shall be populated.
Up to 10 numerical digits including decimals. When populated, this field shall contain up to
For FX, the validation rules state that at least one of Table 2 Fields 62
Section 2g – The exchange rate as of the date and time The decimal mark is not counted as a 10 numerical digits including decimals. FX products: and 63 should be populated. As both are matching fields, it is important
when the contract was concluded.. It shall numerical character. If populated, it shall be The decimal mark is not counted as a
2 62 Foreign Exchange rate 1 C O - - O - - C C O - - O - Y No best practice prepared for this field that there is consistency as to which should be populated. It is therefore
be expressed as a price of base currency in represented by a dot. numerical character. If populated, it shall be For FX products populate "Exchange Rate 1" and leave
Exchange the quoted currency. The negative symbol, if populated, is not represented with a dot. "Forward Exchange Rate" blank. suggested that counterparties should use only "Exchange Rate 1" and
leave "Forward Exchange Rate" blank.
counted as a numerical character. Negative values are allowed. The negative

"CU" then at least one field out of fields 2.62
and 2.63 shall be populated.
Up to 10 numerical digits including decimals. When populated, this field shall contain up to
For FX, the validation rules state that at least one of Table 2 Fields 62
Section 2g – Forward exchange rate as agreed between The decimal mark is not counted as a 10 numerical digits including decimals. FX products: and 63 should be populated. As both are matching fields, it is important
the counterparties in the contractual numerical character. If populated, it shall be The decimal mark is not counted as a
2 63 Foreign Forward exchange rate C O - - O - - C C O - - O - Y No best practice prepared for this field that there is consistency as to which should be populated. It is therefore
agreement It shall be expressed as a price represented by a dot. numerical character. If populated, it shall be For FX products populate "Exchange Rate 1" and leave
Exchange of base currency in the quoted currency. The negative symbol, if populated, is not represented with a dot. "Forward Exchange Rate" blank. suggested that counterparties should use only "Exchange Rate 1" and
leave "Forward Exchange Rate" blank.
counted as a numerical character. Negative values are allowed. The negative
Validations
that date.
Is itTrade level
it Mandatory,
N given
M E action
C R type?
Z V P N given
M E action
C R type?
Z V P

"CU", this field shall be populated and shall
Section 2g – Two ISO 4217 currency codes separated by contain ISO 4217 Currency Code (official list
“/”. First currency code shall indicate the
2 64 Foreign Exchange rate basis Quote base for exchange rate C O - - O - - C C O - - O - only, 3 alphabetical characters) followed by Y No best practice prepared for this field No best practice prepared for this field
base currency, and the second currency code
Exchange shall indicate the quote currency. slash ("/") followed by ISO 4217 Currency
Code (official list only, 3 alphabetical
characters).
AG = Agricultural
EN = Energy
Section 2h - 'If field 2.2 is populated with "CO", this field
Commodities FR = Freights shall be populated and shall contain only one
Indicates the type of commodity underlying ME = Metals
2 65 and emission Commodity base C O - - O - - C C O - - O - of the following values: "AG", "EN", "FR", Y No best practice prepared for this field No best practice prepared for this field
allowances the contract IN = Index "ME", "IN", "EV", "EX", "OT". 2 alphabetical
EV = Environmental
(General) characters.
EX = Exotic
OT = Other
Agricultural
GO = Grains oilseeds 'If field 2.65 is populated with "AG", this field
DA = Dairy shall be populated and shall contain only one
LI = Livestock of the following values: "GO", "DA", "LI",
FO = Forestry "FO", "SO", "SF" or "OT". 2 alphabetical
SO = Softs characters.
SF = Seafood If field 2.65 is populated with "EN", this field
OT = Other shall be populated and shall contain only one
Energy of the following values: "OI", "NG", "CO",
OI = Oil "EL", "IE" or "OT". 2 alphabetical characters.
NG = Natural gas If field 2.65 is populated with "FR", this field
Section 2h -
Commodities CO = Coal shall be populated and shall contain only one
Details of the particular commodity beyond EL = Electricity of the following values: "DR" , "WT" or "OT".
2 66 and emission Commodity details C O - - O - - C C O - - O - Y No best practice prepared for this field No best practice prepared for this field
allowances field 65 IE = Inter-energy 2 alphabetical characters.
OT = Other If field 2.65 is populated with "ME", this field
(General)
Freights shall be populated and shall contain only one
DR = Dry of the following values: "PR" or "NP". 2
WT = Wet alphabetical characters.
OT = Other If field 2.65 is populated with "EV", this field
Metals shall be populated and shall contain only one
PR = Precious of the following values: "WE" , "EM" or "OT".
NP = Non-precious 2 alphabetical characters.
Environmental If field 2.65 is populated with "IN", "EX" or
WE = Weather "OT", this field shall be left blank.
EM = Emissions
OT = Other
If field 2.66 is populated with "NG" or "EL" ,

this field shall be populated and shall contain
Section 2h - -an EIC code as specified in the EIC code list
Commodities and pertaining to a delivery point within the
2 67 Delivery point or zone Delivery point(s) of market area(s) EIC code, 16 character alphanumeric code C O - - O - - C C O - - O - N No best practice prepared for this field No best practice prepared for this field
and emission European Union. or
allowances Repeatable field. - 16 alphanumerical characters
(Energy) XXXXXXXXXXXXXXXX if the delivery point is
not within the European Union.
If field 2.66 is populated with "NG" or "EL" ,

this field shall be populated and shall contain
-an EIC code as specified in the EIC Area
Section 2h -
Codes (Z) code list and pertaining to a
Commodities Identification of the border(s) or border interconnection point within the European
2 68 and emission Interconnection Point EIC code, 16 character alphanumeric code C O - - O - - C C O - - O - N No best practice prepared for this field No best practice prepared for this field
point(s) of a transportation contract Union, or
allowances
(Energy) - 16 alphanumerical characters
XXXXXXXXXXXXXXXX if the interconnection
point is not within the European Union..
BL = Base Load
If field 2.67 or 2.68 is populated with EIC
Section 2h - PL = Peak Load
code, this field shall be populated and shall
Commodities OP = Off-Peak contain one of the following values: "BL",
2 69 and emission Load type Identification of the delivery profile BH = Hour/Block Hours C O - - O - - C C O - - O - N No best practice prepared for this field No best practice prepared for this field
"PL", "OP", "BH", "SH", "GD" or "OT". 2
allowances SH = Shaped alphabetical characters.
(Energy) GD = Gas Day
OT = Other
Section 2h - If field 2.67 or 2.68 is populated with EIC

code, this field shall be populated in a
Commodities
2 70 Load delivery intervals The time interval for each block or shape hh:mmZ C O - - O - - C C O - - O - common input format: hh:mmZ. N No best practice prepared for this field No best practice prepared for this field
and emission Otherwise the field shall be left blank.
allowances
(Energy)

Section 2h - code, this field shall be populated in a
Commodities ISO 8601 date in the UTC time format YYYY- common input format: YYYY-MM-
2 71 and emission Delivery start date and time Start date and time of delivery C O - - O - - C C O - - O - DDThh:mm:ssZ. N No best practice prepared for this field No best practice prepared for this field
MM-DDThh:mm:ssZ
allowances Otherwise the field shall be left blank.
(Energy) This field is repeatable.

code, this field shall be populated in a
Section 2h - common input format: YYYY-MM-
DDThh:mm:ssZ.
Commodities
2 72 and emission Delivery end date and time End date and time of delivery ISO 8601 date in the UTS time format YYYY- C O - - O - - C C O - - O - The value of this field shall be greater than N No best practice prepared for this field No best practice prepared for this field
MM-DDThh:mm:ssZ the value of field 2.71 (Delivery start date
allowances
and time)
(Energy) Otherwise the field shall be left blank.
Validations
that date.
Is itTrade level
it Mandatory,
N given
M E action
C R type?
Z V P N given
M E action
C R type?
Z V P
N=Minutes
H= Hour
Section 2h - D= Day code, this field shall be populated and shall
contain one of the following values: "N", "H",
Commodities W=Week
2 73 and emission Duration The duration of the delivery period M=Month C O - - O - - C C O - - O - "D", "W", "M", "Q", "S", "Y" or "O". 1 N No best practice prepared for this field No best practice prepared for this field
alphabetical character.
allowances Q = Quarter
(Energy) S= Season This field is repeatable.
Y= Annual
O=Other
WD = Weekdays
WN = Weekend
MO = Monday If field 2.67 or 2.68 is populated with EIC
Section 2h - TU = Tuesday code, this field shall be populated and shall
Commodities WE = Wednesday contain one of the following values: "WD",
2 74 and emission Days of the week The days of the week of the delivery TH = Thursday C O - - O - - C C O - - O - "WN", "MO", "TU", "WE", "TH", "FR", "SA", N No best practice prepared for this field No best practice prepared for this field
allowances FR = Friday "SU". 2 alphabetical character.
(Energy) SA = Saturday Otherwise the field shall be left blank.
SU = Sunday This field is repeatable.
Multiple values separated by "/ " are
permitted

contain up to 20 numerical digits including up
to 19 decimals.
Up to 20 numerical digits including decimals
Section 2h - The decimal mark is not counted as a
The decimal mark is not counted as a
Commodities Delivery capacity for each delivery interval numerical character. If populated, it shall be numerical character. If populated, it shall be
2 75 and emission Delivery capacity C O - - O - - C C O - - O - represented with a dot. N No best practice prepared for this field No best practice prepared for this field
specified in field 70 represented by a dot.
allowances Negative values are allowed. The negative
(Energy) The negative symbol, if populated, is not symbol, if populated, is not counted as a
KW
KWh/h
KWh/d If field 2.67 or 2.68 is populated with EIC
MW
MWh/h
Section 2h - MWh/d contain one of the following values: "KW",
Commodities Daily or hourly quantity in MWh or kWh/d "KWh/h", "KWh/d", "MW", "MWh/h",
2 76 Quantity Unit GW C O - - O - - C C O - - O - N No best practice prepared for this field No best practice prepared for this field
and emission which corresponds to the underlying GWh/h "MWh/d", "GW", "GWh/h", "GWh/d",
allowances commodity "Therm/d", "KTherm/d", "MTherm/d",
GWh/d
(Energy) "cm/d" or "mcm/d".
Therm/d Otherwise the field shall be left blank.
KTherm/d
MTherm/d
cm/d
mcm/d

contain up to 20 numerical digits including up
to 19 decimals.
Section 2h - decimals. The decimal mark is not counted as a
Commodities The decimal mark is not counted as a
2 77 Price/time interval quantities If applicable, price per quantity per delivery C O - - O - - C C O - - O - numerical character. If populated, it shall be N No best practice prepared for this field No best practice prepared for this field
and emission time interval numerical character. If populated, it shall be represented with a dot.
allowances represented by a dot.
(Energy) The negative symbol, if populated, is not
counted as a numerical character. symbol, if populated, is not counted as a
Indication as to whether the derivative

contract is a call (right to purchase a
specific underlying asset) or a put (right to
sell a specific underlying asset) or whether
it cannot be determined whether it is a call
or a put at the time of execution of the
derivative contract.
In case of swaptions it shall be: P = Put If field 2.1 (Contract type) is populated with
Section 2i - C = Call "OP" or "ST" this field shall be populated and
2 78 Option type - “Put”, in case of receiver swaption, in C O - - O - - C C O - - O - Y No best practice prepared for this field No best practice prepared for this field
Options O = where it cannot be determined whether shall contain one of the following values: "P",
which the buyer has the right to enter into it is a call or a put "C" or "O". 1 alphabetical character.
a swap as a fixed-rate receiver.
-“Call”, in case of payer swaption, in which
the buyer has the right to enter into a swap
as a fixed-rate payer.
In case of Caps and Floors it shall be:
-“Put”, in case of a Floor.
-“Call”, in case of a Cap.
Indicates whether the option may be A = American If field 2.1 (Contract type) is populated with Reasoning for CapFloors to be reported as "E" is that such products
exercised only at a fixed date (European, B = Bermudan "OP" or "ST" this field shall be populated and This field is populated in line with the information would report field 2.1 (Contract Type) as "OP" and therefore it is
Section 2i -
2 79 Option exercise style and Asian style), a series of pre-specified E = European C O - - O - - C C O - - O - shall contain one of the following values: Y For Caps and Floors, populated with "E" (European) contained in the exchange documentation/CCP file or required to populate the Option exercise style. While a CapFloor would
Options dates (Bermudan) or at any time during the S = Asian "A", "B", "E" ,"S", "AS", "BS" or "ES". Up to 2 static data provider. not have an exercise style, there is no option to report 'Other'.
life of the contract (American style) More than one value is allowed alphabetical characters. Therefore, best practice is be to report as European "E".
If field 2.1 (Contract type) is populated with

"OP" or "ST" this field shall be populated and
decimals. shall contain up to 20 numerical digits
including up to 19 decimals.
numerical character. If populated, it shall be numerical character. If populated, it shall be
Section 2i - represented by a dot. This field shall be populated with the strike price as
2 80 Strike price (cap/floor rate) The strike price of the option. C O - - O - - C C O - - O - represented with a dot. Y No best practice prepared for this field
Options The negative symbol, if populated, is not Negative values are allowed. The negative quoted in major units.
Where the strike price is reported in percent
values, it should be expressed as percentage numerical character.
"999999999999999.99999" is accepted when
where 100% is represented as “100”
the actual value is not available

U = Units
Section 2i - The manner in which the strike price is "OP" or "ST" this field shall be populated and
2 81 Strike price notation P = Percentage C O - - O - - C C O - - O - Y No best practice prepared for this field No best practice prepared for this field
Options expressed Y = Yield shall contain one of the following values: "U",
"P" or "Y". 1 alphabetical character.

2 82 Section 2i - Maturity date of the underlying In case of swaptions, maturity date of the ISO 8601 date in the format YYYY-MM-DD C O - - O - - C C O - - O - Y No best practice prepared for this field No best practice prepared for this field
Options underlying swap "ST" this field shall be populated in a
Validations
that date.
Is itTrade level
it Mandatory,
N given
M E action
C R type?
Z V P N given
M E action
C R type?
Z V P
SNDB = Senior, such as Senior Unsecured

Debt (Corporate/Financial), Foreign Currency
Sovereign Debt (Government),
Section 2j – Information on the seniority in case of SBOD = Subordinated, such as Subordinated
2 83 Credit Seniority contract on index or on a single name or Lower Tier 2 Debt (Banks), Junior C O - - O - - C C O - - O - "CR", this field shall be populated and shall Y No best practice prepared for this field No best practice prepared for this field
contain one of the following values: "SNDB",
derivatives entity Subordinated or Upper Tier 2 Debt (Banks),
"SBOD" or "OTHR". 4 alphabetical characters.
OTHR = Other, such as Preference Shares or
Tier 1 Capital (Banks) or other credit
derivatives

"CR", one of the fields 2.7 or 2.84 shall be
populated.
When populated, this field shall contain:
ISO 3166 - 2 character country code -valid ISO 3166 code - 2 alphabetical
or characters, or
ISO 3166-2 - 2 character country code -valid ISO 3166-2 code - 2 alphabetical
Section 2j – Identification of the underlying reference followed by dash “-“ and up to 3 characters followed by dash ("-"), followed by
2 84 Credit Reference entity alphanumeric character country subdivision C O - - O - - C C O - - O - up to 3 alphanumerical characters, or N No best practice prepared for this field No best practice prepared for this field
entity
derivatives code -a valid LEI included in the GLEIF database
or maintained by the Central Operating Unit.
ISO 17442 Legal Entity Identifier (LEI) 20 The status of the LEI shall be "Issued",
alphanumerical character code "Lapsed", "Pending transfer" or "Pending
archival".
XXXXXXXXXXXXXXXXXX99 can be reported for
non-EEA entities that do not have LEI.

MNTH = Monthly
Section 2j – The frequency of payment of the interest QURT = Quarterly "CR", this field shall be populated and shall
2 85 Credit Frequency of payment C O - - O - - C C O - - O - contain one of the following values: "MNTH", Y No best practice prepared for this field No best practice prepared for this field
rate or coupon MIAN = Semi-annually
derivatives YEAR = Yearly "QURT", "MIAN" or "YEAR". 4 alphabetical
characters.

"CR", this field shall be populated and shall
Section 2j – Numerator and Denominator are numerical contain only numerical characters or word
2 86 Credit The calculation basis The calculation basis of the interest rate C O - - O - - C C O - - O - "Actual" followed by slash followed by N No best practice prepared for this field No best practice prepared for this field
characters or alphabetic expression ‘Actual’,
derivatives e.g. 30/360 or Actual/365 numerical characters or word "Actual". Up to
13 characters.

Section 2j – "CR"and field, 2.7 (Underlying identification
The series number of the composition of
2 87 Credit Series Integer field up to 5 characters C O - - O - - C C O - - O - type) is populated with "X", this field shall be Y No best practice prepared for this field No best practice prepared for this field
the index if applicable
derivatives populated with a positive integer value. Up
to 5 numerical characters.
A new version of a series is issued if one of If field 2.2 (Asset class) is populated with
Section 2j – the constituents defaults and the index has "CR"and field, 2.7 (Underlying identification
2 88 Credit Version to be re-weighted to account for the new Integer field up to 5 characters C O - - O - - C C O - - O - type) is populated with "X", this field shall be Y No best practice prepared for this field No best practice prepared for this field
derivatives number of total constituents within the populated with a positive integer value. Up
index to 5 numerical characters.

It is noted that the valuation rules allow for a value between 0-100
"CR"and field, 2.7 (Underlying identification which implies the index factor is reported as a percentage, however
Up to 10 numerical characters including type) is populated with "X", this field shall be
standard market practice is to represent Index Factor as a decimal.
The factor to apply to the Notional (Field decimals. populated with a value between 0 and 100 (0
Section 2j – 20) to adjust it to all the previous credit The decimal mark is not counted as a and 100 inclusive). Up to 10 numerical digits Report as a decimal, e.g. an index factor of 95% is reported Furthermore, reporting as a percentage is inconsistent with how similar
2 89 Credit Index factor C O - - O - - C C O - - O - Y No best practice prepared for this field fields are formatted/reported, e.g. Attachment Point and Detachment
events in that Index series. numerical character. If populated, it shall be including up to 9 decimals. as '0.95', an index factor of 70% is reported as '0.7', etc.
derivatives The figure varies between 0 and 100. represented by a dot. The decimal mark is not counted as a Point are to be reported as a decimal, i.e. values of 0-1.
numerical character. If populated, it shall be
For consistency with market practice and to align with other similar
represented with a dot. fields, members agreed to report as a decimal as standard practice.

Section 2j –
Indication whether a derivative contract is T= Tranched "CR", this field shall be populated and shall
2 90 Credit Tranche C O - - O - - C C O - - O - Y No best practice prepared for this field No best practice prepared for this field
derivatives tranched. U=Untranched contain one of the following values: "T" or
"U". 1 alphabetical character.
If field 2.90 (Tranche) is populated with "T",

this field shall be populated with a value
Up to 10 numerical characters including between 0 and 1 (0 and 1 inclusive). Up to 10
decimals expressed as a decimal fraction numerical digits including up to 9 decimals.
Section 2j –
2 91 Attachment point The point at which losses in the pool will between 0 and 1. C O - - O - - C C O - - O - The decimal mark is not counted as a Y No best practice prepared for this field No best practice prepared for this field
Credit attach to a particular tranche The decimal mark is not counted as a numerical character. If populated, it shall be
derivatives
represented by a dot. If field 2.90 (Tranche) is populated with "U",
this field shall be left blank.
If field 2.90 (Tranche) is populated with "T",

this field shall be populated with a value
Up to 10 numerical characters including between 0 and 1 (0 and 1 inclusive). Up to 10
decimals expressed as a decimal fraction numerical digits including up to 9 decimals.
Section 2j –
2 92 Detachment point The point beyond which losses do not between 0 and 1. C O - - O - - C C O - - O - The decimal mark is not counted as a Y No best practice prepared for this field No best practice prepared for this field
Credit affect the particular tranche The decimal mark is not counted as a numerical character. If populated, it shall be
derivatives
represented by a dot. If field 2.90 (Tranche) is populated with "U"
this field shall be left blank.
Validations
that date.
Is itTrade level
it Mandatory,
N given
M E action
C R type?
Z V P N given
M E action
C R type?
Z V P
— a derivative contract for the first time, in
which case it will be identified as ‘new’;
— a modification to the terms or details of
a previously reported derivative contract,
but not a correction of a report, in which
case it will be identified as ‘modify’. This
includes an update to a previous report
that is showing a position in order to reflect
new trades included in that position.;
— a cancellation of a wrongly submitted This field shall contain one of the following
entire report in case the contract never values: "N", "M", "E", "C", "R", "Z", "V" or "P".
came into existence or was not subject to 1 alphabetical character.
Regulation (EU) No 648/ 2012 reporting The first report received for given UTI by the
requirements but was reported to a Trade reporting counterparty shall only contain
Repository by mistake, in which case, it will value "N" or "P" in this field. If the first report
N = New
be identified as ‘error’; for a given UTI by the counterparty is with
— an early termination of an existing M = Modify
E = Error action types "M", "E", "C", "R", "Z" or "V" it
Section 2k - contract, in which case it will be identified shall be rejected.
2 93 C = Early Termination
Modifications Action type as ‘early termination’; R = Correction
MMMMMMMM MMMMM M Only one report with the action type "New" N No best practice prepared for this field No best practice prepared for this field
to the contract - a previously submitted report contains for a given combination of Counterparty ID-
Z = Compression
erroneous data fields, in which case the ID of the other counterparty-Trade ID shall
report correcting the erroneous data fields V = Valuation update be accepted.
P = Position component
of the previous report shall be identified as After a report with action type "E" is
‘correction’; submitted, the only allowed action type to be
— a compression of the reported contract, submitted by the other counterparty, if
in which case it will be identified as reporting to the same TR, is "E". No
‘compression’; additional reports shall be allowed for that
— an update of a contract valuation or UTI.
collateral, in which case it will be identified
as ‘valuation update’;
— a derivative contract that is to be
reported as a new trade and also included
in a separate position report on the same
day, in which case it will be identified as a
‘position component’. This value will be
equivalent to reporting a new trade
followed by an update to that report
Indication whether the report is done at

trade or position level.
Section 2k - Position level report can be used only as a
2 94 T = Trade This field shall contain one of the following
Modifications Level supplement to trade level reporting to MM O O M O O M MM O O M O N No best practice prepared for this field No best practice prepared for this field
to the contract report post-trade events and only if P = Position values: "T" or "P".
individual trades in fungible products have
been replaced by the position.
*Fields 67 – 77 apply only to derivative contracts related to Natural Gas and Electricity delivered in the EU.
*Fields 70 - 77 are repeatable
EMIR fields
RTS 22 fields Last Review
NB: this may contradict MiFIR approach
Instrument
Product identification
Number Scenario Instrument ToTV? Venue of execution Type
Venue Identificati Comment
(field 2.15) (field 2.5) (field 36) on code
(field 41)
Reportable trade executed on EEA Trading Venue Y MIC of Trading Venue I MIC of Trading Venue I
1 (defined as Regulated Markets, MTFs and OTFs)
Reportable post-trade event of a trade executed on MIC of Trading Venue MIC of Trading Venue to be Post trade events should reflect where the trade was originally
EEA Trading Venue (defined as Regulated Markets, Y I I
to be peristed peristed executed. Therefore the MIC initially reported should be persisted.
2 MTFs and OTFs)
Reportable trade executed on EEA trading venue (i.e. MIC of Trading Venue
Y if available, otherwise I MIC of Trading Venue I Uncapitalised "trading venue" to represent a trade exected on a
multidealer platform) which is not defined as a venue which is not classified as an RM, MTF or OTF.
3 Regulated Markets, MTFs and OTFs) XOFF
MIC of Trading Venue

Post trade events should reflect where the trade was originally
if available to be MIC of Trading Venue to be
Reportable post-trade event of a trade executed on Y I I executed. Therefore the MIC or XOFF, as initially reported, should
persisted, otherwise peristed
EEA trading venue (i.e. multidealer platform) which is XOFF be persisted.
4 not defined as a Regulated Markets, MTFs and OTFs)
MIC of Trading MiFID s/b same as EMIR. i.e. MIC of TV or XOFF

Venue if available,
otherwise XOFF (if EMIR
Iinstrument is ToTV) If a non-EEA venue has a MIC, report the MIC.
If an ISIN is Otherwise, report as "XOFF" (if the instrument is ToTV) or "XXXX" (if the
or XXXX (if MIC of Trading Venue if available
Y available, then report I instrument is not ToTV).
instrument is not otherwise XOFF
"I". Otherwise {blank} There must be the option to report "XXXX" as a product on a non-EEA
ToTV, in which case venue may not have an ISIN and in such circumstances, field 2.5 cannot
an ISIN may be be reported with "I". As per EMIR validation rules, field 2.5 can be blank
provided or may if 2.15 is either (i) populated with the MIC of a non-EEA trading venue
not) (as per ISO 10383) or (ii) populated with "XXXX".
Reportable trade executed on non-EEA trading
5 venue (e.g. US Swaps Execution Facility)
MIC of Trading Venue
MIC of Trading Venue if available Post trade events should reflect where the trade was originally
Reportable post-trade event of a trade executed on Y if available to be I {blank}
to be persisted, otherwise executed. Therefore the MIC or XOFF, as initially reported, should
persisted, otherwise
non-EEA trading venus (e.g. US Swaps Execution XOFF be persisted.
XOFF
6 Facility)
Reportable post-trade event of a trade executed on If the product cannot be traded on a venue, report as "XXXX".
non-EEA trading venus (e.g. US Swaps Execution N XXXX {blank} XXXX {blank}
7 Facility). LCH will populate the ISIN if available
EMIR - "XOFF" (For EMIR purposes, it is an OTC transction so not

Y I MIC of SI I executed on a venue).
XOFF
Reportable trade executed on Systematic MiFID s/b "MIC of SI"

8 Internaliser
Reportable trade executed on Systematic N XXXX {blank} XXXX {blank} If the product cannot be traded on a venue, report as "XXXX".
9 Internaliser
Post trade events should reflect where the trade was originally
Reportable post-trade event of a trade executed on Y XOFF I MIC of SI I executed. Therefore the MIC initially reported should be persisted
10 Systematic Internaliser for MiFID. EMIR value would remain as XOFF.
If the product cannot be traded on a venue, report as "XXXX".
Reportable post-trade event of a trade executed on N XXXX {blank} XXXX {blank}
11 Systematic Internaliser. LCH will populate the ISIN if available
Reportable post trade event (decrease of position) MiFID s/b MIC of the SI or "XOFF".
MIC of SI if available, otherwise
effected by post trade service not on EEA Trading Y XOFF I I
XOFF
12 Venue EMIR no change
EMIR & MiFID. If the product can be traded on a venue, report as

Y XOFF I XOFF I "XOFF".
Reportable trade executed off-venue, post-trade
13 events NB. LCH will populate the ISIN if available
Reportable trade executed off-venue, post-trade N XXXX {blank} XXXX {blank} EMIR & MiFID. If the product cannot be traded on a venue, report as "XXXX".
14 events
EMIR -
The Beta / Gamma trades will reflect the Venue of Execution value
Retain Venue of
of the Alpha Trade. This conclusion has been made based on an
Execution value of the FCA interpretation that regulators want to know where the original
alpha trade, i.e. MIC of execution took place, regardless of it being the cleared trade that
Trading Venue. is being reported.
Y Post-cleared events: I N/A {blank} Subsequent post-trade events are to persist the value of Venue of
persist the VofE value Exercise, except for compression events (resulting in a new trade
except following a and UTI), where "XXXX" is to be populated.
compression event See scenario 20 for the reasoning why Venue of Execution is
which is reported as populated as "XXXX" for trades resulting from a compression
"XXXX"
event.
Reportable Cleared trade (Beta trade post clearing)-
15 executed on EEA Trading Venue MiFID - Cleared trades aren't reportable under MiFID
Retain Venue of
Execution value of the
alpha trade: "XOFF"
EMIR - see scenario 15
Y Post-cleared events: I N/A {blank}
persist the VofE value
except following a MiFID - Cleared trades aren't reportable under MiFID
compression event
which is reported as
Reportable Cleared trade (Beta trade post "XXXX"
16 clearing) - executed off venue
Retain Venue of
alpha trade.
Post-cleared events:
Y I N/A {blank}
persist the VofE value
compression event
17 clearing) - non EEA venue
Retain Venue of
alpha trade: "XOFF"
Post-cleared events:
Y persist the VofE value
I N/A {blank}
compression event
18 clearing) - executed on Systematic Internaliser
NB. In this scenario, the alpha trade would have been reported as
N XXXX {blank} N/A {blank} "XXXX"
Reportable Cleared trade (Beta trade post MiFID - Cleared trades aren't reportable under MiFID
19 clearing) - executed on Systematic Internaliser
When a compression event occurs, a CCP may be compressing trades

executed on different venues, e.g. a compression where Trade A was
executed on venue ABC and Trade B was executed on venue DEF. The
resulting trade would not have a single meaningful execution venue. As
"I" (if ISIN is availale), such, the Venue of Execution is reported as "XXXX".
NA XXXX otherwise N/A {blank} NB 1. The Venue of Execution field is not a matching field for
{blank} compression trades.
NB 2. Populate the ISIN if available

Reportable Cleared trade (Beta trade post MiFID - Cleared trades aren't reportable under MiFID
clearing) - resulting from compression or other
20 lifecycle event
Scenario
Post Triggers new
Related trades in
Event Type Trade UTI
flow
Event? generation?
New Trade n/a No Yes
Amendment - non-economic (correction to the trade

for any reportable trade attribute that does not affect n/a No No
the price)
Amendment - economic (bilaterally negotiated change

to the trade for any trade attribute that affects the n/a Yes No
price)
Amendment - economic (bilaterally negotiated change

to the trade for any trade attribute that that is Part 43 n/a Yes No
reportable but does not affect the price)
Cancel (trade booked in error) n/a No No
Original
Unallocated No Yes
Trade Allocated “Block” Trade
Yes (one per
Allocated Trades Yes
allocation)
Original Bilateral
No Yes
Trade "alpha"
Cleared Positions
Yes (one for
("beta" and Yes
each)
Cleared Positions "gamma")
Original
Unallocated No Yes
“Block” Trade
Block cleared pre-

Yes Yes
allocation
Post-clearing Yes (for each

Yes
allocations new trade)
Termination / Unwind (with fee) n/a Yes No
Termination / Unwind (no fee) n/a Yes No
Partial Termination / Partial Unwind / Partial Decrease

n/a Yes No
(with fee)
Partial Termination / Partial Unwind / Partial Decrease
n/a Yes No
(no fee)
Increase / Decrease (with fee) n/a Yes No
Increase / Decrease (no fee) n/a Yes No
Original Trade (b/t

Transferor and No Yes
Remaining Party)
Full or Partial Novation

Novated Trade (b/t
Full or Partial Novation Transferee and Yes Yes
Remaining Party)
Fee Trade (b/t
Transferor and Yes Yes
Transferee)
Original Trade (b/t
Transferor 1 and No Yes
Remaining Party)
Novated Trade (b/t
Full or Partial Novation – 4 way Transferee 1 and Yes Yes
Transferee 2)
Fee Trade (b/t
Transferor 1 and Yes Yes
Transferee 1)
Original Option No Yes
Exercise New Swap

(resulting from
No Yes
Physically Settled
option)
EB-client execution No n/a
EB: PB leg No Yes

Prime Brokerage (Off-facility)
PB: Client leg No Yes

Rename No No
Succession Events on Reference Entity for CDS

Yes (for each
Reorganizations No
new trade)
Bankruptcy /
Failure to Pay / Yes No
Other
Restructuring - Full
Yes No
Trigger
Restructuring -
Partial Trigger - Yes No
original trade
Restructuring -
Partial Trigger -
new trade
Yes Yes
(remaining
untriggered
notional)
Credit Events
Credit Events
Restructuring -
Partial Trigger -
Yes Yes
new trade (triggered
notional)
Original Trade -
Yes No
Terminated
Original Trade
Amendment - Yes No
Increase
Original Trade
Amendment - Yes No
Decrease
Compression Events
New Trade Yes Yes
CCP: Position Transfer (i.e. transfer of a trade

n/a Yes Yes
between Clearing Members)
CCP: Compression n/a Yes Yes

Post-priced swaps n/a No Yes
Yes (one or
Package Transactions n/a No
multiple)
*These columns are based on the stated intention of DTCC to add a separate field to capture original
execution timestamp. These columns reflect WG thoughts on how execution timestamp might be
reflected in a two-field approach, but are subject to further information from DTCC and further WG
consideration.
EMIR
Execution Timestamp
Comment
Date&Time trade
agreed
Date&Time [original]
trade agreed
trade agreed
trade agreed
trade agreed
Date&Time block
trade agreed
Date&Time block Bank of England guidance is to report the Execution Date&Time
trade agreed of the original Block trade.
trade agreed
For cleared trades, the Bank of England clarified (verbally) to

CCP's what should be expected for the Venue of execution. It
was BoE's contention that ESMA’s intention was always to
Date&Time [original] receive the MIC of the alpha trade, mechanically therefore
trade agreed forcing the presence of the instrument ISIN into the reporting.
By extension this meant that the execution timestamp should
also be that of the alpha trade. The timestamp of the alpha trade
Date&Time block is received in the clearing request message from the trading
trade agreed platforms or the middleware.
If a CCP does not have an Execution timestamp of the alpha
trade, only then would they use the clearing timestamp.
Date&Time block
accepted to clearing
Date&Time block
trade agreed
trade agreed
trade agreed
trade agreed
trade agreed
trade agreed
trade agreed
trade agreed
Date&Time of
novation consent
n/a
trade agreed
Date&Time of
novation consent
n/a
trade agreed
Date&Time of exercise
n/a
Date&Time of EB-
client execution
Date&Time of PB
acceptance
trade agreed
Date&Time [original] This is a contractual event, and not a lifecycle event. Therefore
trade agreed the 'Date&Time [original] trade agreed' is to be reported.
trade agreed
trade agreed
trade agreed
Date&Time [original] Follow existing EMIR guidance instead of aligning with CFTC
trade agreed for this scenario.
Date&Time [original] Follow existing EMIR guidance instead of aligning with CFTC
trade agreed for this scenario.
trade agreed
trade agreed
trade agreed
Date&Time
compression cycle
completed
Original Date&Time
of acceptance to
clearing
Date&Time
compression cycle
completed
Date&Time contract
agreed
Date&time all
components of
package are known
Best Practice Proposal For Leg 1 / Leg 2 Determination and population of Counterparty Side for EMIR RTS 2.0
Theensure
To below that
tabletrades
showsare
how to determine
reported which for
consistently legmatching
is Leg 1 and the Counterparty
purposes, Side formust
FpML submitters the purposes of 1reporting
submit Leg under
information EMIR
in the firstRTS 2.0swap stream block and Leg 2 information in the second FpML swap stream
FpML
block
Note 1: Where 'higher spread' is used to determine the Buyer / Seller, the higher value is to apply, i.e. if the spreads were '-0.1' and '-0.5', the the higher spread would be '-0.1'.
Note 2: Where the below table fails to determine Buyer then use the tiebreaker logic of Reverse ASCII Sort, first LEI. For the avoidance of doubt, the order is Z, Y, X, W, V, U, T, S, R, Q, P, O, N, M, L, K, J, I, H, G, F,
E, D, C, B, A, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0. The party whose LEI starts with the first value found in the list will be the Payer of Leg 1
Asset Class Base Product Sub- Transaction Type Leg 1 / Leg 2 Proposal Buyer (for Counterparty Side) Seller (for Counterparty Side) Article 3a point Comments
Product
Interest Rate IR Swap Fixed Float Leg 1 = Fixed Leg Payer of Fixed Rate Receiver of Fixed Rate 5
Leg 2 = Float leg
Interest Rate IR Swap Fixed Float OIS As IR Swap Fixed/Float Payer of Fixed Rate Receiver of Fixed Rate 5
Interest Rate IR Swap Fixed Float Zero Coupon As IR Swap Fixed/Float Payer of Fixed Rate Receiver of Fixed Rate 5
Interest Rate IR Swap Fixed Fixed Leg 1 = Higher Fixed Rate Payer of Leg 1 Receiver of Leg 1 5 For example, if both legs have the same Rate,
Leg 2 = Lower Fixed Rate but one leg of the swap has a 3 month
calculation period and the other leg has a 6
If both legs have the same Rate, then: month calculation period, the 3 month period
Leg 1 = Leg with the shortest calculation period will trump the 6 month period. Therefore, Leg
1 would be the leg with the 3 month
calculation period.
'Calculation Period' rather than 'Reset Period'
is used as a Fixed Rate would not be expected
to reset each period.
Interest Rate IR Swap Basis Leg 1 = Leg with the higher spread Payer of Leg 1 Receiver of Leg 1 5 See example under IR Swap Fixed Fixed.
If both legs have the same spread, then:
Leg 1 = Leg with the shortest reset period
Interest Rate IR Swap Basis OIS As IR Swap Basis Payer of Leg 1 Receiver of Leg 1 5
Interest Rate Cross Currency Fixed Float Leg 1 = The currency which appears first when Party receiving (ie paying interest on) the currency which appears Party delivering (ie receiving interest on) the currency which 6 As per ITS Article 3a, paragraph 6, the Buyer
sorted alphabetically by ISO 4217 standard. first when sorted alphabetically by ISO 4217 standard appears first when sorted alphabetically by ISO 4217 standard and Seller for cross currency swaps are to be
determined by ordering the currencies
alphabetically. The Buyer shall be the
counterparty receiving the currency which
appears first, and the Seller shall be the
counterparty delivering the currency which
appears first.
The Leg Alignment best practice is based on
the Buyer/Seller determination, with Leg 1
being the leg of the first currency when sorted
alphabetically, and Leg 2 being the second
currency.
Interest Rate Cross Currency Fixed Fixed Leg 1 = The currency which appears first when Party receiving (ie paying interest on) the currency which appears Party delivering (ie receiving interest on) the currency which 6 As per ITS Article 3a, paragraph 6, the Buyer
appears first.
currency.
Interest Rate Cross Currency Basis Leg 1 = The currency which appears first when Party receiving (ie paying interest on) the currency which appears Party delivering (ie receiving interest on) the currency which 6 As per ITS Article 3a, paragraph 6, the Buyer
appears first.
currency.
Interest Rate Exotic If there is no obvioulsy Buyer/Seller, then: Buyer = Party whose LEI is found first through Tiebreaker Logic Seller = Party whose LEI is found second through Tiebreaker Logic NA Note: It is acepted that the LEI tiebreaker logic
Leg 1 = leg paid by Buyer is not ideal, but for trades where there is an
absense of an obvious Buyer / Seller,
tiebreaker logic is felt to be the best option
available.
Interest Rate Inflation (1) Fixed vx Float then as per IR Swap Fixed/float 1) Payer of Fixed Rate 1) Receiver of Fixed Rate 5
(2) Float vs Float then as per IR Swap Basis 2) See IR Swap Basis 2) See IR Swap Basis
Interest Rate Option Swaption As per the 'Leg 1 / Leg 2 Proposal' applicable to Party who holds the right to exercise the option Receiver of Premium 2
the product type of the underlying swap
Interest Rate Inflation CapFloor N/A Party who holds the right to exercise the option. Receiver of Premium 2 As per RTS Article 3a, paragraph 2, Leg
Alignment for options and swaptions, the
Buyer is identified as the party that holds the
right to exercise and the Seller is the reciever
of premium.
Interest Rate Option Debt Option N/A Party who holds the right to exercise the option Receiver of Premium 2
Interest Rate Forward Debt N/A Buyer of the instrument Seller of the instrument 3
Interest Rate FRA N/A Payer of Fixed Rate Receiver of Fixed Rate 10
Interest Rate CapFloor N/A Party who holds the right to exercise the option Receiver of Premium 2 As per RTS Article 3a, paragraph 2, Leg
Alignment for options and swaptions, the
Buyer is identified as the party that holds the
right to exercise and the Seller is the reciever
of premium.
Article 3a
Counterparty side
1. The counterparty side to the derivative contract referred to in field 14 of Table 1 of the Annex shall be determined in ac
paragraphs 2 to 10.
2. In the case of options and swaptions, the counterparty that holds the right to exercise the option shall be identified as th
counterparty that sells the option and receives a premium shall be identified as the seller.
3. In the case of futures and forwards other than futures and forwards relating to currencies, the counterparty buying the
identified as the buyer and the counterparty selling the instrument shall be identified as the seller.
4. In the case of swaps related to securities, the counterparty that bears the risk of price movement of the underlying secu
the security amount shall be identified as the buyer and the counterparty that pays the security amount shall be identified
5. In the case of swaps related to interest rates or inflation indices, the counterparty paying the fixed rate shall be identifie
the counterparty receiving the fixed rate shall be identified as the seller. In the case of basis swaps, the counterparty that p
shall be identified as the buyer and the counterparty that receives the spread shall be identified as the seller.
6. In the case of cross-currency swaps and swaps and forwards related to currencies, the counterparty receiving the curren
first when sorted alphabetically by International Organization for Standardization (ISO 4217) standard shall be identified as
counterparty delivering that currency shall be identified as the seller.
7. In the case of swaps related to dividends, the counterparty receiving the equivalent actual dividend payments shall be id
buyer and the counterparty paying the dividend and receiving the fixed rate shall be identified as the seller.
8. With the exception of options and swaptions, in the case of derivative instruments for the transfer of credit risk, the cou
the protection shall be identified as the buyer and the counterparty selling the protection shall be identified as the seller.
9. In the case of derivative contracts relating to commodities, the counterparty that receives the commodity specified in th
identified as the buyer and the counterparty that delivers the commodity shall be identified as the seller.
10. In the case of forward-rate agreements, the counterparty paying the fixed rate shall be identified as the buyer and the
receiving the fixed rate shall be identified as the seller.

EMIR Reporting Industry Best Practices Matrix February 2020

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EMIR Reporting Industry Best Practices Matrix February 2020

Uploaded by

Copyright:

Available Formats

Legal Disclaimer

Trade association Email address

XD) of GFMA, the Investment Association (IA), German

istent with other published reporting guidelines, such as

the option to populate the field or not. Specifically, where

-Common input format: YYYY-MM-

For action types "N", "M", "C", "R", "Z", "V"

Shall only contain one of the following

For action types "N", "M","R", "Z", "V" and

This field shall be populated with a valid ISO

When populated, shall contain a valid LEI

In the case where the derivative contract is

“LEI” for ISO 17442 Legal Entity Identifier

The party subject to the rights and

Identifies whether the reporting

Information on whether the contract is

Information whether the reporting

Up to 20 numerical characters including

If field 1.17 is populated, this field shall be

If field 1.17 is populated and field 2.35 is

This field shall be left blank for transaction-level

Whether the collateralisation was

If field 1.22 is populated with "Y", this field

If field 1.24 is populated, this field shall be

If field 1.26 is populated, this field shall be

If field 1.28 is populated, this field shall be

If field 1.30 is populated, this field shall be

If field 1.32 is populated, this field shall be

If field 1.34 is populated, this field shall be

CD = Financial contracts for difference

For products identified through

with (ii) code "XOFF", this field shall be

Otherwise, (i.e. if the field 2.15 is not

The product shall be identified through ISIN

If field 2.2 (Asset class) is populated with

If field 2.7 is populated, this field shall be

This field is only populated for transaction-level and

As per EMIR Q&A TR Answer 47, this field should be

Until global UTI is available and for action

Identifier, internal to the reporting firm to

Until the date of application of [ MiFIR RTS on

The best practice depends on the type of transaction being

• See the 'PriceRate_Price Notation_Quantity' document for

• See the 'PriceRate_Price Notation_Quantity' document for

If field 2.18 is populated with ‘U’ then the

• Report the notional amount at the time of reporting.

• For the avoidance of doubt, a notional change is a

• Zero coupon swaps: Populate with the notional of the

-Up to 20 numerical characters including up

-Up to 20 numerical characters including up

Up to 20 numerical characters including -Up to 20 numerical characters including up

C (Cash): This should be used when the trade is non-

O (Optional for counterparty): This should be used when the

See 'Execution Timestamp' tab for more best practice

• Where an Effective Date is specified in the terms of the

• Although an Optional field, if there is a Maturity Date for

• The unadjusted Maturity Date should be used, unless both

When populated, shall be populated in a

When populated shall be populated in a

Reference to any master agreement, if

If field 2.30 is populated, this field shall be

Cleared trades = "E"

• Y (Non-electronically Confirmed): This should be used if the