mTLS

Definition

mTLS (mutual TLS) is a two-way variant of TLS: the client also presents a certificate, whereas standard TLS authenticates only the server.

In PSD2, it is the mechanism that lets a bank (ASPSP) reliably recognise the TPP (AISP, PISP, CBPII) calling its API, via the QWAC certificate presented during the handshake.

Standard TLS vs mTLS

A standard HTTPS connection authenticates only the server: https://mybank.com presents its certificate, the browser validates it, the connection is encrypted — but the server does not know who you are at the TLS level.

With mTLS, the client must also prove its identity: the server requests a client certificate, the TPP presents its QWAC, and the server verifies it (validity, revocation, PSD2 roles) before accepting the connection. The result: even before the first HTTP request, the bank knows which TPP it is talking to.

Why mTLS for PSD2

• Reliable identification through a qualified eIDAS certificate (QWAC), not a mere API key.
• Phishing resistance: without the private key, it is impossible to impersonate a TPP.
• Role verification: the bank inspects the PSD2 roles right from the handshake and cuts off if the role does not match the endpoint.
• Mature standard: natively supported by web servers (nginx, Apache, Envoy, AWS ALB) and HTTP clients.

What mTLS does not do

• Does not sign the HTTP request: that is the QSealC's job. mTLS secures the pipe, not the content.
• Does not authenticate the PSU: that is SCA. mTLS authenticates the TPP, not its user.
• Does not survive a proxy that terminates TLS: a load balancer, WAF or CDN that decrypts TLS loses the client certificate — the most common architecture mistake.
• Does not remove the need for error handling: an expired, revoked or wrong-role QWAC fails the handshake with no HTTP message — you have to monitor the TCP/TLS logs.

In the PSD2 ecosystem

mTLS is the first barrier on the ASPSP side: until the handshake succeeds, no HTTP request is accepted, and so no application logic (consent, payment, read) runs.

Concrete examples

• Fintech architecture: the QWAC must be presented by the backend that calls the bank. With an API gateway in the middle, it either does TLS passthrough (the backend handles mTLS) or re-establishes the connection with its own QWAC — never an unconfigured load balancer between the two.
• Testing: curl --cert qwac.pem --key qwac.key https://api.banque.fr/accounts validates a QWAC before bringing up the whole stack.
• Classic pitfalls: cipher suites mandated by the bank (TLS 1.2 ECDHE/RSA-AES-GCM), an incomplete certification chain (forgetting the intermediate CA), a precise SNI required in the ClientHello.
• ASPSP side: the frequent mistake is terminating TLS too early (front-end reverse proxy), which loses the QWAC — the fix: forward the client certificate in a signed header, carefully.
• Operational cost: monitor QWAC expiry (alerting at T-30, T-15, T-7), automate rotation when the TSP allows it, and track revocation (CRL/OCSP) to avoid a silent outage.