Article 97 of the revised Payment Services Directive sits above every electronic payment in the European Union.
The Regulatory Technical Standards on Strong Customer Authentication translate it into three concrete technical obligations.
They are often read together.
They are rarely implemented together.
Requirement One: Strong Customer Authentication
Two independent factors from the categories of knowledge, possession, and inherence.
Password plus SMS OTP is the canonical example most banks deploy.
It passes audit. It does not pass the updated threat model.
SIM swapping makes SMS-OTP a shared factor with whoever controls the phone number.
Phishing-as-a-service collects both factors in the same session.
Authorized Push Payment scams produce both factors through the customer themselves, voluntarily, over the phone.
The letter of SCA is met. The intent is not.
Requirement Two: Dynamic Linking
This is where most implementations silently fail.
The RTS require that the authentication code generated for a given transaction be dynamically linked to:
- •the specific amount
- •the specific payee
A six-digit OTP is not dynamically linked to anything. It is a rotating secret indexed by time. It verifies possession of the OTP generator. It tells you nothing about the amount or the payee.
Showing the amount and payee on the OTP screen does not constitute dynamic linking either. The cryptographic material being exchanged is still independent of those fields.
Dynamic linking in the sense the RTS demand requires the cryptographic output itself to bind the amount and payee. Change either value, and the output no longer verifies. That property cannot be retrofitted onto OTP.
The question dynamic linking answers is: which specific transaction was authorized. A code that could have authorized any transaction does not answer it.
Requirement Three: Non-Repudiation
Non-repudiation is the property that the party who produced a signed assertion cannot credibly deny having produced it.
It requires three things.
- •a signing key that only the intended party controls
- •a signed artifact that binds the action and the moment
- •an independent verifier who can check the signature without the signer
A session log is not a non-repudiable artifact. The bank controls the log. The customer can always claim the log was produced incorrectly.
An OTP acknowledgment is not a non-repudiable artifact. The OTP is a shared secret at the moment of use. Nothing about the acknowledgment is uniquely attributable to the customer rather than to the bank’s own system.
A risk score is not a non-repudiable artifact. It is the bank’s own opinion about the transaction.
The only artifact that satisfies non-repudiation is one produced on the customer’s own device, by a key the customer alone controls, over a canonical representation of the specific action.
What Passes Strict Reading
An implementation that satisfies all three requirements simultaneously has a specific shape.
- •Two-factor authentication is performed on the customer’s device, where one factor is biometric and bound to secure hardware.
- •The output of that authentication is a cryptographic signature over the canonical transaction payload — including amount and payee.
- •The signing key is generated and stored in hardware the customer controls, and is never exported.
- •The signature verifies independently against a public key the bank — or a regulator, or a court — holds on record.
That is SCA, dynamic linking, and non-repudiation satisfied in a single artifact.
Most production systems produce three artifacts, one per requirement, none of which is binding on the others.
For the industry view, see Financial Transactions.
Closing
Article 97 does not describe an authentication ritual. It describes an evidentiary outcome.
The outcome is a single artifact that identifies the customer, binds the specific transaction, and stands independent scrutiny.
Every existing implementation that does not produce such an artifact is compliant in form and incomplete in substance.
Regulators read the substance.