Abide Financial Limited Regulatory Reporting For MiFID & EMIR

1. Abide Financial Limited Regulatory Reporting For MiFID & EMIR

2. Agenda Introduction to Abide Financial EMIR Status Update Abide EMIR Reporting Services MiFID - FCA Reporting Commercial considerations

3. Abide Financial Limited • Founded in 2010 • 2011 – Built service and completed FCA approval for ARM • Capacity built and tested to 5m reports per day – 30% of avg. UK volume • 2012 Client acquisition – 13 clients and 1m Transaction Reports /day • Over 45 million back reports submitted • Summer 2012– Advisory services launched • Autumn 2012 – French Financial Transaction Tax service added to hub • Spring 2013 – General-purpose reconciliation service added to hub • June 3rd 2013 - Abide launches EMIR reporting service

4. Abide helps protect reporting compliance • Regulatory Environment is constantly evolving and becoming more complex

5. Abide Tailored Service Management

6. Abide EMIR Service Positioning • Abide believes in the first instance, we can secure better value for our clients by using another repository for the utility reporting aspects • Abide will continue to invest in the core service that differentiates us today • Single data ingestion – multiple regulatory and non regulatory services • Data enrichment and aggregation • Enhanced validations • Standard and customised reconciliations on offer • Outputs to selected authorities in multiple formats • Targeted advisory services • High levels of service management • Abide continues to review landscape. At the appropriate time, Abide will become a repository

7. Abide’s Regulatory Reporting Service Reporting Firm Reporting , Reconciliation and Exception Management Reports produced for MiFID Abide Hub & Value Added Services FCA Abide ARM Reports produced for EMIR ESMA Abide EMIR Reporting TRUtility PublicAccess

8. Abide Platform Architecture Source handler metadata Business logic metadata Output / display metadata ARM I n g e s t o r JSON records V a l i d a t o r F S H a n d l e r FTT JSON records ARM DB JSON records JSON records TR FTT DB JSON records JSON records TR DB Other e.g. DFA Table storage Data sources RDB storage Security GUI

9. The Abide Regulatory Reporting Process • Tailored Service Management

10. Update on EMIR Status

11. Contents • EMIR status update • Requirements • Update on timelines • Implementation challenges • Abide EMIR Reporting Services • Abide positioning • High Level System Architecture • Service description overview • Implementation preparation for Abide Customers • Overview of commercials – Abide Reporting Service

12. EMIR TR Reporting Requirements Summary • All derivative transactions, their termination or modification, whether OTC or Exchange-Traded, are reportable • Once per day update on collateral and Mark to Market to be reported per trade • There is no lower value threshold • There are no exclusions for FX, Commodities, Interest-Rate or Index-related derivatives • Transactions should be reconciled between the counterparties before reporting by T+1 • Both counterparties report Counterparty Data Set (26 fields), only one needs to report Common Data Set of trade details (59 fields)

13. EMIR Timeline (As at June 2013) 23.11.13 Within 90 days 23.02 .14 Within 3 years 23.11 .16

14. EMIR Implementation Challenges No mechanism for data validation by TRs in EMIR No EMIR data extraction and enrichment tools widely available Data standards (LEI, UTI, UPI etc) will not be ready in time for initial implementation – interim solutions are required EMIR designed initially for OTC transactions – ETDs are an after-thought Standards and operating procedures for managing interchanges, including reconciliations, between TRs are not defined The operational model and reporting responsibilities between reporting firms, TRs and CCPs is in its infancy The day one legislation will continue to be refined as issues present themselves

15. Abide EMIR Reporting Service

16. EMIR Trade Reporting Core Service Description • Combined MiFID and EMIR reporting • Data ingestion and validation • Apply a number of basic, logic-driven and reference data driven validations to data reported to trade repository • Back-load of data to August 2012 • Operational monitoring and management • Event-driven notifications of exceptions and errors • System processing status reports • Maintain comprehensive log of all additions and changes • Reconciliation • Against source data, clearing dataand data held in the TR • Implementation support for Trade Reporting responsibility definition • e.g. delineation of reporting responsibilities between trade flow participants • Preparation of data for publication in the Trade Repository

17. EMIR - Implementation Service Options • Identifying trade flows and reporting responsibilities • Data acquisition • Data sources, semantic gap analysis • Data validation and enrichment • Development of operating model • Integration with existing operational processes and data formats • Management Information content and delivery mechanism • Exception management and service management configuration • Development of interim solutions to counter EMIR issues • UTI matching, LEI & UPI workarounds • Bespoke reconciliation & reporting • Multi way reconciliation designed to customer requirements • Inter TR reconciliation • Management information and reporting designed to customer requirements • Position reporting management & updates; complete flexibility on data formats

18. Preparation for EMIR Reporting • Significant effort should now be focused on defining the internal business, process and system changes needed to meet the technical specifications for the EMIR reporting architecture. • Building and testing the new reporting solution – ensure capture of the 85 EMIR fields. • Updating BAU procedures to ensure capture of new data items (such as MTM of collateral, confirmation time stamps etc). • Design and implement a control framework around the new EMIR reporting process and requirements. • Back-load any trades which were outstanding on 16th August 2012 and are still open • Test the new reporting solutions (i.e. run test data through validations and into a TR)

19. MiFID Reporting to FCA

20. The Abide MiFID Reporting Process • Tailored Service Management

21. The Abide MiFID Reporting Process • Abide deploys it’s HUB • Any format • Multi system • We receive sample data from each client system • We engineer data compatibility with TransacPort • Complete internal testing • Test with FCA test system • Extraction of MiFID data

22. The Abide MiFID Reporting Process • FCA Specs require extensive validation which Abide carries out and proactively addresses with the Client prior to submission • Data format and completeness • Correct combination of fields for TR situation • Check sums for ISIN codes • Validity of key data against reference data • Abide carry out additional Validations to warn our Clients of any issues – Reports still submitted but validation warnings made available; for example • ISIN Validation failures against reference data • Reporting of default times • Reports outside of T+1 • Incorrect use of FRNs or Internal references when BICs are available • Incorrect combinations of fields which although passing FCA validation are not compliant with TRUP3 • Validation • FCA Validations • Abide enhanced validations • Intelligent warnings

23. The Abide MiFID Reporting Process EXAMPLE client communication – Abide reported trading with a new client, without updated reference data… "Hi Murray (Abide) That’s interesting about xxxx – I will check that again – we haven’t had any upload errors so maybe there’s a timing issue on our side. Thanks for the heads up. I’ll get the Client info for you shortly.  Client 2" • Tailored • Proactive • System led • Bespoke and automated alerting and problem solving • Exceptions managed on an hourly basis • The GUI is available for more detailed reporting • https://transacport.abide-financial.com/?clientid=demo • Bespoke reporting is included in the onboarding pack • Exception management approach

24. The Abide MiFID Reporting Process • Once as many validation issues as possible have been dealt with inside the T+1 window, Abide processes the data into the FCA formats and submits the Transaction Reports • FCA respond with Zen validation status – all clear, Records accepted or Rejection usually due to reference data differences or duplicated records • Abide proactively manages any rejections with the Client • Abide produces a three way reconciliation between FCA data, Data Submitted by Abide on the Client's behalf and the raw trade data. Report generated for client. • Submission and reporting • Tailored • FCA Liaison • Reporting • Reconciliation

25. Abide Tailored Service Management • Alert frequency, content and recipients completely customisable • Automated emails at each stage of the process • File receipt • Extraction • Validation • Exception management • FCA Liaison • Client selects extent of self serve / management • GUI - Customisable access / views and functionality • Customisable management information and reconciliation

26. Abide Benefits - USP • Dual reporting to the most appropriate repository • Independent, no exchange tie or influences • Multiple services possible driven from singe data source • One of the few firms that can apply ARM experience to EMIR • The tailored approach to the deployed service will be expanded • Abide will isolate Clients from expected changes to regulations post regulation launch • Our advisory service will be available to help practically interpret the new regulations