PSD3 fraud-AI explainability — per-decision reproducibility for SCA exemptions

PSD2 has been the law of EU payments since 2018. The proposed successor package was published by the European Commission in June 2023 as two instruments: PSR — the Payment Services Regulation (COM(2023) 366) carrying the substantive fraud + SCA articles, and PSD3 — the Payment Services Directive 3 (COM(2023) 367) covering licensing + supervision of payment institutions. Trilogue reached political agreement November 2025; OJ publication expected H1 2026; PSR applicability roughly 2028. The package was prompted by an EBA review that found the SCA exemption regime opaque, fraud prevention uneven across member states, and dispute resolution inconsistent.

Three articles most directly affect operators running AI-driven fraud detection or risk-based SCA exemptions: PSD2 Article 97 (still operative, SCA mandate), proposed PSR Article 83 (transaction monitoring + fraud detection), and proposed PSR Articles 85–89 (SCA + risk-based exemption documentation). This post is about what those articles actually require, with engineering specificity, and what the audit log has to contain.

PSD2 Article 97 — SCA, still operative

Article 97 PSD2 requires Strong Customer Authentication for three event types: when a payer accesses a payment account online, initiates an electronic payment, or "carries out any action through a remote channel which may imply a risk of payment fraud". SCA itself is the combination of at least two factors from three independent categories: something you know, have, or are.

Where AI enters the article is in the exemption regime. The SCA RTS (Regulatory Technical Standards, Commission Delegated Regulation (EU) 2018/389) allows risk-based and transaction-based exemptions — a payment service provider can skip SCA for a low-risk transaction if its real-time fraud-monitoring score is below a threshold. That score is typically the output of an ML model.

Article 97 + the SCA RTS implicitly require: (a) the fraud-monitoring score is computed per transaction, (b) the threshold is documented, (c) the exemption decision is recorded with enough detail to reconstruct it. PSD2 left much of (c) underspecified. PSD3 tightens this.

Proposed PSR Article 83 — fraud prevention with explainability

The proposed text:

Payment service providers shall have transaction-monitoring mechanisms enabling the detection of unauthorised or fraudulent transactions.

— Proposed PSR (COM(2023) 366) Article 83(1)

Three layers of implementation requirement follow:

• Per-transaction — the mechanism must produce a decision per payment event. Batch screening that runs nightly does not satisfy.
• Explainable — when a decision is contested, the PSP has to be able to articulate why the transaction was flagged or cleared. An ML model that outputs only a score with no feature attribution is not by itself enough.
• Auditable — the supervisory authority can inspect the decisions at any time. The PSP has to be able to retrieve the per-transaction record on demand.

Promethean's RuntimeAISpec for a fraud classifier addresses the first two structurally:

• The category: "classifier" field declares the ML's role. The outputSchema bounds what the model can return — a closed enum like ["approve", "review", "decline"] with a confidence score and a rationale string.
• The specHash committed to each L12 entry makes silent model swaps detectable; a regulator can audit the spec history independently of the operator's claim.

Proposed PSR Articles 85–89 — SCA + exemptions documented per decision

This is the article most relevant to AI explainability. Risk-based and transaction-based exemptions from SCA must be documented with the risk score, exemption category, and the ability to reproduce the decision on demand.

Reproducibility has two senses worth distinguishing:

• Computational determinism — given the same inputs under the same configuration, the same score is produced. This is a model property.
• Audit reproducibility — the audit log captures enough to identify which configuration was active and what the inputs were. This is a logging property.

Most LLM-driven fraud-detection systems do not satisfy computational determinism — temperature, sampling, and model-version drift make exact reproduction hard. The practical answer is to satisfy audit reproducibility: the L12 entry carries the spec hash (model identity + sampling configuration), the input hash (sufficient to identify the inputs without storing them), and the output canonical hash (the actual decision). A regulator running a dispute can verify that the inputs and configuration recorded match what the PSP claims.

Audit fields per fraud decision

Concretely, an L12 entry for a fraud-classification decision in a PSD3-regulated product:

{
  "id": 84291,
  "recordedAtIso": "2026-05-15T14:32:11.000Z",
  "productId": "acme-fintech",
  "specId": "fraud-classifier-v3",
  "specHash": "5b05721a66c6c11d9cf1761a50485b4...",
  "inputHash": "8d277be586c23e193b5f41068992a60...",
  "outputCanonicalHash": "6a3103c3f1ae6f113761ba69fc8350...",
  "category": "classifier",
  "modelIdentity": {
    "provider": "anthropic",
    "model": "claude-sonnet-4-5",
    "version": "2026-05-01"
  },
  "latencyMs": 162,
  "schemaValid": true,
  "reviewerVerdict": null,
  "fallbackTriggered": false,
  "prevHash": "9c34c8634e1bc7095f24d9af8781cf1...",
  "hash": "f8a91c2b3d4e5f6a7b8c9d0e1f2a3b4...",
  "attestation": { "algorithm": "ed25519", "signature": "...", ... }
}

Several PSD3 audit questions this entry answers directly:

• "Which fraud model decided this transaction?" → specId + specHash + modelIdentity. The spec can be retrieved from the workspace, and silent swaps are detectable.
• "What did the model see?" → inputHash — replay against the operator's input store (which is governed by separate GDPR retention rules; the hash itself is not personal data).
• "Did the system fall back to a safe default?" → fallbackTriggered. Proposed PSR Art. 83 expects the PSP to handle model failures gracefully; the fallback-triggered count over time is a directly regulatable property.
• "Was this entry edited after the fact?" → prevHash + attestation. Hash-chain breakage + Ed25519 signature breakage are both detectable by running verify.mjs.

Overlap with DORA Article 28 — third-party risk

Financial entities are also subject to DORA (Regulation (EU) 2022/2554), which in Article 28 requires documented ICT third-party risk management. The model vendor (Anthropic, OpenAI, Azure, etc.) is a third-party ICT provider; the L12 entry's modelIdentity field is part of the evidence that the PSP knows which third-party services it depends on, by transaction. PSD3 and DORA are not mutually exclusive — they layer.

Promethean's framework handoff packets cover both regulators; see the DORA post for the parallel walkthrough.

Overlap with EU AI Act — Annex III §5(b)

The AI Act's Annex III §5(b) classifies as high-risk: "AI systems used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud." Note the carve-out for fraud detection. But §5(c) explicitly includes "AI systems used for risk assessment and pricing in relation to natural persons in the case of life and health insurance".

Practical reading: the AI Act's fraud carve-out is narrow. Many AI systems labelled "fraud detection" actually do creditworthiness or risk-pricing as a by-product. If your fraud model influences credit decisions downstream, you are in §5(b). The L12 chain audit log satisfies both PSD3 and AI Act Article 12 simultaneously.

PSD2 Article 95 — operational + security risk-management

Still operative in PSD2 and re-stated in PSD3: payment service providers must "establish a framework with appropriate mitigation measures and control mechanisms to manage operational and security risks". The L12 chain's cryptographic integrity (hash chain + per-entry signature + OpenTimestamps Bitcoin anchoring) addresses the log-integrity aspect of operational risk. The wider framework (BCP, incident response runbooks) is operator-owned.

Actionable summary

• Classify each AI feature in your payment product against PSD3 Articles 87 + 88. Anything contributing to a per-transaction fraud or exemption decision is in scope.
• Record per-decision: spec hash (model identity + configuration), input hash, output hash, fallback flag, timestamp, signature chain. Promethean's L12 chain gives all six structurally.
• Make the audit trail verifiable independently of your observability stack. PSD3's "on demand" reproducibility requirement assumes the supervisor can verify the trail without going through the PSP's tooling.
• Layer the AI Act Annex III §5(b) requirements on top — the same audit trail satisfies both. Promethean's framework handoff packets cover both regulators.
• Track the SCA-exemption rate and the false-positive rate. These are aggregate properties of the chain that supervisors will ask for; they are computable directly from the audit log.

Promethean ships PSD3-aware framework templates on the Enterprise tier. The Dev tier produces real signed chains you can evaluate locally; paid tiers add hosted anchoring, federation, multi-tenant primitives (for PSPs serving multiple merchants), and the framework handoff packet generator for PSD3 + DORA + AI Act.

Sector-specific guidance