Reducing the time to market for an ambitious BNPL provider and transition to independent release cycles

The important role of scoring for fintech services

Checkout is a crucial stage of every customer journey in any business that sells products or services. Despite its seemingly simple nature, the checkout process can make or break a customer's shopping experience and impact the success of a business in various ways.

An ambitious Middle Eastern BNPL Company

Our Client was a fintech buy-now-pay-later (BNPL) Company from the Middle East with over 2 million active users. By offering flexible payments online and in stores, they are able to support over 5,000 global brands and small businesses.

As the Сompany was experiencing active growth and expansion into new markets, they required a new faster way to deploy, configure, and update the system. They simultaneously needed the ability to integrate with new merchants and markets to meet their ambitious business goals.

Speed up the time to market

From a business perspective, the Customer’s initial request and requirement was the ability to accelerate time-to-market processes for new functionality. The high speed of business implies rapid adaptability to market and customer requirements. Consequently, it creates the need for simultaneous testing of a large number of hypotheses. The results must later be converted into new features or transform the existing ones.

Another important task for further development of the Client’s business was the need to enter new markets. This task was the basis for a new hypothesis about the ability to quickly adapt existing processes and the system to the requirements of local legislation and merchants. Most of them had their own requirements and features that were difficult to dock with the main system. In particular, the Customer was interested in entering the Egyptian market, but the country’s passports required a separate verification service and a separate procedure for loading and processing documents. These requirements created the need for a separate guide for system users.

Extract scoring from the monolith

The Client’s system was designed with a monolithic approach, which significantly limited the tasks set by the business. Starting as a small startup with a few people, the Client’s business eventually transformed into a full-fledged company with dozens of different modules and separate development teams. An initial single release cycle for all teams with a convenient approach was eventually transformed into a legacy approach. As a result, both the product and the business suffered, as some parts of the system were developed faster than others.

Under such conditions, deploying, upgrading, configuring, and maintaining the system became a lengthy process. Any changes to the system had to be built into the live queue for release. To do this, the Client had to update the entire system, sometimes several times a day. As a result, this had a direct impact on the speed of revisions and the cost of development, increasing both significantly.

For the Company to continue to develop effectively, it needed to move away from the outdated monolithic approach and replace it with a microservice architecture.

How one microservice changes the whole system

Discovery phase and audit as the most effective start

As a first step, Sibedge began working with the Customer on a discovery phase and an audit. Our team analyzed the system and the Customer's team for bottlenecks.

The audit showed that the Customer’s team was chosen commensurate with the level of the system and its functionality. The bottleneck for the business was the monolithic approach on which the Customer’s system was designed. This approach did not allow for the timely implementation of new functionality and testing of an increasing number of hypotheses.

The analysis revealed that the greatest number of hypothesis checks were required on the scoring side. And in this module, it is necessary to release and adapt features twice as often as in other parts of the system.

The Customer’s system needed to be unbundled into separate microservices. Scoring was chosen as the first allocated module since it was most critical for the Client’s business and the BNPL solution in particular.

Architectural refactoring: separating scoring into a separate microservice

Architectural refactoring allowed us to organize the checkout and scoring services.

Scoring was organized as a set of rules – the system highlighted risk factors and assigned values. Singling out scoring into a separate microservice allowed us to solve the problem of interaction between scoring and the monolith. A clear separation of processes was carried out. For example, scoring took over all the processes related to passport validation.

As a result, the scoring module was responsible for two checks:
– the service's own internal rules.
– an additional request to the external scoring service: Axiomatics.
Scoring and Axiomatics jointly took on the function of validating the user's trustworthiness.

Another important feature was how different parts of the system accessed the same data at different stages of the checkout process. And each time, the checkout initiated a new scoring check, creating an additional load between services and, as a result, increasing the load.

As a result of the work on separating the scoring module from the monolith, the single release process was divided between services. Now the scoring team could independently produce the required number of releases per month, turning the module development team into a fully autonomous one. Thus, it directly influenced the total time to market for new customer services and increased the number and speed of hypotheses checked by the business.

Entry to the Egyptian market demonstrated easy integration for new merchants

To test the success of the new architecture and the new development approach, the Company expanded their service to a new location: Egypt. Local rules for processing and verifying personal data were taken into account, along with the individual internal policies of the new country.

The hypothesis of whether the Customer team can successfully enter new markets and adapt the system to the local peculiarities was successfully tested and proven.

Thanks to the new architectural refactoring, the scoring module could accumulate different validation procedures for both the user and their trustworthiness. Thus, we successfully facilitated the procedure of connecting new merchants while accounting for the requirements of new markets and regulators.

Our team successfully split the monolith of the Customer’s single system and isolated the scoring module into a separate microservice. This feat allowed us to achieve autonomous work of development teams, increase the speed of deployment, and reduce the number of incidents in production from 10+ to 3-5 afterwards. Thus, the number of features delivered to the vendor in a period of time in the context of all available teams has increased.

Businesses could test hypotheses faster and reduced the time to market of the new functionality from 14 days to 3 days after the change.

This solution of extracting a separate module into a microservice can be applied to other business types and is not specific to the fintech industry only.