In June, we started working on a feature that prioritised the security of users on our app - building out our Fraud Prevention and monitoring tools as part of our ethos to secure users beyond just payment security measures.

For starters, we wanted to add an extra verification layer and then build out a robust fraud prevention tool over time. This extra verification layer requirement, Multi-factor Authentication (MFA), would protect users from situations where one of their verification methods is compromised. This would make the system much more secure and make it difficult for hackers to gain access.

Of course, building the MFA Feature and our whole security-focused ecosystem took a lot of brilliant minds, processes, QA, testing, etc. So here’s a deep dive into what it looked like to bring the Multifactor Authentication(MFA) to life. This is the story of how we’ve made our app a lot more secure for our users:

First of all - under the hood of multi-factor authentication.

Multi-factor authentication refers to security measures that require users to provide more than one verification factor to access a system or app or complete a transaction. The “multi” points out that this verification level can be more than 2, depending on the system and the sensitivity.

The extra verification layer requirement protects users from situations where one of their verification methods is compromised, making the system much more secure and difficult for scammers to access. However, this also meant that users would have to overcome more hurdles than they were previously used to, and we needed to design this feature to be intuitive, convenient and user-friendly while achieving the aim of secure transactions.

MFA typically involves a combination of the following factors:

• Something You Know: A password, PIN, or secret question answer.

• Something You Have: A physical device like a smartphone, security token, or smart card.

• Something You Are: Biometrics such as fingerprint, facial, or voice recognition.

Every transaction must combine at least 2 of the factors above to fulfil multifactor authentication conditions.

As the product team embarked on this journey, they knew that one thing was paramount: building security into the app in a user-friendly way. The overarching vision beyond regulatory compliance is to achieve a robust security flow, such that multiple rules can be set for different types of transactions. If it is noticed, for instance, that some anomalies in your transaction may indicate a breach of your account, it can be intercepted. 

Building out the MFA Feature

The team started the process with design discovery. The first brainstorming was a very high-level session about how to implement the feature. This meant walking through several ideas until a good one emerged - from implementing a hard token (the ones they use in traditional banks) to a soft token. 

Of course, all these things were considered in line with how people use our platform. We did a poll, and Moniepoint users were grouped into buckets, looking at - who are the people using our platform, and what type of transaction falls into the category of the MFA. 

Next, the team leveraged the five KYC levels we have today on our application. In Timileyin’s words, “Naturally, if you’re on KYC Levels 1 and 2, the maximum transaction you can do at a time is already 500k. MFA rules don’t affect you because these are only lower KYC levels.  Based on these rules, we realised that MFA would only impact users on KYC Level 3 and above.” 

The next layer was to look at users on KYC level three and above and how many were using Android versus iOS. These users on these MFA-affecting levels were put in 2 buckets, Android and iOS. We looked at what biometrics verifications are available for the different devices and what that would mean for our implementation. 

Our internal database (DB) was analysed to see the record of devices with and without biometrics on our DB. We looked at the percentage of devices on record without biometrics (which was incredibly low, about 2%), what type of transactions they typically carry out, and what solutions could be provided. 

With that, user research retired, and prototyping commenced. This meant writing a business requirement document and a technical product document. The business requirement document (BRD) comes first, and it’s a general business overview and the requirement from a layman’s point of view. It describes the final outcome and the customer journey - “we want the MFA to be able to do this or behave this way”, and “I shouldn’t have to think about this when I want to do a transaction”. Of course, the acceptance criteria should be 100% from the user's perspective, and there should be no overthinking of the technical details in the business requirement document.

If, as a customer, I want to do a transaction when I enter the amount, and it’s up to 500k, what happens? I should get a prompt to enter my PIN. Or the prompt for me to verify my face before entering my PIN. What if I have not set up my MFA? Part of the BRD is a flow for different user scenarios, including a walk-through if the user had not set up MFA prior to this transaction.

Using experience maps, they show every path a user will most likely take, what triggers will lead to the next event, where there are overlaps, and how to ensure there are no drop-offs due to oversight on our end. 

The BRD usually produces the technical product document once the business requirement foundation has been laid because both documents are dynamic. As more deep dives happen, additional layers are added. They are, therefore, some form of living document.

Once the technical product manager is done putting together the product document to a large extent, the prototyping goes to the next phase, user experience.

User Experience Design

In this next phase, our designer, Alison, used the BRD created to map out the designs, including how they should look, what needs to be on the pages, and what the exceptions are. She did that on Figma, and the product team brought it to FigJam, where both teams touched the flow together. 

After this, engineers, PMs, and everybody else did a deep dive. This deep dive focuses more on what happens at the backend of every point of the flow path. While this happened, the team also created a prototype flow and link using Useberry. This created a prototype flow of what happens when you click on these transactions: images you can interact with. 

The product team got some users to a moderated research session. They also brought business owners on the call, a mix of people with and without biometrics-enabled devices. Giving them the prototype link to interact with, they were asked some questions at the end of the research, measuring ease of use, how long it took them to complete each task on their transaction flow, how many tasks they finished, if they dropped off at some point, the number of clicks, etc. 

Much later in the testing phase, employees were also brought on board for the beta version, which helped garner more feedback.

In addition to the user flow research, the impact on our transactions was also paramount. Looking at all the transaction channels, including volume POS coming from USSD, Mobile, and Web, the team looked at what percentage of our transactions would be affected by the introduction of MFA. Say 50 million were coming through mobile; how many transactions were less than 500k on mobile? For example, if the percentage is 80%, the MFA will impact 20% of monthly mobile transactions.

On the technical side of things

The team that worked on this and is still working on the other aspects of this system is a combination of Product, Engineering and Design. It included the R&D team led by Ope, the SVP of Channels, the payment team, the mobile team, the front-end team and the fraud team, which Awal leads. Of course, with the support of Solomon Amadi, the SVP in charge. 

On the software architecture level, Dumebi, our principal engineer, was a technical lead for implementing the MFA feature, supporting the engineers, providing input on technical decisions, and helping with deployments and production. 

Leaning on Microservices Architecture, which is the framework we use heavily at Moniepoint, the application is broken down into smaller, loosely-coupled services that communicate with each other over well-defined APIs. When the customer is trying to do a transaction, the system calls our service to screen the transaction. During screening, our service returns a response to the caller to ascertain whether or not MFA is required for the transaction. If MFA is required for the transaction, then this device will show the customer the web pages to enter their MFA token and validate the token.

On the front end, Gabriel’s team focused on achieving multi-factor authentication within the application itself. They implemented this using the SDK approach. An SDK is like a software development kit, a library where you can plug in any application that would help you complete the two processes needed for the MFA on the front end: enrollment and verification.

Enrollment happens in the settings, meaning a user has to enrol. With the SDK embedded within the application, users can call that enrollment function, and it shows up like a UI, and that UI is where users go through all the face verification and TOTP registration steps. 

The SDK also has a function to verify TOTP during the payment flow. If a payment is above a certain threshold or the transaction doesn’t follow preset patterns, the user must show the verification for further authentication.

Using a lightweight version of React, the front end team built this and built it independently of any application. It follows the widget architecture or the in-widget architecture, which allows you to embed any micro app within any application. 

On the backend, because the MFA would be used in a transactional environment, in between transactions, the RPM (requests per minute) for the transactions really mattered a lot, as we wanted very minimal latency. So, the backend engineering team needed to choose something that would be as lightweight as possible, and that's why they decided to go with the Rust programming language; the other alternative was Golang.

In Rust, there is no garbage to collect because the moment something would have become garbage, it gets freed immediately. Plus, they have a smaller memory footprint, which eventually saves costs as well. The most important thing is the speed of their actions. They have a better processing rate or processing speed because they are lightweight; therefore, they are tailor-made to do particular things like what we were targeting.

To achieve minimal latency, we used a cache layer, which is slightly different from the normal cache we use. Normally, in our applications, we store the data in the cache and then store that data permanently in a database or a permanent storage device. The data stored in the cache is static data that doesn't change over time frequently. We store that kind of data in the cache, so the application does not have to go to the database for all types of data requirements. This means we would have to manage the database and the cache ourselves and communicate with the cache - managing all of those things on an application server. 

However, for this MFA & our Fraud Prevention tool as a whole, we adopted a framework that would do this for us out of the box called Tik. It's a framework specific for Rust, a TikV framework, and the TDIS framework used for caching.

Today, all transactions on Moniepoint go through fraud checks because of the system we’ve built and how much thought we put into usability. At Moniepoint, we prioritise the convenience and security of our customer’s transactions; this is not just because of regulations but deeply rooted in our continuous commitment to building what the customers desire. 

Now that you’ve read about how we built our MFA feature, wouldn’t you want to join us in building the next great product for Africans everywhere? Visit our Careers Page to get started