What happens when QWACs are not used for secure payment communications?

Without QWACs, payment communications lose a strong layer of authenticated encryption, which makes it easier for attackers to intercept traffic, impersonate counterparties, or tamper with data in transit. That weakens trust in the payment chain and can undermine compliance with secure communication requirements under PSD2 and related open banking standards.

How QWACs shape trust in payment communications

QWACs do more than encrypt traffic. They bind the secure channel to a verified payment service identity, so the connection is not just private, but also authenticated in a way that supports cross-organisation trust. In payment ecosystems, that matters because parties need to know they are talking to the right endpoint before exchanging sensitive instructions, credentials, or transaction data.

Without that binding, the transport layer may still be encrypted, but the payment relationship is weaker. That is the key distinction: secure transport alone reduces exposure, while a QWAC-backed channel also reduces uncertainty about who is on the other end.

What changes when QWACs are absent

When QWACs are not used, the communication path can lose a high-assurance certificate-based trust anchor. In practice, that can make it harder to distinguish a legitimate counterparty from a lookalike endpoint, especially where routing, intermediaries, or integration complexity create opportunities for impersonation or misdirection.

It also reduces assurance that data in transit has stayed intact. If the channel is not strongly bound to the payment actor, tampering, downgrade attacks, or misconfigured trust chains become more consequential because the receiver has less evidence that the session is both confidential and authentic.

For payment communications that sit inside regulated open-banking or PSD2-aligned workflows, the absence of QWACs can create a trust gap between “encrypted” and “trusted.” That gap is where operational and compliance problems begin, because the system may no longer satisfy the expected standard for secure, authenticated inter-organisation communication.

Why this matters operationally for payment security

Payment systems depend on consistent identity assurance across counterparties, gateways, and APIs. A QWAC is one of the mechanisms used to keep that assurance strong at the transport boundary, which is why its absence can affect both security posture and auditability.

In PCI DSS v4.0, access and account controls are treated as part of a broader expectation that sensitive payment environments restrict and verify who can communicate with them. That same principle is reinforced by EU NIS2 Directive, which pushes organisations toward stronger ICT risk management and trust in critical communications. For identity-bound communication controls, NIST SP 800-53 Rev 5 Security and Privacy Controls remains a useful reference point for authentication, access control, and system integrity expectations.

Risk and Threat Considerations

Removing QWACs from secure payment communications creates a practical trust weakness, not just a cryptographic one. Attackers do not need to break encryption if they can instead exploit weaker endpoint assurance, redirect traffic, or position themselves as a convincing counterpart in the payment path.

Failure mechanism: The communication still appears protected, but the identity of the endpoint and the integrity of the trust chain are less certain, which makes interception, impersonation, and tampering easier to hide or sustain.

Impact: Payment instructions may be exposed or altered, trust between institutions can erode, and regulatory or contractual evidence of secure communication may become harder to defend.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while PCI DSS v4.0 and NIS2 define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-9 — Identification and Authentication (Non-Organizational Users)	Payment counterparties and service endpoints need strong mutual authentication.
	AC-17 — Remote Access	Secure payment communications depend on trusted remote channels and controlled exposure.
	SC-8 — Transmission Confidentiality and Integrity	QWACs support confidentiality and integrity for data in transit.
Recommendation — Use IA-9 to require strong mutual authentication for external payment communications. Apply AC-17 to control and monitor remote payment connections. Enforce SC-8 to protect payment data in transit with authenticated encryption.
PCI DSS v4.0	4.2.1 — Strong Cryptography and Security Protocols	Payment communications require strong cryptographic protection of cardholder-data transmissions.
Recommendation — Use strong cryptography and security protocols for all payment transmissions.
NIS2	Cybersecurity Risk Management Measures	Payment communications are part of ICT risk management and secure trust-chain obligations.
Recommendation — Treat payment-channel authentication as an ICT risk-management requirement.

Practitioner Guidance

What to verify: Confirm that secure payment channels are not relying on encryption alone, and that counterparties are authenticated with a trust model appropriate to the payment relationship. If the channel carries regulated payment traffic, the identity of the endpoint should be verifiable in a way that survives audit and incident review.

Decision rule: If a payment integration handles production transfers, delegated access, or regulated API traffic, treat certificate-based identity assurance as part of the control surface, not as an optional transport add-on. When that assurance is missing, the risk assessment should cover impersonation, man-in-the-middle exposure, and trust-chain failure before focusing on performance or integration convenience.

Practitioner takeaway: The real loss without QWACs is not only confidentiality, it is trustable authentication of the payment channel, which is what makes secure communication defensible in practice.