Our Head of Content, Marie Walker catches up with Openitio's Bhupinder Saini to find out more about their PSD2 MCI....
1. So Openitio specialises in the PSD2 MCI. What exactly is a Modified Customer Interface? What does it accomplish, and why is this suddenly relevant?
Bhupinder: We have a number of Open Banking related products being released this year, of which the MCI is the first.
The MCI is a technical interface that exposes interfaces from a bank / E-money Institution or Payment institution under PSD2 to third party providers (AISPs/PISPs) in a secure and regulated manner so they can access account data in-line with PSD2 RTS specifications.
According to the PSD2 RTS on SCA, the MCI needs to allow ASPSPs to authenticate and identify TPPs before they allow them to screen-scrape (a method used to extract data from a website using customer credentials) or access APIs.
Our MCI does this, specifically blocking access for all TPP's who cannot prove their identity as a regulated organisation, with appropriate PSD2 role & credentials.
2. What does the MCI deliver for Banks / EMIs / Payment Institutions in terms of Regulatory conformance?
Bhupinder: The PSD2 RTS on SCA sets out robust conditions for the secure exposure of dedicated channels for XS2A by institutions. The RTS is also prescriptive in terms of the interfaces that need to be published, specifically a dedicated API interface for ASPSPs going on an API-banking path, or the Web-MCI for ASPSPs who are looking to comply and meet obligations. In both cases the interfaces need to be protected.
To add, organisations with API PSD2 channels have to additionally publish an MCI if they have not explicitly received a (fallback) exemption from their National Competent Authority.
ASPSPs can meet their regulatory obligations for both primary interface and fallback interfaces with an MCI built to PSD2 RTS specifications. For ASPSP's with a primary API channel, the MCI provides fallback capabilities, also known as a contingency mechanism for times when the primary API channel becomes unavailable.
3. What are various options for TPP's to identify themselves for the MCI? Can Banks mandate these options?
Bhupinder: TPP's can use digital certificates which are typically an eIDAS (QWAC/QSEAL) issued by an authorised QTSP or OBWAC/OBSEAL issued by OBIE UK to identify themselves to MCI interfaces.
Yes, banks can specify a set of operational parameters including what type of certificates they will support for the MCI. The general trend seems to be support for QWAC's and OBWAC's to secure the connection between TPPs and ASPSPs.
4. It sounds like the MCI, if not implemented correctly, could potentially be a problem from an information security and GDPR standpoint. Can you elaborate on the relationship between the PSD2 MCI, Data Safeguarding and GDPR?
Bhupinder: Let me start by clarifying that in fact risk is substantially reduced. As Openitio MCI provides an additional security layer, specifically for GDPR type data redaction, on top of requirements mandated by the PSD2 RTS. Without this, screen-scraping becomes considerably riskier to banks and their customers for potential breaches or fraud.
Our MCI redacts and filters data at a PSD2 product level, which means non-payment-account related products such as mortgages, credits cards, pensions etc. are filtered out in addition to Personal Data (GDPR) redaction.
5. How does the MCI mitigate risks of Fraud and Data Theft?
Bhupinder: The main problems with traditional screen scrapping are:
1. Customers handing over banking credentials to TPPs;
2. Banks having no way to identify if a TPP who then approached them with these credentials, was regulated and had the appropriate roles as per the FCA or relevant NCA's for a given jurisdiction.
By forcing all TPPs to present specific and valid digital certificates to prove their identity to banks, our MCI lets banks verify that all TPPs requesting customer data have the necessary license(s) to operate.
The Openitio MCI interface also enables 2-way secure communications between banks and TPPs using QWAC, which reduces the risk of data loss/theft.
I expect systems like the MCI will lead to a decrease in fraud rates for screen scrapping based solutions.
6. And who has defined what the MCI is and how this should work? Is it the EBA or the FCA/PRA in the UK?
Bhupinder: Well, the requirements came from specific PSD2 RTS sections related to SCA (Strong Customer Authentication) and CSC, but UK Finance provided clarity on what the MCI interface needs to deliver in a white-paper two years ago.
The Finance.UK paper described four options ASPSP can adopt, of which only 2 (the 3rd and 4th options) meet all the regulatory requirements. If you'd like to see what this is, check out page 16 of the paper here.
The 3rd option describes how an MCI must force the use of eIDAS type certificates to identify TPPs and also cover personal data redaction. In contrast, the 4th option includes additional non-psd2 account redaction functions as well.
7. And how does Openitio fit into all of this? How is the Openito MCI positioned vis-a-vis the Finance.UK options?
Bhupinder: The Openitio MCI is a lightweight regulatory product that meets PSD2 requirements, and all of the specifications outlined in Finance.UK's 4th option, including full redaction of non-PSD2 information along with redaction of Personal Data for GDPR. With the Openitio MCI, Banks / EMIs and Payment Institutions are in total control of what information TPPs can take from their systems, unlike traditional screen-scraping, where they had no control whatsoever.
8. What use cases do you see from ASPSPs for the MCI?
Bhupinder: We see 3 broad categories:
1. Banks, EMIs and Payment Institutions who have a primary API channel for PSD2, either in place or in development and who have not yet received an exemption;
2. Banks, EMIs and Payment Institutions who have received an exception, but are aware of the fact that regulators can revoke granted exemptions, and if this is the case need a warm-standby in-place as the regulatory timeline only gives them 60 days from the date of revocation;
3. Banks, EMIs and Payment Institutions who are not going down a strategic API journey, who are choosing the MCI as a permanent and low-cost way to meet PSD2 obligations.
9. How does the MCI solution fit in with a Banks / EMIs / PIs dedicated API program?
Bhupinder: Given that our MCI can be stood up within 3-5 of days, often even sooner, ASPSPs are adopting the MCI as a low-cost tactical system they can put in to satisfy regulatory requirements.
ASPSPs can choose to stay with the MCI as a dedicated regulatory interface until the time API interfaces are stable. Besides, the MCI can also be deployed to protect the API channel as a gateway.
We are even working with API Banking specialists, including Fiorano and Ozone API on strategic roadmap approaches that guarantee a smooth journey from MCI to API.
10. My last question, as with any regulatory requirement, I'm sure there are many Banks / EMIs / PIs out there who are wondering if this is relevant to them? Is there anything you are doing to provide market clarity?
Bhupinder: That's a great question, Marie.
Yes, of course. We are working with some key partners including Konsentus and Fiorano on a series of webinars to provide this badly needed clarity.
The next one planned is: 23rd March, 10am (UK)
Why do you need a PSD2 compliant Modified Customer Interface?
- Brendan Jones, Konsentus Limited
- Bhupinder Saini, Openitio Limited
- Biju Suresh Babu, Fiorano
Besides, specifically for Banks, PIs and EMIs who are not sure if they need one or not, we have published a free online self-help assessment tool that takes less than 2 minutes to complete and helps organisations check if they need one or not.
Here is the link. I would encourage Banks, EMIs and PIs to check it out.