Belgium - NBB communication on obstacles to open banking and on access to credit card accounts

On 3 May 2022, the National Bank of Belgium (NBB) released a ‘Communication’ (available in French here and in Dutch here) in which it specified how Belgian account servicing payment service providers (ASPSPs) that have established a dedicated interface are expected to implement relevant guidance from the European Banking Authority (EBA) and the European Commission (EC) in terms of how they give access to payment accounts to third-party service providers (TPPs).

The NBB addresses the issue of some credit card accounts potentially qualifying as payments accounts and therefore being subject to access requirements.

The NBB appears to grant Belgian ASPSPs until 31 March 2023 to not only to comply with the requirement of giving access to some credit card accounts, but in relation to all the issues addressed in the Communication.

Four potential obstacles addressed in the NBB Communication

The NBB covers four topics in its Communication in relation to which an ASPSP may perhaps be considered creating an obstacle to the TPP access to payment accounts; namely,

1. account selection,
2. communication of PSU’s name,
3. confirmation on the availability of funds, and
4. additional checks on consents.

While making it clear that other clarifications proposed by the EBA (e.g. via EBA opinions and Q&A) in relation to other topics remain relevant and the NBB therefore expects Belgian ASPSPs to comply with those even in absence of any specific NBB communication on those topics.

Account selection

In Q&A 2019_4854 (available here), the EBA clarified that ASPSPs cannot reject requests received from PISPs in a redirection or decoupled strong customer authentication (SCA) approach simply because the PISP has not transmitted to the ASPSP the relevant account details (e.g. the IBAN). In Q&A 2021_5763 (available here), the EBA confirmed that the same principle applies to requests received from AISPs.

The NBB clarified the following: where the ASPSP has implemented a redirection or decoupled SCA approach and the TPP has not transmitted to the ASPSP the relevant payment account details, the ASPSP must offer the possibility for the PSU to select, in the ASPSP’s environment, the payment account(s) to which the PSU wants to give the TPP access. This is in line with the EBA Opinion on obstacles (see paragraph 36), in which the EBA stated that dedicated interfaces that require PSUs to manually input their IBAN into the ASPSP’s domain when using TPP services are considered an obstacle. The EBA also provided some examples that ASPSPs may consider (e.g. offering a drop-down list for the PSU to select the payment account(s), or prepopulate the payment account details if the PSU has only one payment account with the ASPSP).

However, the NBB confirmed that ASPSPs requiring separate SCA when the PSU accesses the list of payment accounts in the ASPSP’s environment is not an obstacle.

PSU’s full name

In Q&A 2018_4081 (available here – which was prepared by the EC, and published by the EBA), the EC confirmed that the ASPSP must provide TPPs with the name of the PSU (via the dedicated interface) if that name is included in the information made available to the PSU when the transaction is initiated or access to the payment account is requested directly by the PSU from its ASPSP.

The NBB clarified that if the ASPSP included the PSU’s name in any screen displayed to the PSU in the customer interface when that PSU initiates directly a payment transaction or access directly the payment account, then the PSU’s name must also be provided to the TPPs when they access the PSU’s account. For example, if the PSU’s name is not included on the screen confirming the correct initiation of the payment order, as long as the name is displayed to the PSU in a previous screen, the name also needs to be made available to the TPP.

The NBB further clarified that it is not only the PSU’s name that would need to be shared with the TPPs, but also the name of the agent/employee authorised by the PSU to access the account(s).

If the PSU gave an alias to one or more payment account(s), the ASPSP could not limit itself to sharing that alias to the TPPs. Instead, the ASPSP would still need to provide the TPPs with the actual name of the PSU, if that information was included in any screen displayed to the PSU in the customer interface.

The NBB stresses that ASPSPs must provide the PSU’s name to the TPPs exactly as it is shown to the PSU in the customer interface. For example, in case of joint accounts, the ASPSP would need to share the family names only if this is the way the account appears to the PSUs in the ASPSP’s environment.

Confirmation on the availability of funds

In Q&A 2019_4601 (available here), the EC clarified that upon request, ASPSPs must provide PISPs, with a yes/no answer as to whether the amount necessary for the execution of a payment transaction is available on the relevant payer’s payment account. It is understood that such an answer must be based on the same analysis that the ASPSP would perform in order to determine whether or not to execute a payment order received directly from the payer.

Note that the position taken by the EC in this Q&A is not uncontroversial since PSD2 only seemed to require the provision of such a yes/no answer to the payment service provider issuing card-based payment instruments (CISP) that are contemplated in Article 65 PSD2 and recitals 67 and 68 PSD2 – but not to PISPs which are contemplated in Article 66 PSD2.

The NBB confirms that this confirmation by the ASPSP to the PISP is subject to an SCA of the payer. However, PISPs must have the option to include the confirmation request into the payment order itself that they submit to the ASPSP. If that is the case, the ASPSP can only require one SCA of the payer (i.e. the ASPSP cannot require one SCA for the confirmation on the availability of funds and a second SCA for the payment initiation). This means that any requirement from the ASPSP for second redirection or second SCA to confirm the availability of funds would constitute an illegal obstacle.

It may be the case that certain ASPSPs only confirm the correct initiation of a payment if the relevant payment account has sufficient funds available for the execution of the payment transaction. In that case, ASPSPs may specify in the documentation made available in relation to the dedicated interface that such yes/no confirmation is implicit but certain when the ASPSP confirms to the PISP that the payment order was successfully initiated.

Additional checks on consent

The EBA already clarified that it is the obligation of the TPP to ensure that it has obtained the PSU’s “explicit consent” for the provision PIS/AIS, and the ASPSP cannot check the consent given by the PSU to the that TPP (see EBA Opinion on obstacles, para 43, or also EBA Q&A 2018_4309, available here). Note that “explicit consent” in PSD2 does not have the same meaning as “explicit consent” in GDPR, as confirmed by the EDPB in its guidelines on the interplay of GDPR and PSD2 – available here.

ASPSPs relying on a redirection or decoupled SCA approach are not expected to use within their environment any kind of statement that may somehow discourage PSUs from using PIS or AIS services (e.g. using a statement whereby the ASPSP would ask again the PSU’s consent for the use of third-party PIS/AIS services). Any statement made by the ASPSP must be neutral and strictly fact-based (for example, the following statement is deemed compliant: “the PISP/AISP requested access to your payment account in order to initiate a payment order/consult your account balance. To proceed, you need to be authenticated”).

Similarly, ASPSPs could not set up a button within their environment on which the PSU would have to click before being redirected back to the TPP’s domain (this would be seen as an obstacle). After authentication with the ASPSP, the PSU must be automatically redirected back to the TPP’s environment.

Credit cards accounts

In Q&A 2019 4856 (available here – answer prepared by the EC, but published by the EBA), the EC stated that if

1. an account where funds are covered by a credit line can be used to send or receive payment transactions to or from a third party and
2. that account is accessible online, then that account must be made available to TPPs (via a dedicated interface or a modified customer interface).

This may for example be the case of an account related to a credit card that can be used to make, or receive, P2P payments under e.g. the Visa Direct or Mastercard MoneySend services.

If you would like to receive our regular Payments alerts in your inbox, click here

If you would like to read Bird & Bird’s previous alerts, please check out our Payments In Focus webpage here