Industries/Fintech & Payments/AI fraud classification
AI fraud classification
AI fraud detection is carved out of AI Act Annex III §5(b) — but every other regulator still wants per-decision evidence: PSD2 Art. 95 operational risk, DORA Art. 17/18 incident classification, AMLD obligations on STR/SAR drafting, FCA + BaFin + DNB supervisory inquiries. Promethean records every flagged-or-cleared transaction as an L12 entry with model identity + spec hash + verdict.
What this is
AI fraud classification runs in real time over transactions: card payments, account opens, transfers, top-ups. The classifier outputs a verdict (approve / review / decline) + confidence score + (sometimes) a rationale. Volume runs from 100k to tens of millions of decisions per month at fintech SMB scale.
The regulatory pressure isn't AI Act high-risk classification — fraud is carved out of §5(b) — but the per-decision evidence demand still attaches via three routes: PSD2 Art. 95 operational + security risk management, DORA Art. 17/18 when the model misbehaves and triggers an ICT-related incident, AMLD when fraud-pattern detection cascades into a Suspicious Activity Report.
Promethean records each fraud-classification decision as an L12 entry. The closed-enum output schema (typically: approve / review / decline + confidence band) bounds the model — output not in the enum triggers the deterministic fallback. Per-entry spec hash + model identity make supervisor 'which model decided this specific flag?' answerable in seconds.
Regulatory pressure specific to AI fraud classification
PSD2 Art. 95 — operational + security risk management
PSPs must establish a framework with appropriate mitigation measures + control mechanisms to manage operational + security risks of payment services.
Official source ↗DORA Art. 17–18 — ICT-related incident management + classification
Financial entities must classify ICT-related incidents by impact criteria. When AI fraud detection misbehaves at scale (false-positive surge, model drift), the resulting customer-impact incident falls under DORA.
Official source ↗AMLD 6 Art. 8 — risk management + suspicious activity
Obliged entities must apply customer due diligence + report suspicious transactions to the FIU. AI fraud signals are increasingly part of the input to SAR triage.
Official source ↗EU AI Act Annex III §5(b) — creditworthiness (fraud-detection carved out)
Credit-scoring AI is high-risk but fraud-detection AI is explicitly carved out. Fraud-AI still falls under general AI Act transparency (Art. 50 where applicable) + governance expectations.
Official source ↗How Promethean addresses this
Bounded output (no free-text decisions)
Spec declares the outputSchema as a closed enum (approve / review / decline) plus confidence band. Output not matching triggers fallbackBehavior. The L12 entry records schemaValid + fallbackTriggered explicitly.
Model identity per decision
Each L12 entry carries modelIdentity (provider/model/version). Sudden model swaps in production are visible in the chain — the supervisor sees the modelIdentity transition at entry id N.
DORA 24h incident notification timeline
When fraud-AI behaviour deteriorates (e.g. false-positive spike), the chain provides the precise time window via recordedAtIso. fallbackTriggered + schemaValid counts over the window give the incident-impact metric DORA Art. 18 demands.
STR / SAR narrative drafting (when used)
If you use AI to draft SAR narratives, that's a separate spec (drafter category) with always-human reviewer gate. The L12 entry binds the narrative to the compliance officer who signed it.
Multi-tenant fraud-AI (PSP serving merchants)
R4 tenantId field per L12 entry lets a PSP filter its chain by merchant. Each merchant can be issued a per-tenant audit bundle for their own supervisor inquiries without seeing other merchants' decisions.
What this looks like in practice
Hypothetical: BNPL operator with model-drift incident under DORA
A BNPL operator's fraud classifier drifts over a 10-day window — false-positive rate climbs from 0.8% to 4.1% as merchant traffic mix shifts. Customer complaints spike; the operator hits DORA's 'significant incident' threshold (>10% of customers materially affected over 24h). Art. 17 demands an incident-management process; Art. 19 requires 24h early warning + 72h notification. Without Promethean: weeks reconstructing what the model was doing, what specVersion was deployed, where the drift started. With Promethean: chain-export filtered to the affected window; specHash + modelIdentity confirm no silent model swap; recordedAtIso pinpoints when fallback firings spiked; the notification is filed against verifiable data, not narrative reconstruction.
Frequently asked
Fraud AI is carved out of AI Act Annex III §5(b). So we don't need any of this, right?
Wrong. The carve-out means fraud-AI isn't high-risk under the AI Act Annex III creditworthiness category specifically. But PSD2 Art. 95 still applies (operational risk). DORA still applies if you're a financial entity. AMLD still applies when fraud-AI feeds STR/SAR pipelines. National competent authority guidance + supervisor inquiries demand per-decision evidence regardless of the Annex III status. The carve-out is narrower than people read it.
We have a SOC and Datadog logs already. What does Promethean add?
Application logs are operator-editable. A regulator can't independently verify that the Datadog stream wasn't post-edited. The L12 chain is hash-chained + signed + OTS-anchored — retroactive edits are detectable (verify.mjs reports the break). For fraud-AI specifically: when a chargeback dispute lands months later, you can prove what your model output, under what configuration, at the exact decision moment. Datadog/Splunk are observability; Promethean is evidence.
How does this work with our existing chargebacks / disputes pipeline?
The L12 chain is the decision-side ledger; chargebacks land separately on the operator side (typically through the acquirer/scheme network). Join chargebacks back to the chain via the inputHash (which is computable from the transaction identifiers). The result: per-decision fraud-classification data joined to confirmed-fraud outcome data — the foundation of the fraud-rate metrics the EBA fraud-reporting GL/2020/01 wants.
Decision volume is 5M+ per month. Does Promethean handle that?
Scale tier supports up to 5M entries/month; Enterprise supports more with custom configuration. At very high volumes, the typical pattern is to record the AI's *consequential* decisions (flags / declines / step-ups), not every transaction passed through. Approve-without-friction decisions can be sampled or aggregated; the chain stays meaningful for what regulators actually inspect.