Case Study 2: Meridian Asset Management and the ESMA Transaction Reporting Data Quality Review

Background

Setting: Paris and London, October 2022–August 2023 Institution: Meridian Asset Management S.A. (fictional), a Luxembourg-domiciled asset management firm managing EUR 14 billion AUM across equity, fixed income, and multi-asset strategies. Meridian is CSSF-regulated (Luxembourg) with MiFID II authorisation; it also operates a UK sub-advisory entity, Meridian Asset Management (UK) Ltd, FCA-authorised. Advisor: Priya Nair, Big 4 RegTech consultant specialising in transaction reporting and data quality Regulatory trigger: Letter from ESMA to Meridian's National Competent Authority (the CSSF) following an automated data quality assessment identifying specific reporting anomalies in Meridian's MiFIR transaction reports

The Regulatory Context

ESMA conducts regular automated quality assessments of transaction reports submitted across EU NCAs. The assessments use a set of validation rules that check for completeness, format compliance, and logical consistency. When anomalies exceed certain thresholds, ESMA notifies the relevant NCA, which then typically requires the investment firm to provide an explanation and remediation plan.

ESMA published its Annual Transaction Reporting Common Errors and Failures report in 2022, identifying industry-wide error patterns. Three of the most common failure categories identified were:

  1. Missing or incorrectly formatted Algorithmic Trading Indicator fields (Fields 26, 27, 28)
  2. Missing Investment Decision Maker identifiers (Field 3) for orders generated by discretionary portfolio management systems
  3. LEI validation failures, including lapsed LEIs (registered but expired in GLEIF) and LEIs used for the wrong legal entity

Meridian's reports were flagged for two of these three categories.

The CSSF wrote to Meridian in October 2022, forwarding ESMA's data quality findings and requesting: (a) a root cause analysis of the identified errors; (b) quantification of the scope of affected transaction reports; (c) a remediation plan with implementation milestones; and (d) corrective report submissions for affected transactions within a specified period.

Priya Nair was engaged by Meridian's General Counsel in November 2022.

Phase 1: Understanding the Errors (Weeks 1–4)

The ESMA Findings in Detail

ESMA had identified two categories of data quality failure in Meridian's reports for the period January 2021–June 2022 (18 months):

Finding A: Missing Algorithmic Trading Decision-Making Indicator (Field 27)

ESMA's validation flagged approximately 8,400 transaction reports where Field 26 (Algorithmic Trading Indicator) was populated as "Y" but Field 27 (Algorithmic Decision-Making Indicator) was left blank. Per the MiFIR reporting guidelines, Field 27 is mandatory when Field 26 is "Y" — it indicates whether an algorithm made the investment decision, the execution decision, or both.

Finding B: Missing or Incorrect Decision Maker LEI (Field 3)

ESMA's validation flagged approximately 12,200 transaction reports where Field 3 (Investment Decision Maker) was blank or contained an incorrect identifier. Field 3 should contain the LEI (for algorithmic or firm-level decisions) or the national identifier code (for natural person portfolio managers) of the entity or individual who made the investment decision.

Priya's first task was to understand the systems architecture well enough to identify the root cause of each error category.

The Systems Architecture

Meridian's transaction reporting pipeline was built in 2017 for MiFID II go-live and had not been materially re-engineered since. The pipeline consisted of:

  1. Portfolio Management System (PMS): BlackRock Aladdin, where portfolio managers made investment decisions and raised orders
  2. Order Management System (OMS): Charles River CRIMS, where orders were processed and routed for execution
  3. Execution Management System (EMS): FlexTRADER, where execution algorithms were configured and run
  4. ARM: Unavista (LSEG), receiving a nightly extract from the OMS for transaction report submission

The data flow was: PMS → OMS → ARM extract → Unavista → CSSF/ESMA.

Root Cause: Finding A (Field 27)

Priya traced Finding A to a specific implementation decision made at go-live in January 2018. The OMS extract that fed the ARM had been configured to populate Field 26 ("Y" or "N") based on a flag in the EMS — if a FlexTRADER execution algorithm was used, Field 26 was set to "Y." However, the extract had never been configured to separately populate Field 27, because in 2017 the implementation team had not clearly understood the distinction between the algorithmic trading indicator (Field 26, a binary flag for any algorithmic involvement) and the decision-making indicator (Field 27, specifying whether the algorithm made the investment decision, the execution decision, or both).

The result: for five years, every transaction report involving an execution algorithm had Field 26 = "Y" and Field 27 blank. The ARM's validation did not catch this because Unavista's validation rules, at the time of Meridian's original integration, had treated Field 27 as conditionally required — and the condition logic had not been updated after ESMA's 2019 guidelines clarification that Field 27 is mandatory whenever Field 26 is "Y."

This was a finding that Priya could see would be uncomfortable to explain. Meridian had been submitting incomplete reports for five years. The number of affected reports — approximately 8,400 — was significant.

Root Cause: Finding B (Field 3)

Finding B had two separate root causes, each affecting a different population of reports:

Root Cause B1 (blank Field 3): For systematic strategies — quantitative equity portfolios where investment decisions were made by a rules-based investment model rather than a human portfolio manager — Field 3 had been left blank. The implementation team in 2017 had concluded that there was no natural person to identify and had not configured the OMS to populate the firm's own LEI in Field 3 for algorithm-driven decisions. ESMA's guidelines are clear: for algorithm-generated investment decisions, Field 3 should contain the LEI of the investment firm. Approximately 7,100 reports were affected.

Root Cause B2 (lapsed LEI in Field 3): For orders generated by named portfolio managers (natural persons), the national identifier code was correctly formatted and populated. However, for orders attributed to investment decisions made by a committee or collective process, the OMS was configured to use the Meridian S.A. LEI — but the specific LEI used had lapsed (the annual renewal fee had not been paid to the LOU) in March 2021 and had been invalid for fifteen months at the time of ESMA's assessment. Approximately 5,100 reports used the lapsed LEI. The lapsed LEI appeared in GLEIF's database as "Lapsed" status, which ESMA's validation flagged automatically.

Phase 2: Quantification and Scoping (Weeks 5–8)

Quantification

Priya led a detailed data exercise to quantify the full scope of affected reports. Working with Meridian's data analytics team and Unavista's ARM portal:

Finding A scope: 8,412 transaction reports with Field 26 = "Y" and Field 27 blank. Period: January 2018 (MiFID II go-live) through June 2022. All were technically incorrectly reported.

Finding B1 scope: 7,134 transaction reports with Field 3 blank (systematic strategies). Period: January 2018 through June 2022.

Finding B2 scope: 5,103 transaction reports with lapsed Meridian LEI in Field 3. Period: April 2021 through June 2022 (from the month following LEI lapse).

Total affected reports: 20,649 reports over an 18-month formal review period (but with Finding A and B1 extending back to go-live in 2018, the full scope of non-compliant reporting was five years).

The quantification was uncomfortable reading for Meridian's senior management. But Priya had seen worse.

"The key thing now," she told Meridian's General Counsel, "is not to minimize this. ESMA and the CSSF already know the scope from their own data. Your response needs to demonstrate that you understand it fully and are addressing it comprehensively. Underestimating the scope in your response would be much worse than acknowledging it."

One of the most difficult questions in the engagement was how far back Meridian was obligated to submit corrective transaction reports. MiFIR Article 26 does not specify a look-back period for corrections; ESMA's guidelines indicate that firms should submit corrective reports (CANC + new report) for all incorrectly submitted reports.

After analysis of ESMA precedent and CSSF supervisory practice, Priya recommended: (a) corrective reports for all 20,649 reports in the formal review period (January 2021–June 2022); (b) corrective reports for the B2 (lapsed LEI) population extending back to April 2021; (c) for the broader Finding A and B1 populations extending back to 2018 (approximately 30,000 additional reports), a good-faith submission of corrective reports was recommended, noting that the CSSF had discretion on how far back to require corrections and that voluntary disclosure of the full historic scope would likely be viewed favourably.

Phase 3: Remediation Programme (Weeks 9–24)

Immediate ARM Upgrade

The highest-priority remediation was fixing the OMS extract that fed the ARM so that future reports would be correct. Priya worked with Meridian's technology team and Unavista to redesign the data mapping.

Field 27 fix: A new data element was introduced in the OMS that captured, for each order, whether an algorithm made the investment decision, the execution decision, or both. This required collaboration between the OMS team (who owned the order record) and the EMS team (who knew which algorithms had been used). A mapping table was created: each FlexTRADER algorithm was classified as either "execution only" (Field 27 = "ALGO" only for execution, not decision), "investment decision" (both Fields 27 and 28 set to "ALGO"), or "not applicable." The OMS extract was updated to use this mapping table.

Field 3 fix: Two sub-fixes: - Systematic strategies: The OMS was configured to populate Field 3 with the current Meridian S.A. LEI for all orders originating from quantitative portfolio models. - LEI renewal: Meridian's entity management team renewed the lapsed LEI immediately and implemented a calendar reminder for annual LEI renewal, cross-referenced with GLEIF's published renewal date for each entity.

The ARM changes were tested in Unavista's test environment for four weeks, then deployed to production in week 16.

Validation Enhancement

Priya reviewed Unavista's ARM validation rules and identified that three rules relevant to the errors had not been enabled in Meridian's ARM configuration — they were available but not activated. Meridian updated its ARM configuration to activate all available field-level validation rules. Going forward, any report with a missing Field 27 when Field 26 = "Y" would be rejected before submission to the CSSF, allowing the data team to correct and resubmit.

Additionally, Priya recommended that Meridian implement a pre-submission validation layer in the OMS extract — running validation logic before the data even reached the ARM. This "shift-left" approach catches errors at the source, where they are cheaper and faster to correct, rather than waiting for ARM or NCA rejection.

Corrective Report Submission

The corrective report programme was executed in three batches:

Batch 1 (weeks 17-18): 5,103 reports — Finding B2 (lapsed LEI), January 2021 – June 2022. Each corrective submission consisted of a CANC report (cancelling the original) followed by a new report with the correct LEI. Submitted via Unavista.

Batch 2 (weeks 19-21): 7,134 reports — Finding B1 (blank Field 3 for systematic strategies), January 2021 – June 2022. New LEI populated.

Batch 3 (weeks 22-24): 8,412 reports — Finding A (blank Field 27). Each required populating Field 27 based on the retrospective determination of algorithm type for each execution.

The retrospective determination for Batch 3 was the most complex element. For orders executed between 2021 and mid-2022, Priya's team reconstructed the algorithm used for each execution from FlexTRADER audit logs and the OMS order history. Each algorithm was then classified using the mapping table developed for the Field 27 fix. For a small number of orders where audit logs were insufficient to reconstruct the algorithm classification, a conservative determination was used: Field 27 was populated as "ALGO" (indicating algorithmic involvement in both decision and execution), with an explanatory note in the submission commentary.

The CSSF acknowledged receipt of all corrective submissions in July 2023.

Phase 4: Remediation Response to the CSSF (Weeks 20–26)

Priya led the drafting of Meridian's formal response to the CSSF. The response:

  1. Root cause analysis: A clear explanation of both root causes, without minimisation. The response explicitly acknowledged that the Field 27 error had existed since go-live in 2018, representing five years of incomplete reporting. The response noted that this was an implementation error, not an intentional omission, and that it was consistent with industry-wide errors identified in ESMA's 2022 common errors report.

  2. Quantification: Full quantification of the affected report populations, including the broader historic scope beyond the CSSF's review period.

  3. Corrective submissions: Confirmation of corrective report submission for all affected transactions in the review period, with the submission dates and Unavista reference numbers.

  4. Forward-looking remediation: Description of the ARM configuration changes, OMS extract changes, and pre-submission validation layer, with evidence of testing and deployment dates.

  5. Governance enhancements: Description of new controls: (a) quarterly data quality review of transaction reporting metrics; (b) annual ARM configuration review; (c) LEI renewal calendar management; (d) training programme for compliance operations staff on transaction reporting data quality.

Phase 5: CSSF Response and Outcome (August 2023)

The CSSF response letter, received in August 2023, noted:

"The CSSF has reviewed Meridian Asset Management's root cause analysis and remediation programme. The CSSF considers the response to be comprehensive and the remediation measures to be adequate to address the identified data quality failures. The CSSF notes with approval that Meridian submitted corrective transaction reports for the full scope of affected transactions identified in both the CSSF's review period and the broader historic period. The CSSF will monitor Meridian's transaction reporting quality in subsequent reporting periods. Meridian should be aware that recurring data quality failures of the type identified may be treated as supervisory priority findings in future reviews."

No financial penalty was imposed. The CSSF did not escalate to formal proceedings. Priya understood that the outcome reflected two factors: the genuinely systemic (rather than intentional) nature of the errors, and the comprehensiveness of Meridian's response.

The ARM Upgrade in Detail

One of Priya's recommendations that had the most lasting impact was Meridian's decision to upgrade its ARM contract from a basic submission service to a premium data quality management tier. The upgraded service provided:

Real-time field validation: Every field in the 65-field template was validated against current ESMA rules before submission. The ARM flagged errors with specific field-level messages rather than generic rejection codes.

Instrument reference data integration: The ARM automatically cross-referenced the ISIN against ESMA's FIRDS (Financial Instrument Reference Data System) database to verify instrument classification and venue admission status. Mismatches were flagged before submission.

LEI status checking: The ARM queried GLEIF in real time for every LEI in the report (Field 1, 2, 3, 7, and all counterparty fields). Lapsed or invalid LEIs were flagged immediately.

Quality dashboard: A compliance-facing dashboard showing daily, weekly, and monthly data quality metrics: acceptance rate, rejection rate by field, and error trend over time.

Exception workflow: A web-based workflow tool for the compliance operations team to review, correct, and resubmit rejected reports, with full audit trail.

The cost of the upgrade was approximately EUR 85,000 per annum — a small fraction of the management time and reputational risk consumed by the ESMA data quality review.

"This is the right lesson," Priya told Meridian's COO at the close-out meeting. "The ARM is not a passive pipe. It's an active quality control layer. The firms that treat it as a pipe get the error rates you had. The firms that use the full validation capability catch most of their problems before they become regulatory findings."

Lessons Learned

For Transaction Reporting Operations

1. The go-live implementation deserves ongoing scrutiny. Meridian's Field 27 error was an implementation decision made in 2017 and never reviewed. As ESMA's guidelines have evolved and as the regulator's automated validation has become more sophisticated, errors that were initially invisible have become detectable. Firms should periodically re-examine the data mapping decisions made at MiFID II go-live.

2. Algorithm classification requires cross-functional ownership. The Field 27 error could not be fixed by the compliance team alone — it required collaboration between portfolio management, trading technology, and compliance. Transaction reporting governance must include technology and trading teams, not just compliance.

3. LEI lifecycle management is a compliance function. The lapsed LEI error is preventable with basic entity management: a calendar reminder, an annual GLEIF check, and clear ownership. For multi-entity firms, LEI management should be treated as a formal process with documented ownership.

4. ARM validation rules should be fully enabled. Many ARM services offer validation capability that is not activated by default. Firms should review their ARM configuration to ensure that all available validation rules are active.

For RegTech Strategy

5. Data quality monitoring is not optional. ESMA's automated quality assessment identified errors that had existed for five years. Firms that monitor their own data quality proactively — using ARM dashboards, pre-submission validation, and reconciliation tools — detect and fix these errors before regulators do.

6. Corrective submissions, though painful, demonstrate good faith. The CSSF's positive response to Meridian's outcome reflected the comprehensiveness of the corrective report programme. Supervisors treat voluntary, comprehensive disclosure more favourably than partial or minimised responses.

Discussion Questions

  1. Meridian's Field 27 error existed since MiFID II go-live in January 2018 but was not identified until ESMA's 2022 data quality review — a period of approximately four years. What internal quality controls, had they existed, might have detected this error earlier? Consider both technical controls (ARM validation, reconciliation) and process controls (periodic reporting reviews, regulatory update monitoring).

  2. Priya recommended that Meridian submit corrective reports not only for the formal CSSF review period (January 2021–June 2022) but also for the broader historic period extending back to go-live. Evaluate the legal and regulatory rationale for this approach. What are the arguments for and against a more limited corrective submission restricted to the review period only?

  3. The upgraded ARM service cost EUR 85,000 per annum and prevented regulatory issues that ultimately consumed significantly more in management time, legal costs, and reputational risk. What framework would you use to make the business case for enhanced ARM services to a CFO who views compliance infrastructure as a cost centre?

  4. Compare the root causes of Meridian's transaction reporting failures (Case Study 2) with Cornerstone's best execution failures (Case Study 1). Both firms built compliant frameworks at MiFID II go-live and then failed to maintain them. What organisational structures or governance arrangements might have prevented both sets of failures? Does the RegTech industry offer solutions that address the maintenance problem, not just the initial implementation?