An introduction to Revised Payment Services Directive (PSD2) and PSD2’s Modified Customer Interface (MCI)
The Revised Payment Services Directive (PSD2) is a combination of laws and regulations directed to payment services in the European Union (EU) and the European Economic Area (EEA). This directive was first put in action in 2015, however, the most substantial changes and regulations came into effect on 14 September 2019. The new, revised directive regulates and ensures online payment safety and fraud avoidance.
The PSD2 effectuated updated technical standards which brought changes to the online payments security and implementation. It created a strong legal framework for payment initiation arising from consumer bank accounts. Before PSD2 there had been significant companies’ that provided bank payments growth, however, there was no explicit law regulation to ensure security and uprightness.
To sustain further growth PSD2 came into effect and rendered clear codifying rules to clarify prerequisites. This led to continuous overall growth while ensuring compliance with high security and consumer protection standards.
The payment companies were given a Payment Initiation Service Providers (PISPs) name and were now legally required to hold a license. Before the implementation of PSD2, there was confusion over whom to aid which led to banks denying PISPs requests to access bank accounts. With the effect of PSD2, all banks were required to support and enable PISPs to initiate payment requests.
The principal changes put forward by PSD2 for bank payment initiation services forced banks to adapt to the new requirements. Banks were legally bound to initiate PISPs payments from bank accounts through two methods: Application Programming Interface (API) or PSD2 Modified Customer Interface (MCI).
API is a technical solution controlling how software components interact. It enables systems that belong to separate companies to generate a connection and efficiently operate collectively. Whereas PSD2 MCI is a modified version of a customer's online banking and requires PISP to have the ability to identify itself to the bank. Depending on the bank and its purposes the aforementioned connection types can be rendered on their own or combined.
PSD2 and Modified Customer Interface go hand in hand ensuring customer protection and high-security standards. In general, three different interfaces should be known by any financial payment provider. These are - Customer Interface, Application Programming Interface (API) and Modified Customer Interface (MCI) with Third Party Provider Identification.
Customer Interface is used by the Payment Service User (PSU) to access their banking channels - internet banking, mobile banking etc. According to PSD2 regulations Third Party Providers (TPPs) are not permitted to enter this interface through a screen scraping mechanism.
API is used to dispense access to all banking account information facilities associated with payment accounts. TPPs can only access this information by acquiring a valid PSU’s consent. Account service Provider (AISP), Card Based Payment Instrument Issue (CBPII) and Payment Initiation Service Provider (PISP) should have separate APIs.
As per PSD2 MCI with TPP identification is used for TPPs to access Customer Interface, however, it must be authorised by Electronic Identification, Authentication and trust Service (eIDAS) or NCA. Even more, Account Service Payment Service Provider (ASPSP) should ensure the safeguarding of customer’s personal data. Personal data must remain secured and only financial information is shared. This is required due to General Data Protection Regulation (GDPR) compliance in the EU and EEA. PSD2 Modified Customer Interface is a well-known name, though it can also be referred to as a Fallback Interface or Contingency Mechanism.
The second Payment Service Directive (PSD2) indicates that ASPSPs must have at least one method for secure communication with TPPs. ASPSPs can be banks, e-wallets, neobanks, prepaid cards or e-money institutions with their merchants. They are obliged to impart a sandbox at least six months before the channel's launch and/or production.
Hereinafter are in-depth particulars of how to guarantee that MCI is compliant with PSD2.
According to Regulatory Technical Standard (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.”. In other words, Account Service Payment Service Provider (ASPSP) should have implemented the MCI so that payment statuses and execution of payment transactions would be available to the Payment Initiation Services Provider (PISP). Most importantly, these procedures and provisions must be clearly documented.
Secondly, RTS Article No 30.2 states that “For the purposes of authentication of the payment service user, the interface <...> 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.”. ASPSP’s regulated by the PSD2 through MCI must support the same PSU authentication methods and document these flows.
Furthermore, RTS article No. 30.3 indicates that “Account servicing payment service providers shall ensure that their interfaces follow standards of communication which are issued by international or European standardisation organisations.”. It conveys that MCI that belongs to ASPSP’s must guarantee the following of international standards together with the documentation and its references.
Forbye, Account Service Payment Service Provider (ASPSP) should have all the routines, protocols, tools, URIs and XPath selectors documented and ready to be accessed via MCI. This comes from the RTS article No. 30.3 as stated: “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.”.
ASPSPs are also obliged to have a summary of all the required MCI documentation on their website and publicly available. It means that a party willing to examine the documentation should be able to access it without registering or logging in. Article No 30.3 from RTS states that “Account servicing payment service providers shall at a minimum, and no less than 6 months before the application date <...> 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.”
There is also a requirement for Account Service Payment Service Providers (ASPSPs) to notify TPPs about the upcoming changes in the MCI not less than 3 months in advance. Equally, they must have a clear policy in place to document the process of notification and execute it timely before proceeding with an application. In RTS, article No. 30.4 affirms that “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.”
Additionally, RTS’ article No 30.5 emphasizes the importance of the fact that “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.”. Denoting that ASPSP’s MCI should include a testing facility for all licenced TPP’s, however, safeguarding any sensitive information and restricting it in the testing environment.
PSD2 Modified Customer Interface provided by ASPSP’s should have documentation on the unique identification demands for approval on the availability of funds performance. Moreover, Account Service Payment Service Providers (ASPSPs) must have an instrument to notify TPPs about any faults in PSD2 MCI and document the means. In a case where ASPSP owns a mobile app, it should document the app-to-app authentication flow.
Overall, PSD2 and Modified Customer Interface must go hand in hand to provide accurate service and adhere to the regulations without failure.
We frequently share industry news and Nordigen product updates to our closest friends, fintech innovators and industry experts. Sign up to our newsletter to hear more from us.
By providing your email, you accept