In-scope transactions are subject to Strong Customer Authentication because they meet PSD2 conditions, such as customer-initiated online payments in regulated markets. Out-of-scope transactions are exempt by nature or rule, such as merchant-initiated payments, MOTO transactions, one-leg payments, and anonymous transactions. The distinction determines whether SCA is required or whether a payment can proceed without it.
How PSD2 Uses Scope to Decide Whether Strong Customer Authentication Applies
Under PSD2, “in-scope” is not just a label for payments that happen online. It is the regulatory boundary that determines whether a transaction must be treated as subject to Strong Customer Authentication, or whether it sits in a category that the rules exempt. That distinction is driven by transaction type, who initiates the payment, and the legal/payment context around it.
For practitioners, the first test is whether the payment falls within the regulated PSD2 flow that the authentication rules were designed to cover. Customer-initiated online payments are the clearest example, but scope is broader than channel alone, because a payment can be online and still be exempt, or offline and still fall under related controls depending on the exact transaction model.
The useful way to think about scope is that it answers a compliance question before it answers a technical one: does this payment need SCA, or is the payment model exempt by rule or by nature? That is why scope assessment has to happen early in payment design, routing, and exception handling, not only at checkout.
- Customer-initiated transactions are the default case most teams associate with in-scope handling.
- Merchant-initiated and other exempt flows require separate treatment because the authentication obligation is different.
- Borderline cases should be resolved by transaction classification logic, not by assuming every payment needs the same authentication path.
Which Transaction Types Usually Fall Outside the PSD2 SCA Requirement
Out-of-scope transactions are those that PSD2 treats as exempt because of the nature of the payment or a specific rule-based carve-out. Common examples include merchant-initiated payments, MOTO transactions, one-leg payments, and anonymous transactions. These are not “less important” payments, they simply do not follow the same SCA expectation as in-scope customer-initiated transactions.
That matters because out-of-scope does not mean uncontrolled. It means the payment must be handled under the correct exemption logic, with the right fraud, reconciliation, and monitoring controls around it. A payment can be outside the SCA requirement and still present settlement, fraud, or operational risk if the exemption is misapplied.
The difference also affects system behaviour. If a transaction is misclassified as in-scope, users may face unnecessary friction or failed payments. If a transaction is misclassified as out-of-scope, the organisation may skip authentication when the rule set actually requires it, which creates compliance exposure and can weaken fraud defences.
Risk and Threat Considerations
Misclassifying PSD2 scope is a control failure, not a terminology issue. The main risk is either over-applying SCA and breaking the payment journey, or under-applying it and leaving a regulated payment path without the expected authentication control. In both cases, the error tends to show up at scale as payment failure, disputes, fraud leakage, or regulatory challenge.
Failure mechanism: Teams often encode transaction rules too narrowly, or they inherit legacy payment categories without revalidating whether the PSD2 exemption still fits the actual transaction model. When the classification layer is wrong, every downstream control decision built on it is wrong as well.
Impact: The business can see higher abandonment, higher manual review load, rejected payments, or compliance findings. In the worst case, a genuinely in-scope payment is processed without SCA, which creates avoidable exposure to fraud and audit scrutiny.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the technical controls, while PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 6 — Access Control Management | Scope classification governs when authentication and access control are enforced for payments. |
| Recommendation — Classify payment flows correctly before enforcing authentication paths. | ||
| NIST CSF 2.0 | PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited | PSD2 scope determines when authentication controls must be invoked for a transaction. |
| GV.PO-01 — Organizational cybersecurity policy is established, communicated, and enforced | Transaction scoping needs clear policy so exemption decisions are consistent and auditable. | |
| Recommendation — Apply identity and authentication controls only where the transaction class requires them. Document PSD2 transaction classification rules and enforce them consistently. | ||
| NIST SP 800-63 | SP 800-63B — Authentication and Lifecycle Management | SCA is an authentication decision, so transaction scope affects when authentication assurance is required. |
| Recommendation — Map in-scope payments to the appropriate authentication assurance path. | ||
| PCI DSS v4.0 | 8 — Identify Users and Authenticate Access to System Components | Payment flows need proper authentication controls where regulated transaction handling depends on them. |
| Recommendation — Use strong authentication controls for payment paths that require higher assurance. | ||
Practitioner Guidance
What to verify: Validate the payment initiation model, the legal entity and market context, and the exact exemption rule before deciding whether SCA is required. The decisive question is not “does this payment look online?” but “what transaction class does the rule set place it in?”
Decision rule: If the transaction is customer-initiated and no explicit exemption applies, treat it as in-scope and route it through the SCA path. If the transaction is merchant-initiated or otherwise exempt, preserve evidence for why the exemption was used and make sure that exemption is consistently implemented in production.
Common mistake: Treating scope as a checkout-only issue. In practice, scope is often determined earlier, in orchestration, payment rails selection, and exception handling, so the classification logic has to be owned and tested like any other compliance-critical control.
Practitioner takeaway: The real control is not just authenticating payments, it is classifying them correctly so that SCA is applied where PSD2 requires it and not forced where the rule set exempts it.
Related resources from NHI Mgmt Group
- What is the difference between API access and screen scraping under PSD2 payment account rules?
- What is the difference between OAuth scope inventory and scope monitoring?
- What is the difference between scope-based authorization and object-level authorization in MCP?
- What is the difference between client identity and permission scope in MCP governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
