Lender Integration with Rupeek

In this article we talk about various design challenges faced when integrating with different kinds of lenders on to Rupeek’s lender marketplace and share our approach to address the challenges we encountered.

Background

Rupeek is a leading Fintech company in asset backed lending with the current focus on the Gold Loans domain. Rupeek is a marketplace for Gold Loan products where Banks and NBFCs can provide loans to end customers using Rupeek’s platform. Since a loan has to be disbursed from an external lender, there are multiple workflows where the lender is involved.

1. Customer verification
2. Fund transfer to customer’s Bank account
3. Customer identifier creation in Lender System
4. Loan account creation
5. Collateral creation
6. Loan account settlement in lender system

Challenges

Rupeek as a Fintech company needed to automate all these flows to reduce the overall loan processing time, reduce manual intervention and and provide a best in class customer experience. Lenders have their own Core Banking System(CBS) APIs which can be used to perform these operations and automate the process but integration with these APIs have a certain set of challenges.

1. Many lenders are not comfortable calling their CBS APIs from an external cloud due to security concerns. e.g. one of the banks doesn’t allow Write APIs like customer creation, account opening, fund transfer API calls from Rupeek cloud.
2. Lenders don’t allow an external company to trigger these API calls using the data which is not approved by the lender’s internal team resulting in the need of a business rule engine e.g. a bank doesn’t allow automated fund transfer without the bank’s Central team approval.
3. Lenders are also concerned about data safety, and hence, prefer to manage all their databases within the bank’s network.
4. Some lenders are also concerned with the data payload security in API calls and have asked to add an encryption layer on top of their API calls.
5. There are also challenges in setting up specific network safety measurements for comfort of the lenders like connection whitelisting, site to site VPN tunnelling etc.

Scenarios

While working on integrating with different lenders, we came across different scenarios for different lenders. For some lenders, the Loan Origination system(LOS) already exists and it is capable enough to perform all the operations but for others there is not LOS capacity and a direct connection to the Loan management system or CBS is needed. In Rupeek, we had already built a system called Lender Portal for Lenders to approve the loans at branch level and update customer identifier and loan account details in the system. Considering these scenarios and lender requirements, we had to take different approaches.

1. Lenders who don’t have their own LOS and were not comfortable using Rupeek’s LOS (as Rupeek’s LOS is hosted in cloud), we built a new service with a web interface to provide LOS functionality and run the automated workflow.
2. Lenders who don’t have their own LOS but were comfortable using Rupeek’s lender Portal Interface for LOS operations, we enhanced the Lender Portal with incremental lender specific functionalities like maker/checker operation, lender’s SSO integration and automated workflow execution.
3. Lenders who already have LOS interface and Rupeek need not care about maker/checker, workflow execution etc. Our system just sends the data in the required encrypted form.

Our learning has been that the second model gives us a better control and extensibility in on-boarding multiple lenders in future while minimising challenges in terms of deployment and network security.

How did we solve this

One of the most important steps we have taken towards the solution of this problem is to encapsulate all the flows involving lenders and create a separate microservice called lender Public Service. Major responsibilities for this service are mentioned below.

1. Decouple lender related complexity from Rupeek’s internal services and enable common interfaces for Rupeek’s internal services to call lender related workflows.
2. Route each request from Rupeek internal services to each lender specific route e.g. customer precheck call from Rupeek Core Service will be routed to one of the lenders on our marketplace based on the lender metadata sent from internal services.
3. Log all the requests responses for lenders’ API calls from lender Public service.
4. Maintain logs for events happening in the service deployed in the lender’s network to make sure that Rupeek has full awareness of operations happening at the lender’s side.
5. Maintain frameworks for handling retries, encryption/decryption, workflow engine for task etc in the system.

As a part of this Integration, we have also created a new Application which is called lender Private service. Major responsibilities for this service are mentioned below.

1. This service was built with the purpose of deployment in the lender’s private network and give lenders comfort for the security related concerns raised by them and also make sure that integration with Rupeek can be seamlessly done with this service by integrating with Lender Public system.
2. This service also has a web interface enabled for Bank users. Bank central sanction team can use this to approve loan requests.
3. Maker checker flow for branch approval is also provided in this dashboard. After successful approval from both Maker and Checker users of the Bank, Digital Credit workflow can be triggered in which customer deduplication check, Customer ID creation and account opening tasks are done.
4. In this service, we have used the concept of public interface and private interface. Public interface is enabled to send relevant data from Rupeek lender Public Service.
5. Private interface is enabled only for lender’s internal approval APIs. This cannot be accessed from outside the lender’s internal network. This was achieved through API level IP range whitelisting.
6. This service has also integrated with lender’s SSO to enable their users login and role management.

Deployment Strategy

We built two services: Lender Public and Lender Private. For both the services, deployment strategy was different. Lender Public has to be deployed in Rupeek cloud whereas Lender Private has to be deployed in lender’s Private Network.

1. For lender Public deployment, it has to be deployed in Rupeek AWS cloud. We have deployed multiple server instances for this service. They are running behind Load Balancer. Conventional approach should be using AWS Application Load Balancer but this doesn’t provide any public IP which is required for IP whitelisting at the lender side. Then we tried Network Load Balancer where Elastic IP can be attached but it can’t be run on HTTPS on a port different than 443. So we chose to set up HAProxy as Load balancer and SSL termination was also set up on this.
2. For lender Private deployment, support was required from the lender side. We needed to use the same infrastructure used by lenders. They provided us servers for running the application. Database setup was also planned according to the lender’s current Database service. Network setup was done to whitelist all the open connections. In the lender’s system also, HAProxy setup was done for Load Balancing.