EFF EETTEL ECCT TRROO NNIICC U RREEGGULLATTOORRYY … _ Electronic Data Exchange...1 CpML 5.1.1...

EFET eRR – Electronic Regulatory Reporting Standard Version 1.0 o, Feb 2015

of 119

EEFFEETT EELLEECCTTRROONNIICC RREEGGUULLAATTOORRYY RREEPPOORRTTIINNGG

VVEERRSSIIOONN 11 RREELLEEAASSEE 00 ((VV11..00 DDRRAAFFTT OO))

CCRREEAATTEEDD BBYY EEFFEETT


of 119

Revision History

Version Date Changes Author of changes

1.0a August 13 New document EFET eRR WG

1.0b September 13 Draft EFET eRR WG

1.0c October 13 Draft EFET eRR WG

1.0d November 13 Draft EFET eRR WG

1.0e December 13 Draft EFET eRR WG

1.0f January 14 Draft EFET eRR WG

1.0g January 14 Draft EFET eRR WG

1.0h February 14 Draft EFET eRR WG

1.0i April 14 Draft EFET eRR WG

1.0j June 14 Draft EFET eRR WG

1.0k July 14 EMIR specific clarifications EFET eRR WG

1.0l Aug 14 EMIR specific clarifications EFET eRR WG

1.0n Jan 15 EMIR specific clarifications EFET eRR WG

1.0o Feb 15 EMIR specific clarifications EFET eRR WG

References

Reference

ID

Document Name Document

Version.Release

Document

Publishing Date

1 CpML 5.1.1 August 2013

2 EFET Communication eCM v4.0

Profile

1.0 June 2010

3 Official Journal of the European

Union L52

Vol 56 23rd February 2013

4 ACER Recommendations on

REMIT Records of Transactions

A12-AMIT-04-07

23rd October 2012

5 ISDA Unique Trade Identifier

(UTI): Generation,

Communication and Matching

26th June 2013

6 Futures & Options Association

Update Trade Reporting

Obligations Under EMIR

0.1 5th June 2013

7 Trade Reporting User Manual

(Draft)

27th March 2014


of 119

Copyright notice

Copyright © EFET 2015. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that

comment on or otherwise explain it or assist in its implementation may be prepared, copied, published

and distributed, in whole or in part, without restriction of any kind, provided that the above copyright

notice and this paragraph are included on all such copies and derivative works. However, this

document itself may not be modified in any way, such as by removing the copyright notice or

references to EFET except as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by EFET or its

successors.

This document and the information contained herein is provided on an "as is" basis.

EFET DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY

WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY

IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


of 119

Content

1 CURRENT PROCESSES AND BUSINESS REQUIREMENTS ................................................................... 7

1.1 Current Business Processes ......................................................................... 7

1.2 Requirements for Electronic Business Processes ............................................. 7 eRR Business Process Scope ...................................................................................... 7

2 ELECTRONIC BUSINESS PROCESSES – OVERVIEW ........................................................................... 8

2.1 Actors and Roles ........................................................................................ 8 Scope Regulatory Reporting of OTC (Bilateral) Transactions .......................................... 8 Scope of Regulatory Reporting of Cleared Transactions ................................................ 10

2.2 High Level Business Document Flows .......................................................... 13 High Level Flows for Regulatory Reporting of New Bilaterally Settled OTC Transactions .... 13 High Level Flows for Regulatory Reporting of New Cleared Transactions ......................... 16 High Level Flows for Regulatory Reporting of Amendments to Transactions .................... 17 High Level Flows for Regulatory Reporting of Valuations, Collateralisation Information and Confirmation

Events ...................................................................................................... 18

2.3 Business Document Processing ................................................................... 19 Eligible Transaction Filtering Rules ............................................................................ 19 Formation and Amendment of the UTI ....................................................................... 24 Enrichment of the Input Message .............................................................................. 24 CpML Field Mappings to EMIR and REMIT Data Requirements ....................................... 38 Message Processing................................................................................................. 38

3 ELECTRONIC BUSINESS PROCESSES – BY DOCUMENT TYPES ........................................................ 39

3.1 Naming and Typing Conventions ................................................................ 39 Partner Identification ............................................................................................... 39 Document IDs ........................................................................................................ 39 Constraints on Document ID Usage in the eRR Process ................................................ 39 Optionality in Input Message Fields ........................................................................... 40 Document ID and the Reporting of Lifecycle Events ..................................................... 40

3.2 European Regulatory Reporting Envelope Fields ........................................... 41 CpML Document (CPD) – Document Root ................................................................... 41

3.3 European Regulatory Reporting Valuation Message ....................................... 58 Regulatory Valuation (VAL) – Document Root ............................................................. 58

3.4 European Regulatory Reporting Collateral Message ....................................... 60 Regulatory Collateral (COL) – Document Root ............................................................ 60

3.5 ETD Trade Details (ETD) ............................................................................ 62 Exchange Traded Derivative ..................................................................................... 62 Clearing Parameters ................................................................................................ 63 Product Description ................................................................................................. 63 Buyer Details .......................................................................................................... 65 Seller Details .......................................................................................................... 66 MTF Details ............................................................................................................ 67

3.6 IRS Trade Details (IRT) ............................................................................. 68 IRS Trade Details .................................................................................................... 68 IRS Trade Details – Option Details ............................................................................ 69 IRS Trade Details – Swap Stream ............................................................................. 70 IRS Trade Details – Calculation Period Dates .............................................................. 70 IRS Trade Details – Calculation Period Frequency ........................................................ 71 IRS Trade Details – Payment Dates ........................................................................... 71 IRS Trade Details – Reset Dates ............................................................................... 72 IRS Trade Details – Calculation Period Amount ........................................................... 73

3.7 FX Trade Details (FXT) .............................................................................. 75 FX Trade Details – Document Root ............................................................................ 75 FX Trade Details – FX Single Leg (FXSpot, FXForward and FXSwap) .............................. 76 FX Trade Details – Option Details .............................................................................. 78

3.8 Box Result Document (BRS)....................................................................... 82


of 119

Box Result – Document Root .................................................................................... 82

4 COMMUNICATION PROTOCOL AND INTERFACES ........................................................................... 85

APPENDIX A. DEFINITION OF TYPES AND CODES ....................................................................... 86

A.1. CpML Field Types ...................................................................................... 86

APPENDIX B. CPML FIELD MAPPINGS TO EMIR AND REMIT REQUIREMENTS ............................ 96


of 119

List of Tables

Table 1 Standing Instructions .................................................................................................. 24

Table 2 Generated Data Fields Created withing the eRR Process ................................................... 26

Table 3 Generated Data Fields Derived from Commercial Terms within the Payload Document ......... 28

Table 4 Generated Data Fields Derived from Look Up On Cleared Product Code .............................. 36

Table 5 Reporting Lifecycle Events ............................................................................................ 40

Table 6: Specification of Elements ............................................................................................ 41



Table 9: Specification of Trade Confirmation Elements ................................................................ 62

Table 10: Specification of IRS Trade Details Elements ................................................................. 68

Table 11: Specification of FX Trade Details Elements .................................................................. 75

Table 12 Specification of Box Results Elements .......................................................................... 82

Table 13: CpML Field Types ..................................................................................................... 86

List of Figures

Figure 1 Use Case Diagram for Centrally and Bilaterally Executed OTC Transactions ......................... 8

Figure 2 Use Case Diagrams for Regulatory Reporting of Cleared Transactions ............................... 10

Figure 3 Activity Diagram for Centrally and Bilaterally Executed OTC Transactions .......................... 13

Figure 4 Activity Diagram for Cleared Transactions ..................................................................... 16

Figure 5 Activity Diagram for Reporting Amendments to Transactions ........................................... 17

Figure 6 Activity Diagram for Reporting Valuations, Collateralisation and Confirmation Events ......... 18

Figure 7 Box Result Root Document Schema .............................................................................. 83

Figure 8 Box Result EuropeResult Section Schema ...................................................................... 84


of 119

1 Current Processes and Business Requirements

1.1 Current Business Processes

Regulatory reporting defined under the European regimes of EMIR, REMIT and other jurisdictional

regimes such as Dodd-Frank in the US, establish new operational requirements on trading businesses

operating in commodities and other asset classes. Consequently, no current business process exists as

a precursor for standardisation, therefore the eRR process has been developed directly from official

documentation [3, 4] and with reference to the work of other industry bodies and associations [5, 6].

1.2 Requirements for Electronic Business Processes

The goal of the eRR process is to define an industry standard solution for the single reporting of

eligible transaction, continuation and lifecycle event data by, or on behalf of, counterparties to

transactions that fall within a standardised definition of the scope of the regulation, independent of the

disperate data formats, codification schemes, transmission protocols and technical interfaces

supported by underlying databases and trade repositories. The purpose of the standard is to facilitate

automation of an electronic regulatory reporting process and to minimise the risk and cost of a

fragmented, piecemeal response to the introduction of this new operational process into European and

international commodity markets and the markets of related assest classes such as interest rates and

foreign exchange.

eRR Business Process Scope

The scope of the eRR process includes:

Definition of a standard set of filtering criteria that may be applied to a portfolio of trades to identify

those trades that are eligible for reporting under EMIR and REMIT, thereby mitigating the risk of

discrepancies between what is reported by each counterparty

Development of a ‘universal’ CpML [2] compliant message extension allowing a single CpML trade

description message to be used to report any eligible transaction under EMIR and/or REMIT, thereby

mitigating the risk of market participants needing to report two different messages: one to each

regime; and to enable a market participant, if necessary, to report to both regimes and/or multiple

underlying databases with a single message

Development of a standard process and message choreography for notifying regulatory databases of a

new trade, the modification or early termination of a reported trade and the reporting of valuations,

collateral information and the confirmation event as well as the cancellation of errorneous

submissions, that is independent of any specific mechanisms defined by underlying trade repositories

or regulatory databases to which the message must be delivered, thereby ensuring that market

participants are insulated from the complexity of the underlying trade repository landscape

Documentation of the approach to Unique Trade Identification (UTI) formatting, generation,

dissemination and reconciliation in collaboration with the other industry associations [5, 6]

Definition of a standard mechanism by which an ‘agent’ might report on behalf of one or both

counterparties to a transaction, thereby alleviating, where feasible, the need for a counterparty to

report directly (e.g. an execution platform or CCP reporting on behalf of both counterparties or one

counterparty to trade reporting on behalf of themselves and the other counterparty)

Specification of standard recommended features to be supported by underlying trade repositories and

databases necessary for allowing market paticipants to achieve a consolidated view on the status of all

transactions submitted by themselves or their counterparties or by an agent into disperate underlying

trade repositories or databases.


of 119

2 Electronic Business Processes – Overview

This section describes the workflow defined for the standard EFET compliant eRR process. For this

purpose the actors and their systems are considered to be “black boxes”. EFET has restricted itself to

defining the interface requirements for the incoming and outgoing documents and processing criteria

where appropriate.

2.1 Actors and Roles

Scope Regulatory Reporting of OTC (Bilateral) Transactions

Counterparty

OtherCounterparty

CP Agent

InternalAgent

Execute OTC Transaction

InternalCounterparty

Other Counterparty

Book New OTC Transaction

EMIRTrade Repository

REMITTrade Database

Generate UTI

Report Eligible New OTC Transaction<<extend>>

Determine Eligibility

<<include>>

ProprietaryTrade Repository

NRATrade Database

ACERTrade Database

Report On Behalf of Other Counterparty

<<extend>>

Annotate NewTransaction with

Eligibility

<<extend>>

Counterparty

Amend ExistingOTC Transaction

Other Counterparty

Terminate ExistingOTC Transaction

Apply Results of Compression

<<include>>

<<include>>

Other Counterparty

Report Lifecycle Event for Eligible Transaction

<<extend>>

<<extend>>


REMITTrade Database

Report Lifecycle Event On Behalf of Other

Counterparty

<<extend>>

CP Agent

InternalAgent

Confirm New OTCTransactionCounterparty

Other Counterparty

Report Confirmation Event For Eligible Transaction

<<extend>>

Report Confirmation On Behalf of Other Counterparty

<<extend>>


REMITTrade Database

Report Valuation forEligible OTC Transaction

NFC+Counterparty

FCCounterparty

Counterparty

NFCCounterparty

Report Valuation On Behalf of Other Counterparty

<<extend>>

Report Collateralisation for OTC Portfolio

Report Collateralisation On Behalf of Other

Counterparty

<<extend>>

CP Agent

InternalAgent

Maintain Standing Instructions On Behalf of

Other Counterparty

Reference StandingInstructions

<<include>>


<<include>>


<<include>>

Reconcile UTI

<<extend>>

Amend UTI<<extend>>

Maintain Reference Data

Counterparty

Access ReferenceData

<<include>>


<<include>>

Monitor Pending & Alleged Status

Counterparty

REMITTrade Database


Notify Counterparty of Alleged Event

Execution Broker<<include>>

<<extend>>

Execution Agent

Store UTI

<<include>>

Generate UTI

<<include>>

Generate UTI

<<include>>

<<extend>>

Execute Bilateral OTC Transaction

Exchange UTI

<<include>> <<include>>

<<extend>>Book New OTC

Transaction

Execution Agent

Figure 1 Use Case Diagram for Centrally and Bilaterally Executed OTC Transactions


of 119

Figure 1 Use Case Diagram for Centrally and Bilaterally Executed OTC Transactions provides an

overview of the scope and context of the eRR process for (bilaterally settled) OTC transactions under

EMIR and REMIT regulations.

An OTC transaction is executed either on an electronic (broker) platform or negotiated bilateraly. The

Unique Trade ID (UTI) is generated by the platform or, in the case of the bilateral negotiation may,

under some cicumstances, be exchanged between the parties at execution. On booking of the new

transaction into the system of record the UTI is stored with the new transaction and the internal Trade

ID; if the UTI is not available then it may be generated locally and stored with the trade.

The new transaction is submitted for reporting within timescales defined by the regulation (i.e. D+1).

The eligibility of the transaction for reporting is established and the trade annotated with the

conclusion: if it is eligible for reporting, or not and if so then under which regimes and upon what

criteria. The determination will require the application of standard rules and make use of reference

data sources. A report containing trade details and the UTI of the trade is made under each regulatory

regime underwhich the transaction is eligible; prior to reporting the UTI is generated, if not already

available, and the transaction details in the system of record are updated with the UTI. Both

counterparties are obliged to report either directly or through a third party agent. One of the

counterparties to the trade can fulfil the role of the agent and complete a report for themself and

another report on behalf of the other counterparty. Alternatively the operator of the electronic

execution platform may offer to act as as an agent for reporting new transactions executed on their

platform, in this case either one or both counterparties may elect to have the platform operator act as

the agent reporting on their behalf. An agent making a report on behalf of a party to the transaction

requires access to certain details about the counterparty. If a Counterparty wishes to make use of an

agent to report on their behalf they must make the necessary details available to the agent as a set of

‘standing instructions’ which the agent can draw upon when completing the transaction report on

behalf of the Counterparty.

Upon successful confirmation of an eligible transaction the original regulatory report(s) must be

amended with relevant information about the event, unless the information was included in the

original report. If a discrepancy between the UTIs used by the two counterparties to identify the

reported transaction is noticed at confirmation then the counterparties must reconcile the discrepancy

and apply any correction to the original report(s) if they have already been submitted.

Any lifecycle events affecting an eligible transaction that has been reported must also be reported as

amended versions of the original report(s). A Counterparty to the trade can report lifecycle

amendments on behalf of the Other Counterparty in the role of Counterparty Agent, the operator of

the platform upon which the original transaction was executed cannot act as an agent in the case of

lifecycle event since they are only aware of the original execution event and not aware of any

subsequent changes agreed bilaterally between the parties. An agent in the privileged position of

having access to the transaction details of two counterparties to an eligible transaction, but not

themselves being a party to the transaction, can also report lifecycle events (as well as the original

execution) on behalf of the counterparties; typically the two counterparties would be part of the same

organisational group as the ‘Internal Agent’ reporting on their behalf. If a compression event is the

cause of one or more lifecycle events including a new transaction, an amendment to an existing

transaction or the termination of a transaction then for any eligible transaction affected the lifecycle

event must be reported with the information that it was related to a compression event.

Eligible counterparties to eligible OTC transactions are obliged to report daily valuation on a per

transaction level and collateralisation information on a portfolio level. A Counterparty Agent or Internal

Agent may report this information on behalf of the Other Counterparty or one or both counterparties

to the original transaction if they have access to the relevant information.

Agents must maintain the standing instruction data they hold for the legal entities upon whose behalf

they are reporting, information such as the ‘Trading Capacity’ etc. to be used by the agent when

compiling a report on behalf of the legal entity.

Counterparties and agents need to maintain reference data used in compiling regulatory reports

including data about their own organisation and other organisations, such as LEI information.

Counterparties wish to view the status of their own regulatory reports but are also interested in the

submissions made by the other counterparty. EMIR trade repositories and REMIT trade databases


of 119

should provide information to counterparties about reports submitted for which they are identified as

the ‘Other Counteparty’. The UTIs of these ‘alleged’ transaction reports can be compared with the set

of ‘pending’ UTIs from the counterparties own submissions to highlight any discrepancies.

Scope of Regulatory Reporting of Cleared Transactions

Counterparty

Clearing Broker

ClearingAgent

Execute Cleared Transaction

Other Counterparty

Book New Cleared Transaction

REMITTrade Database

Report Eligible New Cleared Transaction<<extend>>


<<include>> NRATrade Database

ACERTrade Database


<<extend>>

Annotate NewTransaction with

Eligibility

<<extend>>

Counterparty

Amend ExistingCleared Transaction

Terminate ExistingOTC Transaction

Clearing Broker Report Lifecycle Event for Eligible Transaction

<<extend>>

<<extend>> REMITTrade Database

Report Lifecycle Event On Behalf of Other

Counterparty

<<extend>>

ClearingAgent

Report DailyCleared Position

Counterparty

ClearingBroker

Clearing AgentMaintain Standing

Instructions On Behalf of Other Counterparty


<<include>>


<<include>>

Maintain Reference Data


<<include>>


<<include>>

Monitor Pending & Alleged Status

Counterparty

REMITTrade Database


Notify Counterparty of Alleged Event

Exchange

Store UTI

<<include>>

Assemble TradeUTI

<<include>>

ExecutionBroker

CCP

Clear New Trasnaction

<<extend>>

Clearing Broker

ProprietaryTrade Repository



Report Valuation forCleared Position

Report Valuation On Behalf of Other Counterparty<<extend>>

Report Collateralisation for Cleared Position

Report Collateralisation On Behalf of Other

Counterparty

<<extend>>


Store Position UTI<<include>>

Assemble Position UTI

<<include>>


<<extend>>

Access UTI Component Data

<<include>>

Access Position UTI Component Data

<<include>>

Report Valuation forCleared Transactions in

Position

<<include>>

Exchange Data For UTI Assembly

NFC+Counterparty

Cascade, Explode, Amalgamate

<<include>>

<<include>>

Book New Cleared Transaction

<<include>>

Cascade, Explode, Amalgamate

<<extend>>

FCCounterparty

Counterparty

Figure 2 Use Case Diagrams for Regulatory Reporting of Cleared Transactions


of 119

Figure 2 Use Case Diagrams for Regulatory Reporting of Cleared Transactions provides an overview of

the scope and context of the eRR process for cleared transactions under EMIR and REMIT regulations.

The description draws on draft proposals [6] developed by the CCPs and Clearing Brokers in response

to EMIR specific regulations with the purpose of incorporating these proposals within the overall

description of the eRR process for reporting of OTC and cleared transactions under EMIR and REMIT.

The proposals [6] do not consider REMIT.

A cleared transaction is executed on an exchange or, anonymously, on an off-exchange electronic

platform (e.g. a broker platform). OTC trades subsequently given up for clearing are not currently

considered within the scope of the use case and anonymous transactions executed on an off-exchange

electronic platform are treated as equivalent to exchange transactions from the perspective of the

business process. Upon execution the transaction is entered into clearing at the CCP with the

participation of the Clearing Broker who acts upon behalf of the original Counterparty. The original

execution event results in four new trades: one between the CCP and the Clearing Broker acting on

behalf of one of the counterparties and one between the CCP and the Clearing Broker acting on behalf

of the other counterparty; as well as two ‘back to back’ trades each between the Clearing Broker and

the original Counterparty upon whose behalf the Clearing Broker is acting (n.b. the organisation to

which the Counterparty belongs may themselves be acting in the role of the Clearing Broker, a

Clearing Broker may also be acting on behalf of both the Counterparty and the Other Counterparty).

For the purpose of the eRR process scope only the relationship between the Counterparty (including

the Other Counterparty) and the Clearing Broker will be considered, the relationship between the

Clearing Broker and the CCP is considered to be outside the scope of the eRR process. The Clearing

Broker takes on the role of a Counterparty to the transactions that are considered to be within the

scope of the eRR Process.

Both the Counterparty and the Clearing Broker (acting as a Counterparty) book the new cleared

transaction into their system of record. The UTI for the transactions is stored at the time of booking.

Since the trade between the Clearing Broker and the Counterparty is the indirect result of the

execution event they do not share a UTI generated by the execution platform. The UTI is therefore

assembled from other information relating to the transaction which is already shared between the

Clearing Broker and the Counterparty as a result of their normal business practices and sufficient to

uniquely identify the two sides of the same transaction, as set out in [6].

The new transaction is submitted for reporting within timescales defined by the regulation (i.e. D+1).

The eligibility of the transaction for reporting is established and the trade annotated with the

conclusion: if it is eligible for reporting, or not and if so then under which regimes and upon what

criteria. The determination will require the application of standard rules and make use of reference

data sources. A report containing trade details and the UTI of the trade (which must be present) is

made under each regulatory regime underwhich the transaction is eligible. The original Counterparty

and their Clearing Broker are in the role of Counterparty and Other Counterparty; both counterparties

are obliged to report either directly or through an agent. The Clearing Broker may offer to act as the

agent (Clearing Agent) for the purposes of reporting both for themselves and for the Other

Counterparty, the Clearing Broker is well placed to provide this service since they are party to all

commercial information relating to the trade and to continuation data, where relevant, such as the

daily valuation of the transaction, the collateralisation information at the portfolio level, as well as all

lifecycle events affecting the transaction. The Cleairng Broker acting as the Clearing Agent for the

purpose of reporting requires access to certain details about the Other Counterparty. If a Counterparty

wishes to make use of a Clearing Agent’s services to report on their behalf they must make the

necessary details available to the Clearing Agent as a set of ‘standing instructions’ which the Clearing

Agent can draw upon when completing the transaction report on behalf of the Counterparty.

Reference [6] foresees daily reporting of position data to ESMA in addition to the transaction level

reporting specified in EMIR regulation. Each daily position will comprise an ‘aggregate trade’ with a

Unique Position Identifier – UPoI - assembled from other information relating to the transaction which

is already shared between the Clearing Broker and the Counterparty as a result of their normal

business practices and sufficient to uniquely identify the two sides of the same transaction, as set out

in [6]. There may be more than one daily position reported with each position representing a group of

underlying transactions. The grouping of transactions into positions must be agreed bilaterally

between the Counterparty and the Clearing Broker; typically transactions may be grouped by cleared


of 119

product. If the Clearing Broker offers such services then the Counterparty may elect to use the

Clearing Agent to report position data on their behalf.

Any lifecycle events affecting an eligible transaction that has been reported must also be reported as

amended versions of the original report(s). The Clearing Agent can report lifecycle amendments to

individual transactions on behalf of the Other Counterparty.

If any cascading, explosion or amalgamation occurs to one or more eligible cleared transactions on

registration into clearing or subsequently during the life of the reported transaction and the event is

the cause of one or more lifecycle events which may include a new transaction, an amendment to an

existing transaction or the termination of a transaction then the lifecycle event must be reported.

Lifecycle event reporting at the position level will be addressed within the daily position report since

any transaction level events affecting the position will be incorporated within the daily report. The

impact of any cascading, explosion or amalgamation of individual transactions which may affect how

they are grouped into positions (i.e. by product) must be managed bilaterally between the Clearing

Broker and the Counterparty to ensure consistency in reporting of daily positions and the

incorporation of the impact of such changes into the daily position report.

Eligible counterparties to eligible cleared transactions are obliged to report daily valuation on a per

transaction level and collateralisation information on a portfolio level. The Other Counterparty and

Clearing Broker, if eligible, must report this information under EMIR. If the service is offered by the

Clearing Broker the the Other Counterparty may opt to have the Clearing Agent report this

information on their behalf.

The Clearing Agent must maintain the standing instruction data they hold for the Other Counterparties

upon whose behalf they are reporting, information such as the ‘Trading Capacity’ to be used by the

agent when compiling a report on behalf of the legal entity.

Counterparties and Clearing Brokers need to maintain reference data used in compiling regulatory

reports including data about their own organisation and other organisations, such as LEI information.

Counterparties and Clearing Brokers must exchange data related to the clearing process from which

UTIs for transactions and UPoIs for positions can be assembled.

Counterparties wish to view the status of their own regulatory reports (perhaps submitted on their

behalf by the Clearing Agent) but are also interested in the submissions made by the Clearing Broker.

EMIR trade repositories and REMIT trade databases should provide information to counterparties

about reports (both at the transaction and position level) submitted for which they are identified as

the ‘Other Counteparty’. The UTIs of these ‘alleged’ reports can be compared with the set of ‘pending’

UTIs from the counterparties own submissions to highlight any discrepancies.


of 119

2.2 High Level Business Document Flows

High Level Flows for Regulatory Reporting of New Bilaterally Settled

OTC Transactions

eRR ProcessBack Office Trade Repositories


Create CP Output Message

StoreEligibility

Book NewTransaction

ACK PendingTransaction

Notify AllegedTransaction

Create Other CP Output Msg

Submit Report(s)

Reconcile UTIs

GenerateUTI

StoreUTI

Figure 3 Activity Diagram for Centrally and Bilaterally Executed OTC Transactions

HIGH LEVEL COUNTERPARTY OUTPUT MESSAGE PROCESSING

The input message to the eRR Process may be required to be enriched prior to submission. The input

message must contain all mandatory reportable business data that is maintained within the system of

record, such as the price and volume specific to the transaction etc. Other data required for compliant

reporting under EMIR and/or REMIT may be maintained outside the system of record facilitating

implementation of the eRR Process either as an extension to the system of record or as an external

system or service. If the input message (from the system of record) does not include certain optional

fields required for the final regulatory report then the eRR Process will ‘complete’ the message prior to

submission of the regulatory report of the transaction.

Enrichment involves:


of 119

Generation of field values (if not already present in the input message) such as the ‘Reporting

Timestamp’ or derivation of the ‘Product ID’ from data within the input message based on ‘Interim

Taxonomy’ defined by ESMA

Reference data look-ups (if not already present in the input message) based on externally

maintained data sources, such as if the Other Counterparty is based within the EEA or if a

contract is listed by ESMA as subject to the clearing obligation under Regulation (EU) No

648/2012

Standing Instruction look-ups (if not already present in the input message) based on data

internally maintained within the eRR Process by the Counterparty or the agent acting on their

behalf, such as their setting for ‘Clearing Threshold’ or a permanent default setting for ‘Trading

Capacity’ should they always trade either as ‘Principle’ or always as ‘Agent’ unless otherwise

stated in the input message.

HIGH LEVEL OTHER COUNTERPARTY OUTPUT MESSAGE PROCESSING

A ‘Counterparty’ can report on their own behalf and on behalf the ‘Other Counterparty’ to the

transaction in the role of an agent. A third party agent can also report as the ‘Counterparty’ and, if

required, on behalf of the ‘Other Counterparty’.

In any of the cases involving reporting on behalf of the ‘Other Counterparty’ a separate regulatory

report must be submitted on behalf of the ‘Other Counterparty’. The report must be created with the

‘Other Counterparty’ as the ‘Counterparty’, i.e. the roles must be reversed to create the reporting

perspective required by the EMIR and/or REMIT specifications.

As described in High Level Counterparty Output Message Processing, it may be necessary to enrich the

input message to create the report if the data is not present within the original input message. The

ability to enrich the message, especially with Standing Instructions maintained by, or on behalf of the

‘Other Counterparty’, means that an agent need only submit the commercial terms of the transaction

allowing the eRR Process to ‘complete’ the message with all other necessary data which in some cases

they are unlikely to have access to; for example, an execution agent (e.g. a broker) might be able to

offer to act as an ‘Execution Agent’ supplying the commercial terms of the transaction on behalf of one

or both counterparties, with the regulatory reports being completed using the Standing Instructions

maintained within the eRR Process by the Execution Agent on behalf of their clients.

The ability to enter and maintain Standing Instructions directly by a Counterparty or by and agent on

behalf of a Counterparty is pre-requsite upon the Counterparty being identified by an LEI. If a ‘Client

Code’ is used to identify an ‘unknown’ entity then all information otherwise available from Standing

Instructions must be included in the input message to the eRR Process since Standing Instructions are

not supported for Client Codes, only for LEI codes.

HIGH LEVEL ELIGIBILITY PROCESSING

Both counterparties to eligible transactions are required to report under EMIR and REMIT regulations.

By applying the same standard criteria for determining the eligibility of each transaction the risk of

discrepancies between what is reported under the relevant regulation by each counterparty may be

mitigated.

Each new transaction booked onto the system of record must have its eligibility for reporting

determined in a timely fashion to facilitate compliance with reporting timescales defined within the

applicable regulation. Since reporting timescales may differ between regulatory regimes and may also

change due to revisions to the terms of a regulatory regime, it is highly recommended that eligibility

for reporting is determined at the time of booking of the transaction into the system of record, rather

than at some later time, such as after close of business on the day of execution of the transaction.

A transaction may not be eligible for reporting, in which case this information is returned to be stored

in the system of record and the eRR Process ends. Otherwise the criteria underwhich which the

transaction falls eligible are recorded within the process and the eligibility under EMIR and/or REMIT is

returned to be stored in the system of record against the transaction.

HIGH LEVEL UTI GENERATION PROCESSING

Transactions eligible for reporting under EMIR and REMIT must be identified by a UTI. If an input

message describing a transaction has been received by the eRR Process and it has been determined


of 119

that the transaction is eligible for reporting but has been submitted to the eRR Process without an

externally supplied UTI then the eRR Process will generate a UTI and return the UTI value to be stored

in the system of record against the transaction for subsequent use when reporting lifecycle events

and/or continuation information and for inclusion within any confirmation process performed bertween

the Counterparty and Other Counterparty.

If an input message contains an externally supplied UTI then an internal UTI will not be generated

within the process.

It is recognised that an external UTI already shared between the counterparties, ideally generated at

the point of execution, should if, possible be submitted to the eRR Process. However it is also

recognised that in some circumstances, such as for bilatetrally negotiated transactions, there may not

be an established mechanism for UTI sharing between counterparties ahead of confirmation matching,

or that the eRR Process is the preferred mechanism for generating the UTI, and that the use of

internally generated UTIs in these cases is expedient.

In any case UTIs will need to be reconciled as part of the confirmation process for bilateral OTC

transactions and so the rules set out in [5] for identification of the ‘Generating Party’ are mandated by

the eRR Process for defining which party’s UTI must be used by both counterparties, thus providing a

standardised and automatable mechanism for resolving discrepancies that may arise at confirmation

between the UTI to be used for a transaction.

HIGH LEVEL SUBMIT REPORT(S) PROCESS

Each eligible input message, including UTI and completed with all required fields will be passed to the

Submit Report(s) process. The Submit Report(s) process will manage the necessary interactions with

the underlying EMIR Trade Repositories and REMIT database(s).

For transactions reported under EMIR the target repository is specified in within the enhanced input

message.

For transactions reported under REMIT the target databases will be determined depending on

mechanisms agreed between ACER and the National Regulatory Authorities (NRAs).

An individual transaction may be reported under EMIR, REMIT or under both EMIR and REMIT. The

ability for the eRR Process to accept one input message and to report to multiple regimes and multiple

physical databases and repositories, as required, minimises the operational and technical impact of

regulatory reporting and is a key feature of the process.

Successfully submitted reports must be confirmed by an acknowledgement from the the underlying

trade repository and trade database(s).

HIGH LEVEL RECONCILE UTI PROCESS

Each transaction successfully reported by or on behalf of a Counterparty is logged within the eRR

Process and assigned to the ‘Pending’ state within the reconciliation queue.

Each repository and traded database, for compliancy with the eRR Process, is required to incorporate

the functionality to notify the ‘Other Counterparty’ of the submission of a regulatory report by the

‘Counterparty’ and to supply at least the UTI used by the Counterparty in their submitted report. The

eRR Process therefore receives notificactions of ‘alleged’ UTIs submitted by Counterparties. Each

alleged notification is logged within the eRr Process and assigned to the ‘Alleged’ state within the

reconciliation queue. The eRR Process will continually reconcile ‘Pending’ and ‘Alleged’ UTIs in each

Counterparty reconciliation queue.

If the reconciliation queue contains aged, unreconciled UTIs then the Counterparty must take actions

outside the eRR Process to investigate and reconcile, potentially through the confirmation process, any

discrepancies and to apply any amendments to the UTI of the reported transaction to their system of

record and propagate the amendment to the underlying repositories and traded databases through the

eRR UTI amendment mechanism.


of 119

High Level Flows for Regulatory Reporting of New Cleared

Transactions



AssembleUTI


StoreEligibility

Book NewTransaction

ACK PendingTransaction

Notify AllegedTransaction


Submit Report(s)

Reconcile UTIs

AssembleUPoI

Report DailyPosition(s)

Figure 4 Activity Diagram for Cleared Transactions

The flow for reporting of newly executed OTC cleared or exchange traded cleared transactions

comprises a subset of the process steps described in High Level Flows for Regulatory Reporting of New

Bilaterally Settled OTC Transactions. The major variations are: ‘self-assembly’ of the UTI for individual

cleared transactions which must occur in the Back Office of the Counterparty or agent; and the

submission of daily positions in addition to reporting of individual transactions.

The process of UTI ‘self assembly’ is set out in [6] and draws on data already shared between client

and clearing broker outsode of the scope of the eRR Process as part of existing business practices.


of 119

The mechanism for specifying the content of the daily position, as well as the ‘self assembly’ of

associated UP(o)Is is also specified in [6].

The processes of determining eligibility of a cleared transaction, the creation of the output message(s)

for the Counterparty and Other Counterparty in the case of a agency role, as well as the submission

and reconciliation of pending and alleged UTIs and UP(o)Is are consistent with the approach for OTC

bilaterally settled transactions. At this stage however the ‘counterparty data’ associated with the

submission of the reported position remains uncertain and needs clarification in subsequent versions

of [6]. Any such clarifications may need to be addressed wihth the Stanading Instructions defined for

eRR.

High Level Flows for Regulatory Reporting of Amendments to

Transactions



Amend Eligible transaction

ACK Submission


Submit Report(s)

Figure 5 Activity Diagram for Reporting Amendments to Transactions

The flow for reporting eligible lifecyle events including amendments (ActionType = “M”) to and early

terminations (ActionType = “C”) of reported transactions as well as the removal of reports submitted

in error (ActionType = “E”) comprises a subset of the process steps described in High Level Flows for

Regulatory Reporting of New Bilaterally Settled OTC Transactions. Each ‘ActionType’ is submitted as

an amendment to a previouslysubmitted input message. These process setps are applicable for both

bilaterally settled and cleared transactions and independent of the underlying causes: compressions,

novations, cascades, amalgamations and explosions etc.


of 119

High Level Flows for Regulatory Reporting of Valuations,

Collateralisation Information and Confirmation Events



Daily Valuations

ACK Submission


Submit Report(s)

Daily Collateralisation

Report Confirmation

Figure 6 Activity Diagram for Reporting Valuations, Collateralisation and Confirmation Events

FC and NFC+ Counterparties must report daily valuations for all reported trades eligible under EMIR

regulations to the Trade Repository to which the original transaction was reported until the transaction

terminates.

FC and NFC+ Counterparties must report daily collateralisation information under EMIR at the portfolio

level for all notified portfolios to the Trade Repository to which the associated transactions were

originally reported until all transactions in the portfolio have terminated. EMIR permits transaction

level reporting of collateralisation but the eRR Process recommends portfolio level collateralisation

reporting.

All Counterparties must report the confirmation event, if not reported as part of the original report,

under both EMIR and REMIT.

A Counterparty, such as the Clearing Broker may report valuation and collateralisation information on

their own behalf and in the role of the Clearing Agent on behalf of the Other Counterparty. In such

cases the report for the Other Counterparty will be created from their perspective using the same

valuation or collateralisation information from the input message. In the case of the collateralisation

information the Other Counterparty’s portfolio code, if not present in the input message, is looked up

for the corresponding portfolio to that being reported by the Clearing Broker from Standing

Instructions for the Other Party.

Counterparty may report the confirmation event on their own behalf and on behalf of the Other

Counterparty. In such cases the report for the Other Counterparty will be created from their

perspective using the same confirmation information from the input message.

All reports are submitted to the Trade Repository and trade databases to which the original

transaction was reported unless otherwise expressed in the input message.


of 119

2.3 Business Document Processing

Eligible Transaction Filtering Rules

EMIR and REMIT are separate regulatory frameworks with their own separate scope and purpose but

with overlapping data reporting requirements. The eRR Process aims to minimise reporting overhead

by specifying a single input message which can be used to satisfy a counterparty’s reporting

obligations under both regimes. On submission of an input message the eRR Process must determine

the eligibility (or not) of the underlying transaction based on the data supplied in the message for

reporting under both regimes.

A further aim of standardising the filter criteria for determining eligibility for reporting around a single

standardised input message is to mitigate the risk of inconsistent reporting between counterparties

who under both EMIR and REMIT have a dual obligation to report both side of the transaction.

Discrepancies in regulatory submissions and the subsequent overhead of resolving such discrepnacies

may be avoided by agreeing to a standard set of criteria based on a standard input message to the

filtering process.

The principles for the standardising the process for determining eligibility under EMIR and REMIT are:

To use an input message to the process defined by the CpML data standard

To define one ‘filter’ that acts upon the CpML input message per regulation i.e. one set of filter

values for EMIR and another independent set of filter values for REMIT

To directly derive the filter criteria from the essential regulatory clauses

To retain an audit trail specifying upon which criteria the eligibility of each input message was

determined

REGULATORY DERIVATION OF FILTER CRITERIA FOR EMIR

The following commentary is based on based on MiFID I definitions, Section C

• C5: all financial instruments with cash settlement

• CpML analysis:

• All OTC and cleared Swaps, options on these instruments and Financial Options

defined within the CpML data standard are cash settled instruments and therefore

eligible under this clause

• All OTC Physical Forwards (including spot contract) both fixed and floating price

and options on these instruments defined within the CpML data standard are

physically settled instruments and therefore ineligible under this clause

• All cleared Physical Forwards (including spot contract) both fixed and floating price

and options on these instruments defined within the CpML data standard are

physically settled instruments and therefore ineligible under this clause unless

otherwise defined as financially settled by the ‘CRAProductCode’ referenced within

the CpML ETDTradeDetails schema and maintained by the Regulated Market or

MTF where the product is traded in which case they are eligible under this clause

• Futures and exchange traded options are cash settled and therefore eligible under

this clause unless otherwise defined as physically settled by the ‘CRAProductCode’

referenced within the CpML ETDTradeDetails schema and maintained by the

Regulated Market or MTF where the product is traded in which case they are

ineligible under this clause.

• CpML filter criteria:

• All CpML payload documents, including ETDTradeDetails which describe cleared

transactions, in the input message with the following ‘TransactionType’ values

WILL be captured by this clause:

• “FXD_SWP”: Fixed/float swap

• “FXD_FXD_SWP”: Fixed/fixed swap

• “FLT_SWP”: Float/float swap


of 119

• “OPT_FXD_SWP”: Fixed/float swaption

• “OPT_FXD_FXD_SWP”: Fixed/fixed swaption

• “OPT_FLT_SWP”: Float/float swaption

• “OPT_FIN_INX”: Option on an index

• All CpML payload documents, excluding ETDTradeDetails which describe cleared

transactions, with the following ‘TransactionType’ values WILL NOT be captured by

this clause:

• “FOR”: Physical Forward that settles against a fixed price

• “OPT”: Option on a physical forward

• “PHYS_INX”: Physical forward that settles against an index

• “OPT_PHYS_INX”: Option on a physical forward that settles against an

index

• CpML ETDTradeDetail payload documents in the input message with the following

‘TransactionType’ values WILL be captured by this clause unless a look up of the

‘CRAProductCode’ indicates that the referenced product is physically settled, in

which case it WILL NOT be captured by this clause:

• “FUT”: Future

• “OPT_FUT”: Exchange traded option





index

• C6: all physically settled instruments traded on a Regulated Market or MTF with physical delivery

• CpML analysis:



ineligible under this clause


and options on these instruments, defined within the CpML data standard are

physically settled instruments and therefore eligible (with the exception of spot

contract which are not ‘derivatives’) under this clause if the ‘Venue of Execution’ is

identified with a MIC which indicates, for the purposes of the eRR Standard, that

the platform is an MTF or Regulated Market and that these physically settled

instruments, in this context, are eligible under this clause

• All cleared transactions are cash settled and therefore ineligible under this clause

unless otherwise defined as physically settled by the ‘CRAProductCode’ referenced

within the CpML ETDTradeDetails schema and maintained by the Regulated Market

or MTF where the product is traded in which case they are eligible (with the

exception of spot contract which are not ‘derivatives’) under this clause if the

‘Venue of Execution’ is identified with a MIC which, for the purposes of the eRR

Standard, indicates that the platform is an MTF or Regulated Market OR ‘Venue of

Execution’ is identified as “XOFF” which means that the cleared (or ‘listed’) product

was executed on a venue that is not a RG or MTF and that these cleared but

physically settled instruments, in this context, are eligible under this clause


• All CpML payload documents, including ETDTradeDetails which describe cleared


WILL NOT be captured by this clause:



of 119









WILL NOT be captured by this clause unless the value for the ‘Venue of Execution’

is a MIC AND ‘Effective Date’ > ‘DATE(Execution Timestamp)+2, in which case it

WILL be captured by this clause:





index


‘TransactionType’ values WILL NOT be captured by this clause unless a look up of

the ‘CRAProductCode’ indicates that the referenced product is physically settled

AND the value for the ‘Venue of Execution’ is a MIC OR “XOFF” AND ‘Effective

Date’ > ‘DATE(Execution Timestamp)+2, in which case it WILL be captured by this

clause:





index



• C7: all physically settled instruments executed on a third country RM/MTF (or equivalent) that are

cleared

• CpML analysis:



ineligible under this clause


and options on these instruments, defined within the CpML data standard are

uncleared, physically settled instruments and therefore ineligible under this clause

• All cleared transactions are cash settled and therefore ineligible under this clause

unless otherwise defined as physically settled by the ‘CRAProductCode’ referenced

within the CpML ETDTradeDetails schema and maintained by the Regulated Market

or MTF where the product is traded in which case they are eligible (with the

exception of spot contract which are not ‘derivatives’) under this clause if the

‘Venue of Execution’ is identified with a MIC for a thrird country venue which, for

the purposes of the eRR Standard, indicates that the thrird country platform is

equivalent to an EU MTF or Regulated Market OR ‘Venue of Execution’ is identified

as “XOFF” which means that the cleared (or ‘listed’) product was executed on a

venue that is not a RG or MTF and that these cleared but physically settled

instruments, in this context, are eligible under this clause



of 119

• All CpML payload documents in the input message with the following

‘TransactionType’ values WILL NOT be captured by this clause:










WILL NOT be captured by this clause:





index


‘TransactionType’ values WILL NOT be captured by this clause unless a look up of

the ‘CRAProductCode’ indicates that the referenced product is physically settled

AND the value for the ‘Venue of Execution’ is a MIC or “XOFF” (n.b. it has been

agreed that there is no requirement to validate the nature or status of a venue

identified by a MIC as being EU or third country or if third country equivalent to an

EU MTF or RG) AND ‘Effective Date’ > ‘DATE(Execution Timestamp)+2, in which

case it WILL be captured by this clause:





index



• C10: Cash settled Options, futures, swaps, forward rate agreements relating to climatic variables,

freight rates, emission allowances

• CpML analysis

• Any cleared transaction for the identified commodities which must be described

according to CpML using the ETDTradeDetails schema will be eligible under this

clause.


• All CpML ‘ETDTradeDetails’ payload documents in the input message for which

‘CommodityBase’ = “EV” or “FR”

REGULATORY DERIVATION OF FILTER CRITERIA FOR REMIT

The following commentary is based on [4]

• Natural gas and electricity for delivery in the ‘EU’

• CpML analysis:


of 119

• All Physical Forwards (including spot contract) both fixed and floating price and

options on these instruments defined within the CpML data standard with a

delivery point or area within the EU WILL be eligible

• All Swaps and Financial Options defined within the CpML data standard for

which the underlying Commodity Reference is priced off a contract referencing

a delivery point or area with the EU WILL be eligible

• Futures and exchange traded options and, more generally, any cleared product

for which the “CRAProductCode” refers to a delivery point or area with the EU

WILL be eligible



‘TransactionType’ values WILL be captured by this clause if ‘Commodity Base’

= “CO” AND ‘Commodity Details’ = “NG” or “EL” AND ‘Delivery Point Area’ is

an EIC code that identifies a point or area that is within the EU:





index


‘TransactionType’ values WILL be captured by this clause if ‘Commodity Base’

= “CO” AND ‘Commodity Details’ = “NG” or “EL” AND ‘Commodity Reference’

is defined as referring to some underlying contract that references delivery at

a point or area that is within the EU:








• All input messages that contain an ETDTradeDetails schema for any of the

following ‘TransactionType’ values WIL be captured by this clause if

‘Commodity Base’ = “CO” AND ‘Commodity Details’ = “NG” or “EL” AND

‘CRAProductCode’ is defined as referring to some underlying contract that

references delivery at a point or area that is within the EU:





index










of 119


Formation and Amendment of the UTI

UTI FORMATION FOR UNCLEARED TRANSACTIONS

The UTI for uncleared transactions is defined by the eRR Standard, inconjunction with [5], as

comprising:

Namespace which must be 7-16 from the LEI

32 randomly generated characters

UTI FORMATION FOR CLEARED TRANSACTIONS

The UTI for cleared transactions and positions is defined by the eRR Standard as specified in [6].

AMENDMENT OF THE UTI

The UTI is an amendable data item within the eRR Process. To change the UTI on a previously

submitted transaction report it is necessary to submit an amendment (same Document ID , higher

Document Version) with the ActionType = “M” and including any changes including the new UTI.

Any constraint on amendment of UTI placed by the underlying repositories and databases will be

managed through the Submit Report(s) sub-process and may include combining the cancellation of

the original submittion and the opening of a new entry in the repository.

Enrichment of the Input Message

The essential commercial terms of eligible transactions must be complimented with other information

that is either captured in addition to the commercial terms during booking of the transaction, derived

from commercial information or created as part of the reporting process or added to the submitted

report from some external source. The three types of information required to complete a regulatory

report in addition to the essential commercial terms are described in more detail below and in full

detail in Appendix B CpML Field Mappings to EMIR and REMIT Requirements.

STANDING INSTRUCTIONS BY COUNTRERPARTY

Standing instructions comprise information about the ‘Counterparty’ reporting a transaction which

may vary from transaction to transaction but which may remain consistent for the majority, or indeed,

all transactions. Such data can be maintained by the Counterparty or by an agent acting on their

behalf as legal entity specific ‘default’ values that may be used to enrich regulatory reports for

individual transactions for that legal entity. The presence of such default values means that the input

message to the eRR Process does not need to contain these values as the values can be added from

the defaults specific to the Counterparty. This has two potential benefits: either to reduce the

reporting overhead of the Counterparty, since this data no longer need to be maintained or added to

the commercial terms within the input message; or to allow an agent who has access to the

commercial terms of the individual transactions to report on behalf of the Counterparty thereby

alleviating the counterparty of the overhead of reporting the transactions themselves.

Table 1 Standing Instructions

Name Type Description

Repository RepositoryType The identity of the EMIR repository to which the

Counterparty wishes to report.

CPIDCodeTy

pe

CPIDCodeTypeTyp

e

The codification scheme for the party identifier for the

Counterparty and Other Counterparty

Default value = “LEI”.

CPName CPNameType Corporate name of the reporting counterparty. This field

can be left blank in case the counterparty ID already

contains this information.


of 119

CPDomicile CPDomicileType Information on the registered office, consisting of full

address, city and country of the reporting counterparty.

This field can be left blank in case the counterparty ID

already contains this information.

CPSector CPFinancialNature

Type

Nature of the reporting counterparty's company activities

(bank, insurance company, etc.). This field can be left

blank in case the counterparty ID already contains this

information.

CPFinancial

Nature

CorporateSectorT

ype

Indicate if the reporting counterparty is a financial or

non-financial counterparty in accordance with Article

2(8,9)of Regulation (EU) No 648/2012.

ReportingEn

tityID

NameType For REMIT usage only: ID of the reporting party (RRM) as established with the reporting party’s ACER registration.

Default = “<name of eRR service provider>” e.g.

“EFETnet”.

BeneficiaryI

D

PartyType The party subject to the rights and obligations arising

from the contract. Where the transaction is executed via

a structure, such as a trust or fund, representing a

number of beneficiaries, the beneficiary should be

identified as that structure. If the beneficiary of the

contract is not a counterparty to this contract, the

reporting counterparty has to identify this beneficiary by

a unique code or, in case of individuals, by a client code

as assigned by the legal entity used by the individual.

TradingCapa

city

TradingCapacityT

ype

Identifies whether the reporting counterparty has

concluded the contract as principal on own account (on

own behalf or behalf of a client) or as agent for the

account of and on behalf of a client.

Commercial

orTreasury

TrueFalseType Information on whether the contract is objectively

measurable as directly linked to the reporting

counterparty's commercial or treasury financing activity,

as referred to in Art. 10(3) of Regulation (EU) No

648/2012. This field shall be left blank in case the

reporting counterparty is a financial counterparty, as

referred to in Art. 2 (8) Regulation (EU) No 648/2012.

ClearingThre

shold

TrueFalseType Information on whether the reporting counterparty is

above the clearing threshold as referred to in Art. 10(3)

of Regulation (EU) No 648/2012. This field shall be left

blank in case the reporting counterparty is a financial

counterparty, as referred to in Art. 2 (8) Regulation (EU)

No 648/2012.

Collateralisa

tion

CollateralisationTy

pe

Whether collateralisation was performed.

Not required if Clearing Threshold = “False”.

Collateralisa

tionPortfolio

TrueFalseType Whether the collateralisation was performed on a

portfolio basis. Portfolio means the collateral calculated

on the basis of net positions resulting from a set of

contracts, rather than per trade.

Not required if Clearing Threshold = “False”.


of 119

Collateralisa

tionPortfolio

Code

PortfolioCodeType If collateral is reported on a portfolio basis, the portfolio

should be identified by a unique code determined by the

reporting counterparty.

This may be a different value for each product and

counterparty.

Not required if Clearing Threshold = “N”.

Taxonomy TaxonomyType The contract shall be identified by using a product

identifier.

N.B. this field is not required for ‘Reporting on Behalf Of’

as the field value for the agent will be used to define the

same Taxonomy for reporting both sides of a

transaction.

TaxonomyCo

deType

TaxonomyCodeTy

pe

The scheme used for the field value in ‘Taxonomy’.

Default = "EMIR_Taxonomy"



same Taxonomy Code type for reporting both sides of a

transaction.

Product1Cod

eType

TaxonomyCodeTy

pe

The scheme used for the field value in ‘ProductID1’




same Product Code type for reporting both sides of a

transaction.

UnderlyingC

odeType

UnderlyingCodeTy

peType

The scheme used for the field value used to identify the

‘Underlyer’ in the commercial terms of the transaction

being reported.

Default = "UPI"



same Underlying Code Type for reporting both sides of a

transaction.

MasterAgree

mentVersion

MasterAgreement

VersionType

The ‘vintage’ of the agreement under which the reported

transaction was executed.

This may be a separate value for each value of ‘Master

Agreement’ and Counterparty.



same Master Agreement Version for reporting both sides

of a transaction.

GENERATED DATA FIELDS

Generated values comprise either data values in the output message that are created within the eRR

Process or data values in the output message that are derived from data values within the input

message ‘payload’ document that comprise the commercial terms of the transaction.

Table 2 Generated Data Fields Created withing the eRR Process



of 119

ReportingTi

mestamp

UTCTimestampTy

pe

Date and time of the submission of the report.

Reporting

Entity

NameType REMIT submission output message mapping:

If not present in the input message then

this field will be set to the default value in the REMIT output message

else

this value will be used to populate the REMIT output message.

Default = “<name of eRR service provider>” e.g.

“EFETnet”.

EMIR submission output message mapping:

If 'ReportingRole' = "Trader" then

this field = <Payload>/SenderID

else

this field = ‘Agent ID’

Taxonomy TaxonomyType Default = “E”.

TaxonomyCo

deType

TaxonomyCodeTy

pe


EProductID1 EProduct1CodeTy

pe

If payload document = CNF then this field = "CO" in the

output message

else

if payload document = IRSTradeDetails then this field must = "IR"

else

if payload document =ETDTradeDetails then this

field = ETDTradeDetails/PrimaryAssetClass

else

if payload document = FXTradeDetails then this field

= “CU”.

Product

Code Type

If this field is omitted in the input message then the field

will be set to the default value and the default value will

be used to populate the output message.



of 119

EProductID2 EProduct2CodeTy

pe

If payload document = CNF then

if CNF/TransactionType = "FOR" this field must = "FW"

else if CNF/TransactionType = "OPT" or "OPT_PHYS_INX" or " OPT_FIN" or "OPT_FXD_SWP" or "OPT_FLT_SWP" then this field must = "OP"

else if CNF/TransactionType = "FXD_SWP" or "FLT_SWP" then this field must = "SW"

If payload document = IRSTradeDetails then if IRSTradeDetails/TransactionType =

"OPT_FXD_SWP" or "OPT_FLT_SWP" or "OPT_FXD_FXD_SWP" then this field must = "OP"

else if IRSTradeDetails/TransactionType = "FXD_SWP" or "FLT_SWP" or "FXD_FXD_SWP"then this field must = "SW"

If payload document =ETDTradeDetails then

if ETDTradeDetails/TransactionType = "FOR" or “SPT” this field must = "FW"

if ETDTradeDetails/TransactionType = “OPT” or "OPT_FXD_SWP" or "OPT_FLT_SWP" or "OPT_FXD_FXD_SWP" or “OPT_FIN” then this field must = "OP"

else if ETDTradeDetails/TransactionType = "FXD_SWP" or "FLT_SWP" or "FXD_FXD_SWP"then this field must = "SW"

else if ETDTradeDetails/TransactionType = “FUT” or “OPT_FUT” then this field = "FU"

If payload document = FXTradeDetails then if if FXTradeDetails/TransactionType = "FOR" or

“SPT” this field must = "FW" if FXTradeDetails/TransactionType = “OPT” or

“OPT_FXD_FXD_SWP” then this field must = "OP" else if FXTradeDetails/TransactionType =

"FXD_FXD_SWP"then this field must = "SW"

Underlying

Code Type

UnderlyingCodeTy

peType




Default = "UPI"

Table 3 Generated Data Fields Derived from Commercial Terms within the Payload Document


Counterpart

y ID

PartyType If 'ReportingRole' = "Trader" Trader ", "CP_Agent" or

"Clearing_Agent"then this field =

TradeConfirmation/SenderID

elseif 'Acting onBehalf Of' = "Buyer" then this field =

TradeConfirmation/BuyerParty

elseif 'Acting onBehalf Of' = "Seller" then this field =

TradeConfirmation/SellerParty

elseif 'Acting onBehalf Of' = "Buyer_And_Seller" then

this field = TradeConfirmation/BuyerParty


of 119

ID of the

other

counterparty

PartyType If 'ReportingRole' = "Trader" Trader ", "CP_Agent" or

"Clearing_Agent"then this field =

TradeConfirmation/RecieverID

elseif 'Acting onBehalf Of' = "Buyer" then this field =


elseif 'Acting onBehalf Of' = "Seller" then this field =



this field = TradeConfirmation/SellerParty

For ETDs see mappiong rules in 3.5 ETD Trade

Details (ETD)

Counterpart

y side

String (1) If 'ReportingRole' = "Trader" Trader ", "CP_Agent" or

"Clearing_Agent"then if TradeConfirmation/SenderID =

TradeConfirmation/Buyer Party then "B" else "S"

elseif 'Acting onBehalf Of' = "Buyer" then this field = "B"

elseif 'Acting onBehalf Of' = "Seller" then this field = "S"


this field = "B"

For ETDs see mappiong rules in 3.5 ETD Trade

Details (ETD)


of 119

Notional

Amount

QuantityType OTC Commodity:

FXD_SWP: SUM(TradeConfirmation/DeliveryPeriods/DeliveryPeriod/DeliveryP

eriodNotionalQuantity * FixedPrice)

OPT_FXD_SWP, OPT_FLT_SWP, OPT_FIN_INX:

SUM(TradeConfirmation/DeliveryPeriods/DeliveryPeriod/DeliveryP

eriodNotionalQuantity *

TradeConfirmation/OptionDetails/StrikePrice) FLT_SWP:

The following rule applies to the instance of

TradeConfirmation/FloatPriceInformation where

TradeConfirmation/FloatPriceInformation/FloatPricePayer =

TradeConfirmation/BuyerParty. If there are multiple

TradeConfirmation/FloatPriceInformation/CommodityReferences/

CommodityReference elements then

CpMLDocument/Reporting/Europe/EURegulatoryDetails/NotionalA

mount

If there is one


CommodityReference element: TradeConfirmation/TotalVolume *

TradeConfirmation/FloatPriceInformation/CommodityReferences/CommodityReference[1]/SpreadInformation/SpreadAmount

If there is no



TradeConfirmation/FloatPriceInformation/FormulaSpreadInformat

ion/SpreadAmount or 0 if there is no FormulaSpreadInformation

element

PHYS_INX, OPT_PHYS_INX:

CpMLDocument/Reporting/Europe/EURegulatoryDetails/NotionalAmount

FOR, OPT:

TradeConfirmation/TotalContractValue

Interest Rate

IRSTradeDetails/SwapStream[1]/CalculationPeriodAmount/Calcul

ation/NotionalSchedule/NotionalStepSchedule/InitialValue

ETDs

if Transaction Type = "OPT*" then

ETDTradeDetails/ClearingParameters/Lots *

ETDTradeDetails/ClearingParameters/StrikePrice * CpMLDocument/Reporting/Europe/EURegulatoryDetails/ETDProd

uctInformation/PriceMultiplier

else


ETDTradeDetails/ClearingParameters/UnitPrice *

CpMLDocument/Reporting/Europe/EURegulatoryDetails/ETDProd

uctInformation/PriceMultiplierForeign Exchange

If FXTradeDetails/TransactionType = "OPT" then

If FXTradeDetails/FXOption/Strike/QuoteBasis = "PutCurrencyPerCallCurrency" then

FXTradeDetails/FXOption/PutCurrencyAmount/Amount DIVIDED

BY FXTradeDetails/FXOption/Strike/FXRate else

FXTradeDetails/FXOption/PutCurrencyAmount/Amount *

FXTradeDetails/FXOption/Strike/FXRate

else

FXTradeDetails/FXSingleLeg[1]/PaymentAmount

Commodity Formula Swaps:

FXD_SWP:

SUM(TradeConfirmation/DeliveryPeriods/DeliveryPeriod/DeliveryPeriodNotionalQuantity * FixedPrice)


SUM(TradeConfirmation/DeliveryPeriods/DeliveryPeriod/DeliveryP

eriodNotionalQuantity *

TradeConfirmation/OptionDetails/StrikePrice)

FLT_SWP:



TradeConfirmation/FloatPriceInformation/FloatPricePayer = TradeConfirmation/BuyerParty.



TradeConfirmation/FloatPriceInformation/FormulaSpreadInformat

ion/SpreadAmount or 0 if there is no FormulaSpreadInformation

element

PHYS_IN, OPT_PHYS_INXX:

CpMLDocument/Reporting/Europe/EURegulatoryDetails/NotionalA

mount

FOR, OPT: TradeConfirmation/TotalContractValue


of 119

Quantity QuantityType TradeConfirmation/TotalVolume

or

ETDTradeDetails/ClearingParameters/Lots * 'Price Multiplier'

for REMIT

Or

ETDTradeDetails/ClearingParameters/Lots for EMIR

Else set = “1”

Delivery

type

String (1) For OTC Commodity transactions:

If TradeConfirmation/TransactionType = "FOR" or

"PHYS_INX" or "OPT" or "OPT_PHYS_INX" then must

equal "P"

else if TradeConfirmation/TransactionType = "FXD_SWP"

or "FLT_SWP" then must equal "C"

else if TradeConfirmation/TransactionType = "OPT_FIN"

or "OPT_FXD_SWP" or "OPT_FLT_SWP" then if

TradeConfirmation/OptionDetails/CashSettled = "Y" then

"C" else "P".

For ETDs:

CpMLDocument/Reporting/Europe/EURegulatoryDetails/E

TDProductInformation/DeliveryType if present

else

ETDTradeDetails/Product/CRAProductCode

For OTC FX and IR transactions:

Set = “C”

Cleared String (1) If the input message Payload Document is

<ETDTradeDetails”> then this field

• Must be set to “Y”

Else

• It must be set to “N”


of 119

Commodity

base


If

TradeConfirmation/FloatPriceInformation/CommodityRef

erence[1]/IndexCommodity is in the set of values

'Agricultural' then = "AG"

elseif

'Energy' = "EN"

elseif

'Wet Freight' OR 'Dy Frieight' = "FR"

elseif

'Metals' = "ME"

elseif

'Emissions' OR 'Weather' = "EV"

else

"EX"

For OTC non standard Commodity transactions:

CpMLDocument/Reporting/Europe/EURegulatoryDetails:/

FormulaProductInformation/CommodityBase

For ETDs:

If ETDTradeDetails/PrimaryAssetClass = "CO" then


TDProductInformation/CommodityBase if present

else

derive from ETDTradeDetails/Product/CRAProductCode

else

this field must be set to “NA”


n/a

Commodity

details


Derive similarly to above from


erence[1]/IndexCommodity mapping CpML values to

EMIR classifications


CpMLDocument/Reporting/Europe/EURegulatoryDetails:/

FormulaProductInformation/CommodityDetail set to "NA"

For ETDs:

If 'Commodity Base' is present in the output message

then this field must be present and derive from

ETDTradeDetails/Product/CRAProductID else it must be

set to "NA".


n/a


of 119

Underlying UnderlyingType For OTC Commodity transactions

:

If


erences/CommodityReference element occurs only once

then set to the value "I" for 'Index'

Else

set to the value "B" for 'Basket


CpMLDocument/Reporting/Europe/EURegulatoryDetails/F

ormulaProductInformation/Underlying

For ETDs:


TDProductInformation/Underlying if present

else


For OTC IR transactions:

IRSTradeDetails/SwapStream/CalculationPeriodAmount/

Calculation/FloatingRateCalculation/FloatingRateIndex

n/a

For OTC FX transactions:

n/a

BeneficiaryI

D

If 'Trading Capacity' <> "A" then this field is set to the

same value as the value as ‘CounterpartyID’ and in the

case of the other counterparty to ‘OtherCounterPartyID’.

Collateralisa

tion

If 'Clearing Threshold' = "N" then this field will be set to

“NA” in the output message

Transaction

Reference

Number

ETDTradeDetails/ClearingParameters/DealID if

present, else

CpMLDocument/Reporting/Europe/EURegulatoryDe

tails/TradeID


of 119

Price/Rate For OTC Commodity transactions

FXD_SWP:

TradeConfirmation/DeliveryPeriods/FixedPrice for the 'fixed price'

OPT*:

TradeConfirmation/OptionDetails/TotalPremiumValue

FLT_SWP:

TradeConfirmation/FloatPriceInformation[1]/CommodityReference[1-

n]/SpreadInformation/SpreadAmount or Spread Rate if present until the

first occurrence of a non zero value is found

else TradeConfirmation/FloatPriceInformation[2]/CommodityReference[1-



else "0"

PHYS_INX:

TradeConfirmation/FloatPriceInformation/CommodityReference[1-



else

"0"

FOR:

CpMLDocument/TradeConfirmation/TimeIntervalQuantity[1]/Price

or if Commodity is an 'Emissions Commodity'

CNF/EUATradeDetails/Price


FXD_SWP:

TradeConfirmation/DeliveryPeriods/FixedPrice for the 'fixed price'

else

CpMLDocument/TradeConfirmation/Currency

OPT*:

TradeConfirmation/OptionDetails/TotalPremiumValue

FLT_SWP:

TradeConfirmation/FloatPriceInformation[1]/FormulaSpreadInformation/Spr

eadAmount or Spread Rate if present

else

TradeConfirmation/FloatPriceInformation[2]/FormulaSpreadInformation/Spr

eadAmount or Spread Rate if present

else

"0"

PHYS_INX:

TradeConfirmation/FloatPriceInformation/FormulaSpreadInformation/Spread

Amount or Spread Rate

else

"0"

For ETDs:

ETDTradeDetails/ClearingParameters/UnitPrice


If payload = IRT then set to 999999999999999.99999 in the output

message



SUM(FXTradeDetails/FXOption/PremiumPayments[1-

n]/PremiumPaymentValue)

else

FXTradeDetails/FXSingleLeg[1]/ExchangedRate[1]/SpotRate +

FXTradeDetails/FXSingleLeg[1]/ExchangedRate[1]/ForwardPoints


of 119

PriceNotatio

n

For OTC Commodity transactions

FXD_SWP:

CpMLDocument/TradeConfirmation/FixedPriceInformation/FPCurrency for

the 'fixed price' if present

else


OPT*:

CpMLDocument/TradeConfirmation/OptionDetails/PremiumCurrency

FLT_SWP:

CpMLDocument/TradeConfirmation/FloatPriceInformation[p]/CommodityRef

erence[q]/SpreadInformation/SpreadCurrencyUnit or "100" for a

SpreadRate

where [p] and [q] identify the first occurrence of a non zero value in

TradeConfirmation/FloatPriceInformation[1-2]/CommodityReference[1-

n]/SpreadInformation/SpreadAmount or Spread Rate

else


PHYS_INX:

CpMLDocument/TradeConfirmation/FloatPriceInformation[1]/CommodityRef

erence[q]/SpreadInformation/SpreadCurrencyUnit or "100" for a

SpreadRate

where [q] identify the first occurrence of a non zero value in

TradeConfirmation/FloatPriceInformation[1]/CommodityReference[1-

n]/SpreadInformation/SpreadAmount or Spread Rate

OR


FOR:



FXD_SWP:

CpMLDocument/TradeConfirmation/FixedPriceInformation/FPCurrency for

the 'fixed price' if present

else


OPT*:

CpMLDocument/TradeConfirmation/OptionDetails/PremiumCurrency

FLT_SWP:

CpMLDocument/TradeConfirmation/FloatPriceInformation[p]/FormulaSpread

Information/SpreadCurrencyUnit or "100" for a SpreadRate

where [p] identifies the first occurrence of a non zero value in

TradeConfirmation/FloatPriceInformation[1-

2]/FormulaSpreadInformation/SpreadAmount or Spread Rate

else


PHYS_INX:

CpMLDocument/TradeConfirmation/FloatPriceInformation[1]/FormulaSpread

Information/SpreadCurrencyUnit or "100" for a SpreadRate

OR


FOR:

CpMLDocument/TradeConfirmation/CurrencyFor


of 119

PriceNotatio

n

(continued)

For ETDs:


TDProductInformation/PriceNotation if present

else




FXTradeDetails/FXOption/PremiumPayments[1]/Premium

Currency

else

FXTradeDetails/FXSingleLeg[1]/ExchangeCurrency[1]/Pa

ymentCurrency


If payload = IRT then set to “NA” in the output message

Price

Multiplier

If payload is not ETD then set to 1 in the output message

else


TDProductInformation/PriceMultiplier if present

else


Table 4 Generated Data Fields Derived from Look Up On Cleared Product Code


Underlying UnderlyingType Derived from look up on


Notional

currency 1

CurrencyCodeTyp

e

Derived from look up on


Notional

currency 2

CurrencyCodeTyp

e



Deliverable

currency

CurrencyCodeTyp

e



Price

Notation

CurrencyCodeTyp

e



Price

multiplier

QuantityType Derived from look up on


TotalVolum

eQuantity

Unit

UnitOfMeasureTyp

e



Delivery

type

SettlementType Derived from look up on


Effective

date

DateType ETDTradeDetails/Product/DeliveryPeriod/StartDate (if

present)

otherwise



of 119

Maturity

date

DateType ETDTradeDetails/Product/DeliveryPeriod/EndDate (if

present)

otherwise


Commodity

base

CommodityBaseT

ype



else this field must be omitted in the output messge.

Commodity

Detail

CommodityDetailT

ype



else this field must be omitted in the output messge.

Delivery

point or

zone

AreaType Derived from look up on


Interconne

ction Point

AreaType Derived from look up on


Load type LoadTypeType Derived from look up on


Contract

capacity

QuantityType Derived from look up on


EnergyQua

ntity Unit

UnitOfMeasureTyp

e



Delivery

start date

and time

UTCTimeStampTy

pe

If ETDTradeDetails/Product/DelvieryPeriod is present

then

ETDTradeDetails/Product/DelvieryPeriod/DeliveryStartDa

teAndTime

else

derive from ETDTradeDetails/Product/CRAProductCode.

Delivery

end date

and time

UTCTimeStampTy

pe

If ETDTradeDetails/Product/DelvieryPeriod is present

then

ETDTradeDetails/Product/DelvieryPeriod/DeliveryEndDat

eAndTime

else

derive from ETDTradeDetails/Product/CRAProductCode.

Currency 2 CurrencyCodeTyp

e

The cross currency, if different from the currency

of delivery.

Exchange

rate 1

PriceType The contractual rate of exchange of the currencies.

Exchange

rate basis

QuoteBasisType Quote base for exchange rate.

Fixed rate

of leg 2

QuantityType An indication of the fixed rate leg 2 used, if

applicable.

Fixed rate

day count

DayCountFraction

Type

The actual number of days in the relevant fixed

rate payer calculation period, if applicable.

Fixed leg

payment

frequency

FrequencyPeriodT

ype

Frequency of payments for the fixed rate leg, if

applicable.


of 119

Floating

rate

payment

frequency

FrequencyPeriodT

ype

Frequency of payments for the floating rate leg, if

applicable.

Floating

rate reset

frequency

FrequencyPeriodT

ype

Frequency of floating rate leg resets, if applicable.

Floating

rate of leg

1

RateIndexType An indication of the interest rates used which are

reset at predetermined intervals by reference to a

market reference rate, if applicable.

Floating

rate of leg

2

RateIndexType An indication of the interest rates used which are



REFERENCE FIELDS

Reference Fields comprise fields the values of which can be derived from looking up external data

sources


OtherCPEE

A

TrueFalseType Looked up from LEI data source.

Clearing

obligation

TrueFalseType Looked up from ESMA data source.

CpML Field Mappings to EMIR and REMIT Data Requirements

See Appendix B CpML Field Mappings to EMIR and REMIT Requirements

Message Processing

The eRR Process accepts input messages and responds with ‘Box Results’.

You may receive more than one box results per submission. For example, you submit a NEW report,

you will get a box results saying it was accepted by eRR, and a second saying it was accepted by the

TR

There is a millisecond timestamp on the message and you should always sort the box results by that.

Box Results are classified in to three sequential stages each with its own major ‘action’: “Submit”,

“Processing” and “Reporting”. At each stage a successful result is signified by receipt of a Box Result

document containing positive feedback for example, for the successful submission of a report the Box

Result “Submit”/”OK” is returned. On completion a successfully submitted report will have a Box

Result from each stage: “Submit”/”OK”, “Processing”/”Report”, “Reporting”/”OK”. In case of an error

at any point a Box Result will be returned containing the ‘action’ and information on the error:

“Submit”/”Error/Reason”.


of 119

3 Electronic Business Processes – by Document

Types

The CpML data formatting standard is used to define eRR Process documents, for a full description of

the CpML schema descriptions refer to [1]. This section contains the proposed extension to [1] arising

out of the requirements of the eRR Process.

3.1 Naming and Typing Conventions

Document rules check the validity of data within a given document against the document type

definition.

Agreed abbreviations for document types:

- “CPD” for the CpMLDocument

- “VAL” for Valuation Document

- “COL” for Colateralisation Document

- “CON” for Confirmation Event Document

Partner Identification

Valid ‘PartyIDType’ are: Energy Identification Codes (EIC Codes) or Legal Entity Identifiers (LEI

codes); if EIC codes are used then they must be used consistently throughout a document and if LEI

codes are used then they must be used consistently throughout the document, it is not permitted to

identify Parties within a single document using both EIC and LEI codes.

Document IDs

Often, documents are listed in reporting tools, as XSL stylesheets, etc. To provide a common syntax

that is comprehensible and maintains uniqueness, a rule for creating unique Document IDs is defined

as follows as a mandatory requirement for all CpML documents:

A composition of the following components NOT exceeding a total character length of more then 50

characters in all:

- Document type abbreviation (e.g. “CPD” for CpMLDocument)

- DateCode (8 characters, in yyyymmdd format),

- Locally unique TradeID (or Strategy ID) (min. 10 characters excluding “underscore” characters)

of the sender side

- “@”

- Sender identification, i.e. domain name of the sender.

Example:

[email protected]

This document ID shall correspond with the MessageID of the ebXML Message Service and should be

comprehensible for human users.

Constraints on Document ID Usage in the eRR Process

A document ID is unique per sender and per trade. This means that if a Document ID is used to first

report a trade this document ID must never change in the future for this trade.

All amendments for this trade will use the same document ID.

The eRR Process must reject a document if

• The Document ID is already in use by another customer


of 119

• A document with Document ID “123” contains a UTI that is known to the CMS with document

ID “567” (from the same sender)

For payload document types: CNF, IRT and FXT the ReceiverID MUST be set to the

identification code use to identify the other counterparty to the trade: other than the SenderID

For payload document type ETD apply the rules as described in 3.5 ETD Trade Details (ETD)

Optionality in Input Message Fields

Many of the fields in the eRR input message (the CpMLDocument) within the ‘Europe’ section are

optional or conditional and can be omitted. This permits discretion on behalf of the process user as to

how rich the input message that they submit to the process can be. A richer message reduces the

amount of processing need to complete the message ahead of submittion to the underlying

repositories and databases. A less rich message leave more to be completed by the process. In this

way the associated processing behind each field can be insourced by the process user or outsourced.

For example the ‘EMIRReportingMode’ field allows the user to evaluate the transaction for eligibility

inhouse and enter the result using the appropriate value supported by the process for this field, or

indicate that the service implementing the process should establish the eligibility of the transaction for

reporting to EMIR based on the standard filtering criteria. This is a general principle behind the

process as set out previously in High Level Counterparty Output Message Processing.

Document ID and the Reporting of Lifecycle Events

Table 5 Reporting Lifecycle Events shows a sequence of lifecycle events reported through eRR for a

transaction.

Table 5 Reporting Lifecycle Events

User Message Data Data sent to eRR

# Date Action User ID Our

version

UTI Document ID (including type)

1 23/08/2013 Buy

created

87654321 1 ACMELEIxx_12345678901234

567890123456789012

CPD_20130823_0087654321@A

CMEtrading.com

2 23/08/2013 Term in

trade CNF

amended

87654321 2 ACMELEIxx_12345678901234

567890123456789012

CPD_20130823_0087654321@A

CMEtrading.com

3 24/08/2013 Term in

trade CNF

amended

87654321 3 ACMELEIxx_12345678901234

567890123456789012

CPD_20130823_0087654321@A

CMEtrading.com

4 25/08/2013 Term in

EU

envelope

changed

87654321 4 ACMELEIxx_12345678901234

567890123456789012

CPD_20130823_0087654321@A

CMEtrading.com

5 26/08/2013 UTI

amended

to that of

the seller

based on

confirm

87654321 5 CPTYLEIxx_210987654321098

76543210987654321

CPD_20130823_0087654321@ed

ftrading.com

6 26/08/2013 Trade

confirmed

87654321 CPTYLEIxx_210987654321098

76543210987654321

CON_20130826_0087654321@A

CMEtrading.com

mailto:[email protected]













of 119

3.2 European Regulatory Reporting Envelope Fields

CpML Document (CPD) – Document Root

Table 6: Specification of Elements

Name Usage Type Key/

Info

Business Rule

CpMLDocument

Mandatory Section within CpMLDocument: Reporting

Mandatory Section within Reporting: Europe

Mandatory Section within Europe: ProcessInformation

ReportingRo

le

C ReportingRoleTyp

e

Key If ‘ReportingRole’ = “Clearing_Agent” then the payload

document must = “ETDTradeDetails”.

N.B. CP_Agent or Clearing_Agent must be a party to the

transaction described in the <payload> Document.

Internal_Agent or Execution_Agent must not be a party

to the transaction described in the <payload>

Document.

If the transaction being reported is an intra group

transaction being reported on behalf of another group

entity and the reporting entity is a party to the

transaction then the ReportingRole should be set to

“CP_Agent”, otherwise if the reporting entity is not a

party to the transaction (i.e. the trade is between two

other group entities or a group entity and an external

organisation) then the ReportingRole should be set to

“Internal_Agent”.

EMIRReport

Mode

M ReportModeType Key

REMITRepor

tMode

M ReportModeType Key

Position C TrueFalseType Key If the payload document is an ETDTradeDetails then

This field must be present

Else

This field must be omitted

If present this field must be set to “Y” if the payload

document describes a position and it must be set to “N”

if the payload document describes an individual

transaction.

Backload M TrueFalseType Key This field must be set to “True” if the message is to be

treated as back loaded information otherwise it must be

set to “False”.

End of Process Information Section

Mandatory Section within Europe: Action


of 119

ActionType M ActionTypeType Key Whether the report contains:

• a derivative contract or post-trade

event for the first time, in which case it will be identified

as new

• a modification of details of a

previously reported derivative contract, in which case it

will be identified as modify

• a cancellation of a wrongly

submitted report, in which case, it

will be identified as error

• a termination of an existing contract,

in which case it will be identified as

cancel

• a compression of the reported

contract, in which case it will be

identified as compression

• any other amendment to the report,

in which case it will be identified as other.

N.B. The “Z” flag for compression should be used to

indicate the event of a compression in the life of a

previously reported transaction, or, in the case of

exchange traded derivatives, a close-out event or to

indicate that the ETD transaction has been aggregated

into a position for reporting purpses.

The ‘V’ flag for valuation must not be used. Valuations

are submitted using the dedicated Valaution document.

If ‘Backload’ = “True” then this field must contain the

value “N” ensuring that any backloaded report is loaded

as a new action.

ActionDetail C ActionDetailType Key If ‘Action Type’ = “O” then


Else

This field must be omitted.

N.B. in the case of an amendment arising from a

novation this field must contain the statement

“Novation”.

End of Action Section


of 119

Mandatory Section with Europe: EURegulatoryDetails

If 'ReportingRole' = "Trader" or “CP_Agent” or “Clearing_Agent” then this section must be completed from the

perspective of the sender ( if ‘Sender ID’ = ‘BuyerParty’ then the sender is the Buyer, else if ‘Sender ID’ =

‘SellerParty’ then the sender is the Seller)

Else if

“ActingOnBehalfOf” = “Buyer” then this section must be completed from the perspective of the “BuyerParty” in the payload document

Else if

“ActingOnBehalfOf” = “Seller” then this section must be completed from the perspective of the “SellerParty”

in the payload document

document

Else if

“ActingOnBehalfOf” = “Buyer_And_Seller” then this section must be completed from the perspective of the

“BuyerParty” in the payload document

UTI O UTIType Key If not present in the input message then

this field will be generated and used to populate the output message

else

this value will be used to populate the output message.

Repository C RepositoryType Key If this field is omitted in the input message then the field

must be present in the Standing Instructions for the

Counterparty reporting this transaction or on whose

behalf this transaction is being reported by an agent and

the Standing Instructions will be used to populate the

output message or it will be set to the default value in

the output message.

ReportingTi

mestamp

O UTCTimestampTy

pe

Key If not present in the input message then

this field will be generated at the time of creation of the output message and added to the output message

else


CPIDCodeTy

pe

O CPIDCodeTypeTyp

e


then the field must be present in the Standing Instructions for the Counterparty reporting this transaction or on whose behalf this transaction is being reported by an agent and the Standing Instructions will be used to populate the output message or it will be set to the default value in the output message.

else

this value will be used to populate the output

message.

Default value = “LEI”.

The value of this field will apply to the codification

scheme for both the Counterparty AND the Other

Counterparty to the transaction being reported.

N.B. the format of the ‘Buyer Party’ and ‘Seller Party’ in

the payload document must be validated against this

code type.


of 119

TraderUserN

ame

C NameType Key Current assumption: only required to be reported by the

platform where the deal was executed. If this is not

being reported by the platform then the login details to

the platform are not known.

If 'ReportingRole' = "Execution_Agent" then this must be

present otherwise it must not be present.

OtherTrader

UserName

C NameType Key Current assumption: only required to be reported by the


being reported by the platform then the login details to

the platform are not known.

If 'ReportingRole' = "Execution_Agent" then this must be


Condition Section within EURegulatoryDetails: ReportingCounterpartyDetails (0-

1)

If 'CPID Code Type' <> "LEI" and this section is omitted in the input message then these fields must be present

in the Standing Instructions for the Counterparty reporting this transaction and the Standing Instructions will be

used to populate the output message.

CPName M CPNameType Key

CPDomicile M CPDomicileType Key

End of ReportingCounterpartyDetails Section

CPFinancial

Nature

O CPFinancialNature

Type

Key If this field is omitted in the input message then the field





output message.

CPSector C CorporateSectorT

ype

Key If ‘CPFinancialNature' = "F" then

• this field may be present

else

• this field must not be present.

If 'CPFinancialNature' = "F" and this field is omitted in

the input message then the field must be present in the

Standing Instructions for the Counterparty reporting this

transaction or on whose behalf this transaction is being

reported by an agent and the Standing Instructions will


BeneficiaryI

D

C PartyType Key If 'Trading Capacity' = "A" then

this field may be present

else

this field must not be present and the value in the output message will be set to the same value as the value as ‘CounterpartyID’.

If 'Trading Capacity' = "A" and this field is omitted in the

input message then the field must be present in the


transaction or on whose behalf this transaction is being

reported by an agent and the Standing Instructions will



of 119

TradingCapa

city

O TradingCapacityT

ype






output message.

OtherCPEEA O TrueFalseType Key If this field is omitted in the input message then the field

must be mapped from LEI reference data and used to

populate the output message; otherwise the value in this

field must be used to populate the output message

Commercial

orTreasury

C TrueFalseType Key If ‘CPFinancialNature’ = “F” then

this field must not be present

else

this field may be present.

If this field is omitted in the input message and the

payload document does not describe an ETD position

(the payload document is not an ETDTradeDetails or

‘Position’ = “False”) then the field must be present in the


transaction, or on whose behalf this transaction is being

reported by an agent, and the Standing Instructions will


ClearingThre

shold



else

this field must be present.






output message.

N.B. this value could be generated within the eRR

process by summarising the ‘Notional Amount’ in all

EMIR compliant output messages for this reporting

counterparty.

Collateralisa

tion

C CollateralisationTy

pe

Key If 'Clearing Threshold' = "N" then this field must be

omitted, and the value in the output message will be set

to “NA”

else if

this field is omitted in the input message then the field





output message.


of 119

Collateralisa

tionPortfolio

C TrueFalseType Key If 'Clearing Threshold' = "False" or ‘Collateralisation’ =

“U” then


Else

If this field is omitted in the input message then the

field must be present in the Standing Instructions

for the Counterparty reporting this transaction or on

whose behalf this transaction is being reported by

an agent and the Standing Instructions will be used

to populate the output message or it will be set to

the default value in the output message.

Default = “True”.

Collateralisa

tionPortfolio

Code

O PortfolioCodeType Key If 'Clearing Threshold' = "N" or ‘Collateralisation’ = “U”

or CollateralisationPortfolio = “N” then


Else








Conditional Section within EURegulatoryDetails: ReportingOnBehalfOf

If 'ReportingRole' <> "Trader" then this section must be present otherwise it must not be present.

ActingOnBeh

alfOf

C OnBehalfOfType Key If ‘ReportingRole’ = “CP_Agent” or “Clearing_Agent” or if

(payload document = “ETDTradeDetails” and

‘ReportingRole’ = “Internal_Agent”) then this field must

NOT contain the value “Buyer_And_Seller” since the

Counterparty Agent or Clearing Agent must be a party to

the transaction being reported (see business rule for

‘AgentID’), or in the case of an ETD the Internal_Agent

cannot know the identity of the other counterparty since

the deal is cleared and anonymous.

If payload document = “ETDTradeDetails” and

‘ReportingRole’ = “Execution_Agent” then

<payload>/SenderID = ‘AgentID’

Else if ‘ReportingRole’ = “Internal_Agent” and

‘ActingOnBehalfOf’ = “Buyer” then

<payload>/SenderID = <payload>/BuyerParty

Else if ReportingRole’ = “Internal_Agent” and

‘ActingOnBehalfOf’ = “Seller” then

<payload>/SenderID = <payload>/SellerParty

AgentID C PartyType Key If ‘ReportingRole’ = “CP_Agent” or “Clearing_Agent” then

‘AgentID’ = <payload>/SenderID


of 119

Conditional Section within ReportingOnBehalfOf: OtherCounterpartyDetails

If ReportingRole = “ExecutionAgent” or “InternalAgent” and ‘ActingOnBehalfOf’ = “Buyer_And_Seller”

then this section may be present and, if present, must refer to the “SellerParty” in the payload document,

else

if ReportingRole = “CP_Agent” or “Clearing_Agent”, then this section may be present. If this section is

present and ‘ActingOnBehalfOf’ = “Buyer” then this section must refer to the the “BuyerParty” in the

payload document else this section must refer to the the “SellerParty” in the payload document

else

this section must be omitted.

Conditional Section within OtherCounterpartyDetails: Reporting Counterparty

Details (0-1)

If 'CPID Code Type' <> "LEI" and this section is omitted in the input message then these fields must be present

in the Standing Instructions for the Counterparty reporting this transaction and the Standing Instructions will be

used to populate the output message.

CPName M CPNameType Key

CPDomicile M CPDomicileType Key

End of ReportingCounterpartyDetails Section







the output message.

CPFinancial

Nature

O CPFinancialNature

Type






output message.

CPSector C CorporateSectorT

ype

Key If ‘CPFinancialNature’ = “F” then

this field must be present

else

this field must not be present.

BeneficiaryI

D

C PartyType Key If 'Trading Capacity' = "A" then

this field may be present

else

this field must not be present and the value in the output message will be set to the same value as the value as ‘OtherCounterpartyID’.

If 'Trading Capacity' = "A" and this field is omitted in the

input message then the field must be present in the Standing Instructions for the Counterparty reporting this transaction or on whose behalf this transaction is being reported by an agent and the Standing Instructions will be used to populate the output message.


of 119

TradingCapa

city

C TradingCapacityT

ype






output message.

OtherCPEEA C TrueFalseType Key If this field is omitted in the input message then the field

must be mapped from LEI reference data and used to

populate the output message; otherwise the value in this

field must be used to populate the output message.

Commercial

orTreasury



else

this field may be present. If this field is omitted in the input message and the payload document does not describe an ETD position (the payload document is not an ETDTradeDetails or ‘Position’ = “False”) then the field must be present in the Standing Instructions for the Counterparty reporting this transaction, or on whose behalf this transaction is being reported by an agent, and the Standing Instructions will be used to populate the output message.

ClearingThre

shold



else

this field must be present.






output message.

N.B. this value could be generated within the eRR

process by summarising the ‘Notional Amount’ in all

EMIR compliant output messages for this reporting

counterparty.

Collateralisa

tion

C CollateralisationTy

pe

Key If 'Clearing Threshold' = "False" then this field must be

omitted, and the value in the output message will be set

to “NA”

else if

this field is omitted in the input message then the field





output message.


of 119

Collateralisa

tionPortfolio

C TrueFalseType Key If 'Clearing Threshold' = "False" or ‘Collateralisation’ =

“U” then


Else








Default = “Y”.

Collateralisa

tionPortfolio

Code

C PortfolioCodeType Key If 'Clearing Threshold' = "N" or ‘Collateralisation’ = “U”

or CollateralisationPortfolio = “N” then


Else








End of within OtherCounterpartyDetails

End of within ReportingOnBehalfOf

Optional Section within EURegulatoryDetails: ProductIdentifier

If this section is omitted in the input message then these fields will be generated based on the default value for

‘Taxonomy’ and used to populate the output message.

Taxonomy O TaxonomyType Key If this field is omitted in the input message then the field






the output message.

Default = “E”.

TaxonomyCo

deType

O TaxonomyCodeTy

pe







the output message.


Conditional Section: EProduct below ProductIdentifier

If 'Taxonomy Type' = "EMIR_Taxonomy" and 'Taxonomy' = "E" then


of 119

EProductID1 M EProduct1CodeTy

pe

Key If payload document = CNF then this field = "CO" in the

output message

else

if payload document = IRSTradeDetails then this field must = "IR"

else

if payload document =ETDTradeDetails then this field = ETDTradeDetails/PrimaryAssetClass

else if payload document = FXTradeDetails then this field

= “CU”.

Product1Cod

eType

O TaxonomyCodeTy

pe





EProductID2

M EProduct2CodeTy

pe

Key If payload document = CNF then

if CNF/TransactionType = "FOR" or “PHYS_INX” this field must = "FW"

else if CNF/TransactionType = "OPT" or "OPT_PHYS_INX" or " OPT_FIN" or "OPT_FXD_SWP" or "OPT_FLT_SWP" then this field must = "OP"

else if CNF/TransactionType = "FXD_SWP" or "FLT_SWP" then this field must = "SW"

If payload document = IRSTradeDetails then if IRSTradeDetails/TransactionType =

"OPT_FXD_SWP" or "OPT_FLT_SWP" or "OPT_FXD_FXD_SWP" then this field must = "OP"

else if IRSTradeDetails/TransactionType = "FXD_SWP" or "FLT_SWP" or "FXD_FXD_SWP"then this field must = "SW"

If payload document = FXTradeDetails then if FXTradeDetails/TransactionType = "OPT" or

"OPT_FXD_FXD_SWP" then this field must = "OP" else if FXTradeDetails/TransactionType =

"FXD_FXD_SWP" then this field must = "SW" else if FXTradeDetails/TransactionType = "FOR" or

“SPT” then this field must = “FW”

If payload document =ETDTradeDetails then

if ETDTradeDetails/TransactionType = "FOR" or “SPT” this field must = "FW"

if ETDTradeDetails/TransactionType = “OPT” or "OPT_FXD_SWP" or "OPT_FLT_SWP" or "OPT_FXD_FXD_SWP" or “OPT_FIN” then this field must = "OP"

else if ETDTradeDetails/TransactionType = "FXD_SWP" or "FLT_SWP" or "FXD_FXD_SWP"then this field must = "SW"

else if ETDTradeDetails/TransactionType = “FUT” or “OPT_FUT” then this field = "FU"

Conditional Section: UProduct below Product Identifier

If 'Taxonomy Type' = "EMIR_Taxonomy" and 'Taxonomy' = "U" then

UProductID1 M UProductCodeTyp

e

Key

Product1Cod

eType

O TaxonomyCodeTy

pe





Conditional Section: IProduct below Product Identifier

If 'Taxonomy Type' = "EMIR_Taxonomy" and 'Taxonomy' = "I" then


of 119

IProduct ID

1

M IProduct1CodeTyp

e

Key The ISIN or Aii.

Product1Cod

eType

O TaxonomyCodeTy

pe





IProductID2 M IProduct2CodeTyp

e

Key The CFI.

End of Product Identifier Section

UnderlyingC

odeType

O UnderlyingCodeTy

peType







the output message.

Default = "UPI"

LinkedTrans

actionID

C UTIType Key Current assumption: only required to be reported by the


being reported by the platform then there can be no

transactions linked by a platform.

If 'ReportingRole' = "Execution_Agent" then this may be


TradeID M TradeIDType Key The internal Trade ID of the Counterparty reporting the

transaction.

If 'ReportingRole' = "Execution_Agent" then this will be

the transaction ID given by the platform to both the buy

and the sell sides of the transaction since the internal

Trade ID of the Counterparty will not be known to the

Execution Agent.

VenueOfExe

cution

M VenueOfExecution

Type

Key If this transaction was executed on a Regulated Market

or MTF then

this field must contain the MIC code of the venue

Else

if the transaction was a ‘listed derivative’ executed on a venue that is not a Regulated Market or MTFthen this field must contain the value: “XOFF”

Else

this field must contain the value: “XXXX”.

Compression O TrueFalseType Key If this field is omitted in the input message then the field



Default = "False"

Must be set to "True" if the transaction was the result of

compression; otherwise "False".

UpFrontPay

ment

O PriceType Key If there is an upfront payment to report then this field

must be present in the input message and must contain

a value; otherwise it must not be present.


of 119

Upfront

Payment

Currency

C CurrencyCodeTyp

e

Info If UpFrontPayment is present then


Else

this field must be omitted.

ExecutionTi

mestamp

O UTCTimestampTy

pe

Key If this field is omitted in the input message then it will

be set to the the Trade Date and Trade Time fields

defined within the <payload> document and these

values will be used to populate the output message.

Time of entry into the system of record of the reporting

counterparty or of the agent reporting on behalf of the

reporting counterparty.

MasterAgree

mentVersion

O MasterAgreement

VersionType

Key The ‘vintage’ of the agreement under which the reported

transaction was executed.







the output message.

ClearingObli

gation

O TrueFalseType Key If this field is omitted in the input message then the field

will be looked up from the external ESMA reference

source, if no value is found then this value will be set to

the default value and the default value will be used to

populate the output message.

Default = "False"

Intragroup M TrueFalseType Key

LoadType C LoadTypeType Key If <payload> is a CNF and

TradeConfirmation/Commodity = "Power" or "Gas" then

this field must be present in the input message

otherwise it must not be present.

Confirmatio

nMeans

M ConfirmationMean

sType

Key Whether the contract was electronically confirmed, non-

electronically confirmed or remains unconfirmed.

Confirmatio

nTimestamp

C UTCTimestampTy

pe

Key Date and time of the confirmation of the transaction with

this UTI, as defined under Regulation (EC) the xx/2012

[Commission delegated regulation endorsing draft

regulatory technical standards on OTC Derivatives]

indicating time zone in which the confirmation has taken

place.

If ‘ConfirmationMeans’ = “N” then

this field must be omitted

Else



of 119

Notional

Amount

C QuantityType Key If the payload document is a ‘CNF’ and TransactionType

= “PHYS_INX” or “OPT_PHYS_INX” or (“FLT_SWP” AND

the CommodityRefernece, if present, has more than one

occurrence within either FloatPriceInformation section)

then this field

is mandatory

else

it is optional


will be derived from the Payload Document and the

result will be added to the output message.

Early

Termination

Date

O DateType Info Termination date of the reported contract.

If ActionType = “C” or “Z” or Backload = True then

This field may be present

Else


Conditional Repeatable Section within EURegulatoryDetails: SettlementDates (0-

n)

If the payload document is a ( ‘CNF’ and TransactionType = “FOR” or “PHYS_INX”) or if the payload document is

an ‘ETDTradeDetails’ or if the payload document is an (‘IRSTradeDetails’ and "FXD_SWP" or

"FXD_FXD_SWP" or "FLT_SWP") then this section must be present, otherwise this section may be present.

N.B. If this section is not present then the payload document will be used as the source of the Settlement

Date(s).

DateOfSettle

ment

M DateType Key Use the final settlement date if multiple settlement dates

exist for the transaction.

For OTC Swaps and Physical Forwards use the last date

of settlement of the derivative contract.

For Options use the premium payment date

For exchange traded derivatives being reported then use

the logic: the Date of Settlement is the greater of the

Maturity Date or the Cease Date.

End of Settlement Dates Section

Optional Section within EURegulatoryDetails: ETDProductInformation

An optional section containing explicit values derived from ETD product definitions.

Underlying M UnderlyingType Info The underlying shall be identified by using a unique

identifier for this underlying. In case of baskets or

indices, an indication for this basket or index shall be

used where a unique identifier does not exist.

Notional

currency 1

M CurrencyCodeTyp

e

Info The currency of the notional amount. In the case of an

interest rate derivative contract, this will be the notional

currency of leg 1.

Notional

currency 2

O CurrencyCodeTyp

e

Info The currency of the notional amount. In the case of an

interest rate derivative contract, this will be the notional

currency of leg 2.

Deliverable

currency

M CurrencyCodeTyp

e

Info The currency to be delivered.


of 119

Price

Notation

M PriceNotationType Info The manner in which the price is expressed.

Price

Multiplier

M QuantityType Info The number of units of the financial instrument which

are contained in a trading lot; for example, the number

of derivatives represented by one contract.

TotalVolum

eQuantity

Unit

C UnitOfMeasureTyp

e

Info The unit of measurement used.

If CpMLDocument/ETDTradeDetails/PrimaryAssetClass =

“Commodity” then:


Else

It must be omitted

Delivery

type

M SettlementType Info Indicates whether the contract is settled physically or in

cash.

Effective

date

M DateType Info Date when obligations under the contract come into

effect.

Maturity

date

M DateType Info Original date of expiry of the reported contract. An early

termination shall not be reported in this field.

Commodity

Base

C CommodityBaseT

ype

Info Indicates the type of commodity underlying the contract.




Else

It must be omitted

Commodity

Detail

C CommodityDetailT

ype

Info Details of the particular ‘Commodity Base’.




Else

It must be omitted

Delivery

point or

zone

C AreaType Info Delivery points(s) of market area(s).




Else

It must be omitted

Interconne

ction Point

C AreaType Info Identification of the border(s) or border point(s) of

a transportation contract.




Else

It must be omitted


of 119

Load type C LoadTypeType Info The product delivery profile which correspond to

the delivery periods of a day.




Else

It must be omitted

Contract

capacity

C QuantityType Info Quantity per delivery time interval.




Else

It must be omitted

Energy

Quantity

Unit

C UnitOfMeasuretyp

e

Info Daily or hourly quantity in MWh or kWh/d which

corresponds to the underlying commodity.




Else

It must be omitted

Delivery

start date

and time

C UTCTimestampTy

pe

Info Start date and time of delivery.




Else

It must be omitted

Delivery

end date

and time

C UTCTimestampTy

pe

Info End date and time of delivery.




Else

It must be omitted

Currency 2 C CurrencyCodeTyp

e

Info The cross currency, if different from the currency

of delivery.


“ForeignExchange” then:


Else

It must be omitted

Exchange

rate 1

C PriceType Info The contractual rate of exchange of the currencies.




Else

It must be omitted


of 119

Exchange

rate basis

C QuoteBasisType Info Quote base for exchange rate.




Else

It must be omitted

Fixed rate

of leg 2

C QuantityType Info An indication of the fixed rate leg 2 used, if

applicable.


“InterestRate” then:


Else

It must be omitted

Fixed rate

day count

C DayCountFraction

Type

Info The actual number of days in the relevant fixed

rate payer calculation period, if applicable.




Else

It must be omitted

Fixed leg

payment

frequency

C FrequencyPeriodT

ype

Info Frequency of payments for the fixed rate leg, if

applicable.




Else

It must be omitted

Floating

rate

payment

frequency

C FrequencyPeriodT

ype

Info Frequency of payments for the floating rate leg, if

applicable.




Else

It must be omitted

Floating

rate reset

frequency

C FrequencyPeriodT

ype

Info Frequency of floating rate leg resets, if applicable.




Else

It must be omitted


of 119

Floating

rate of leg

1

C RateIndexType Info An indication of the interest rates used which are






Else

It must be omitted

Floating

rate of leg

2

C RateIndexType Info An indication of the interest rates used which are






Else

It must be omitted

End of ETDProductInformation

Conditionl Section within EURegulatoryDetails: FormulaProductInformation

If the payload document within the CpMLDocument is a CNF and if the CNF contains a FormulaID within the

Float Price Information then this section must be present otherwise it must not be present.

Underlying M UnderlyingType Info The underlying shall be identified by using a unique

identifier for this underlying. In case of baskets or

indices, an indication for this basket or index shall be

used where a unique identifier does not exist.

Commodity

Base

M CommodityBaseT

ype

Info Indicates the type of commodity underlying the contract.

Commodity

Detail

M CommodityDetails

Type

Info Details of the particular ‘Commodity Base’.

IndexCurre

ncyUnit

O CurrencyCodeTyp

e

Info The currency of the notional amount.

End of FormulaProductInformation

End of EURegulatoryDetails

End of Europe

End of Reporting

End of CpMLDocument


of 119

3.3 European Regulatory Reporting Valuation Message

Regulatory Valuation (VAL) – Document Root



Info

Business Rule

DocumentID M IdentificationType Info When a party receives a document with an ID unknown

to the receiver then the receiver must treat this

document as the initial version of a new document.

Otherwise the receiver must treat this document as an

amendment of an already sent document (see field

“Document Version”).

DocumentUs

age

M UsageType Info “Test” or “Live”

SenderID M PartyType Info Party code of Sender

This field identifies the sender who is either the

Counterparty or an agent acting on behalf of the

Counterparty







the output message.

ReportingTi

mestamp

O UTCTimestampTy

pe

Key

ConterpartyI

D

M PartyType Key The Counterparty to the original transaction upon whose

behalf this valuation is being submitted.

This is the identity of the party from whose perspective

the information is being reported, if the Counterparty is

reporting on their own behalf then this value will be the

same value as for the Sender ID

Mandatory Repeating Section: Valuation (1-n)

UTI C UTIType Key The UTI of a previously submitted transaction for which

the valuation is being reported.

If ‘USI’ is present then this field

Must not be present

Else

It must be present

USI C USIType Key The USI of a previously submitted transaction for which

the valuation is being reported.

If ‘UTI’ is present then this field

Must not be present

Else

It must be present


of 119

ValuationTi

mestamp

M UTCTimestampTy

pe

Key Date and time of the last mark to market valuation for

this UTI.

MtMValue M PriceType Key Mark to market valuation of the contract, or mark to

model valuation where applicable under Article 11(2) of

Regulation (EC) No 648/2012.

MtMCurrenc

y

M CurrencyCodeTyp

e

Key The currency used for the mark to market valuation of

the contract, or mark to model valuation where

applicable under Article 11(2) of Regulation (EC) No

48/2012.

N.B, this will be mapped to the 3 Char ISO 4217

Currency Code in the output message.

ValuationTy

pe

O ValuationTypeTyp

e


this field will be set to the default value in the output message

else


Default value = “M”.


of 119

3.4 European Regulatory Reporting Collateral Message

Regulatory Collateral (COL) – Document Root



Info

Business Rule

DocumentID M IdentificationType Info When a party receives a trade document with an ID

unknown to the receiver then the receiver must treat

this document as the initial version of a new document.




DocumentUs

age



This field identifies the sender who is either the

Counterparty or an agent acting on behalf of the

Counterparty







the output message.

ReportingTi

mestamp

O UTCTimestampTy

pe

Key

ConterpartyI

D

M PartyType Key The Counterparty to the original transaction upon whose

behalf this valuation is being submitted.

This is the identity of the party from whose perspective

the information is being reported, if the Counterparty is

reporting on their own behalf then this value will be the

same value as for the Sender ID

Mandatory Repeating Section: Collateralisation (1-n)

UTI O UTIType Key The UTI of a previously submitted transaction for which

the collateral is being reported.


of 119

Collateralisa

tionPortfolio

Code

C PortfolioCodeType Key Code of the portfolio for which the collateralisation is

being reported.

Code of the portfolio for which the collateralisation

is being reported.

If the field ‘UTI’ is nor present

• this field should be present

else if the ‘CollateralisationPortfolio’ = “Y” for the

transaction report specified by the UTI in field

‘UTI’ then

• this field should be present and contain

the same value that is contained in the field

‘CollateralisationPortfolioCode’ in the transaction

report with the same UTI value

else

• this field should be omitted.

CollateralVal

ue

M PriceType Key Value of the collateral posted by the reporting

counterparty to the other counterparty. This field should

include the value of all collateral posted for the portfolio.

CollateralCu

rrency

M CurrencyCodeTyp

e

Key The currency in which the ‘Collateral Value’ is

denominated.

N.B, this will be mapped to the 3 Char ISO 4217

Currency Code in the output message.

CollateralDa

te

M DateType Key The ‘as of’ date of the calculation.


of 119

3.5 ETD Trade Details (ETD)

Exchange Traded Derivative

Table 9: Specification of Trade Confirmation Elements


Info

Business Rule

DocumentID M IdentificationType Info When a party receives a document with an ID unknown

to the receiver then the receiver must treat this

document as the initial version of a new document.




DocumentUs

age



ReceiverID M PartyType Info Party code of Receiver.

If ‘ReceiverRole’ = “ClearingBroker” then this field must

= ‘BrokerID’ when ‘AgentType’ is “ClearingBroker”

Else if ‘ReceiverRole’ = “ClearingHouse” then this field

must = ‘ClearingHouseID’

Else if ‘ReceiverRole’ = “Exchange” then this field must =

‘ClearingRegistrationAgentID’

Else if ‘ReceiverRole’ = “Broker” then this field must =

‘BrokerID’ when ‘AgentType’ is “Broker”

Else if ‘ReceiverRole’ = “Trader” then this field must

contain the LEI of the counterparty to the sender i.e. the

LEI of the Trader who is the buyer or seller in this

cleared trasnaction..

ReceiverRol

e

M ETDRoleType Info The relevant ‘role’ as defined by the process e.g:

“ClearingBroker”, “ClearingHouse” or “Exchange” if

the sender is a counterparty to the original

execution

“Trader” or “ClearingHouse” if the sender is a

clearing broker

“Trader” or “ClearingBroker” if the sender is a

clearing house

“ClearingHouse” or “Exchange” if the sender is the

venue of execution.

DocumentVe

rsion

M VersionType Info The version number is always associated the Document

ID. It is used to distinguish and order the initial

document and all its amendments over time. A fixed first

version number for the initial document is not defined

(see field “Document ID”).

CreationTim

estamp

M UTCTimestampTy

pe

Info Timestamp at which ETD document was generated.


of 119

TransactionT

ype

M ETDTransaction-

Type

Key Indicates the type of transaction OTC or future being

cleared.

PrimaryAsse

tClass

M AssetClassType Key An indication of the primary asset class.

Clearing Parameters

Mandatory Section below ETD Trade Details: ClearingParameters

DealID O IdentificationType Key A common deal identifier known to buyer/seller/broker to a

deal i.e. the Transaction Reference Number (TRN). If

CpMLDocument/Reporting/Europe/ProcessInformation/Positio

n = “True” then this must be the position identifier associated

with the UTI of the reported position, this value could be

available from the clearing broker – organisations should

discuss with their clearing broker what code should be used

and how they can receive it.

ClearingRegi

strationAgen

tID

M PartyType Key “<MIC code>0000000000000000” of clearing registration agent

via whom the deal is registered for clearing i.e. the exchange

where the cleared product is traded and where the

CRAProduct Code is listed. E.g. this would be

“XEEE0000000000000000” representing EEX if the CRAProduct

Code was a PHELIX code.

ClearingHou

seID

M PartyType Key LEI code of clearing house.

Lots M LotsType Key Number of contracts to be registered.

If

CpMLDocument/Reporting/Europe/ProcessInforma

tion/Position = “False” then

• this field must not be 0

else

• this must be the sum of the lots netted

across all the transactions in the position being

reported.

UnitPrice M PriceType Key Unit price per contract. The number of (non-zero) decimal

digits must not exceed the number of decimals used in the

CRA's product definition (price quote).

If


n = “True” then this must be the closing price on the exchange

on the AS OF day of the report.i.e. the day the report

has been generated for.

Anonymous O TrueFalseType Info "True" if deal is anonymous, "False" otherwise

Initiator O IdentificationType Info LEI code of initator (who offered the deal).

Product Description

Mandatory Section below ETD Trade Details: Product


of 119

CRAProduct

Code

M String(100) Key Product code as issued by Clearing Registration Agent (CRA)

e.g. the exchange product code for this traded product.

Optional Section below Product: DeliveryPeriod (0-1)

DeliveryStar

tDateAndTi

me

M UTCTimestampTy

pe

Key Start date of physical delivery of the underlying commodity.

Describes the start date of the Exchange product not when

there is physical delivery under the contract e.g. a Phelix Peak

Aug-2013 Future will have an start delivery date of 1-Jun-2013

even though the first days of the month are a weekend with no

peak hours.

If


n = “True” then the position must represent one cleared

product and the DeliveryStartDateAndTime must be the same

for the reported position as it is for a reported transaction for

the same product (and maturity); for example: for the cleared

product (F1BY 1/1/15-31/12/15). DeliveryStartDateAndTime =

01/01/15.

This is the ‘Effective Date’ for non-deliverable products.

DeliveryEnd

DateAndTim

e

M UTCTimestampTy

pe

Key End date of physical delivery of the underlying

commodity.Describes the end date of the Exchange product

not when there is physical delivery under the contract e.g. a

Phelix Peak Aug-2013 Future will have an end delivery date of

31-Aug-2013 even though the last days of the month are a

weekend with no peak hours.

If


n = “True” then the position must represent one cleared

product and the DeliveryEndDateAndTime must be the same

for the reported position as it is for a reported transaction for

the same product (and maturity); for example: for the cleared

product (F1BY 1/1/15-31/12/15). DeliveryEndDateAndTime =

31/12/15.

This is the ‘Maturity/Termination Date’ for non-deliverable

products.

Conditional Section below Product: OptionDetails

Must be present if ‘TransactionType’ = “OPT” or “OPT_PHYS_INX” or “OPT_FXD_SWP” or

“OPT_FXD_FXD_SWP” or “OPT_FLT_SWP” or “OPT_FIN_INX”.

“OPT_FUT” otherwise must not be present.

Type M OptionType Key "Put" or "Call"

If


n = “True” then if the options product position can be split into

a ‘Call’ position and a ‘Put’ position and each position reported

separately then this field should be set to the relevant value,

however the correct reporting approach may vary and must be

agreed with the Other Counterparty (i.e. the Clearing Broker or

CCP) to avoid incompatible reporting.


of 119

StrikePrice M PriceType Key Strike price.

If


n = “True” then if the options product position can be split into

separate strikes and each position reported separately then

this field should be set to the relevant value, however the

correct reporting approach may vary and must be agreed with

the Other Counterparty (i.e. the Clearing Broker or CCP) to

avoid incompatible reporting.

OptionStyle M EMIROptionStyle Key Style of execution of the option.

Optional Repeating Section below Product: AdditionalData (0-n)

Key M AdditionalDataKeyT

ype

Key

Value M AdditionalDataValu

eType

Key

Buyer Details

Conditional Section below ETD Trade Details: BuyerDetails

Must be present if ‘SenderID’ = ‘BuyerParty’ or ‘SenderID’ = ‘MTFID’ otherwise this

section must not be present.

BuyerParty M PartyType Key LEI code of buyer. Note that this is the actual trade

counterparty (beneficiary), not an exchange member clearing

on its behalf.

If


n = “True” then this MUST be the Party with the long position.

DealID C IdentificationType Key A local deal identifier known to buyer of the deal.

If ‘SenderID” = ‘BuyerParty’ then this field

Must be present

Else

It must be omitted

ExecutionTi

mestamp

C UTCTimestampTy

pe

Info If the MTFDetails section is present then this field

must be omitted

else

must be present

Timestamp at which ETD was booked into the system of

record.

If


n = “True” then this must be the execution time stamp

of the first (position opening) transaction.


of 119

Conditional Unordered Repeatable Section below BuyerDetails: Agents (1-N)

For each agent acting on behalf of the Buyer Party in respect to this transaction the following fields

must be present.

Mandatory for “Clearing_Broker”.

Where reporting party is a CM then the reporting party should report itself, or the relevant part of

its organisation, as the ClearingBroker.

AgentType M AgentType Key

AgentName O NameType Info

BrokerID M PartyType Key N.B. this is any LEI and can identify any specific entity

with an LEI who is acting in the role of defined in

‘AgentType’ e.g. “Broker”, “ClearingBroker”,

“SettlementAgent”.

If ‘AgentType’ = “Broker” then this may be a Broker

Code as an alternative to an LEI.

Seller Details

Conditional Section below ETD Trade Details: SellerDetails

Must be present if ‘SenderID’ = ‘SellerParty’ or ‘SenderID’ = ‘MTFID’ otherwise this

section must not be present.

SellerParty M PartyType Key LEI code of seller. Note that this is the actual trade

counterparty (beneficiary), not an exchange member clearing

on its behalf.

If


n = “True” then this MUST be the Party with the short position.

DealID C IdentificationType Key A local deal identifier known to seller of the deal.

If ‘SenderID” = ‘SellerParty’ then this field

Must be present

Else

It must be omitted

ExecutionTi

mestamp

M UTCTimestampTy

pe

Info If the MTFDetails section is present then this field

must be omitted

else

must be present

Timestamp at which ETD was booked into the system of

record.

If


n = “True” then this must be the execution time stamp of the

first (position opening) transaction.

Conditional Unordered Repeatable Section below SellerDetails: Agents (1-N)

For each agent acting on behalf of the Seller Party in respect to this transaction the following fields

must be present.

Mandatory for “Clearing_Boker”.




of 119







MTF Details

Conditional Section below ETD Trade Details: MTFDetails

Must be present if ‘SenderID’ = ‘MTFID’ otherwise this section must not be present.

MTFID M PartyType Key LEI of MTF on which deal was executed.

ExecutionTi

mestamp

M UTCTimestampTy

pe

Info Timestamp at which ETD was booked into the system of

record.


of 119

3.6 IRS Trade Details (IRT)

IRS Trade Details

Table 10: Specification of IRS Trade Details Elements


Info

Business Rule

DocumentID M IdentificationType Info When a party receives a IRS Trade Details with an ID


this document as the initial version of a new IRS Trade

Details document. Otherwise the receiver must treat this

document as an amendment of an already sent IRS

Trade Details document (see field “Document Version”).

DocumentUs

age



ReceiverID M PartyType Info Party code of Receiver, brokerID in case only Broker is

involved.

ReceiverRol

e

M RoleType Info The relevant ‘role’ as defined by the process.

DocumentVe

rsion


ID. It is used to distinguish and order the initial IRS

Trade Details document and all its amendments over

time. A fixed first version number for the initial IRS

Trade Details document is not defined (see field

“Document ID”).

TradeID O IdentificationType Info Identification code created for this transaction.

TransactionT

ype

M IRSTransaction-

Type

Key

IRSProduct M IRSProductType Key

BuyerParty M PartyType Key

SellerParty M PartyType Key

Agreement M AgreementType Key

Currency M CurrencyCode-

Type

Key “Settlement Currency”

TradeDate M DateType Key

TradeTime O TimeType Info UTC time

TraderName O NameType Info

Rounding O RoundingType Info


of 119

CommonPric

ing

O CommonPricing-

Type

Info

If present and if all holiday calendars happen to be the

same then Common Pricing must, by default, be set to

‘True’.

If present and if there is only one Commodity Reference

section in the document then this value must be set to

‘False’ since Common Pricing is not relevant if there is

only one price source.

BusinessDay

Convention

M BusinessDayConv

entionType

Key The convention for adjusting an unadjusted date if it

would otherwise fall on a day that is not a business day.

This is the default rule for all adjustable dates in the

document, unless otherwise specified in a rule specific to

an adjusted field within this document.

Conditional Unordered Repeatable Section below IRSTradeDetails: Agents (0-N)

For each agent specified in a IRS Trade Details document the following fields must be present.









IRS Trade Details – Option Details

Conditional section below IRSTradeDetails: OPTION DETAILS

This section must be present if and only if the value of field “Transaction Type” = “OPT_FXD_SWP”

or OPT_FXD_FXD_SWP” or “OPT_FLT_SWP”

OptionsType M OptionType Key

OptionWrite

r

M PartyType Key The party code of the “Seller Party”

OptionHolde

r

M PartyType Key The party code of the “Buyer Party”

OptionStyle M OptionStyleType Key

StrikePrice M PriceType Key

OptionCurre

ncy

M CurrencyCodeType Key The currency of the Strike Price, Second Strike Price,

Capped Price, and the Floored Price.

PremiumRat

e

M PriceType Key

PremiumCur

rency

M CurrencyCodeType Key

TotalPremiu

mValue

M PriceType Key Must equal the sum of each of the Premium Values in all

the Premium Payments.

N.B. For Financial Transactions this field shall be rounded

to 2 decimal places.


of 119

Mandatory Ordered Repeatable Section below OptionDetails: Premium Payments

(1-N)

Ordered by “Premium payment date”

PremiumPay

mentDate

M DateType Key

PremiumPay

mentValue

M PriceType Key The sum of the Premium Payment Values must equal the

Total Premium Value

Conditional Ordered Repeatable Section below OptionDetails: EXERCISE

SCHEDULE (0-N)

Exercise

Date Time

M UTCTimestampType Key This date and time must be after the date and time

specified in the previous Exercise Date and Time field.

IRS Trade Details – Swap Stream

Mandatory Ordered Repeatable Sub-Section below IRSTradeDetails: Swap

Stream (1-N)

PayerParty M PartyType Key The party responsible for making the payments defined by

this structure

If this is the first instance of the repeating group then

‘Payer Party’ must equal ‘Buyer Party’.

ReceiverPar

ty

M PartyType Key The party that receives the payments corresponding to

this structure.


‘Receiver Party’ must equal ‘Seller Party’.

IRS Trade Details – Calculation Period Dates

Mandatory Sub-Section below Swap Stream: Calculation Period Dates

Mandatory Sub-Section below Calculation Period Dates: EffectiveDate

Effective

Date

M DateType Key The first day of the term of the trade. An unadjusted date.

Optional Sub-Section below EffectiveDate: DateAdjustments

This section must be present if the Business Day Convention for the ‘Effective date’ is not the same

as the ‘Business Day Convention’ in the Header section of the IRSTradeDetails document.

BusinessDay

Convention

M BusinessDayConven

tionType

Key The convention for adjusting the ‘Effective Date’ if it would

otherwise fall on a day that is not a business day.

This will

Mandatory Sub-Section below Calculation Period Dates: TerminationDate

Termination

Date

M DateType Key The last day of the term of the trade. An unadjusted date.

Optional Sub-Section below TerminationDate: DateAdjustments

This section must be present if the Business Day Convention for the ‘Termination date’ is not the

same as the ‘Business Day Convention’ in the Header section of the IRSTradeDetails document.

BusinessDay

Convention

M BusinessDayConven

tionType

Key The convention for adjusting the ‘Termination Date’ if it



of 119

IRS Trade Details – Calculation Period Frequency

Optional Sub-Section below Calculation Period Dates: Calculation Period

Frequency

PeriodMultip

lier

M PeriodMultiplierTyp

e

Key A time period multiplier, e.g. 1, 2 or 3 etc. If the period

value is T (Term) then periodMultiplier must contain the

value 1.

Period M PeriodType Key A time period, e.g. a day, week, month, year or term of

the stream.

RollConventi

on

M RollConventionType Key Used in conjunction with a frequency and the regular

period start date of a calculation period, determines each

calculation period end date within the regular part of a

calculation period schedule.

Conditional Sub-Section below CalculationPeriodFrequency: DateAdjustments

This section must be present if the Business Day Convention for the calculation period end date is

not the same as the ‘Business Day Convention’ in the Header section of the IRSTradeDetails

document.

BusinessDay

Convention

M BusinessDayConven

tionType

Key The convention for adjusting the end date of each

calculation period if it would otherwise fall on a day that is

not a business day.

IRS Trade Details – Payment Dates

Mandatory Sub-Section below Swap Stream: Payment Dates

Mandatory Sub-Section below Payment Dates: Payment Frequency

The frequency at which regular payment dates occur. If the payment frequency is equal to

the frequency defined in the calculation period dates component then one calculation

period contributes to each payment amount. If the payment frequency is less frequent

than the frequency defined in the calculation period dates component then more than one

calculation period will contribute to the payment amount. A payment frequency more

frequent than the calculation period frequency or one that is not a multiple of the

calculation period frequency is invalid. If the payment frequency is of value T (term), the

period is defined by the ‘Termination Date’.

PeriodMultip

lier


e



value 1.


the stream.

Optional Sub-Section below PaymentFrequency: DateAdjustments

This section must be present if the Business Day Convention for the ‘payment date’ is not the same

as the ‘Business Day Convention’ in the Header section of the IRSTradeDetails document.

BusinessDay

Convention

M BusinessDayConven

tionType

Key The convention for adjusting the payment date if it would



of 119

Optional Sub-Section below Payment Dates: Payment Relative To

Specifies whether the payments occur relative to each adjusted calculation period start date, adjusted

calculation period end date or each reset date. Calculation period start date means relative to the start of the

first calculation period contributing to a given payment. Similarly, calculation period end date means the end of

the last calculation period contributing to a given payment.

PayRelative

To

M PayRelativeToType Key E.g. "CalculationPeriodEndDate" - Payments will occur

relative to the last day of each calculation period.

IRS Trade Details – Reset Dates

Conditional Sub-Section below Swap Stream: Reset Dates

If this Swap Stream is for a floating leg then this section is optional else it must be omitted.

ResetRelativ

eTo

M ResetRelativeToTyp

e

Key The reset dates schedule e.g. "CalculationPeriodEndDate" -

Payments will occur relative to the last day of each

calculation period.

Sub-Section below Reset Dates: Reset Frequency

The frequency at which reset dates occur. In the case of a weekly reset frequency, also specifies the day of the

week that the reset occurs. If the reset frequency is greater than the calculation period frequency then this

implies that more than one reset date is established for each calculation period and some form of rate averaging

is applicable.

PeriodMultip

lier


e



value 1.


the stream.

WeeklyRollC

onvention

C WeekDayType Key If the transaction has weekly resets then this field

Is optional

else

It must be omitted.

Optional Sub-Section below ResetFrequency: DateAdjustments

This section must be present if the Business Day Convention for the ‘reset date’ is not the same as

the ‘Business Day Convention’ in the Header section of the IRSTradeDetails document.

BusinessDay

Convention

M BusinessDayConven

tionType

Key The convention for adjusting the reset date if it would


Optional Sub-Section below Reset Dates: Fixing Dates

Specifies the fixing date relative to the reset date in terms of a business days offset.

PeriodMultip

lier


e



value 1.


the stream.

Optional Sub-Section below FixingDates: DateAdjustments

This section must be present if the Business Day Convention for the ‘fixing date’ is not the same as

the ‘Business Day Convention’ in the Header section of the IRSTradeDetails document.


of 119

BusinessDay

Convention

M BusinessDayConven

tionType

Key The convention for adjusting the fixing date if it would


IRS Trade Details – Calculation Period Amount

Sub-Section below Swap Stream: Calculation Period Amount

The calculation period amount parameters.

Sub-Section below Calculation Period Amount: Calculation

The parameters used in the calculation of fixed or floating rate calculation period amounts.

Sub-Section below Calculation: Notional Schedule

The notional amount or notional amount schedule.

Sub-Section below Notional Schedule: Notional Step Schedule

The notional amount or notional amount schedule expressed as explicit outstanding notional amounts and dates.

InitialValue M QuantityType Key The non-negative initial rate or amount, as the case may

be. An initial rate of 5% would be represented as 0.05.

Currency M CurrencyCodeType Key The currency in which an amounts: ‘initial Value’ and ‘Step

Value’ are denominated.

Conditional Repeatable Sub-Section below Notional Schedule: Step (0 – N)

The schedule of step date and non-negative value pairs. On each step date the associated step value becomes

effective.

If the notional varies between Calculation Periods then this section must be present otherwise it must not be

present.

Ordered by ascending step date.

StepDate M DateType Key The date on which the associated ‘Step Value’ becomes

effective.

Unadjusted date.

StepValue M QuantityType Key The non-negative rate or amount which becomes effective

on the associated ‘Step Date’. A rate of 5% would be

represented as 0.05.

XML Choice under Calculation:

Choice 1: Conditional Sub-Section below Calculation: Fixed Rate Schedule

The fixed rate or fixed rate schedule expressed as explicit fixed rates and dates.

If the Swap Stream describes a fixed rate then this section must be completed.

InitialValue M QuantityType Key The non-negative initial rate or amount, as the case may

be. An initial rate of 5% would be represented as 0.05.

Conditional Repeatable Sub-Section below Fixed Rate Schedule: Step (0 – N)

The schedule of step date and non-negative value pairs. On each step date the associated step value becomes

effective.

If the rate varies between Calculation Periods then this section must be present otherwise it must not be

present.

Ordered by ascending step date.


of 119

StepDate M DateType Key The date on which the associated ‘Step Value’ becomes

effective.

Unadjusted date.

StepValue M QuantityType Key The non-negative rate or amount which becomes effective

on the associated ‘Step Date’. A rate of 5% would be

represented as 0.05.

Choice 2: Conditional Sub-Section below Calculation: Floating Rate Calculation

A floating rate calculation definition.

If the Swap Stream describes a floating rate then this section must be completed.

FloatingRate

Index

M RateIndexType Key

Sub-Section below Floating Rate Calculation: Index Tenor

Specifies the tenor of the floating rate.

PeriodMultip

lier


e



value 1.


the stream.

End of XML Choice

DayCountFra

ction

M DayCountFractionTy

pe

Key The day count fraction.


of 119

3.7 FX Trade Details (FXT)

FX Trade Details – Document Root

Table 11: Specification of FX Trade Details Elements


Info

Business Rule

DocumentID M IdentificationType Info When a party receives a FX Trade Details with an ID


this document as the initial version of a new FX Trade

Details document. Otherwise the receiver must treat this

document as an amendment of an already sent FX Trade

Details document (see field “Document Version”).

DocumentUs

age



ReceiverID M PartyType Info Party code of Receiver, brokerID in case only Broker is

involved.

ReceiverRol

e

M RoleType Info The relevant ‘role’ as defined by the process.

DocumentVe

rsion


ID. It is used to distinguish and order the initial FX Trade

Details document and all its amendments over time. A

fixed first version number for the initial FX Trade Details

document is not defined (see field “Document ID”).

TradeID O IdentificationType Info Identification code created for this transaction.

TransactionT

ype

M FXTransaction-

Type

Key The values of this field are limited to the following:

“SPT” “FOR” “FXD_FXD_SWP” “OPT” “OPT_FXD_FXD_SWP”

FXProduct M FXProductType Key

BuyerParty M PartyType Key

SellerParty M PartyType Key

Agreement M AgreementType Key

TradeDate M DateType Key

TradeTime O TimeType Info UTC time

TraderName O NameType Info

Conditional Unordered Repeatable Section below FXTradeDetails: Agents (0-N)

For each agent specified in a FX Trade Details document the following fields must be present.




of 119







FX Trade Details – FX Single Leg (FXSpot, FXForward and FXSwap)

Conditional Repeatable Sub-Section below FXTradeDetails: FXSingleLeg (0-2)

If ‘TransactionType’ =

“FOR” or “SPT” then the number of occurrences of this sub-section must be 1 (one)

“FXD_FXD_SWP” then the number of occurrences of this sub-section must be 2 (two)

Else this section must be omitted.

If ‘TransactionType’ = “FXD_FXD_SWP” then the first occurrence of this sub-section is the near leg

and must describe the FX transaction with the earliest value date.

Mandatory Repeatable Sub-Section below FXSingleLeg: ExchangedCurrency (2)

There must be two occurrences of this section. The first occurrence must refer to the first of the two

currency flows that define a single leg of a standard foreign exchange transaction. The second

occurrence must refer to the second of the two currency flows that define a single leg of a standard

foreign exchange transaction.

PayerParty M PartyType Key The party responsible for making the payments defined by

this structure


‘Payer Party’ must equal ‘Buyer Party’.

If this is the second instance of the repeating group then

‘Payer Party’ must equal ‘Seller Party’.

ReceiverPar

ty

M PartyType Key The party that receives the payments corresponding to

this structure.


‘Receiver Party’ must equal ‘Seller Party’.

If this is the second instance of the repeating group then

‘Receiver Party’ must equal ‘Buyer Party’.

PaymentCur

rency

M CurrencyType Key The currency in which an amount is denominated.

PaymentAm

ount

M PriceType Key The monetary quantity in currency units specified in

‘PaymentCurrency’

ValueDate M DateType Key The date on which the exchange currency will settle.

End of Section ExchangedCurrency

Mandatory Repeatable Sub-Section below FXSingleLeg: ExchangeRate (1-n)

The first occurrence must refer to ExchangeCurrency. Subsequent optional occurrences must refer

to currency exchange rates used to cross between the traded currencies for non-base currency FX

contracts.

Currency1 M CurrencyCodeType Key The first currency specified when a pair of currencies is to

be evaluated.

Currency2 M CurrencyCodeType Key The second currency specified when a pair of currencies is

to be evaluated.


of 119

QuoteBasis M QuoteBasisType Key The method by which the exchange rate is quoted.

SpotRate M PriceType Key The current market rate for a particular currency pair.

ForwardPoin

ts

M QuantityType Key Forward points represent the interest rate differential

between the two currencies traded and are quoted as a

premium or a discount. Forward points are added to, or

subtracted from, the spot rate to create the rate of the

forward trade.

A Discount must be a signed value: a negative sign MUST

be included if the interest rate differential between the two

currencies traded is a discount.

Optional Sub-Section below FXSingleLeg: NonDeliverableSettlement (0-1)

Must be present for an FX forward transaction that is settled in a single currency (for example, a

non-deliverable forward), otherwise must not be present.

SettlementC

urrency

M CurrencyCodeType Key The currency in which cash settlement occurs for non-

deliverable forwards and cash-settled options (non-

deliverable or otherwise).

SettlementD

ate

M DateType Key The date on which settlement is scheduled to occur

BusinessDay

Convention

M BusinessDayConven

tionType

Key The convention for adjusting the ‘Settlement Date’ if it


Mandatory Repeatable Sub-Section below NonDeliverableSettlement: Fixing (1-

n)

Specifies the source for and timing of a fixing of an exchange rate. This is used in the agreement of

non-deliverable forward trades as well as various types of FX OTC options that require observations

against a particular rate. It has multiple occurrence to support the case where fixing details must be

specified for more than one currency pair e.g. on an option settled into a third currency (that is not

one of the option currencies)


be evaluated.


to be evaluated.


FixingDate O DateType Describes the specific date when a non-deliverable forward

or cash-settled option will "fix" against a particular rate,

which will be used to compute the ultimate cash

settlement.

Optional Sub-Section below Fixing: FXSpotRateSource (0-1)

Specifies the methodology (reference source and, optionally, fixing time) to be used for determining

a currency conversion rate.

PrimaryRate

Source

M FXReferenceType Key The primary source for where the rate observation will

occur. Will typically be either a page or a reference bank

published rate.

RateSourceP

age

O FXRateSourcePageT

ype

Key A specific page for the rate source for obtaining a market

rate.

RateSourceP

ageHeading

O FXRateSourcePage

HeadingType

Key The heading for the rate source on a given rate source

page.


of 119

FixingTime O UTCTimestampType Key The time at which the spot currency exchange rate will be

observed.

End of Sub-Section FXSpotRateSource

End of Sub-Section Fixing

End of Sub-Section NonDeliverableSettlement

End of Sub-Section FXSingleLeg

FX Trade Details – Option Details

Conditional Sub-Section below FXTradeDetails: FXOption (0-1)

If ‘TransactionType’ = “OPT” or “OPT_FXD_FXD_SWP” then this section must be present, otherwise

this section must be omitted.

OptionWrite

r

M PartyType Key The party code of the “Seller Party”

OptionHolde

r

M PartyType Key The party code of the “Buyer Party”

OptionType M OptionType Key Indicates how the product was original sold as a Put or a

Call.

EffectiveDat

e

M DateType Key Effective date for a forward starting derivative.

UTC date.

BusinessDay

Convention

M BusinessDayConven

tionType

Key The convention for adjusting the ‘EffectiveDate’ if it would


Mandatory Sub-Section below FXOption: PutCurrencyAmount

Currency M CurrencyCodeType Key The currency amount that the option gives the right to

sell.

Amount M PriceType The monetary quantity in currency units.

End of section PutCurrencyAmount

Mandatory Sub-Section below FXOption: CallCurrencyAmount

Currency M CurrencyCodeType Key The currency amount that the option gives the right to

buy.

Amount M PriceType The monetary quantity in currency units.

End of section CallCurrencyAmount

Mandatory Sub-Section below FXOption: Strike

Defines the option strike price.

FXRate M QuantityType Key The rate of exchange between the two currencies of the

leg of a deal.


End of section Strike

Mandatory Ordered Repeatable Section below FXOption: PremiumPayments (1-

N)

Ordered by “Premium payment date”


of 119

PremiumPay

mentDate

M DateType Key The payment date, which can be expressed as either an

adjustable or relative date

BusinessDay

Convention

M BusinessDayConven

tionType

Key The convention for adjusting the ‘PremiumPaymentDate if

it would otherwise fall on a day that is not a business day.

PremiumCur

rency

M CurrencyCodeType Key The currency in which the PremiumPaymentValue is

denominated.

This must be the same currency for each occurrence of the

section.

PremiumPay

mentValue

M PriceType Key The monetary quantity in the PremiumCurrency.

End of section PremiumPayments

Optional Sub-Section below FXOption: CashSettlement (0-1)

Specifies the currency and fixing details for cash settlement. This optional element is produced only

where it has been specified at execution time that the option wlll be settled into a single cash

payment - for example, in the case of a non-deliverable option (although note that an Fx option

may be contractually cash settled, without necessarily being non-deliverable).

SettlementC

urrency

M CurrencyCodeType Key The currency in which cash settlement occurs for non-

deliverable forwards and cash-settled options (non-

deliverable or otherwise).

SettlementD

ate

M DateType Key The date on which settlement is scheduled to occur

BusinessDay

Convention

M BusinessDayConven

tionType

Key The convention for adjusting the ‘Settlement Date’ if it


Mandatory Repeatable Sub-Section below CashSettlement: Fixing (1-n)

Specifies the source for and timing of a fixing of an exchange rate. This is used in the agreement of

non-deliverable forward trades as well as various types of FX OTC options that require observations

against a particular rate. This element is optional, permitting it to be omitted where fixing details

are unavailable at the point of message creation. It has multiple occurrence to support the case

where fixing details must be specified for more than one currency pair e.g. on an option settled into

a third currency (that is not one of the option currencies)


be evaluated.


to be evaluated.


FixingDate O DateType Describes the specific date when a non-deliverable forward

or cash-settled option will "fix" against a particular rate,

which will be used to compute the ultimate cash

settlement.

Optional Sub-Section below Fixing: FXSpotRateSource (0-1)

Specifies the methodology (reference source and, optionally, fixing time) to be used for determining

a currency conversion rate.

PrimaryRate

Source

M FXReferenceType Key The primary source for where the rate observation will

occur. Will typically be either a page or a reference bank

published rate.

RateSourceP O FXRateSourcePageT Key A specific page for the rate source for obtaining a market


of 119

age ype rate.

RateSourceP

ageHeading

O FXRateSourcePage

HeadingType

Key The heading for the rate source on a given rate source

page.

FixingTime O UTCTimestampType Key The time at which the spot currency exchange rate will be

observed.

End of Sub-Section FXSpotRateSource

End of Sub-Section Fixing

End of Sub-Section CashSettlement

Mandatory Section below FXOption: FXExerciseSchedule

OptionStyle M OptionStyleType Key E.g. “American” or “European”.

ExpiryDate C DateType Key Represents a standard expiry date as defined for an FX

OTC option.

If ‘ExpiryDateTime’ is present then


Else


ExpiryDateA

ndTime

C UTCTimestampType Key The date and time of expiry. If ‘ExpiryDate’ is present then


Else


CutName O IdentityType Key The code by which the expiry time is known in the market.

ValueDate M DateType Key The date on which both currencies traded will settle.

For an American style option this is the latest date on

which both currencies traded will settle.

UTC Date.

Conditional Section below FXExerciseSchedule: AmericanOptionDetails

If ‘OptionStyle’ = “American” then this section must be present otherwise it must be omitted.

Commence

mentDate

M DateType Key The date on which both currencies traded will settle.

UTC Date.

BusinessDay

Convention

M BusinessDayConven

tionType

Key The convention for adjusting the ‘CommencementDate’ if it


Optional Section below AmericanOptionDetails: MinimumNotionalAmount (0-1)

The minimum amount of notional that can be exercised if the transaction is subject to multiple

exercise.

Currency M CurrencyCodeType Key The currency in which an amount is denominated.

Amount M PriceType Key The monetary quantity in currency units.

End of Sub-Section MinimumNotionalAmount

Optional Section below AmericanOptionDetails: MaximumNotionalAmount (0-1)

The maximum amount of notional that can be exercised if the transaction is subject to multiple

exercise.


of 119

Currency M CurrencyCodeType Key The currency in which an amount is denominated.

Amount M PriceType Key The monetary quantity in currency units.

End of Sub-Section MaximumNotionalAmount

End of Sub-Section AmericanOptionDetails

End of Sub-Section FXExerciseSchedule


of 119

3.8 Box Result Document (BRS)

Box Result – Document Root

Table 12 Specification of Box Results Elements


Info

Business Rule

Section: Document Header

DocumentID M IdentificationType Info

DocumentVe

rsion

O VersionType Info

TimeStamp M UTCTimeStampTy

pe

Info

Mandatory Section within Document Header: EuropeResult

Action M String 35

Result M String 35

Regime O EuropeRegimeTyp

e

Repository O RepositoryType

Optional Section within EuropeResult: ReportingResult (0-1)

TradeID M TradeIDType

UTI O UTIType

Optional Repeatable Section within ReportingResult: Reason (0-n)

ReasonCode M String 255

ErrorSource O String 255

Originator O String 255

ReasonText O String 512

End of Section ReportingResult

Optional Section within EuropeResult: ValuationResult (0-1)

Mandatory Repeatable Section within ValuationResult: Valuation (1-n)

UTI M UTIType

Result M String 255

Optional Repeatable Section within ValuationResult: ValuationReason (0-n)





End of Section ValautionReason


of 119

End of Section ValuationResult

Optional Section within EuropeResult: CollateralResult (0-1)

Mandatory Repeatable Section within CollateralResult: Collateral (1-n)

UTI O UTIType

PortfolioCod

e

O PortfolioCodeType

Result M String 255

Optional Repeatable Section within CollateralResult: CollateralReason (0-n)





End of Section CollateralReason

End of Section CollateralResult

End of Section EuropeResult

Figure 7 Box Result Root Document Schema


of 119

Figure 8 Box Result EuropeResult Section Schema


of 119

4 Communication Protocol and Interfaces

This chapter presents the specific communication protocol elements required to transport all EFET eCM

messages. Please refer to references [1] & [2] for further information on the EFET Communications

Standard and to how it must be applied in the case of the eCM process.


of 119

Appendix A. Definition of Types and Codes

This appendix describes code conventions and best practices for the technical implementation of eCM

and other EFET compliant interfaces. It is not limited to the use within the eCM process but should be

used and extended to support other implementations related to other processes.

The actual implementation of this standard within the eCM processes and the description of the EFET

eCM standards interface is the subject of the relevant sections describing the individual

messages.

A.1. CpML Field Types

Table 13: CpML Field Types

TypeName

Order by

DEFINITION XML Base

Type

Size

AdditionalDataKe

yType

Generic field for extension data. String 35

AdditionalDataVal

ueType

Generic fied for extension data. String 255

ActionDetailType Free text. String 50

ActionTypeType Values:

“N”= New

“M”= Modify

“E”= Error,

“C”= Cancel,

“O”= Other

“Z” = Compression.

N.B. “V” for valuation has been intentionally left out.

NMTOKEN

AgentType Values:

“Broker”

“ECVNA” “ClearingBroker” “SettlementAgent”

NMTOKEN

BusinessDayConv

entionType

"FOLLOWING" The non-business date will be adjusted to

the first following day that is a business day

"FRN" Per 2000 ISDA Definitions, Section 4.11. FRN

Convention; Eurodollar Convention.

"MODFOLLOWING" The non-business date will be adjusted

to the first following day that is a business day unless that

day falls in the next calendar month, in which case that date

will be the first preceding day that is a business day.

"PRECEDING" The non-business day will be adjusted to the

first preceding day that is a business day.

"MODPRECEDING" The non-business date will be adjusted to

the first preceding day that is a business day unless that

day falls in the previous calendar month, in which case that

date will be the first following day that us a business day.

"NEAREST" The non-business date will be adjusted to the

nearest day that is a business day - i.e. if the non-business

day falls on any day other than a Sunday or a Monday, it

NMTOKEN


of 119

TypeName

Order by

DEFINITION XML Base

Type

Size

will be the first preceding day that is a business day, and

will be the first following business day if it falls on a Sunday

or a Monday.

"NONE" The date will not be adjusted if it falls on a day that

is not a business day.

"NotApplicable" The date adjustments conventions

are defined elsewhere, so it is not required to specify them

here.

CollateralisationT

ype

Values:

U=uncollateralised

PC= partially collateralised

OC=one way collateralised

FC= fully collateralised.

NA = not applicable

NMTOKEN

CommodityBaseT

ype

Permitted values:

“AG”=Agricultural

“EN”=Energy

“FR”=Freights

“ME”=Metals

“IN”= Index

“EV”= Environmental

“EX”= Exotic

“NA” = Not applicable

NMTOKEN

CommodityDetail

sType

Permitted values:

Agricultural

o “GO”= Grains oilseeds

o “DA”= Dairy

o “LI”= Livestock

o “FO”= Forestry

o “SO”= Softs

Energy

o “OI”= Oil

o “NG” = Natural gas

o “CO”= Coal

o “EL”= Electricity

o “IE”= Inter-energy

Metals

o “PR”= Precious

o “NP” = Non-precious

Environmental

o “WE”=Weather

o “EM”= Emissions

Or “NA” if not applicable.


of 119

TypeName

Order by

DEFINITION XML Base

Type

Size

ConfirmationMea

nsType

Values:

“Y”= Non-electronically confirmed,

“N”= Non-confirmed,

“E”= Electronically confirmed.

NMTOKEN

CorporateSectorT

ype

Values:

A=Assurance undertaking authorised in accordance with

Directive 2002/83/EC;

C=Credit institution authorised in accordance with Directive

2006/48/EC;

F=Investment firm in accordance with Directive

2004/39/EC;

I=Insurance undertaking authorised in accordance with

Directive 73/239/EEC;

L=Alternative investment fund managed by AIFMs

authorised or registered in accordance with Directive

2011/61/EU;

O=Institution for occupational retirement provision within

the meaning of Article 6(a) of Directive 2003/41/EC;

R=Reinsurance undertaking authorised in accordance with

Directive 2005/68/EC;

U=UCITS and its management company, authorised in

accordance with Directive 2009/65/EC;

NMTOKEN

CPDomicileType A word or combination of words constituting the individual

designation by which a place, or thing is known.

string 500

CPFinancialNatur

eType

Values:

“F” = Financial

“N” = Non-financial

NMTOKEN

CPNameType A word or combination of words constituting the individual

designation by which a person or thing is known.

string 100

CPIDCodeTypeTy

pe

Values:

“LEI”

“MIC”

“BIC”

“ClientCode”

NMTOKEN

DayCountFraction

Type

For permitted values refer to: http://www.fpml.org/coding-

scheme/day-count-fraction

NMTOKEN

EMIROptionStyle Permitted values are:

“A”=American,

“B”=Bermudan,

“E”=European,

“S”=Asian.

NMTOKEN

EProduct1CodeTy

pe

Values:

“CO”=Commodity

“CR”=Credit

NMTOKEN

http://www.fpml.org/coding-scheme/day-count-fraction

http://www.fpml.org/coding-scheme/day-count-fraction


of 119

TypeName

Order by

DEFINITION XML Base

Type

Size

“CU”=Currency

“EQ”=Equity

“IR”=Interest Rate

“OT”= Other

EProduct2CodeTy

pe

Values:

Derivative type:

CD= Contracts for difference

FR= Forward rate agreements

FU= Futures

FW=Forwards

OP=Option

SW=Swap

OT= Other

NMTOKEN

ETDRoleType One of the values: “ClearingHouse”, “ClearingBroker”,

“Exchange”, “Trader”, “Broker”.

NMTOKEN

ETDTransactionTy

pe

Values are:

“FOR”: Physical Forward that settles against a fixed price

“OPT”: Option on a physical forward

“PHYS_INX”: Physical forward that settles against an index

“OPT_PHYS_INX”: Option on a physical forward that settles

against an index

“FXD_SWP”: Fixed/float swap

“FXD_FXD_SWP”: Fixed/fixed swap

“FLT_SWP”: Float/float swap

“OPT_FXD_SWP”: Fixed/float swaption

“OPT_FXD_FXD_SWP”: Fixed/fixed swaption

“OPT_FLT_SWP”: Float/float swaption

“OPT_FIN_INX”: Option on an index.

“FUT”: Exchange traded future (can be traded off exchange

but under the terms of the Regulated Market)

“OPT_FUT”: Exchange traded option (can be traded off

exchange but under the terms of the Regulated Market)

“SPT”: Spot transaction.

NMTOKEN

FXProductType Permitted values:

“FXSpot”

“FXForward”

“FXSwap”

“FXOption”

“FXForward_Non_Delivererable”

“FXOption_Non_Deliverable”

NMTOKEN

FXRateSourcePag

eHeadingType

This is the heading of a page of a reference source where an

FX spot price is published.

String 255

FXRateSourcePag

eType

This is a reference to a page of a reference source where an

FX spot price is published.

String 255


of 119

TypeName

Order by

DEFINITION XML Base

Type

Size

FXTransactionTyp

e

Values are:





“SPT”: Spot transaction.

NMTOKEN

IProduct1CodeTy

pe

ISIN or AII, 12 digits alphanumerical code. String 12

IProduct2CodeTy

pe

CFI, 6 digits alphanumerical code. String 6

IRSProductType Permitted values:

“IRSwap” “Basis” “CrossCurrency”

NMTOKEN

IRSTransactionTy

pe

Values are:







NMTOKEN

LoadTypeType Values:

“BL” =Base Load

“PL”= Peak Load

“OP”= Off-Peak

“BH”= Block Hours

“OT”= Other

NMTOKEN

LotsType Positive integer or zero Integer 16

MasterAgreement

VersionType

The version of the master trading agreement under which

the reported transaction was executed as defined by the

year of the agreement e.g. “2005”

String 4

OnBehalfOfType Values:

"Buyer"

"Seller"

"Buyer_And_Seller"

NMTOKEN

OptionStyleType Values: “American”, “European”, “Asian”, “Cap”, “Floor”,

“Collar”, “Bermudan”

N.B. “Cap”, “Floor” and “Collar” refer to an exercise style

which can be equated to a strip of automatically exercised

optlets with a strike price equal to the ‘Cap Price’/’Floor

Price’.

NMTOKEN

PayRelativeToTyp

e

"CalculationPeriodStartDate" - Payments will occur relative

to the first day of each calculation period.

"CalculationPeriodEndDate" - Payments will occur relative to

NMTOKEN


of 119

TypeName

Order by

DEFINITION XML Base

Type

Size

the last day of each calculation period.

"LastPricingDate" - Payments will occur relative to the

last Pricing Date of each Calculation Period.

"ResetDate" - Payments will occur relative to the reset date.

"ValuationDate" - Payments will occur relative to the

valuation date.

See: http://www.FpML.org

PeriodMultiplierTy

pe

A time period multiplier, e.g. 1, 2 or 3 etc. Integer 3

PeriodType "D" - Day.

"W" - Week.

"M" - Month.

"Y" - Year.

“T” – Term.


NMTOKEN

PriceNotationTyp

e

The manner in which the price is expressed.

ISO 4217 3 character currency codes, AND the value “100”

to represent ‘percentage’.

NMTOKEN

PortfolioCodeTyp

e

An internal code identifying a portfolio. String 20

QuoteBasisType Values:

“Currency1PerCurrency2" - The amount of currency1 for one unit of currency2

"Currency2PerCurrency1" - The amount of currency2 for one unit of currency1

"PutCurrencyPerCallCurrency" - The strike price is an amount of putCurrency per one unit of callCurrency.

"CallCurrencyPerPutCurrency" - The strike price is an amount of callCurrency per one unit of putCurrency.

NMTOKEN

RateIndexType For permitted values refer to: http://www.fpml.org/coding-

scheme/floating-rate-index

String 63

ReportingRoleTyp

e

Values:

"Trader" can report on behalf of themselves

"CP_Agent" can report on behalf of a counterparty and themselves including internal counterparty transactions to which they are a party

"Internal_Agent" can report on behalf of either or both counterparties to an intragroup transaction.

"Execution_Agent"

"Clearing_Agent"

NMTOKEN

ReportModeType Values:

“Report” = report this transaction to the relevant regime

“NoReport” = do not report this transaction to the relevant regime

“CmsReport” = apply the standard filtering and routing

NMTOKEN

http://www.fpml.org/


http://www.fpml.org/coding-scheme/floating-rate-index

http://www.fpml.org/coding-scheme/floating-rate-index


of 119

TypeName

Order by

DEFINITION XML Base

Type

Size

rules for the relevant regime.

RepositoryType Value: as defined in the Static Data tables ‘Repository Reference’ on www.EFET.org, which must at least include:"DTCC-EU"

"REGIS-TR”

"UNAVISTA"

“ICE”

String

(20)

ResetRelativeToT

ype

"CalculationPeriodStartDate" - Payments will occur relative

to the first day of each calculation period.

"CalculationPeriodEndDate" - Payments will occur relative to

the last day of each calculation period.


NMTOKEN

RollConventionTy

pe

Valid values are:

"EOM" - Rolls on month end dates irrespective of the

length of the month and the previous roll day.

"FRN" - Roll days are determined according to the

FRN Convention or Eurodollar Convention as

described in ISDA 2000 definitions.

"IMM" - IMM Settlement Dates. The third

Wednesday of the (delivery) month.

"IMMCAD" - The last trading day/expiration day of

the Canadian Derivatives Exchange (Bourse de

Montreal Inc) Three-month Canadian Bankers'

Acceptance Futures (Ticker Symbol BAX). The

second London banking day prior to the third

Wednesday of the contract month. If the determined

day is a Bourse or bank holiday in Montreal or

Toronto, the last trading day shall be the previous

bank business day. Per Canadian Derivatives

Exchange BAX contract specification.

"IMMAUD" - The last trading day of the Sydney

Futures Exchange 90 Day Bank Accepted Bills

Futures contract (see

http://www.sfe.com.au/content/sfe/trading/con_spe

cs.pdf). One Sydney business day preceding the

second Friday of the relevant settlement month.

"IMMNZD" - The last trading day of the Sydney

Futures Exchange NZ 90 Day Bank Bill Futures

contract (see

http://www.sfe.com.au/content/sfe/trading/con_spe

cs.pdf). The first Wednesday after the ninth day of

the relevant settlement month.

"SFE" - Sydney Futures Exchange 90-Day Bank

Accepted Bill Futures Settlement Dates. The second

Friday of the (delivery) month.

"NONE" - The roll convention is not required. For

example, in the case of a daily calculation

frequency.

"TBILL" - 13-week and 26-week U.S. Treasury Bill

NMTOKEN

http://www.efet.org/



of 119

TypeName

Order by

DEFINITION XML Base

Type

Size

Auction Dates. Each Monday except for U.S. (New

York) holidays when it will occur on a Tuesday.

"1" - Rolls on the 1st day of the month.

"2" - Rolls on the 2nd day of the month.

"3" - Rolls on the 3rd day of the month.

"4" - Rolls on the 4th day of the month.

















"21" - Rolls on the 21st day of the month.

"22" - Rolls on the 22nd day of the month.

"23" - Rolls on the 23rd day of the month.








"MON" - Rolling weekly on a Monday.

"TUE" - Rolling weekly on a Tuesday.

"WED" - Rolling weekly on a Wednesday.

"THU" - Rolling weekly on a Thursday.

"FRI" - Rolling weekly on a Friday.

"SAT" - Rolling weekly on a Saturday.

"SUN" - Rolling weekly on a Sunday.

See also: http://www.FpML.org

SettlementType Permitted values are:

“C” = Cash

“P” = Physical

NMTOKEN



of 119

TypeName

Order by

DEFINITION XML Base

Type

Size

“O” = Optional

TaxonomyCodeTy

pe

Values:

“EMIR_Taxonomy ”= Taxonomy defined under EMIR for describing the product for the reported transaction.

NMTOKEN

TaxonomyType Values:

“U”=Product Identifier [endorsed in Europe]

“I”=ISIN or Aii

“E”=Interim taxonomy

NMTOKEN

TradeIDType An internal locally unique identifier for a transaction String 30

TradingCapacityT

ype

Values:

“A” if the counterparty reporting the transaction is acting in the role of an ‘agent’ for a third party beneficiary at execution

“P” if the counterparty reporting the transaction was acting on their own behalf at execution.

NMToken

TransactionType Values are:



“PHYS_INX”: Physical forward that settles against an index

“OPT_PHYS_INX”: Option on a physical forward that settles

against an index

The following transaction types are collectively termed

‘Financial Transactions’





“OPT_FIN_INX”: Option on an index.

NMTOKEN

UnderlyingCodeT

ypeType

Value: as defined in the Static Data tables ‘Commodity

Reference’ of www.EFET.org, which must at least include:

“ISIN” – to indicate that the Underlying coding scheme is ISIN

“LEI” – to indicate that the Underlying coding scheme is LEI

“IEI” – to indicate that the Underlying coding scheme is an interim entity identifier

“UPI” – to indicate that the Underlying coding scheme is UPI

“B” – to indicate that the Underlying is a basket

“I” – to indicate that the Underlying is an index

String 20

UnderlyingType Values:

ISIN (12 alphanumerical digits)

LEI (20 alphanumerical digits)

Interim entity identifier (20 alphanumerical digits)

String 255

http://www.efet.org/


of 119

TypeName

Order by

DEFINITION XML Base

Type

Size

UPI (to be defined)

B= Basket

I=Index

UProductCodeTyp

e

Product Identifier (UPI), to be defined under EMIR/REMIT String 255

UTIType Unique Transaction ID under EMIR or REMIT String 52

ValuationTypeTyp

e

Values:

“M”= mark to market

“O”= mark to model.

NMTOKEN

VenueOfExecutio

nType

Values:

ISO 10383 Market Identifier Code (MIC), 4 digits alphabetical.

“XOFF”

“XXXX”

String 4

WeekDayType "MON"

"TUE"

"WED"

"THU"

"FRI"

"SAT"

"SUN"

"TBILL"

NMTOKEN


of 119

Appendix B. CpML Field Mappings to EMIR and REMIT Requirements

# EMIR

Field

Name

REMIT

Field

Name

CpML Field

OTC Commodities

CpML Field

OTC IRS

CpML Field

ETD (Cleared X-Asset)

CpML Field

OTC FX

CpML Field

OTC Commodities Formula Swap

Table 1 -

Counterpa

rty Data

Counte

rparyt

Data

E Reporti

ngRole

E Acting

On

Behalf

Of

E Agent

ID

1 Reporti

ng

timesta

mp

Reporti

ng

Timesta

mp

CpMLDocument/Reporting/Europe/EURegulatory

Details/ReportingTi meStamp

CpMLDocument/Reporting/Europe/EURegulator

yDetails/ReportingTi meStamp







2 Counter

party ID

ID of

Market

Particip

ant

If 'ReportingRole' = "Trader ", "CP_Agent" or

"Clearing_Agent" then this field =


elseif 'Acting onBehalf Of' = "Buyer" then this

field = TradeConfirmation/BuyerParty

elseif 'Acting onBehalf Of' = "Seller" then this

field = TradeConfirmation/SellerParty

elseif 'Acting onBehalf Of' = "Buyer_And_Seller"

then this field = TradeConfirmation/BuyerParty



IRSTraderDetails/SenderID


field = IRSTraderDetails/BuyerParty


field = IRSTraderDetails/SellerParty

elseif 'Acting onBehalf Of' =

"Buyer_And_Seller" then this field =

IRSTraderDetails/BuyerParty


"Clearing_Agent"" then this field =

ETD/SenderID


field = ETD/BuyerDetails/BuyerParty


field = ETD/SellerDetails/SellerParty



ETD/BuyerDetails/BuyerParty



FXTradeDetails/SenderID


field = FXTradeDetails/BuyerParty


field = FXTradeDetails/SellerParty



FXTradeDetails/BuyerParty












of 119

(CP)

Type of

Code

Used


Details/CPIDTypeOfCode


yDetails/CPIDTypeOfCode







Trader

Login

Userna

me


Details/TraderUserName

n/a CpMLDocument/Reporting/Europe/EURegulator

yDetails/TraderUserName


yDetails/TraderUserName

3 ID of

the

other

counter

party

ID of

Other

Market

Paritcia

pnt









then this field = TradeConfirmation/SellerParty



IRSTraderDetails/RecieverID


field = IRSTraderDetails/SellerParty


field = IRSTraderDetails/BuyerParty



IRSTraderDetails/SellerParty


"Clearing_Agent"" then this field

=ETD/RecieverID


field = ETD/RecieverID


field = ETD/RecieverID



ETD/SellerDetails/SellerParty



FXTradeDetails/RecieverID


field = FXTradeDetails/SellerParty


field = FXTradeDetails/BuyerParty



FXTradeDetails/SellerParty











(Other

CP)

Type of

Code

Used

CpMLDocument/Reporting/EURegulatoryDetails/

CPIDTypeOfCode









Trader

Login

Userna

me

(Other

Particia

pnt)


Details/OtherTraderUserName


yDetails/OtherTraderUserName


yDetails/OtherTraderUserName

4 Name

of the

counter

party

n/a CpMLDocument/Reporting/Europe/EURegulatory

Details/ReportingCounterpartyDetails/CPName


yDetails/ReportingCounterpartyDetails/CPNam

e



e



e



e

5 Domicil

e of the

counter

party

n/a CpMLDocument/Reporting/Europe/EURegulatory

Details/ReportingCounterpartyDetails/CPDomicil

e


yDetails/ReportingCounterpartyDetails/CPDomi

cile



cile



cile



cile


of 119

6 Corpora

te

sector

of the

counter

party


Details/ReportingCounterpartyDetails/CPCorpora

teSector


yDetails/ReportingCounterpartyDetails/CPCorp

orateSector



orateSector



orateSector



orateSector

7 Financia

l or

non-

financial

nature

of the

counter

party


Details/ReportingCounterpartyDetails/CPFinanci

alNature


yDetails/ReportingCounterpartyDetails/CPFinan

cialNature



cialNature



cialNature



cialNature

8 Broker

ID

TradeConfirmation/Agents/Agent/BrokerID IRSTradeDetails/Agents/Agent/BrokerID where

'AgentType' = "Broker"

Depending on the role of the reporting entity

ETDTradeDetails/BuyerDetails/Agents/Agent/Br

okerID where 'AgentType' = "Broker"

or

ETDTradeDetails/SellerDetails/Agents/Agent/Br

okerID where 'AgentType' = "Broker"

or

ETDTradeDetails/MTFDetails/Agents/Agent/Bro

kerID where 'AgentType' = "Broker"

FXTradeDetails/Agents/Agent/BrokerID where

'AgentType' = "Broker"

TradeConfirmation/Agents/Agent/BrokerID


of 119

9 Reporti

ng

entity

ID

If 'ReportingRole' = "Trader" then this field =

CNF/SenderID

else


Details/ReportingOnBehalfOf/AgentID

REMIT submission output message mapping:


• this field will be set to the default value in the

REMIT output message

else

• this value will be used to populate the REMIT

output message.

Default = “<name of eRR service provider>”

e.g. “EFETnet”.


IRSTradeDetails/SenderID else


yDetails/ReportingOnBehalfOf/AgentID


ETDradeDetails/SenderID

else



If 'ReportingRole' = "Trader" then this field

=FXTradeDetails/SenderID else




CNF/SenderID

else



REMIT submission output message mapping:


• this field will be set to the default value in

the REMIT output message

else

• this value will be used to populate the REMIT

output message.

Default = “<name of eRR service provider>”

e.g. “EFETnet”.

9 Reporti

ng

Entity

ID


Details/ReportingEntityID



• this field = <Payload>/SenderID

else

• this field = ‘Agent ID’


yDetails/ReportingEntityID


yDetails/ReportingEntityID



• this field = <Payload>/SenderID

else

• this field = ‘Agent ID’

1

0

Clearing

member

ID

n/a n/a NB 'Broker ID' contains the value for any of

the standard Agent Types

If 'Agent Type' = "Clearing_Broker" then

ETDTradeDetails/BuyerDetails/Agents/BrokerI

D

or

ETDTradeDetails/SellerDetails/Agents/BrokerID

or

ETDTradeDetails/MTFDetails/Agents/BrokerID

n/a n/a

1

1

Benefici

ary ID

Benefici

ary ID


Details/Beneficiary

If 'Trading Capacity' <> "A" then this field is set to the

same value as the value as ‘CounterpartyID’ and in

the case of the other counterparty to

‘OtherCounterPartyID’.


yDetails/Beneficiary

If 'Trading Capacity' <> "A" then this field is set to

the same value as the value as ‘CounterpartyID’ and

in the case of the other counterparty to




















1

2

Trading

capacity

Trading

Capacit

y


Details/TradingCapacity


yDetails/TradingCapacity








of 119

1

3

Counter

party

side

Buy/Sel

l

Indicat

or


"Clearing_Agent" then if

TradeConfirmation/SenderID =

TradeConfirmation/Buyer Party then "B" else "S"


field = "B"


field = "S"


then this field = "B"



IRSTradeDetails/SenderID =

IRSTradeDetails/Buyer Party then "B" else "S"


field = "B"


field = "S"


"Buyer_And_Seller" then this field = "B"



ETDTradeDetails/SenderID =

ETDTradeDetails/BuyerDetail/BuyerParty then

"B" else "S"


field = "B"


field = "S"





FXTradeDetails/SenderID =

FXTradeDetails/Buyer Party then "B" else "S"


field = "B"


field = "S"





TradeConfirmation/SenderID =

TradeConfirmation/Buyer Party then "B" else

"S"


field = "B"


field = "S"



1

4

Contrac

t with

non-

EEA

counter

party


Details/OtherCPEEA

if present as it is in the case of agent reporting


Details/ReportingOnBehalfOf/OtherCounteraprty

Details/OtherCPEEA.


yDetails/ OtherCPEEA



yDetails/ReportingOnBehalfOf/OtherCounterapr

tyDetails/OtherCPEEA.



















1

5

Directly

linked

to

commer

cial

activity

or

treasury

financin

g


Details/CommercialTreasury


yDetails/CommercialTreasury







1

6

Clearing

threshol

d


Details/ClearingThreshold


yDetails/ClearingThreshold







1

7

Mark to

market

value of

contract

RegulatoryValuation/Valuation/MtMValue RegulatoryValuation/Valuation/MtMValue RegulatoryValuation/Valuation/MtMValue RegulatoryValuation/Valuation/MtMValue RegulatoryValuation/Valuation/MtMValue

1

8

Currenc

y of

mark to

market

value of

the

contract

RegulatoryValuation/Valuation/MtMCurrency RegulatoryValuation/Valuation/MtMCurrency RegulatoryValuation/Valuation/MtMCurrency RegulatoryValuation/Valuation/MtMCurrency RegulatoryValuation/Valuation/MtMCurrency


of 119

1

9

Valuatio

n date

RegulatoryValuation/Valuation/TimeStamp RegulatoryValuation/Valuation/TimeStamp RegulatoryValuation/Valuation/TimeStamp RegulatoryValuation/Valuation/TimeStamp RegulatoryValuation/Valuation/TimeStamp

2

0

Valuatio

n Time

RegulatoryValuation/Valuation/TimeStamp RegulatoryValuation/Valuation/TimeStamp RegulatoryValuation/Valuation/TimeStamp RegulatoryValuation/Valuation/TimeStamp RegulatoryValuation/Valuation/TimeStamp

2

1

Valuatio

n Type

RegulatoryValuation/Valuation/ValuationType RegulatoryValuation/Valuation/ValuationType RegulatoryValuation/Valuation/ValuationType RegulatoryValuation/Valuation/ValuationType RegulatoryValuation/Valuation/ValuationType

2

2

Collater

alisation


Details/Collateralisation

If 'Clearing Threshold' = "N" then the value in the

output message will be set to “NA”


yDetails/Collateralisation















2

3

Collater

al

portfolio


Details/CollateralPortfolio


yDetails/CollateralPortfolio








of 119

2

4

Collater

al

portfolio

code


Details/CollateralPortfolioCode


yDetails/CollateralPortfolioCode







2

5

Value of

collater

al

RegulatoryCollateral/PortfolioCollateralisation/Co

llateralValue

RegulatoryCollateral/PortfolioCollateralisation/C

ollateralValue


ollateralValue


ollateralValue


ollateralValue

2

6

Currenc

y of the

Collater

al value

RegulatoryCollateral/PortfolioCollateralisation/Co

llateralCurrency


ollateralCurrency


ollateralCurrency


ollateralCurrency


ollateralCurrency

Table 2 -

Common

Data

Commo

n Data

Section 2a

- Contract

type

-

Contrac

t Type

1 Taxono

my

Taxono

my


Details/ProductIdentifier/Taxonomy


yDetails/ProductIdentifier/Taxonomy







Taxono

my

Type


Details/ProductIdentifier/TaxonomyType


yDetails/ProductIdentifier/TaxonomyType


yDetails/ProductIdentifier/TaxonomyType


of 119

2 Product

ID 1

Product

ID


Details/ProductIdentifier/EProduct/ProductID1

or


Details/ProductIdentifier/UProduct/ProductID1

or


Details/ProductIdentifier/IProduct/ProductID1


yDetails/ProductIdentifier/EProduct/ProductID1

or


yDetails/ProductIdentifier/UProduct/ProductID1

or


yDetails/ProductIdentifier/IProduct/ProductID1



or



or





or



or





or



or



Product

Code

Type


Details/ProductIdentifier/EProduct/ProductCodeT

ype

or


Details/ProductIdentifier/UProduct/ProductCode

Type

or


Details/ProductIdentifier/IProduct/ProductCodeT

ype


yDetails/ProductIdentifier/EProduct/ProductCod

eType

or


yDetails/ProductIdentifier/UProduct/ProductCo

deType

or


yDetails/ProductIdentifier/IProduct/ProductCod

eType


yDetails/ProductIdentifier/EProduct/ProductCod

eType

or


yDetails/ProductIdentifier/UProduct/ProductCo

deType

or


yDetails/ProductIdentifier/IProduct/ProductCod

eType


of 119

3 Product

ID 2


Details/ProductIdentifier/EProduct/Product2

or


Details/ProductIdentifier/IProduct/Product2


yDetails/ProductIdentifier/EProduct/Product2

or


yDetails/ProductIdentifier/IProduct/Product2



or





or





or



4 Underlyi

ng

Underly

ing

If

TradeConfirmation/FloatPriceInformation/Comm

odityReferences/CommodityReference element

occurs only once then set to the value "I" for

'Index'

else

set to the value "B" for 'Basket'

IRSTradeDetails/SwapStream/CalculationPerio

dAmount/Calculation/FloatingRateCalculation/F

loatingRateIndex


yDetails/ETDProductInformation/Underlying if

present

else


Set to the value "NA". CpMLDocument/Reporting/Europe/EURegulator

yDetails/FormulaProductInformation/Underlyin

g

Underly

ing

Code

Type

Default to "UPI" n/a Default to "UPI" n/a Default to "UPI"

5 Notional

currenc

y 1

FXD_SWP:

Currency is

TradeConfirmation/FixedPriceInformation/FPCurr

encyUnit if present, otherwise

TradeConfirmation/Currency

OPT*:

Currency is

TradeConfirmation/OptionDetails/PremiumCurre

ncy

FLT_SWP:



TradeConfirmation/FloatPriceInformation/FloatPr

icePayer = TradeConfirmation/BuyerParty.

IRSTradeDetails/SwapStream[1]/CalculationPe

riodAmount/Calculation/NotionalSchedule/Noti

onalStepSchedule/Currency


yDetails/ETDProductInformation/NotionalCurre

ncy1 if present

else


If FXTradeDetails/TransactionType = "OPT"

then

FXTradeDetails/FXOption/PutCurrencyAmount/

Currency

else

FXTradeDetails/FXSingleLeg[1]/ExchangeCurre

ncy[1]/PaymentCurrency

FXD_SWP:

Currency is

TradeConfirmation/FixedPriceInformation/FPCu

rrencyUnit if present, otherwise


OPT*:

Currency is

TradeConfirmation/OptionDetails/PremiumCurr

ency

FLT_SWP:


TradeConfirmation/FloatPriceInformation

where

TradeConfirmation/FloatPriceInformation/Float


of 119

If there are multiple


odityReferences/CommodityReference elements.

Currency is TradeConfirmation/Currency

If there is one


odityReferences/CommodityReference element:

Currency is


odityReferences/CommodityReference[1]/Sprea

dInformation/SpreadCurrencyUnit if present,

otherwiseTradeConfirmation/Currency

PHYS_INX:


FOR:


PricePayer = TradeConfirmation/BuyerParty.

Currency is

TradeConfirmation/FloatPriceInformation/Form

ulaSpreadInformation/SpreadCurrencyUnit if

present, otherwise


PHYS_INX:


6 Notional

currenc

y 2

FXD_SWP:




icePayer = TradeConfirmation/SellerParty. N.B.

for a FXD_SWP the floating leg is always the

seller's leg.





If there is one



Currency is





OPT*:

Currency is

TradeConfirmation/OptionDetails/PremiumCurre

ncy

FLT_SWP:




icePayer = TradeConfirmation/SellerParty.





If there is one



Currency is







onalStepSchedule/Currency


yDetails/ETDProductInformation/NotionalCurre

ncy2 if present

else



then

FXTradeDetails/FXOption/CallCurrencyAmount/

Currency

else



FXD_SWP:



where


PricePayer =

TradeConfirmation/SellerParty.N.B. for a

FXD_SWP the floating leg is always the seller's

leg.

Currency is



present, otherwise


OPT*:

Currency is

TradeConfirmation/OptionDetails/PremiumCurr

ency

FLT_SWP:



where


PricePayer = TradeConfirmation/SellerParty.

Currency is



present, otherwise


PHYS_INX:



of 119

PHYS_INX:

TradeConfirmation/PriceUnit/Currency FOR:

Currency is

TradeConfirmation/PriceUnit/Currency

7 Delivera

ble

currenc

y

Currenc

y

FOR, PHYS_INX, FXD_SWP, FLT_SWP:


OPT, OPT_PHYS_INX, OPT_FXD_SWP,

OPT_FLT_SWP, OPT_FIN:

TradeConfirmation/OptionDetails/OptionCurrenc

y

FXD_FXD_SWP, FXD_SWP, FLT_SWP:

CNF/IRSTradeDetails/Currency

OPT_ FXD_FXD_SWP, OPT_FXD_SWP,


CNF/IRSTradeDetails/OptionDetails/OptionCurr

ency


yDetails/ETDProductInformation/DeliverableCu

rrency if present

else


If FXTradeDetails/TransactionType = "OPT" or

"OPT_FXD_FXD_SWP" then

FXTradeDetails/FXOption/CallCurrencyAmount/

Currency

else

FXTradeDetails/FXSingleLeg[1]/ExchangeRate/

Currency2

FOR, PHYS_INX, FXD_SWP, FLT_SWP:


OPT, OPT_PHYS_INX, OPT_FXD_SWP,


TradeConfirmation/OptionDetails/OptionCurren

cy

Section 2b

- Details

on the

transactio

n

-

Details

of

Transac

tion: If

a

Product

ID is

reporte

d and

contain

s the

relevan

t

product

informa

tion

below,

this

informa

tion is

not

require

d to be

reporte

d

Transac

tion

Type

TradeConfirmation/TransactionType n/a ETDTradeDetails/TransactionType n/a TradeConfirmation/TransactionType


of 119

8 Trade

ID

Transac

tion ID


Details/UTI


yDetails/UTI


yDetails/UTI


yDetails/UTI


yDetails/UTI

Linked

Transac

tion ID


Details/LinkedTransactionID


yDetails/LinkedTransactionID


yDetails/LinkedTransactionID

9 Transac

tion

referenc

e

number

Transac

tion

Rrefere

nce

Number


Details/TradeID


yDetails/TradeID

CpMLDocument/ETDTradeDetails/ClearingPara

meters/DealID if present,

else


yDetails/TradeID


yDetails/TradeID


yDetails/TradeID

1

0

Venue

of

executio

n

Organis

ed

market

place

ID/OTC


Details/ExecutionVenue


yDetails/ExecutionVenue







1

1

Compre

ssion


Details/Compression


yDetails/Compression






of 119

1

2

Price /

rate

Price FXD_SWP:

TradeConfirmation/DeliveryPeriods/FixedPrice

for the 'fixed price'

OPT*:

TradeConfirmation/OptionDetails/TotalPremiumV

alue

FLT_SWP:

TradeConfirmation/FloatPriceInformation[1]/Co

mmodityReference[1-

n]/SpreadInformation/SpreadAmount or Spread

Rate if present until the first occurrence of a non

zero value is found

else


mmodityReference[1-



zero value is found

else

"0"TradeConfirmationTradeConfirmationTradeCo

nfirmation

PHYS_INX:


odityReference[1-



zero value is found TradeConfirmationElse

"0"

FOR:

CpMLDocument/TradeConfirmation/TimeInterval

Quantity[1]/Price

or if Commodity is an 'Emissions Commodity'

CNF/EUATradeDetails/Price

Set to 999999999999999.99999 ETDTradeDetails/ClearingParameters/UnitPrice If FXTradeDetails/TransactionType = "OPT"

then

SUM(FXTradeDetails/FXOption/PremiumPayme

nts[1-n]/PremiumPaymentValue)

else

FXTradeDetails/FXSingleLeg[1]/ExchangedRate

[1]/SpotRate +

FXTradeDetails/FXSingleLeg[1]/ExchangedRate

[1]/ForwardPoints

FXD_SWP:

TradeConfirmation/DeliveryPeriods/FixedPrice

for the 'fixed price'

OPT*:

TradeConfirmation/OptionDetails/TotalPremium

Value

FLT_SWP:

TradeConfirmation/FloatPriceInformation[1]/Fo

rmulaSpreadInformation/SpreadAmount or

Spread Rate if present

else

TradeConfirmation/FloatPriceInformation[2]/Fo

rmulaSpreadInformation/SpreadAmount or

Spread Rate if present

else

"0"TradeConfirmationTradeConfirmationTradeC

onfirmationPHYS_INX:


ulaSpreadInformation/SpreadAmount or

Spread Rate

Else

"0"

1

3

Price

Notatio

n

Price

Notatio

n

FXD_SWP:

CpMLDocument/TradeConfirmation/FixedPriceInf

ormation/FPCurrency for the 'fixed price' if

present

else


OPT*:

CpMLDocument/TradeConfirmation/OptionDetail

s/PremiumCurrency

FLT_SWP:

CpMLDocument/TradeConfirmation/FloatPriceInf

ormation[p]/CommodityReference[q]/SpreadInf

ormation/SpreadCurrencyUnit or "100" for a

SpreadRate

where [p] and [q] identify the first occurrence of

a non zero value in


2]/CommodityReference[1-


RateTradeConfirmationTradeConfirmationelse


PHYS_INX:

Set to “NA” CpMLDocument/Reporting/Europe/EURegulator

yDetails/ETDProductInformation/PriceNotation

if present

else



then

FXTradeDetails/FXOption/PremiumPayments[1]

/PremiumCurrency

else



FXD_SWP:

CpMLDocument/TradeConfirmation/FixedPriceI

nformation/FPCurrency for the 'fixed price' if

present

else


OPT*:

CpMLDocument/TradeConfirmation/OptionDeta

ils/PremiumCurrency

FLT_SWP:

CpMLDocument/TradeConfirmation/FloatPriceI

nformation[p]/FormulaSpreadInformation/Spre

adCurrencyUnit or "100" for a SpreadRate

where [p] identifies the first occurrence of a

non zero value in


2]/FormulaSpreadInformation/SpreadAmount

or Spread Rate

else


PHYS_INX:


of 119

CpMLDocument/TradeConfirmation/FloatPriceInf

ormation[1]/CommodityReference[q]/SpreadInf

ormation/SpreadCurrencyUnit or "100" for a

SpreadRate

where [q] identify the first occurrence of a non

zero value in


mmodityReference[1-


RateTradeConfirmationOR


FOR:


CpMLDocument/TradeConfirmation/FloatPriceI

nformation[1]/FormulaSpreadInformation/Spre

adCurrencyUnit or "100" for a

SpreadRateTradeConfirmationTradeConfirmatio

nTradeConfirmationOR


FOR:


1

4

Notional

amount

Notiona

l

Amount

FXD_SWP:

SUM(TradeConfirmation/DeliveryPeriods/Deliver

yPeriod/DeliveryPeriodNotionalQuantity *

FixedPrice)


SUM(TradeConfirmation/DeliveryPeriods/Deliver

yPeriod/DeliveryPeriodNotionalQuantity *


FLT_SWP:




icePayer = TradeConfirmation/BuyerParty.



odityReferences/CommodityReference elements

then


Details/NotionalAmount

If there is one



TradeConfirmation/TotalVolume *



dInformation/SpreadAmount

If there is no



TradeConfirmation/TotalVolume *

TradeConfirmation/FloatPriceInformation/Formul

aSpreadInformation/SpreadAmount or 0 if there

is no FormulaSpreadInformation element



Details/NotionalAmount

FOR, OPT:

TradeConfirmation/TotalContractValue


yDetails/NotionalAmount if present



onalStepSchedule/InitialValue



else

if Transaction Type = "OPT*" then


ETDTradeDetails/ClearingParameters/StrikePric

e *


yDetails/ETDProductInformation/PriceMultiplier

else


ETDTradeDetails/ClearingParameters/UnitPrice

*





else


then

If FXTradeDetails/FXOption/Strike/QuoteBasis

= "PutCurrencyPerCallCurrency" then


Amount DIVIDED BY

FXTradeDetails/FXOption/Strike/FXRate else


Amount *


else

FXTradeDetails/FXSingleLeg[1]/PaymentAmou

nt

FXD_SWP:

SUM(TradeConfirmation/DeliveryPeriods/Delive

ryPeriod/DeliveryPeriodNotionalQuantity *

FixedPrice)


SUM(TradeConfirmation/DeliveryPeriods/Delive

ryPeriod/DeliveryPeriodNotionalQuantity *


FLT_SWP:



where


PricePayer = TradeConfirmation/BuyerParty.

TradeConfirmation/FloatPriceInformation/Com

modityReferences/CommodityReference

element: TradeConfirmation/TotalVolume *


ulaSpreadInformation/SpreadAmount or 0 if

there is no FormulaSpreadInformation element



yDetails/NotionalAmount


of 119

1

5

Price

multipli

er

Price

Multipli

er

Set to 1 Set to 1 CpMLDocument/Reporting/Europe/EURegulator


if present

else


Set to 1 Set to 1

Quantit

y

TradeConfirmation/TotalVolume n/a ETDTradeDetails/ClearingParameters/Lots *

'Price Multiplier'

n/a TradeConfirmation/TotalVolume

1

6

Quantit

y

Set to 1 Set to 1 ETDTradeDetails/ClearingParameters/Lots Set to 1 Set to 1

Quantit

y Unit

TradeConfirmation/TotalVolumeUnit n/a CpMLDocument/Reporting/Europe/EURegulator

yDetails/ETDProductInformation/TotalVolumeQ

uantityUnit if present

else


n/a TradeConfirmation/TotalVolumeUnit

1

7

Up-front

paymen

t


Details/UpFrontPayment


yDetails/UpFrontPayment







1

8

Delivery

type

Deliver

y Type

If TradeConfirmation/TransactionType = "FOR"

or "PHYS_INX" or "OPT" or "OPT_PHYS_INX"

then must equal "P"

else if TradeConfirmation/TransactionType =

"FXD_SWP" or "FLT_SWP" then must equal "C"


"OPT_FIN" or "OPT_FXD_SWP" or

"OPT_FLT_SWP" then if

TradeConfirmation/OptionDetails/CashSettled =

"Y" then "C" else "P".

Must equal "C" CpMLDocument/Reporting/Europe/EURegulator

yDetails/ETDProductInformation/DeliveryType

if present

else


Must equal "C" If TradeConfirmation/TransactionType = "FOR"

or "PHYS_INX" or "OPT" or "OPT_PHYS_INX"

then must equal "P"


"FXD_SWP" or "FLT_SWP" then must equal "C"


"OPT_FIN" or "OPT_FXD_SWP" or

"OPT_FLT_SWP" then if

TradeConfirmation/OptionDetails/CashSettled

= "Y" then "C" else "P".

1

9

Executi

on

timesta

mp

Transac

tion

Timesta

mp


Details/ExecutionTimeStamp if present

else

TradeConfirmation/TradeDate & TradeTime


yDetails/ExecutionTimeStamp if present

else

IRSTradeDetails/TradeDate & TradeTime



else

ETDTradeDetails/BuyerDetails/ExecutionTimeS

tamp

or

ETDTradeDetails/SellerDetails/ExecutionTimeSt

amp

or

ETDTradeDetails/MTFDetails/ExecutionTimeSta

mp



else

FXTradeDetails/TradeDate & TradeTime



else

TradeConfirmation/TradeDate & TradeTime


of 119

2

0

Effectiv

e date

Effectiv

e Date

TradeConfirmation/TimeIntervalQuantities[1]/St

artDate

or

TradeConfirmation/EffectiveDate

IRSTradeDetails/Swapstream[1]/CalculationPer

iodDates/EffectiveDate


yDetails/ETDProductInformation/EffectiveDate

if present

else

ETDTradeDetails/Product/DeliveryPeriod/Start

Date (if present)

else



then

FXTradeDetails/OptionDetails/EffectiveDate

else

EARLIEST(FXTradeDetails/FXSingleLeg[1]/Exch

angedCurrency[1-2]/ValueDate)

TradeConfirmation/TimeIntervalQuantities[1]/S

tartDate

or

TradeConfirmation/EffectiveDate

2

1

Maturity

date

Maturit

y Date

If ActionType = "N" or "M" then

TradeConfirmation/TimeIntervalQuantities[N]/E

ndDate

or

TradeConfirmation/TerminationDate



iodDates/TerminationDate



yDetails/ETDProductInformation/MaturityDate

if present

else

ETDTradeDetails/Product/DeliveryPeriod/EndDa

te (if present)

else




then

FXTradeDetails/OptionDetails/FXExerciseDate/

ExpiryDate

else

FXTradeDetails/FXSingelLeg[1]/ValueDate


TradeConfirmation/TimeIntervalQuantities[N]/

EndDate

or


2

2

Termina

tion

date

Termin

ation

Date

If ActionType = "C" or "Z" then

If present


Details/EarlyTerminationDate,

Else

If present

TradeConfirmation/TimeIntervalQuantities[N]/E

ndDate

Else

If present TradeConfirmation/TerminationDate


If present


yDetails/EarlyTerminationDate

Else

If present


iodDates/TerminationDate




else


yDetails/ReportingTimestamp


If present



Else

If present


then

FXTradeDetails/OptionDetails/FXExerciseDate/

ExpiryDate

else



If present



Else

If present

TradeConfirmation/TimeIntervalQuantities[N]/

EndDate

Else

If present


2

3

Date of

settlem

ent

Settlem

ent

Date


Details/SettlementDates[1-n]/DateOfSettlement

if present

else

If TransactionType = "FOR" or "PHYS_INX" then


Details/SettlementDates[1-n]/DateOfSettlement

else

If TransactionType = "OPT" then

TradeConfirmation/OptionDetails/PremiumPaym

entDate

else

If TransactionType = "OPT_PHYS_INX" or

"OPT_FXD_SWP" or "OPT_FLT_SWP" or

"OPT_FIN" then

TradeConfirmation/OptionDetails/PremiumPaym

ents[1-n]/PremiumPaymentDate

else

If TransactionType = "FXD_SWP" or "FLT_SWP"

then

TradeConfirmation/DeliveryPeriods[1-

n]/PaymentDate


yDetails/SettlementDates[1-

n]/DateOfSettlement if present

else

If TransactionType = "OPT_FXD_SWP" or

"OPT_FXD_FXD_SWP" or "OPT_FLT_SWP" then

IRSTradeDetails/OptionDetails/PremiumPayme

nt[1-n]/PremiumPaymentDate


yDetails/SettlementDates/DateOfSettlement[1-

n]


then

if present:

FXTradeDetails/OptionDetails/CashSettlement/

SettlementDate

else

FXTradeDetails/OptionDetails/PremiumPaymen

ts[1-N]/PremiumPaymentDate

else

If present:

FXTradeDetails/FXSingelLeg[1]/NonDerliverabl

eSettlement/SettlementDate

else




n]/DateOfSettlement if present

else

If TransactionType = "PHYS_INX" then



n]/DateOfSettlement

else

If TransactionType = "OPT_PHYS_INX" or

"OPT_FXD_SWP" or "OPT_FLT_SWP" or

"OPT_FIN" then

TradeConfirmation/OptionDetails/PremiumPay

ments[1-n]/PremiumPaymentDate

else

If TransactionType = "FXD_SWP" or

"FLT_SWP" then

TradeConfirmation/DeliveryPeriods[1-

n]/PaymentDate


of 119

2

4

Master

Agreem

ent type

Master

Agreem

ent

Type

TradeConfirmation/Agreement IRSTradeDetails/Agreement n/a FXTradeDetails/Agreement TradeConfirmation/Agreement

2

5

Master

Agreem

ent

version

Master

Agreem

ent

Version


Details/MasterAgreementVersion


yDetails/MasterAgreementVersion





Section 2c

- Risk

mitigation

/

Reporting

2

6

Confirm

ation

timesta

mp

Confirm

ation

Timesta

mp

See Confirmation Event message

or


Details/ConfirmationTimestamp


or


yDetails/ConfirmationTimestamp

n/a See Confirmation Event message

or




or



2

7

Confirm

ation

means

Confirm

ation

Means


Details/ConfirmationMeans


or


yDetails/ConfirmationMeans

n/a See Confirmation Event message

or





Section 2d

- Clearing

2

8

Clearing

obligati

on


Details/ClearingObligation


yDetails/ClearingObligation





2

9

Cleared Cleared Default "N" Default "N" Default "Y" Default "N" Default "N"

3

0

Clearing

timesta

mp

Clearin

g

Timesta

mp

n/a n/a ETDTradeDetails/BuyerFDetails/ExecutionTime

Stamp

or

ETDTradeDetails/SellerDetails/ExecutionTimeSt

amp

or

ETDTradeDetails/MTFDetails/ExecutionTimeSta

n/a n/a


of 119

mp

3

1

CCP CCP n/a n/a ETDTradeDetails/ClearingParameters/ClearingH

ouseID

n/a n/a

3

2

Intragro

up


Details/IntraGroup


yDetails/IntraGroup


yDetails/IntraGroup


yDetails/IntraGroup


yDetails/IntraGroup

Section 2e

- Interest

Rates

3

3

Fixed

rate of

leg 1

n/a IRSTradeDetails/swapStream[1]/calculationPer

iodAmount/calculation/fixedRateSchedule/initia

lValue

ETDTradeDetails/ClearingParameters/UnitPrice n/a n/a

3

4

Fixed

rate of

leg 2


iodAmount/calculation/fixedRateSchedule/initia

lValue


yDetails/ETDProductInformation/FixedRateOfLe

g2 if present

else

derive from


else

this field must be omitted in the output

messge.

n/a n/a

3

5

Fixed

rate day

count


iodAmount/calculation/dayCountFraction


yDetails/ETDProductInformation/FixedRateDay

Count if present

else

derive from


else


messge.

n/a n/a

3

6

Fixed

leg

paymen

t

frequen

cy

n/a IRSTradeDetails/swapStream[1]/paymentDate

s/paymentFrequency/periodmultiplier

and

IRSTradeDetails/swapStream[1]/paymentDate

s/paymentFrequency/period


yDetails/ETDProductInformation/FixedLegPaym

entFrequency if present

else

derive from


else


messge.

n/a n/a

3

7

Floating

rate

paymen

t

frequen

cy

n/a IRSTradeDetails/swapStream[2]/paymentDate

s/paymentFrequency/periodmultiplier

and

IRSTradeDetails/swapStream[2]/paymentDate

s/paymentFrequency/period


yDetails/ETDProductInformation/FloatingRateP

aymentFrequency if present

else

derive from


n/a n/a


of 119

else


messge.

3

8

Floating

rate

reset

frequen

cy

n/a IRSTradeDetails/swapStream[2]/resetDates/re

setFrequency/periodmultiplier

and

IRSTradeDetails/swapStream[2]/resetDates/re

setFrequency/period


yDetails/ETDProductInformation/FloatingRateR

esetFrequency if present

else

derive from


else


messge.

n/a n/a

3

9

Floating

rate of

leg 1


iodAmount/calculation/floatingRateCalculation/

floatingRateIndex


yDetails/ETDProductInformation/FloatingRateof

Leg1 if present

else

derive from


else


messge.

n/a n/a

4

0

Floating

rate of

leg 2


iodAmount/calculation/floatingRateCalculation/

floatingRateIndex


yDetails/ETDProductInformation/FloatingRateof

Leg2 if present

else

derive from


else


messge.

n/a n/a

Section 2f

- Foreign

Exchange

4

1

Currenc

y 2


yDetails/ETDProductInformation/Currency2 if

present

else

derive from


else


messge.

If FXTradeDetails/TransactionType = "OPT" or

"OPT_FXD_FXD_SWP" then


Currency

else

FXTradeDetails/FXSingleLeg[1]/ExchangedCurr

ency[1]/PaymentCurrency

4

2

Exchan

ge rate

1


yDetails/ETDProductInformation/ExchangeRate

1 if present

else

derive from


else


messge.


then


else

FXTradeDetails/FXSingleLeg[1]/ExchangeRate[

1]/SpotRate


of 119

4

3

Forward

exchang

e rate

ETDTradeDetails/ClearingParameters/UnitPrice If FXTradeDetails/TransactionType = "OPT"

then


else


1]/SpotRate +


1]/ForwardPoints

4

4

Exchan

ge rate

basis


yDetails/ETDProductInformation/ExchangeRate

Basis if present

else

derive from


else


messge.


then

FXTradeDetails/FXOption/Strike/QuoteBasis

else


1]/QuoteBasis

Section 2g

-

Commoditi

es

General

4

5

Commo

dity

base

If


odityReference[1]/IndexCommodity is not

present then set to “NA”

Else

if it is in the set of values

'Agricultural' then = "AG"

elseif

'Energy' = "EN"

elseif

'Wet Freight' OR 'Dy Frieight' = "FR"

elseif

'Metals' = "ME"

elseif

'Emissions' OR 'Weather' = "EV"

else

"EX"

n/a If ETDTradeDetails/PrimaryAssetClass = "CO"

then


yDetails/ETDProductInformation/CommodityBa

se if present

else

derive from


else

this field must be set to “NA”.


yDetails/FormulaProductInformation/Commodit

yBase


of 119

4

6

Commo

dity

details

Derive similarly to above from


odityReference[1]/IndexCommodity mapping

CpML values to EMIR classifications else set to

"NA"

n/a If 'Commodity Base' is present in the output

message then this field must be present and

derive from

ETDTradeDetails/Product/CRAProductID else it

must not be present in the output message

else set to "NA".


yDetails:/FormulaProductInformation/Commodi

tyDetail else set to "NA"

Energy n

4

7

Delivery

point or

zone

Deliver

y Point

or Zone

TradeConfirmation/DeliveryPointArea n/a CpMLDocument/Reporting/Europe/EURegulator

yDetails/ETDProductInformation/DeliveryPoint

OrZone if present

else

derive from


n/a n/a

4

8

Interco

nnectio

n Point

Interco

nnectio

n Point

TradeConfirmation/DeliveryPointArea n/a CpMLDocument/Reporting/Europe/EURegulator

yDetails/ETDProductInformation/Interconnectio

nPoint if present

Else


n/a n/a

4

9

Load

type

Load

Type


Details/LoadType


yDetails/ETDProductInformation/LoadType if

present

Else


n/a n/a

5

0

Delivery

start

date

and

time

Delvier

y Start

Date &

Time

TradeConfirmation/TimeIntervalQuantities[1…N]

/StartDate

n/a If ETDTradeDetails/Product/DelvieryPeriod is

present then

ETDTradeDetails/Product/DelvieryPeriod/Delive

ryStartDateAndTime

else


yDetails/ETDProductInformation/DeliveryStart

DateTime if present

else

derive from

ETDTradeDetails/Product/CRAProductCode.

n/a n/a


of 119

5

1

Delivery

end

date

and

time

Deliver

y End

Date &

Time

TradeConfirmation/TimeIntervalQuantities[1...N

]/EndDate

n/a If ETDTradeDetails/Product/DelvieryPeriod is

present then

ETDTradeDetails/Product/DelvieryPeriod/Delive

ryEndDateAndTime

else


yDetails/ETDProductInformation/DeliveryEndD

ateTime if present

else

derive from


n/a n/a

5

2

Contrac

t

capacity

Transac

tion

Capacit

y

TradeConfirmation/TimeIntervalQuantities[1]/Ca

pacity

n/a 'CpMLDocument/Reporting/Europe/EURegulato

ryDetails/ETDProductInformation/ContractCapa

city if present

else

derive from


n/a n/a

5

3

Quantit

y Unit

Qunatit

y Unit

(of

capacit

y)

TradeConfirmation/CapcityUnit n/a CpMLDocument/Reporting/Europe/EURegulator

yDetails/ETDProductInformation/EnergyQuantit

yUnit if present

else

derive from


n/a n/a

5

4

Price/ti

me

interval

quantiti

es

Price/Ti

me

Interval

Quantit

y

TradeConfirmation/TimeIntervalQuantities[1…N]

/Price

n/a ETDTradeDetails/ClearingParameters/UnitPrice n/a n/a

Section 2h

- Options

5

5

Option

type

Option

Type

TradeConfirmation/OptionsDetails/OptionType IRSTradeDetails/OptionDetails/OptionType ETDTradeDetails/Product/OptionDetails/Option

Type

FXTradeDetails/OptionDetails/OptionType TradeConfirmation/OptionsDetails/OptionType

5

6

Option

style

(exercis

e)

Option

Style

TradeConfirmation/OptionsDetails/OptionStyle IRSTradeDetails/OptionDetails/OptionStyle ETDTradeDetails/Product/OptionDetails/Option

Style

FXTradeDetails/OptionDetails/OptionStyle TradeConfirmation/OptionsDetails/OptionStyle

5

7

Strike

price

(cap/flo

or rate)

Strike

Price

TradeConfirmation/OptionsDetails/StrikePrice IRSTradeDetails/OptionDetails/StrikePrice ETDTradeDetails/Product/OptionDetails/StrikeP

rice

FXTradeDetails/OptionDetails/Strike/FXRate TradeConfirmation/OptionsDetails/StrikePrice

Section 2i

-

Modificati

ons to the

report


of 119

5

8

Action

type

Action

Type

CpmlDocument/Reporting/Europe/EURegulatory

Details/Action/ActionType

CpmlDocument/Reporting/Europe/EURegulator

yDetails/Action/ActionType







5

9

Details

of

action

type

Details

of

Action

Type

CpmlDocument/Reporting/Europe/EURegulatory

Details/Action/ActionDetail


yDetails/Action/ActionDetail







Non-

Standa

rd

-

Contrac

t Type

Contrac

t

descript

ion

-

Details

of the

contrac

t

Deliver

y

period

-

Additio

nal

informa

tion for

non-

standar

dised


of 119

contrac

ts

Enclosu

re of

the

non-

standar

dised

contrac

t

EFF EETTEL ECCT TRROO NNIICC U RREEGGULLATTOORRYY … _ Electronic Data Exchange...1 CpML 5.1.1...

Documents

Transcript of EFF EETTEL ECCT TRROO NNIICC U RREEGGULLATTOORRYY … _ Electronic Data Exchange...1 CpML 5.1.1...