Safeguard
Compliance•

QWAC and QSealC under PSD2: which certificate identifies a TPP

PSD2 providers identify themselves with eIDAS qualified certificates. What a QWAC and a QSealC are, who chooses, and what the EBA opinion says.

Safeguard Security Team
3 min read

Under the PSD2 technical standards, payment service providers identify themselves to each other using qualified certificates under eIDAS: either a QWAC for website authentication or a QSealC for electronic seals. The bank that runs the interface decides which one it accepts, and the EBA recommends supporting both.

The two certificates

  • QWAC: a qualified website authentication certificate, used at the TLS layer to identify the party at the other end of a connection.
  • QSealC: a qualified certificate for electronic seals, used to seal messages, so a request can be shown to come from a given provider even after it passes through intermediaries.

Both are issued by qualified trust service providers and carry PSD2 specific attributes, such as the provider's role and authorization details.

What the rule and the opinion say

Article 34(1) of Delegated Regulation (EU) 2018/389 says payment service providers rely on qualified certificates for electronic seals or for website authentication when identifying themselves. The word is "or", so neither is the only legal route.

The EBA published an Opinion on the use of eIDAS certificates on 31 July 2019. Its main points:

  • Account servicing payment service providers (ASPSPs) decide whether to use a QSealC or a QWAC, because they provide the interface and secure the communication.
  • The EBA describes three possible approaches and recommends that QSealCs and QWACs be used in parallel.
  • The Opinion maps payment services to the roles recorded in the certificate.
  • Competent authorities may ask for revocation of certificates issued to a provider whose authorization is withdrawn.
  • Accuracy of certificate information remains the responsibility of the provider and the issuing trust service provider.

Some vendor pages say the standards force QWACs on every call. That overstates the text. Read the regulation and the Opinion directly.

Engineering consequences

  1. Treat certificates as inventory. Record expiry, issuer, role and owner for each, and alert well before expiry.
  2. Plan renewals. A lapsed certificate can take your integration offline.
  3. Handle revocation and role changes. Check status during connection or message validation.
  4. Protect the private key. A sealing key is as sensitive as a signing key. Use hardware backed storage where you can.
  5. Test both modes if the banks you connect to differ in their choice.
  6. Do not rely on the certificate alone. Add OAuth, consent and authorization checks on top.

Where this fits

Certificates identify the party. They do not prove the user consented, and they do not decide what data a call may read. Those are separate controls, covered in our posts on dedicated interface and fallback rules and on SCA exemptions.

Quick check

Who chooses between QWAC and QSealC?

Per the EBA Opinion, the ASPSP that provides the interface decides.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.