Loan Origination System for a Leading Local Bank
Modernising the existing system to improve credit turnaround.
I designed the experience of a newly refreshed loan origination system, which consolidates previously disparate credit applidcation journeys into a single webapp.
The platform is used by relationship managers and approvers for large corporations across 13 markets.
My Role
Product Design
Stakeholder Management
Prototyping
Design System
The team
Designers
Software Engineers
Product Owners
Business Analysts
Subject Matter Experts
Timeframe
Oct 2023 - Present
Context
In the first half of 2024, businesses contributed 46% of the bank's profits, with 65% of that amount stemming from loans. Nearly half of these loans were RM-serviced and applied for through the bank’s loan origination system.
As part of a bank-wide initiative to modernize its enterprise systems, the loan origination system emerged as a prime candidate—not only due to its age but, more importantly, because of the significant profits generated by RM-serviced business loans.
Impact
As a UX designer, I was involved in improving the credit journey and designing new features for the system from its secondary research phases through to implementation.
I frequently chaired meetings with credit approvers, risk portfolio management, ESG and relationship managers to gather requirements and seek alignment on design solutions.
Challenges
Complex domain knowledge required
The credit journey contains many inter-dependent workflows and complex details about loans, which was new to me.
I actively worked with team members from other squads to identify cross-module dependencies and ensure design consistency.
Stakeholder management
The system and its associated modules will be used by stakeholders from multiple business units of the bank, each with their own viewpoints and business needs.
To ensure that design solutions were effective and robust for users and the business, I worked closely with product owners (ex relationship managers) to gather and distill key insights from discussions with the various stakeholders.
Design system constraints
We had to work with an inherited design system which contained outdated components and components not suited for a data heavy platform.
To tackle this, the design team conducted a platform audit and worked with the wider team to improve and update components.
User Journey
(Credit Application Process)
01
Plan
I learn about my client’s financing needs
02
Prepare
I put together a Credit Application
03
Review
I discuss my submission with my approvers
04
Approval
I obtain approval
Parts of the credit journey I worked on.
05
Implement
I follow up on tasks to get my line implemented
06
Monitor
I monitor and track my client’s credit conditions
Designs
The modules that I design for focuses on risk scoring. In risk scoring, Relationship Managers (RM) prepare documents that cover the financial health and overall standing of the company. These documents are evaluated together with the details of the loan to determine the risk of disbursing the loan.
Financial Spreading
RMs must first do their due diligence and evaluate the financial health of borrowers, guarantors or shareholders. To do this, figures from financial statements are recorded in the system.
Design Principle
As with most modernisation projects, a common point of friction for users is that they expect previous features to be available. I had to strike a balance between preserving aspects of the existing system while improving upon others. I worked with the PO and RPM to prioritise must haves, and spoke with users to identify and solve existing pain points.
Financial Projections
In addition to manually typing in projected figures, users are also able to apply projection parameters to financial figures to automatically calculate future values.
I collaborated with RPM, synthesized the requirements for the projection parameters, and translated them into on-screen controls. These controls were designed in a side panel to allow users to preview how parameters affected the projected values.
Variance in financial figures
Although financial documents released by borrowers follow a standard format, they can contain unique financial items.
This meant that in addition to standard financial document templates, we had to allow users to add and customise other financial figures.
Variance in evaluation methods
When presenting their case to approvers, RMs present key financial figures as evidence when evaluating the financial health of a company. However, the presented figures are often RM and deal specific.
I designed a feature for RMs to build a customisable table to tackle this. RMs can pull existing figures from any financial statement.
We found out that RMs also present other non-standard financial metrics, most of which consist of a formulas using standard figures in financial statements. I designed a custom formula builder to help RMs calculate and present these figures.
Obligor Grade (OG) Scorecards
In OG scorecards, RMs answer a series of qualitative and quantitative questions to obtain an OG score. These scores are used to quantify the potential risks of disbursing a loan based on the company’s standing. These scores are then evaluated by credit approvers.
Design Principle
Although the user goals for RMs and approvers differ slightly, they edit or consume information in similar ways. RMs typically only make targeted changes to existing questions, while approvers compare existing and proposed scores when evaluating.
To save on development time, the design caters to the goals of both approvers and RMs. I designed the scorecard to closely resemble the final output of an OG scorecard. I used a column based layout to display existing and proposed scores in close proximity, and used tighter margins and padding to make it succinct and glanceable.
Discretionary tweaking
RMs will use their discretion to adjust answers for more favourable scores within reason. Answers for one question may affect the scores of one or more related questions, in addition to the final score.
I designed the scores to be updated on every saved input, kept the final score always in view, and highlighted key scores to make tweaks more discernible.
Repetitive data entry
Answers in subsequent OG scorecards do not change when updating the scorecard for existing borrowers, save a few. However, it is important to highlight these changes when they occur.
Answers from previous scorecards are automatically imported to reduce repetitive data entry. Changes to existing scores or overrides are highlighted.
Facility Grade (OG) Scorecards
In FG scorecards, an FG score is calculated to quantify the credit risk of the loans. RMs enter details about the loan and its associated securities and collaterals. The calculation engine uses these details and other associated parameters to assign an FG score to a loan.
Scoring for borrowers outside of LEAP
The loan origination process for some categories of borrowers such as financial institutions are not handled on LEAP in the initial release. However, as the existing scorecard system is being replaced by a module in LEAP, the scorecard must be designed for LEAP borrowers and off-platform borrowers.
Loans, securities and collateral details are pulled from LEAP borrowers' credit applications. For off-platform borrowers, users are able to key in these details in the scorecard itself.
Credit application-scorecard data integrity
Scorecards for credit applications must inherit loan, security and collateral details. These details are filled in by RMs in the credit application. To ensure FG scorecards serve as accurate documentation for credit applications, information must be synced between credit applications and scorecards.
I designed a feature to import loan, security and collateral details from credit applications into the scorecard. To reduce workflow and technical dependencies, the user has to reimport to pull any updates made within the credit application.
This case study is a work in progress
benlzw94@gmail.com
Designed by Benjamin Lee