AFM MiFIR transaction reporting in the Netherlands

Every Dutch-authorised investment firm files MiFIR transaction reports to AFM the day after the trade. The obligation flows from Article 26 of MiFIR — Regulation (EU) 600/2014 — and applies to transactions in financial instruments admitted to trading on an EU venue, plus the derivative and index extensions that catch instruments referencing them. The reports feed the market-surveillance database that AFM and ESMA use to detect market abuse, so validation is strict and data-quality follow-up is real. This piece walks through who files, what the report contains, the Dutch specifics — including the BSN privacy overlay — and where implementation projects actually lose time.

1. Legal basis

• Regulation (EU) 600/2014 (MiFIR) — Article 26, the reporting obligation itself
• Commission Delegated Regulation (EU) 2017/590 — the RTS defining the fields, formats and identifier rules
• ESMA Guidelines on transaction reporting — the field-by-field interpretation layer
• AFM policy notices and submission instructions — the Dutch channel mechanics

2. Who files

• Dutch-authorised investment firms (beleggingsondernemingen) executing transactions in financial instruments
• Credit institutions providing investment services under their banking licence
• Netherlands branches of EU investment firms, for transactions executed through the branch
• Branches of third-country firms where in scope

“Executing” is broader than trading on own account: receiving and transmitting an order can leave the reporting obligation with the transmitting firm unless the strict transmission conditions in the RTS are met and documented. Many double-reporting and under-reporting findings trace back to firms assuming transmission relief applies without the paperwork to support it.

3. What is reported

The MiFIR transaction report carries 65 fields per transaction, uniform across the EU. The headline groups: reporting-party LEI; buyer and seller identification; decision-maker and trader identification; instrument identification (ISIN, CFI, underlying); transaction details — date, time, price, quantity, venue, currency; buy/sell indicator; trading capacity; waiver and special-purpose flags such as short-sale and commodity-derivative indicators.

4. Cadence and channel

• Frequency: daily — transactions executed on day T reported no later than close of T+1
• Format: XML against the ESMA schema defined under the RTS
• Channel: AFM’s transaction-reporting portal, by direct XML upload or through an Approved Reporting Mechanism (ARM)
• Acknowledgement: AFM returns file- and record-level validation results; rejected records must be corrected and resubmitted

5. Direct vs through an ARM

Same choice as in France, Italy and the Spanish equivalent: submit XML directly to the supervisor or route through an ARM. Most mid-tier Dutch investment firms use an ARM — it buys schema maintenance, pre-validation and a support desk. Large institutions with existing reporting infrastructure submit directly. Either way, the legal responsibility for completeness and accuracy stays with the investment firm: an ARM contract outsources the plumbing, never the obligation.

6. Worked example — retail equity order

Facts: a Dutch beleggingsonderneming executes a buy order in a listed equity for a Dutch retail client on a Tuesday afternoon. The client is a natural person resident in the Netherlands; the firm deals as agent.

What the rule says: the transaction is reportable under Article 26 by close of Wednesday. The buyer is the client, identified with the national identifier prescribed for Dutch natural persons under the RTS identifier hierarchy; the firm appears with its LEI as executing entity in an agency capacity; the trader who executed and, where relevant, the algorithm that made the investment decision are identified in the decision-maker fields.

What the practitioner does: makes sure onboarding captures the identifier data — nationality, date of birth, the concatenated fallback where no priority identifier exists — before the first trade, because backfilling identifiers after rejection is the single most common cause of late reports. The T+1 clock does not pause for missing reference data.

7. Worked example — OTC derivative without an ISIN

Facts: the same firm writes an OTC derivative for a corporate client. The contract references a listed underlying but is not itself admitted to trading, and no ISIN exists for it at trade time.

What the rule says: instruments traded OTC are reportable where the underlying is admitted to trading on an EU venue. The report must then carry the instrument’s classification and underlying details in place of a simple venue-instrument lookup: CFI code, underlying ISIN, and the reference-data fields the RTS prescribes for off-venue instruments. The corporate client must be identified by LEI — no LEI, no valid report.

What the practitioner does: builds the OTC instrument-reference workflow as its own pipeline rather than forcing OTC trades through the exchange-traded logic, and makes an active, renewed LEI a hard onboarding gate for every legal-entity client. Chasing lapsed LEIs on T+1 mornings is where OTC desks lose their reporting SLA.

8. BSN and the Dutch privacy overlay

The Burgerservicenummer (Citizens’ Service Number) is a sensitive personal identifier under Dutch law, with tightly restricted permissible uses. The RTS requires national identifiers for natural persons following a per-country priority list; the Dutch operational reality is that the BSN is generally not the identifier exposed in external reporting — the RTS-defined alternatives, including the CONCAT construction, are used where the BSN is not an appropriate field to transmit. Calibrate the exact identifier logic against AFM’s operational guidance rather than copying another member state’s mapping: the priority list is country-specific by design.

9. Where data-quality work concentrates

• Counterparty identifier completeness — LEIs for legal entities, correct national identifiers for natural persons, CONCAT fallbacks built to the letter of the RTS
• Decision-maker and trader identification for algo-driven flows — mapping algo IDs consistently across systems and time
• Instrument classification for OTC derivatives where no ISIN exists at trade time
• Country-of-residence and nationality determination, which drives the identifier hierarchy per client
• Reconciliation — periodically comparing what the front-office systems executed against what was actually accepted by AFM, because silent gaps accumulate

10. Interaction with other reporting

The regimes share counterparty and instrument reference data. Firms that build one golden-source reference layer and feed all four spend materially less on change management every time a schema updates.

11. FAQ

12. What to do, today

• Founders scoping a beleggingsonderneming: build the transaction-reporting layer alongside the authorisation dossier, not after grant.
• COOs: decide direct vs ARM submission early — it shapes the build and the run-cost model.
• Data leads: build the counterparty reference layer once and reuse it across MiFIR, EMIR and SFTR.
• Compliance: calibrate BSN and national-identifier handling against AFM’s operational guidance, and reconcile executed vs accepted transactions on a fixed cycle.
• Everyone: track MiFIR Refit — field-mapping decisions made now should anticipate the revised standards.

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