Tick the 11 boxes if your Modified Customer Interface meets each PSD2 requirement

According to the second Payment Service Directive (PSD2), all the financial institutions that provide payment accounts (ASPSPs) - banks, e-wallets, prepaid cards, neobanks and e-money institutions with their agents - must have in place at least one channel for secure communication with third party providers (TPP). They can choose to offer a dedicated channel (API) or a Modified Customer Interface (MCI), being obliged to provide a sandbox 6 months prior launching the channel(s) in production.

Lately I’ve been getting more and more questions about the MCI channel, how secure it is, and its overall compatibility with the PSD2 requirements. For any ASPSP that is considering or already offers this implementation, for vendors that offer such service, or for any TPP faced with integrating MCI channels, I’ve prepared a detailed list of criteria, based on the RTS and EBA’s latest opinion, on how to understand whether a certain MCI is fully compliant with PSD2.

1. ASPSP implemented the MCI in such a way as to make payment statuses available to PISP (including payment statuses and execution of payment transaction) and has this documented

RTS, Article 30.1.C:  “... payment initiation service providers are able to communicate securely to initiate a payment order from the payer's payment account and receive all information on the initiation of the payment transaction and all information accessible to the account servicing payment service providers regarding the execution of the payment transaction.”

2. ASPSP’s MCI supports same PSU authentication methods and has documented all authentication flows

RTS, Article 30.2:  “For the purposes of authentication of the payment service user, the interface referred to in paragraph 1 shall allow account information service providers and payment initiation service providers to rely on all the authentication procedures provided by the account servicing payment service provider to the payment service user.”

3. ASPSP’s MCI follows international standards and references them in documentation 

RTS, Article 30.3: “Account servicing payment service providers shall ensure that their interfaces follow standards of communication which are issued by international or European standardisation organisations.”

4. ASPSP has documentation on all the routines, protocols, tools, URIs, XPath selectors used on all the pages available via MCI

RTS, Article 30.3: “Account servicing payment service providers shall also ensure that the technical specification of any of the interfaces is documented specifying a set of routines, protocols, and tools needed by payment initiation service providers, account information service providers and payment service providers issuing card-based payment instruments for allowing their software and applications to interoperate with the systems of the account servicing payment service providers.”

5. ASPSP has a summary of the MCI documentation on the website, publicly available without registration

RTS, Article 30.3: “Account servicing payment service providers shall at a minimum, and no less than 6 months before the application date referred to in Article 38(2), or before the target date for the market launch of the access interface when the launch takes place after the date referred to in Article 38(2), make the documentation available, at no charge, upon request by authorised payment initiation service providers, account information service providers and payment service providers issuing card-based payment instruments or payment service providers that have applied to their competent authorities for the relevant authorisation, and shall make a summary of the documentation publicly available on their website.”

6. ASPSP has documented the process of notifying TPPs 3 months in advance before applying any changes to the MCI or to the testing facility

RTS, Article 30.4: “In addition to paragraph 3, account servicing payment service providers shall ensure that, except for emergency situations, any change to the technical specification of their interface is made available to authorised payment initiation service providers, account information service providers and payment service providers issuing card-based payment instruments, or payment service providers that have applied to their competent authorities for the relevant authorisation, in advance as soon as possible and not less than 3 months before the change is implemented.

Payment service providers shall document emergency situations where changes were implemented and make the documentation available to competent authorities on request.”

7. ASPSP’s MCI provides a testing facility that can be used by any licensed TPP (or that are in process of getting the authorization) with eIDAS test or production certificates. ASPSP also has available the corresponding documentation on the testing facility

RTS, Article 30.5: “Account servicing payment service providers shall make available a testing facility, including support, for connection and functional testing to enable authorised payment initiation service providers, payment service providers issuing card-based payment instruments and account information service providers, or payment service providers that have applied for the relevant authorisation, to test their software and applications used for offering a payment service to users. This testing facility should be made available no later than 6 months before the application date referred to in Article 38(2) or before the target date for the market launch of the access interface when the launch takes place after the date referred to in Article 38(2).

However, no sensitive information shall be shared through the testing facility.”

8. ASPSP’s MCI has documented how uniquely identification of each payment transaction is performed

RTS, Article 35.4.b: “... for payment initiation services, the uniquely identified payment transaction initiated”

9. ASPSP’s MCI has documented how uniquely identification of requests for confirmation on the availability of funds is performed

RTS, Article 35.4.c: “... for confirmation on the availability of funds, the uniquely identified request related to the amount necessary for the execution of the card-based payment transaction.”

10. ASPSP has a mechanism to notify TPPs about errors in MCI and this process is documented 

RTS, Article 36.2: “... exchange of the data elements, the account servicing payment service provider shall send a notification message to the payment initiation service provider or the account information service provider and the payment service provider issuing card-based payment instruments which explains the reason for the unexpected event or error.”

11. ASPSP’s MCI has documented app-to-app authentication flow (in case ASPSP has mobile app)

Opinion of the European Banking Authority on obstacles under Article 32(3) of the RTS on SCA and CSC, Clause 12: “ASPSPs that enable their PSUs to authenticate using biometrics when directly accessing their payment accounts or initiating a payment, and that require the PSU to authenticate with the ASPSP to use AISPs/PISPs’ services, should also enable their PSUs to use biometrics to authenticate with the ASPSP in a PIS or AIS journey. Given that biometrics are not transmittable credentials, this means that these ASPSPs should enable their PSUs to authenticate with the ASPSP in an AISP or PISP journey using biometrics, by supporting decoupled authentication or app-to-app redirection to the ASPSP’s authentication app, and secure transmission of the ASPSP’s app authentication status to the ASPSP (e.g. using a signed proof that the biometric validation has been performed successfully).”
Clause 14: ”If the interfaces provided by ASPSPs do not support all the authentication procedures made available by the ASPSP to its PSUs, this would be a breach of Article 30(2) RTS and an obstacle under Article 32(3) RTS.”

MCI by definition can support only embedded and decoupled authentication flows, while redirect (OAuth) or app-to-app authentication flows can be implemented only via API interfaces. 

In case ASPSP relies on proxy service for controlling access to MCI and such proxy service is delivered by a third party vendor, all data from and to TPPs are accessible by the vendor (including PSU credentials and dynamic linking codes).

If you are aware of an MCI implementation that fully meets all these requirements, please share the link to the ASPSP developer portal in comments.