1. How to mitigate constant changes in legal transaction reporting
Your integration partner within the financial industry
How to mitigate constant changes in legal transaction reporting
Mikkel Mördrup, TradeChannel
October 11th 2016

2. We all face the same challenge!
ESMA, NCA, ARM… all need a solution for Mifid II
ready January 3rd 2018
The challenges is to have a flexible set-up that
can be extended to additional regulations and
mitigate constant change management
The regulation is equal to all!
T+1 transaction reporting should be high
on the MiFID II project agenda
Source: Northern Trust ”Taming the Data set”
Survey : Most important
regulation
Source : Fima White paper ”A SNAPSHOT OF CHALLENGES IN FINANCIAL DATA MANAGEMENT”

3. Our experience is based upon EMIR reporting on behalf of…
Our experience is based upon EMIR reporting on behalf of…
: RP & TP for Life & Mutual funds
: RP & TP for Pension, Mutual funds & Inst clients
: RP for Pension
: RP for Mutual funds
: RP & TP for Live and Pension
: RP, TP & Delegations for Markets clients (sell side)
: Regis TR as Trade repository – Data model with outset in ESMA
: ETD (R010), OTC (R001)
ETD : Futures, Options, FRA, IRF
OTC : FX Forward, FX Swap, FX Option, IRS, TRS, CDS,
Swaps, Inflation Swaps, Swaptions
Instrument
coverage

4. The regulation challenge – Mitigate continuous changes
The regulation challenge – Mitigate continuous changes

5. Reflections from EMIR regulation
Advisory has moved from TR to local FSA
Terminology and instrument handling are different between market, portfolio systems, TR and ESMA
Different TR looks upon instruments differently
Equal to MiFID II, requirements were unclear until very late in the process
EMIR is to a large extent a data management project
Clients must report equal to counterparty for block and allocations for ETD
Key question, keep existing or build new?

6. Reflections EMIR RTS, MiFID II & SFTR
A choice between delegate, build or buy
When is end point ready for tests?
Selection of “end point” (FSA, ARM, TR and/or APA)
Will Brexit influence choice of “end point”
Aggregation of EMIR and MiFIR data or report separately?
MiFIR
Handling of personal data
Validation of instruments against ESMA new instrument list database (ISIN)
Data from several sources (Instruments & EMS vs IBOR)
Include SFTR?
Source : Consultation paper page Example 3

7. But we do not yet see dialogues related to the operation aspect of MiFID II
The industry have put emphasize on the market perspective & business impact
Quote from
FIM Asset Management AB
Johan Wahlman
CEO

8. What made us agile coping with changes
Selection of TR was crucial – For us, a choice between DTCC and Regis TR
Critical success parameter was a fully automated flow from source system to TR including reconciliation
Separating EMIR database structure from other applications relying only on raw data from source system
Life cycle events in depending on source system transaction / holding
Normalising data according to validation rules
Focus on connectivity
Running change management in freeze period without interrupting trade process, settlement or bookkeeping
Focus on usage of LEI only from inception
Introduction of configurable validation engine on all fields from inception
Full support for all instruments
Knowledge sharing between clients as the regulation is equal to all

9. Timeline T+1 Transaction reporting
Source Regis TR
Conclusion
Q – Test MiFIR
Q – UAT RTS
Q – UAT MiFIR
Q – Production RTS
Q – UAT SFTR
Q – Production MiFIR
Q – Production SFTR
Choices
Q – Dev or buy MiFIR
Q – Selection of ARM
We consider the coming changes as one package – one project with several deliveries
We are looking at end points as we speak
We are participating in Deutsche Börse MiFID II Pilot project
We are looking into requirements and data sources
Post trade transparency reporting to an APA is still under evaluation
A) OTC / SI – Trade with counterpart outside EU
B) OTC / SI – Seller with non SI counterpart
15 min

10. Our Target operation model for T+1 Transaction reporting
Assumptions : Personal data stored with ARM – ARM validate instruments against ESMA Instrument list
WEB Portal
One integration – several regulations
Client data sources
Data validation - reconciliation
ARM, APA, TR
EMS / OMS
IBOR
EMIR
SFTR
MiFIR
Active MQ
WEB service
sFTP
Separate data validation models to mitigate change management
Translation
LEI
Portfolio
Collateral
Client ID
Fixed field
TradeseC
Translation table:
Buy & Seller details
Decision Maker details
Managed by client
Restricted access
B & S ID Details
ASP – Hosted - SaaS

11. Required data sources for MiFID II – map your infrastructure
TradeseC
(report engine)
Report & Sender identification field
Logic for reportable transactions (Buy, Sell,
Close out, change of nominal)
IBOR
IBOR
IBOR
Transaction & Instrument details
Usage of ISIN
Identification of Buyer & Seller (LEI or ID)
Same, same but different to EMIR
Complexity
EMS / OMS
EMS / OMS
EMS / OMS
Investment decision & execution
Short sale indicator
OTC Post trade transaction type
Algorithms, Waiver
Decision maker, Trader (Personal ID)
Complexity

12. Wrap up One integration with ARM & TR
The data model for each regulation must be separated
The report engine must be able to load data from several sources
Introduce a validation model on field level
Ensure full audit trail – being able to document when and what has been reported – requires reconciliation on message level
Separate report engine from daily transaction flow
Share experience with your community

13. Disclaimer
The views and statements in this presentation is based upon our reflections and experiences working with clients within the area of Transaction T+1 reporting. This presentation is not a interpretation of MiFID II Our presentation is based upon current assessment of MiFID II…it will change as we come closer.

14. Visit
for more information