EU Directive 2015/2366 — Technical Analysis

The Age of
Open Banking.

The implementation of PSD2 marked a historic shift, moving the balance of power away from centralised bank control towards an open and interoperable ecosystem. It is not just a regulation: it is an infrastructural revolution.

The core of this transformation lies in opening banking APIs to authorised third parties and in the mandatory Strong Customer Authentication, redefining security and transaction flows across Europe.

2018
Year of
enforcement
2 of 3
Mandatory
SCA factors
150+
Data points
3DS 2.0
€30
SCA exemption
e-commerce threshold
Scroll to explore
Art. 4 RTS — EBA

Strong Customer Authentication

SCA requires that every account access or payment initiation is validated with at least 2 independent factors. Compromising one element must not make it easier to breach the second — multi-layered defence.

KnowledgeSomething only you KNOW — Password, PIN
PossessionSomething only you HAVE — Smartphone, Hardware token, SIM
InherenceSomething only you ARE — Fingerprint, Face ID, voice biometrics
0 / 2 required factors
Evolution: from old OTP via SMS to digitally signed push notifications inside secure banking apps — far more resistant to interception.
Transaction Blocked
Select at least 2 factors to authorise the payment.
ACCESS DENIED

Advanced Technical Mechanisms

Art. 5 RTS

Dynamic Linking

The authentication code is cryptographically bound to the amount and the payee. Changing either the destination or the amount immediately invalidates the code — anti Man-in-the-Middle.

①Awareness: amount and payee shown before confirmation
②Integrity: data digitally signed in the SCA packet
③Uniqueness: code valid only once, for that specific operation
Anti-Man-in-the-Middle
UX Optimisation

SCA Exemptions

The RTS provide exemptions to balance security and usability. The PSP must prove it has advanced fraud monitoring systems.

E-commerce < €30
Max cumulative: €100 or 5 consecutive transactions
Contactless ≤ €50
Max cumulative: €150 or 5 consecutive transactions
Recurring subscriptions
SCA only on the first transaction of the series
Whitelisting
Payees added to the user's trusted list
Infrastructure

Tokenisation & PCI-DSS

Sensitive card data never reaches the merchant's servers. The input is a protected iframe from the payment gateway, which returns only a unique token to the merchant.

// Merchant only receives:
"tok_1NxZ3aLkdIwABC"
// Real data stays at the gateway
Reduces PCI-DSS scope
EMVCo Standard

3-D Secure: 1.0 vs 2.0

Version 2.0 overcomes the limitations of v1.0 — poor mobile compatibility, static passwords, fragmented experience — thanks to a native SDK, ML and over 150 data points for risk assessment.

Parameter 3DS 1.0 3DS 2.0 ✓
Integration Browser (iframe / redirect) Native mobile SDK + browser
Data exchanged ~15 elements 150+ elements
Authentication Static password / SMS OTP Biometrics + signed push notification
User Experience Friction (frequent interruptions) Frictionless / selective Challenge
Risk analysis Static and limited Real-time Machine Learning (RBA)
Risk-Based Authentication (RBA): If the risk is low (known device, consistent behaviour), the transaction proceeds in frictionless mode — no interruption. If anomalies are detected, the Challenge Flow is triggered with mandatory SCA.
Open Banking Infrastructure

API Architecture

A banking API allows a Fintech's software to "talk" to the bank in a standardised way. REST architecture, JSON format, three mandatory security layers.

Layer 1 — Identity
eIDAS Certificates
QWAC — authenticates the TPP's website
QSealC — digitally signs the data
Issued by EU certified authorities
Layer 2 — Channel
mTLS
Mutual TLS — mutual authentication
Both TPP and bank authenticate each other
Data in transit cannot be intercepted
Layer 3 — Protocol
FAPI
Financial-grade API — more restrictive than OAuth 2.0
Protection against injection and session hijacking
International standard for banking
API Response — JSON
// Press "Simulate Call" to see the JSON response...

OAuth 2.0 Token Lifetimes

The token mechanism separates user authentication from app authorisation, without ever sharing the bank's username and password.

Authorization Code
< 10 minutes
Temporary code exchanged immediately by the TPP. Used only once to obtain the final tokens.
Access Token
30 – 60 min
Authenticates every single API call. Expires quickly to limit damage in case of interception.
Refresh Token
Days / Months
Renews the Access Token without involving the user. SCA mandatory every 90–180 days for AISPs.
Step-by-step orchestration

Payment Simulator

Experience how the bank decides between speed and security through Risk-Based Authentication and 3DS 2.0.

🛒

New Online Purchase — €80

Choose the scenario to simulate:

Cybercrime Post-PSD2

Threats in the Open Banking Era

As technical defences have strengthened, criminals have shifted their focus to the weakest link: the user and legacy communication channels. Select a threat.

📞 Social Engineering
Manipulation + AI deepfake vishing
📡 SIM Swap Fraud
OTP interception — makes SMS useless
🎣 Phishing AitM 2.0
Transparent proxy — EvilProxy / Starkiller
🏦 APP Fraud
You approve the fraudulent payment yourself
📱

You are about to receive a phone call…

An unknown number calls claiming to be your bank.

Deepfake Vishing: Criminals clone the voice of real bank employees using AI. The call is almost indistinguishable from a genuine one.
Type Main mechanism Technical objective
Social Engineering / Vishing AI voice cloning (deepfake) Forced manual SCA authorisation
SIM Swap Social engineering on telco SMS-OTP interception
Phishing AitM Transparent reverse proxy Session cookie and token theft
APP Fraud Context manipulation Legitimate SCA for fraudulent payment