What is MiCA transaction monitoring?

MiCA (Regulation (EU) 2023/1114) does not use the phrase "transaction monitoring" as a single defined term. The closest operative obligations sit in Title V Chapter 2 (Articles 66-73), which govern how a crypto-asset service provider (CASP) must run its operations day to day: general conduct (Art. 66), prudential safeguards (Art. 67), governance and AML/CFT systems (Art. 68), reporting to competent authorities (Art. 69), safekeeping of client assets (Art. 70), complaints handling (Art. 71), conflicts of interest (Art. 72), and outsourcing (Art. 73).

Which MiCA article requires an audit trail for automated decisions?

There is no single MiCA article titled 'audit trail.' Article 68 requires CASPs to have governance arrangements including AML/CFT detection and prevention systems, and ICT resilience aligned with DORA. Article 69 requires information to be made available to competent authorities. Together these create a practical need for a verifiable decision record, but the exact record-keeping mechanism is an implementation choice, not a specific article's literal text.

Does MiCA require pre-execution enforcement, or is monitoring after the fact enough?

MiCA's operating-conditions articles (66-73) describe outcomes a CASP must achieve (honest conduct, AML detection, safekeeping, complaint handling) without mandating a specific software architecture. In practice, detecting a violation after a transaction has already settled does not prevent the violation, and does not satisfy the spirit of Art. 68's 'detect and prevent' language as cleanly as a control that runs before execution.

When did MiCA enforcement for crypto-asset service providers start?

CASP authorisation and the Title V operating conditions became enforceable on 1 July 2026, the date used throughout Intaglio's own compliance tooling.

MiCA Title V · Chapter 2 · Articles 66-73

MiCA Article 66-73 transaction monitoring: what enforcement means

MiCA (Regulation (EU) 2023/1114) Title V, Chapter 2 sets the ongoing operating obligations for crypto-asset service providers. This page breaks down what Articles 66 through 73 actually require, and why detecting a policy violation after it happens is a different (and weaker) control than enforcing the policy before the transaction executes.

What Articles 66-73 require, article by article

Art. 66

General obligations

Act honestly, fairly, professionally. Clear, fair, not-misleading client communication. Risk warnings.

Art. 67

Prudential safeguards

Minimum own-funds or insurance requirement, scaled to service type (advisory vs. custody/exchange).

Art. 68

Governance arrangements

Management-body suitability. AML/CFT detection and prevention systems. ICT resilience aligned with DORA.

Art. 69

Information to competent authorities

Reporting obligations to national regulators.

Art. 70

Safekeeping of client assets

Segregation of client crypto-assets and funds, sub-custody rules, client disclosure.

Art. 71

Complaints-handling

A documented complaints procedure, supplemented by ESMA RTS.

Art. 72

Conflicts of interest

Annual review, public disclosure, scrutiny of listing decisions and proprietary trading.

Art. 73

Outsourcing

EBA outsourcing guidelines applied by analogy; DORA Art. 28-30 for ICT outsourcing.

[VERIFY] Article summaries above are paraphrased from public MiCA commentary and regulator/law-firm summaries, not the consolidated official text. Confirm exact wording against EUR-Lex Regulation (EU) 2023/1114 before relying on this for a compliance filing.

Where 'transaction monitoring' actually lives in MiCA

MiCA does not contain an article literally titled "transaction monitoring." The practical monitoring/detection obligation is implied by Article 68's requirement that a CASP have "systems, procedures and arrangements" to detect and prevent money laundering and terrorist financing, read alongside Article 69's reporting duties to competent authorities.

[VERIFY] Which specific sub-clause of Art. 68 maps to real-time transaction screening versus periodic AML review has not been confirmed clause-by-clause in this pass. Treat this as directional, not a legal citation.

Enforcement in an agent's request path

For an AI agent that initiates payments or transfers, "enforcement" means the policy check happens in the request path itself — before the funds move — not as a downstream alert. Intaglio's proxy evaluates every action against an APL policy and returns a decision before forwarding the request:

curl -X POST http://localhost:3001/v1/actions \
  -H "Authorization: Bearer <agent-secret>" \
  -H "Content-Type: application/json" \
  -d '{
    "action": {
      "rail": "x402",
      "amount": { "value": 500, "currency": "USD" },
      "timestamp": "2026-07-06T00:00:00Z"
    }
  }'

A response of DENY means the action is rejected before it reaches the upstream target. A response of REQUIRE_APPROVAL routes the decision to a human before execution can continue. See the x402 enforcement overview for the policy-checked payment flow.

Start enforcing policy today

MiCA CASP enforcement is active as of July 1, 2026.

Open dashboard Read the APL spec