PSPs are required to use a QWAC PSD2 certificate when sending a VOP Request for authentication by the Responding PSP. When a PSP uses the services of an RVM to initiate its VOP Requests, the PSP must share its certificate - including the private key - with the RVM. Although certificate sharing is common with API aggregators in PSD2, PSPs are hesitant due to the sensitive nature of QWAC PSD2 credentials and the associated security risks. The following measures are recommended to mitigate these risks:
- A PSP should use a dedicated certificate for VOP; this allows the certificate to be revoked at any time without impacting other processes.
- RVMs must implement IT security best practices, including secure key storage (e.g., TRSM) and robust incident response procedures.
- The PSP can restrict the usability of the QWAC PSD2 certificate by including only appropriate values in the Role Field to prevent the certificate from being for used for payments if compromised. This measure is explained in more detail in the remainder of this article.
Restrict usability of the QWAC PSD2 Certificate through the Role field:
The ETSI TS 119 495 standard defines the QWAC PSD2 certificate; this includes the available PSD2 roles (e.g., PSP_PI, PSP_AI). The role determines the certificate’s scope: some roles (e.g., PSP_PI) allow payment initiation, while others (e.g., PSP_AI) do not. The EPC identified following options to use this field to restrict the usability of the certificate:
- Option 1: use roles like PSP_AI or PSP_AS (low risk, no technical changes)
A PSP can request a QWAC PSD2 certificate that only includes the PSP_AI role and does not include PSP_PI. This mitigates the risk of the certificate being used for initiating payments should it be compromised.
This option can be implemented within the current ETSI standards, without any technical changes.
- Option 2: use role “Unspecified”
A PSP can request a QWAC PSD2 certificate with the role set to “Unspecified". This type of certificate cannot be used for PSD2 Open Banking; hence it significantly reduces the risk of the certificate being used for other purposes should it be compromised. According to the ETSI standards the authorisation of the requester must be done using “other means” when such certificate is used; this corresponds to the approach for VOP whereby the authorisation needs to be verified against the EDS.
Some communities (e.g. AT, NL) confirmed they intend to use this option. However, there is no common practice (yet) for role “Unspecified”; therefore, there is a risk that some Responding PSP or RVM currently don’t accept such certificates and will need to adapt their API authentication solution (it is to be noted these PSPs and RVMs would not be compliant with the EPC API Security Framework if they don’t support the ETSI standard); and there is a risk that some QTSP do not (yet) support these types of certificates.
Conclusions and EPC recommendations:
- Requesting PSPs and RVMs:
- Preferably use a QWAC PSD2 certificate with only role PSP_AI if available for the PSP as this role does not allow making payments and is already generally accepted by all PSP for PSD2.
- The role “Unspecified” can be used to limit the usage of the certificate to the VOP services; however, this role may not explicitly prohibit payments in a future scenario for instance and this role might not be accepted generally by all responding PSPs.
- Responding PSPs and RVMs: it is recommended to ensure certificates with any role, including “Unspecified”, are accepted as it’s very likely there will be PSPs who will use this type of certificate for VOP to restrict its usage. The role should not be checked.
Way forward: introduce a new VOP-specific role in ETSI standards
The EPC consulted representatives of ETSI who concluded that a new role could be defined (without a new scheme) that will be used in an Open Finance use case in the ETSI standard. A QWAC PSD2 certificate with such new role would not be usable for PSD2 Open Banking.
This approach requires an update of the ETSI standards and all PSP and RVM need to ensure their API authentication solution supports the updated ETSI standard. ETSI are evaluating an update of the standards to support VOP in a next version; the EPC will provide further communication once this progresses.