- 03.07.2020 08:15 am
- 08.04.2019 12:45 pm
- 13.03.2019 12:45 pm
- 14.08.2018 01:00 pm
- 13.02.2018 06:00 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.
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.