European Commodity Market Regulations Part 1

Research Report – 2014/001.1a
Updated 23rd April 2014
European Commodity Market Regulations
Implementation, Impacts and Solutions
Part 1 of 2
Sponsored by

European Energy Market Regulations
© Commodity Technology Advisory LLC and ETR Advisory Ltd, 2014, All Rights Reserved. 2
Contents
Introduction....................................................................................................................................................5
Big Compliance comes to Energy Trading.......................................................................................................6
Background.....................................................................................................................................................7
The Banking crisis of 2007/2008.................................................................................................................7
MiFID II........................................................................................................................................................7
Basle III/CRD IV ...........................................................................................................................................8
The EU “Third Package” and REMIT............................................................................................................8
Key Themes.....................................................................................................................................................8
EMIR Rules Overview....................................................................................................................................10
Different types of party under EMIR ........................................................................................................10
REMIT Rules Overview..................................................................................................................................11
Timings..........................................................................................................................................................12
The EMIR Threshold for Non-Financial Counterparties................................................................................13
Threshold calculation................................................................................................................................13
Trade Reporting............................................................................................................................................15
Trade Reporting for EMIR.........................................................................................................................15
What must be reported?......................................................................................................................15
Where data should be reported?.........................................................................................................15
Which data must be reported? ............................................................................................................15
When should data be reported? ..........................................................................................................16
Backloading ..........................................................................................................................................16
Trade Reporting for REMIT.......................................................................................................................16
Which data must be reported? ............................................................................................................16
Where should data be reported?.........................................................................................................17
What data types must be reported? ....................................................................................................17
Non Standard Trades............................................................................................................................19
Data Destinations .....................................................................................................................................19
Implementing a trade reporting solution.................................................................................................21
Solution types.......................................................................................................................................21
Required Solution Activities......................................................................................................................22
Data sourcing and gap analysis ............................................................................................................22
Data mapping and capture...................................................................................................................22
Configuration choice and connection mechanism...............................................................................22
Data enrichment...................................................................................................................................22

Pre trade data.......................................................................................................................................22
Issues being encountered.........................................................................................................................23
LEIs (Legal Entity Identifiers) ................................................................................................................23
The UTI (Unique Trade Identifier).........................................................................................................23
Which rules apply to a trade?...............................................................................................................24
Changing requirements........................................................................................................................24
Risk Management .........................................................................................................................................25
Timely confirmation..................................................................................................................................26
Portfolio Reconciliation and Dispute Resolution......................................................................................26
The reconciliation process........................................................................................................................26
Typical modes of operation..................................................................................................................26
Bilateral reconciliation..........................................................................................................................27
Third Party Service Provider.................................................................................................................27
Agent ....................................................................................................................................................27
Contractual Changes required for Portfolio Reconciliation and dispute resolution ............................27
Portfolio Compression..........................................................................................................................28
Bilateral Compression...........................................................................................................................28
Multilateral Compression.....................................................................................................................28
Is it worth compressing if it is not mandatory?....................................................................................29
Daily mark to market/model................................................................................................................29
European Regulatory Solutions Directory ....................................................................................................30
Types of service and software..................................................................................................................30
Trade Repositories................................................................................................................................30
Reporting Services................................................................................................................................35
NASDAQ OMV.......................................................................................................................................35
Specialist Reporting and aggregation software....................................................................................37
E/CTRM offerings..................................................................................................................................44
Portfolio Reconciliation/Dispute Resolution........................................................................................47
Portfolio Compression..........................................................................................................................48
TriOptima triReduce.............................................................................................................................48
Trade Surveillance ................................................................................................................................49
About The Authors........................................................................................................................................52
Aviv Handler..............................................................................................................................................52
Dr. Gary M. Vasey.....................................................................................................................................52
ComTech Advisory....................................................................................................................................53
ETR Advisory .............................................................................................................................................53

About the Sponsor........................................................................................................................................54
TriOptima..................................................................................................................................................54

Introduction
Increased regulation and oversight of European energy and commodity trading has commenced as
various aspects of the EMIR (European Market Infrastructure Regulation), REMIT (Regulation on
wholesale Energy Market Integrity and Transparency), and other regulations start to bite, with Trade
Reporting under EMIR going live on February 12th
2014. The regulations are already having an impact
on trading and risk management business practices and may have far reaching and as yet, even un-
thought of consequences for the industry. Despite several go live dates having passed, there is still a
lack of clarity over many of the details. This has left a trail of confusion in the wake of the rule roll
out.
The Trade Reporting go live was but one milestone in the many that await the energy and
commodity trading industry. REMIT, mandatory clearing, MiFID II and others will follow in the not
too distant future. And as with the rules we have already seen there is a great deal of confusion
about scope, applicability and detail.
This research, conducted jointly by industry leading analysts and experts, Commodity Technology
Advisory and ETR Advisory, aims to help to clarify the issues and to examine the impact of regulation
on software requirements in the trading and risk management business function. It looks at the
current implementation schedule of the regulations and examines some of the implementation
impacts of the yet to be defined details of the regulations. It also reviews the software, services and
platforms available in the market to support aspects of the European regulatory environment and
establish the readiness of European traders for operating under the regulations.
The research is focused on understanding:
Implementation time frames and what this means to traders
The unknowns and yet to be defined details and their implications as the rules are rolled out
A review of solutions, services and platforms in the market designed to support these
regulations, including how the solutions offered for EMIR reporting fared during the go live
Readiness of trading organizations from a business process, technology and holistic
standpoint – This is a separate report.
This report is an updated version of the original written in the second half of 2013. It adds notes of
post go live reality, and also updates on the next regulations to be implemented.

Big Compliance comes to Energy Trading
The energy and broader commodity-trading world is in the process of its latest stage in its maturity:
That of “Big Compliance”.
The rules that most energy traders will have to implement not only require a great deal of IT work,
but also some process re-engineering and an acceptance of the fact that compliance will occupy a
significantly larger component of overall activities and budgets on an on-going basis. One can argue
as to whether this is appropriate for an industry that many feel is “non-systemic”, but as things stand
most of these changes will happen with the result that industry business processes, practices, the IT
landscape and possibly even the players, will change.
The Trade Reporting go live underlines this point. While the “big bang” IT project could be
considered to be heading towards the “stabilization” phase, it is expected that many more changes
will come. And after that, we expect the Financial Stability Board (FSB) review of Trade reporting
implementation to require more re work.
This is clearly therefore simply the start of an ongoing stream of work.
Advertisement

Background
The upcoming rule sets stem initially from two sources:
1) Reactions to the Banking crisis of 2007/2008
2) The EU “3rd
Package” - which further aims to create a single European gas and power
market.
The Banking crisis of 2007/2008
Following the crisis, several initiatives kicked off in order to attempt prevention of a repeat. Key
amongst these was the declaration that arose out of the 2009 G20 Pittsburgh Summit, which stated:
“All standardized OTC derivative contracts should be traded on exchanges or electronic
trading platforms, where appropriate, and cleared through central counterparties by end‐
2012 at the latest. OTC derivative contracts should be reported to trade repositories. Non‐
centrally cleared contracts should be subject to higher capital requirements.”
In essence, the objective of this declaration was a reduction in the “systemic risk” that brought the
crisis about.
Each G20 country undertook to conform to the declaration, and this has resulted in several
initiatives including Dodd Frank in the US, and EMIR (European Marketing Infrastructure Regulation)
in the EU. Other G20 countries are also in the process of implementing their versions.
Amongst the principles encompassed in the declaration, were:
- Transparency
- Move to standardized exchanges
- Risk reduction
These have led to a variety of pillars including reporting of trades to repositories, a move to OTC
Clearing, several risk reduction techniques and the desired imposition of mandatory position limits
on commodities.
MiFID II
In addition to EMIR, other initiatives were created in order to address the issues. In Europe, this
includes MiFID II. The Markets in Financial Instruments Directive (MiFID) came into force in 2007 and
introduced several new concepts for financial companies, such as “passporting” i.e. the requirement
to be able to execute equally in any European location, and a requirement to provide best execution.
It introduced the concept of a Multilateral Trading Facility (MTF) to which certain transparency and
operation rules apply.
However, the majority of commodity traders received an exemption from these rules.
MiFID II extends the original initiative in many ways, including a wider ranging Organized Trading
Facility (OTF). Of particular interest to our market are three items:
1) The potential narrowing of the commodity trader exemption, in many cases,
2) The widening of the scope of what a derivative is, bringing more physical trades into the
threshold calculation
3) Mandatory Position Limits (which in the US are being implemented within Dodd Frank).

The result of some of the above will mean that more energy traders will find themselves either
needing to or wanting to obtain MiFID licenses, thereby turning them into Financial Counterparties.
That in itself has consequences including the introduction of mandatory clearing.
Basle III/CRD IV
The Basle III accords modify the Basle II accords targeted at the banking industry. These outline how
banks should calculate their capital requirements, for credit, market and operational risk, amongst
other things. Basle III moves to a more prudent capital calculation methodology and capital ratios for
banks. This includes the use of Credit Value Adjustment (CVA) and similar measures. In Europe, the
rules are being implemented as the fourth Capital Requirements Directive (CRD). It also requires
extra reporting such as COREP.
Some of the new capital calculation rules could well apply to energy traders, although probably not
until 2017. However, these are yet another set of rules that should be on Energy Traders’ radars,
especially if they obtain MiFID licenses, which brings CRD IV straight into scope.
The EU “Third Package” and REMIT
The European Union third package was adopted in 2009. It aimed to further open up Europe’s gas
and power markets using several means including unbundling previously vertically integrated gas
and power companies, the move to standardize TSOs, and the creation of a single market.
As part of this framework, the Regulation of Wholesale Markets Transparency and Integrity (REMIT)
aims to increase transparency within the market, by the prohibition of insider trading, and aims to
further limit market abuse.
The prohibition of market abuse involves not only avoiding attempted and actual market
manipulation, but also reporting trade and “fundamental” data to the authorities.
REMIT applies to all wholesale physical Gas, Power, LNG and Emission trading in Europe as well as to
connected derivatives.
Key Themes
There are four key “themes” identifiable across all of these new initiatives and these are explored in
the body of this report:
- Trade and Position Reporting – reporting of trades under EMIR and REMIT and also position
reporting under MiFID II
- Clearing - OTC Clearing as mandated under EMIR
- Risk Management – Rules such as Portfolio reconciliation and compression under EMIR as
well as CRD IV rules
- Trade Monitoring and Surveillance – Under REMIT as well as MAD II

The table above summarizes the regulations and the four key themes.
Although linked, each stream requires a different set of process and IT changes. We will be
addressing them separately, with this particular report focused on trade reporting and risk
management.
Advertisement
unified app
emir
remit
mifid II / mifir
mad....
interfacing
seamless upload
etrm/pms
trading platforms
multiple formats
static data
counterparty
agreements
repository
delegation
uti
define rules
generate
consume
update
flexible
mapping
data enrichment
reporting
rollback/resubmit
portfolio
reconciliation
bilateral
third party
as-a-service
Gotenstrasse 13 · 68259 Mannheim · Germany
Tel : +49 (621) 319 55030
Fax : +49 (621) 319 55031
e-Mail : info.eopt@eopt.org
secure
in-house data
audit logging
archive data
features
multi-tenant
fully automated
on-behalf reporting
mismatch details
PriceHub
e·Comply
The Complete Compliance Solution
Reporting Clearing Risk Management Trade
Monitoring
EMIR To Trade
Repositories
To applicable OTC
derivatives for FC
and NFC+
Timely Confirmation
Portfolio,
Reconciliation,
Dispute Resolution,
Portfolio
Compression,
Daily mark to
market (FC, NFC+)
REMIT Power and gas
physical and
financial to RRMs
Fundamental data
to RISs
None
manipulation
rules apply to
physical and
financial gas
and power
MiFID II Real time position
reporting and
limits
various
MAD II Extends MAD

© Commodity Technology Advisory LLC and ETR Advisory Ltd, 2014, All Rights Reserved.
10
EMIR Rules Overview
As outlined above, EMIR is based on the declaration at the G20 Summit in Pittsburgh in 2009. It
entered into force on 16 August 2012. The European Securities Market Authority (ESMA)
implements EMIR, and the local National Compliance Authorities (NCAs), such as the UK FCA,
enforce it. The Regulatory Technical Standards to implement many of the rules were proposed in
December 2012 and subsequently approved by the European parliament in February 2013.
EMIR has four key themes:
Trade Reporting – This requires all derivatives (OTC and Exchange Traded) to be reported to
third party “Trade Repositories” (TR). Both sides of the deal must report the trade using the
same identifier, within T+1. This requirement commenced on 12th
February 2014 for all OTC
derivatives.
Clearing of OTC Derivatives – It is desired that as many OTC derivatives as possible are
cleared via CCPs. This will generally apply to more standardized derivatives. There will also
be new rules about the margin requirements of uncleared derivatives but these are not yet
finalized.
Risk Mitigation – Five sets of rules designed to mitigate risk: Timely Confirmations, Portfolio
Reconciliation, Dispute Resolution, Portfolio Compression, and Daily Mark to Market/Model.
These rules are explained in more detail in the section below.
CCPs (Central Clearing Counterparties) – Rules about the running and funding of CCPs that
are not relevant to the Energy Trading business. However as Energy and Commodity Traders
get pulled into the world of clearing it will be important for all to be familiar with how CCPs
operate.
Different types of party under EMIR
EMIR defines four types of party:
1) Financial Counterparties (FC) such as banks and other financial institutions
2) Non-Financial Counterparties (NFC) – all other EU-based entities. These are divided into:
a. Over the “threshold” (NFC+) - those who trade over a certain amount per year
b. Under the “threshold” (NFC-)
3) Third country – those outside the EU
NFCs must determine their status by using a different threshold number for each asset class as
follows:
Credit - €1bn
Equity - €1bn
Interest Rates - €3bn
FX - €3bn
Commodities €3bn
The numbers above refer to annual gross notional numbers. Only “unhedged” trades are to be
included in this number. Only one of these numbers must be breached in order for the trading entity
to be considered “over the threshold”.

11
It has been obligatory to report being over the threshold since 15th
March 2013. All market
participants are obligated to be calculating their totals on a daily basis, using a 30-day average.
Those under the threshold have a more lenient interpretation of the rules, as will be outlined below.
The way that thresholds have been calculated across the industry seems to vary. Not only have
ESMA issued new advise several time over the last few months, in the form of Questions and
Answers documents, but there appears to still be room for a great deal of interpretation, especially
in commodities and energy. Until clarity is obtained it is expected that there will be a great deal of
confusion in this area.
REMIT Rules Overview
The objective of REMIT is to promote market integrity and transparency in the European gas and
power markets, and it entered into force in December 2011. The EU-level Agency for the
Cooperation of Energy Regulators (ACER) are responsible for implementing the rules with local
National Regulatory Authorities (NRAs) enforcing them by implementing national laws. It applies to
all physical wholesale gas, power, LNG and emission trading in Europe, and derivatives based on
them. REMIT is an EU level “Regulation”, which each country must implement. ACER publishes
“guidance” on how it thinks the rules should be implemented but these are non-binding.
REMIT has two pillars:
Inside Information – From December 2011 it was prohibited to trade using inside information. The
information in scope relates to physical information that could be used to the receiving party's
advantage, such as knowledge of an unplanned outage. If in possession of such information, market
participants may only trade under very limited circumstances. The approach to compliance so far has
been to publish the information as soon as possible usually on a company website (known as the
“REMIT Page”). The information can also be published to transparency platforms managed by
certain parties, such as the National Grid in the UK.
Prohibition of Market Manipulation - Once REMIT is “implemented” by the European parliament, it
will be prohibited to attempt to or actually manipulate the markets. The ACER guidance contains
many details of what comprises market manipulation, divided into: a) false or misleading
transactions, b) price positioning c) transactions involving deception and, d) dissemination of
misleading information.
In addition to prohibiting this activity, REMIT requires that all trade and fundamental data be
reported to ACER 6 months after the rules come in. This gives rise to the second trade-reporting
requirement, which is outlined in the section below.

12
Timings
This diagram summarizes the various timings of EMIR, REMIT and MiFID II:-
15th March 2013 Daily Threshold Calculation
Confirms T+7/5
15th Sept 2013 Portfolio Reconciliation
Dispute Resolution
Compression
12th February 2014 EMIR Trade Reporting
12th
May 2014
EMIR Backloading (Trades after 16th August
2012)
Q3 to Q1 2015 OTC Clearing for FCs
15th September
2014 Remaining EMIR Risk Management
Q2 REMIT “Implemented
Q4 REMIT Reporting (Standard Trades)
Jan 2016 Beginning of MiFID II implementation.
The timetable above shows a summary of the dates as at the time of writing. However, it is worth
noting that many of these dates, particularly for trade reporting, have slipped and some could slip
again.
For example, REMIT was originally to be implemented in June 2013. However this has not yet
occurred at the time of writing. Implementation is now expected in Q2 2014.
Reporting is to start 6 months after implementation. However, this would require that the
infrastructure is ready. We recommend that participants keep a close eye on developments.

13
The EMIR Threshold for Non-Financial Counterparties
Non-financial counterparties that are over the threshold must bear more onerous requirements than
those that are under, as summarized in this chart:
NFC- NFC+-
Trade Reporting All trades to be reported All trades to be reported
including daily market to mark
information and collateral
information
Clearing OTC Clearing not mandatory OTC Clearing Mandatory
Timely Trade Confirmations Currently must confirm within
T+4 going to down T+2 in
August 2014
Currently must confirm within
T+2 going to down T+1 in
August 2014
Portfolio Reconciliation Must reconcile either quarterly
or annually depending on size
of portfolio
Must reconcile daily, weekly or
quarterly depending on size of
portfolio
Portfolio Compression Must compress trades for
portfolios with over 500 trades
Must compress trades for
portfolios with over 500 trades
Daily Mark to market Not required Must mark to market or model
daily.
The requirement to clear, when it comes in, could require a great deal of extra capital from the
market participants, Therefore, many market participants consider it to be desirable to be under the
threshold.
Threshold calculation
Since 15th
March 2013, it has been obligatory for NFCs to calculate their threshold values on a daily
basis using a 30-day average, and to report to the NCA if over.
In order to be considered to be over the threshold, a market participant needs to be over one of the
following:
Credit - €1bn
Equity - €1bn
Interest Rates - €3bn
FX - €3bn
Commodities €3bn
The gross notional value of the balance of each number is taken. There are however, some
important considerations:
Group level calculation – The value to be used is the total for all entities in the group, no
matter where they are. Therefore, a small subsidiary of a large non-EU group could find
itself over the threshold. The participant must calculate each number for each group
member and sum those on a gross basis to see if they are over. If the group company is in a
third country, which is a “recognised regime”, that total may not need to be included.

14
Hedges – Hedged trades do not contribute to the threshold. Hedges under EMIR are defined
as a trade being one of the following:
a) The trade is already defined as a hedge under hedge accounting rules (e.g. IAS 39)
b) It is designed to objectively “reduce risk” of assets, services, inputs, products,
commodities or liabilities that the NFC owns
c) It is designed to reduce the risk of a hedge instrument as defined above
It is important to record the hedge status of each trade to determine if it is a hedge or not.
NCAs are already auditing NFCs that are not over the threshold and so it is important to
record the hedge reason.
What is a derivative? – When calculating the threshold it is important to consider which
trades are considered “derivatives” under EMIR. A derivative under EMIR is in fact defined
under MiFID Annex C.
This definition is not simple but is generally defined as a trade that is settled for cash, but
also as a trade that is transacted via a multilateral trading facility (MTF), which is particularly
important for physical forwards, which could otherwise not be considered thus.
Different execution venues, platforms and brokers may or may not be MTFs, and there is a
current trend for certain platforms to delist themselves from the MTF list. Since the list will
be dynamic, any solution to calculate threshold values will need to be able to cope with such
changes It is also worth noting that many brokers are offering both “MTF” and “Non” MTF
execution paths, with trading gateways often offering routes to brokers via both methods.
There is also confusion over what a “physical” trade is – must it be physically settled, or does
it count if it could be physically settled? The different clauses of MIFID Annex C have different
wordings.
Because of all of this confusion, on February 14th
ESMA wrote to the European Commission
asking for clarification on this topic (as well as FX Forwards). Until then, ESMA have been heard
to say that they will not be enforcing the reporting of physical trades under EMIR.
If an intra-group trade is not a hedge (although it often will be), then both sides of the trade
count towards the threshold i.e. double the notional.

15
Trade Reporting
EMIR and REMIT each have trade reporting requirements: EMIR for OTC and Exchange Traded
Derivatives, and REMIT for physical wholesale gas power, LNG and emissions trades as well as their
derivatives.
EMIR Trade reporting started in February 2014, with REMIT due in Q4 2014.
REMIT specifically has a goal of “avoidance of double reporting” which is intended to remove the
need to send any data twice under both EMIR and REMIT. This is turning out to be difficult in
practice.
In this section, we will first examine the trade reporting requirements of each rule set and then bring
them together.
Trade Reporting for EMIR
What must be reported?
EMIR requires all derivatives trades to be reported, by any party transacting them. This is in contrast
with Dodd Frank in two key ways:
1) Dodd Frank only requires OTC trades to be reported, EMIR requires Exchange Traded deals
(ETD) as well
2) Both sides of the trade must report, using the same Unique Trade Identifier (UTI).
In some cases exchange traded deals can be reported by the exchanges themselves, or by clearing
brokers (for a fee). However, the obligation to report remains with the market participant. Lack of
clarity about this issue, and about which Entity IDs to put into certain fields, led to a request by
ESMA to delay reporting until 2015. However, this was denied by the European Commission. The last
minute introduction of such reporting has led to a great deal of confusion, which has still not been
resolved.
When deciding what a derivative is, careful consideration must be given to the type of instrument
and where it is executed. This is discussed in more detail in the “calculating the threshold “section.
Where data should be reported?
EMIR trade data must be reported to a registered “Trade Repository” (TR), a third party who will
make the data available to ESMA runs a trade repository. Several entities are approved as TRs at the
time of writing and most are detailed in the services catalogue at the end of this report.
When reporting, market participants can either send data straight to TRs, get someone else to do it
on their behalf, or send the data via “Reporting Services”. All of these options are considered in the
services directory at the end of this report.
Which data must be reported?
Detailed data differs per asset class. However, the data can be divided into the following categories:
Entity Identification – Of the parties involved in the trade. Will include the reporting entity,
counterparty and others such as the beneficiary (if not the counterparty) broker etc.
Contract Information - Information about the deal and contract, including where it was
executed. UPIs preferred. Could require a complex product type derivation.
Transaction Information – Trade level details such as quantity, notional etc., requires the
Unique Trade Identifier.

16
Trade Type Specific Information - Different sets of fields for IR, FX, and Commodity etc.
Commodity profiles are multi record.
Option Information - Strike, call or put, etc.
Confirm Information – About the trade confirmation.
Clearing Information – Including the Clearer ID and time of clearing.
Status – “New/modify/cancel/termination/compression/valuation update/other.” – Each
time a trade changes it must be resent with a new status.
In addition to the above, FCs and NFC+s must report collateral and valuation information on a daily
basis. However, this reporting will only start 6-months after the initial reporting i.e. on 12th
August
2014.
Some details of this data are examined in the “realities of implementation” section below.
When should data be reported?
Data typically should be reported to a repository by the end of the next working day. This includes
when some of the data, such as the confirmation data, is missing. It should be sent later in an
update. Trades executed after 4pm count as the next day’s trades in terms of measuring T+1.
Backloading
EMIR came into force on 16th
August 2012. This means that any data on trades in existence then
must also be reported or “backloaded” to repositories. By implication, it is important to locate this
data as soon as possible.
Backloading is required in several stages:
Trades still open on the first reporting date (i.e. February 12th
2014) executed after 16th
August, 2012 – upon go live (12th
February 2014)
Trades still open on the first reporting date (i.e. February 12th
2014) executed before 16th
August, 2012 – 3 months later (i.e. May 12th
2014) - although most backloaded these on
go live
Trades executed after August 16th
2012 but that matured before the first reporting date- 3
years after reporting date
Trade executed before August 16th
2012 but that were still open on 16th
August 2012 – 3
years after reporting.
Trade Reporting for REMIT
Which data must be reported?
REMIT reporting falls into the following two categories at the highest level:
Trade Data – Data related to trades and orders
Fundamental Data – Data related to the physical state of the grid, e.g. outages, loads, etc.
Here we focus on trade data.
REMIT covers Physical Power, Gas, LNG and Emissions, as well as their related derivatives.
Technically, therefore some of the derivatives will fall under both REMIT and EMIR. However, ACER
has put forth a principle of the “avoidance of double reporting”. In theory, this means that if you
report data under EMIR you do not have to report it again under REMIT. However, since REMIT

17
requires additional data elements to EMIR, it is not yet clear how and if this will work in practice.
Each version of the draft implementing Act has seen a different approach proposed and so the
market will need to wait for a final version in order to work out how to address this.
Where should data be reported?
ACER will be collecting all of the reported data and using it to monitor the market for abuse. A
system called “ARIS” (ACER’s Regulatory Information System) is being built for this purpose.
Because of the large number of market participants, ACER do not wish for data to be sent to them
directly, instead, they need to be sent via intermediaries called “Registered Reporting Mechanisms
(RRMs). These third party facilities will each have their own way of collecting the data and
forwarding it to ACER.
An EMIR TR could also be an RRM, or it may not be one. An RRM that is not a TR could forward the
data to the TR as well, or they may not. This is discussed in the “Data Destinations” section.
What data types must be reported?
REMIT requires pre trade data, i.e. order information, to be reported as well as trade data through
the lifecycle. The order information includes orders for unexecuted deals.
REMIT defines four “Data Views” which different data elements required within each view. These
are:
- Order view – Elements required to be sent when an order record is sent
- Execution view – Elements required to be sent when a trade is executed
- Confirmation/Clearing – Elements required to be sent when a trade is confirmed and/or
cleared
- Non Standard View – Elements required for a complex “nonstandard” trade (see below)

18
The data elements can be summarized by this table:
Order Execution Clearing
/Confirm
Non
Standard
Identification Of the various parties, including
broker etc. Likely to require LEIs.
Includes market place ID
P x x x
Contract Info about the deal and contract,
including where it was executed.
UPIs preferred, Could require a
complex taxonomy
p x x
Order Order Type (Market, Limit etc.,) x
Transaction Trade level details such as quantity,
notional etc. + UTI
p x x p+ PDF
Trade type
specific info
Different sets of fields for IR, FX, and
Commodity etc. For commodity
profiles are multi record. Includes
physical data
x x
Option Info Strike etc. x x
Confirm Info When confirmed, details to be filled
in
Clearing Info When confirmed, details to be filled
in
x
Status New/Split/Modify/Cancel/
Terminate/Other
x x x x
The full field list is found in the document on the ACER website at
http://www.acer.europa.eu/remit/Documents/Recommendations%20on%20REMIT%20Records%20
of%20transactions.pdf

19
Non Standard Trades
For trades that are considered “complex”, it is only necessary to send a subset of 23 data elements.
In addition, there is a requirement to send a PDF scan of the contract to ACER. Details about how
this will work, and also about which trades are defined as non-standard are not yet known.
Data Destinations
Ultimately, EMIR data must reach a Trade Repository, and REMIT data must reach an RRM. However,
there are several different combinations and services available:
1) TR Only – Some EMIR TRs will only accept EMIR data. If choosing one of these, it will also be
necessary to send data to an RRM separately
2) RRM Only – Similarly some RRMs will only accept REMIT data
3) TRs that are also RRMs – some TRs have committed to becoming RRMs
4) RRMs that forward to TRs – some prospective RRMs will accept all data and forward the data
to an EMIR RRM
5) Reporting services – Some third party services are planned that will take in all of the data
and report it to both TRs and RRMs
Advertisement

20

21
Implementing a trade reporting solution
Solution types
Every market participant is required to implement a trade reporting solution in some form. This may
be very simple, for example uploading a trade spreadsheet to a repository, or it may require a large
amount of engineering, for example for a multi-site market participant with several ETRMs. It is also
possible to delegate the reporting to another party, or several parties.
There are several different types of configuration available, which can be summarized by these
levels:
Level Key features Pros and cons Typical
participant type
Delegated Another party reports on the market
participant’s behalf, This can either
be as a specialized service or in some
cases for a set of deals, for example,
an exchange reporting all trades
executed there, or pre trades for
REMIT.
+ Less work for participant
+ Less prone to error
-No audit log for
participant
- Could be expensive.
- Participant is still liable
for errors
Small traders, or
as a partial
solution for any
type
Manual A manual spreadsheet/csv upload to
a repository or reporting service.
Some repositories will offer on
screen trade entry.
+Easy to use for smaller
traders
+Good way to send trades
already in spreadsheets
even for larger players
-Lack of auditability
-Prone to error
Small participant
with few trades
or as a partial
solution for larger
participants
Outsourced Duty of reporting outsourced to
another party. The party will either
have the most of data already, or
provide a simple mechanism to take
the data The provider will perform
some tasks such as data enrichment.
+Less work for participant
+ Less prone to error
- No audit log for
participant
- Could be expensive.
- Participant is still liable
for errors
Smaller traders
that already
execute most of
their trades
outside of their
own
environment.
Direct Sending the data directly to a
repository. RRM and/or a reporting
service.
+ More control
+ Lower running cost
- Could require a large
project to set up
- Requires in house
expertise
Medium and
larger
participants
It is also possible to use a combination of these methods. For example, exchange traded deals could
be sent by an exchange, and OTC ones via another route.

22
Required Solution Activities
While this document is not intended to be a comprehensive guide to building a reporting solution,
here we identify some key tasks that the majority of participants will need to undertake to have a
working solution:
Data sourcing and gap analysis
Before data can be provided to any destination, it must be sourced from somewhere, be it the
E/CTRM(s), trading platform or spreadsheet.
It is important to perform a data gap analysis as early as possible to ensure that you have all of the
required data from each product type traded. This will involve going through each product type
traded, and for each field required (under EMIR or REMIT) ensuring that you know here it can be
found. It is not sufficient to simply map to the source field in an E/CTRM, It is also necessary to
ensure that the business process in place updates this field.
Data mapping and capture
There must be a mechanism in place that can rapidly identify all qualifying trades (new, modified,
voided etc.), extract the required data items for reporting purposes from possibly multiple systems,
and format the data appropriately for transmission to the trade repositories. Furthermore, the data
must be validated for missing items, correct formats and codes, and corrections must be made
manually or automatically prior to transmission.
Whatever systems are in use to capture and process trades including vendor provided, home grown
or even spreadsheet-based solutions, they must contain all of the required data items that are to be
reported. Furthermore, there must be processes in place to ensure the capture these data items for
reporting purposes.
Configuration choice and connection mechanism
It will be necessary to select the “shape” of configuration choice. It is possible to select several
configurations; for example, a large participant could report most OTC and physical trades directly,
but chose to use the exchange’s facilities to report ETD, and to upload some rarely traded physical
deals manually.
If not outsourcing completely and building an internal solution, it will also be necessary to select a
connection mechanism. This could involve either building one internally, or purchasing reporting
software that has adapters built in. The incumbent E/CTRM system may also have built in adapters
to one or more destinations.
Data enrichment
The various reporting destinations require entities and product to use standard identifiers, such as
LEIs, EICs, UPIs, and ISINs etc. There are several entity records for most deal types, and each requires
different product information. In addition, some other information, such as “Counterparty status”
flags are required.
As a result, each trade must be “enriched” with appropriate standard data. The difficulty of this task
varies by number of trades, trade types and source system.
Reporting software will usually offer a solution to the issue, which will be particularly useful to those
with multiple E/CTRMs. In addition, many of the outsourced services offer a partial solution.
Pre trade data
REMIT requires that pre trade information such as order information be forwarded to ACER. The
arrangements for this forwarding are not yet clear. However, it is likely that execution venues will
provide facilities (at a cost) for delivery of such data. Participants should monitor market
developments to see how this will be handled. We will also be covering it in a later report.

23
Issues being encountered
This section outlines some issues being encountered in the market by those implementing trade
reporting solutions. Updates will be issued regularly.
LEIs (Legal Entity Identifiers)
An LEI is a globally unique identifier for counterparty. The LEI initiative also arose from G20 desires
after the banking crisis, to create a globally uniform mechanism to identify an entity in a transaction.
This eventually led to the Financial Stability Board (FSB) issuing a paper and outline for how such a
database could be constructed and governed. The global database is not yet ready, but a “pre LEI”
database is being formed, and others already exists in the absence of a final global version.
EMIR will require the use of LEIs, or pre LEIs upon go live, although they have not yet been defined
for all entities.
Market participants will need to:
- Add facilities in place to map their existing entity Ids to LEIs
- Add facilities so that it is possible to store an LEI for each entity going forward.
It is interesting to note that there was a distinct lack of LEI registrations on Feb 12th, with a surge of
registrations occurring later. Clearly the LEI rollout is not yet complete.
The UTI (Unique Trade Identifier)
Trades sent to EMIR repositories need to contain a 52 character UTI. Under EMIR, both sides of the
trade must send in a deal with the same UTI. The generation of this ID and the workflow around are
leading to a great deal of uncertainty at the time of writing. In particular:
Generation of the UTI – There is no mandatory mechanism for the generation of the UTI, which has
been left by ESMA to “the industry”. An ISDA working group is currently attempting to provide for a
recommended solution although this is not yet final or accepted by all in industry.
The commonly accepted approach depends on whether the trade is executed on a platform or not. If
it is, then the platform should generate the ID for both parties.
For bilateral trades, the consensus is that the seller should generate the ID and provide it to the
buyer. However until this is agreed, the resolution is as yet unknown.
Workflow around the UTI – However the UTI is generated, it needs to somehow make it into one or
both party’s ETRM systems, and be sent to a repository.
If the trade is executed on a trading platform, it will be necessary to extend the interface between
the platform and the ETRM to capture the UTI before the trade is sent to ESMA.
For bilateral trades, the capture of the ID is harder: the generating party must find a way of
providing it to the other side, and this will need to be electronic since manual entry of a 52 character
code is not an option. It is worth noting the triOptima, EFETNet and Trayport all have useful UTI
generation tools.
The obvious place for the code to come in is on the trade confirmation. However, that may not
arrive until after the trade must be reported to ESMA.
In an update to the Questions and Answers on EMIR, that was issued by ESMA the night before go
live, some new guidance was given on the format of UTIs. However this format is also not
mandatory.
The solution to the issue will need to evolve over the next months.

24
Which rules apply to a trade?
It is important to have a granular and flexible mechanism to ensure that trades get “routed” to the
correct place under the right rules.
Firstly, the definition of a derivative under EMIR is not always straightforward and subject to change.
The rules as outlined in the “threshold calculation” section require:
- A “hedge marker” to be placed on all trades in the source system. In some cases, a rule could
be used to derive this, for example if all hedges are in specific portfolios. In other cases, they
will need to be marked manually.
- It is import to have mechanism in place that can deduce whether a trade has been executed
on an MTF. The list of MTFs keeps changing, and this must be factored into the solution
Furthermore for some trades executed via brokers it may be difficult to determine the place
of execution in the first place. Expect the recent FCA ruling to be modified as well.
Similarly, with REMIT, it will be necessary to have a flexible mechanism in place in order to
determine which trades to cover.
Changing requirements
As market participants get closer to go live and further into their projects, more detailed issues are
emerging. At the same time, messages from regulators repositories and others give rise to changes
and intricacies.
It is important to keep a close eye on developments. This can be accomplished over various forums
including the website www.enegrytradingregulation.com and via updates to this report through
time.
Advertisement

25
Risk Management
EMIR specifies five different measures that must be adopted by market participants:
Timely confirmations – All trades must be confirmed (matched) within a certain timeframe
Portfolio reconciliation- Uncleared bilateral trades must be reconciled between each set of
parties at pre-defined intervals
Dispute resolution – Dispute resolution procedures to be put in place for trades in dispute
for more than 5 days
Portfolio Compression – Certain parties must perform mandatory compression on OTC deals
Daily mark to market/model – Trades to be marked to market or model by certain parties.
The requirement and timeline can be summarised by this chart:
Rule Summary FC NFC+ NFC- Timing
Timely
Confirmation
Bilateral Trades
to be confirmed
(and matched)
within the given
timetable.
T+1 T+2 Requirement for T+7/5
came in on 15th
March
2013. Window narrows
every few months until
August 2014 when the
timings shown here will
be required.
Portfolio
Reconciliation
Uncleared trades
to be matched
periodically
between
counterparties.
Daily for portfolios
greater than 500
trades.
Weekly for portfolios
with between 51 and
499 trades.
Quarterly otherwise.
Quarterly for
portfolios of
more than 100
trades.
Annually
otherwise.
Starts on15th
September
2013.
Dispute
Resolution
All to have
processes in place
to identify, track
and monitor
disputes. Formal
procedure if more
than 5 days.
Report
all
disputes
over 15
days
and
15M
EUR
Procedures must be in place. Starts on15th
September
2013.
Portfolio
Compression
OTC trades to be
“compressed”
periodically.
Twice a year for portfolios with more
than 500 trades.
Starts on15th
September
2013.
Daily mark to
market/model
All trades to be
either marked to
market or model
on a daily basis.
All trades that are
sufficiently liquid to be
marked to market
daily and the values
sent as part of trade
reporting. Otherwise
they must be marked
to model and values
sent.
Not required.

26
Timely confirmation
The timely confirmation requirement of EMIR is intended to reduce risk and encourage a move to
electronic confirmations.
The confirmation deadline refers to the time the trade is confirmed as matched, rather than when it
is sent.
Portfolio Reconciliation and Dispute Resolution
EMIR requires that counterparties reconcile their portfolios of uncleared trades from 15th
September
2013 onwards, as follows:
FC and NFC+:
More than 500 trades: Daily
Between 50 and 499 trades: Weekly
49 or less: Quarterly
NFC-:
More than 100 trades: Quarterly
Less than 100 trades: Annually.
Where an NFC- is the counterparty of an NFC+ or FC, the NFC- timings apply.
Generally, for those with many reconciliations to perform, there is a good case for automation, if it
does not already exist. There is clearly far less work to perform for an NFC-, which reduces that case
and will give rise to the reconciliations being performed manually.
However, NFC-‘s are advised to calculate exactly how long this will take. A medium sized utility with
20 counterparties with over 100 trades will still need to do 20 of these per quarter, i.e. one every 3
working days, and also have the overhead of the annual reconciliations, which may be numerous.
Consideration should therefore be given to at least a “semi-automatic” solution.
The reconciliation process
In order to reconcile trades, the two parties must exchange the position each thinks it has with the
other. In order to do this each party must provide data to the other so that it will be “matched”.
(Usually via a file). The file will contain a pre agreed set of fields, known as the “key terms” that can
be used to identify a specific trade. In addition, fields such as price and notional and sometimes
mark to market will be sent.
The parties then take each file and compare them using the key terms. Those where the key terms
and positions are the same are declared a “match”. If there is no match or a large difference in views
are marked in dispute. In reality, not all fields will always match, and so the parties declare a
“tolerance” for the key terms.
Those that are in dispute then are checked and if that cannot be resolved, the dispute resolution
procedure commences. There are various ways in which this may happen:
Typical modes of operation
In general, there are three usual modes of operation:
Bilateral – where counterparties exchange files (either one or both ways).
Third Party Service provider – Where a third party is involved in the reconciliation, to
organise it as a central service.
Agent – Where another party performs the reconciliation on the counterparty’s behalf.

27
Bilateral reconciliation
Before reconciliation starts, counterparties will need to establish procedures/systems to monitor
how often they must reconcile with each entity. This may vary over time.
Once established, a reconciliation schedule needs to be agreed with the other party (except for daily
reconciliation).
On the day of the reconciliation, the parties exchange data files. In some cases, only one party sends
the file for the other to check. The fields contain the data in the key terms as well as position data.
They then run matching processes, using the key terms and tolerances. If there are “breaks”, the
parties communicate and fix them, or if necessary initiate the dispute resolution procedure.
The matching itself can be performed by specialist software, or using a spreadsheet. Spreadsheets
can be complex in this area, although the introduction of the UTI will make this task easier.
The benefit of the bilateral approach is that it is simple to use, especially for those with a small
number of reconciliations to perform
The drawback is that any counterparty with more than a handful of reconciliations to perform will
need to send a large number of files to different counterparties on the correct dates. This can
become logistically complex and lead to operational risk, and the wrong fields being sent to the
wrong places, risking a breach of confidentiality.
Third Party Service Provider
An alternative of bilateral reconciliation is to use a third party to assist in the process. –Using this
method a third party service such as the triResolve service provided by TriOptima is used centrally to
organise reconciliation. They do not however, perform the reconciliation from a legal perspective.
They simply organise the process and make it easier than a bilateral reconciliation.
When using the service provider model, each subscriber sends a file on a regular basis to the service
provider, containing data regarding other subscribers.
The service then calculates how often reconciliation is necessary and performs the appropriate
scheduling. It then performs the matches and informs the subscribers of any disputes, after
following a prescribed process.
There are several benefits to this approach: Firstly, only one set of data needs to be sent for all of
the subscribing counterparties. This greatly reduces operational risk and the logistical overhead.
The second benefit is that the service will provide scheduling services on behalf of the client. This
removes the scheduling overhead of the bilateral approach. A service provider will be able to
optimise the schedule whilst taking into consideration all of the subscribers simultaneously.
Agent
Using this paradigm a third party performs the reconciliation on the participant’s behalf. The entire
process is outsourced to another party, who perform the reconciliation on their behalf. They will be
given the portfolio to reconcile and advise of disputes if they arise and cannot be resolved by the
agent themselves.
Contractual Changes required for Portfolio Reconciliation and dispute resolution
Market participants are required to amend their ISDA and other contracts in order to accommodate
these changes, the contract should encompass the new protocols that permit information sharing
for the appropriate key terms in order to reconcile, as well as requiring the reconciliation to take
place.
See the ISDA website for more details.

28
Portfolio Compression
Portfolio Compression is the process of reducing the number of trades in a portfolio whilst
maintaining a risk equivalent position.
Reducing “unnecessary” trades with a counterparty reduces credit risk and settlement risk.
EMIR mandates compression for FCs and NFC’s every six months for counterparty portfolios with
more than 500 trades. EMIR also “encourages” compression wherever possible.
Compression is not always easy or desired by all in an organisation, although it is desired by the
credit department and has many benefits once in place in terms of risk management.
Compression can be performed either bilaterally or multilaterally.
Bilateral Compression
When one counterparty attempts compression directly with another, there are several steps:
1- Identify counterparties – It is necessary firstly to identify which counterparties are being
compressed with and when to schedule them for.
2- Identify areas for compression – An analysis of the portfolio must be carried out in order to
determine which trades may be compressed, if any.
3- Agreement of compression – the two entities must then agree the set of trades
4- Execute compression – execution of a compression involves terminating the deals being
compressed, and replacing them with new ones.
5- Mark trades- The new trades must be marked as “resulting from compression” in EMIR trade
reporting. The ETRM system will need to record this as a reason for the trade.
Multilateral Compression
Compression involving several parties can be a great deal more effective than bilateral compression.
Multilateral compression involves viewing the trades between all of the counterparties in a group,
and then reducing them down as much as possible using a combination of trades and closures. The
more parties involved in a compression, the more benefit it will have.
TriOptima‘s triReduce service offers such a service, both within the energy industry and within
banking.
Multilateral compression involves the following steps;
1- Set calendar – multilateral compressions take place periodically (typically quarterly
depending on market characteristics).
2- Send in trade portfolio – each party sends in candidate trades with the other entities in the
group to the service. Nominate trades – each party agrees to the compressions from the
suggestion list
3- Dress rehearsal – on a specific day, the compression is “simulated” by all parties
4- Execution – On a nominated day, all of the agreed trades are closed out and new ones
created. Service suggests trades – the service will suggest which trades can be compressed,
which trades will need to be closed out and which new ones created
A typical cycle lasts two weeks, with trade submission and matching in the first week, and dress
rehearsal and live execution in the second week.
As with bilateral compression, all trades resulting from a compression must be marked and reported.

29
Is it worth compressing if it is not mandatory?
As outlined above there are many benefits to compression, in particular credit risk reduction. One
other benefit that applies in particular to non-financial counterparties, is the reduction in total Gross
Notional Value. By compressing enough trades, an NFC- may be taking them further away from the
threshold, which could be considered a great advantage. Other benefits include:
o Capital cost: With the Basel III leverage ratios it is quite beneficial to reduce gross
notional
o Balance sheet: Compression also reduces gross mark-to-market, which under IFRS
accounting will decrease your balance sheet
o Operational costs and risks: Compression leads to fewer trades that needs to be
processed through its lifecycle, i.e. fewer lifecycle events like scheduling,
settlements, payments, etc. to process, where each step has a cost and risk
associated
Daily mark to market/model
All FCs and NFC+s are required to mark all trades to market daily. If this is not possible then trades
must be marked to an approved model.
It is also necessary to report these valuations daily, as part of trade reporting, six months after the
initial reporting date.

30
European Regulatory Solutions Directory
We have made an effort to identify a variety of possible solutions for the European Regulatory
environment and assembled this directory. This is most certainly not the total picture and we will add
to it through time to try to keep it up to date. Please note that the product descriptions are often
lightly edited versions of the vendor’s web content associated with the product and we are not
responsible for any errors in this content. Please also see the CTRMCenter software directory at
http://www.ctrmcenter.com.
Types of service and software
There are a variety of services and software that can be considered when implementing trade-
reporting solutions:
Trade Repositories – Trade Repositories that have applied under EMIR.
Reporting Services – Third party services to which data can be reported and sent on to a TR
or RRM. In most cases these will be acting as RRMs
Specialist Reporting and aggregation software – Software specifically designed to take in
data from one or more sources including ETRMs and reference data systems and send it to
one or more Trade Repositories and /or reporting services
ETRM offerings – Adapters from ETRM vendors that link their systems (only) to one or more
destinations.
Exchange Offerings – Exchanges offering to report information about deals executed there.
Trade Repositories
A number of organizations applied to ESMA for registration as Trade Repositories including;
the CME Group,
the London Stock Exchange,
Intercontinental Exchange (ICE) Trade Vault,
REGIS-TR,
LSE Unavista
The Independent Data Repository,
KDPW-TR and,
The Depository Trust and Clearing Corporation (DTCC).
Those in bold have so far been approved by ESMA.
It is interesting to note the provenance of several of these applicants as some already act as Swap
Data Repositories in the USA and others as approved reporting mechanisms under MiFID. All of
these entities plainly have some degree of experience in collecting and storing trade data.
In the USA, Swap data repositories (“SDRs”) were new entities created by the Dodd-Frank Wall
Street Reform and Consumer Protection Act (“Dodd-Frank Act”) in order to provide a central facility
for swap data reporting and recordkeeping. Some seven entities applied to become SDRs but two
applications were later withdrawn and a third does not cover commodities as an asset class. The
four remaining include BSDR LLC, CME, DTCC and ICE where BSDR LLC is a new entity specifically

31
created for the purposes of becoming an SDR. CME, DTCC and ICE are all applying for registration
under EMIR too.
LSE has some experience as regional trade repositories for MiFID. Only REGIS –TR and the
Independent Trade Repository Ltd. have no real prior track record having been specifically set up for
EMIR, although with a test system having been live already for several months; REGIS TR is proving
to be popular. KDPW-TR is the central securities depository of Poland and has some experience of
working with large amounts of trade data as a result.
CME Group
The CME's Swap Data Repository Service already provides public data on swap transactions and
stores confidential trade and position data for regulatory purposes, in accordance with the Dodd-
Frank Act. The CFTC approved its repository service as a swap data repository (SDR) for credit default
swaps, interest rate swaps, commodities and foreign exchange asset classes.
CME Europe's cross-asset trade repository solution is to launch on 1st
January 2014 in line with the
first reporting requirements, In addition to operating for CME's global clearing and execution
facilities, it will accept non-cleared bilateral OTC and exchange trades executed anywhere in the
market.
The CME Repository Service leverages the CME ClearPort front-end, a gateway to CME reporting and
clearing post-trade services. This common point of connectivity offers messaging efficiency and
lower maintenance costs.
LSE
The London Stock Exchange Group also has applied to ESMA for its UnaVista platform to be a trade
repository across all asset classes for both exchange traded derivatives and OTC derivatives.
UnaVista currently operates as a European Approved Reporting Mechanism (ARM) under the MiFID
regime for all asset classes and markets. LSE believes that by becoming a trade repository for all
asset classes across all venues, its customers will only need to connect once to meet both their EMIR
and MiFID reporting requirements.
As a MiFID Approved Reporting Mechanism (ARM), UnaVista already reports c1 billion multi-asset
transactions annually to multiple regulators, including over 300 million derivatives on behalf over
600 clients. As a hosted central utility, UnaVista will utilize its inbuilt reconciliation engine to
facilitate the ESMA requirement for contract details to be reconciled before reporting to the various
different trade repositories
ICE
ICE has decided to establish ICE Trade Vault Europe Limited (ICE Trade Vault Europe) as a Trade
Repository (TR) for the reporting of derivatives trade data to meet requirements of the European
Market Infrastructure Regulation (EMIR). It plans to serve the commodities, credit, interest rate and
foreign exchange asset classes.
In June 2012, ICE Trade Vault, LLC (ICE Trade Vault US) became the first Swap Data Repository (SDR)
in the U.S. to receive provisional regulatory approval from the CFTC and the Vault began accepting
credit default swaps trade data in October 2012 followed by commodities trade data in February
2013. Since its inception, ICE Trade Vault US has already accepted around fifteen million trades.
Since ICE provides direct access to the core energy and commodity market infrastructure, it believes
itself to be a qualified trade repository for those markets. Through the ICE trading platform and
clearing houses, as well as ICE eConfirm, ICE sees an opportunity to simplify workflows and trade

32
data reporting requirements for market participants, helping its customers achieve efficient and
cost-effective compliance with evolving regulations.
Utilizes ICE eConfirm as the front-end application for counterparties to submit data to ICE
Trade Vault, thereby enabling market participants to use their long-established connectivity
solutions with fewest modifications possible
Distributes real-time trade data to market participants and provides historical data for online
viewing and access. Participants will control permissions for regulatory reporting purposes
as well
Features a high-performance, scalable data warehouse and reporting platform
ICE is likely to also act as an RRM.
REGIS-TR
REGIS-TR is a European trade repository created as a joint venture by Clearstream Banking S.A.
(Deutsche Börse Group) and Iberclear (Bolsas y Mercardos Españoles). Its services have been
operating live since 2010. Derivatives based on interest rates, foreign exchange, commodities and
equities are currently eligible for registration at REGIS-TR, which will enable full compliance with
EMIR for all asset classes and listed derivatives before the reporting obligation comes into places.
Key characteristics of REGIS-TR are as follows;
European provider, fully compliant with EMIR, with a Financial Market Infrastructure (FMI)
license
Co-owned by two neutral securities services infrastructures, providing services from
Luxembourg, holding data exclusively in the EU
One-stop-shop for the registration of all types of derivatives on all asset classes
Flexible access for all types of counterparties (financial and non-financial entities)
Competitive price list allowing full price transparency and predictability. Fee caps for all
users
Commitment to be a REMIT RRM
Flexible trade delivery mechanism spanning simple upload of csv files to a web services
based XML sending mechanism.
REGIS-TR will enable full compliance with EMIR’s derivatives reporting requirements. However, it
also allow customers to meet their obligations for transaction reporting under the Markets in
Financial Instruments Directive (MiFID), the Regulation on Energy Market Integrity and Transparency
(REMIT) and repo agreements and securities lending reporting under the Capital Requirements
Directive (CRD IV).
In addition to its statutory trade repository activities, REGIS-TR may also offer its clients extra
services such as electronic matching and confirmation services, independent valuation services and
exposure management.
REGIS-TR and TriOptima have also recently announced that they will provide portfolio reconciliation of
REGIS-TR’s trade repository data with data in TriOptima’s triResolve reconciliation service for OTC
derivatives as requested by their clients.

33
The Independent Trade Repository
CapitalTrack, a vendor of a data transfer database and network, Capital Market Daily Portal, a data
network, technology and services vendor, and Fincore, a software vendor, have established a new
company, Trade Repository, and hope to win ESMA approval for its Independent Trade Repository
product.
The Independent Trade Repository will allow users to submit the details of their trades on
spreadsheets to its online database. The Independent Trade Repository believes that it will be
particularly attractive to market participants because it is not affiliated to a clearinghouse and
because the companies operating it have an expertise in data management.
DTCC
DTCC’s Global Trade Repository (GTR) Service provides full coverage of all cleared and uncleared OTC
derivatives products within each major asset class. Trade submissions will be supported for 100% of
products traded in each asset class regardless of whether trade is electronically processed or
bespoke – paper confirmed.
A customer of a Repository may selectively elect to enable reporting for one or more
jurisdiction/regulation that is supported by that Repository. For example, a member of the DDRL
legal entity may elect to report to any combination of ODRF, HKMA, CSA, and ESMA.
The above TR entities can also be registered as foreign TR in other jurisdictions, e.g. Canada and
Australia.
The GTR service supports a multitude of data submissions including real-time price reporting,
transaction details, confirmation records, and valuation data.
The GTR service provides open access to third-party providers to promote efficient reporting
processes – this includes:
Electronic Execution Platforms
Confirmation Providers
Clearing Houses (CCPs)
Inter-dealer brokers
Custodians
Any other middleware providers
The GTR is brought to the energy industry by EFETNet who have partnered with DTCC in the US and
will offering forwarding of trades under EMIR to the repository via the eRR service.

34
KDPW-TR
On 2 November, the Central Securities Depository of Poland (KDPW) launched the trade repository
service (KDPW_TR) in response to Regulation No. 648/2012 of the European Parliament and of the
Council of 4 July 2012 on OTC derivatives, central counterparties and trade repositories (“EMIR”).
According to Article 48.5a of the Act on Trading in Financial Instruments of 29 July 2005 as amended
by adding provisions concerning novation, the Central Securities Depository of Poland (KDPW) may –
under the rules set out in separate rules – collect and store information concerning trade in financial
instruments and information concerning such instruments. The detailed operating rules of KDPW_TR
are set out in the Trade Repository Rules.

35
Reporting Services
NASDAQ OMV
NASDAQ OMX already provides a service for Nordic Market Participants for MiFID trade reporting
(TRS) to local Financial Supervisory Authorities (FSA) and will extend this reporting service to cover
EMIR derivative reporting to Trade Repositories.
It offers its members reporting services regarding:
Establishing connectivity with relevant Trade Repositories
Reporting of derivatives contracts traded and cleared on NASDAQ OMX’s markets
Reporting of OTC derivatives transactions that are not traded or cleared by NASDAQ OMX
Ability for members to append required data to derivatives transactions for reporting
Daily updates to the Trade Repository of collateral and mark-to-market valuations
Reporting feedback of submitted reports
NASDAQ OMX further aims to extend its service to include reporting obligations under REMIT for the
energy market.
It provides the option of full service reporting of all required data and a complimentary reporting
service where NASDAQ OMX and the Customer jointly complete the reports.
For derivatives cleared with NASDAQ OMX where the Market Participant keeps position-segregated
accounts per beneficial owner, NASDAQ OMX can complete the Trade Repository report with all
required data without the need for interaction from the Customer. For Customers with a setup
where NASDAQ OMX does not have access to all required data or where the Customer selects to
submit its own reports to a Trade Repository but need NASDAQ OMX to complement their reports
with some data, it will offer a partial reporting service according to the alternatives described below:
For Customers that connects to a Trade Repository themselves for reporting, NASDAQ OMX
will duplicate the missing data at the Trade Repository to the report created by the
Customer.
Alternatively, the Customer can complete partial reports created by NASDAQ OMX and
submit the reports to the Trade Repository through NASDAQ OMX. This option does not
require direct connectivity to a Trade Repository for the Customer.
OTC derivatives transactions that are not traded or cleared by NASDAQ OMX may also be
submitted via the service interface. This option, also, does not require direct connectivity to
a Trade Repository for the Customer.
The service is provided with a flexible interface where the Customer can select to interact with the
service via a provided application or by uploading fixed formatted files.
The Trade Repository application is a desktop application that enables the Customer to perform the
following activities:
View status of submitted reports
View status of individual reported transactions
Search for historical reports

36
Review and confirm NASDAQ OMX generated reports
Complement partial NASDAQ OMX generated reports with additional data before
submission
Create new transactions for reporting
Export data to external systems
Vendor – Nasdaq OM
http://www.nasdaqomx.com/europeanclearing/traderepositoryservices/
EFETnet eRR
EFETnet’s electronic Regulatory Reporting (eRR), is an industry wide solution to an industry
wide problem; implementation of regulatory reporting requirements is having a significant
impact on the wholesale European energy market. Operational processess and systems are
under pressure because of the changing regulation and investments in IT are inevitable to
comply with all regulatory reporting obligations. EFETnet developed eRR, a single
standardized interface for regulatory reporting, delivering reporting compliance for REMIT,
EMIR, MIFID, CRD IV etc. eRR operates through a single open industry standard interface
providing connectivity to the different regulatory repositories.
eRR will be offered as an add on to EFETNet ‘s confirmation matching service, which is
already used widely in the industry. Trade information will be sent using the same protocol
and format and for confirmation matching. Trade information will only need to be sent once
for both confirmation and regulatory reporting.
EFETNet uses the CpML format to represent trades. In order to encourage that use of this
format as a standard, its management is now being given to an independent body run by
EFET and the CIO Council. This will permit other vendors to use CpML in order to encourage
interoperability. The initiative to carry this out has already begun.
Vendor – EFETnet
http://www.efetnet.org
TrayPort Complete
Trayport Complete is designed to reduce the operational costs and delays associated with
trading energy commodities. The Complete suite of real-time solutions will provide market
participants with transparency and control over their post-trade activity. With Complete,
users will be able to accurately manage and monitor their post-trade workflows across the
160+ markets accessible through Trayport's platform immediately following the trade.
Complete will be seamlessly integrated with existing Trayport products and will enable users
to:

37
Clear – Users can see the status of trades in real-time across all clearing houses and
counterparties on the Trayport network through one screen. Complete Clear is live
and available for CME ClearPort, LCH, MEFF, NOS and SGX. Connectivity to European
Commodity Clearing AG (ECC) and OMIClear will be announced in the coming weeks
Confirm – Users will be able to confirm standardized terms of a trade immediately
post execution with up to 400 counterparties and 17 brokers on the Trayport
network. Complete Confirm will enable users to define their own confirmation
processes and workflows to meet their internal requirements. This will improve
efficiency, optimize workflows and reduce operational risk and the processing costs
associated with energy trading.
Report – Users will be able to report as close to real time as they choose to
European regulatory authorities and trade repositories. Complete Report will be
designed to satisfy REMIT and EMIR regulatory reporting obligations at the point of
execution. Further reporting obligations and jurisdictions will be added in the future.
Control – With Complete Control, users will be able to manage post-trade execution
with transparency and control. The real-time monitoring application will allow all
counterparties to the trade to track the progress of their trade and immediately
identify and resolve any questionable trades at the point of execution, significantly
reducing operating risk and cost.
Vendor – Trayport
http://www.trayport.com
Specialist Reporting and aggregation software
BroadPeak - K3
BroadPeak is an integration/ETL software firm. Its flagship product, K3, is a low latency, fully audited
integration/ETL platform for simplifying trading integration. Used in production at banks, trading
merchants and hedge funds, K3’s low latency integrations with Exchanges, Trade Repositories, Price
Sources and ensure audited, transparent and correct delivery of data payloads.
K3 has current off the shelf integrations for both Dodd-Frank and EMIR compliance. Purpose built to
meet FC, NFC+ and NFC- reporting demands, K3’s off the shelf connections include, ICE Trade Vault, CME,
DTCC and Regis-TR. K3 also has existing connections to most ETRM systems including, OpenLink,
Triplepoint, Amphora, Allegro, Eka, Sungard and Brady. For ad-hoc reporting, BroadPeak also offers
cloud based drop copy service that allows users to drop an Excel sheet of trades into a local folder that is
picked up by K3 for routing and transformation to the TR of choice.
Vendor – BroadPeak Inc
www.broadpeakpartners.com
info@broadpeakpartners.com

38
EMIR-ate.com
emir-ate.com is a service provided by Treamo Business Consulting GmbH. and is a cloud-based SaaS-
solution that helps corporates comply with the reporting requirements of EMIR. It interacts with
existing systems and tools (TMS, spreadsheets, trading platform) as well as with the Trade
Repository. It is a service that ensures EMIR compliance at the press of a button.
The trades will be reported via XML files. At the moment, the Trade Repository requires approx. five
minutes for the return message that either confirms the correctness of data or contains a list of
errors. EMIRate will convert these status messages in an understandable format and will present the
result of the return message in the list of trades, where users can, for example, filter all those
transactions, which have been sent but not yet acknowledged. The same also applies to messages
regarding the reconciliation status.
Vendor – Treamo Business Consulting GmbH
http://www.emir-ate.com
DeltaconX/Tradelogic
DeltaconX Captures the compliance data held in your trading, financial, and logistical systems,
transforms them into the correct message structures, and routes them to the appropriate regulatory
reporting destination such as Trade Repositories, CCPs, RRMs, ARMs, and ACER. Response and status
messages are captured as part of the submission process and relayed back to the source systems. A
full audit trail of data processing and transfers is maintained. There is no need to upgrade your
trading system as all the required and missing data can be added directly in DeltaconX.
DeltaConx is being offered to the market together with TradeLogic as implementation partners.
Vendor: CH Consult GmbH
http://www.deltaconx.com
Finalyse
FINALYSE offers an automated solution for the new European Market Infrastructure Regulation
(EMIR). This solution can be easily implemented on site or externalized towards Finalyse (Third
Party).
The goal of this solution is to allow customers to be EMIR compliant with a minimum of investment
costs and to benefit from our expertise in terms of European regulation and implementation
solutions.
The main advantages of the solution are:

39
EMIR Compliant Data Model
Our EMIR data model is compliant with the new regulatory standards of the European
Securities and Markets Authority (ESMA) and is built according to the most modern and
advanced data model design techniques (full auditable, security and normalization).
Furthermore, it will store a complete history of all transactions.
Automated Data Quality Checks
Our EMIR data model is verifying the data for completeness and is transforming the client’s
specific naming conventions into the EMIR required taxonomy. Specific data quality errors
are monitored and reported for improvement.
Automated Reporting to Trade Repository
Our solution is an automated process flow for the reporting of modifications, valuations and
trade terminations towards one of the major trade repository systems. Furthermore, the
process reports information coming back from the TR (e.g. uncommitted trade reports).
Easy Implementation or Full Outsourcing
Finalyse’s solution for EMIR consists of a data model concept and process flow which can be
easily implemented on site. The remaining workload is to build a bridge between our ready-
to-use solution and the client’s internal data system(s). Furthermore, customers can
delegate the reporting as well towards Finalyse, which will act as Third Party.
Vendor – Finalyse
http://www.finalyse.com
Seven2one
Steria Mummert Consulting AG and Seven2one Informations systeme GmbH offer companies subject
to reporting requirements a mature, holistic solution for secure, transparent and cost efficient
reporting that is fully compliant with the EMIR and REMIT regulations.
The solution includes;
EMIR/REMIT compliant data model
Automated collection of data from upstream systems and reporting: any data format
possible, no adaptation required
Stable, automated and auditable reporting processes
Integrated data quality checks ensure highest data quality
Simple and transparent monitoring of data, processes and reports
Easy implementation in your own company, full outsourcing or SaaS
Can be expanded to comply with future reporting requirements (e.g. MiFID, Bafin)
Secure investment with added value and full cost control (fixed price offer)
Wide variety of functions (portfolio comparison, risk cockpit, compliance relevant
evaluations, e.g. market manipulation, market abuse)
High professional utility, e.g. mapping of electricity products with complex profiles, mapping
of orders for REMIT, serves all asset classes (FX, IR, commodities)
Immediate implementation, project can be started immediately
Full control over reportable data, data streams and generated reports

40
Reporting with added value: expandable without programming to comply with further
reporting obligations (e.g. MiFID, BAfin) even up to the production of an internal reporting
tool for trading and risk management
Tried and tested standard software solution offers a high degree of reliability
Rapid integration of new reporting obligations through modular updates
Strong partners offer extensive experience with both the technology and sector
A broad range of services provide optimum support - from professional consulting on the
regulatory framework to the implementation of an automated solution to operation of the
software
Vendor – Seven2One
http://www.seven2one.de
Impendium Elements
Impendium Systems Elements is a Private Cloud Platform that enables you to be compliant with
multiple regulations throughout the world using a single solution. Unlike traditional approaches and
vendors we incorporate the technical elements of common global regulations onto the Platform
enabling you to be compliant sooner. Report to regulators, central banks or even internal
departments using Elements in a timely and cost efficient manner whilst having a complete single
view of your regulatory data.
Elements is a specifically engineered regulatory platform. Impendium Systems Regulatory Advisory
Board – made up of industry and regulatory experts – continuously studies the global regulatory
roadmap and ensures that key regulatory components are incorporated directly into the Platform.
Elements services many current financial regulations including as Dodd-Frank, EMIR, REMIT and
MiFID and work is underway on future regulations such as MiFID II and MAD II.
Vendor – Imperium Systems
http://www.impendiumsystems.com
Lombard Risk REFORM
The Lombard Risk REFORM platform is a highly configurable solution designed to help firms manage
predominantly trade-related processes – such as pre-/post-trade processing and regulatory
transaction reporting.
Right now firms are using REFORM to meet the global regulatory transaction reporting
requirements. Lombard Risk REFORM is designed for real-time regulatory transaction reporting, will

41
interface seamlessly with an organization’s banking (or other) systems, and is ideally suited for EMIR
(as well as Dodd-Frank, MiFID and REMIT) that are being introduced to monitor and regulate the
OTC derivatives market.
Vendor – Lombard Risk
http://www.lombardrisk.com
OpenLink – RegCube
The EMIR and REMIT business intelligence solution is an extension of OpenLink's CubeIntelligence
portfolio. The new online analytical processing (OLAP) based cube offering provides financial
institutions and organizations in other verticals, particularly energy firms, participating in energy and
financial trading a speedy and cost-effective way to comply with the new reporting and
reconciliation requirements.
The CubeIntelligence team has developed the OpenLink REG Cube to ensure clients continue to have
access to the market while remaining compliant with the new regulations set to come into force this
year.
The OpenLink RegCube offers firms the ability to:
Generate the regulatory reports that firms must provide daily to trade repositories and
registered reporting mechanisms
Send the data to EMIR TRs and REMIT RRMs
Calculate and record the gross notional values in line with EMIR
View the EMIR and REMIT values for the entire firm and also drill down, by all categories into
trade level detail if required
Easy integration of multiple source systems (whether produced by Openlink or not) using a
simple interface which offers trade enrichment with reference date and other complex rule
based transformations
Specify which trades, books or products are in scope of the regulations so users can filter on
these criteria to calculate the EMIR and REMIT values for the in-scope trades only
Enrich and transform data before sending to the Repository using a complex transformation
engine
Perform bilateral portfolio reconciliation using the data already in the cube combined with
file production and matching facilities
The cube is integrated with other cubes such as the Risk Cube. It can be used as the basis of a cross
company business intelligence solution.
Openlink also supply an “accelerator” from Endur and IRM so that those systems can be connected
to the cube with a short implementation time.
Vendor - OpenLink Financial
http://www.olf.com

42
Energeya – XDM Compliance
Energeya’s XDM© COMPLIANCE allows users to manage manage regulations as a Business Process
with a complete environment of tools and processes for full requirements management versus local
and international Compliance Regulators.
The solution is multi-regulation, rules-based, data-independent, workflow-based and provides batch
support. It is part of XDM© Suite for commodities management, and is available both stand alone or
together with other Energeya’s commodities and process management modules.
As a standalone solution, XDM© COMPLIANCE can address the Compliance requirements also for
customers who already have other ETRMs or Contract Management systems: in this case, XDM©
COMPLIANCE takes advantage from the full modularity of the XDM© platform, providing the
Customer with a lightweight version of the XDM© system but with the whole set of infrastructure
core modules.
Vendor: Energeya
http://www.energeya.com
e·Opt PriceHub e·Comply
PriceHub e·Comply has been developed by e·Opt Solutions, a Germany based provider of solutions in the
Energy Trading space. It is a comprehensive tool for Regulatory Reporting under EMIR and REMIT and is
targeted towards the obligations of most medium to small sized energy companies in Europe. It is a viable
tool for this market and though currently built for EMIR and REMIT, it can be easily extended to serve
future Regulatory challenges.
e·Comply has an intuitive and transparent workflow. It offers extensive Reporting and interfacing
possibilities as well as an open data model for upstream source systems, thereby making bespoke
interfacing to ETRM or other systems achievable with limited effort. e·Comply already has a downstream
interface for REGIS-TR and as other Repositories and RRMs expose their interfaces, e·Opt plans to update
its interfacing as well.
Two key differentiators of e·Comply have are firstly its ability to seamlessly report Orders to Trade under
REMIT, and secondly its Third Party Reporting module. The former uses online interfacing to Trayport and
other platforms to gather orders. The Third Party Reporting module allows companies to offer Reporting
Services to smaller clients with limited resources and trading operations.
With Regulators expected to be increasingly intrusive, the Trade Annotation function is a useful tool to
answer background questions on Trades and Orders.
e·Comply has been built as a comprehensive Compliance tool for organizations, rather than being limited
to EMIR and REMIT. It is deployed as an inward as well as outward looking tool, helping Compliance
Managers to satisfy internal as well as external demands.
e·Comply is currently live at Syneco Trading GmbH, Enovos Luxembourg and SmartestEnergy UK.
The team behind e·Opt, led by its CEO, Rajeev Bhatt traces its roots to years of Energy Trading and Risk
Management experience. The PriceHub suite with its various modules for Forward Curves, Price Data

43
Management, Pricing and related areas, have been built using their experience in Trading and
Technology.
Vendor – e·Opt Solutions
http://www.eopt.org
Pioneer Solutions Compliance Tracker
Pioneer Solutions' ComplianceTracker provides enterprise-wide compliance tracking,
performance monitoring and reporting for corporate, regulatory, environmental and other
compliance requirements.
ComplianceTracker supports the following:
 Compliance requirements administration
 Performing activities and monitoring
 Approving activities and monitoring
 Triggers and exception management
 Compliance management
 Reporting
Vendor – Pioneer Solutions
http://www.pioneersolutionsglobal.com
Calvus Solutions Golden Trade Repository
Many organisations use the regulatory reporting services offered by the exchange or banks with
which they trade. However, they remain responsible for providing evidence that all their
transactions have been properly reported. CalvusControl™ provides this evidence. We aggregate all
the information from each of your banks and exchanges, together with any directly reported
transactions, into a single consistent view that provides the compliance you require.
Vendor – Calvus Solutions
http://www.calvussolutions.com

European Commodity Market Regulations Part 1

European Commodity Market Regulations Part 1

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (17)

Similar to European Commodity Market Regulations Part 1

Similar to European Commodity Market Regulations Part 1 (20)

More from CTRM Center

More from CTRM Center (20)

Recently uploaded

Recently uploaded (20)

European Commodity Market Regulations Part 1