Settling a bad loan used to take three days and four different systems.
I designed the One-Time Settlement workflow inside Collection Central that got this down to under a day, in one place. It now handles ₹15–20 Cr of settlements a month.
When a customer can't repay, a settlement is usually the best outcome left.
A One-Time Settlement (OTS) is how Piramal Finance closes out a loan that isn't going to be repaid in full. A field collector negotiates a reduced amount with the customer, that amount goes up a chain of approvers, and once it's approved the customer pays. I was the only designer on this, so I owned the whole thing: how a request gets raised, how it gets approved, and how the payment gets tracked.
Where requests really went
I started by following actual requests through the organisation, which looked very different from the documented process.
Rules the system could own
The approval matrix and the monthly recalculations were all being worked out by hand. Most of it could be logic the system just runs.
One flow, start to finish
A single guided workflow from raising the request to collecting the money, with every action logged along the way.
Four tools, and nobody had the full picture.
Here's how a settlement worked before. An Area Relationship Manager (ARM) would email in the request. Approvals happened in a separate Online Approval System (OAS). Payment information sat in the Loan Management System (LMS). And someone kept an Excel sheet to track which requests were still open. If you wanted to know where a request was stuck, whether this customer had defaulted on a settlement before, or where the audit paperwork was, you asked around.
Speed was the obvious complaint, but the real issue was that nobody could see the process, so nobody really owned it.
There was no room for a visual redesign, and that wasn't the point anyway.
Things I couldn't change
Collection Central already had a design system, and OAS and LMS weren't going anywhere. Whatever I designed had to sit on top of them.
Audit was in the room
Internal audit and NBFC rules meant specific documents, records, and approval evidence had to exist at every step. None of that was negotiable.
The whole settlement, start to finish, inside Collection Central.
An OTS now starts, gets approved, and gets paid without leaving Collection Central. The system works out who needs to approve it, checks whether the customer has settled before, generates the payment links, and keeps a record of everything for audit.
Four screens carry most of the work.
Raising a request, one step at a time
The ARM works through the request in steps: loan details, OTS history, settlement details, tranches. Each step shows only what that step needs, and nothing from the next one.
Seeing where an approval is
Every request shows who has it right now and who's next. If an approver sends it back, the comments and the rework happen on the same screen.
A payment link for each tranche
Once a settlement is approved, the system generates a payment link per tranche, each sized to what the customer can actually pay in one transaction.
The full history, on the record
Every request keeps its full record, and if the customer has dishonoured a settlement before, approvers see that without having to go looking.
I started by following real requests, not the process document.
Before I opened Figma, I spent time with the people doing this every day. Five or six ARMs who raise the requests, a few of the Geographical and Branch Recovery Managers who approve them, and the collections business team in a series of working sessions. Then, with product, engineering, and internal audit, we went through every approval, document, and compliance requirement and wrote down what actually had to move online.
5–6 ARMs
They raise the requests. Most are handling several customer cases at once, and often filling in the form while still on the phone with the customer.
GRMs & BRMs
They approve. I wanted to know what they actually look at before saying yes, and what they wished they could see.
Business + Audit
What the module had to do, what audit needed from it, and where requests were quietly dying today.
Three things I didn't know going in.
A request could go stale halfway through approval.
The amount a customer owes is recalculated on the first of every month. So a request raised on the 28th could be based on the wrong numbers by the 1st, and nothing stopped it from continuing through approvals. We decided the system should expire those requests automatically. The ARM raises a fresh one with the current numbers and a new agreement from the customer. Slightly annoying for the ARM, much better than approving the wrong amount.
Approved settlements were still falling through at payment.
Some settlements got all the way through approval and then didn't get paid. The reason was mundane: the amount was over the standard UPI transaction limit, so customers were trying to split it into multiple payments themselves, and some just gave up. That's what pulled payments into scope. The system now generates a payment link per tranche, each under the limit, so the customer can pay in one go.
Approvers couldn't tell if the customer had done this before.
A customer could accept a settlement, not pay, and come back a few months later asking for another one. The approver had no easy way of knowing that. The system now checks history automatically and shows any dishonoured settlement right on the approval screen, before anyone decides.
Most of the design work was in the rules, not the screens.
Type in the amount, and the approvers sort themselves out.
Every OTS is approved according to a Waiver Authority Matrix. Depending on how much is being waived and how much is outstanding, the final approver could be anyone along this chain:
Before, the ARM had to work out the right approvers themselves, enter each one into OAS by hand, and then chase them on email. Get the matrix wrong and the request came back. Now, as soon as the OTS amount goes in, the system calculates the waiver percentage, picks the final approver, and routes the request through everyone who needs to recommend it along the way. The ARM doesn't have to look anything up.
My first version put everything on one screen. That was a mistake.
I assumed more information would help, so the first prototype showed the customer's entire context at once. Then I watched ARMs try to use it. They're doing several of these a day, often with the customer on the line, and a dense screen made them slower, not faster. I threw that version out and rebuilt initiation as a stepped flow, where each step only shows what you need to complete it.
The happy path was the easy part.
A lot of real requests don't go straight through, so these cases were designed up front rather than patched in later.
What happens when an approver says no, or not yet?
Any approver can send the request back with a comment. The ARM fixes it in the same request, and the whole back-and-forth stays on the record.
What if documents are missing?
The required documents are checked when the request is raised. It can't go to the first approver until they're attached, which means audit never has to chase them later.
What if the customer pays in parts?
A settlement can be split into tranches. Each one gets its own payment link, its own status, and its own entry in the record.
I spent more time understanding how a settlement actually gets approved than I spent drawing screens for it.
I didn't wait for the PRD.
I started working with both PMs during discovery, before there was a spec. Rough workflow prototypes in FigJam (with a few quick AI-assisted passes to get past the blank page, then properly refined in Figma) became the thing we argued over in product discussions, and a lot of that went straight into the PRD. Once we were building, I went through edge cases with the seven engineers, checked interactions as they landed, and did design QA before UAT so what shipped matched what we'd agreed.
Requests move in a day, and nobody is chasing them over email anymore.
- →Under 24 hours average processing time, down from 2–3 days.
- →One workflow, instead of email, Excel, OAS, and LMS stitched together by hand.
- →₹15–20 Cr a month in settlements now go through a single process that audit can actually trace.
- →Documents on every request, so audit stops being a scramble.
- →Approvers see prior dishonoured settlements before they approve, not after.
What I learned
Fixing one team's problem doesn't fix the process.
Collections is now digital from request to payment. But once the customer pays, Operations still reconciles that payment manually. If I were continuing this, that's what I'd do next: a payment lands in LMS and the settlement closes itself in Collection Central, with no spreadsheet in between.
The interface was the smaller half of the job.
I went in thinking about screens and came out having spent most of my time on approval rules, month-end recalculations, and UPI limits. That's where the friction was. The screens were mostly about getting out of the way once the rules made sense, and giving different teams one place they could all trust.