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

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

Ilia Dragan

Head of PSD2 Compliance Solution at Salt Edge

Views 439

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

29.06.2020 09:45 am

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.

Latest blogs

TYRON JONES n/a

How Technology Has Disrupted the Used Car Buying Experience

We’ve seen many fields change rapidly as a result of the integration of modern technological advancements over the last couple of decades. And it looks like more is coming on the horizon as well, judging by current trends. One of the markets that Read more »

Shuvo G. Roy Mphasis

Reboot 1.0: How financial services technology can enable the supply chain to support a post-lockdown boom

Ground control and Captain Tom When veteran Captain Tom Moore decided to walk one hundred laps of his garden before his 100th birthday to raise funds to support NHS heroes battling Covid-19 from the frontline, he never imagined that he would Read more »

Lisa Gutu Salt Edge

Building a PSD2 compliant channel: challenges and opportunities for financial institutions

PSD2 obliges ASPSPs including banks, e-wallets, prepaid cards and other companies that offer payment accounts to provide at least one channel for secure communication with third party providers (TPP). Even neobanks or e-money institutions, including Read more »

Thomas Pintelon Capilever

Credit origination - A lot of innovation on the horizon

While consumer credits are becoming more automated and user-friendly to request, all other credits are often still very manual and labor intensive to originate. In this (relatively long) blog I will try to give a description of the (potentially Read more »

Kelly Kearsley Hourly.io

Time Card Theft is a Big Problem. Here's How to Stop It.

Trust is at the core of every employer-employee relationship. You trust your people to do their jobs, and they trust you to compensate them for their work. Most of the time, it works. However, there's always the person looking to bend the rules or Read more »

Related Blogs

Lisa Gutu Salt Edge

Building a PSD2 compliant channel: challenges and opportunities for financial institutions

PSD2 obliges ASPSPs including banks, e-wallets, prepaid cards and other companies that offer payment accounts to provide at least one channel for secure communication with third party providers (TPP). Read more »

Arta Sylejmani Gemalto

Building a Trust Loop: How banks can transform their relationship with the customer

Today’s consumers expect a frictionless customer journey, regardless of whether they are shopping online, applying for a mortgage or opening a new bank account. Delivering such a seamless customer experience will require banks to not only boost Read more »

Danny Healy MuleSoft

PSD2 Deadline Tomorrow - How Should Banks Respond?

Tomorrow marks PSD2’s next deadline – the point by which banks must make their open APIs available for testing by payment and account information service providers. Danny Healy, financial technology evangelist at MuleSoft has thoughts on it. Danny Read more »

Anna Tsyupko Paybase

If you have a gig/sharing economy business or online marketplace, there has been a big change in legislation that you need to know about

Changes to the commercial agent exemption require action, but they will bring benefits to all involved You may not have heard of the ‘commercial agent exemption', but if you have an online marketplace or gig/sharing economy business, you may have Read more »

Nick England EasyFX

PSD2: The Honeymoon Period

PSD2 has been one of the most fiercely debated payments topics of recent times. Will this be the death of traditional banks? Will consumers get a better deal when it comes to financial products? Are FinTech’s going to take over? Read more »

Magazine
ALL
Free Newsletter Sign-up
+44 (0) 208 819 32 53 +44 (0) 173 261 71 47
Download Our Mobile App
Financial It Youtube channel