SCA exemption decisions

What this is

Strong Customer Authentication (SCA) under PSD2 Art. 97 requires multi-factor authentication on most online payments. The RTS on SCA carves out exemptions: low value (Art. 16), transaction risk analysis below fraud-rate thresholds (Art. 18), corporate payments (Art. 17), trusted beneficiaries (Art. 13). PSPs that apply exemptions inherit the obligation to document each decision — risk score, exemption category, fallback to step-up auth on doubt.

The proposed Payment Services Regulation (PSR, COM(2023) 366) — sibling to the PSD3 directive — strengthens this: per-decision documentation must be reproducible on demand under Arts. 85–89 (SCA + exemptions). Supervisors are increasingly inspecting the exemption logic itself — is the AI risk model bounded, was it the same model that decided last quarter's exemption that's under inspection today, can the exemption decision be regenerated under the same inputs.

Promethean records each exemption decision as an L12 entry: the spec hash (which version of your risk model decided), input hash (which transaction context), output canonical hash (the verdict — exempt / step-up / decline + score), model identity (provider + model + version), and fallback flag. The chain is tamper-evident — retroactive edits break verification.

How Promethean addresses this

• Per-decision risk score retention

  Each exemption decision is an L12 entry with outputCanonicalHash binding the risk score + exemption category. The score is recoverable from the operator's source data via inputHash.

• Reproducibility on supervisor demand

  specHash + modelIdentity per entry mean a supervisor can verify which model + spec version decided a specific exemption. Replay against the same inputs is straightforward if the model is deterministic; if not, the chain proves what configuration was active.

• Fallback to step-up auth on doubt

  Spec declares fallbackBehavior (typically 'queue-for-review' for low-confidence or 'reject' to force SCA). The L12 entry records fallbackTriggered + schemaValid. Fallback rate is a supervisor-friendly health metric over time.

• Tamper-evident chain across the audit period

  OpenTimestamps anchoring binds chain heads to Bitcoin. Retroactive edits at the audit window break the hash chain — verify.mjs reports the break with the exact entry id. Operator can't silently revise risk-scoring history.

• Per-exemption-category fraud-rate reporting (EBA GL 2020/01)

  Chain export groups L12 entries by spec (where each exemption category maps to a distinct spec or sub-classifier). Aggregate fraud-confirmation feedback (from the operator's separate chargebacks pipeline) joined to the chain yields per-category rates for the EBA report.

What this looks like in practice

Hypothetical: PSP supervisory inspection on Q3 exemption decisions

A mid-size PSP receives a supervisor inquiry: 'Provide per-decision evidence for the 14,000 SCA exemptions you applied in Q3 to transactions over €200. Demonstrate the risk model in use was the documented one. Show the fallback rate.' Without Promethean: dump from a fraud-monitoring tool, manually correlate with model-deployment logs, weeks of reconciliation. With Promethean: chain-export filtered to Q3 + outputCategory=exemption-applied; the supervisor runs verify.mjs against the export; specHash sequence shows one continuous version (the documented one); fallbackTriggered count is 220 (1.6% fallback rate to step-up auth). The conversation moves from 'do you have evidence' to 'does the evidence support your governance claim'.

Frequently asked