In the era of Open Banking, trust is based not only on cryptographic mechanisms. These include the secure transmission of data through encryption, the assurance of the integrity of transmitted information, authentication by means of digital signatures, and the protection of confidentiality. More importantly, however, trust depends on the availability of up-to-date and reliable regulatory data. Cryptographic mechanisms such as Qualified Website Authentication Certificates (QWACs) or Qualified Electronic Seal Certificates (QSealCs) do establish a secure technical connection and confirm the identity of a third-party provider – but they do not indicate whether that provider is still legally authorised to offer certain services.
The often-overlooked risk
This presents a significant regulatory risk: a certificate can remain formally valid even if the third-party provider is no longer authorised to provide payment services. For example, a TPP may have lost its licence – either revoked by the supervisory authority or surrendered voluntarily. It is also possible that specific roles have been withdrawn from the provider, such as the role of Payment Initiation Service Provider (PISP), meaning it may no longer initiate payments on behalf of end customers. Another frequently overlooked scenario is when a TPP holds a valid licence in its home country but has not extended it to the target country through the passporting procedure – thereby lacking the legal right to operate in that jurisdiction.
All these cases have one thing in common: from a technical perspective, the TPP’s access appears legitimate – but from a regulatory perspective, it is not. Failing to scrutinise this carefully can unintentionally open the door to unauthorised access, create liability risks, and potentially result in breaches of PSD2 requirements.
Regulatory risk: What’s at stake with incomplete checks?
A concrete example: customer data could be unintentionally shared with a TPP whose licence has in the meantime been revoked – perhaps due to regulatory breaches or because the provider has ceased operations. There is also the risk of processing a payment transaction initiated by a provider who no longer holds the PISP role and is therefore not permitted to execute payment orders. The situation becomes particularly critical when a TPP is granted access to an interface while being regulated in another EU country but lacking a valid passporting authorisation for the relevant jurisdiction – meaning it is not legally entitled to operate in that market.
Such scenarios are not only violations of the principle of regulatory compliance, they can also result in direct financial and legal consequences. In some cases, the ASPSP may be liable for unauthorised transactions – for example, through refund obligations under Article 73 of PSD2. Moreover, such incidents always put customer trust at risk. If customers perceive that an Open Banking infrastructure is insufficiently protected against unauthorised access, this can lead to long-term reputational damage – a risk that can be easily avoided with a proactive compliance approach.
The solution: Continuous, multi-layered validation
At Qwist, we understand that true PSD2 compliance requires more than the purely technical validation of a certificate. That is why our PSD2 API solution deliberately goes beyond traditional certificate checks – supplementing them with intelligent, multi-layered validation based on up-to-date regulatory data.
In practical terms, this means we verify in real time whether a third-party provider not only holds a valid QWAC or QSealC, but is also genuinely authorised to perform its role – and in the specific jurisdiction where access is being requested. To achieve this, our solution automatically connects to the European Banking Authority (EBA) register as well as relevant national registers. There, we verify:
- whether the TPP is currently listed in the register,
- whether it holds the correct authorisation for its role (e.g. as an AISP, PISP or both).
In addition, we work continuously to further enhance the quality of these checks. A key element of this is the technical integration with National Authorisation Competent services (NACs) and other decentralised sources. This allows us not only to expand the data available, but also to make it significantly more precise – a decisive advantage, especially in cases involving country-specific nuances or sudden changes to licences.
Real-time compliance instead of static checks
So, what happens – in practical terms – if the regulatory status of a TPP changes? For example, if a licence is revoked or a role is withdrawn?
Quite simply: even if the certificate itself is still valid, our solution detects the change immediately – and automatically blocks access in real time. There is no need for manual intervention or daily list checks. Our technology ensures that only providers who are genuinely authorised gain access, based on the current regulatory status of the day. This delivers the highest possible level of security – not only in terms of encryption, but also from a legal perspective. And that is precisely what is crucial for the long-term success of, and trust in, your Open Banking infrastructure.
What this means for your business
With this enhanced register-based verification, you:
- meet regulatory expectations for due diligence (even if not explicitly stipulated in the RTS),
- reduce the risk of unauthorised access and fraud attempts,
- and demonstrate to customers and auditors alike that your PSD2 API is built on real-time compliance rather than static logic.
Conclusion
To achieve PSD2 compliance not only on paper but also in practice, you need more than valid certificates – you need continuous, intelligent validation that seamlessly combines technological security with regulatory conformity. Only by checking both certificates and regulatory status can you truly protect your PSD2 interfaces – and remain secure both technically and legally.
