Loan Origination System for Gold Loan Product
4 mins read
Context
As an expansion of Aumnee products suite, we were tasked with Building a Loan Origination System (LOS) to banks for generating Leads, process a loan to disburse a loan.
I lead this project from end-to-end as sole product designer - which includes collaborating with stakeholders, defining problem, creation of wireframes, prototype.
Collaborators
PMs, Head of Product, Business Team, Client (Bank)
Duration
2 months
What is "Gold Loan LOS"?
Aumnee is a technology company solving fintech problems through innovative SaaS solutions, empowering banks to manage the complete lifecycle streamlining the discovery to loan management processes.
Our solutions are currently used by 10+ bank partners handling 4 Lakh Transactions, 1000+Cr AUM so far.
"Gold Loan LOS" is one of the products in our Fintech solution that helps banks manage the loan cycle of their customers.
Getting started
As with any project, I kickstarted this project with initial calls with PMs understanding requirements and accessed all the relevant documents and sources for understanding.
Understanding Product Workflow
The PM created an end-to-end workflow of the product based on the requirements. It gave us clarity on the different roles involved at each stage, highlighted edge cases, and helped me start thinking about how to structure the information architecture. While it felt overwhelming at first, we decided to approach the design one module at a time.
In conversations with the PM, it became clear that the workflow would involve multiple roles, each with distinct needs. To document this, I created a detailed role matrix to map out their responsibilities and expectations.
This helped guide my design decisions and ensured we were aligned on priorities. We used this sheet during design reviews to evaluate whether our solutions met the needs of each role effectively.
NOTE: Given the project's multiple modules, I’ll focus on just a couple to keep the case study clear and concise.
Module 1: Gold Loan application list page
This is the main application list view where users can track loan applications across different stages. The goal was to keep things clean and scannable because the people using this are mostly ops teams who deal with large volumes of data every day. I kept the layout simple with a table view that shows all key details like applicant name, channel, branch, and status in one glance.
Each column gives specific info that’s important for tracking and taking action, and the status tags are color-coded to help users quickly understand what stage something is in or if it needs attention. I also added filtering, sorting, and search to help users narrow things down fast. Tabs at the top help switch between stages smoothly without needing to go to another page.
Overall, the idea was to reduce visual clutter, make it fast to skim through rows, and support high efficiency for daily ops work. It might look very white, but the whitespace actually helps avoid cognitive overload since the data is already heavy.
Scroll right 👀
Module 2: Detailed Data Entry
Detailed Data Entry is the initial stage, where the lead (customer) details along with documents are being collected and verified by the bank to access whether the lead can be considered as application and moved to Next stage for Underwriting.
This stage mostly involves lot of field data entries, verification, document collection.
I was shared the different categories of data and the fields that needs to be collected in a logical order by the PM.
Stepper? Wizard?
Since the stage involves multiple kinds of data entry, I tried exploring wizard form design and stepper because they help break down complex inputs into manageable steps, reducing cognitive load.
Scroll right 👀
Address Fields: Tabs or Inline?
One key decision was how to structure address fields—should they be placed in tabs or displayed sequentially? During client feedback, users pointed out that they rely on CTRL+F for quick navigation.
Hiding addresses inside tabs would disable search functionality, slowing them down. Based on this, we opted to keep address fields stacked inline rather than tabbed.
Hiding Tabs: A Misstep in Visibility
Each Stage has its own stage specific actions that needs to be performed only when the application moves to that stages.
Initially, we considered hiding irrelevant tabs based on the application stage to reduce clutter and keep users focused. However, when we presented this to the client, they were confused: "Why aren’t we seeing actions for other stages? This doesn't give us the full picture."
Rethinking our approach, instead of hiding tabs, we kept all stages visible but disabled tabs that weren’t yet relevant—providing clarity while maintaining structure.
Aligning with User Expectations
During our prototype presentation, we received significant feedback. While users couldn’t always pinpoint what felt off, their comments revealed a preference for a single-page, dense-data layout—a format they were already familiar with.
Our initial approach of using sub-tabs to guide users gradually was meant to reduce cognitive overload, but it turned out to be inconvenient for bank users accustomed to data-dense screens.
Final Solution
We redesigned the information architecture completely, consolidating all data into a single tab while using categorized anchor links for easy navigation. While this resulted in a longer form, it significantly improved user clarity and reduced confusion.
Module 3: Dedupe
As part of loan processing, to ensure that the applicant does not have multiple or fraudulent identities, and to get a clearer picture of their creditworthiness, a process called Dedupe (short for de-duplication) will be done during DDE stage and merged if customer already exists. If fastens the Data entry as system already have the customer details.
For example, A customer might apply for the same loan using different IDs or slightly altered personal information. Dedupe helps identify such attempts to get multiple loans deceptively.
How it works
The system checks incoming customer data against internal records.
Uses match algorithms to flag duplicates.
Matches are categorised (Partial match, Complete match) and shown to the operations or credit team for review.
Bank can choose merge if they found close match, or else create a new ID.
Scroll right 👀
Dedupe is an outcome
Once the third iteration was shared, the team aligned on the design. But I had this lingering feeling that something was off—like there was still room for improvement, even if I couldn’t quite put my finger on it. So I went back to the beginning and started questioning the flow from scratch. That’s when something clicked.
Here were some of the issues I noticed across all iterations:
Why am I seeing all this information after dedupe is done?
Dedupe feels like a temporary step—I’m just merging or creating an ID and moving on.
To me, the ID is the outcome of this action, not the point where I should be overloaded with more details once its done.
Moving to Pop-up
Scroll right 👀
Module 4: Home Page
For the dashboard, I wanted to use it to surface key information tailored to each user based on their role, and evaluate whether it could be helpful and informative. Since there were primarily two distinct personas involved, we needed to design two different home screens depending on the user’s role:
Branch Manager – Needs to view rich analytics related to overall products, loan performance, AUM, disbursal rates, and more.
Branch Ops – Information related for day-to-day operations. They need to see dashboard metrics such as task counts and a recent history of assigned tasks.
Scroll right 👀
Module 5: Designing a Clear & Traceable Audit Log Timeline
Audit Log view I designed to help internal users track every action taken on a lead—from creation to the final submission. In fintech, especially in loan processing, maintaining traceability is super important for compliance and internal reviews, so the goal here was clarity and transparency.
I structured the log as a vertical timeline to show a clear chronological flow. Each action is grouped with its timestamp, the person responsible, and relevant icons to make scanning faster. For example, uploads are shown with an upward arrow and linked to filenames, while edits show old vs. new values with strikethrough and arrows to visually communicate what changed—this helps users catch important updates at a glance.
I also added a “Show less” toggle for long updates to keep the view from feeling overwhelming. The “Filter by” and “Export” options give power users more control, especially when they need to extract logs for audits or reports.
The focus was on building a trustworthy, human-readable timeline that doesn’t feel like a wall of text. It’s meant to make ops teams feel confident about what happened, when, and by whom.
Scroll right 👀
Outcome
The project is currently in QA stage. Post- live we'll be checking these metrics and modify design based on the performance:
Engagement, retention, or task completion rate
Support tickets or complaints made
Adoption rate post-launch
Positive user or stakeholder feedback
Learnings and Highlights
My biggest project yet
This was the largest project I’ve shipped as the only designer. It came with a lot of responsibilities and tight timelines. It was definitely challenging, but with the right feedback at the right time, I was able to navigate through and deliver successfully.
Faster turnaround, higher approval
After incorporating major feedback in the first round with 40% changes, I was able to deliver the second iteration with just 5% changes and a turnaround time of 1 week. This not only sped up the process but also improved stakeholder alignment and approval significantly.
Balancing quality and delivery
I learned how to manage my time better and work more efficiently. There were moments when I couldn’t deliver pixel-perfect designs, but this project taught me that sometimes timely delivery matters more than quality of designs—especially when the stakes are high.