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 flowsRTS, 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 documentationRTS, 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 MCIRTS, 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 registrationRTS, 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 facilityRTS, 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 facilityRTS, 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 performedRTS, 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 performedRTS, 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 documentedRTS, 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 on my LinkedIn page.

Written by Ilia Dragan, Head of PSD2 Compliance Solution at Salt Edge

About Salt Edge

Salt Edge – a financial API platform with PSD2 and open banking solutions. The company has two main vectors of activity: enabling third parties to get access to bank channels via a unified gateway, and developing the technology necessary for banks to become compliant with the directive’s requirements. ISO 27001 certified and AISP licensed under PSD2, the company employs the highest international security measures to ensure stable and reliable connections between financial institutions and their customers. The company is integrated with 5800+ financial institutions in almost 70 countries.

More information: www.saltedge.com
Phone number: +1-437-886-3969
E-mail: press@saltedge.com

Salt Edge report

Discover what is the current state of open banking in Europe

Download now

Related articles

4 min read Jan 2021

Sorted selects Salt Edge to simplify daily accounting tasks for freelancers via open banking

Sorted, Germany-based accounting app for freelancers and self-employed, teamed up with Salt Edge, a leader in developing open banking solutions, to get instant access to banking data – making the ongoing accounting processes more efficient and preparing for tax season with confidence. These days the global job market is changing…

9 min read Jun 2019

TPP identification challenge for ASPSP under PSD2

According to PSD2, the financial institutions that act as ASPSPs should have in place at least one interface for regulated TPPs (including other ASPSPs that act as TPPs) for identification and secure communication. Identifying themselves is mandatory for all TPPs that wish to get access to ASPSP’s sandbox, live API,…

9 min read Mar 2020

Highlights from the biggest Open Banking event in Eastern Europe

After successfully organizing an inspiring event in London – Open Banking Reality: Beyond the Noise – and sharing its vast experience with other open banking innovators, Salt Edge was ready for the next step and combined forces with MasterCard and Tekwill to power Fintech Moldova Conference 2020, a platform for…

4 min read Apr 2021

FinSS Global to introduce in Australia the CDR Compliance solution powered by Salt Edge

Australia is at the forefront of giving consumers greater control over their data via Customer Data Right (CDR). With phase two of the regulatory adoption quickly approaching, Australian data holders are welcoming a new CDR Compliance solution on the market. The technology solutions expert FinSS Global joined forces with Salt…