← Industries/Fintech & Payments
Promethean for Fintech & Payments
Neobanks, payment processors, BNPL, lending platforms, and crypto SMBs running LLM-driven fraud, KYC, or risk-scoring. PSD3 + DORA together demand per-decision reproducibility plus tamper-evident incident logs. Promethean ships the evidence layer that satisfies both without a six-month vendor contract.
Who this is for
Compliance + engineering teams in fintech SMBs. Typically:
- Series A–C fintech with 10–100 engineers; 1–4 ML-in-the-loop product features in production.
- Already PSD2-licensed (or pending) under a national competent authority. Preparing for PSD3 entry into force 2026-2027.
- Annual fraud volume in the millions; AI fraud-classifier or risk-scorer hitting between 100k and 5M decisions per month.
- Has a CISO or Head of Compliance; doesn't have dedicated compliance engineering yet.
- Existing observability on Datadog / Grafana / Splunk — but the regulator audit conversation requires more.
The regulatory pressure
Proposed PSR Art. 83 — fraud-prevention explainability
Transaction-monitoring mechanisms in the proposed Payment Services Regulation (COM(2023) 366) must detect unauthorised + fraudulent transactions with reproducible-per-decision logic. AI-driven fraud detection has to surface the reasoning behind any flagged event.
Deep-dive →Proposed PSR Arts. 85–89 — SCA + risk-based exemptions
The PSR proposal carries the SCA + risk-based-exemption regime. Exemptions must be documented per-decision with risk score, exemption category, and reproducibility on demand. (PSD3 / COM(2023) 367 is the companion directive on payment-institution licensing.)
Deep-dive →DORA Art. 17–18 — ICT-related incident management
Financial entities must classify ICT-related incidents by impact + report majors within 24h. When the failing component is an LLM, you need per-decision evidence quickly.
Deep-dive →EU AI Act Annex III §5(b) — creditworthiness
Credit-scoring AI is high-risk; full Chapter II obligations (Articles 9-15) apply. Article 12 record-keeping = per-decision signed log.
Deep-dive →Where LLMs typically run in Fintech & Payments
Real-time fraud classification
Closed-enum classifier producing approve / review / decline per transaction, with a confidence score + rationale. Schema-bound output; reviewer gate fires on low confidence; deterministic fallback (typically decline-all) when the model errors.
Risk-based SCA exemption decisions
Per-transaction risk score that determines whether SCA can be skipped under the PSD2 RTS exemption regime. Each decision needs a recorded score, exemption category, and reproducibility for supervisor inspection.
KYC document extraction
LLM extracts structured fields from passports, utility bills, company filings. Schema-bound output + per-document audit trail; reviewer gate on low confidence to satisfy KYC due-diligence standards.
AML transaction monitoring narrative
LLM drafts the narrative explanation accompanying a SAR / STR filing. Drafter category; reviewer gate always-human (compliance officer signs every filing).
How the substrate maps to your audit
| Your LLM feature | What the regulator asks | Promethean evidence |
|---|---|---|
| Fraud classifier | Which model decided this transaction? Can it be reproduced? | specHash + modelIdentity + inputHash per L12 entry; spec change is hash-detectable. |
| SCA exemption decision | Per-decision risk score + exemption category, retrievable on demand. | outputCanonicalHash binds the exemption verdict; chain export is regulator-runnable. |
| DORA incident notification | When did the AI start misbehaving? How many decisions affected? | Time-bounded chain export with fallbackTriggered + schemaValid counts. |
| KYC extraction | Document seen? Schema valid? Reviewer engaged? | inputHash + reviewerVerdict + schemaValid per L12 entry. |
| AML narrative | Compliance officer signed off; what did they see? | Reviewer-gate always-human + verdict logged in the chain. |
Which Promethean tier fits
Recommended for typical SMBs in Fintech & Payments
Production€499 / month flat
Up to 25 specs · 1M entries / month · hourly OTS anchoring · multi-tenant · federation read-only.
Production tier covers the typical fintech SMB profile: 1–4 active specs (fraud + SCA + KYC + AML narrative), 1M signed entries/month, hourly OTS anchoring (matches DORA's incident-detection latency expectations), multi-tenant (if you serve merchants), federation read primitives (for consortium fraud sharing if applicable). Scale (€1,199/mo) is the upgrade path for federation full + HSM custody (both roadmap) for fintechs preparing for customer-controlled keys.
Larger Fintech & Payments operators with multi-tenant or framework-template needs upgrade to Scale (€1,199 / month flat).
What this looks like in practice
Hypothetical: a €60M-ARR BNPL platform after a PSD3 inspection
A BNPL operator gets a routine supervisory inspection from their national competent authority. The supervisor asks: 'Show us the per-decision evidence for last quarter's risk-based SCA exemptions, and demonstrate the AI fraud classifier is reproducible.' Without Promethean, the engineering team scrambles to export Datadog logs, reconstruct model versions, and assemble a narrative — three weeks of work that probably won't satisfy reproducibility-on-demand. With Promethean, the compliance team exports the relevant L12 chain slice, hands it to the supervisor with verify.mjs, and the supervisor runs `node verify.mjs chain.jsonl --trusted-key <workspace-pubkey>` air-gapped. Exit code 0. Conversation moves to substance.
Frequently asked
Does Promethean replace our existing fraud-monitoring platform?
No. Promethean is the evidence layer on top of your fraud-monitoring platform. The classifier still runs in your stack (whether that's a custom LLM, a vendor solution, or a hybrid); Promethean records each decision into the L12 chain with the spec hash, model identity, input hash, output canonical hash, schema-validation result, reviewer verdict, and fallback flag. The classifier does the fraud detection; Promethean does the regulator-grade audit trail. They're complementary.
How does Promethean fit with our PSD2 / PSD3+PSR obligations specifically?
The PSR proposal (COM(2023) 366) Art. 83 (transaction monitoring + fraud detection) and Arts. 85–89 (SCA + risk-based exemptions) are the substantive AI-decisioning articles. PSD3 (COM(2023) 367) is the companion directive covering licensing + supervision of payment institutions. Promethean's L12 chain records the spec hash (which captures the fraud model's configuration) and inputHash (replay-against-source identifier) per decision. A supervisor inspecting a flagged transaction can verify the inputs and configuration recorded match what you claim. PSD2 Art. 95 operational/security risk management is addressed by the chain's cryptographic integrity (hash chain + Ed25519 + OTS anchoring). For deep details see our PSD3 / PSR deep-dive at /blog/psd3-sca-fraud-ai-explainability.
What about DORA — when an AI fails, how does Promethean help with the 24h notification?
DORA Art. 17 requires a documented ICT-incident-management process; Art. 18 requires classification by impact criteria; Art. 19 requires major-incident notification within 24h. Promethean's L12 chain lets you answer the six questions a DORA postmortem needs (when did it start, which spec, which model, how many decisions affected, fallback fired?, reviewer caught it?) in minutes rather than days — because the chain is already there. The postmortem becomes a query rather than a forensic exercise. See /blog/dora-incident-classification-for-ai-decisions for the full mapping.
We have multiple LLM features (fraud + KYC + AML narrative). Do we need separate Promethean workspaces per feature?
No. One workspace handles all your LLM features. Each feature is a separate RuntimeAISpec (with its own category, model identity, input/output schema, reviewer gate, fallback). They share the same chain or — if you prefer per-spec chains — append to separate chain files. The Production tier supports up to 25 active specs; most fintech SMBs sit at 2–6 specs.
We're a small payments SMB without a dedicated compliance engineering team. Is this realistic for us?
Yes. Self-service onboarding is the design point. Sign up, get an API key + Ed25519 signing key, install the SDK, point it at your existing fraud classifier or KYC extraction. Most fintech SMBs go live in a day. The free Dev tier is enough to evaluate the architecture locally against a real chain; Production tier (€499/mo) for the actual deployment. No procurement-committee approval needed at that price; one engineer can spin it up.
Drill into a specific use case
Each Fintech & Payments use case has its own page with the regulation-specific evidence mapping + hypothetical scenario:
Definitions used on this page
The substrate primitives referenced above (L12 receipt chain, spec hash, reviewer gate, fallback behaviour, OpenTimestamps anchor, tenant ID) all have canonical definitions in the glossary: