Control template: MiFID II / MiFIR (transaction reporting + record-keeping)

Status: Public Beta · Version: mifid-ii/v0.1.0-beta

A bundle of CALM control snippets covering the architecturally enforceable subset of MiFID II (Directive 2014/65/EU) and MiFIR (Regulation (EU) 600/2014), with emphasis on RTS 22 (transaction reporting), RTS 25 (clock synchronisation), and the record-keeping obligations under Art. 16 + Art. 25. You copy these into your *.calm.json files on the nodes that execute, route, record, or report investment-service activity.

Who MiFID II applies to

EU and UK investment firms (and their subsidiaries / branches) providing investment services or performing investment activities under MiFID II Annex I. Common categories: - Banks operating an investment-services division - Independent investment firms (brokers, dealers, asset managers) - Trading venues (RM, MTF, OTF) and their operators - Systematic Internalisers (SI) - Approved Reporting Mechanisms (ARMs) and Approved Publication Arrangements (APAs)

Brexit note: UK firms operate under the UK's onshored regime (UK MiFIR + the FCA's Handbook), substantively aligned with EU MiFID II at the time of writing but increasingly divergent. This template uses the EU naming conventions; the architectural surface is substantially the same under UK rules. Confirm specifics with your compliance team.

What this template covers

MiFID II / MiFIR citation	Architectural surface	Control alias
RTS 22 Art. 2 + Annex I	Transaction-report audit envelope	`mifid-audit-fields`
Directive Art. 16(7)	Trade-record retention (≥5 years)	`mifid-trade-record-retention`
Directive Art. 16(6)	Order record-keeping	`mifid-order-record-keeping`
Directive Art. 27	Best-execution evidence	`mifid-best-execution-evidence`
RTS 25 Art. 2 + Annex	Clock synchronisation (UTC + divergence + granularity)	`mifid-clock-synchronization`
RTS 22 Art. 15	Transaction reporting submission (ARM → NCA)	`mifid-transaction-reporting`
RTS 22 Annex I §3–5	Investor identification (LEI/concat)	`mifid-investor-identification`
RTS 22 Annex I §41	Instrument reference data (ISIN / CFI / venue)	`mifid-instrument-reference-data`
RTS 22 Annex I §28 + Art. 1(5)	Algo / decision-maker identification	`mifid-decision-maker-identification`
Directive Art. 16(11) + Delegated Reg. Art. 76(11)	Phone / electronic-communication recording	`mifid-electronic-communication-recording`

10 controls covering the architecturally enforceable subset. Algorithmic trading (Art. 17 / RTS 6), pre/post-trade transparency (RTS 1 / RTS 2), and SI quoting (RTS 1) are NOT in this template — they're specialised regimes; sub-templates may follow.

The "MiFID-scope" pattern

A node is MiFID-scope if it executes, routes, records, or reports investment-service activity (trades, orders, quotes, decisions to deal). Tag those nodes:

{
  "unique-id": "execution-router",
  "node-type": "service",
  "name": "Execution Router",
  "metadata": {
    "mifid-in-scope": true,
    "mifid-activity": "execution-on-own-account",
    "data-classification": "regulated-financial"
  }
}

Then attach the relevant controls below.

Control snippets

Copy each block under the controls key of the node it applies to.

RTS 22 — Audit envelope (`mifid-audit-fields`)

Per-node. The 65-field RTS 22 envelope must be populated on every reportable transaction. This control declares the minimum set the firm's audit pipeline emits per execution.

"mifid-audit-fields": {
  "description": "MiFID II RTS 22 Annex I — audit envelope on every reportable transaction. Failure to populate required fields blocks the ARM submission.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/mifid-audit-fields",
      "config": {
        "control-id": "mifid-audit-fields",
        "required-fields": [
          "client_id",
          "venue_id",
          "decision_maker_id",
          "executing_trader_id",
          "isin",
          "trade_date",
          "trading_capacity",
          "buy_sell_indicator",
          "quantity",
          "price",
          "currency",
          "venue_code",
          "transaction_reference_number"
        ],
        "audit-trail-document-url": "https://internal.example.com/mifid/audit-fields"
      }
    }
  ]
}

Continuity note: the existing requirement-url path (/catalog/req/mifid-audit-fields) matches what the demo traderx-trading CALM already uses. This template formalizes the reference shape; firms already using it keep their authoring.

Directive Art. 16(7) — Trade-record retention (`mifid-trade-record-retention`)

Per-node. Minimum five years; some NCAs require seven for specific activity (e.g., investment advice). Tune to your firm's record-retention policy.

"mifid-trade-record-retention": {
  "description": "MiFID II Directive Art. 16(7) — trade records retained for at least 5 years (some NCAs require 7).",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/mifid/trade-record-retention",
      "config": {
        "control-id": "mifid-trade-record-retention",
        "retention-days": 1827,
        "storage-immutable": true,
        "storage-location": "s3-with-object-lock",
        "indexing-by": ["transaction_reference_number", "client_id", "trade_date"]
      }
    }
  ]
}

Directive Art. 16(6) — Order record-keeping (`mifid-order-record-keeping`)

Per-node. Pre-trade order data (placed, amended, cancelled) plus execution details.

"mifid-order-record-keeping": {
  "description": "MiFID II Directive Art. 16(6) — record of all services, activities, and transactions sufficient to allow the competent authority to reconstruct each key stage.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/mifid/order-record-keeping",
      "config": {
        "control-id": "mifid-order-record-keeping",
        "captured-events": ["order-placed", "order-amended", "order-cancelled", "order-rejected", "order-routed", "execution-received"],
        "retention-days": 1827,
        "destination": "centralized-immutable-store"
      }
    }
  ]
}

Directive Art. 27 — Best execution evidence (`mifid-best-execution-evidence`)

Per-node. The firm must evidence that it took all sufficient steps to obtain the best possible result for the client.

"mifid-best-execution-evidence": {
  "description": "MiFID II Directive Art. 27 — best execution. Firm records the factors considered, venues compared, and the rationale for the selected execution path.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/mifid/best-execution-evidence",
      "config": {
        "control-id": "mifid-best-execution-evidence",
        "factors-recorded": ["price", "cost", "speed", "likelihood-of-execution-and-settlement", "size", "nature"],
        "venue-comparison-required": true,
        "rationale-captured-per-execution": true,
        "review-frequency": "annual",
        "policy-document-url": "https://internal.example.com/mifid/best-execution-policy"
      }
    }
  ]
}

RTS 25 — Clock synchronisation (`mifid-clock-synchronization`)

Per-node. Operators of trading venues and their members must synchronise business clocks used to record event timestamps to UTC, with divergence and granularity tuned to activity type.

"mifid-clock-synchronization": {
  "description": "MiFID II RTS 25 — business clocks used to record reportable-event timestamps synchronised to UTC. Maximum divergence and timestamp granularity depend on activity type per RTS 25 Annex.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/mifid/clock-synchronization",
      "config": {
        "control-id": "mifid-clock-synchronization",
        "reference-source": "ntp-stratum-1-or-ptp",
        "maximum-divergence-microseconds": 100,
        "timestamp-granularity-microseconds": 1,
        "monitoring": "drift-alarms-on-divergence",
        "alerting-target": "ops-soc@example.com",
        "activity-class": "matched-trade-on-venue"
      }
    }
  ]
}

RTS 25 prescribes different divergence + granularity expectations by activity type (HFT, gateway-to-gateway venue, voice trading, etc.). Tune the values to your activity profile.

RTS 22 Art. 15 — Transaction reporting (`mifid-transaction-reporting`)

Graph-level. The submission pipeline from the firm to the NCA via an ARM.

"metadata": {
  "controls": {
    "mifid-transaction-reporting": {
      "description": "MiFID II RTS 22 Art. 15 — transaction reports submitted to the firm's home NCA via an Approved Reporting Mechanism (ARM) no later than T+1.",
      "requirements": [
        {
          "requirement-url": "https://archrails.io/catalog/req/mifid/transaction-reporting",
          "config": {
            "control-id": "mifid-transaction-reporting",
            "arm-name": "Acme Reporting Services Ltd.",
            "arm-leid": "549300ABCDEFGHIJKLMN",
            "home-nca": "FCA",
            "submission-deadline-business-days": 1,
            "rejection-handling-process-url": "https://internal.example.com/mifid/reporting-rejections",
            "monthly-reconciliation-required": true
          }
        }
      ]
    }
  }
}

RTS 22 Annex I §3–5 — Investor identification (`mifid-investor-identification`)

Per-node. Required for every reportable transaction. Natural-person identification follows the CONCAT rule; legal persons use LEI.

"mifid-investor-identification": {
  "description": "MiFID II RTS 22 Annex I §3–5 — client identification on every reportable transaction. Natural persons use CONCAT; legal persons use LEI.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/mifid/investor-identification",
      "config": {
        "control-id": "mifid-investor-identification",
        "natural-person-identifier": "concat-per-rts-22",
        "legal-person-identifier": "lei",
        "lei-validation-source": "gleif",
        "missing-identifier-policy": "block-execution",
        "encryption-at-rest": true
      }
    }
  ]
}

RTS 22 Annex I §41 — Instrument reference data (`mifid-instrument-reference-data`)

Per-node.

"mifid-instrument-reference-data": {
  "description": "MiFID II RTS 22 Annex I §41 — instrument reference data (ISIN, CFI, MIC) populated on every reportable transaction.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/mifid/instrument-reference-data",
      "config": {
        "control-id": "mifid-instrument-reference-data",
        "required-fields": ["isin", "cfi-code", "venue-mic", "instrument-classification"],
        "reference-data-source": "esma-firds",
        "stale-data-tolerance-hours": 24
      }
    }
  ]
}

RTS 22 Annex I §28 — Decision-maker identification (`mifid-decision-maker-identification`)

Per-node. The natural person or algorithm responsible for the investment decision.

"mifid-decision-maker-identification": {
  "description": "MiFID II RTS 22 Annex I §28 + Delegated Reg. Art. 1(5) — investment-decision-maker identification. Natural person (CONCAT) or algorithm (firm-assigned identifier).",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/mifid/decision-maker-identification",
      "config": {
        "control-id": "mifid-decision-maker-identification",
        "natural-person-identifier": "concat-per-rts-22",
        "algorithm-identifier-format": "firm-assigned-stable",
        "algorithm-registry-url": "https://internal.example.com/mifid/algo-registry",
        "missing-identifier-policy": "block-execution"
      }
    }
  ]
}

Directive Art. 16(11) + Delegated Reg. Art. 76(11) — Electronic-communication recording (`mifid-electronic-communication-recording`)

Per-node. Recording of telephone and electronic communications relating to transactions.

"mifid-electronic-communication-recording": {
  "description": "MiFID II Directive Art. 16(11) + Delegated Reg. (EU) 2017/565 Art. 76(11) — recording of phone calls and electronic communications relating to transactions intended to result in a deal. Retained at least 5 years (7 for some activities or where the NCA requires).",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/mifid/electronic-communication-recording",
      "config": {
        "control-id": "mifid-electronic-communication-recording",
        "channels-covered": ["voice", "email", "chat", "instant-messaging"],
        "retention-days": 1827,
        "storage-immutable": true,
        "client-notification-required": true
      }
    }
  ]
}

What the engine enforces

Same constraint engine that handles PCI / DORA / SOX / HIPAA / SOC 2 / your own controls. Per-rule behavior:

Presence-shape rules (audit-fields, investor-identification, best-execution-evidence, etc.): the engine fires a finding when a node tagged mifid-in-scope: true does NOT declare the corresponding control.
Set-required rules (required-fields on audit-fields, on instrument-reference-data, on order-record-keeping): the engine enforces that the firm's audit pipeline emits each listed field.
Value-constrained rules (retention-days, divergence-microseconds, granularity-microseconds): the engine checks the config value.

All deterministic — pure function over your CALM JSON. Verdicts are replayable byte-for-byte. The 65-field RTS 22 envelope check specifically is the strongest demonstration of architectural enforcement we have: missing a single field in the audit pipeline blocks the diff, surfacing the gap before it becomes a regulator rejection at T+1.

Auto-include during bootstrap (coming)

A future release will let archrails bootstrap detect MiFID-scope repos (asset managers, brokerage backends, execution venues) and offer to auto-include this template.

Versioning

This is mifid-ii/v0.1.0-beta. Pre-1.0 = beta. Bumps to v1.0.0 per the GA criteria above. Updates as MiFID II RTS amendments, ESMA Q&As, or NCA guidance materially refine the architectural surface.

Out of scope for this template

Algorithmic trading controls (Directive Art. 17 / RTS 6) — specialised regime for algorithmic and HFT firms; pre-trade controls, kill switches, market making, capacity testing. Sub- template may follow if customers ask.
Pre/post-trade transparency (MiFIR Art. 3+10 / RTS 1 / RTS 2) — trading venues, SIs, and APAs. Sub-template may follow.
Product governance (Directive Art. 16(3) + Art. 24(2)) — target market definition, ongoing review. Mostly process / governance, not architectural.
Conduct of business / suitability (Directive Art. 25) — client onboarding, KYC, suitability assessments. Process / procedural, not architectural.
Market-abuse surveillance (MAR, separate from MiFID II) — there's a separate framework (Market Abuse Regulation, EU 596/2014) with its own architectural surface.

For those surfaces, pair this template with your MiFID II compliance framework and engage an FCA / CySEC / NCA-experienced compliance consultant.

Control template: MiFID II / MiFIR (transaction reporting + record-keeping)

Who MiFID II applies to

What this template covers

The "MiFID-scope" pattern

Control snippets

RTS 22 — Audit envelope (mifid-audit-fields)

Directive Art. 16(7) — Trade-record retention (mifid-trade-record-retention)

Directive Art. 16(6) — Order record-keeping (mifid-order-record-keeping)

Directive Art. 27 — Best execution evidence (mifid-best-execution-evidence)

RTS 25 — Clock synchronisation (mifid-clock-synchronization)

RTS 22 Art. 15 — Transaction reporting (mifid-transaction-reporting)

RTS 22 Annex I §3–5 — Investor identification (mifid-investor-identification)

RTS 22 Annex I §41 — Instrument reference data (mifid-instrument-reference-data)

RTS 22 Annex I §28 — Decision-maker identification (mifid-decision-maker-identification)

Directive Art. 16(11) + Delegated Reg. Art. 76(11) — Electronic-communication recording (mifid-electronic-communication-recording)