Who is accountable for deciding whether a Trusted Beneficiary or other SCA exemption can actually be applied?

Accountability sits with the payment ecosystem, not the merchant alone. The merchant can design the checkout flow and request an exemption, but the payment service provider or issuing bank ultimately controls whether the exemption is granted. For Trusted Beneficiary cases, the cardholder’s bank also carries liability and can refuse the request, so governance is shared across parties.

Who actually decides whether the exemption applies

In practice, this is a shared governance decision, but not a shared veto in the same sense. The merchant can only present the use case and request the exemption; the payment service provider, acquirer, or issuing bank decides whether the transaction can proceed under that exemption, based on scheme rules, risk appetite, and the cardholder relationship. For Trusted Beneficiary, the issuer’s role is especially important because the bank can accept or refuse the request and remains accountable for the decision path.

The key point is that the exemption is not something the checkout page can self-authorise. It depends on a control point outside the merchant’s environment, which is why merchant design, payment routing, and issuer policy all matter. If those parties are not aligned, the exemption may fail even when the checkout flow is technically correct.

That control-point model is consistent with broader identity and trust governance: a requestor may initiate a privileged flow, but another party must validate whether the trust condition is actually satisfied. For payment credentials and certificate trust alike, the decisive step sits with the authority that owns the trust relationship, not the party that merely asks for it. For background on how abuse of trusted material can be exploited in the wild, see Snowflake breach.

What changes between Trusted Beneficiary and other SCA exemptions

Trusted Beneficiary is different from many operational exemptions because it depends on explicit cardholder trust and issuer recognition, not just transaction context. That means the merchant cannot treat it as a static optimisation rule. The exemption only holds if the issuer, and in some cases the cardholder’s bank policy, has accepted that beneficiary as eligible for the low-friction path.

Other SCA exemptions may be driven by transaction risk analysis, low-value thresholds, recurring payment logic, or whitelisting-type controls. Those paths still sit inside a broader ecosystem decision model, but the deciding party and the basis for approval can differ. Practitioners should therefore separate “we can request this exemption” from “the ecosystem will honour it.” Those are not the same thing.

From a control perspective, this is a trust-boundary question rather than a checkout UX question. If the merchant, PSP, and issuer do not share the same understanding of who is trusted, when, and for what scope, the exemption outcome becomes unpredictable. That is why exemption design should be treated as a governed payment policy, not as a front-end feature.

Practitioner implications for payment and fraud teams

What to verify: Confirm which party owns exemption eligibility, which party logs the decision, and which party can override or refuse it. If the merchant cannot produce a clear flow showing who approves Trusted Beneficiary status, the control is not operationally reliable.

Common mistake: Treating a merchant-side request as if it were an approval. That confusion leads to false assumptions about conversion uplift, chargeback exposure, and dispute handling when the exemption is denied upstream.

What good looks like: The merchant knows which exemptions are merely requested, the PSP knows how they are forwarded, and the issuer has a documented basis for acceptance or rejection. Decision ownership is explicit, evidence is retained, and exception handling is consistent across channels.

Practitioner takeaway: Treat SCA exemptions as ecosystem-controlled decisions, not merchant-controlled settings, and design the checkout and fraud workflow around the possibility of refusal, not the expectation of approval.

Risk and Threat Considerations

Because exemption handling sits across multiple parties, the main risk is misplaced trust: a merchant may assume a benefit exists before the issuer has actually honoured it, or may assume a beneficiary relationship is valid when it has not been accepted for that cardholder. That creates exposure in both fraud control and customer experience, especially when teams cannot explain why an exemption was granted in one case and refused in another.

Failure mechanism: Weak ownership clarity, inconsistent issuer policy, or poor request routing can cause exemptions to be applied incorrectly, denied unexpectedly, or relied on without valid trust state.

Impact: The result can be avoidable authentication friction, failed conversion, increased dispute handling, and weaker fraud assurance where teams believe they have a protection or approval path that is not actually in force.

Related resources from NHI Mgmt Group

• Who is accountable for deciding whether identity security resources are actually reducing risk?
• How do security teams know whether encrypted telemetry is actually trusted?
• Who is accountable when SCA exemptions are applied incorrectly?
• How do organisations know whether SCA is actually reducing risk?