Moniepoint’s products are often praised for their speed and reliability. From our terminals to our personal banking application, millions of our customers can trust that their transactions will not just go through, but do so at lightning speed. For a company of our scale, there are quite a few factors that contribute to this, but connecting them all, is our core banking application, and here’s the story of how it came alive.

Simple origins

A core banking application is a back-end system that handles banking transactions and financial records. Things like deposits, withdrawals, loans and more are all made possible by the core banking application.

For what Moniepoint initially was - an agency banking solution, these functions were handled by a simple table. It was a wallet table where the balances were saved and could be changed when a transaction occurred—just a basic database.

The problem with this was that it was too simplistic, prone to error and not at all scalable.

By the start of 2020, around a year after Moniepoint’s agency banking solution was first launched and had begun to gain traction, the risks associated with using the current system far outweighed whatever benefits of simplicity it brought. It was time to switch to a proper core banking application.

Our first attempt at getting a CBA

Caleb, who’s currently a project manager at Moniepoint, had spent less than a year at the company when the project he’d been working on was put on hold. He was excited to get on something new, and while he sought what that could be, he got a call from Felix about our plan to switch to a CBA.

Until this point, most of the transactions performed on Moniepoint were withdrawals and deposits. But the people who used the product were beginning to request more features, like loans, for example. And this was something to take into cognisance as we explored getting a new core banking application.

The first option was finding an open-source CBA that could handle our needs. Caleb spoke with Adrian, SVP of UX (who was a project manager at the time), about these needs. They started looking at assets, liabilities, expenses, and many other accounting terms and concepts they needed to familiarise themselves with to make sense of the project they were about to embark on.

After doing this for a couple of days, he was called to work with Sulaiman, an enterprise architect,  on getting the new open-source CBA ready. Caleb’s job then was to study the system as a QA and figure out how it worked. Sulaiman’s job was to look at the code, and how we could integrate with it. Then, they would share their ideas with Tosin, our CEO.

The goal was to get an in-depth knowledge of this CBA, as that was the only way they could work with it. They explored how it worked in different scenarios and use cases.

After about a week of working on that, trying to figure out if it had everything they needed, they were getting closer to perfectly understanding it, and could tell what was working and what wasn't. They understood how everything flowed and were preparing to go live.

The screw loose in the engine.

Going live with this open-source core banking application would involve connecting it to Moniepoint’s agency banking app, and using it for our agents. The plan was to have a demo the next day, then progress to staging, beta testing with some merchants, and eventually, migrating everyone onto it.

On the day before the demo, Tosin asked a question that would change our direction with this. As they discussed what they had discovered about the CBA we were planning to use, he asked a question about the transaction references.

Every transaction involves debit entries and corresponding credit entries, and although each transaction had a reference, Tosin asked if there was a reference for each debit and credit entry within a transaction batch.

The answer was No. With this CBA, you could track a batch, but not the entries within that batch. And that was a dealbreaker. We needed to be able to track the entries within each batch.

Later that day, they stopped working on that CBA, as Felix had a decision to make; we either modified the code of the open-source application so it would have what we wanted, or we would build our CBA from scratch.

Turning point

Both of those options had their pros and cons. The positives of modifying the code of the existing open-source software were that, firstly, we wouldn’t be starting from scratch. This meant that we could save time on months of development and updates, and have far less work to do. It also meant that we could deliver the entire thing faster.

However, there were possibilities of the complexity of the code. Being an open-source application meant it would also be challenging to predict the maintenance of the codebase. The team discussed the pros and cons of whatever direction they’d take, and Felix decided on the next step. 

Building our own CBA

A couple of weeks before the COVID-19 pandemic, Toba, SVP of core systems, got a call from Felix, our CTO, asking him to come into the office to discuss. Felix had decided to go with the option of building our own CBA.

Toba came into the office, and they had a deep dive. Everyone shared their knowledge of a CBA  - how it should work, and a couple of initial requirements that we needed for an MVP. They talked about the table structures, endpoints, expected behaviours, and more, and that 3-4 hour meeting went a long way in the product itself.

With this knowledge, Toba returned home to work on building something small for starters that they could test out. Part of it was influenced by the insight that Caleb and Sulaiman had garnered from extensively studying the open-source CBA we had hoped to use. The other part was years of experience gained from building similar solutions for Nigeria’s leading traditional banks.

The primary goal was to be able to post transactions. This involved a double entry - debiting an account and crediting another concurrently.  Ergo, for every debit, there had to be a corresponding credit to compensate for it, and vice versa. They also needed to put other things in place, which involved identifying the common properties they might need to manage on an accounting level.

They put everything together and created a scheme. Even though this was an MVP, they had to ensure they weren’t rushing things. A lot of the necessary context came from the product owners connecting to the CBA, who shared their insights from their previous experiences. The requirements were very clear, and that cut down execution time.

In under 48 hours, working on the code alone at home, Toba had an MVP ready. 

Testing and deployment

As soon as he was done, Toba called Felix to inform him that he had finished working on it. The team then got to work, verifying that this new application could handle our projected load.

Once that was confirmed, it was about converting that viable product and making sure that all the extra things that needed to be put in place down the line, that the CBA would not provide were available on it as well. And that took place over a couple of weeks.

The CBA today

Soon after, integration started. Moniepoint was still primarily an agency banking product at the time, and became the first product integrated with the CBA. Every hand was on deck as they worked on migrating accounts from the previous system to the new application that had been built. They also continuously monitored it to ensure that all the posted entries were accurate.

Over the next few months, Toba and Felix continued to make iterations and improvements to the MVP, and Caleb came on as a QA. With the bulk of the work done, Toba focused on making necessary updates with Felix, and Caleb would come on to test as soon as they were done.

The first of these updates happened a month after the MVP and periodically over the next 8-9 months. Every month, they would add something new or make a significant update on something we had before, based on the requirements of the other products that were using it, too.

With many more requests, they pushed the CBA to its limit and optimised it to help with the load. The initial data source was just MySQL, and then they introduced Clickhouse. They had a CDC (change data capture) system in place, so the main database could handle the writes, while the reads went to clickhouse. That allowed us to adjust the system and process more transactions.

It grew from a simple double-entry system to a proper core banking application that could handle many more features typical of a traditional core banking app. Features like interests, account sweeping, overdrafts, and liens, were introduced as we released more products, bringing us to the CBA we have today, that powers the dreams of millions across emerging markets.

If you'd like to be part of a team that's redefining the financial experience for the next million Africans, click here to claim your spot.