“Open banking” is one of those terms that marketing teams love to overuse. A side effect of this overuse is the dilution of the term’s meaning. Even within ModusBox, the definition varies because we work with various types of financial institutions (FIs) and governmental organizations spanning the globe. In the US, we help fintechs ease the pain of connecting to community financial institution (CFI) customers via our “Fintech Hub,” PortX. Throughout developing countries, we’re collaborating with organizations ranging from national level payment network operators to microfinance institutions to enable easy connectivity to and participation in inclusive real-time payment networks. As a result, every person we engage has a slightly different perspective.
In a quest to clarify the definition of “open banking,” I asked two of our experts, Dr. Warren Carew and Paul Makin, to join me, Kent Brown, for a conversation to uncover what it means at ModusBox and its impact on the financial services industry.
PSD2 vs. Open Banking Standard vs. open banking
Kent:
Open banking can have a different meaning in the US than in the UK, Europe, and even developing countries where we do much of our work. Please start by clarifying the difference between PSD2 and open banking.
Paul Makin:
The first important distinction is that PSD2 (the second Payments Services Directive adopted by the European Commission, enacted in 2018) and the Open Banking Standard are two separate but related sets of regulations. The Open Banking Standard is the UK’s implementation of PSD2, and remains in place even though the UK is no longer a member of the European Union. In addition, the term “open banking” is used widely throughout the industry as the practice of allowing financial service providers (FSPs) to initiate payments or access a customer’s banking data via their financial institution. So, it can get confusing.
AISP, PISP, and 3PPI
Kent:
Tell us more about the different facets of open banking, such as AISPs, PISPs, and for Mojaloop, 3PPI.
Paul:
Open banking can be segregated into two parts: payment initiation and account information.
AISPs
Account Information Service Providers, or AISPs, are authorized by both the account holder and their bank to retrieve that customer’s account information from their bank. For example, one of the most well-known AISPs in the US is Plaid. People utilize Plaid to transfer their customer account information from their bank, building society (UK), or credit union (US) to a fintech or payment application such as Venmo.
PISPs
To complement AISPs, Payment Initiation Service Providers, or PISPs, are authorized by both the account holder and their FSP to initiate a payment from their bank to somebody else, often using a third-party mobile app. A merchant can also initiate payments as a customer authorization request, asking them to approve a purchase from their account. For example, imagine receiving a prompt to authorize a payment from your bank through your Amazon app. When you agree, the PISP completes a merchant request to pay.
3PPI
A key weakness in the PISP model is that it requires a service provider to gain access to the functionality by integrating with each bank before it can offer the service to the banks’ customers. Through a partnership with Google Pay, we solved this problem for Mojaloop. It’s called Third-Party Payment Initiation (3PPI), and it solves this problem by aggregating the PISP service into the Mojaloop Hub. When a PISP service provider integrates with the Hub, they instantly integrate with every FSP connected to the Hub.
The AISP role is more challenging than PISP because it requires an AISP to pull account information from the core banking system (balances, transactions, etc.) behind the security protocols. PISPs can take a more “anonymous” approach, and whether it succeeds or fails, the account number and other details are hidden from the outside observer. Nonetheless, in view of its potential, we are exploring ways to integrate AISP into Mojaloop.
If you would like to learn more about PISP and 3PPI, read Drive Innovation and Inclusion in Real-Time Payment Networks with Payment Initiation Service Providers.
Assuring interoperability
Kent:
Please expand on the difference between PISP and Google Pay’s 3PPI functionality built into Mojaloop.
Warren:
The most significant distinction between Mojaloop’s 3PPI functionality and PSD2 and Open Banking in Europe is that Mojaloop has a built-in common service. To help illustrate this concept, my Garmin smartwatch connects with Starling Bank and some other FIs. Unfortunately for me, it does not link to my principal bank provider. However, my wife’s Samsung watch does connect to our bank as well as Starling and others. In the absence of a common service, organizations have developed individual point-to-point integrations, creating bilateral technical and business relationships – which undermine interoperability.
The emergence of API aggregators
Paul
The problem that Warren just described has resulted in the emergence of API aggregators – a relatively new industry where much of the open banking innovation is taking place in Europe. An API aggregator acts as a replacement for a common service (like Mojaloop has) because an organization only needs to integrate with a single aggregator connected with everyone else. The aggregator does all the challenging work of wrangling other APIs so that fintechs only need to integrate with a single API. The 3PPI approach eliminates this additional integration work on behalf of the FSPs, which, with Mojaloop, comes for free.
Warren:
Stripe is a well-known aggregator worldwide but there are others such as African organizations such as PayStack (which is one of Stripe’s global investments). The economics speaks to how valuable this industry is. Aggregators are very successful (and highly valued) companies doing a job that, in part at least, may have been eliminated had the original participants designed for it from the beginning – as we did with Mojaloop. However, since everyone else couldn’t get their act together, they fill a significant business need due to the relative complexity of maintaining connections with each participant in the system.
Pros and cons of API aggregators
Warren:
Stripe has become the de-facto standard in the US because it gained critical mass. Other organizations now have to imitate its process. It’s a capitalistic approach to setting a standard; whoever wins defines the interface.
Paul:
The other side of that is that there are many standards from which to choose. No single aggregator dominates the market.
Additionally, one of the predictable side effects of aggregators is that all large banks in the UK have tried to set themselves up as aggregators. If you have a NatWest Bank account, you don’t need to use anyone else; just access all your accounts through NatWest’s banking app.
Warren:
Aggregators introduce another problem: Who’s responsible, and who do you trust? Within the Mojaloop and Google 3PPI initiative, we’ve created a solution where the Mojaloop platform provides a one-to-many Fintech-to-Account-holding-institutions as a PISP. Once a fintech connects to Mojaloop, it can link to all FIs on that Mojaloop hub. The connected banks are still required to support the PISP function. However, any fintech that joins the network can immediately connect when they do, creating a tremendous economy of scale.
The Mojaloop model is so powerful that if an organization told me that it wanted to be a PISP aggregator, I would simply tell them to run a Mojaloop hub!
What’s next?
In our next conversation, we’ll take a more in-depth look at how we designed Mojaloop to expose similar services to those of the PSD2 standard but with Mojaloop-specific APIs that foster true interoperability and economy of scale. Additionally, we’ll discuss the shortcomings of the ISO-20022 messaging standard, the pitfalls to watch out for, and how to avoid compromising your design when building an ISO-20022-compliant interoperable instant payment system. Lastly, in this conversation, we’ll elaborate on our approach to building open banking tools that propel connections between CFIs and fintechs.
To learn more about all of our open banking solutions, start by visiting our PortX platform overview page. If you need support on your Mojaloop journey, either as a scheme owner or hub operator, please start a conversation with our Payment Solutions team.
About our conversationalists
Kent Brown is Co-Founder and CTO at ModusBox with 30+ years of experience in technical cloud development and integration. Prior to ModusBox, Kent played various roles in software architecture, development, and product management at Microsoft and Merrill Lynch primarily focused on cloud, distributed computing, and enterprise integration.
Dr. Warren Carew is Managing Director at INFITX,. Warren has been a leader in the Digital Financial Services industry since 2005, when he played a significant role on the team that created and launched the industry-shaping mobile money service M-PESA in 2007. Warren leads the core design and development team for Mojaloop.
Paul Makin, Digital Finance and Identity Consultant, is one of the creators of the M-PESA mobile money service. In 2004, as a consultant to Vodafone, he conceived the core operating model and developed many of the concepts behind agent liquidity management. Paul works with financial regulators, mobile money operators, banks, funding agencies, and others across emerging markets. He has recently been a key contributor to the core design team for Mojaloop.