Select Region/Country
  • Global
  • Nigeria
  • Kenya

Tech & Processes

November 21, 2023

6 mins read

Redundant systems: how Moniepoint engineers for financial inclusion.

by Chukwudum Ekwueme


You probably wanted to skip this as soon as you saw “financial inclusion” in the title, but hold on for a minute. While it’s easy to chuck it up to a buzzword that’s probably even beginning to lose its fervour, there’s much real work to be done about it to meet the CBN’s 95% inclusion target by next year.

With our products being used by over 33 million Nigerians, across Nigeria’s 774 local governments, a wide range of micro-cultural influences and nuances come into play when people interact with them. Ensuring an inclusive experience for every one of those people remains front and centre when we create products, and this translates into every line of code we write.

What does financial inclusion mean to the excluded?

Picture a business owner situated in any of Nigeria’s local governments that do not cut across major cities. Given the location of this business owner, Mrs Maryann, and her customers, access to banking services is constrained.

The closest bank to them is an uncomfortable distance, and even if they were to make it, resolving whatever challenges they might have depends on several other factors. Because of this, the relationship between people like her and the banking system is tenuous, to say the least.


The more issues she encounters, the less likely she is to feel included in the banking system, or that what exists is meant for her. Compound this over months and years, and you might get an inkling of what’s meant when the financial ecosystem is described as “low trust”.

But this is just one piece of the jigsaw puzzle. For this business owner, whose monthly turnover is just enough to keep her business afloat, ensuring her funds are safe is a top priority. Safety of funds, in this context, goes beyond just fraud. It also means that it’s inconvenient to have her money tied up in unsuccessful transactions, with her money somewhere in financial limbo.

For business owners like this, financial inclusion extends beyond just getting access to financial services. A huge part of the burden involves ensuring that the services they get access to are reliable enough that they can depend on them, and this is where our engineering team swings in with code.

Redundant, but in a good way.


Hypothetically, financial transactions should work simply. To the user, money moves from A directly to B with no drama. But behind the scenes, it’s far more complicated. Several components are involved in making even the most basic transactions a success.

In this context, inclusive engineering goes beyond mapping the direct path from A to B. It also has to include all the likely unlikely things that may occur between the person initiating a transaction, and the person receiving it.

This is why building redundancies forms a core part of engineering at Moniepoint.

Redundancies, in engineering terms, refer to multiple versions of specific components and flows created to improve the reliability of a system. Think of it as plan B-Z, in case plan A doesn’t work.

So, a fire breaks out. Ideally, the fire wasn’t supposed to happen, but here we are. Thankfully, we already made a fire extinguisher available. But what if the fire doesn’t let you get to the extinguisher? What if the extinguisher somehow fails? What if, for some reason, the extinguisher makes the fire get bigger?

Of course, we focus on the more probable “what ifs”, but building redundancies involves accounting for these possible problems. We create multiple fail safes to ensure that, as much as possible, our processes have the highest chance of success.

How we apply this to our products.

A live example of this is our “request for refund” feature. Failed POS transactions may occur for a lot of reasons, and when they do occur, they traditionally take a long time to resolve. The customer takes a printout of their failed transaction to the bank, where they’re told it might take a couple of days for the transaction to be reversed. Sometimes, a reversal never happens.

Beyond building a system that reduces the number of failed POS transactions, our terminals also come with a system that enables merchants to log these failed transactions and request refunds for their customers.

From days, the reversal process is brought down to minutes, without the merchant or their customer needing to disrupt their day. The efficiency of this system increases the likelihood of the customer choosing to make a card payment next time. 

Building redundancies like this means that we end up writing more code. The code to get the thing to work could be 10 lines (wouldn’t that be great if it was actually 10). But accounting for eventualities and handling what happens if it fails could extend it to a 100.

You write more code to make sure what you wrote doesn’t fail. Or that if it does, it can be resolved as smoothly as possible.

Because, in the financial system, there are so many moving parts. Many people you talk to, systems you integrate with, and quite a number of middlemen between the user and the person they’re trying to get to. So we want to make sure, even when it’s “out of our control”, we create systems that ensure that our users don’t experience failure.

Our mentality is that, on the off chance that there’s a problem, solving that problem involves building a system to prevent it from happening again. And that keeps our product teams busy - finding and solving new problems.

What this means for our users.

For the business owner, in our earlier story, most of this is invisible. Our first step is ensuring she has direct access to support as soon as needed. There’s someone down her street who understands our products and likely speaks her language too, and can, thus, give her tailored solutions.

On the side of our engineering team, they’re working to ensure she never even needs the help in the first place. Failed transactions are next to zero, and even when they happen, she knows they’ll get reversed as soon as possible without needing to go anywhere.

As with the “request for refund” feature, financial inclusion for her means having a solution that she can rely on to never fail. And if she can depend on us, so can a million businesses more.

Read similar stories

What’s the Point: The battle with erroneous transfers
Tech & Processes

May 02, 2024

What’s the Point: The battle with erroneous transfers

by Emmanuel Paul

What’s the point of Biometrics in banking?
Tech & Processes

April 25, 2024

What’s the point of Biometrics in banking?

by Emmanuel Paul

My framework for leading as an engineer
Tech & Processes

April 03, 2024

My framework for leading as an engineer

by Konstantinos Prassas

Get more stories like this

Sign up for exciting updates on Moniepoint and how we’re powering business dreams.