MiFID II Data Challenges: What Do You Need to Solve?

MiFID II requirements around transparency, reporting, and access to liquidity sources are putting enormous pressure on European financial institutions and are consuming considerable internal resources. The volume and variety of data to be processed and analysed, the complexity of the analytical processes, and the urgency of the reporting requirements necessitate a step change in technology.

In July 2016, McKinsey Quarterly wrote that to meet such challenges, “banks simply deploy their considerable IT expertise in patching holes, maintaining systems, and meeting regulations.”

But patching holes will no longer work. Indeed, it is vital that financial firms establish a sound application framework to meet MiFID II’s requirement by January 2018, and any successful framework must consider current and future data sources and challenges.

Many of those challenges will revolve around specific requirements in MiFID on reporting and data delivery. Specifically,

• Transaction Reporting. MiFID requires financial firms to send information for all eligible trades within a regulated market to a regulator as soon as practicable. This means that trades need to be reported to an authorised reporting mechanism (ARM), which is responsible for packaging up the information and providing it to the local competent authority.
• Post Trade Transparency. Trades are sent to the ARM in real-time through an authorised publishing authority (APA). These authorities are responsible for making public trades related to bonds, structured finance products, emission allowances, and derivatives. This is a tough requirement to satisfy.
• KPI Reporting. To safeguard against Algo trading as well as trading beyond limitations and to ensure investor protections against inducements, organizations will need to generate reports on various Key Performance Indicators (KPI). As part of the mandate to be able to reconstruct past events and unwind any trade with communications, a second timeline will be imposed to answer the question, “What did we know when the trade was made and how can we prove it?” This bitemporal feature answers this critical question by tracking when events occurred (valid time) in combination with when they were recorded (system time).
• Governance. Proof of the governance behind the business: Is the business really putting in processes to infuse the business with a fair operational culture for its customers and to be transparent to regulators and customers? To do so, the business needs a robust data governance system.

Assessing Your Ability to Meet MiFID II’s Reporting Requirements

The guide below will help you assess your current framework’s ability to meet these challenges.

Data management. No data left behind.Can your trade/transaction reporting platform report across multiple sources of data in real-time? Siloed controls and inflexible legacy technologies, are, in most cases, unable to handle multiple sources of data. The number of fields for transaction reporting has significantly increased. Traditional relational databases struggle to process the data when some information doesn’t fit the required fields. That data will be rejected, resulting in inaccuracy of reportable data. The possibility to ingest the data as-is and reconcile the data in place represents significant advantages and expedites the route to compliance.

Communication data supervision and reconstruction.Can you track the provenance of information through your reporting regime? Companies must demonstrate effective oversight and control over policies and procedures which govern all communications. Moreover, there is a requirement to supply regulators with communications associated with a specific trade and being able to reconstruct history of trade cycle events. Knowing what information you knew and when and how you knew it has changed over time. Now a bitemporal view of data lineage is a critical component of your regulatory reporting infrastructure.

Data storage.Can you support on-demand audit and investigative requests for access to complete history data on transactions, customer records, reports, computational results? Companies must make records available to clients for a retention period of five years and for up to seven years for regulators. The need for secure data storage has never been greater especially when jurisdictional limitations need to be considered. Some jurisdictions may enforce confidentiality rules and restrict information sharing among parties; in those cases identifiers will need to be used.

Data quality and data logic checks.Can you demonstrate end-to-end provenance and governance on data along the reporting hierarchy with proven processes that validate sources, relationships and temporal affinity? Banks have to be able to generate the right information for the regulator, and that creates the need for a compliance library and logic that can be reused. With many consumers of information internally and externally, logic that defines fields for reporting is often duplicated across reports. Rather than encourage an army of business analysts to re-process information for each data delivery, a better approach is to store and re-use methods and program code and associate both to the data sets and results used with timestamps. The methods and code can be updated over time independently of data updates.

Making your compliance solution a business analyst-led framework.Does your solution empower the IT staff or business analysts? It is important to institute the processes in place which can be managed by non-technical analysts. This will have significant cost-saving implications as well as ensure operational efficiency without the need to re-architect the regulatory data centre when the regulatory rules evolve. The right technology can provide a number of benefits, including:

• Consolidation of structured and unstructured data, indexing and searchability.
• Bitemporality, or the ability to track when events occurred (valid time) in combination with when they were recorded (system time), for auditing and tracking.
• Discovery of new and emerging relationships in concepts found across text documents as well as relationships between text and structured data.

The right platform has to be easy to integrate into any front-office business intelligence applications.

Sourcing the data just once.How reusable and extensible is the logic that you have built into the reporting system? Within a distributed architecture, calculations can be duplicated in multiple databases and applications. Accuracy can be achieved by placing all data into one operational database. Taking a risk calculation as an example, customer reference data stored in a single location can be enriched with the products of multiple business processes. In risk analytics, the same data set on a traded portfolio may be used by several users with different models. The data serviced by a shared data platform that marks the record of reference set for each method and time would be prudent governance. The method information and the results may also be returned to the same database with annotations and associations establishing time history of analytical results, reports and lineage inbound data as one unit of work subject to review, audit and certify.

Querying the data and exporting the information.Are you able to explore and query the data that you have aggregated to answer business questions as well as new regulatory requests? A traditional data warehouse is extremely difficult to query. Arguably, only a multi-model technology can ensure that data can be explored without losing the richness of the original source because it allows us to search multiple databases, each with its own storage and operational requirements, while leaving the data in place. This has great advantage over traditional approaches in which we convert data from different formats and flatten the source models so they can be retained. Doing so creates vast flat tabular structures that may be conducive to spreadsheet operations and may be filtered. However, we cannot ask new questions, nor can we identify what we discarded in the flattening process. A multi-model approach provides the ability to explore information without necessarily having to map and transport these flattened models.

E-discovery, archiving and record retention across all sorts of data, structured and unstructured.How do I really identify what I knew when, and how can I prove it? Retail banks are very familiar with the issue of discovery, but with many messaging and data formats the ability to identify information across not just business silos but information silos (email, messages, texts, office documents etc.) is a serious challenge for investment banks. How do I really identify what I knew when, and how can I prove it? Traditional databases store unstructured data as BLOBs which, as a unit of information, is not sufficiently granular and cannot resolve complex search and discovery questions. Even after the search problem is solved, managing this information as part of an information life cycle management (ILM) process becomes singularly important to prevent operational costs escalating. The retention requirements vary; trade transactions, depending on asset class and venue may be retained and rendered accessible online for five years. Audit trails, reports, settlement and clearance instructions, specific investigations, corrective actions and contractual information and counterparty data affiliated with transactions are required for retention and regulatory access for seven years.

Evolving Reporting Requirements.Does your platform offer the flexibility to adapt to evolving regulatory requirements? We recommend a design approach for reporting solutions that ensures agility and flexibility. The solution should deliver a regulatory reporting platform that incorporates best practices and operational effectiveness and allow for adaptive growth in scope and scale. The design goal should not be to remedy one-off reporting requests but to build in a capability to respond to emerging requirements with relative ease and cost efficiency.

More on MiFID II

• Listen to our MiFID II webinar.
• To dig a little deeper into multi-models, read Damon Feldman’s mini case study on his experiences with a client.
• Learn how you can keep truly accurate records of the past with bitemporal tracking.