By Sophie Njagi, Payments and Fintech Expert at Eqwire
I was a teenager when I watched my mother pay my school fees from a corner shop.
Not at a bank. Not online. At a duuka, the kind of small shop in Embu that sells airtime, eggs, and cold Fanta from the same counter. She took out her phone, typed a few numbers, and the agent behind the counter nodded. Done. Fees paid. We walked home.
I didn’t think anything of it. That was just how things worked in Kenya.
M-Pesa had launched a few years earlier and by the time I was a teenager it was everywhere, not as an app, not as a fintech product, just as life. Market traders used it. Landlords used it. My mother used it to pay school fees at a corner shop because that was easier, faster, and more reliable than anything a bank was offering. This was the mid-2000s. Most European banks still didn’t have a functioning mobile app.
I moved to Cyprus, then London, and I braced for something more advanced. What I found was more complicated which is not the same thing.
The products looked incredible. Slick apps, instant notifications, beautiful design. But the closer I got to how things worked underneath, the more it felt like looking behind a stage set. I worked at a company where the payment experience felt seamless to users and was, internally, held together by three different systems that didn’t agree on when a transaction had settled. If something went wrong on a Friday afternoon, someone in operations was piecing it together manually by Monday morning.
Nobody talked about it openly. It was just how things worked except this time, “how things worked” meant a spreadsheet at 9am on a Monday.
I kept thinking about the corner shop.
M-Pesa wasn’t sophisticated. It ran on basic feature phones over SMS. But it was coherent, every piece of it, from the SIM card to the agent to the confirmation text you got the instant money moved, was designed around one moment – a person who needed to know their money had arrived. Safaricom owned the whole thing, so they could guarantee that moment. There was no gap between what the product promised and what happened underneath.
European Open Banking is trying to reach the same place, giving people control of their financial data, making payments flow freely, letting developers build products that work across banks without starting from scratch each time. The ambition is exactly right. But it was built on top of systems that already existed and had no interest in cooperating, which means the gaps are different. The API works. The thing behind the API sometimes doesn’t.
This is the bit nobody writes about clearly enough, so I’ll say it plainly – getting an Open Banking integration live is easy. Getting it to behave reliably when something goes wrong like a failed authentication, a webhook that doesn’t fire, a payment stuck in pending with no one owning it is where most of the real work is. The user stares at a spinner. They don’t know if the payment went. Neither, sometimes, does the system.
M-Pesa solved this with an SMS. Two pence worth of confirmation that told you instantly, it worked. European Open Banking often has no equivalent moment. Someone in a product meeting decided the API response was enough. It isn’t.
The other thing M-Pesa got right, and this one took me longer to see was the operational layer underneath.
Every corner shop agent in the M-Pesa network had to manage float, from the balance between physical cash and electronic value. Too much cash and not enough e-float, they can’t take deposits. Too much e-float and not enough cash, they can’t pay out. Safaricom built an entire layer of super agents whose only job was to move liquidity around the network so individual agents didn’t run dry. It was unglamorous infrastructure. It was also the reason the system worked at scale.
European fintech has the same problem, just dressed differently. It’s called safeguarding, or treasury, or end of day settlement. And because Open Banking splits responsibility across multiple vendors, your payment rail, your compliance stack, your reconciliation tool, your bank partner, nobody owns the float problem end to end the way Safaricom did. Everyone owns a piece. Nobody owns the gap between the pieces.
I’ve sat in rooms where this gap has come up in an audit and genuinely surprised senior people. Not because they were careless. Because the system looked fine from every angle they were responsible for. The problem lived in the space between responsibilities.
PSD3 is coming, and it will tighten a lot of this with better API standards, clearer liability, stronger fraud protections and that’s real progress. But regulation sets a floor, it doesn’t build the house.
The companies that will pull ahead are the ones doing the same thing M-Pesa did, building the operational layer nobody sees before they need it. Not just connecting the APIs but making the reconciliation, the safeguarding, the failure states, and the user facing confirmation all work as one coherent thing.
That’s a harder problem than it sounds, because you’re building on top of systems designed by other people for other purposes. M-Pesa had the luxury of starting with nothing.
But that corner shop in Kenya is still the best benchmark I know. My mother didn’t need to understand how it worked. She just needed it to work. And it did, reliably, instantly, every time.
That’s the bar. It was always the bar.
About Author
Sophie Njagi is a fintech infrastructure and payments specialist with experience across EMIs, PSPs, banking and crypto-adjacent environments.
As Head of EQWIRE, a UK-regulated Electronic Money Institution authorised by the FCA, she leads product, operational strategy and platform scalability across cross-border financial services infrastructure.
With a background in financial law and expertise in AML, compliance and risk management, Sophie comments on payments infrastructure, fintech regulation, evolving banking models and the operational realities of scaling financial services businesses.
