CONSOB MiFIR transaction reporting in Italy

Every Italian-authorised investment firm files a MiFIR transaction report to CONSOB the business day after the trade — and the reporting rules changed under the hood in 2024 while the surface-level obligation stayed the same. The duty flows from Article 26 of MiFIR — Regulation (EU) 600/2014 — and reaches every transaction in a financial instrument admitted to trading on an EU venue. The reports feed ESMA’s EU-wide transaction-reporting database, used for market-abuse surveillance across all member states, not just Italy. This piece walks through the legal basis, the field-level mechanics, the Italian portal specifics, where reporting projects actually lose time, and how the MiFIR Review changes what firms report.

1. Legal basis

• Regulation (EU) 600/2014 (MiFIR) — Article 26 sets the transaction-reporting obligation itself.
• Commission Delegated Regulation (EU) 2017/590 (“RTS 22”) — the implementing technical standard specifying the reportable fields, data standards and validation rules.
• Regulation (EU) 2024/791 (the “MiFIR Review”) — published in the Official Journal on 8 March 2024, in force from 28 March 2024, amending Articles 25 and 26 MiFIR and mandating ESMA to revise RTS 22 in consequence.
• ESMA’s MiFIR Transaction Reporting Guidelines — the operational reference used across all national competent authorities, including CONSOB.
• CONSOB’s Regolamento Mercati and dedicated reporting instructions — the Italian operational layer sitting on top of the EU framework.

2. Who files

• Italian-authorised investment firms (SIMs) executing transactions in financial instruments.
• Credit institutions when providing investment services in scope of MiFID II.
• Branches of EU investment firms operating in Italy, for transactions executed through the branch.
• Branches of third-country firms established in Italy, where in scope under Article 26(5) MiFIR.

The reporting duty sits with the executing firm. If a firm transmits an order to another firm for execution rather than executing it itself, Article 26(4) MiFIR sets out residual notification cases — the transmitting firm can rely on the receiving firm’s report only if specific conditions on the transmission are met, and firms frequently get this allocation wrong when outsourcing execution.

3. What is reported

A MiFIR transaction report under RTS 22 carries around 65 distinct fields per transaction, built on a uniform EU-wide XML schema. The headline groups:

• Reporting-party LEI (Legal Entity Identifier).
• Buyer / seller identification — LEI for legal entities, a national identifier (see below) for individuals.
• Decision-maker and executing-trader identification, including for algorithmic execution.
• Instrument identification — ISIN, CFI code, and underlying identifiers for derivatives.
• Transaction details — date, time (to microsecond precision for venue-matched trades), price, quantity, venue, currency.
• Buy/sell indicator, trading capacity (dealing on own account vs matched principal vs agency).
• Waiver flags and other special-purpose indicators (e.g. short-selling flag).

4. Cadence and channel

• Frequency: daily — transactions executed on day T are reported by close of business on T+1.
• Format: XML, validated against the ESMA RTS 22 schema.
• Channel: CONSOB’s transaction-reporting infrastructure, reached either by direct XML upload or through an Approved Reporting Mechanism (ARM) authorised under MiFID II Article 65.
• Acknowledgement and correction: CONSOB returns validation results — accepted, rejected, or flagged for review — within a defined processing window; rejected reports must be corrected and resubmitted, and firms should track their own internal correction-rate metric as a data-quality signal.

5. Direct reporting vs through an ARM

As with the French AMF equivalent, a firm either submits XML directly to CONSOB’s systems or routes through a regulated ARM, which handles schema validation, formatting and submission on the firm’s behalf. Most mid-tier Italian SIMs use an ARM because building and maintaining direct RTS 22-compliant XML generation in-house is a meaningful ongoing engineering cost; larger institutions with existing market-data infrastructure more often submit directly. Either way, the reporting firm remains legally responsible for the accuracy and timeliness of the data — using an ARM does not transfer the Article 26 obligation.

6. Where data-quality work concentrates

Italian-specific points that consistently cause friction:

• Codice Fiscale handling — for Italian-resident individuals, RTS 22 accepts the Codice Fiscale as the national client identifier; the format must match the ESMA-defined country-specific identifier structure exactly, and a mismatched checksum is a common rejection cause.
• Country-of-residence determination — this drives which national identifier scheme applies to a given counterparty, and gets missed most often for clients who moved residence after onboarding without a KYC refresh trigger.
• CONSOB’s own validation layer — sits on top of the baseline ESMA RTS 22 validation, so a report that passes generic EU schema checks can still be rejected on an Italy-specific rule.

7. Three worked examples

• Scenario 1 — Retail client who relocated. An Italian SIM’s client moves from Italy to France mid-year but the onboarding record is never refreshed. Rule: RTS 22 ties the national-identifier field to current country of residence, not country at onboarding. Action: the firm’s compliance team builds a periodic residence-refresh check into its KYC-review cycle rather than relying on a one-time onboarding capture. Outcome: subsequent transaction reports carry the correct identifier scheme and stop generating rejections tied to a stale residence field.
• Scenario 2 — Order transmitted to another firm for execution. A smaller SIM transmits a client order to a larger firm for execution rather than executing in-house. Rule: Article 26(4) MiFIR lets the transmitting firm rely on the executing firm’s report only where the transmission meets specific conditions (correct counterparty and instrument data passed, and a written agreement covering the arrangement). Action: the transmitting firm checks its execution agreement against those conditions before assuming no report is needed on its side. Outcome: the firm avoids a reporting gap that would otherwise surface only when CONSOB cross-checks the two firms’ data.
• Scenario 3 — OTC derivative with an ambiguous underlying. A firm executes an OTC derivative whose underlying instrument mapping is unclear between two plausible ISINs. Rule: RTS 22’s instrument-identification fields require a single, unambiguous underlying reference. Action: the firm builds a reference-data resolution step into its pre-submission validation, rather than letting the ambiguity reach CONSOB and trigger a rejection cycle. Outcome: the report clears on first submission instead of round-tripping through a correction.

8. The MiFIR Review changes what gets reported

Regulation (EU) 2024/791 — the MiFIR Review — entered into force on 28 March 2024 and amended Articles 25 and 26 MiFIR, including a revised scope for reporting certain OTC derivatives now brought within the post-trade transparency framework. In consequence, ESMA has been revising RTS 22 itself (Commission Delegated Regulation (EU) 2017/590), consulting on the updated technical standards and preparing to submit a revised draft to the European Commission. Firms should expect the specific fields and validation rules to be refreshed rather than the Article 26 obligation being replaced wholesale — track ESMA’s published RTS 22 revision materials directly rather than assuming today’s field list is final for the life of a reporting build.

9. Interaction with other reporting

MiFIR transaction reporting sits alongside several parallel regimes that firms often build with shared reference data:

• EMIR — derivatives reporting to a trade repository.
• SFTR — securities-financing-transaction reporting to a trade repository.
• Banca d’Italia Segnalazioni — prudential and statistical supervisory reporting.
• COREP-IFR — quarterly prudential reporting for investment firms under the IFR/IFD regime.

ESMA’s ongoing “report once” work aims to eventually merge the MiFIR, EMIR and SFTR reporting templates into a single structure — see our explainer on that reform for the projected timeline.

10. FAQ

11. What to do, today

• If you are scoping a new SIM authorisation, build the transaction-reporting layer alongside the licensing dossier — it goes live the moment the licence is granted, not after a grace period.
• Decide direct-reporting vs ARM early, based on your in-house engineering capacity to maintain a schema that changes periodically.
• Build the counterparty reference-data layer — LEI, Codice Fiscale, country of residence — once, and reuse it across MiFIR, EMIR and SFTR rather than maintaining parallel copies.
• Wire a periodic residence-refresh check into your KYC cycle so the national-identifier field doesn’t drift stale between onboarding and a later relocation.
• Track ESMA’s RTS 22 revision work under the MiFIR Review so your reporting build doesn’t calcify around a schema that is being actively updated.

Related: ESMA ‘report once’ reform · CONSOB MiFID II investment firm · AMF MiFIR France · Investment firm Spain