They should decline the transaction unless a valid exemption applies. The practical decision is to treat non compliant requests as blocked activity, then verify whether the payment qualifies for a low value exemption, a low risk treatment, or a prior whitelist arrangement. That approach keeps the control enforceable and prevents exceptions from becoming a back door.
Why PSD2 SCA Non-Compliance Must Be Treated as a Hard Stop
When a transaction does not meet PSD2 Strong Customer Authentication requirements, the safe operational default is to refuse execution until the request is brought into a compliant path. That is not just a compliance preference, it is a control boundary. If teams allow a non-compliant payment to pass “temporarily”, the exception becomes part of the normal payment flow and weakens the enforceability of the rule.
The decision point is therefore simple, but the supporting checks matter: determine whether the request can be handled under a documented exemption, whether the transaction qualifies for a low-risk treatment, or whether it falls under a prior whitelist arrangement. If none of those conditions is clearly met, the transaction should stay blocked. In payment environments, that discipline is the difference between a controlled exception process and an uncontrolled bypass.
For broader payment-security context, organisations should align this decision with the control expectations in PCI DSS v4.0, which emphasises restricted access paths and controlled account behaviour in environments that process sensitive payment activity.
How to Distinguish a Valid Exemption from an Informal Override
The practical challenge is not understanding that non-compliant transactions should be declined, it is proving when an exception truly applies. A valid exemption should be identifiable before approval, documented in a way that survives review, and narrow enough that it does not create a standing bypass for future transactions. That is especially important where teams use exemption language loosely to avoid customer friction.
The most common failure mode is treating operational convenience as if it were a policy exception. If the merchant, processor, or internal operations team cannot point to the exact exemption basis, then the request should be handled as non-compliant. That standard keeps the approval flow auditable and prevents ambiguous cases from being normalised into routine acceptance. Payment teams can also use the OWASP ASVS and the NIST Cybersecurity Framework 2.0 as supporting references for disciplined control enforcement, even though PSD2 SCA itself remains the governing requirement.
If a transaction only appears to qualify after manual interpretation, the safer decision is to pause and verify rather than approve on assumption. That verification should be performed before authorisation, not after settlement or exception logging.
Practitioner Guidance for Enforcing PSD2 SCA Decisions
What to verify: Build a clear decision tree that checks exemption eligibility before the transaction reaches the approval stage. The reviewer should be able to see why the request is exempt, who approved it, and what evidence supports that classification.
Common mistake: Do not let customer-service pressure, partner escalation, or repeated transaction patterns turn an exception into an unwritten policy. Once a non-compliant path is used repeatedly, it stops behaving like an exception and starts behaving like a control gap.
What good looks like: Declined transactions are consistently routed back into a compliant customer journey, while legitimate exemptions are logged with enough detail to withstand audit and dispute review. The organisation can show that blocked requests were blocked for a reason, not simply failed or abandoned.
Practitioner takeaway: The control objective is not to make every transaction succeed, it is to make every approval decision defensible. If the request cannot be shown to meet SCA or a clearly approved exemption, treat it as a blocked payment path, not an exception in waiting.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| PCI DSS v4.0 | 7 — Restrict Access by Business Need to Know | Payment exceptions need tightly bounded approval paths to prevent bypasses. |
| 8.6 — System and Application Accounts and Authentication Management | Transaction approval exceptions should be controlled and traceable, not informal overrides. | |
| Recommendation — Restrict approval paths to documented business need and prevent ad hoc exception handling. Use controlled account and authentication practices for any transaction override workflow. | ||
| NIST CSF 2.0 | PR.AC — Access Control | SCA is an access decision for payment initiation and should be enforced as a control boundary. |
| Recommendation — Enforce access and approval controls so non-compliant transactions cannot proceed unchecked. | ||
| CIS Controls v8 | 6 — Access Control Management | Controls must prevent unauthorised or undocumented payment approval paths. |
| Recommendation — Manage payment approval access so only approved exemption paths can override SCA. | ||
