FinanceGadget
Guide

Strong Customer Authentication: What PSD2 Requires

The short answer

Strong Customer Authentication is the European rule that made two-factor authentication mandatory for electronic payments and account access. It requires two independent factors drawn from three categories, and for payments it requires something more interesting: the authentication code must be cryptographically bound to the specific amount and the specific payee.

That second requirement — dynamic linking — is what makes SCA more than 2FA with a European accent. It is also the reason SCA stops some fraud completely and does almost nothing against other kinds, which is worth understanding before you assume your bank has it covered.

The three categories

Two factors, from two different categories. Two passwords are not two factors.

Knowledge — something only you know. A password, a PIN, an answer to a security question. The weakest category, because knowledge can be copied without you noticing.

Possession — something only you have. A registered phone with a bank app installed, a card reader, a hardware security key, a SIM receiving an SMS. What matters is that possession must be demonstrated, not asserted.

Inherence — something you are. Fingerprint, face, voice. On modern phones the biometric almost never leaves the device: the sensor unlocks a key held in secure hardware, and the bank sees a cryptographic signature rather than your fingerprint. That design is what makes inherence usable at all.

The independence requirement matters more than the categories. Breaching one factor must not compromise the other. A password reset link sent to the same phone that receives the OTP is a weak pair, because compromising the phone gets both.

Dynamic linking, the part that matters

For remote payments, the rules go beyond identifying you. The authentication code must be specific to the amount and the payee, both must be shown to you at the moment you approve, and any change to either must invalidate the code.

This is the difference between these two prompts:

Your verification code is 481920.

Approve payment of €1,240.00 to NORTHGATE SUPPLIES LTD?

The first authenticates you. The second authenticates a transaction. Only the second defeats the attack where you are on the phone to a “fraud investigator” who needs your code — because the screen you are approving states the amount and the recipient in plain language, and neither matches the story you are being told.

When people are defrauded despite having SCA, the mechanism is very often that they were shown the first kind of prompt, or shown the second and did not read it.

The exemptions

SCA is not applied to every payment, by design — friction has its own costs, and the rules allow banks to skip it in defined cases.

Low value. Small individual payments, subject to a cumulative limit since the last authentication. This is why contactless works without a PIN until it suddenly asks for one.

Trusted beneficiaries. You can add a payee to a whitelist held at your bank, after which payments to them skip SCA. Convenient, and worth knowing exists, because an attacker with session access who adds a beneficiary to that list has created a durable route out.

Recurring payments. The first payment in a series is authenticated; later identical ones to the same payee are not.

Transaction risk analysis. The provider’s fraud engine may exempt a payment it scores as low risk, permitted only while the provider’s measured fraud rate stays under defined thresholds. Most invisible checkout experiences rest on this.

Merchant-initiated transactions. Where you have given a mandate and the merchant initiates, SCA does not apply per payment.

Exemptions are requested by the merchant or acquirer and granted at the issuer’s discretion. Your bank can always insist on authentication.

What SCA does not protect against

This is where expectations and reality separate.

Authorised push payment fraud. If you are deceived into making a payment yourself, you will authenticate it perfectly. SCA confirms you meant to send the money; it has no view on whether you were lied to about who was receiving it. This is now the dominant fraud type in several European markets, and SCA is structurally blind to it. Dynamic linking helps only if you read the screen.

Real-time relay of codes. An attacker running a convincing fake banking site can prompt you for an OTP and replay it within its validity window. Codes are phishable because they are transferable — which is exactly the property passkeys remove. Passkeys for banking covers why domain binding defeats this entire class.

Compromise of the device holding both factors. If your phone runs the banking app, receives the SMS, and holds the biometric, malware with sufficient privileges has all three. Android accessibility-service abuse is the standard route — see what app permissions actually grant.

SIM swap. Where SMS is the possession factor, transferring your number transfers the factor. SIM swap: protecting your bank accounts covers the defence.

Social engineering of account recovery. The recovery path is frequently weaker than the authentication path, and attackers go around rather than through.

What to actually check

Find out what your bank uses as its possession factor. If it is SMS, ask whether an app-based or hardware option exists and move to it. If the bank app is the factor, check whether app installation on a new device requires more than your password.

Read the approval screen every time. The amount and the payee are shown because the rules require them to be shown. Approving without reading discards the single most valuable control you have.

Check your trusted-beneficiary list. Most people do not know they have one. It is in online banking under payment settings, and anything unexpected on it is serious.

Set transaction limits deliberately. Most banks allow a daily or per-payment cap that you can raise temporarily. A low default limit converts a total loss into a bounded one and costs you two minutes on the rare occasion you need more.

Treat any inbound contact about a code as fraud. No legitimate institution asks you to read back a code, approve a prompt you did not initiate, or move money to a “safe account”. There is no exception to this, which makes it a rule you can apply without judgement — and rules you can apply without judgement are the ones that survive being frightened.