At the Mojaloop Foundation, we’re dedicated to closing the financial inclusion gap by powering inclusive real-time payment systems, and we recently hosted a webinar that explores the role of a payment initiation service providers (PISP) in these systems. The webinar featured industry leaders from Google, Crosslake Technologies, ModusBox and the Mojaloop Foundation and dove into how third parties creating services in the last mile are helping make transactions simpler, safer and more cost effective. To learn more, view the complete webinar.
The audience engagement on the webinar proved the importance of and interest in the topic, and the speakers fielded a wide array of questions. Below is a sample of those questions, starting first with some Mojaloop-specific inquiries:
There are some commercial MNOs who are building interoperable solutions for Africa. How will Mojaloop deal with those entities? Will there be an overarching framework to incorporate those solutions? How do they intend to compete with/replace those?
We see the Mojaloop Foundation as a movement around payment interoperability, and we want technology players and those creating schemes and payment systems to see this as an open innovation forum for us to connect and make the open-source aspect itself a useful component for those doing the hard work on the ground. We absolutely still need those groups to keep doing what they’re doing. Mojaloop Foundation isn’t running payment systems; we’re open source software for the digital public good, and we want to work with those schemes on the ground to remove fragmentation and create interoperability across solutions.
Is Mojaloop free for MFIs?
Mojaloop is open source technology. There are components of the software that help MFIs very cost effectively get connected to a Mojaloop Powered Scheme, but Mojaloop is not the scheme that decides per transaction pricing. The price to the participants and the price of the transactions is going to be set by the scheme that decides to implement Mojaloop.
Does Mojaloop cover EU PSD2 requirements?
What we have proposed with Mojaloop certainly covers the two factors required when initiating payments. We have true possession, which is the FIDO credential, and with FIDO you’re required to grant consent with each and every request, which reduces the possibility for multiple use tokens to be stolen or copied from system to system. As far as the security authentication authorization aspect goes, our proposal more than satisfies PSD2 requirements.
As part of explaining the Mojaloop 3PPI initiation design, the presenters showed a working demo, with a fictitious service “PineapplePay” that provided its customer with a smartphone app. The app allowed the customer to link her bank accounts and initiate payments to any account connected to the Mojaloop Scheme, without returning to the bank’s app – no need for the recipient to also use Pineapple Pay or have a smartphone.
The discussion prompted several interesting questions:
Can PineapplePay operate with Mobile Money operators as well, in addition to banks?
Short answer: yes. The 3PPI API is designed to help those creating smartphone apps to be able to act on behalf of any account holding institution in a Mojaloop Scheme – with consent from the account holder and strong authentication of every transaction (e.g. using FIDO biometrics and One Time PINs). That means if a mobile money operator wants fintechs to be able to act in this way, they need to sign up to enable this service for their account holders.
How Does PineapplePay get Compensated?
What we see a lot in the industry today is an assumption of a per-transaction-fee margin centered business model. What this thinking allows us to do is to decouple how PineapplePay makes money from how customers manage their money. This is groundbreaking!
The 3PPI API means that PineapplePay doesn’t need to own either the credit party account or the debit party account – they can imagine different business models such as gig economy platforms that connect farmers to buyers, school tutors to students, taxi drivers to customers and more. In some cases they will be paid by enterprises simply for providing an excellent payroll software solution or agent management tool suite.
It’s important that everyone in the ecosystem figure out a sustainable livelihood, but fundamentally per transaction additional charges to the customer are not the only option available long-term.
What is the ultimate recourse that a payer would have in the event of an attempted fraud by a hacker?
Security is only as good as the credential mechanism. Schemes have to think about a lot of practical realities in order to go to market, and the software will serve the scheme’s decisions.
We also are able to introduce the concept of multifactor authentication in this story. Right now, most digital financial services on the ground rely on pins and passwords. What happens if we change that so it’s more about devices, or biometrics, or the size of the transactions or something else we know about the typical patterns of the bank?
The bank is still very much part of this, and their fraud and risk management systems are still very central to this question. The software can’t address it on its own. The ultimate recourse depends on the implementation and how the scheme wants to implement the technology.
Given PineapplePay is responsible for authentication in the payment initiation process, in the unlikely event of fraud, which party is responsible for financial loss? The account holding bank, Mojaloop or PineapplePay?
It’s important to remember that while PineapplePay is the one who requests the signature for authentication, it’s the bank or money provider who is responsible for evaluating the signature.
At the end of the day, PineapplePay has no money on the system as part of the transaction. When it initiates a payment, it is doing nothing more than asking the bank to please send the money between these two accounts, and it provides the signature to authenticate. So, barring any scheme rules that dictate otherwise and any bilateral agreements between different parties, the most obvious and standard place for this to happen is for the source of funds to evaluate the transaction and cancel it if it’s suspicious.
The organization receiving the request from PineapplePay has the ability to say no, so the buck stops there in terms of fraud responsibility. Mojaloop’s technology players think a lot about what good looks like, and we will support schemes and DFSPs thinking about launching the 3PPI use case via a Mojaloop powered hub.
We hope you found this Q&A helpful. To learn more, watch the webinar and check out this recent white paper, Design Principles for Third-Party Initiation in Real-Time Payment Systems.
Connect with us here to join the Mojaloop community, and be sure to follow us on Twitter, LinkedIn and Facebook for all the latest.