QSealC

Definition

The QSealC (Qualified electronic Seal Certificate) is a qualified eIDAS certificate that lets a TPP electronically sign every HTTP request sent to a bank.

Unlike the QWAC, which stops at the TLS layer, the QSealC operates at the application level: the signature travels within the request itself and constitutes legally enforceable proof of who sent what, when and with what content.

QSealC vs QWAC: signature vs identification

This is the fundamental duality of PSD2 security:

• QWAC — identification at the transport level (mTLS): "I really am Bridge." It disappears after the handshake.
• QSealC — signature at the application level (HTTP-signature): "here is my request, sealed, provable tomorrow." It persists in logs and traces.

In the event of a dispute (a contested payment), it is the QSealC the bank will produce, not the QWAC.

How the signature works

The standard is HTTP-signature (adopted by STET and the Berlin Group):

1. The TPP computes a hash of the request body (Digest).
2. It selects several critical headers (request-target, host, date, digest, x-request-id).
3. It signs them with the private key associated with the QSealC.
4. The signature is added to the Signature header.
5. The ASPSP retrieves the QSealC (via keyId), verifies the signature and replays the digest.

Any alteration in transit — even a single character — invalidates the signature and rejects the request.

What a QSealC does not do

• Does not secure the connection: that is the role of mTLS (with the QWAC).
• Does not replace SCA: it proves the TPP's identity, not the PSU's.
• Does not sign on its own: the TPP must implement the chain correctly (digest, headers, signature) — forgetting x-request-id or using a different case are common mistakes.
• Is not the same as a personal signature: it is an electronic seal of a legal entity, not of a natural person.

Within the PSD2 ecosystem

The QSealC is the non-repudiation building block: without it, a TPP could deny having sent a request, or an attacker could alter a transfer request in transit without detection. It is what gives the PSD2 flow its legal value.

Real-world examples

• Typical case: a PISP (Fintecture, Bridge, Trustly) initiates a €12,500 transfer. The QSealC seals the amount, the beneficiary IBAN and the timestamp; in the event of a dispute, the bank can prove to the millisecond what the PISP requested.
• Issuers: the same as for the QWAC (Certigna, Certinomis, D-Trust, InfoCert), often sold as a QWAC + QSealC bundle.
• Classic errors: header case (Digest vs digest), a space added after JSON serialisation that changes the digest, a desynchronised clock rejected by the ASPSP.
• Tools: the Bridge and STET sandboxes offer request-dump tools; on the open-source side, the http-message-signatures library (Node, Python, Java) covers most cases.
• On the ASPSP side: the absence of a valid QSealC is the leading cause of rejection in the sandbox — to be checked first.