QWAC for Canada

Canada's shift toward open banking and cross-border fintech partnerships has pushed a niche European compliance instrument into the spotlight for Canadian companies: the Qualified Website Authentication Certificate, or QWAC. Originally created under the EU's eIDAS regulation to secure PSD2 API connections between banks and third-party providers, QWACs are now becoming relevant to Canadian payment processors, neobanks, and account aggregators that operate across European payment rails or hold licenses as Payment Initiation Service Providers. This guide explains exactly what a QWAC is, how it differs from standard TLS certificates, why regulatory frameworks like OSFI B-13 and the Consumer-Driven Banking framework are driving adoption in Canada, and what practical steps a Canadian company needs to take to obtain, deploy, and maintain one without risking a compliance failure or a production outage.

Understanding What a QWAC Certificate Actually Is and Why It Differs from Standard TLS

A QWAC — Qualified Website Authentication Certificate — is a specific type of TLS certificate defined under the eIDAS regulation (Electronic Identification, Authentication and Trust Services). It is not a marketing label or a premium tier of an ordinary SSL certificate. It is a legally defined instrument issued only by a Qualified Trust Service Provider (QTSP) listed in an EU member state's Trusted List.

The key difference from a standard Domain Validated (DV) or Organization Validated (OV) certificate:

For Canadian companies operating in cross-border fintech, open banking, or digital identity contexts — particularly those serving European clients or integrating with European payment rails — a QWAC is not optional. It is the technical and legal prerequisite.

Why Canadian Fintech and Financial Services Companies Are Looking at QWAC Now

Canada's open banking framework moved from consultation phase to implementation phase between 2023 and 2025. The Department of Finance Canada released the Consumer-Driven Banking framework in 2024, and by 2026 accredited participants in the Canadian open banking ecosystem are required to authenticate API connections using certificates that meet specific trust criteria.

While Canada has not adopted eIDAS directly, the influence of European frameworks is significant for three reasons:

1. Cross-border payment corridors. Canadian payment processors, neobanks, and account aggregators increasingly handle transactions that pass through European payment infrastructure. SWIFT ISO 20022 migration and open API connections with European banks require mutual authentication using certificates both sides recognize.

2. FINTRAC and OSFI compliance overlap. OSFI Guideline B-13 (Technology and Cyber Risk Management), updated in 2024, explicitly requires financial institutions to implement strong mutual authentication for API-based data sharing. QWACs satisfy this requirement because they carry verified legal identity — not just domain ownership.

3. Passporting and equivalency. Several Canadian fintech companies hold licenses in EU jurisdictions to operate as Payment Initiation Service Providers (PISPs) or Account Information Service Providers (AISPs) under PSD2. Those licenses require QWAC and QSEAL certificates for each API call to a bank's dedicated interface.

The Technical Architecture of a QWAC: What Is Actually Inside the Certificate

A QWAC is an X.509 certificate. From a protocol perspective it functions identically to any TLS certificate — it enables the TLS handshake, encrypts the channel, and authenticates the server. The difference is in the certificate contents and the issuance process.

Key fields in a QWAC that are absent or optional in standard TLS:

• Certificate Policy OID: 0.4.0.194112.1.4 (QCP-w, defined in ETSI EN 319 411-2). This OID signals to relying parties that the certificate was issued under a qualified policy.
• QCStatements extension: Contains id-etsi-qcs-QcType with value id-etsi-qct-web, confirming it is a qualified website authentication certificate.
• Subject fields: Must include the organizationIdentifier field encoded according to ETSI EN 319 412-1. For PSD2 use, this field includes the Authorization Number (e.g., PSDDE-BAFIN-12345678), the competent authority, and the roles (PSP_AI, PSP_PI, PSP_IC, PSP_AS).
• NCAName and NCAId: The National Competent Authority that granted the PSP its license under PSD2.

For a Canadian company with a European license, this means the certificate literally encodes the regulatory authorization inside the cryptographic object itself. When a bank's API gateway reads the certificate, it can verify both the TLS channel and the regulatory standing of the connecting party in a single operation.

How QWAC Fits Into the PSD2 Technical Architecture for API Authentication

Under PSD2 (EU Directive 2015/2366) and the associated Regulatory Technical Standards (RTS on Strong Customer Authentication, Commission Delegated Regulation 2018/389), banks must allow third-party providers access to payment account data and payment initiation. That access happens through a dedicated interface — typically a REST API using OAuth 2.0 or similar flows.

The authentication flow works like this:

1. The TPP (Third Party Provider) presents its QWAC during the TLS handshake to the bank's API gateway.
2. The bank's gateway extracts the organizationIdentifier from the certificate.
3. It validates the certificate against the QTSP's OCSP responder or CRL to confirm it has not been revoked.
4. It checks the QCStatements to confirm qualified status.
5. It maps the Authorization Number to the EBA (European Banking Authority) register of authorized PSPs.
6. If all checks pass, the API session proceeds.

This entire flow happens in milliseconds, at the TLS layer, before any application-level authentication occurs. There is no separate login, no API key exchange for identity — the certificate is the identity.

For Canadian companies acting as TPPs in Europe, step 1 requires a valid, current QWAC issued by a QTSP. An expired or revoked QWAC immediately breaks step 6. This is why certificate lifecycle management is operationally critical.

The eIDAS 2.0 Update and What It Changes for QWAC Holders in 2026

eIDAS 2.0 (Regulation EU 2024/1183) entered into force on May 20, 2024 and is being phased in through 2026 and 2027. It introduces several changes relevant to QWAC:

• EUDIW (EU Digital Identity Wallet): Member states must offer citizens and businesses a digital identity wallet by 2027. QWACs will be a component of relying party authentication within the wallet ecosystem.
• Expanded qualified trust services: Article 45 of eIDAS 2.0 introduces new requirements for browsers to recognize and display qualified certificates differently. This was already contentious — the original Article 45 text was amended after pushback from browser vendors, but qualified certificate recognition remains a requirement.
• New certificate types: eIDAS 2.0 adds Qualified Electronic Attestation of Attributes (QEAA). While not replacing QWACs, these attestations can be combined with QWAC-authenticated sessions to provide richer, verifiable identity claims.
• Non-EU equivalency: eIDAS 2.0 creates a clearer path for non-EU countries to achieve mutual recognition. Canada is not yet on that path, but bilateral digital trade agreements under CETA (Comprehensive Economic and Trade Agreement) include provisions that Canadian negotiators have cited when discussing technical standards alignment.

For Canadian companies, the practical implication in 2026 is: if you need QWAC today for PSD2 compliance, you will also need to monitor eIDAS 2.0 timelines because the certificate profiles and QTSP requirements are updating, and QWACs issued under the old profile may require renewal or replacement earlier than their stated validity period.

QSEAL Certificates: The Other Half of the PSD2 Certificate Requirement

QWACs handle channel authentication — they secure and identify the TLS connection. QSEALs (Qualified Electronic Seals) handle message-level authentication — they sign the HTTP request bodies so the bank can verify the message was not tampered with in transit.

Most implementations use both:

Under the Berlin Group's NextGenPSD2 framework (the most widely implemented open banking API standard in Europe), TPPs sign requests using the QSEAL private key and include the signature in the Signature HTTP header. Banks validate this signature using the public key from the QSEAL certificate retrieved from the QTSP's directory.

A Canadian fintech company connecting to a German, French, or Dutch bank API will need both certificates active and correctly configured. Losing either one breaks the connection — QWAC revocation cuts the TLS channel, QSEAL revocation breaks message signature validation.

How to Obtain a QWAC in Canada: The Practical Steps

Canadian companies cannot obtain QWACs from Canadian CAs because no Canadian CA is a QTSP under eIDAS. The certificate must come from a QTSP listed in the EU Trusted Lists (currently administered by ENISA following the eIDAS 2.0 transition).

The process involves:

Step 1: Obtain a PSP license in an EU member state. This is the regulatory prerequisite. Common choices for Canadian companies are Ireland, Lithuania, and the Netherlands — all have fintech-friendly licensing regimes and English-language regulatory communication. The license application involves AML/KYC documentation, business plan, capital requirements, and fit-and-proper assessments of management.

Step 2: Receive your Authorization Number. The National Competent Authority (NCA) — for example, the Central Bank of Ireland — assigns an Authorization Number upon license grant. This number goes into your QWAC.

Step 3: Select a QTSP. Major QTSPs operating in 2026 include Certigna (France), D-Trust (Germany), InfoCert (Italy), Swisscom Trust Services (Switzerland, with EU recognition), and several others. Selection criteria: supported certificate profiles, OCSP response times, directory infrastructure, pricing, and support for Canadian company legal structures.

Step 4: Complete identity verification. The QTSP must verify your company's legal identity. For a Canadian company with an EU branch, this typically requires notarized or apostilled corporate documents, director ID verification, and confirmation of the EU license from the NCA.

Step 5: Generate a CSR (Certificate Signing Request). Your private key must be generated in an HSM (Hardware Security Module) or equivalent secure environment. The CSR must include the correct subject fields. The organizationIdentifier field format is strictly specified — errors here result in rejection.

Step 6: Certificate issuance and integration. QTSP issues the certificate (typically within 1–5 business days for first issuance, faster for renewals). You configure it in your API gateway, test against sandbox environments, then deploy to production.

Validity period: QWACs are commonly issued for 1-year or 2-year terms. Renewal should begin at least 30 days before expiry.

Certificate Lifecycle Management: The Operational Risk Most Companies Underestimate

Certificate expiry is one of the most common causes of production outages in fintech API infrastructure. A QWAC expiry does not produce a gradual degradation — it causes an immediate, hard failure of every API connection that relies on mutual TLS.

Notable incidents that illustrate the risk:

• In 2022, a mid-sized European neobank lost access to 14 bank connections simultaneously when their QWAC expired on a weekend with no automated renewal process.
• In 2024, a Canadian payment aggregator operating in Europe failed a compliance audit because their QSEAL certificate had been renewed but their QWAC had not, leaving a 9-day gap in their certificate validity chain.

Lifecycle management best practices:

Automated certificate management using ACME protocol is available from some QTSPs but not all. For QWACs specifically, the identity verification requirement makes full automation impossible — a human must confirm the company's regulatory status has not changed.

How QWACs Interact with Canadian Open Banking Standards

Canada's Consumer-Driven Banking framework, as enacted through the Financial Consumer Agency of Canada (FCAC), does not mandate QWACs. However, it does require that:

• API connections between accredited participants use mutual TLS.
• The certificate used for mTLS must contain verified organizational identity.
• Certificates must be issued by a CA that is trusted within the accreditation framework.

The technical specifications published by the FCAC's open banking working group in 2025 reference the Financial Data Exchange (FDX) API standard. FDX's security profile requires mTLS with OV or EV certificates at minimum for domestic connections.

For companies operating in both Canada and Europe simultaneously, the practical approach is to use QWACs even for Canadian domestic connections where the regulatory minimum is OV. A QWAC satisfies OV requirements and more — it contains full verified legal identity and does not expire more frequently than a standard OV certificate.

This dual-use approach reduces certificate inventory complexity: one certificate type, one renewal process, one HSM setup, regardless of which API you are connecting to.

Comparing QWAC Providers: What to Evaluate Beyond Price

The QTSP market has consolidated since 2022. Several smaller QTSPs have ceased operations or merged. As of 2026, the relevant evaluation criteria for a Canadian company selecting a QTSP are:

Technical criteria:

• OCSP response time (should be under 200ms for production environments)
• OCSP stapling support
• Directory service uptime SLA
• Support for eIDAS 2.0 certificate profiles (important for 2027 compliance)
• API for automated certificate status queries
• HSM options (cloud HSM, on-premise, QTSP-managed)

Operational criteria:

• Certificate issuance turnaround for renewals
• Support for Canadian legal entity structures in subject field encoding
• English-language support (not all European QTSPs offer this)
• Revocation process and response time in case of key compromise

Compliance criteria:

• Audit reports (ETSI EN 319 401, EN 319 411-1, EN 319 411-2)
• Presence on current EU Trusted List (verify directly on the ENISA Trusted List Browser — not on the QTSP's own marketing materials)
• History of compliance incidents

Comparing major QTSPs on key operational parameters in 2026:

Note: Entrust's main commercial CA had its Chrome trust removed in 2024, but its EU QTSP subsidiary operates under separate qualified trust infrastructure and is unaffected by that action.

Digital Identity Beyond Certificates: Where QWAC Fits in a Broader Security Architecture

A QWAC handles one specific problem: proving to a remote API gateway that you are a legally authorized entity before the session begins. It does not replace other security controls.

A complete fintech security architecture for a Canadian company operating cross-border includes:

Transport layer:

• QWAC for outbound mTLS to European bank APIs
• Separate OV/EV TLS for customer-facing web properties
• HSTS preloading and OCSP stapling on all public endpoints

Application layer:

• OAuth 2.0 with PKCE for user authorization flows
• QSEAL for message-level signing on PSD2 API calls
• JWT with short expiry for session tokens

Identity layer:

• FIDO2/WebAuthn for user strong authentication
• EUDIW integration (for European users from 2027)
• KYC/AML API connections using verified identity attributes

Operational security:

• HSM for all private key storage (QWAC, QSEAL, signing keys)
• Certificate transparency log monitoring
• Automated revocation checking for incoming client certificates

Compliance monitoring:

• Continuous monitoring of QTSP Trusted List status
• Automated alerts for certificate expiry across all environments
• Audit logging of all certificate operations for OSFI B-13 reporting

Common Mistakes Canadian Companies Make When Implementing QWAC

Based on implementation patterns visible in the industry, the most frequent errors are:

1. Using the QWAC private key in a software keystore instead of an HSM. eIDAS requires private keys for qualified certificates to be protected at a level equivalent to a secure signature creation device. Software keystores do not meet this requirement. If a QTSP audit reveals this, the certificate can be revoked.

2. Encoding the organizationIdentifier incorrectly. The field must follow the format specified in ETSI EN 319 412-1, Section 5.1.4. The Authorization Number format varies by country and regulatory authority. Errors here are not caught until the certificate is rejected by a bank's API gateway.

3. Not monitoring OCSP response validity. OCSP responses have their own validity period (typically 24–72 hours). If your server is not configured for OCSP stapling and the QTSP's OCSP responder has a temporary outage, relying parties may get indeterminate responses and reject your certificate.

4. Treating QWAC renewal as a one-time task. Certificate teams sometimes treat the first issuance as the complex part and assume renewals are automatic. They are not. Renewals require re-verification of company details and, if the company's regulatory status has changed (new license, new NCA), the certificate subject fields must be updated.

5. Not testing in sandbox before production renewal. Most major European banks operate open banking sandbox environments. Always test a renewed certificate in sandbox before deploying to production. A misconfiguration that would cause a production outage takes minutes to catch in sandbox.

6. Conflating QWAC with website SSL. A QWAC should not be used as the TLS certificate for your public website unless it is specifically configured for that purpose. Browser display of QWACs varies — Chrome, Firefox, and Safari do not currently display the qualified status indicator, so using a QWAC for a consumer-facing site provides no visible trust benefit to end users.

OSFI B-13 and QWAC: What Canadian Banks and Fintechs Need to Document

OSFI Guideline B-13, Technology and Cyber Risk Management, requires federally regulated financial institutions (FRFIs) to maintain documented controls for:

• Third-party API authentication (section 4.2)
• Certificate management (implicit in cryptographic controls section)
• Vendor risk for trust service providers (section 5.1)

For an FRFI connecting to a third party that presents a QWAC, the compliance documentation should include:

• Process for validating incoming QWACs (OCSP check, Trusted List verification, OID check)
• Vendor risk assessment for the QTSP that issued the QWAC
• Incident response procedure for QWAC revocation events
• Testing schedule for mTLS certificate validation logic

For a Canadian fintech that is not an FRFI but is an accredited participant under the Consumer-Driven Banking framework, similar documentation is required by the FCAC accreditation criteria.

Frequently Asked Questions About QWAC Certificates in Canada

What is the difference between a QWAC and an EV TLS certificate, and can an EV certificate replace a QWAC for PSD2?

No, an EV (Extended Validation) certificate cannot replace a QWAC for PSD2 compliance. They share some similarities — both require verified organizational identity — but they differ in critical ways. An EV certificate is issued under CA/Browser Forum guidelines and carries no specific regulatory OID for financial services. A QWAC is issued under ETSI EN 319 411-2, carries the QCP-w policy OID, includes the PSD2 Authorization Number in the organizationIdentifier field, and is issued by a QTSP on the EU Trusted List. A bank's PSD2 API gateway checks for the specific QCStatements extension and the ETSI OID — an EV certificate without these fields will fail that check regardless of its validation level.

Does a Canadian company need a European entity or branch to obtain a QWAC?

Yes, in practice. The QWAC must contain a valid PSD2 Authorization Number issued by a European National Competent Authority. To obtain that number, the company must hold a PSD2 license in at least one EU member state. You do not necessarily need a full legal subsidiary — some member states (Ireland and Lithuania in particular) allow passporting arrangements and branch licenses — but some legal presence and a license application process are required. The QTSP will also need to verify your legal entity details, which are easier to provide when the entity is registered in an EU jurisdiction.

How long does it take to get a QWAC from application to production deployment?

The bottleneck is the PSP licensing process, not the certificate issuance itself. Once you hold a valid EU license, certificate issuance from a QTSP typically takes 2–10 business days for initial issuance, depending on the QTSP and the completeness of your documentation. Renewals, where identity details have not changed, can be completed in 1–3 business days. The licensing process itself, depending on the jurisdiction, takes 3–18 months. If you already hold a license and need your first QWAC urgently, prioritize QTSPs that offer expedited processing and have existing processes for non-EU company structures.

What happens if a QWAC is revoked and how quickly does it affect API connections?

Revocation takes effect as quickly as relying parties check certificate status. Banks using OCSP stapling or real-time OCSP checks will detect the revocation on the next TLS handshake attempt. In practice, most production systems detect revocation within minutes to a few hours. The impact is immediate disconnection from every bank API that validates certificate status in real time. If revocation is caused by key compromise, you should also assume that any transactions signed with the compromised QSEAL private key may be disputed. Revocation procedures require notifying your QTSP, which initiates the OCSP status update and CRL publication. Emergency revocation for key compromise should be completed within 24 hours under ETSI standards.

Can a QWAC be used for mutual TLS in Canadian domestic open banking connections?

Yes. Canadian open banking technical standards require mTLS with verified organizational identity, and a QWAC satisfies that requirement. Using a QWAC for Canadian domestic connections when you already hold one for European compliance eliminates the need to maintain separate certificate types. The QWAC contains richer identity information than a standard OV certificate, which can simplify audit evidence for FCAC accreditation and OSFI B-13 documentation. The only consideration is that your Canadian counterparties' systems must be configured to accept the ETSI-specific OIDs in the certificate without rejecting them as unknown extensions — this is a configuration issue on the receiving end, not a problem with the certificate itself.

What are the key differences between eIDAS and eIDAS 2.0 for QWAC holders and when do the changes take effect?

eIDAS 2.0 (Regulation EU 2024/1183) is being implemented in phases. For QWAC holders, the most significant near-term changes are: browser recognition requirements under Article 45 (timeline still being finalized through implementing acts in 2026), updated certificate profiles from ETSI to accommodate EUDIW relying party authentication, and new requirements for QTSPs to support attribute attestation in addition to identity certificates. Certificates issued under the current eIDAS framework remain valid until their expiry date — there is no forced migration. However, when you renew, your QTSP should be issuing certificates under the updated profiles. Verify with your QTSP that their issuance infrastructure is already aligned with eIDAS 2.0 requirements before your next renewal cycle. QTSPs that have not updated their Certificate Policy documents by mid-2026 represent a compliance risk at renewal time.