A Centralized System for a Leading Consumer Lending Bank
Making Loan Processing Efficient by Transforming Manual Processes into a Centralized Automated System for a Consumer Lending Bank
decrease in turnaround time per contract(1 hour to 30 mins)
manual hours for 800 users saved every single day
daily active users across 5+ departments
releases within two years
Leading Consumer Lending Bank
Our client is a leading customer credit provider in the United States, committed to assisting customers in achieving their objectives through excellent customer service and flexible lending alternatives.
For over 70 years, our client has been providing exceptional service to its customers. As a high-performing company with a large credit clientele, they want to optimize their processes further.
WHAT WE DID
When the client first approached us, the goal was to transition one of the departments from a manual process to a digitized automated system.
After researching multiple department workflows, we realized the vast potential involved in automation and cross-functional usability of the product.
Through an in-depth discovery of the existing processes and problems, prioritizing automation, and designing the best possible solution, we were able to achieve the following for our client:
A keen study of the existing product and our client’s requirements, a careful selection of suitable solutions, and close collaboration with the client helped us achieve the goal of delivering a highly scalable solution in a short time. Some of our key wins include:
Having a centralized system where agents can access all the loan contracts.
Frequently deploying new updates and maintaining an average release of two weeks for the last two years.
Automating all manual checks, saving up to 4000 manual hours for 800 users.
Transforming more than five departments, thanks to the success of transforming one department.
Improving the entire banking process, leading to immense client satisfaction.
Centralized system to access loan contracts
Addressing privacy concerns
Automating static, repeated checks
The road ahead
1. PROBLEM DISCOVERY
Our client has over 3.6 million unique loan contracts across various departments. Manually handling these contracts led to significant bottlenecks as the number of contracts escalated.
The client also used a legacy CRM hosted on on-prem servers. This involved substantial maintenance costs for servers and a separate IT department.
For every contract, important information was stored in plain text as memos. The cloud seemed the correct choice as the number of agents and contracts increased.
As mentioned, manual errors inevitably started creeping in as agents worked on a contract and performed multiple actions, such as numerous clicks and data entries. Agents had to rework the same contract leading to a high turnaround time for a single contract.
On close examination, this issue persisted across all the departments.
2. CENTRALIZED SYSTEM TO ACCESS LOAN CONTRACTS
Before we partnered, our client had no centralized access system. Instead, the agents had to do multiple logins to different branch systems to find the correct contract and then log in to other workflow systems to work on them.
The first problem we wanted to tackle was designing and developing a centralized system to access and work on all the contracts. This led to us developing the Customer Account Technology System or CATS.
Our approach solved the multiple sign-in problems; the agents would only have to sign in once to access everything from everywhere.
3. ADDRESSING PRIVACY CONCERNS
As our client is a leading banking institution, they deal with customer-sensitive information such as PII (Personal Identification Information).
Since our clients primarily relied on on-prem servers, there were many concerns regarding the security of this data on the cloud.
Our solution was to design a cloud-based system that doesn’t store any PII data. To address security concerns regarding the PII data, we decided not to keep sensitive data in our cloud-based application but instead on the existing on-prem server.
4. AUTOMATING STATIC, REPEATED CHECKS
To solve the issue of high turnaround time due to rework and manual errors, we decided full-scaled automation was the best way to go.
Previously, agents performed manual checks to determine if the bank should proceed with a particular loan processing.
Bringing in automation saved agents considerable manual effort because the application now ran the static repeated checks on every contract to determine its state and subsequent workflow appropriately.
All agents had to do now was perform the unavoidable mandatory checks using the application.
5. INTUITIVE UI
While building out the UI of the application, there were internal debates within the client organization about introducing an entirely new system and disrupting the existing workflow.
Since the agents are used to fixed flows and interfaces, we quickly realized the importance of having a smooth user experience.
We found that 100% of our users use Windows. Therefore, we followed the latest design trends and patterns popularized by Microsoft to reduce the cognitive complexity and the learning curve for the new system. Hence, the users could experience the application like any other Windows app instead of a new alien system.
6. LIGHTWEIGHT SYSTEM
Since this was a new product for our client, we designed it to be a lightweight system. As new requirements led to new features, we adopted an agile process where the deployment of the updated application can happen with the click of a button.
By being truly agile about what we do and sticking to the frequent deployments principle, our release frequency has been two weeks on average for the last two years.
7. THE ROAD AHEAD
One of the primary reasons for the product’s success was the small self-sufficient agile teams working in tandem with each other with their customized scrum models. This resulted in high productivity and very rapid deployments.
In the future, we are aiming to productize the application. Although the current product solves many client problems by saving time and effort, it is still a service product. The developers can only implement new features or updates.
We are changing this by introducing small changes so users can change and update the product.
*All the metrics in this case study are accurate as of the time of publishing.