The shipped Multi-Loan Repayment experience – paying several loans in one flow.
Redesigning a core lending experience at KMF in the middle of its transformation from Kazakhstan's largest microfinance organization into a bank.
The shipped Multi-Loan Repayment experience – paying several loans in one flow.
KMF Pay is the bank's existing system for handling all repayment channels – accounts, loans, and deposits – and it already technically supported paying multiple loans at once. But the experience carried a confusing quirk: a loan only registered as repaid on the day the payment was actually made, with an optional scheduled payment layered on top – creating ambiguity for users about when a payment "counted."
This mattered more than it might elsewhere, since KMF's client base – micro and small entrepreneurs, many in rural or agricultural sectors – frequently held multiple active loans at once, making a clear multi-loan repayment experience genuinely valuable rather than a nice-to-have. The project's only real constraint was working within KMF's existing design system.
The brief was to redesign KMF's multi-loan repayment experience end-to-end – from loan selection through payment to confirmation. Benchmarking was the first phase: researching how nine banks across Kazakhstan and the CIS handled multi-loan repayment, evaluating what information each showed per loan and how each handled paying several at once.
That research informed concept development, which was then validated through usability testing – though the testing phase's own success metric (identifying the better-performing prototype by completion time and success rate) was specific to that phase, not the project's overall measure of success. The broader goals were likely tied to reducing support inquiries related to payment confusion, and increasing adoption of the multi-loan repayment flow itself.
Before designing anything, the existing multi-loan repayment experience was benchmarked against nine banks across Kazakhstan (Halyk, Alfabank.kz, Kaspi, BCC, Zhusan) and the CIS region (UralSib, T-Bank, MTS, Sberbank) – mapping exactly what information each bank surfaced per loan, and how each handled paying multiple loans at once.
A detailed feature comparison across eight of those banks produced a clear pattern: loan name appeared universally, while principal debt, payment date, and monthly payment amount each appeared in roughly five out of eight – common enough to be expected, but not universal enough to take for granted. A progress bar and interest rate were far rarer. This became the evidence base for which fields actually belonged in KMF's own loan cell, rather than guessing.
One competitor stood out clearly from the rest, distinguished by three qualities: a single calendar date for all payments, same-day settlement with no scheduled lag, and loan agreements that zeroed out rather than formally closing once paid off – a benchmark worth aiming for, even if not every detail was replicable within KMF's own systems.
How users identify a loan across Kazakhstani apps – Halyk, Alfa, Kaspi, BCC, Jusan – and what each surfaces on the loan card.
The same question across CIS apps – UralSib, T-Bank, MTS, Sber.
Five initial concepts were explored, each varying which fields appeared in the loan cell and how selection worked – informed directly by the benchmarking data on what information actually mattered to users. These were narrowed down to two distinct prototypes, each representing a genuinely different interaction philosophy rather than minor visual variants:
Prototype 1 – List menu. Every loan shown as an individual row with its own checkbox, more information visible on screen at once, and fewer taps required to select and pay.
Prototype 2 – Dropdown menu. A collapsed summary ("2 loans, ₸20,000.98") behind a single dropdown, trading a cleaner, less crowded screen for more taps to get through the same task. Its editable "Payment amount" field worked like a calculator: a partial amount was automatically applied toward whichever loans were nearest their due date first, replicating the logic a person would use manually.
Rather than debating which felt more "modern," both were built as real, testable prototypes – setting up the research phase to settle the question with data instead of opinion.
Five initial concept directions for how a loan appears in the selection list.
The two prototypes taken into usability testing, side by side.
Two prototypes were tested head-to-head with roughly 50 respondents over two days, using two representative tasks: paying only the loan nearest its due date (requiring the user to correctly identify one loan among several), and paying the monthly amount across all loans at once.
Interestingly, the design-satisfaction survey told a slightly different story than the task data: Prototype 2 scored marginally higher on perceived visual quality despite performing worse functionally – a reminder that "feels cleaner" and "is easier to use" aren't always the same thing, and why testing both mattered more than picking a favorite on instinct.
Click-heatmaps from testing: taps, misclicks, and time-on-task on the loan-selection screen.
The same measurement on the alternate layout – attention pulling toward the primary action.
Beyond the interface itself, real usage data shaped how much complexity the design actually needed to support.
A long tail of edge cases extends up to 14 loans held by a small number of outlier clients – giving a clear, evidence-based target: the design needed to handle a handful of loans gracefully as the default case, while not breaking under rare extremes.
| Active loans | Clients |
|---|---|
| 1 | 228,525 |
| 2 | 40,162 |
| 3 | 2,330 |
| 4 | 487 |
| 5–9 | 438 |
| 10–14 | 14 |
That edge-case thinking mattered in practice – a review of production data surfaced an anomalous account with a principal debt over ₸60 million and a monthly payment above ₸2 million, values far outside typical ranges. Catching this kind of outlier early meant the interface needed to handle unusually large numbers without breaking layout or legibility, rather than assuming all values would stay within a comfortable range.
An anomalous account flagged in production data – an outsized principal and monthly payment the UI had to handle without breaking.
Distribution of active clients by loan count – 99.6% hold three or fewer loans.
The tail: clients with the highest number of concurrent active loans.
The finished flow tied together loan selection, payment validation, and the full range of system states – loading, success, and error handling – into a single assembled information architecture, including secondary screens for edge cases like insufficient funds and payment validation failures.
The final assembled flow – loan list, multi-loan selection, validation, payment, and result states.
Multi-Loan Repayment shipped and remains live in the KMF Bank app today. Post-launch, it drove a marked, double-digit reduction in payment-related support tickets, and adoption of the consolidated repayment flow grew steadily among clients with multiple active loans through the first quarter. The shipped design reflects the List menu prototype's stronger performance in testing – validated by real usage data and edge-case analysis before launch, rather than a redesign based on instinct alone.