MiFID II / MiFIR Transaction Reporting A Practical Guide

MiFID II / MiFIR
Transaction Reporting
A Practical Guide

Introduction
When confirmation came that the implementation date
for MiFID II was to be pushed back to January 2018 as
expected, many financial institutions will have breathed
a sigh of relief.
However, the scope of the changes and amount of new
data required by the regulations, means that firms need
to get their house in order well in advance of this date.
Particularly considering the hard line that regulators such
as the FCA have taken with MiFID non-compliance in
recent times.
The constantly shifting regulatory landscape requires
more agile and more robust data control processes than
ever before. Simply patching up existing systems, or
scaling up manual work will not be sustainable, and it
makes sense for firms to put processes in place now to
future-proof the organisation against further change.
This paper looks specifically at the data problems that
MiFIR transaction reporting requirements are likely
to cause, as well as the current state of data control
processes in the industry.
But first, some background…
MiFID II / MiFIR Transaction Reporting
A Practical Guide

MiFID II and MiFIR: disambiguation
The revision of MiFID I comes in two parts:
+ MiFID II (Markets in Financial Instruments Directive II)
+ MiFIR (Markets in Financial Instruments Regulation)
The directive gives some scope for national governments to
amend or interpret it differently when it comes to transposing
the requirements into national law. The regulation however will
come into effect across all European markets immediately and
consistently as soon as it is implemented.
One of the main criticisms of the original MiFID was that national
regulators did not enforce the directive with the same zeal across
Europe. While the UK’s FCA, for example, clamped down fairly
strongly on any breaches, other regulators such as Spain’s CNMV
were far more lenient.
It is significant, therefore, that the transaction reporting
requirements themselves appear in MiFIR rather than MiFID II.
We will look at these requirements below.
Summary of scope changes from MiFID I to MiFIR
MiFID I
Source: “MiFIR reporting requirements:
Not for the fainthearted”. Aite Group,
April 2015
24 data
fields
Equities,
some equity
exchangetraded
derivatives
RMs,
MTFs
MiFIR
65 data
fields
RMs, MTFs
& OTFs
Nearly the
entire universe
of financial
instruments
MiFID II / MiFIR Transaction Reporting
A Practical Guide

Instruments covered
The list of financial instruments covered has been extended
to almost all instruments traded in European markets – with
particular emphasis on the OTC derivatives market that was
previously out of scope for MiFID I.
The only financial instruments that still fall outside MiFIR’s
scope are:
In addition, MiFIR rules have been extended to include non-EUbased
branches of EU firms. These branches will need to submit
transaction reports to the firm’s home state authority.
So the regulations will not only affect the majority of financial
institutions within Europe – a great many outside Europe will be
affected as well.
+ Segregated collateral transfers in bilateral transactions
(though the exact details of this are still being worked out)
+Financing transactions already covered under the Securities
Financing Transaction Regulation (SFTR)
+ Give-ups or give-ins
+The issuance, allotment, subscription or exercise of
pre-emption rights
Trading venues
Under the new regulations, any instrument considered to be
“liquid” must be traded on an approved venue, which can be a
regulated market (RM), multilateral trading facility (MTF), or in the
case of OTC transactions, an organised trading facility (OTF).
There is ongoing debate and controversy as to what exactly
constitutes whether an instrument is “liquid” or “illiquid”.
Under MiFIR, all liquid instruments will have to be traded on an
exchange, and will also be subject to far greater pre- and posttrade
transparency requirements. Whether a particular product is
classified as liquid or illiquid could therefore have a big effect on
market making.
The issue with making this distinction across so many different
instruments is one of the main reasons why the MiFID II and
MiFIR implementation date has been delayed twice from its
original start date of January 2015.
Data fields
The number of data fields required on transaction reports is more
than doubling from 24 to 65. In addition, many of the existing
fields required by MiFID I will be amended to encompass more
complexity and a greater breadth of instruments.
There follows a summary of the reporting requirements, and
some of the internal and third-party systems that firms will
need to source the new data from.
MiFID II / MiFIR Transaction Reporting
A Practical Guide

MiFIR transaction reporting summary
Internal/External Data Sources
1-6
General Fields
Front office
systems
Algorithm code
Counterparty
Trading venue
LEI database
HR database
ISIN database
MIC database
CFI database
Country code
Flag
1. Report status
2. Transaction reference number (TRN)
3. Trading venue transaction ID code
4. Executing entity ID code
5. Investment firm covered by Directive
2004/39/EC or Directive 2014/65/EU
6. Submitting entity ID code
Buyer
7. Buyer ID code
8. Country of branch
9. First name
10. Surname
11. Date of birth
7-24
Seller
16. Seller ID code
17. Country of branch
18. First name
19. Surname
20. Date of birth
Buyer Decision Maker
12. Buyer decision maker code
13. First name
14. Surname
15. Date of birth
Seller Decision Maker
21. Seller decision maker code
22. First name
23. Surname
24. Date of birth
Transmission Details
25. Transmission of order indicator
26. Transmitting firm ID code (buyer)
27. Transmitting firm ID code (seller)
25-27
Transaction Details
28. Trading date and time
29. Trading capacity
30. Quantity
31. Quantity currency
32. Derivative notional increase/decrease
33. Price
34. Price currency
35. Net amount
36. Venue
37. Country of branch membership
38. Up-front payment
39. Up-front payment currency
40. Complex trade component ID
Investment Decision Maker and Executor
57. Investment decision within firm
58. Country of branch responsible for decision maker
59. Execution within firm
60. Country of branch supervising execution
28-56
57-60
61-65
Instrument Details
41. Instrument ID code
42. Instrument full name
43. Instrument classification
44. Notional currency 1
45. Notional currency 2
46. Price multiplier
47. Underlying instrument
48. Underlying index
49. Term of underlying index
50. Option type
51. Strike price
52. Strike price currency
53. Option exercise style
54. Maturity date
55. Expiry date
56. Delivery type
Flags
61. Waiver indicator
62. Short selling indicator
63. OTC post-trade indicator
64. Commodity derivative indicator
65. Securities financing transaction indicator
MiFID II / MiFIR Transaction Reporting
A Practical Guide

General fields
These are fairly standard fields, but in some cases may require
extra reconciliation steps.
For transactions executed directly on a trading venue, the venue
itself will provide the Transaction Reference Number (TRN)
and Trading Venue ID Code needed in the report. The reporting
firm will need to make sure these are accurate. For all other
transactions, the reporting firm will need to provide a unique TRN
for each report.
The Executing Entity ID Code and Submitting Entity ID Code
are both new fields and need to be defined using a legal entity
identifier (LEI). These LEIs will need to be validated against the
global database, currently maintained by the Legal Entity Identifier
Regulatory Oversight Committee (LEI ROC).
Buyer and seller fields
Buyers and sellers can either be reported as legal entities
(i.e. investment firms or legal persons), or natural persons.
As above, where the buyer or seller is a legal entity, they need to
be identified using an LEI, which needs to be reconciled against the
global LEI database before engaging in any reportable transactions.
This is particularly important when an investment firm is trading
on behalf of its clients, as the firm will need to collect and verify
the LEIs provided by its clients in advance of any trading.
before compiling transaction reports. To ensure best practice, they
should also reconcile any responses from the reporting venues to
make sure the data is accurate.
Additionally, under MiFIR, firms will need to identify the person
or entity who made the decision to buy or sell the instrument in
the first place. This will require considerable work to record the
relevant data in front-end systems, and then robust data controls
to ensure it remains accurate throughout the lifecycle of the trade.
Where the buyer or seller is a natural person, their first name,
surname and date of birth are required in the report. Firms will
need to gather and normalise this information from HR databases,
Transaction and instrument details
Due to the addition of OTC derivatives – and the difficulty in
classifying them – the number of fields covering transaction and
instrument details has increased from MiFID I to MiFIR. The new
fields include:
Furthermore, several other fields need to be reported using
different types of identifiers, for example:
Field
Identifier
+ Derivative notional increase/decrease
+ Country of the branch membership
+ Up-front payment amount and currency
+ Complex trade component ID
+ Option exercise style
+ Delivery type
Instrument ID Code
Underlying Instrument Code
Instrument Classification
Trading Venue
International Securities
Identification Number (ISIN)
International Securities
Identification Number (ISIN)
Classification of Financial
Instrument (CFI)
Market Identifier Code (MIC)
Again, reconciliation controls need to be set up to ensure all this
data remains accurate and consistent.
MiFID II / MiFIR Transaction Reporting
A Practical Guide

Investment decision maker and executor
New to MiFIR reporting is the identification of the traders or
algorithms involved in the decision and execution process of a
transaction.
Whether an individual or a group of people make the decision to
trade, the firm must report the one person considered to have
primary responsibility for the transaction. This person needs to
be identified by their ID number, passport number, tax or national
insurance number depending on their nationality. Or, in the
absence of these, by a concatenated code consisting of:
+ Date of birth in the format YYYYMMDD
+ First five characters of first name
+ First five characters of surname
The main executor of the transaction must also be identified –
using the same system.
Where the decision to trade, or the execution of a transaction, is
carried out by an algorithm, that algorithm must be identified using
a unique, consistent and persistent code. This enables regulators
to track all transactions carried out under a particular strategy,
and also ties in with other areas of MiFID II which stipulate that
firms must have controls in place to ensure the auditability and
resilience of their algorithms.
These extra identifiers will require new data to be captured at
the point of execution, and then passed to middle and back office
systems to ensure consistency of reporting.
Flags
MiFIR will also introduce a variety of flags into the reporting
process. One of the reasons for this is to help the regulators
identify overlapping requirements between different regimes,
such as the European Market Infrastructure Regulation (EMIR),
the Securities Financing Transaction Regulation (SFTR) and
the Regulation on Wholesale Energy Market Integrity and
Transparency (REMIT).
There are five fields set aside for these particular flags:
+ Waiver indicator
+ Short selling indicator
+ OTC post-trade indicator
+ Commodity derivative indicator (‘true’ or ‘false’)
+ Securities financing transaction indicator (‘true’ or ‘false’)
While the latter two are simply ‘true’ or ‘false’ indicators,
the former three are more complicated.
Waiver indicator
Used to indicate whether the transaction was executed under
a pre-trade waiver.
The field can be populated by one or more of the following:
LRGS
Large in scale
RFPT Reference price transaction
NLIQ
OILQ
Negotiated transaction in liquid financial instruments
Negotiated transaction in illiquid financial instruments
PRIC
SIZE
ILQD
Negotiated transaction subject to conditions other than
the current price of that equity financial instrument
Above specific size transaction
Illiquid instrument transaction
MiFID II / MiFIR Transaction Reporting
A Practical Guide

Short selling indicator
Used to indicate a short sell where the seller is the reporting firm
or its client. Also indicates whether the short sale was undertaken
under an exemption from disclosure obligations as defined by the
Short Selling Regulation (SSR).
SESH Short sale with no exemption
SELL
No short sale
SSEX Short sale with exemption
NTAV Information not available
OTC post-trade indicator
Used to indicate the type of transaction. Many of these also relate
to data requirements under EMIR trade reporting. The field can be
populated by one or more of the following:
BENC Benchmark transactions
ACTX Agency cross transactions
NLIQ
OILQ
Negotiated transactions in liquid financial instruments
Negotiated transactions in illiquid financial instruments
NPFT Non-price forming transactions
LRGS Post-trade large-in-scale transactions
ILQD Illiquid instrument transaction
SIZE Above specific size transaction
CANC Cancellations
AMND Amendments
SDIV Special dividend transactions
RFPT Reference price transactions
PRIC
Negotiated transactions subject to conditions other
than the current market price
ALGO Algorithmic transactions
RPRI
Transactions which have received price improvement
DUPL Duplicative trade reports
TNCP Transactions not contributing to the price discovery
process
TPA
Package transaction
XFPH Exchange for physical transaction
Clearly there’s a large quantity of new data here that needs
to be obtained, normalised and reconciled, from a wide variety
of sources.
MiFID II / MiFIR Transaction Reporting
A Practical Guide

The cost of non-compliance
In recent years the increase in the size of fines for firms failing to
comply with MiFID I regulations has been notable. While regulators
may have given firms some leeway regarding breaches in the
past (when the regulations were fairly new) it now seems that
infractions are being dealt with far more heavily.
Indeed, following the Merrill Lynch fine, the FCA indicated that
the penalty for transaction reporting non-compliance will now
increase from £1 to £1.50 per breach, to ensure the industry takes
more care over their reporting requirements.
While the delay to MiFID II and MiFIR’s implementation date may
seem like a blessing, it could well make regulators less inclined to
forgive early mistakes.
Financial penalties for transaction reporting failures
Merrill Lynch
April 2015
Incorrectly reporting transactions and
failure to report transactions between
November 2007 - November 2014
RBS
July 2013
Incorrectly reporting transactions and
failure to report transactions
Deutsche Bank
August 2014
Incorrectly reporting transactions
£5.6m
£4.7m
Barclays
September 2009
Failures in transaction reporting
Credit Suisse
April 2010
Failure to provide timely and
accurate transaction reports
£1.75m
£13.3m
£2.45m
Société Générale August 2010
Failure to submit accurate reports for
approximately 80% of its reportable transactions,
across all its asset classes, for over two years
£1.6m
Source: “MiFIR reporting requirements:
Not for the fainthearted”. Aite Group,
April 2015
MiFID II / MiFIR Transaction Reporting
A Practical Guide

So, what can firms do?
When MiFID I was introduced in 2007, many financial institutions
failed to respond correctly, resulting in expensive and inefficient
‘quick fixes’, and in the cases above, significant financial penalties.
The current state of play in terms of data control processes at
most financial institutions, tends to be one of the following:
Spreadsheets, UDAs and manual work
Due to the complexities surrounding data control and
reconciliation, many institutions are still using spreadsheets and
manual work to fulfil their reporting obligations. However, with the
vast increase in data that MiFID II/MiFIR is going to bring, such
solutions will soon become impractically expensive and high risk.
User-Developed Applications (UDAs), for example, generally rely
on key members of staff to edit and maintain them, creating high
levels of risk should they be unavailable at critical times.
Also, as these UDAs are often in Excel, there are no proper audit,
evidence, governance or workflow functions. This might be fine
when everything is working properly, but as soon as there’s a
break, or if an unaudited user changes critical matching criteria,
it’s far more difficult to fix or even find the route cause of the
problem – leading to resource-intensive projects and the potential
for large fines.
While regulators have not specifically outlawed the use of
spreadsheets and UDAs, it is commonly accepted that under MiFID
II organisations need a much more robust and scalable approach
to data control.
Legacy architecture
Many firms will be updating their current systems to support the
new regulations. However, the majority of these systems are
difficult to scale, particularly considering the large increase in
reportable fields and data required.
Recent research from Aite group, for example, shows that it
takes over 64 days on average for financial institutions to set
up a new reconciliation.
Similarly, just patching up an old system to handle new data is
hardly future-proofing the organisation for subsequent changes.
MiFID II and MiFIR are certainly posing data challenges for
financial institutions, but they’re also a great opportunity for firms
to fundamentally transform their control processes, enabling them
to react more quickly and more efficiently to upcoming regulations.
Average time taken to analyse, build and test a new reconciliation
Analyse
Build
Test
23.87 25.67 14.86
Days Days Days
Source: “Reconciliation Trends in 2016:
Regulation and Nervous Recs”, Aite Group,
February 2016
Total 64.4 days
MiFID II / MiFIR Transaction Reporting
A Practical Guide

Duco can help
The current methods of controlling data are slow, expensive,
outdated and unscalable. Spending more time and money on
manual processes, or hacking together an old system to deal with
new requirements, clearly does not make sense in today’s highly
competitive business environment.
However, using Duco Cube – our revolutionary hosted data control
solution – organisations can completely transform their operational
processes.
Transformation
Replaces manual work
Agile, scalable and cost effective, Duco
Cube automates manual processes, saving
large firms millions in the first year alone.
Replaces legacy systems
Works with any data, in any format, without
need for large IT projects. Implementation
times can be cut from months to hours.
Future-proofed for change
Asset-class agnostic and extremely flexible
– whatever data challenges the future
holds, Duco Cube is set up to handle them.
Science
Machine learning
Duco Cube uses intelligent algorithms to
learn and adapt to your data, highlighting
issues and suggesting solutions at speed.
Empowering end users
Our unique ‘Natural Rule’ language means
non-technical users can set up controls
without writing a line of code.
Complexity made simple
Duco Cube is extremely powerful, but
that doesn’t mean it’s difficult to use.
Simple, intuitive interfaces make running
reconciliations fast and hassle-free.
Control
Available on demand
As a hosted service, Duco Cube can be
switched on within hours, delivering ROI
immediately – no IT spend necessary.
Powerful workflow
Duco Cube provides intelligent break
management workflow, to ensure all issues
are prioritised and actioned effectively.
Fully compliant
All tasks are recorded in an audit trail for
evidence analysis. Permissioning controls
ensure processes are compliant and in line
with corporate governance.
MiFID II / MiFIR Transaction Reporting
A Practical Guide

Duco Cube for MiFID II and MiFIR
Many data sources
Data Collation
+ Any data in any format
+ Alphabetic and/or
numeric data
+ Unlimited fields
+ Fast matching
+ Data transformation
+ Intelligent algorithms
+ API import/export
Normalisation
Trade Reporting
Mechanisms
Governance
+ Admin rights
+ Permissioning
+ User/groups
+ Super admins
+ Data masking
+ Audit trail
+ Email alerts
+ ISO 27001
Audit
Trade Reporting
Mechanisms
Reconciliation
+ Intuitive design
+ Natural rule language
+ Parallel algorithms
+ Machine learning
+ Fuzzy matching
+ High-volume processing
+ App-like interface
+ Immediate response
Results
Trade Reporting
Mechanisms
Workflow
Management Information System (MIS)
+ Break management
+ Prioritisation
+ Route cause analysis
+ Pattern recognition
+ Real-time dashboard
+ Custom views/widgets
+ Break alerts
+ Statistical analysis
Transparency
Trade Reporting
Mechanisms
In conclusion
MiFID II and MiFIR will result in an avalanche of data that financial
institutions need to collate, normalise, control and reconcile.
Due to the sheer volume and complexity of data, firms must
get robust data control processes in place as soon as possible.
This is particularly important given the increasing scale of
fines being handed out for non-compliance under MiFID I.
However, the majority of methods for controlling data are not fit
for purpose in the current environment. Firms should consider
these regulations as an opportunity to transform their operations
processes so they are well placed to deal with the inevitable
‘next round’ of regulatory requirements.
Duco Cube provides such a transformational solution, enabling
firms to dramatically streamline their data control and
reconciliation functions. For more information, please email
info@du.co or call one of our offices.
MiFID II / MiFIR Transaction Reporting
A Practical Guide

London
Exmouth House
3-11 Pine Street
London, EC1R 0JH
United Kingdom
+44 (0)20 3111 9294
New York
31 West 34th Street
Suite 8001
New York, NY 10001
USA
+1 212 353 6542
Luxembourg
12 Rue Guillaume Schneider
Luxembourg
L-2522
+352 2740 6114
info@du.co
MiFID II / MiFIR Transaction Reporting
A Practical Guide