EV-TLS (Extended Validation TLS)

Published on

02/09/2026

Updated on

03/09/2026

Reading time

5 min

Definition

EV-TLS (Extended Validation TLS) refers to a TLS server certificate issued in accordance with the CA/Browser Forum’s strictest validation level. The difference between it and a standard certificate lies not in the cryptography (which is identical), but in the validation process preceding issuance.

An EV certificate attests that the underlying organization actually exists as a legal entity, is registered under the stated company name, and controls the domain. The steps required for this are set out in the CA/Browser Forum’s EV Guidelines.

The three stages of review

StageWhat is checkedMeaning
DV – Domain Validationonly control over the domain“Someone controls this domain”
OV – Organisation Validationadditionally, the organization“an organization of this name exists”
EV – Extended Validationlegal existence, company name, country of incorporation, registration number (according to documented procedure)“This specific legal entity operates this server.”

The leap from OV to EV lies in traceability: the process is standardized, the verified details are presented in a structured format within the certificate, and the certification authority is liable for their accuracy.

What the certificate contains

In addition to the domain name, an EV certificate includes verified identity attributes in its Subject field (such as the registered company name, legal form, jurisdiction, and the organization’s registration number). It also contains a policy OID indicating compliance with the EV Guidelines.

Crucial for machine processing is the fact that these details are stored in structured fields rather than as free text. A receiving system can read them and verify them against expected values.

EV has become invisible to end users, as most browsers stopped displaying the corresponding indicator (the “green bar”) in 2019. However, this changes nothing regarding machine-to-machine communication.

EV-TLS in Verification of Payee (VoP)

The EPC API Security Framework (EPC164-22) governs the securing of interfaces between payment service providers within EPC schemes, such as Verification of Payee and SEPA Request-to-Pay.

An asymmetric assignment applies to VoP that one needs to be aware of:

SideRoleCertificate
ClientVoP Requesting PSP, Routing and Verification MechanismQWAC PSD2
ServerVoP Responding PSPEV-TLS

The framework (as of 2026) explicitly states for the server side: “The API server does not need a QWAC; it can use a standard website certificate. To ensure a sufficiently high level of authentication, an EV TLS certificate is required.”

Both sides authenticate each other – the framework requires mutual TLS: “When calling another scheme Participant’s API’s endpoint, the Participants MUST perform mutual authentication.”

The requesting payment service provider must not only prove its identity but also its regulatory role, as it is requesting third-party account data. For this purpose, the QWAC incorporates attributes from the PSD2 environment. The responding payment service provider only needs to unequivocally prove that it is who it claims to be. EV TLS is sufficient for this.

Distinction from QWAC

Both types of certificates verify an organization’s identity. The difference lies in who vouches for them and under which regime.

EV-TLSQWAC
BasisCA/Browser Forum EV GuidelineseIDAS Regulation (EU) No 910/2014
CharakterIndustry standardEU law
Issuerpublic certification authority in the root programQTSP on the EU Trusted List
Anchor of trustRoot stores of browsers and operating systemsEU Trusted Lists (EUTL)
Checkslegal identity of the organizationlegal identity, qualified under eIDAS
Additionaly–PSD2 roles (PSP_AS, PSP_PI, PSP_AI, PSP_IC) and identifier of the competent supervisory authority
in VoPServer-sideClient-side

Technically, a QWAC is also a website certificate. The difference lies not in the technology but in the chain of trust: with EV-TLS, a commercial certificate authority vouches for the certificate in accordance with the rules of an industry body, whereas with a QWAC, a qualified trust service provider does so under European law.

Other types of certificates used in payment transactions are covered in the entry on certificates.

Overview of the VoP process

EV-TLS and QWAC in a VoP call — two certificates, two trust anchorsA Verification of Payee call begins with a mutual TLS handshake. The requesting payment service provider opens the connection as the API client. The responding provider presents an EV-TLS server certificate, which the client validates against its own trust store of public certification authority roots; the certificate proves the organisation, its jurisdiction and its registration number. The server then asks the client to identify itself. The client presents a QWAC with the PSD2 attributes, which the server validates against the EU Trusted Lists; this proves not only the identity but also the regulatory role and the competent authority. Only once both sides are identified is the channel open and the VoP request can be sent. Two things break this in practice: a missing certification authority root in the trust store, and a QWAC issued without the client authentication extension.Trust storeCA roots, held by the clientVoP Requesting PSPthe API clientVoP Responding PSPthe API serverEU Trusted Liststhe QTSP register1 · the server proves who it is2 · the client checks it — against its own trust store3 · the client proves who it is4 · the server checks it — against the EU Trusted Lists5 · only now the payloadClientHello · the client opens the connectionserver certificate · EV-TLSchain check · is the issuing CA root in the store?valid · organisation, jurisdiction, registration numbercertificate request · the server asks the client to identifyclient certificate · QWAC PSD2trusted list check · is the QTSP listed?valid · identity plus PSD2 role and NCA identifierVOP request · name and IBANVOP response · match · close match · no matchmutual TLS established — both sides identifiedroot not in the trust store → handshake failsQWAC without id-kp-clientAuth → client auth failsA VoP call starts with a handshake — and two very different certificatesThe client opens the connection; the server presents its EV-TLS certificateThe client checks the chain against its own trust store — and no official list of CAs existsThe server asks the client to identify itself: a QWAC carrying the PSD2 attributesThat one is checked against the EU Trusted Lists — identity plus regulatory roleOnly now is the channel open, and the VoP request can be sentTwo things break it in practice: a missing root, and a QWAC issued without client authentication
EV-TLS and QWAC in a VoP call — the server proves itself to a trust store, the client to the EU Trusted Lists

Two outstanding issues

Which certification authority is trusted? Unlike with QWACs, there is no official list for EV-TLS certificates. The EPC clarifies in its FAQs: “The ASF does not specify which CAs can issue EV TLS certificates for VOP” and “No single public source is available listing the root certificates of CAs issuing EV-TLS certificate.”

In practical terms, this means that each participant must manually add the root certificates of the relevant certification authorities to their trust store. The EPC recommends relying on certification authorities common in the European financial sector for the server side, maintaining their root certificates on the client side, and always providing the complete certificate chain during the TLS handshake. Consequently, maintaining the trust store becomes an ongoing operational task—and a silent source of errors if neglected.

Client authentication is disappearing from public certificates. Google’s root program mandates that, starting June 15, 2026, public TLS server certificates must no longer include the client authentication extension (id-kp-clientAuth). Major certification authorities are therefore gradually making the switch (in some cases, this applies to QWACs as well).

The EPC points out that VoP interfaces do not require browser support and that QWAC-PSD2 certificates are not intended for use with browsers anyway. Nevertheless, the implications for financial institutions are concrete: they must ensure that their QTSP continues to issue QWAC-PSD2 certificates containing the id-kp-clientAuth value; otherwise, mutual authentication will fail.

Sources

Back to Glossary

acmt.023 ISO 20022 Message acmt.024 ISO 20022 Message
Berlin Group
camt.027 ISO 20022 message camt.029 ISO 20022 message camt.056 ISO 20022 Message camt.087 ISO 20022 message
ECMS (Eurosystem Collateral Management System) EV-TLS (Extended Validation TLS)
GiroCode
IBAN (International Bank Account Number) IMPay (International Mass Payments) ISO 20022
Overview SEPA Reason Codes
pacs.002 ISO 20022 message pacs.003 ISO 20022 message pacs.004 ISO 20022 message pacs.008 ISO 20022 message pacs.009 ISO 20022 message pacs.010 ISO 20022 message pacs.028 ISO 20022 message pain.001 ISO 20022 message pain.002 ISO 20022 message pain.007 ISO 20022 message
Relay (Payment Initiation Relay) RTGS – Real-Time Gross Settlement
SEPA Request-to-Pay
ViDA
Wolfsberg Group Standards
xBRL-CSV