Developing a broker service that connects online stores and partner banks to provide fast credit arrangements for non-residents of RF right on the store’s website.
Working with customer’s developers* (CFT), we have created the Credit Broker 2.0 service, which connects directly to partner banks and presents credit terms. The terms depend on the input data, such as passport details and average monthly income.
The service speeds up credit arrangement thanks to the direct connection to the bank and a unified request-response model.
Business logic. The service prompts the user to fill in a questionnaire with personal data, including passport details and average monthly income. Then it sends the details directly to the integrated banks and in just a few minutes returns credit offers.
Partner integration. The service is connected to partner banks on one end and to online stores on the other. An application submitted in the online store is sent to every partner bank.
Credit Broker 2.0 provides a generalized API, which works for any online store. All adaptations to the banks are performed internally, inside the service.
Each bank has an adapter developed for it that can be considered a separate service, since every bank has a unique API. The result is a unified system that encapsulates all specifics of each model of interaction between the banks and the online stores.
Thus, the service acts as an aggregating broker. This is convenient for online stores, since they do not have to integrate with banks and adapt to their unique request-response models.
Interaction between the service and customer’s ecosystem. In addition to online stores and partners banks, the service has other customer’s products connected to it: services for text messaging and scoring. The architecture built during the development process effectively uses these services to perform tasks in Credit Broker 2.0.
The team that worked on the project was not well-versed in high security requirements of the financial sector. Every architecture change had to be approved by our customer’s financial and information security team. They had many requirements to the code; every data transfer protocol had to be secure. Algorithm requirements were just as strict. We were prepared for this, but some team members did not have experience with financial tech projects.
We had to do our research on effectively working with Kafka, which acted as a data bus for the project to prevent any security breaches and instabilities in the service.
Even the tiniest leak of internal information would be unacceptable, so we extended the range of specific checks for incoming requests. Many checks at the scoring stage had to be performed through CFT’s internal microservices. This took us a long time.
The Credit Broker 2.0 service is deployed into production. It receives personal data from the user, connects to a partner bank, and presents a complete credit arrangement. This speeds up credit arrangements for non-residents of RF. The service can be used by RF residents as well. On average, it issues 5 arrangements a day to non-residents and 80 arrangements a day to residents.
An online store and two banks have already been connected to Credit Broker 2.0 in test mode.
Compliance with strict security requirements. Protected data transfer protocols, incoming request validation.