How should teams respond when PSD2 controls need to work across cards, wallets, and open banking?

Standardise PSD2 control decisions across channels

When cards, wallets, and open banking all sit under PSD2, the mistake is letting each channel develop its own interpretation of authentication and exemption handling. A single control model gives teams one way to classify risk, one evidence pattern to retain, and one governance logic for proving that similar payment journeys were treated consistently.

That matters because the control objective is not just to “support PSD2” in general, but to keep authentication, exemption approval, and recordkeeping aligned when the transaction path changes. If the same customer journey is handled differently by product team, processor, or partner, the organisation can no longer explain why one path passed with an exemption while another required stronger step-up.

Teams should therefore define the control once at the policy layer and then map it into channel-specific implementations. For example, card-present, wallet tokenisation, and open banking initiation may differ technically, but they still need the same underlying decision logic for when authentication is required, when an exemption is permitted, and what evidence shows the decision was justified.

Why channel drift creates governance gaps

Channel drift usually starts with local optimisation. A card team tunes for conversion, a wallet team inherits scheme rules, and an open banking flow is built around bank-to-bank redirects, so each area adds exceptions that make sense in isolation but do not compose cleanly across the enterprise. The result is inconsistent control outcomes even when the regulatory obligation is the same.

That inconsistency is more than a reporting issue. If exemptions, challenge steps, or fallback paths are not governed in the same way, the firm can end up with uneven customer friction, weak auditability, and a broken line of sight from policy to execution. A unified model reduces the chance that one channel becomes the “easy exception” while another becomes over-controlled.

For teams operating across regulated payment paths, a useful reference point is the Financial Services Identity Security Guide, which ties payment-sector identity obligations to authentication, privileged access, and third-party risk. For broader control design, the ISO/IEC 27002:2022 Information Security Controls guidance helps teams anchor control selection in consistent implementation practice.

What a single PSD2 control model should contain

A workable model should define three things clearly: the authentication rule, the exemption rule, and the evidence rule. Authentication rule means when a payment flow must step up and what counts as acceptable assurance. Exemption rule means who can approve an exception, under what conditions, and how that decision is bounded. Evidence rule means what logs, approvals, and transaction metadata must be retained to prove the control operated as intended.

The model should also distinguish policy from implementation. Policy says what must happen; implementation says how cards, wallets, and open banking systems satisfy it without inventing new interpretations. That distinction is important because different providers and protocols will expose different technical levers, but they should all feed the same governance outcome.

For control mapping, the ISO/IEC 27001:2022 Information Security Management standard is useful where teams want the control to sit inside a broader management system, especially around access control, authentication, and evidence retention. The NIST Cybersecurity Framework 2.0 is helpful when the organisation wants to frame the issue as governance plus control assurance rather than a single technical safeguard.

Make evidence portable across cards, wallets, and open banking

The hardest part is often not the control itself but the proof. Evidence has to be portable enough that a compliance or audit team can compare one payment path with another without reconstructing the logic from scratch. That means the same minimum record set should be captured for every channel, even if the underlying authentication method or partner integration differs.

At a minimum, teams should be able to show the decision made, the rule or exemption basis used, the actor or system that approved it, and the transaction context that justified it. If that evidence cannot be produced consistently, then the organisation has a control design problem, not just a documentation problem.

Relevant external control references include the CIS Controls v8 for account management and audit logging discipline, and NIST SP 800-53 Rev 5 Security and Privacy Controls for formalising identification, authentication, and audit requirements in a control catalogue.

Risk and Threat Considerations

Channel-specific PSD2 handling creates exposure when exemptions, step-up decisions, or evidence rules diverge by product line. That drift can weaken governance, create inconsistent customer treatment, and make it harder to detect when a control failure is systematic rather than isolated.

Failure mechanism: Separate implementations begin to encode different interpretations of the same policy, so a weak or overly permissive exemption path can persist unnoticed in one payment channel while others remain tighter.

Impact: The organisation loses comparability, weakens its audit trail, and increases the chance that an exception, dispute, or supervisory review exposes inconsistent control operation across payment types.

Practitioner Guidance

What to prioritise: Start with a common decision model, not a common technical stack. The first goal is to prove that every channel answers the same control questions in the same order, even if the execution path differs.

What to verify: Check that exemption approval, authentication outcome, and evidence retention are all tied to one policy taxonomy. If each channel has its own naming or approval logic, consolidation will be superficial.

Common mistake: Treating cards, wallets, and open banking as separate compliance projects leads to drift that only appears when auditors or dispute teams ask for cross-channel comparability.

Practitioner takeaway: The control is only as strong as its weakest payment path, so the real objective is to make every channel produce the same governance answer, not merely the same customer experience.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• Why does PSD2-style open banking increase the need for stronger identity and authentication controls?
• How should payment teams strengthen authentication as digital transactions shift toward mobile wallets, open banking, and passwordless access?
• How should security teams adapt SOC 2 controls when employees work remotely across unmanaged networks and devices?