Embed Size (px)
Citation preview
1
Client Welcome Pack & Onboarding Guide Version 1.00
2
TABLE OF CONTENTS 1 WELCOMING YOU TO MARKETAXESS ...................................................... 4
2 EXECUTIVE BRIEF ........................................................................................ 5
3 INTRODUCTION ............................................................................................. 6
3.1 Document Structure ........................................................................................ 6
3.2 Introduction to MarketAxess ............................................................................ 7
3.3 Meet MarketAxess .......................................................................................... 8
3.4 Timeline ........................................................................................................... 9
4 BUSINESS TRANSITION ............................................................................. 10
4.1 Legal Considerations .................................................................................... 10
4.2 Service Delivery During Business Transition ................................................ 10
4.3 Service and Support Model During Business Transition ............................... 10
5 MIGRATION .................................................................................................. 11
5.1 Migration planning ......................................................................................... 11
5.2 Service delivery after migration ..................................................................... 13
5.3 Description of migrated services ................................................................... 15
5.3.1 ARM .............................................................................................................. 15
5.3.2 APA ............................................................................................................... 16
5.3.3 Best execution – Quality of Execution (RTS 27) ........................................... 16
5.3.4 Best Execution – Top 5 Venue Report (RTS 28) .......................................... 17
5.3.5 Systematic Internalizer (SI) Identification ...................................................... 17
5.3.6 Systematic Internalizer (SI) Reference Data Reporting (RTS 23) ................. 17
5.3.7 Commodity Position Reporting (CPR, Art. 58) .............................................. 18
5.3.8 EMIR Reporting ............................................................................................. 18
5.4 Step-by-step migration lifecycle .................................................................... 18
5.4.1 Timeline ......................................................................................................... 19
5.4.2 Data Analysis and Submission ...................................................................... 20
3
5.4.3 Technical Connectivity .................................................................................. 22
5.4.4 Training and Testing ..................................................................................... 23
5.4.5 Cutover .......................................................................................................... 24
6 DATA STORAGE AND PROCESSING ........................................................ 26
6.1 Security Principles ......................................................................................... 26
6.2 European Data Store (EDS) .......................................................................... 27
6.3 The Virtual Private Cloud .............................................................................. 29
6.4 Network security ............................................................................................ 29
6.5 Encryption and Key Management ................................................................. 30
7 BUSINESS AS USUAL OPERATING MODEL ............................................ 31
7.1 Service and Support Model Post-Migration ................................................... 31
7.2 Generic Client Operating Model .................................................................... 32
7.3 Client Forums and Working Groups .............................................................. 34
7.4 Risk Management ......................................................................................... 34
8 MARKETAXESS SYSTEMS AND ARCHITECTURE .................................. 36
8.1 Technology Platform ..................................................................................... 36
8.1.1 Platform Overview ......................................................................................... 36
8.1.2 Deep Dive: Business Logic and Data Access tier Services .......................... 36
8.2 People ………………………………………………………………………………38
8.3 Software Development Life Cycle (SDLC) .................................................... 39
8.4 Summary of Activity ...................................................................................... 40
9 INVOICING & PAYMENT DETAILS ............................................................. 41
10 COMMON IMPLEMENTATION QUESTIONS .............................................. 41
11 GLOSSARY OF TERMS AND ACRONYMS ................................................ 61
For any help or assistance regarding this document please contact the Post-Trade Relationship Management (PTRM) team
• Email: [email protected]
• Netherlands – Telephone: +31 (0)20 8888 026 / UK – Telephone: +44 (0)20 3655 3588
4
1 WELCOMING YOU TO MARKETAXESS
You are now a MarketAxess Post-Trade client. We’re delighted to welcome you to our client family and want you to know that you’re in good hands. And, with this introduction, we want to quickly explain what being our client means. First and foremost, it means that you’re now part of an innovation story that’s over 30 years in the making. Since the creation of Trax in 1985 – the original firm that forms the nucleus of our MarketAxess Post-Trade business – we’ve been delivering regulatory reporting and data services to the world’s leading financial institutions. From MiFID and EMIR to CSDR and SFTR, we’ve helped hundreds of clients to improve efficiency, reduce operational risk and manage regulatory compliance. In short – we’re regulatory reporting experts, and we’re in it for the long haul. You can rely on us to be there when you need us. You’re also now part of the wider MarketAxess story. That’s a story built on technical excellence, industry transformation and, importantly, a drive to always think client-first. We are a leader in institutional electronic trading in fixed-income securities. We’re also one of the fastest growing companies in the S&P500 and serve over 1,700 buy-side and sell-side firms across the globe. So, you are in good company. Our entire team is here to make your transition to MarketAxess as seamless, as easy and as valuable as possible. The team is based out of both Amsterdam and London, and has been expanded to ensure local, on-the-ground leadership for that transition. With the ongoing help and support of the Regulatory Reporting Hub team at Deutsche Börse Group, we will make sure that all your regulatory reporting obligations are met and your services uninterrupted. From personalised migration plans to pro-active client support, we promise to work with you to develop a clear path forward. That path starts today, with this onboarding pack. In this document, you will find detailed information on everything from our service and support model through to technical specifications and reference documentation. This is designed to give you complete transparency into your migration process, and to provide you with answers to any questions that you may have. It also contains contact details for the team. And, of course, if there is anything else that you need, or any question that we have missed, both we and the Deutsche Börse Group team are here and ready to help. These are unusual times, we know. But we want to re-assure you that we’re here to support your business, whatever the regulatory reporting environment throws at us next. And we very much look forward to meeting you in person once the situation allows. Welcome to MarketAxess. Chris Smith, Head of MarketAxess Post-Trade, and Geoffroy Vander Linden, Head of MarketAxess Netherlands & EU27 Trading
5
2 EXECUTIVE BRIEF
MarketAxess and Deutsche Börse Group (DBG) have closed the transaction for MarketAxess to acquire Deutsche Börse Group’s Regulatory Services GmbH (RegS) subsidiary. This will merge with MarketAxess’ Dutch ARM & APA (Trax NL B.V.) shortly after closing.
RegS currently provides reporting and publication services to clients in Europe through its Regulatory Reporting Hub (RRH). In MarketAxess, Deutsche Börse Group has found a partner with more than 30 years of experience in regulatory reporting who will be able to support and enhance the services you need to meet all your regulatory reporting obligations.
The merger is structured so that your current contract remains in place and you become MarketAxess clients without new business negotiations. MarketAxess and Deutsche Börse Group will work together through the 2021 transition period to ensure that all your regulatory obligations are met. Until your migration to MarketAxess systems is complete, Deutsche Börse Group technology will continue to fulfil your reporting requirements, while the service model will be delivered jointly.
Migration onto MarketAxess systems will occur in phases throughout 2021. We will reach out to discuss your specific availability to take this step. The scope of MarketAxess services is broadly similar to RegS and our intention is that all currently contracted services will continue to operate as they are now. Some technical changes (e.g. connectivity, firewall permissions) will be required, depending on your current service connectivity. We will explore the detail on a customer by customer basis as we continue planning of the migration phases.
The team at MarketAxess looks forward to welcoming your firm and providing any assistance you need for a successful migration.
6
3 INTRODUCTION
3.1 Document Structure
This document serves as a one stop reference for all information relating to your migration to MarketAxess.
To this end, we have structured this document to provide quick reference to the typical functions within a MiFID reporting firm; business, technology, compliance.
The key business and technology solution details are presented and explained in:
• Section 4: Business transition – legal considerations, service delivery and support model from closing until you are migrated onto MarketAxess systems during 2021
• Section 5: Migration – information on migration planning, service delivery post-migration, an overview of migration steps, technical specifications and other reference documentation
• Section 6: Data Storage and Processing – information on our security principles and setup, including our European Data Store (EDS) solution
• Section 7: Business as Usual Operating Model – information on the handover to your business operations and compliance functions
For supporting information, please reference:
• Section 8: MarketAxess Systems and Architecture – for a technology overview, information on interfaces, formats, bandwidths, connectivity, performance and architecture
• Section 9: Invoicing & Payment details – to inform your billing requirements
• Section 10: Common implementation questions – based on information requested in previous implementation
• Section 11: Glossary of Terms and Acronyms
The contents of this document are intended to support you in your migration but should not replace your own regulatory and compliance advice. This guide does not constitute part of the contractual documentation for the relevant MarketAxess services and intentionally does not address the contractual documentation.
7
3.2 Introduction to MarketAxess
MarketAxess provides a full range of pre- and post-trade services, market data products, and automated trading solutions. We operate a leading, institutional electronic trading platform as well as the award-winning Open Trading™ marketplace.
Figure 1: MarketAxess business overview
Trax NL B.V. and Xtrakter Limited are MarketAxess’ respective Data Reporting Services Providers (DRSP) for our clients in the EU and the UK.
Both are wholly owned subsidiaries of MarketAxess Holdings Inc. in the Netherlands and the UK respectively. All MarketAxess group entities use the brand name ‘MarketAxess’, including Trax NL B.V. and Xtrakter Limited. However, in this document, for purposes of clarity, Trax NL B.V. is referred to as Trax NL, and Xtrakter Limited is referred to as Trax UK. Where the distinction does not matter, then the generic term MarketAxess shall be used to refer to either/or both entities.
Trax NL is licensed by the Autoreit Financiële Markten (AFM) as a DRSP for the provision of ARM and APA services. For those firms wishing to continue to report to the UK post-Brexit, MarketAxess already operates Trax UK which is authorised and regulated as a DRSP by the UK Financial Conduct Authority (FCA) for the provision of ARM and APA services.
For more information, please visit www.marketaxess.com.
With the acquisition of RegS, MarketAxess is strengthening both our global post-trade and data businesses in two important ways: significantly extending our European client footprint, and increasing our ability to bring new, innovative technologies and solutions to a critical and complex part of the trade lifecycle. It underlines our long-term commitment to investing in post-trade and regulatory reporting services in Europe.
8
The further enhancement of our post-trade business is important to MarketAxess as we look to extend the front-to-back, full trade-lifecycle services we offer clients. MarketAxess is committed to building a stronger regulatory landscape across Europe. With new regulations coming fast (SFTR recently, CSDR) it is imperative that firms can be confident that their regulatory reporting provider is fully committed to supporting their needs in the long term.
3.3 Meet the MarketAxess team
Your successful transition to MarketAxess is a priority for us. The leaders of the MarketAxess Post-Trade business will be heavily involved in your migration plan, and in ensuring your satisfaction as a client. They are:
• Chris Smith, Head of MarketAxess Post-Trade and a member of the management team for Europe and Asia. In his role, Mr. Smith is responsible for the development and delivery of all MarketAxess Post-Trade services, including regulatory reporting and trade matching.
Before joining MarketAxess in 2014, Chris developed the first commercial post MiFID dark pool, Euro Millennium, at NYFIX, which was later purchased by NYSE Euronext in 2009. After the acquisition by NYSE Euronext, he became Head of Hosted Commercial Markets. Before working for NYFIX and NYSE Euronext, he was responsible for European post-trade STP services with TradeWeb, building the first electronic confirmation method for Interest Rate Swaps. Previously, Chris held various operational management roles with Thomson Reuters and founded the Electronic Trade Confirmation (ETC) initiative with Fidelity Investments in the early 1990’s.
• Geoffroy Vander Linden, MarketAxess Country Head in the Netherlands, looks after MarketAxess’ MTF, EU trading and reporting businesses based in Amsterdam, providing services to Continental Europe. Geoffroy is responsible for the management of business support functions, all operational aspects of the country such as client services, and for growing the business in the region. Prior to moving to the Netherlands, Geoffroy developed MarketAxess’ transparency and APA solutions under MiFID II.
Before joining MarketAxess, Geoffroy spent over 10 years with Euroclear where he held a number of roles including Product Manager for liquidity management and clearing services.
As an active leader in the industry, Geoffroy serves as co-chair of multiple FIX sub-groups and is a member of ESMA Consultative Working Group.
On a day to day basis, you will be supported by our client-facing teams:
• Our Client Services team will be your go-to contacts with regard to all technical questions from onboarding to incident management
• The Relationship Management team will be your liaison in all business considerations and a trusted partner in all matters regulatory reporting
Further detail on your interaction with the above teams can be found in the sections Service and Support Model During Business Transition and Service and Support Model Post-Migration.
9
3.4 Timeline
The business will transition throughout 2021 and you will migrate onto MarketAxess systems by year-end. We are committed to migrate each firm in its entirety onto our systems, meaning that we plan to migrate a firm only once all their services can be migrated.
The below sequencing indicates the earliest you can migrate based on the bundle of services you are using today. We will work with you to develop individual client migration plans that accommodate your input.
Figure 2: Timeline
The Migration section outlines our initial proposal of migration sequencing.
Starting in the preparation phase, and throughout the transition phase during 2021, we are appraising impacted regulators of our plans and progress.
10
4 BUSINESS TRANSITION
4.1 Legal Considerations
MarketAxess is acquiring the business of RegS by way of a share acquisition. The business to be purchased by Trax NL consists of client contracts and obligations to provide the existing services to those clients. Following the closing of the acquisition and subsequent merger of RegS into Trax NL the existing contracts will be acquired and Trax NL. shall step into the shoes of RegS from a contractual perspective.
There will be no need for negotiations and the existing contracts will remain in place without any changes. There is no need to sign any new agreements with MarketAxess unless you require a new service which is not offered by RegS, such as when a client is required to report to the FCA post-Brexit, in which case it will need to sign new terms with Trax UK.
There are no anticipated changes in prices under your existing contractual terms.
4.2 Service Delivery During Business Transition
MarketAxess and DBG will partner during the 2021 transition period, to support continuous compliance with your regulatory obligations.
Until your firm migrates onto MarketAxess systems, MarketAxess will be using the existing DBG technology to fulfil your reporting requirements. With regard to APA, DBG will route your data to MarketAxess for publication.
4.3 Service and Support Model During Business Transition
The same level of support already provided by RegS will be offered during the transition period in 2021. Gradually, post-closing and upon commencement of the migration, clients will be introduced to the MarketAxess Client Services and Relationship Management teams who will assist them during and after the migration.
Our client teams are working together to support your day-to-day reporting operations during the transition period. Your new partner for all service requests is the MarketAxess Client Services team, and they will be supported by the DBG Client Services team as required.
11
Figure 3: Joint Client Services model during transition period
Where required, local language support in German, French or English will continue to be provided.
5 MIGRATION
5.1 Migration planning
We realise that migrating onto new systems may appear a complex task, but please be assured that both MarketAxess and DBG have performed careful planning in order to deliver a successful migration with your partnership. MarketAxess has experience with the transition from other Service Providers to our Post-Trade services. We have built open and adaptive technologies that minimize disruption to the client and we will be able to maintain lifecycle integrity.
We are looking forward to optimizing your individual pathway taking into account your services and scheduling requirements, and working towards the below objectives:
• Continuity of reporting and minimal service impact for clients
• Smooth transition and distribution of clients over the next 12 months
• Completion of migration by year-end 2021
We are committed to migrate each firm in its entirety onto our systems, meaning that we plan to migrate a firm only once all their services can be migrated. We have conducted an extensive analysis of RegS services offered along with your service subscriptions using the data that is available to us today. Based on our analysis, the initial migration phasing proposed below sets out how clients will be invited to migrate related to a number of criteria such as the number of services which each firm uses at DBG, the various national regulators they report to, their connection methods and finally any service complexities.
12
Figure 4: Initial migration phasing
Each phase is linked to our planned technology releases, which we will further detail throughout next year. Initially, and in accordance with our overall Timeline we have planned the phases as follows:
• Migration Phase 1 (estimated from Feb 2021): We will invite clients to migrate who use just ARM and/or APA services, and who have reporting obligations to NCAs to which we have established connectivity.
• Migration Phase 2 (estimated from May 2021): We will invite clients who use ARM and/or APA as well as Best Execution (BestEx) and/or Systematic Internaliser (SI) services in addition to Phase 1 clients who have not yet migrated. We will also have established connectivity to additional NCAs by then.
• Migration Phase 3 (estimated from August 2021): This phase involves clients who use Commodity Position Reporting (CPR) and/or EMIR in addition to the Phase 1 and Phase 2 services in addition to those clients who have not yet migrated.
• As required, we will continue to migrate clients and plan to complete migration in the week commencing 22nd November 2021 at the latest
In the above chart, you will recognize the names of the typical MiFID and EMIR reporting services running along the horizontal axis of the diagram. Running vertically are some service deliverables which, once implemented by MarketAxess unlock further waves of migrations.
One driver of service complexity is NCA connectivity. MarketAxess is already expanding their NCA connectivity and will continue to do so throughout the migration phases in 2021. This will ensure that all NCAs that former RegS clients are currently using will be provided going forward. The below table shows the NCAs that are in scope for migration per phase:
13
Connectivity timeline NCA
In scope for Phase 1 DE-BaFin, DK-Finanstilsynet, FI-Finanssivalvonta, FR-AMF, GB-FCA, HU-MNB, IE-Central Bank Of Ireland, IT-CONSOB, LU-CSSF, MT-MFSA, NL-AFM, NO-Finanstilsynet, SE-FI
In scope for Phase 2 AT-FMA, BE-FSMA, CZ-CNB, GI-GFSC, HR-HANFA, LI-FMA, PL-KNF, RO-ASF, SK-NBS
In scope for Phase 3 BG-FSC, PT-CMVM, SI-ATVP
Table 1: NCA Connectivity Timeline
The remaining phasing criteria are technical connectivity, which is detailed in the section Technical Connectivity, and service model specifics, such as custom reports. Of the latter, nothing of note has surfaced up until now. Our consultations with you will be the opportunity to explore these specifics.
We are conscious that our initial analysis might be subject to change once syndicated with all clients, and we will work with you to schedule your migration based on your availability and according to your eligible phase.
We will equip you with support and materials relevant to your migration and service continuity. Please also expect further communication, webinars, updates to the FAQ and direct meetings.
5.2 Service delivery after migration
A significant positive factor of the RegS to MarketAxess merger is how complimentary our services are, and our intention is that all currently contracted services will continue to operate as similar as possible to how they operate now.
The below table overlays all MiFID and EMIR services offered and the green checks show where our services match, and it is evident that there is not any significant build required by MarketAxess to meet your regulatory reporting requirements. Even CPR, which we did offer clients in the past, is not a new build but can be re-released.
14
Figure 5: Comparison of service offering
In practice, the experience gained migrating firms from their legacy MiFID/EMIR reporting services onto MarketAxess is that data fields in reports can differ in number and in content. And therefore, can require some adaptation and change.
Granted all regulatory data fields required by ESMA must naturally be consistent and present, the differences actually lie in the fields related to file names and extra fields which support value added services such as for example ISIN search.
Both Deutsche Börse Group and MarketAxess are conducting an in-depth analysis of existing services, including additional services such as data enrichment. We have identified some minor gaps and are working to close them. Where possible, data conversion (through a format converter) will be provided so that no build on your part will be required. With the exception of temporary Brexit arrangements, data conversion will be a permanent solution. If a client wishes they may connect directly in the MarketAxess format.
Further information on the services offered by MarketAxess can be found under https://www.marketaxess.com/post-trade/resources. During the course of the migration, a full demonstration and overview of service functionality will be provided. As we align our services with Deutsche Börse Group, the exact file specifications and service descriptions might evolve to take into account new requirements.
Similar to RegS, MarketAxess provides assisted reporting capabilities – its clients can report on behalf of underlying clients where required and have the option to provide their clients with access to the MarketAxess dashboard (GUI).
Beyond RegS's offering, MarketAxess offers SFTR reporting and a UTI sharing solution.
15
5.3 Description of migrated services
5.3.1 ARM
Similarities in general functionality: With regard to general functionality and similar to former RegS, we will provide transaction lifecycle handling from collection of transaction data via SFTP, manual entry or dashboard (GUI) upload to ARM/NCA feedback and reconciliation including extensive validation executed as per ESMA rules and with additional warnings, party reference data upload and a comprehensive and detailed audit trail. We also perform eligibility checks to ensure the transactions are within the scope of the regulation.
Differences in general functionality: We provide data enrichment with OTC post-trade data (APA) and new instrument reference data enrichment capabilities (ISIN lookup service via interface to the ANNA DSB and enrichment of reference data fields 42-56 based on ISIN), but we will not enrich data from DBG venues. If you have been using venue enrichment in your operations, you might need to assess the impact of this change on your operations and we stand ready to discuss the implications on your business and ways forward. MarketAxess offers a three-way managed reconciliation service.
Submission: We will create the capability to support your current submission formats, which we will convert internally. If you wish, you can also adapt to our existing submission format. Nevertheless, there will be changes to the response file format for clients and MarketAxess error codes and status’ will not be translated to former RegS equivalents.
Dashboard (GUI): Our service delivery will be supported by a dashboard with a different look and feel, including an enhanced end-of-day status reporting capabilities and an improved Assisted Reporting dashboard. In addition, you will be able to leverage regulatory business intelligence which we provideall our clients. A process that we do not currently support is four eyes authorization.
European Data Store (EDS): If clients choose to set up a tokenized solution, it is a pre-requisite before submitting any report to submit the relevant natural person data into the EDS either via HTTPS entry or SFTP upload. More detail can be found in the section Data storage and processing. If clients choose not to use the tokenized solution, then all of their data, including all personal data, will be processed in the primary data centres.
Relevant documentation
• MarketAxess ARM – Dashboard (GUI) User Guide
• MarketAxess ARM – Creating User Profiles as an Administrator
• ARM specifications — MarketAxess ARM – CSV File Specification Post Trade Technical Specification CSV File Format — MarketAxess ARM – XML File Specification Post Trade Technical Specification XML File Format
• MarketAxess ARM – ISIN Lookup Specification
16
5.3.2 APA
Similarities in general functionality: We provide both pre- and post-trade transparency services as well as Portfolio Compression reporting. We provide reporting obligation check (with the capability to handle package transactions), reporting responsibility instrument scope checks (ToTV) including outside of transparency scope checks (OOTS), calculation of deferrals for trades and waivers on quotes, assisted reporting, price & volume validation (with differences in calculation methodology to DBG),
Differences in general functionality: We leverage a different reference data provider to DBG, which might result in slight differences in asset classification and ToTV assessment results.
Submission: We will be able to provide data conversion for clients using XML over MQ, so you can continue to use your current submission formats, which we will convert internally. We will not provide data conversion for clients using FIX – we kindly ask you to build to our existing schema. In addition, we will support Portfolio Compression via CSV, but not via FIX. There will be changes to the response file format for clients and MarketAxess error codes and status’ will not be translated to former RegS equivalents.
Dashboard (GUI): Our service delivery will be supported by a dashboard with a different look and feel, including an improved Assisted Reporting dashboard.
Relevant documentation
• MarketAxess APA – Dashboard (GUI) user guide
• MarketAxess APA – Creating User Profiles as an Administrator
• APA specifications — MarketAxess APA – Trade Reporting FIX Specification — MarketAxess APA – Trade Reporting CSV Upload Specification — MarketAxess APA – Quote Reporting FIX Specification
• MarketAxess APA – Instrument Concatenation Support for Trade Reporting
5.3.3 BEST EXECUTION – QUALITY OF EXECUTION (RTS 27)
Similarities in general functionality: We will enhance the functionality of our existing QoE service by using near-time data from quotes in addition to that from trades. Using this data, we will replicate the former RegS functionality of calculating all nine tables except the cost table (table 5). Our output reports will be provided in former RegS XML format so clients can ingest these.
Submission: Calculation of most tables is conducted with near time trade and quote data submitted via the OTC Trade Reporting and SI Quote Publication service. Clients have the ability to indicate whether they were a Liquidity Provider using an optional APA custom field (Aggressor Indicator). Similar to former RegS, we would require quarterly upload of clients’ CSV to complete the cost table (table 5).
Output reports: We will provide output reports via CSV or XML rather than via a GUI. We also offer the option to automatically publish reports.
17
5.3.4 BEST EXECUTION – TOP 5 VENUE REPORT (RTS 28)
Similarities in general functionality: Data is typically calculated using ARM transaction reports. Our output reports will be provided in former RegS XML format so clients can ingest these.
Submission: Data is sourced from data submitted to the ARM with five additional fields provided by the client specifically for the Top 5 service (passive/aggressive, directed order, client type, order type, broker trading capacity). In addition to using ARM transaction reports, we also support a standalone CSV input format.
Output reports: We also offer the option to automatically publish reports. We will provide output reports via CSV or XML rather than via a GUI. We also output indicative reports throughout the year as well as the final publication at the end of the year.
5.3.5 SYSTEMATIC INTERNALIZER (SI) IDENTIFICATION
Similarities in general functionality: Our SI Identification service offers the entire scope of the RegS solution (TOTV check, TOAX check, liquidity status, currency conversion, technical validations).
Differences in general functionality: We do not require clients to report a TOAX flag in APA, as we will calculate this automatically based on transaction reporting data. The indicative output reports we provide use actual market data from current period rather than previous period’s ESMA data. Our SI Identification report includes data relating to the SI Relevance report and will differ slightly in format. We submit only one CSV SI Report, however it covers all the same information RegS provides today.
Submission: We will be using just ARM transaction data – enrichment by TOAX flag reported in related trades via the OTC Trade Reporting (APA) will no longer be necessary. Alternatively, we support a standalone input format.
Relevant documentation
• MarketAxess SI Identification - CSV Specification
5.3.6 SYSTEMATIC INTERNALIZER (SI) REFERENCE DATA REPORTING (RTS 23)
Similarities in general functionality: MarketAxess supports the reporting of instrument reference data to NCAs across Europe. The reference data needed to report will be enriched from reference data sourced by MarketAxess across all instruments in scope of MiFID II.
Differences in general functionality: The instrument reference data report is triggered by the submission of an XML file containing the instruments the SI or Trading Venue wishes to report alongside a few venue specific fields. Based on the ISIN the remaining reference data attributes can then be enriched and/or validated before the report is onward reported to the relevant NCA.
GUI: Our service delivery will not be supported by a dashboard (GUI), however, feedback files are provided with all the relevant status updates which clients can ingest.
Submission: We use a standalone instrument reference data submission format based on the ESMA standard.
18
Relevant documentation
• MarketAxess SI Reference Data Reporting (RTS 23) – Specification
5.3.7 COMMODITY POSITION REPORTING (CPR, ART. 58)
Similarities in general functionality: We provided this service to clients in the past but had discontinued due to a lack of client demand. Before migrating your services, we will rebuild and recommission the service under the standards you are currently provided from RegS.
Differences in general functionality: In contrast to RegS current offering, we plan to fully cover assisted reporting – not only in exceptional cases – and we will provide a dashboard (GUI).
Submission: MarketAxess will implement CPR offering leveraging RegS’s submission format to all end points.
5.3.8 EMIR REPORTING
Similarities in general functionality: We will provide transaction lifecycle handling, file and transaction validation using ESMA and Regis-TR validation rules, TR connectivity to Regis-TR and DTCC, TR response and reports ingress, record lifecycle creation via GUI, reporting health situation dashboard, file and recording status and reporting audits.
Differences in general functionality: Matching and pairing reports will be integrated into the dashboard (GUI). We will not be able to offer the TREMIR enrichment/mapping service, which uses DBG venue data.
Submission: We will create the capability to support your current RegS submission formats, which we will convert internally. If you wish, you can also adapt to our existing submission format. Nevertheless, MarketAxess status’ and error codes will not be converted to RegS format.
5.4 Step-by-step migration lifecycle
You can lay the groundwork for migration once a formal introduction to the MarketAxess Relationship Management Team has taken place.
Shortly thereafter, you can access the profile we have created for you on our CRM-system as a first step to migration. There, clients can review their onboarding details per service. These will be pre-completed, and clients should fill any gaps or correct any errors.
Once we have notified you that your phase is eligible for migration, you will find in this section the end-to-end steps to migrate all your services onto our systems at the same time.
Your Relationship Management Team will be your point of contact to oversee your migration lifecycle. Based on significant experience, we would expect your firm to also appoint a project manager to coordinate activities and resources on its behalf.
The impacted functions for this project are the following: Operations, Technology, Program Management, Compliance/Legal, Procurement. It is prudent to seek input from each of these functions at the appropriate time in the migration lifecycle.
19
In general, the migration lifecycle consists of the following steps: aligning on the timeline, establishing technical connectivity, analysing data requirements, developing data submission solutions, training and testing, and finally cutover. For more complex migration, additional steps might be required.
5.4.1 TIMELINE
We will keep an overall migration schedule so that we can coordinate across all clients in a given phase. This will ensure that both sides can deploy resources to support the individual desired migration path.
No matter when your phase begins, all clients must have cut over by the week commencing 22nd November 2021 at the latest.
Based on the steps required to migrate onto our systems, firms should notify MarketAxess at least six to eight weeks1 ahead of their desired cutover date.
Each of the remaining sections should be fully delivered and signed off prior to cutover. Firms should schedule appropriate clarification meetings with MarketAxess on each of the relevant sections below.
1 This timeframe represents a simple migration. The timeframe for clients using several services will be longer.
20
5.4.2 DATA ANALYSIS AND SUBMISSION
Objectives for this project phase
• Ensure clients have all the information needed to start analysis
• Where clients need to build to an MarketAxess file specification, clients need to understand the file flow and the message formats to submit data to MarketAxess
• Where MarketAxess is building a converter for a particular service, clients will need to assess any small changes in the end-to-end process
• Ensure clients can generate data extracts required for each relevant MarketAxess service
• Clients to determine whether they leverage MarketAxess EDS solution for ARM reporting, details on which can be found in the European Data Store (EDS) section
Non-converted services (APA over FIX)
For services where clients must build to the MarketAxess specification, we will provide documentation and assistance to help you modify your existing DBG file format into the required MarketAxess file format.
For example, for APA reporting via FIX, we are performing a detailed business analysis between the DBG and MarketAxess FIX specification documents and will capture in a delta document the key differences. We will make this kind of document available to you and you can ask to review it with us, should you require.
Clients can then leverage these delta documents to perform the required field level changes so that their data files will be accepted by MarketAxess systems.
Converted services (e.g. ARM, EMIR, SI and Best Execution services)
For most migrated services we will build a data conversion application on the MarketAxess side so that we can accept a legacy data format without your firm having to undertake changes. With the exception of temporary Brexit arrangements, these applications will be a permanent solution. If a client wishes they may connect directly in the MarketAxess format.
Nevertheless, there will likely be some changes to the response file format for clients and not all MarketAxess error codes and status’ will be translated to RegS equivalents.
For all migrated services, we strongly suggest clients perform user acceptance testing before they cut over. This is covered in the Training and Testing section. In the following are the more detailed migration steps to ensure your data reaches MarketAxess in the correct format and is accepted by our systems. Specifications for all MarketAxess services are on our public internet resources site. Note that the below displays the latest information. Details are continuing to take shape as we approach migration.
21
Client activities
Service Process / functionality differences DBG / MarketAxess
Migration activity
APA FIX • No data conversion for clients using FIX
• Build to MarketAxess FIX format, using specification and delta docs
APA • Price & volume checks
• Reference Data
• Reference Data Return Service
• Be prepared operationally for some differences in processing outcomes.
EDS • MarketAxess proprietary solution to help firms securely manage their Natural Person Data
• Obtain your firm’s EDS administrator system credentials from MarketAxess
• Create EDS profiles for all traders and decision makers within your MiFID legal entity
• Please see section European Data Store (EDS) for details
ARM • MarketAxess will not enrich data
from DBG venues
• Response message format changes
• Assess the impact of this change on your operations
• Assess any technical implications of response format changes.
BestEx – QoE and Top5
• Output reports via CSV or XML rather than via a GUI
• We also offer the option to automatically publish reports
• Analyse how best to consume these reports
SI services • Output formats for SI Identification and Relevance reports might differ
• Analyse how best to consume these reports
CPR • Exact difference TBC • Service familiarization
EMIR • MarketAxess will not be able to offer TREMIR enrichment/mapping service using DBG venue data
• Not all MarketAxess status’ and error codes will be converted to RegS format
• Matching and pairing reports will be integrated into the GUI
• Response message format changes
• Supply MarketAxess with all relevant trade, collateral and valuation messages
• Assess any technical implications of response format changes.
22
5.4.3 TECHNICAL CONNECTIVITY
Objectives for this project phase
• Understand connectivity options based on firm’s current arrangements
• Engage with MarketAxess technical onboarding team for required steps
• Agree key milestones and dates
• Outputs: client Test and Production credentials, dashboard/GUI access via client IP whitelisting
The majority of MarketAxess clients connect over the internet via SFTP for ARM services or SSL/TLS-encrypted FIX for APA services and our initial position is that this would be the connectivity approach of choice for most of you who are connecting to DBG either via the internet or VPN.
From recent migration we have developed a proven and rapid process for client connectivity. Onboarding for connectivity over the internet involves mainly the white-listing of IP addresses and the sharing of your client credentials. Once this is complete, we can very often stand up a test environment in as little as 48 hours.
We also offer leased lines which firms currently use for their FIX-enabled APA reporting. There is no change in the near term for firms connecting via this method because DBG can serve as a connectivity service provider for the next 2-3 years (2022-2023). Before the end of that period, you will need to migrate to MarketAxess-supported extranet providers and connect to MarketAxess through them. If clients wish, they can engage with our supported extranet providers from day one.
Figure 6: Connectivity options and expected pathways
23
Connectivity process
MarketAxess provides two environments for all our regulatory services: User Acceptance Testing (UAT) and Production. Clients are first onboarded onto UAT. Once we have your firm’s complete initiation details (firm name, key person contact details, public IP addresses), our onboarding team will use these details to grant you access to our URL-delivered dashboard/GUI and your inbound/outbound SFTP-folders/FIX sessions.
Once you have connectivity to us, firms can opt for a straight-through machine-to-machine file delivery method.
Firms wishing to connect via a leased line should engage with our Infrastructure Support team as soon as possible due to the anticipated lead times of such a connection.
If you are already a MarketAxess customer, please reach out to our Infrastructure team to move the traffic across to your existing connectivity model.
Documentation provided
• MarketAxess APA – Connectivity Guide
5.4.4 TRAINING AND TESTING
Objectives for this project phase
• Familiarization with our solution for all client user roles
• Create and fulfil your test plan so that your firm achieves readiness to cutover
• Complete GUI profile (permissions, credentials) setup for all firm users
Training
Prior to testing, all users at your firm should be familiarized with MarketAxess’ reporting platform. To support this, we offer pre-prepared videos by subject and can also offer live video-enabled training.
In the weeks leading up to your migration onto MarketAxess systems, typically your operations control teams will require follow-up training. Please assess your needs and follow up with our Relationship Management team on that.
MarketAxess will create system administrators at each firm. It is the duty of these administrators to create relevant user profiles and add staff.
Documentation provided
• MarketAxess ARM – Creating User Profiles as an Administrator
• MarketAxess APA – Creating User Profiles as an Administrator
• MarketAxess EDS – Creating an Upload Account
24
Testing
MarketAxess provides two environments for all our regulatory services: User Acceptance Testing (UAT) and Production. The setup of the two environments is very similar, however, clients should bear in mind some key differences.
• Instrument (ISIN) data exists in UAT, but might not be as fresh as in Production with respect to ISIN completeness and eligibility (ToTV) status
• UAT is not set up to accommodate similar volume throughput as our Production environment, therefore clients should advise MarketAxess prior to conducting load testing in UAT
• Please note that not all NCAs provide UAT environments and our UAT environment is currently connected to the UK FCA only
• MarketAxess reserves every Wednesday afternoon between midday and 1800 CET for scheduled maintenance releases. During this time clients can still submit transactions, but they will be queued for processing until the service is restored
As MarketAxess will build data conversion adapters for data in, but not for data out, firms might need to adapt their reporting processes to consume both ARM and NCA response files.
Business Testing Approach and Scenarios
It is recommended that clients design and implement an end-to-end completeness and accuracy testing framework as a key step to migration readiness.
The industry has provided some resources in order to help you with your testing approach. Among others, this is provided in the following documents:
• ESMA has defined some ARM best practice reporting guidance to help you assess your expected results
• The Fix Trading Community provided guidance on implementing the requirements for post trade transparency
• AFME has published MiFID II / MiFIR post-trade reporting requirements – Understanding bank and investor obligations
5.4.5 CUTOVER
Milestones before cutover
• Client to agree a cutover date with the Relationship Management team
• Client to confirm their migration cutover criteria are met 1. Testing exit criteria have been met 2. Each required service is live in client’s production environment, e.g. technical connectivity with
MarketAxess and data submission process 3. Connectivity is established to all relevant Regulators and Trade Repositories for EMIR 4. Day 1 operational readiness
25
• Ensure go-live when you are eligible, but no later than week commencing 22nd November 2021
• Client to familiarize with post-migration service and support model — Day-to-day client requests to be handled by Post-Trade Client Services team — Escalation via Relationship Management team — Further details in section Service and Support Model Post-Migration
26
6 DATA STORAGE AND PROCESSING
6.1 Security Principles Trax NL and Trax UK are both approved as providers of ARM and APA services through the AFM and the FCA, respectively.
In performing these services, MarketAxess acts upon the instructions of its clients to enable them to comply with their own regulatory obligations. This means that MarketAxess is acting as a data processor on behalf of its clients, who act as data controllers for the purposes of the General Data Protection Regulation (GDPR).
MarketAxess has built its solutions to ensure client data, including Natural Person Data (NPD) for MiFID II Transaction Reporting, is secure and has safeguards in place to fully comply with regulatory requirements. Our security principles address these obligations:
Table 2: Security principles
MarketAxess has for several years used systems and data centres in the U.S. to perform services for clients. Our European client base has historically been comfortable with this activity and the security measures we have in place to underpin it.
Due to new data sensitivities introduced from 2018, we have created a private cloud based European Data Store (EDS) hosted in Germany and Ireland for the storage of NPD provided by clients in connection with MarketAxess Report services.
Clients may choose whether or not to use the EDS to store NPD. If clients opt to use the EDS, then the underlying personal data of the relevant individuals (the NPD) will be stored in the EU. Where firms choose not to use the EDS, then all data elements, including personal data, will be processed and stored in our data centres in the U.S.
27
6.2 European Data Store (EDS) Since MiFID II RTS 22 transaction reporting began in January 2018 MarketAxess offers a solution to help firms securely manage their Natural Person Data that ESMA requires in fields 57, 59 – Execution Trader and Investment Decision maker, and the Buyer and Seller blocks, where they are natural persons.
As a result of ESMA demanding that these fields contain natural person data such as Passport numbers, Tax codes or National ID Card # or a Contact, MarketAxess built a secure process to help firms manage the collection, maintenance and reporting.
The process involves firms creating records for each trader and investment decision maker in our European data Store (EDS) system. The system gives the firm a non-identifiable “token” for each personal record which the firm then sends in the report to MarketAxess’ ARM. By using a pseudonym in place of the actual personal date this can lower the information security risk on the firm’s side.
Figure 7: Simplified data flows and data process
Following the process visualized above, once we at MarketAxess receive the token in your normal RTS 22 report, we use it to look up the appropriate values from your firm’s records in the EDS. We replace the token with the corresponding natural person data and our ARM sends your file to the regulator via a secure channel.
If you are interested in a more detailed description of data flows and data process, please refer to the figure below.
28
Figure 8: Comprehensive data flows and data process
To support clients in using the EDS, we have compiled the below information, which covers initial setup, implications for your transaction reporting, NCA reporting and your use of our MarketAxess dashboard (GUI).
Figure 9: EDS usage instructions
29
Documentation provided
• MarketAxess EDS – Creating an Upload Account
• MarketAxess EDS – Creating Trader Tokens
• MarketAxess EDS – Creating Fund Tokens
6.3 The Virtual Private Cloud The European Data Store (EDS) was built to enable MarketAxess to utilize its state-of-the-art US data centres whilst also complying with GDPR and other EU regulations.
This involves leveraging the Amazon Web Services (AWS) data centres in Dublin and Frankfurt, as an IaaS Virtual Private Cloud – not as a Public Cloud.
As such, the private cloud model means all MarketAxess security infrastructure (e.g. F5 LoadBalancers) and vendor software (e.g. Oracle) is replicated in AWS as an extension of the MarketAxess corporate network. The same security principles apply across the EDS and MarketAxess primary data centres.
6.4 Network security MarketAxess, as a global service provider, goes to great lengths to establish network security. A suite of controls is in place, including
• For our US data centres: IP Whitelisting and 24x7 managed Security Operations Centre (SOC) monitoring on all external connections
• For the EDS: IP Whitelisting along with Web Application Firewalls (WAF) controls. Within the virtual private cloud, MarketAxess has full control over its network security arrangements
• Traffic between the US data centres and the EDS via an encrypted VPN (virtual private network)
• Intrusion-Detection-System / Intrusion-Prevention-System enabled on externally facing firewalls
• IP blacklisting implemented for known malicious IPs
• Usage of Distributed Denial of Service (DDoS) Protection for our internet connections
30
6.5 Encryption and Key Management We are using Key exchange/management solutions provided by industry leading suppliers to aid management and configuration of all security keys.
Figure 10: Our Approach to Encription and Key Management
Technical Whitepapers on the Encryption Infrastructure are available:
• Ciphertrust manager
• Transparent encryption
• Application data protection
31
7 BUSINESS AS USUAL OPERATING MODEL
7.1 Service and Support Model Post-Migration
MarketAxess operates a 24 x 7 ITIL derived service model from its offices in London and Amsterdam comprising Post-Trade Client Services (PTCS), 2nd and 3rd Line Technical Teams. The technical teams are complemented by Post-Trade Relationship Management (PTRM) teams.
Figure 11: MarketAxess Service and support model
Roles and Responsibilities
• Document, triage and where possible resolve cases raised by clients
• Participate in Major Incident process where required
• Manage the post sales client onboarding process
• Participate in client-facing engagements where required, such as conference calls and service reviews
Contact Method
Clients may raise cases by either telephone (+44 203 655 3440) or email ([email protected]).
Maintenance Windows
• Production – MarketAxess reserves every Saturday morning between midnight and midday for scheduled maintenance releases, however, may not make use of every window. If a window is to be utilized a notification will be sent to all impacted clients no less than 5 working days prior. During this time clients can still submit transactions, but they will be queued for processing until the service is restored.
32
• UAT – MarketAxess reserves every Wednesday afternoon between midday and 1800 CET for scheduled maintenance releases. During this time clients can still submit transactions, but they will be queued for processing until the service is restored.
7.2 Generic Client Operating Model
Adapt existing Operational Model including BAU elements, such as how often you send us data files, where the MarketAxess dashboard is embedded in your process, and your firm’s approach to correcting any rejection messages.
Adapt your existing Control Framework taking into account the functionality of the MarketAxess dashboard, transaction search and KRI/KPI metrics.
MarketAxess dashboard
Our dashboard features a customisable, web-based operational service to help clients manage and monitor the status of your reporting and matching activity through a single interface. Clients can quickly identify exceptions and data quality issues as well as view industry leading analytics and peer benchmarking reports.
Figure 12: MarketAxess dashboard
The user-interface also enables firms to be able to correct transaction reports. This can be done by:
• Uploading a CSV file into the “File upload” area of the dashboard, or
• Manually keying in the details of the transaction report
Transaction reports also include sensitive natural person data (NPD) which firms are able to restrict access to. The firm’s administrator is able to control which specific individuals within that firm are able
33
to access this type of information. Individuals without permissions to see natural person data will see the data as restricted as per the screenshot below.
Figure 13: MarketAxess dashboard – masking of NPD data
The user interface also enables firms to manage their natural person data. This can be accessed by clicking on the relevant menu tab at the top of the screen. Note that only individuals who have been assigned the relevant privileges by the firm’s administrator will be able to access this section of the dashboard.
34
Figure 14: MarketAxess dashboard – NPD maintenance
Firms can assess their own training needs, and if there is any functionality they would like to see in further detail, please reach out to Post-Trade Client Services.
7.3 Client Forums and Working Groups
Given the detailed and everchanging nature of European regulation, MarketAxess hosts regular client-wide forums, where reporting firms come together to discuss key themes such as recent changes to specific reporting guidance, upcoming ESMA consultations, and Regulatory focus on data quality, etc.
MarketAxess maintains close relationships with national Regulators to try and stay abreast of their market oversight agenda.
Where themes are buy-side or sell-side specific, MarketAxess sometimes may convene smaller working groups to discuss these topics in more detail.
7.4 Risk Management
Enterprise Risk and Resilience Framework
MarketAxess operates a comprehensive Enterprise Risk and Resilience Framework (“ERRF”) through which its risks and business services are identified, assessed, monitored and controlled.
Risk and Resilience management plays a crucial role in support of our financial performance and operational stability. The Group has structured its Risk and Resilience activities across the Three Lines of Defence model. Under this model responsibilities and accountabilities for risk management and compliance reside with the appropriate departments that undertake the day-to-day activities, with appropriate policies, checks and controls implemented by independent functions. If further
35
distinguishes between functions that own and manage risk, functions that oversee risk and functions providing independent assurance
The ERRF is designed to meet the MarketAxess’ risk and resilience management obligations. It includes:
1. The Governance processes and mechanisms, by which decisions are made, actions are delegated, and accountability is enforced.
2. The Risk and Resilience Practices that identify, measure, manage monitor and report risk and resilience effectively.
3. The Risk Language that the Group uses consistently to identify and assess risks, to develop risk policies and facilitate risk aggregation and reporting.
4. The Culture, Behaviours and Values that the Group promotes to encourage transparency, honesty and integrity.
Risk Department
As part of the second line of defence, the Risk department is an integral part of the entire management and control governance system. The system incorporates the identification, assessment, management, monitoring and reporting of risks. The ability to effectively manage risk is important for ensuring that the organisation is operating in a manner consistent with the ‘Board’s expectations.
The Risk function provides support by:
• Exerting independent oversight of the Firm’s adherence with risk management policies and procedures,
• Providing the Group with risk management advice and expertise,
• Monitoring a number of qualitative and quantitative measures to ensure that the businesses risks remain within acceptable levels. Using these measures, MarketAxess produce a number of risk intelligence reports which are disseminated through the governance structures at all levels as appropriate to provide an independent view of risk exposures.
Business Continuity Management
MarketAxess has developed a Business Continuity Management (“BCM”) program to prepare the organisation for crisis situations that could jeopardise MarketAxess’ core mission and its long-term viability. The primary goal of the BCM program is to enable the organisation to ensure personnel safety and restore critical business processes. Strategies have been developed including plans and actions that provide protection or alternative modes of operations for those business processes which, if they were to be interrupted, might otherwise bring about a seriously damaging or potentially fatal loss to the organisation and its clients.
36
8 MARKETAXESS SYSTEMS AND ARCHITECTURE
8.1 Technology Platform
8.1.1 PLATFORM OVERVIEW
The Post Trade Platform is architected as a proprietary 3-Tier application:
1. The Data Storage tier is an Oracle Database, plus Elasticsearch fast-cache.
2. The Business Logic and Data Access tier services are written in Java 8, use Apache ACTIVEMQ, REST APIs, and run in Apache Camel containers
3. The Presentation tier uses the AngularJS JavaScript-based, open-source front-end web framework
8.1.2 DEEP DIVE: BUSINESS LOGIC AND DATA ACCESS TIER SERVICES
Post Trade Services Landscape
Figure 15: Post Trade Services Landscape
EDS SERVICE
This batch service was built in 2017/18.
Functionally:
• It manages Natural Person Data for Post Trade clients.
• It interacts via REST with other Post Trade Services.
• It is deployed in 1 FUSE node, in a MarketAxess Virtual Private Network in AWS Dublin and Frankfurt.
37
APA SERVICE
This real-time service was built in 2017/18.
Functionally:
• It facilitates pre-trade and post-trade transparency by publishing Quotes and Trades to both a public website and via a FIX feed.
• It accepts transactions via FIX, csv-files and UI-entry.
• It uses reference data from the sub-systems, SecDB and RefDB.
• It stores Quotes and Trades in the Post Trade DB running in the MarketAxess data centre.
• It is deployed in 4 FUSE nodes, running in the MarketAxess data centre.
ARM, EMIR AND CPR SERVICES
This batch service was built in 2017/18.
Functionally:
• It facilitates RTS22 Transaction Reporting, Commodity Position Reporting and EMIR Reporting to NCAs & Trade Repositories across EMEA.
• It accepts transactions via MQ(XML), SFTP(XML & csv-files) and UI-entry.
• It uses reference data from the sub-systems, SecDB and RefDB.
• It stores Transactions in the Post Trade DB running in the MarketAxess data centre.
• It is deployed in 4 FUSE nodes, running in the MarketAxess data centre.
RTS27/28 AND SI DETERMINATION SERVICE
This batch service was built in 2017/18.
Functionally:
• It facilitates RTS1, RTS2, RTS23, RTS27 and RTS28 Periodic and Best Execution Reporting, and SI Determination.
• It stores Reports in the Post Trade DB running in the MarketAxess data centre.
• It is deployed in 2 FUSE nodes, running in the MarketAxess data centre.
REFERENCE DATA SERVICE
This batch service was built in 2017/18.
Functionally:
• It serves data across MarketAxess functions from sources including ANNA DSB, Copp Clark, Thomson Reuters, GLIEF and ESMA.
• It stores Reference Data in the Post Trade DB, and replicates to the Trading Platform.
38
• It is deployed in 4 FUSE nodes, running in the MarketAxess data centre.
DASHBOARD/GUI SERVICE
This UI service was built in 2015/16.
Functionally:
• It implements Administration functions in the Post Trade UI, such as Login, Logoff, Password Reset.
• It stores config. data in the Post Trade DB.
• It is deployed in 2 FUSE nodes, running in the MarketAxess data centre.
Transport and Message Formats per Service (current state)
Service Transport Message Format
ARM SFTP/MQ CSV/XML
APA FIX/SFTP FIX/CSV
EMIR SFTP CSV
8.2 People
The Post Trade Technology team is made up of ~70 MarketAxess employees, plus ~30 consultants, most of whom are based in London, but also with support from colleagues in the US, Singapore and India (outsourced).
The team operates as 13 distinct SCRUM teams within an organisation model based on the Scaled Agile Framework (SAFe).
Each SCRUM team consists of Developers, QA Testers, a SCRUM Master, a Product Owner and a Product Manager.
The SCRUM teams are aided and assisted by the following additional teams:
• A Centre of Excellence (CoE) team for Platform Improvements
• A Production Support team with members in London, Singapore and New York
• A Client Connectivity team
• A UK-based IT Infrastructure team, with support from colleagues in NY and Asia
Tenure: The average MarketAxess tenure of the (employees) Post Trade Technology team is 6 years which speaks to the fact that the team has stability and maturity.
Institutional knowledge: The team works very closely with their colleagues in Client Services, Production Support, and Operations and this ensures that each member of the Technology team has a good understanding of the business context in which their software operates.
39
8.3 Software Development Life Cycle (SDLC)
MarketAxess is responsive to regulatory driven changes. In recent years MarketAxess has successfully adapted to MiFID II, EMIR and SFTR to note but a few changes. MarketAxess will always seek to provide as much notice to any client impacting change as possible.
The Post Trade Platform currently supports two planned releases every quarter, with off-cycle releases being only undertaken for major project releases or emergency bug-fixes (EBFs).
Before each release, each and every code change is taken through a cycle of Unit Test, Integration Test, Regression Test, Load Test, UAT and Client Test to ensure consistency and validity.
40
8.4 Summary of Activity
41
9 INVOICING & PAYMENT DETAILS
Post-closing (Nov 30, 2020), invoices will be issued by MarketAxess. You will continue to be invoiced according to your current contractual terms and in the same currency you are today.
MarketAxess runs a monthly finance cycle and bills clients in arrears. Please update relevant bank details by Dec 18, 2020 as follows:
• Beneficiary Bank Name: J.P. Morgan Bank Luxembourg S.A., 6 route de Treves, L-2633, Senningerberg, Luxembourg
• Beneficiary Bank SWIFT: CHASLULX
• Ultimate Beneficiary Name: Trax NL B.V.
• Ultimate Beneficiary Account: 7000049088
• Ultimate Beneficiary IBAN: LU460670007000049088
• Currency: EUR
• VAT Number: NL 857933735B01
10 COMMON IMPLEMENTATION QUESTIONS
Below we presented common implementation questions and answers based on our experience with firms like yours.
Set Up
Ref. Question Answer
1
You have set up the Administration account for me. How do I add other users?
See Section Training and Testing. Documentation provided includes
• MarketAxess ARM – Creating User Profiles as an Administrator
• MarketAxess APA – Creating User Profiles as an Administrator
• MarketAxess EDS – Creating an Upload Account
For any further information needs, please reach out to Post-Trade Client Services [email protected]
2
What Permissions should I be assigning to users? Where can I get an explanation of the implications of ticking each permissions box?
See question number 1 just above.
42
Planning
Ref. Question Answer
1
Where should I go to get answers to any questions that I have?
The Post-Trade Client Services (PTCS) and Relationship Management (PTRM) teams will be your central points of contact for MarketAxess Post Trade and will be able to get you answers to any questions you may have
2
Can you provide me with the information I need for my internal project reporting?
Yes, as part of your migration planning, we will ensure we have a common understanding of activities, and dates and agree how progress reporting and issues escalation should be managed
3
Do you have any formal tests that we need to pass before we can go live?
No, but we will agree the go-live criteria with you early in your migration plan so that we both understand what is required and, if necessary, can identify and address any gaps during the migration
4
Can the system be operated from several locations/Multi Legal entity capabilities?
Yes. The graphical user interface (GUI), our MarketAxess dashboard, is designed to enable clients to work in a geographically dispersed manner. Each user profile can be configured to allow access to the data of one or many legal entities.
5
Is remote diagnostic support available? Describe how it occurs, and any limitations you may have encountered in providing this service.
Yes. Limitations are usually in respect of remote security policies, in the instance that this is the case MarketAxess have utilised the Customer’s preferred remote access solution where possible.
6
Please describe the initial and ongoing training required/offered.
As part of the onboarding process MarketAxess will provide training through telephone, videoconference or in person (where possible). Throughout the life of the contract technical support and training is provided as part of the service.
43
Ref. Question Answer
7
What testing services will you provide? MarketAxess operates a test environment for each product that mirrors the functionality found in our production environments. This test environment is available to all clients and forms a key component of our onboarding a certification process.
Business as usual operation
Ref. Question Answer
1
Please provide details of your communications protocol in the event of any incident impacting us or our investors.
Client impacting incidents are notified to client via email, should a breach be in effect all available efforts will be made to engage the designated contacts by email and telephone.
2
After unscheduled service downtime, will you communicate the quantifiable impact (e.g. in terms of number of trades not reported) to the client and the regulator?
Yes.
3 Does the application integrate with mobile devices e.g. iPad, Blackberry, iPhone?
No.
4 Is there any integration with additional productivity tools (e.g. MS Office plug-ins)?
No.
5 Are you able to provide detailed bespoke monthly management information reports?
Yes, MI is provided both via the MarketAxess dashboard.
6
Can we meet our regulatory requirements to store / re-create historical reports across all specified regimes?
Yes. MarketAxess will store all versions of every report under each regime. All data is accessible through the GUI or via Client Services.
7 Does the system maintain an audit trail of transactions reported?
Yes, all activity is persisted at the database level.
8 Describe your ability to track changes/audit trail on historical data/reports
MarketAxess retains all previous versions of a submitted report, including those that may have been rejected.
Product Development / Changes / Defects
44
Ref. Question Answer
1 What is the process for requesting new features / bug fixes?
New features and bug fixes should be raised through the Client Services team or at client forums.
2
Does your solution support the use of automated test tools for regression testing? If so, list automation software used as examples.
This is not client facing functionality.
3
Do customers and user groups influence releases of the solution? Describe how.
It is by continual consultation with our customers that the solution has been developed into the rich platform that it is today.
Customers can recommend enhancements through any point of contact that they have within MarketAxess. The request will then be analysed and in most cases will be added to the product if it is a) technical possible and b) of benefit to the MarketAxess Post Trade community.
4
Describe how clients are sent new software versions including release notes.
Due to our MarketAxess dashboard (GUI) being web-based there is no requirement to install any software. When new features and fixes are introduced through our release cycle clients will receive a notification prior to the event and after detailing the release notes.
45
ARM
Ref. Question Answer
1
How can MarketAxess help me populate ISIN codes?
For OTC derivatives, MarketAxess can perform a lookup based on the characteristics of the contract to the ANNA DSB and return an ISIN to the transaction report.
For ETDs, MarketAxess can use the exchange product code to populate search for the relevant ISIN from the exchange and populate that on the transaction.
For OTC transactions where there is no Systematic Internaliser, no ISIN is required, but the relevant reference data fields must be populated on the transaction report instead of the ISIN.
Please read the MarketAxess ARM – ISIN Lookup Specification for more details on this process.
2 What will be the maximum number of transactions clients can submit in each submission batch?
99,999.
3
Why is my transaction report in a status of held?
There are two main reasons for this:
1. The client is using the EDS and a transaction has been sent in for which MarketAxess is unable to enrich, this could be because: — The static data does not exist in the EDS
environment — The static data exists but does not
match the details of the transaction report, for example: – The effective from date is after the
trade date of the transaction report – The executing LEI does not match.
2. The transaction is queued behind another transaction that is pending being processed, some of which could be in a HLD status.
46
European Data Store (EDS)
Ref. Question Answer
1 Where is data within the EDS stored? All data in the EDS is stored within the EU.
2
What value should I use as the “token”? This can be anything that you can use to uniquely identify the individual, but it should not be something that contains details that can easily be tied back to the individual.
3
What is the key that MarketAxess uses to lookup an individual in the EDS?
The combination of Executing Entity LEI and “token” and “trade date” are used to reference a record. Note that the “trade date” should be after the “effective from date” of the record and before the expiry date.
4 If I use MarketAxess Post Trade and MarketAxess Trading Platforms. Can the same EDS records be utilised?
Yes, the solution is used by both MarketAxess Post-Trade and the MarketAxess Trading Platforms.
5
What type of codes can MarketAxess map in the EDS?
MarketAxess can map both LEIs and details relating to natural persons (for both buyer/seller decision maker and execution/investment decision within firm).
6
What is the difference between an internal EDS record type and a client type record?
Internal records are used only for “execution within firm” and “investment decision within firm”. Client records can be used for “buyer/seller” or “buyer/seller decision maker” fields.
7
How can I cancel an EDS record? EDS records can be expired in the GUI or cancelled via the SFTP channel. An EDS token can also be used on two records simultaneously if the effective dates do not overlap.
APA – Deferrals
Ref. Question Answer
1 Will you handle deferral rules for all countries?
Yes, as long as you indicate which NCA governs your entity and the NCA has communicated which deferral will be allowed.
47
Ref. Question Answer
2
Could you advise the circumstances under which supplementary deferrals will apply - given that we will be subject to a particular NCA’s deferral regime.
Liquidity: we will determine whether OTC product is liquid depending on sub class it belongs to. If sub class does not appear on ESMA list, then it will be deemed illiquid. We will use different attributes (maturity, etc...) to map the subclass, depending on asset and sub asset class
Thresholds: we will use the threshold of the subclass and compare it against the notional expressed/converted in EUR.
3
How does MarketAxess deal with Deferrals?
Our rules engine has been designed to deal with any type of deferral (at instrument and NCA level) so we are able to support all deferral scenarios.
48
APA – Filtering rules
Ref. Question Answer
1
What criteria does MarketAxess take into account to determine what is a ‘venue trade’?
FIX tag 30 (Last Market) is taken into account. i.e. if last market is XOFF, SINT or SI MIC, then the rules engine proceeds to the reporting responsibility rule. If an EU venue MIC Code is given, then it is assumed the venue has reported.
In addition, when ESMA publishes the third country equivalent venue, MarketAxess intends to source the list and filter accordingly: it will not be required to print trades if you execute on one of these equivalent venues.
MarketAxess does not take into account broker capacity for venue of execution filtering. If an EU venue is provided, then it means the subscriber indicates that the trade is executed under the rules of the venue (regardless the broker capacity), and MarketAxess will apply the filter accordingly.
The broker trading capacity is taken into account for the calculation of deferral (trade can be subject to SSTI level if one of the party trades on own account)
2
Buyer/Seller: Is MarketAxess able to apply to RTS 22 rules as to who is the buyer and seller of a derivative? Or is this an aspect that the order management system will need to provide?
The order management system will need to provide MarketAxess with buy/sell indicator according to RTS 22 rules.
49
Ref. Question Answer
3
Chains: If there are chains, and another entity in the chain has already reported the trade, is MarketAxess able to identify this and apply the logic accordingly?
MarketAxess cannot apply the logic as it will not have the visibility if the trade being part of the chain has already been reported. MarketAxess will assess the trade as provided.
4
Flags: Which of the flags can MarketAxess enrich? For example, can it apply the post-trade large in scale transaction flag?
MarketAxess will enrich transparency flags in relation to the deferral process and trade lifecycle (cancel/amend).
5
Spot/Forward: Is MarketAxess able to filter spot FX from Forward FX for the purpose of MiFID II eligibility?
MarketAxess together with its data vendor partner is maintaining a list of MiFID eligible instruments.
50
Ref. Question Answer
6
Exclusions: To what extent can the rules engine filter out other transaction types that are outside the scope of transaction reporting (e.g. primary issuances, corporate actions etc.)?
MarketAxess relies on clients to pre-filter trade which are not subject to regime according to the nature of the trade.
MarketAxess does not have access to the nature of the trade beforehand. Clients can however send the trades and indicate that they are not eligible (by marking them as non-published). MarketAxess will filter them accordingly.
7
Concatenation: Please can you explain how this works? If we trade an instrument without an ISIN would we be expected to apply this approach instead?
MarketAxess enables subscribers to send concat (list of attributes as defined by RTS 2 and RTS 23) to uniquely identify an instrument in case the client does not have an ISIN. MarketAxess will generate the concat ID based on these attributes. The trade will then be printed with the concat ID.
51
APA – Size of transaction calculation
Ref. Question Answer
1
What is the calculation for size of transaction, which is used to compare against SSTI and LIS thresholds and in RTS 1&2 Quantitative Reports
Asset Class Calculation for trades
Calculation for quotes
Equity Financial Instruments
Bonds (ETCs and ETNs)
Securitised Derivatives
Quantity * Price
(Converted to EUR using Price
Currency)
Bid/Offer size * Price
(Converted to EUR using Price Currency)
Emission Allowances
Emission Allowance Derivative
Quantity * Unit of Measure Qty
Bid/Offer size
(Converted to EUR using Price Currency
Structured Finance Products
Interest Rate Derivatives
Equity Derivatives
Commodity Derivatives
C10 Derivatives
FX Derivatives
Credit Derivatives
CFDs
Notional
(Converted to EUR using Notional
Currency)
Bid/Offer size
(Converted to EUR using Price Currency
52
APA – Best Ex specification logic (incl. 27:APA & 28:ARM)
Ref. Question Answer
1
What logic is being used to select trades from APA data for RTS27 reports?
RTS27 what logic is being used to populate each field on Tables 3 and 4?
Scope of trades for populating tables 3 and 4 will be derived where the following is true
• Executing firm LEI
• Aggressor FLAG = FALSE
• Trading capacity = Deal
• Execution Venue = XOFF or MIC of Systematic Internaliser (if applicable)
• ISIN (or alternative instrument string) is in Table 2
NB, Last version of trade report will be used.
All other tables per CSV submitted by reporting firm
2
What logic is being used to select trades from ARM data for RTS28 reports?
Scope of transactions to be populated for each report will be derived from:
• Executing Entity Identification code = LEI
• Report_type = FILL
• Venue = valid MIC
Where Client type =
• PROF (for inclusion in the professional client report)
• RETL (for inclusion in the retail client report)
• SECF (for inclusion in the SECF Financing client report)
Denominator = “Total in that class of financial instrument”. i.e. includes all transactions within Class of Financial Instrument
Mapping of instrument to relevant Class of Financial Instrument (per RTS 28 Annex)
Delegated Acts (Art 65) “Top 5 Brokers”, as per RTS 28, but using Buyer (or Seller) Identification Code LEI where Venue = “XOFF” or “XXXX”
Passive Aggressive Liquidity indicator and Directed Order fields / values also taken into consideration
53
Ref. Question Answer
3
Where we have a different requirement for Post-trade Transaction/Trade reporting to Best Ex reporting (e.g. OTC trades reported to venue), how can MarketAxess support this variation?
RTS 27 utilises (OTC) data submitted to the APA (either via FIX or CSV upload).
RTS 28/DA 65(5) utilises data (OTC and On venue) data submitted via the ARM (or CSV upload).
4 What is the reporting currency for RTS 27?
RTS 27 reports are published based on the currency of the instrument per Table 2.
5 What EURO FX conversion rate is used?
RTS 27 reports are published in currency per Table 2.
RTS 28 will use the prior Year End Euro FX ECB rate.
6
RTS27 where ISIN is not available, what CONCAT value will be produced as an alternate identifier on Tables 3 and 4?
The Alternative Instrument ID “concat string” should be submitted by concatenating the “concat fields” together in the order of the MarketAxess APA Concat spec.
Empty/Null values are excluded.
Example formats:
• DERVINTRFUTRXOFF2018-01-04GBP2018-06-0923456GB00026482841K5LZHJ5JD3MJDCQOD47EONA36MNTHPUTO45.89GBPEUROCASHBNDF1K5LZHJ5JD3MJDCQOD472017-01-09345DAYSGBP43434567899561.54563DAYS2014-05-05MOSP
• BONDMAEL2018-12-32GBP
• DERVCURRFORWDVLBEUR2018-09-251.25EURCASHUSDFXCR
7
RTS 28 what logic is being used to categorize trades into Venue or Broker? And identify the particular Venue or Broker?
Where Venue = “XOFF” or “XXXX”, indicates broker execution.
8
Please confirm that there is no distinction between the type of venues and MarketAxess is doing the same across all venues irrespective what they are used for.
Correct, there is no distinction of type of venue. MarketAxess will distinguish based on class of instrument, SFT or not. NB, Per RTS 28, MarketAxess will treat Systematic Internaliser as Execution venues.
54
Ref. Question Answer
9
If a trade is arranged between a firm and counterparty via a broker, there is no place in TR for broker info.
1. How will MarketAxess derive the top 5 venues and /or brokers if the broker information is not there; there is no place to put broker on TR,
2. Does this mean the MarketAxess would consider it bi-lateral even if broker arranged it?
1. MarketAxess will work out the venue and broker based on counterparty information populated in the transaction reporting, using Buyer (or Seller) Identification Code LEI where Venue = “XOFF” or “XXXX”.
2. Correct. It is either executed on venue or off venue. MarketAxess will consider it bilateral if the venue code is not a trading venue.
10
What is the definition of:
1. Passive order
2. Aggressive order
1. ‘Passive order’ means an order entered into the order book that provided liquidity;
2. ‘Aggressive order’ means an order entered into the order book that took liquidity;
APA – MarketAxess APA Configuration
Ref. Question Answer
1
It is our view that filtering trades prior to sending to the APA carries risk, seeing as maintaining a list of MiFID II and 3rd country equivalent MICs will require ongoing monitoring and support. Have you received similar feedback from other clients? What is your recommendation?
We are not in a position to comment the level of risk carried if you use a third party to manage the filtering.
We can however say that regulatory reporting and filtering are part of MarketAxess core business, and the majority of our clients have decided to rely on our rules engine to manage the filtering.
2
Are there volume considerations or concerns based on our trade figures assuming we do send along all trades without any MIC filter?
There is no reason to have volume concerns. Our architecture is scalable.
55
APA – OTC Derivative-specific questions
Ref. Question Answer
1
Please could we have a copy of the specification for the SFTP transfer option (file specifications and how to connect)?
Yes, this is available on the MarketAxess website under https://www.marketaxess.com/post-trade/resources.
2 How frequently will trade report files be picked up for processing once sent to the SFTP site?
MarketAxess picks up files as soon as they are uploaded by the subscriber.
3
If the file has been received by MarketAxess within 15 minutes, have we met the obligation, or must the file be transferred, picked up and processed by MarketAxess within the 15-minute window?
File must be transferred, processed and trades printed within 15 minutes.
4
Can you say at approximately what time post-execution we would need to send trade reports via SFTP to be within the 15-minute reporting window for OTC derivatives? We expect SFTP to be slower than FIX and we therefore expect to have to build in more time for the trade report to be sent and received
MarketAxess has designed its solution to process trades within seconds. We do not advise specific times when trades have to be submitted. However, clients should take necessary measures to send as real time as possible to the MarketAxess APA.
56
APA – ISIN validation
Ref. Question Answer
1
Does the MarketAxess APA cover the following scenarios
1. We will provide APA with all necessary information for post trade transparency publication
2. We will provide APA with transaction data that will be enriched by APA with necessary reference data (ISIN, CFI, TToV flag, LIS/SSTI flags as well trade transparency flags) for the purpose of APA post trade publication as well as for the purpose of us having the necessary instrument reference data for ARM reporting.
Both scenarios are covered by the core APA solution
1. MarketAxess will accept ISIN or concatenation information to identify the instrument. MarketAxess will generate the concatenation ID; we will not however retrieve the ISIN based on the concatenation as the attributes are different.
2. MarketAxess supports an ISIN creation service whereby we send the request to ANNA-DSB and we send you back the ISIN. This is however part of separate workflow from our APA reporting. Note that you will also need a license with ANNA.
2
Is the CONCAT used only if ANNA fails to respond in a timely manner?
Or is CONCAT acceptable for post-trade transparency in all cases?
The CONCAT is acceptable in all cases.
3
Will the MarketAxess Post trade transparency service determine the instrument eligibility by checking against the ToTV if we populate an ISIN on our trade messages?
MarketAxess will check the ToTV status based on ISIN provided on the trade report message
4
If a given instrument is not on ToTV, will you NPUB the trade and notify us by populating the FIX tags 751/1328 with the appropriate code and text?
If the instrument is not on ToTV, the trade will be flagged with the status NPUB.
However, 751/1328 will only be populated if the trade has been rejected (REJT). We will notify you of the reason for it not being published in field 58 with text ‘The trade has not been published. The security is not MiFID II eligible.’
5 Can we test the MarketAxess Post trade transparency service information eligibility functionality?
Yes, it is currently available to test in UAT
6
Do you have any updated spec for pre-trade that includes support for concatenation id?
We will accept any kind of string if you don’t have an ISIN. ESMA didn’t prescribe to use a concat ID, just an ID which uniquely identify the product. We will let the firm choice of instrument ID. We will not be able to do any filtering though
57
Ref. Question Answer
7
If each SI sends the concatenation id in their own unique format, how will the consumer of this information identify the product being quoted by different SIs?
It will be up to SI to provide an unique ID. ESMA didn’t prescribe any specific ID for quotes where there is no ISIN. It is only mandatory to use concat for post-trade where there is no ISIN
8
Do you plan to return ISIN in ack message for the case where quote or trade is submitted with concatenation id?
It is not possible to identify ISIN based on the concat ID as defined by ESMA, given that ANNA and ESMA have defined different attributes for same product
9 Will MarketAxess send the ISIN back to client in AR message?
MarketAxess will always publish with the concat ID. We will not send an ISIN back to client
APA – General
Ref. Question Answer
1
What options does MarketAxess offer for Assisted Reporting?
Model 1: The client relies on Broker to send the trade report to the MarketAxess APA. The client has access to MarketAxess’ monitoring tools and has a contractual relationship with MarketAxess
Model 2: A designated firm reports on behalf of the client and manages the monitoring and all the exceptions. The client will not have access to the MarketAxess APA monitoring tools and will not enter into an agreement with MarketAxess
2
What information do you require about the counterparty in the fix protocol in order to provide Assisted Reporting?
If you provide assisted reporting, from perspective of your client, you have swapped parties and buy/sell indicator (from perspective of your client). The executing entity will be the client and the counterparty will be the reporting firm. The reporting firm will be the party who has the technical link with MarketAxess.
58
Ref. Question Answer
3
What actions need to be taken by the broker and by the broker’s client to on board an Assisted Reporting client?
By the reporting broker:
• Broker will notify MarketAxess and provide MarketAxess with underlying client details. MarketAxess will contact the client or the client can directly contact MarketAxess.
By the client:
• To review and sign MarketAxess contractual and service documentation, including Service Order Form (SOF)
• To complete on-boarding form
• MarketAxess will set up client and will give access to its UAT and web-based monitoring tools via our MarketAxess dashboard (GUI)
• Client to familiarize with monitoring tools, exceptions management in MarketAxess testing environment.
MarketAxess will notify broker when client is set up.
Both broker and client need to have a contract with MKTX before both parties can be onboarded.
4
Are we able to set up control in the MarketAxess APA?
How and where? Can I do it in the GUI?
For example, to place a control on the volume field.
All our validation rules will be common across the MarketAxess clients. You can however switch on and off certain key rules such as MiFID filtering.
The dashboard will give you the full picture of the status of any trades, with a range of widgets.
5 What happens if an LEI is sent which MarketAxess hasn’t set up?
LEI will be rejected if not set up.
6
How do we test an OTC product in UAT?
Reporting firms CANNOT load OTC product in UAT with dummy ISIN or ISIN created by ANNA – specific products cannot be tested.
MarketAxess will share its reference data so that reporting firms can test products using ISINs set up in the MarketAxess UAT environment.
59
Ref. Question Answer
7
Can you send me a brief explanation on the situations when you expect to receive the concatenated instrument identifier?
For transparency purposes, we will expect to receive concatenated instrument identifier where you don’t have an ISIN primarily due to timing constrain to report on time, i.e. either because you don’t have the time to obtain the ISIN or because you don’t know if the ISIN exist.
In other words, we will support the “OTHR” identifier based on set of fields which constitute the concatenated instrument identifier.
8
Which fields/what information are/is needed specifically to go into the fix protocol in order for you to decide who has the reporting obligation (SI vs Seller)?
We will need the LEI code of your counterparty as well as buy/sell indicator.
9
Given that we want to make sure we set up the entitlement for the data correctly, how are you looking to disaggregate the data? If by asset class, how will that be split?
We will be able to disaggregate data as per the dis aggregation criteria defined by ESMA.
10
I see in the sample, there is a list of products included, but can I confirm which are the ones that will be reported on the APA?
All assets will be reported through our APA.
11
Can you send over the Trade Types expected to see on this APA (e.g. Normal Trade, Automatic Trade, SI Trade etc)?
We will only published data as per RTS 1 / RTS 2, with flags such as XOFF / SINT.
12
Will you be sending the MMT or ESMA flags or propriety trading conditions? Please do send details of these flags/codes as they are not in the current spec.
We will be sending the transparency flags as per RTS 1 / RTS 2.
60
Ref. Question Answer
13
We require some clarification (definitions) for the following parties:
• Reporting Party/ Reporting Entity
• Executing Party/ Executing Entity
• Counterparty
Reporting party:
• Contracting party (eg parent company)
• Responsible for reporting under MiFID II
Executing party:
• Actual reporting firm (eg one of the LEI part of the parent company). This can be same as Reporting entity or in case of Facilitated Reporting you would use the LEI responsible for reporting which would be a different LEI.
Counterparty is the party on the other side the trade (eg the broker LEI).
14
CSV upload trade report - Would you reject a trade report without a notional?
Yes, we would reject a trade report if the Notional Amount has not been provided. There isn’t a concept of PNDG for notional in the regulation, whereas there is for price.
15
How will the trade size be calculated for each product type – I can see that TraxNotionalAmount (22600) & TraxNotionalCurrency (22601) would be sufficient for OTC’s – how about for non-OTC’s?
Correct, it will be based TraxNotionalAmount (22600) & TraxNotionalCurrency (22601) for Derivatives and FI products. For Equity, we will use Quantity and Price (Converted to EUR using Price Currency). For Emission allowance, we will use Quantity and Unit of Measure Qty.
61
11 GLOSSARY OF TERMS AND ACRONYMS
This list is largely based on the ESMA list of abbreviations and acronyms. It is not definitive, and acronyms may have other meanings.
Term/Acronym Meaning
AII Alternative Instrument Identifier
AIFMD Alternative Investment Fund Managers Directive
APA Approved Publication Arrangement – A regulated service which publishes RTS 1 and RTS 2 data on behalf of MiFID firms and venues
ARM Approved Reporting Mechanism – A regulated service which validates RTS 22 data and routes it to the appropriate national regulator
AUM Assets Under Management
BestEx Best Execution, namely Top 5 Venue (RTS 27) and Quality of Execution Reporting (RTS 28)
CCP Central Counterparty Clearing
CDS Credit Default Swaps
CDO Collateralized Debt Obligations
CPR Commodity Position Reporting
CRD Capital Requirements Directive
CSD Central Securities Depositories
EBA European Banking Authority
ECB European Central Bank
EEA European Economic Area
EMIR European Market Infrastructure Regulation
EP European Parliament
ESCB European System of Central Banks
ESMA European Securities and Markets Authority
ECMF European Capital Markets Forum
FAQ Frequently Asked Questions document that is provided to clients migrating from DBG to MarketAxess
FSC Financial Services Committee
GAAP Generally Accepted Accounting Principles
IFRS International Financial Reporting Standards
62
Term/Acronym Meaning
IFRS IC International Financial Reporting Standards Interpretations Committee
IOSCO International Organisation of Securities Commissions
IT Information Technology
ITIL Information Technology Infrastructure Lifecycle
MAD Market Abuse Directive
MiFID Markets in Financial Instruments Directive
MiFIR Markets in Financial Instruments Regulation
MTF Multilateral Trading Facility
NCAs National Competent Authorities
NPD Natural Person Data
OAM Officially Appointed National Mechanism
OTC Over-The-Counter
Q&A Questions and Answers
RegS Regulatory Services GmbH – a Deutsche Börse Group subsidiary that currently provides reporting and publication services to clients in Europe
RRH Regulatory Reporting Hub - the product & solutions “brand” under which Regulatory Services GmbH marketed its services
RFQ Request for Quote
SEC Securities and Exchange Commission
SFTR Securities Financing Transaction Regulation
SI Systematic Internalizer
SSM Single Supervisory Mechanism
TD Transparency Directive
TREM Transaction Reporting Exchange Mechanism
UAT User Acceptance Testing – a test environment comparable to what former RegS clients might know under SIM
UCITS Undertakings for Collective Investment in Transferable Securities (Directive)
63
©2020 Trax NL B.V.
Trax NL B.V. (69597774) is incorporated in the Netherlands and licensed by the Autoriteit Financiale Markten (“Trax NL”). Xtrakter Limited (01917944) is incorporated in England and Wales, and is authorised and regulated by the Financial Conduct Authority (“Trax UK”). MarketAxess is a trading name of the aforementioned entities, and references to ‘MarketAxess’ shall be taken to refer to either, or both, of Trax UK or Trax NL, as applicable. The information contained in and accompanying this document is strictly confidential and intended solely for the use of the intended recipient(s) and may not be redistributed without the prior written consent of the Company or its subsidiaries.
All rights reserved, no part of this document may be copied, reproduced, transmitted or divulged in any form to any party without the prior written consent of MarketAxess.
Whilst every effort has been made to ensure that the contents contained herein are accurate and complete, MarketAxess does not accept any liability for any errors or omissions. The development of products and methods is continuous, and information contained herein may not be up to date. Therefore, it is important to check the current status with MarketAxess.
