Delegated Authentication

Delegated authentication is an arrangement in which the party normally responsible for confirming a customer's identity, usually an issuing bank, allows another party to carry out that check and agrees to rely on the result. The other party might be a digital wallet, a phone maker, a large merchant or a payment service provider. The customer proves who they are once, for example with a fingerprint on their phone, and the issuer treats that as its own authentication when deciding whether to approve the payment.

The idea grew in card-not-present commerce, where issuers usually authenticate customers through 3-D Secure (3DS) and its challenge screens. Delegation aims to cut that friction while still meeting rules such as strong customer authentication (SCA) under the EU's PSD2. It is different from simply skipping authentication through an exemption: under delegation, a check still happens, but someone else performs it.

Think of a building where a trusted company has its own security desk. Instead of making that company's staff show ID again at the main building entrance, the landlord agrees: "If your desk has checked them, that is good enough for me." The check still happens, just at a desk the landlord trusts.

In payments, the bank is the landlord. Normally it checks you itself, perhaps by sending a code to your phone. With delegated authentication, the bank trusts another party, such as your phone's wallet, to do the check. When you pay by touching your fingerprint to the phone, the wallet confirms it was you, and the bank accepts that answer. You get one quick step instead of two, and the bank still knows a proper check took place.

1. Agreement. The issuer, or a card network programme acting for issuers, approves the delegate and sets requirements on methods, security, data sharing and audit.
2. Customer authentication. The delegate authenticates the customer, typically with device-bound credentials such as biometrics, a device passcode or a FIDO passkey.
3. Passing the evidence. The delegate sends data about the authentication, such as the method used, its time and a cryptographic proof, with the authorization or through the 3DS message flow, where EMV 3DS fields let a requestor share details of authentication it has already done.
4. Issuer decision. The issuer evaluates the evidence along with its own risk checks and approves or declines. A soft decline may still ask for the issuer's own challenge if it is not satisfied.

• Device wallets. Tokenized wallets on phones and watches verify the user with the device's own biometric or passcode, and issuers accept this as the cardholder verification method (CVM). This works together with network tokenization, which binds the card to the device.
• Merchant or PSP delegation. Large merchants and payment providers that authenticate users strongly at login may be permitted to perform SCA on the issuer's behalf for certain transactions.
• Network programmes. Card networks have run frameworks that set common rules so that one delegate can be trusted by many issuers rather than each issuer signing separate deals.
• Web-based standards. The W3C's Secure Payment Confirmation lets a passkey registered with one party be used to confirm a payment in the browser, supporting a similar pattern.

Under PSD2, the payment service provider that issues the payment instrument is responsible for applying SCA. The European Banking Authority has indicated that an issuer may outsource the performance of SCA to a third party, such as a wallet provider, under an outsourcing arrangement, but the issuer remains responsible for compliance and must ensure the delegate's elements meet the SCA requirements. This is why delegation is built on contracts and audits rather than informal trust. It is a narrower idea than delegated authority in governance, which concerns who may make decisions inside an organisation.

Liability for fraud follows the agreement. In card schemes, a fully authenticated 3DS transaction usually shifts liability for fraud-related chargebacks from the merchant to the issuer. With delegation, the scheme rules or contract decide whether the issuer, the delegate or the merchant bears losses if the delegate's check proves wrong. Merchants and wallets that become delegates may accept some of that liability in return for smoother checkouts.

The main benefit is conversion. Every extra screen in a checkout loses some customers, and challenges sent by the issuer, such as a one-time password by text message, are a common cause of abandoned e-commerce payments. Device-based methods are also harder to phish than SMS codes. For issuers, accepting a well-run delegate can reduce cost and fraud at once.

Concerns include concentration, since a small number of large technology firms become gatekeepers for authentication; reduced visibility for issuers, who see less of the customer's session; and complexity, as each delegate model has different data and liability terms. Weaknesses at a delegate, such as poor device binding or a flawed account recovery process, can expose many issuers at once, which links delegated authentication to wider third-party risk management. Signals from behavioural biometrics and device checks are often added by delegates to strengthen their side of the process.

• EMVCo
• European Banking Authority
• FIDO Alliance