Secure authentication protocols
Authentication is the foundation of trust in payments. This area covers both strong authentication of end users and the machine-to-machine authentication between providers in open banking interfaces.
Two levels of authentication
In payment services, authentication takes place at two levels. The first level is the authentication of the payer: when a person logs in to online banking or approves a payment, PSD2 requires strong customer authentication (SCA). It is based on at least two mutually independent elements from three categories: knowledge (e.g. a PIN), possession (e.g. a phone or security key) and inherence (e.g. a fingerprint).
The second level is authentication between providers. When a payment initiation service or an account information service uses a bank's interface, it must prove its identity and its licence. In Europe this is done with qualified certificates under the eIDAS Regulation, and authorisation is typically handled on the basis of OAuth 2.0. The financial sector also uses the OpenID Foundation's FAPI profiles, which tighten OAuth's security requirements.
In Finland, banks' identification tools hold a special position because they are also used as strong electronic identification in public and private online services. The same tool can therefore serve both to approve a payment and to verify identity, which makes for a smooth user experience but underlines the importance of protecting the tool.
In remote transactions, the authentication code must be linked to a specific amount and payee. If either changes, the code becomes invalid. The requirement is based on Article 5 of Delegated Regulation (EU) 2018/389.
The authentication flow in payment initiation
An example of the redirect-based model, which is the most common in Europe. In the embedded and decoupled models the steps differ in part.
Provider identification
The payment initiation service establishes an mTLS connection to the bank's interface and presents its eIDAS certificate. The bank checks the licence and role.
Creating the payment order
The service sends the payment order details: amount, currency, payee name and IBAN, and the reference.
Authorisation request
The bank returns an authorisation URL. In the FAPI profile the request is sent securely (e.g. PAR) and bound with a PKCE value.
Payer SCA
The payer authenticates in their own bank with two elements and sees the amount and payee to be approved.
Authorisation code exchange
The service exchanges the single-use authorisation code for a short-lived access token bound to the client certificate.
Execution and status
The bank executes the payment and returns the status. The service notifies the merchant of the outcome with a signed message.
Where strong authentication is required
PSD2 sets out the situations in which SCA is required and the exemptions a provider may apply on a risk basis.
Logging in to a payment account
SCA is required when the payer accesses their payment account online.
Initiating an electronic payment
Every payer-initiated electronic payment requires SCA in principle.
High-risk actions
For example, adding a new payee or changing the authentication tool.
Trusted beneficiaries
An exemption where the payer has marked the payee as trusted in their bank.
Transaction risk analysis
An exemption that may be applied when the provider's fraud rate stays within the prescribed limits.
Low-value remote payments
The low-value exemption, subject to cumulative amount and count limits.
Threats to authentication and countermeasures
Attacks on authentication have increasingly shifted from technical breaches to deceiving the user. Controls must cover both.
| Risk | Description | Control |
|---|---|---|
| Phishing | The user is lured to a fake site to enter their credentials. | App-based approval, clear display of payment details and user education. |
| Session hijacking | An attacker uses a stolen access token. | Certificate-bound tokens (mTLS) and short validity periods. |
| Authorisation code interception | In a redirect, the code ends up with the wrong party. | PKCE, precisely registered redirect URIs and PAR. |
| SIM swap | A phone number is transferred to an attacker to intercept text message codes. | Device-bound app keys instead of text messages. |
| Social engineering | The payer is persuaded to approve a fraudulent payment themselves. | Verification of payee, warnings and behaviour-based monitoring. |
- Delegated Regulation (EU) 2018/389
- SCA requirements, exemptions and the principles of secure communication.
- OAuth 2.0 (RFC 6749) and PKCE (RFC 7636)
- The core authorisation protocol and protection of the code exchange.
- FAPI
- The OpenID Foundation's security profiles for the financial sector, which require, among other things, sender-constrained tokens.
- eIDAS
- Regulation (EU) No 910/2014 and its amendments: qualified certificates and trust services.
Questions: secure authentication protocols
Is a text message code a sufficient SCA element?
A text message can serve as a possession element, but it is considered weaker than a device-bound app key because the phone number can be hijacked. Many banks have moved to app-based approvals.
Why do providers need eIDAS certificates?
The bank must be able to reliably verify that the party using the interface is an authorised payment institution or account information service. A qualified certificate contains information about the licence and roles, so the bank can check them automatically on every connection.
What does decoupled authentication mean?
In the decoupled model, the payer does not move to the bank's page in the browser but approves the payment separately, for example in the bank's mobile app. The model is smooth for the user but requires reliable status propagation between the services.
Does SCA eliminate fraud entirely?
No. SCA makes fraud based on stolen credentials considerably harder, but it does not prevent situations in which the payer is deceived into approving a payment themselves. This is why regulation now also emphasises verification of payee and transaction monitoring.
Related topics
Other technology areas and knowledge base guides that go deeper into this topic.
Digital payment processing
The payment lifecycle from initiation to settlement: gateways, processors, account-to-account payments and reconciliation.
Read more → Technology areaTransaction infrastructure
SEPA schemes, TIPS and RT1, ISO 20022 messages, idempotency, availability and operational resilience.
Read more → GuideOpen banking networks in the Nordics and the Baltics
How PSD2 account information and payment initiation services work in practice, which API standards the region's banks use and why bank IDs sit at the centre of the ecosystem.
Read the guide →Is something important missing?
Suggest a topic or send a correction. We update our content as regulation and standards change.