MIFID II RECONCILIATION: Six scenarios participants cannot ignore

  • 1544

    MIFID II RECONCILIATION: Six scenarios participants cannot ignore

    While the financial industry has intently focused on reporting requirements under Markets in Financial Instruments Directive (MiFID) II, reported data reconciliation requirements are not receiving nearly enough attention. With MiFID II transaction reporting set to disrupt legacy systems and existing processes, Manu Garg highlights six scenarios that will affect reconciliation.

    A challenging task under previous regimes, trade data reconciliation is about to become more complex. MiFID II not only requires processing a large amount of data but also encompasses managing multiple scenarios, such as:

    • Transparency and transaction reporting
    • The inclusion of multiple new products in reporting obligations
    • Accounting for the buy-side and sell-side counterparties after swapping party identifiers and leg fields for dual reporting and real-time reconciliation

    Most firms typically build their reconciliation process on top of legacy systems with in-house-developed utilities. These can be dependent on specific users, requiring time-consuming manual intervention. What’s more, they are often rigid and not easily extendible to support new regulations.

    Considering the data required for MiFID II, these systems could prove to be obsolete, impractical, expensive and risk borne. Firms can of course upgrade these utilities. However, given MiFID II’s complexity and the evolving nature of regulatory requirements, new technology is needed to keep pace and minimize the risk of regulatory fines.


    Investment firms must complete statutory reconciliation under MiFID IIís RTS 22 and RTS 6 for trading records versus trade data from national competent authorities (NCAs). The other recommended processes include reconciling reference data such as Legal Entity Identifiers (LEIs), International Securities Identification Numbers (ISINs) and personally identifiable information (PII) available within an investment firm as opposed to what is supported by the European Securities and Markets Authority (ESMA).

    Approved Reporting Mechanisms (ARMs), Approved Publication Arrangement (APAs) and NCAs are also required to run timely reconciliation between data that is reported to firms and the data they publish back to their clients.

    The following six scenarios highlight the impact of MIFID II reconciliation requirements.


    SCENARIO #1: Records vs. Data from NCAs

    Regulators have asked for frequent reconciliation of front-office trading records with trade data provided by NCAs. The intent is to more efficiently identify any inaccurate and incomplete transaction reporting. This includes confirming the timeliness of the report, ensuring individual data fields are complete and ensuring compliance against the standards and formats specified within the RTS document.

    If the NCAs fail to provide trade data, firms are required to reconcile the following:

    • Front-office trading records versus transaction reports as submitted toARMs, APAs and CTPs
    • Front-office trading records versus transaction reports that ARMs or trading venues have submitted to NCAs

    Transactions from trade booking systems are subject to data cleansing, data transformations and trade enrichment, as well as complex reporting rules before submission. As a result, it becomes impossible to directly reconcile front-office trading records against transaction reports from regulators, or transaction reports from ARMs, APAs and CTPs to the NCAs.

    To perform these reconciliations, the process needs to be broken into different use cases:

    • Reconciliation between data from the trade booking system versus unenriched data as received by the reporting system
    • Trade data as reported by the reporting system versus transaction reports by NCAs and ARMs on a firm’s behalf. A successful reconciliation without any breaks would ensure timely transaction reporting, the accuracy of the individual data fields, and compliance with standards and formats.

    A successful reconciliation without any breaks on both of the above examples would ensure timeliness, accuracy and completeness of the individual data fields and compliance with the standards and formats specified by the regulator.


    SCENARIO #2: Trading Logs vs. Executed & Outstanding Orders

    ESMA has directed firms to implement post-trade controls to monitor market and credit risk. To do so, firms must calculate their own outstanding exposure and that of their traders and clients in real time. Through post-trade reconciliation, ESMA expects reconciliation of electronic trading logs against the records of executed and outstanding orders from trading venues, clearing members or central counterparties (CCPs).

    A successful reconciliation without any breaks in this data would ensure there is not any unaccounted risk exposure against the counterparty, thus reducing market and credit risk. Firms will also understand their outstanding orders and risk exposures as provided by the trading venue to which they send orders.

    In addition, under MiFID II (Article 13, Chapter 2, RTS 6), firms must implement pre-trade controls to restrict potential market abuse or breaches for position limits. That means generating alerts on at least the following day. Pre-trade controls need to be conducted before an order is submitted to a trading venue.

    Firms must reconcile their own electronic trading logs versus the records provided by trading venues. Discrepancies in reconciliation, such as extra outstanding orders at a trading venue, would identify signs of disorderly trading or a breach of pre-trade limits. Regulatory guidelines instruct firms to reconcile in real time when market participants provide the information for all individual data fields  with the specified standards and formats.

    Similarly, regulatory guidelines instruct firms to reconcile in real-time when market participants provide the information for all individual data fields with the standards and formats specified in RTS.  As a result, firms may have to upgrade or enhance their existing systems to handle the real time reporting and additional data field requirements.


    SCENARIO #3: APAs & CTPs Reconcile Transaction Reports from Client vs. Data Sample from NCA

    APAs and CTPs must perform periodic reconciliations between the trade reports they receive and the trade reports they publish to verify accurate information is sent back to the reporting firms.

    A successful reconciliation between trade reports received by APAs and CTPs versus trade reports published by APAs and CTPs to investment firms ensures the data reporting services provider can monitor whether their published reports are accurate and complete. If breaks and discrepancies are identified, APAs and CTPs can take corrective actions to resolve omissions or ask the client if reconciliation breaks are the result of incorrect reporting.

    Ultimately, the goal is to create an automated reconciliation process in which all data is sourced, cleansed, transformed and reconciled without user intervention or security concerns.


    SCENARIO #4: ARMs to Reconcile Transaction Reports from Client vs. Data Sample from NCA

    The ARM must perform periodic reconciliations at the request of the competent authority. This includes the information that the ARM receives from its client or generates on the client’s behalf for transaction reporting purposes against the data samples of information provided by the competent authority.

    This process confirms that complete and accurate information is published or submitted by the ARM.


    SCENARIO #5: Reconciliation of PII

    To ensure consistent surveillance for the prevention of market abuse, regulators require identification referred to in transaction reports and trade records. People who made investment decisions should be identified by the country of their nationality followed by identifiers assigned by the country of nationality of those persons. Where more than one person in a firm makes the investment decision, the person taking the primary responsibility for the decision must be identified in the reported data.

    Reporting accurate PII is another reason to ensure that PII information sent by the source system is in harmony with the PII sent to regulators via a reporting system. There are various challenges associated with sourcing and verifying this information. These include:

    1. The integration of a reconciliation system with an investment firm’s human resources systems and trade booking systems
    2. The enrichment and encryption of PII. Source systems will send the PII IDs to ARMs, and the ARMs will enrich the PII information before sending it to the NCA/ESMA. For security purposes, this information will most likely be encrypted so the reconciliation system will need to decrypt the information.
    3. The legal aspects to handle PII. Firms providing reconciliation services or systems will need to comply with SOC-II standards for security, availability, process integrity, confidentiality and privacy.

    Beyond the aforementioned challenges, firms must ensure regulators receive accurate PII. For this to occur, the PII, which is housed in multiple systems, should be converted into a standard format before moving it into a reconciliation system. The PII that is actually reported to regulators then needs to be reconciled to ensure accuracy.


    SCENARIO #6: Reconciliation of ISIN, CFI, SIS

    ESMA requires reference data reporting for financial instruments (e.g., ISIN, CFI, LEI, SI) in a consistent format to effectively monitor competent authorities.

    Promptly receiving reference data for all traded financial instruments will enable competent authorities and ESMA to ensure data quality and effective risk monitoring. Regulators will provide acknowledgments only for those transactions where the product identifier is a subset of ESMA’s list of ISINs and CFIs. The same holds true for other reference data. Ideally, only transactions where ISINs and other reference data is in accordance with ESMA’s supported list should be reported.

    If the intended ISIN or CFI cannot be located in ESMA’s list, firms can uncover a potential threat of regulators rejecting a reported transaction, thereby reducing the number of failure messages or NACKS from the regulator. Similarly, other reference data such as LEIs, SIs and MIC codes can be reconciled for accurate reporting.

    However, it is not mandatory to report transactions only with ESMA-listed product identifiers.Transactions with product identifiers not yet available in ESMAís list will be put on hold for seven business days by the NCA, and the NCA will check if the reported identifier is added to ESMA’s list. If it’s not, ESMA will send a failure message back to ARM/APA, which in turn will inform the reporting entity about the failure message status.

    Efficient Reconciliation

    Traditionally, firms have relied on spreadsheets or user-developed applications for reconciliations and data control, but the depth and breadth of data make these systems unsustainable.

    Ultimately, the goal is to create an automated reconciliation process in which all data is sourced, cleansed, transformed and reconciled without user intervention or security concerns. Reducing touchpoints for data transfer and applying consistent standards between market participants will alleviate time spent on manual processing and data administration.

    The Author

    MANU GARG is a Senior Associate in Trading and Risk Management at Sapient Global Markets. He focuses on portfolio reconciliation solutions for multiple regulations and multiple trade repositories for Sapient’s CMRS solution. Prior to joining Sapient, Manu worked as a Business Analyst in the ETRM/CTRM space and was a former trader of financial investments and derivatives listed in major global exchanges.

    Leave a Comment