Out-Of-Scope Transaction

How out-of-scope transactions work

Out-of-scope transactions are excluded from Strong Customer Authentication because the payment itself falls into a defined PSD2 category, such as merchant-initiated payments, mail order or telephone order payments, one-leg transactions, or use of anonymous payment instruments. The key point is that the exemption is driven by transaction context, not by a weaker security posture.

That distinction matters because the payment rail may still be controlled, monitored, and subject to other fraud and compliance checks even when SCA is not required. For example, merchant-initiated flows often depend on an earlier customer-authenticated setup, while one-leg transactions depend on where the payment touches the PSD2 perimeter.

Why these transactions are treated differently

PSD2 does not treat every payment the same way. Some flows are excluded because authenticating the payer again would not materially improve the security of that specific transaction, while others sit outside the regulation’s scope because the payment path, geography, or instrument type places them outside the SCA requirement.

This is why “out of scope” is not a synonym for “uncontrolled.” It is a regulatory classification that reflects the payment context. A payment can be out of scope for SCA and still be high value, fraud-prone, or operationally sensitive, especially when the transaction is initiated by a merchant or processed through channels that reduce direct payer interaction.

Common examples and boundary cases

The clearest examples are merchant-initiated payments, mail order and telephone order payments, one-leg transactions, and anonymous payment instruments. Each has a different reason for falling outside the SCA obligation, but they all share one feature: the normal challenge-response model of cardholder authentication does not map cleanly onto the transaction.

Boundary cases are where teams make mistakes. A recurring payment may start as a customer-authenticated transaction and later continue as merchant-initiated activity. Likewise, cross-border flows can be misread if the team does not distinguish between a payment that is merely unusual and one that is actually outside the PSD2 SCA requirement.

How to assess scope in practice

Assess the payment by asking three questions: what type of transaction is it, where does it occur, and does an explicit PSD2 exclusion apply? If the answer depends on one of those recognized categories, the payment may be out of scope for SCA even though other controls remain relevant.

Good scope assessment depends on payment metadata, channel classification, and consistent rule application across products and payment partners. The most common implementation failure is not the exemption itself, but inconsistent interpretation across operations, fraud teams, and payment service providers.

Risk and Threat Considerations

Out-of-scope status can create false confidence if teams treat it as a security shortcut rather than a regulatory exception. The main exposure is that reduced authentication can make a payment path easier to abuse when merchants, processors, or customer support channels accept weakly governed transaction setup or poorly validated exceptions.

Failure mechanism: Attackers or dishonest insiders may target merchant-initiated flows, remote-order channels, or exception handling paths where the payer is not present, then exploit weak verification, replay, or authorization controls to submit payments that appear legitimate.

Impact: The result can be unauthorised payment activity, higher fraud loss, disputed transactions, chargeback pressure, and control gaps between what the business believes is “outside SCA” and what still needs fraud and reconciliation oversight.

Practitioner Guidance

What to watch for: The biggest governance issue is not whether a payment is exempt in theory, but whether the exemption is applied consistently and evidenced correctly. Teams should be able to explain why a transaction is out of scope, which rule or exclusion applies, and what compensating controls still protect the payment flow.

Practitioner takeaway: Treat out-of-scope as a classification to prove, not a shortcut to assume.

Related resources from NHI Mgmt Group

• How can security teams tell whether AI agent access is drifting out of scope?
• How can organisations tell whether an agent session is drifting out of scope?
• Why do organisations struggle to keep cardholder data out of PCI scope in modern collaboration tools?
• Who is accountable when a 3D Secure authenticated transaction later turns out to be fraudulent?