Hi everyone! I'm Petrovich, a Java Development Team Lead at softwarecats.dev. We provide development services and we are also creating our own products.
Today, I want to share a story about how we decided to develop our own solution for customer credit score evaluation (so called "risk management system" or RMS) for financial companies and to bring it to the market.
Let me give you some background first. The top and middle management of our company is represented by people whose experience either comes directly from the financial technologies field or is connected to it. Evaluation of customers credit score is vital for any financial company which lends money at interest, whether it’s a bank, a microfinance organization, or a non-bank credit organization. The goal of such evaluation is simple—to give money to good customers and not to give money to the bad ones. And what exactly is a good or a bad customer? A good customer is a customer who returns loaned money in time, in full, and avoiding defaults (delays in payment schedule). Accordingly, a bad customer is a customer who either wasn’t going to pay from the very beginning or decided not to do so when already had the loaned money. The credit score evaluation system (let's call it RMS for short) should solve a single problem—predicting the probability of accurate payments from a customer. The more accurate the forecast is, the more valuable the RMS becomes and the more people want to use it.
How can we accurately evaluate a customer who has just come to a company if all we know about them is the personal data they left on the site while applying for a loan? There are a number of services for this but the main source of data is the customer’s credit history. Only the credit history can provide the most extensive and reliable information on customer payment history.
Fortunately, we have already had extensive experience in integration with loan offices—which are the main and only providers of customer credit history data—and other services which provide ad hoc evaluations (from mobile operator billing analytics to social media analytics). Many of our team members have worked in microfinance companies, so we understood both the weaknesses of this business and the processes which could be successfully automated. That’s why our first idea was to develop and implement a prototype for one of our clients, a microfinance company.
While we were designing a prototype, we realized that it shouldn’t be limited to just microfinance companies. We can create a platform which can be used by any company, not just by financial ones. Our solution can be used in any area which requires checking customers compliance with a list of criteria.
Today, I want to share a story about how we decided to develop our own solution for customer credit score evaluation (so called "risk management system" or RMS) for financial companies and to bring it to the market.
Let me give you some background first. The top and middle management of our company is represented by people whose experience either comes directly from the financial technologies field or is connected to it. Evaluation of customers credit score is vital for any financial company which lends money at interest, whether it’s a bank, a microfinance organization, or a non-bank credit organization. The goal of such evaluation is simple—to give money to good customers and not to give money to the bad ones. And what exactly is a good or a bad customer? A good customer is a customer who returns loaned money in time, in full, and avoiding defaults (delays in payment schedule). Accordingly, a bad customer is a customer who either wasn’t going to pay from the very beginning or decided not to do so when already had the loaned money. The credit score evaluation system (let's call it RMS for short) should solve a single problem—predicting the probability of accurate payments from a customer. The more accurate the forecast is, the more valuable the RMS becomes and the more people want to use it.
How can we accurately evaluate a customer who has just come to a company if all we know about them is the personal data they left on the site while applying for a loan? There are a number of services for this but the main source of data is the customer’s credit history. Only the credit history can provide the most extensive and reliable information on customer payment history.
Fortunately, we have already had extensive experience in integration with loan offices—which are the main and only providers of customer credit history data—and other services which provide ad hoc evaluations (from mobile operator billing analytics to social media analytics). Many of our team members have worked in microfinance companies, so we understood both the weaknesses of this business and the processes which could be successfully automated. That’s why our first idea was to develop and implement a prototype for one of our clients, a microfinance company.
While we were designing a prototype, we realized that it shouldn’t be limited to just microfinance companies. We can create a platform which can be used by any company, not just by financial ones. Our solution can be used in any area which requires checking customers compliance with a list of criteria.
After 2 months of designing and prototyping, we managed to gather requirements for the future system. So, our system should be:
- Fast. It should work as fast as possible. The speed of decision-making can affect all other parts of the system and, ultimately, the company image.
- In addition to being fast, the system should also be flexible. From our experience we know that even the seemingly slightest changes can happen to take weeks to implement. You should try to foresee such scenarios right from the design stage.
- The system should allow us to run A/B tests on users and collect statistics. For example, you want to check how a new set of rules works, but you don't want the system to make a decision right away. A good RMS system should allow you to do it.
- The system should be highly portable, including the ability to use it in other countries. The task of porting a solution to another country arises quite often these days and it usually comes down to this: how long will it take to implement the solution in another country and how much will it cost? In addition to engineers who work on the infrastructure, you also need someone from the client side to come up with a new set of rules and to check them on new data.
- The system should have no vendor lock-ins. That means the system's design and implementation shouldn’t be vendor-dependent. Ideally, all technologies should be open source.
- Our RMS must provide analytics tools in web interface, so that a specialist could understand what is happening with the process and where the problem is just by looking at the charts. It should also be able to generate reports on past periods, so that you could have all the necessary analytics at any time.
- And last but not least, our future RMS should provide flexible configuration of integration requests caching, including those for loan offices.
- The system shouldn’t be expensive. Industrial solutions can cost tens of millions rubles per license plus hundreds of thousands per month for support. That is too much for our product because we won’t be able to cover the largest segment of the market at these costs.
- All industrial systems have a very significant flaw—they either can’t adapt to customer at all or the customization costs a lot of money. We checked a number of estimates for system improvements and they varied from 600 thousand to 1.5 million.
- RMS must be designed for heavy data flows. We tested capacity of some systems and it was really poor ranging from 2–5 requests per minute to 2 requests per second. That means these systems cannot evaluate more than two customers at the same time. If the evaluation takes 20 seconds or more, it's not scalable.
Having gathered the requirements, we started to plan the future architecture. On the one hand, we wanted to make the process as flexible as possible; on the other hand, we didn't want to drown in numerous settings of the future system. We decided to choose the stack our developers usually use: microservices in Java and Spring Boot, PostgreSQL for long-term storage, Elasticsearch for analytics and fast search requests, BPMN for process orchestration, and REST or gRPC for communication between modules. As a result, the following chart was born:
We decided to make only the core monolithic and to implement all other parts as separate modules which can be connected at the source code level. This solution allows us to avoid transfer of unnecessary integrations and deploy only the required modules when transferring the system from country to country. Access to the RMS should be handled through a single API gateway. The same gateway should be used for authentication, authorization, role management, etc. The BPMN engine should provide flexible configuration of the decision-making process via web interface. The project standardization in terms of process variables and mapping from a common data model to a data source model requires more time at the beginning but in the long run reduces the time needed for new integrations and for replacing specialists working on the project.
The biggest problem and potential bottleneck in such systems is the internal data model. The need to constantly change the model and propagate changes to the entire system can cause a lot of problems. Changes in the internal model can often conflict with each other; developing several integrations at the same time can also result in conflicts. We decided to use json as a base and make the model as flexible as possible—to avoid hardcoding specific data sources into request and response bodies by using a generic type object with an unlimited set of fields instead. The object can be conveniently configured in a web interface to store everything necessary to receive requests and responses. All configurations will be stored in the database, have versions, and could be restored and modified at any time upon a customer's request via the web interface. Our design motto was—if something can be configured by user, the user should be given means to do so.
Along with the system, we decided to supply our own authorization server based on Keycloak. We think that the use of reliable Oauth2 and numerous integrations with third-party systems (Active Directory), both existing and potentially possible, should set our solution apart from solutions of other vendors. After all, it is much easier to find a specialist for an open source technology than for a proprietary one.
We reviewed the technologies we chose and our own experience in decision-making systems development and decided to come into the market. And now I want to share some numbers, so that you could understand how long, difficult, and expensive it is to implement a system of this scale. The implementation requires:
3 specialists (1 back-end developer, 1 front-end developer, 1 DevOps engineer). Processing core and request module for customer data from the National Bureau of Credit Histories—1.5 months for each module. Passport verification module—0.5 month. Factor calculation module—1 month. Web interface for the entire system—3 months. And one more month for the infrastructure. And three months for testing. In total, 5.5–6 months of work for 3–4 specialists and you get a working RMS as a result.
In terms of money, that would round up to about 6 millions rubles.
Half a year and 6 million rubles in exchange for being free from vendors and getting a flexible and reliable credit score evaluation system which can be expanded directly in interface. We think it is a really good investment of time and money for any company.
The biggest problem and potential bottleneck in such systems is the internal data model. The need to constantly change the model and propagate changes to the entire system can cause a lot of problems. Changes in the internal model can often conflict with each other; developing several integrations at the same time can also result in conflicts. We decided to use json as a base and make the model as flexible as possible—to avoid hardcoding specific data sources into request and response bodies by using a generic type object with an unlimited set of fields instead. The object can be conveniently configured in a web interface to store everything necessary to receive requests and responses. All configurations will be stored in the database, have versions, and could be restored and modified at any time upon a customer's request via the web interface. Our design motto was—if something can be configured by user, the user should be given means to do so.
Along with the system, we decided to supply our own authorization server based on Keycloak. We think that the use of reliable Oauth2 and numerous integrations with third-party systems (Active Directory), both existing and potentially possible, should set our solution apart from solutions of other vendors. After all, it is much easier to find a specialist for an open source technology than for a proprietary one.
We reviewed the technologies we chose and our own experience in decision-making systems development and decided to come into the market. And now I want to share some numbers, so that you could understand how long, difficult, and expensive it is to implement a system of this scale. The implementation requires:
3 specialists (1 back-end developer, 1 front-end developer, 1 DevOps engineer). Processing core and request module for customer data from the National Bureau of Credit Histories—1.5 months for each module. Passport verification module—0.5 month. Factor calculation module—1 month. Web interface for the entire system—3 months. And one more month for the infrastructure. And three months for testing. In total, 5.5–6 months of work for 3–4 specialists and you get a working RMS as a result.
In terms of money, that would round up to about 6 millions rubles.
Half a year and 6 million rubles in exchange for being free from vendors and getting a flexible and reliable credit score evaluation system which can be expanded directly in interface. We think it is a really good investment of time and money for any company.