Payment appropriation is a configuration science
A single loan product can order its payment appropriation more than 10 million ways. The order decides what a payment retires, and it lands on the product's RoA.
A short-tenor unsecured product and a secured product with a ten-year runway do not want the same thing from a partial payment. One needs its charges recognised early. The other needs the balance to fall so the asset stays clean.
Both wants are expressed in the same place: the order of appropriation, the sequence in which a payment is applied across the eight amounts a borrower can owe. When a payment covers everything owed, the order does not matter. When it does not, which is the normal case on a delinquent account, it decides which dues get settled and which stay outstanding.
Every lender can quote its rate and its NPA norms from memory. Far fewer can state that order without opening a configuration screen, because it is set once during implementation and then shared by every product on the book.
- One product can order its appropriation more than 10 million ways. Eight components rank 40,320 ways, and each carries its own traversal rule, multiplying the space by 256.
- The same payment produces different books. In Lokta’s simulator, one ₹37,440 payment on an identical account retired ₹27,740 of principal under the borrower-friendly order, ₹20,594 under the arrears-first default, ₹19,662 under interest-first, and ₹5,855 under income-first.
- The order moves RoA from both directions at once. It decides what income is recognised now, and how fast the earning asset runs off. Two products with different return profiles have no reason to share one.
- Traversal is as consequential as the ranking. The one order that sweeps components across installments retires less than a quarter of what the best order does.
- Grouping does not split a payment proportionally. It forces its members to settle installment first, which quietly stops a sweeping component from sweeping.
How many appropriation orders are there really?
Count the choices in that one screen. Eight components can be ranked 40,320 ways. Each also carries its own traversal rule, settle this installment before the next or sweep this component across every installment, which multiplies the space by 256. That is 10,321,920 configuration combinations in this eight-bucket model, before anyone links two components into a group. They are not 10 million distinct legal policies or economic outcomes, but the defensible ones among them still diverge.
Most are nonsense on a real book. The difference between the sensible ones still lands on the borrower and on the P&L.
That is what makes it a science rather than a preference. The space is enumerable, the mechanics are deterministic, and any candidate order can be computed against any account state before it is adopted. The order is the hypothesis, the simulation is the experiment, and principal retired is the measurement. In our experience it is rarely run before go-live.
What does the same payment do under four different orders?
The account is the same in all four runs: ₹5,00,000 at 18% p.a. on a reducing balance over 24 months, EMI ₹24,962, with installments 3 to 10 open, 3 to 5 past due, and ₹2,05,029 scheduled across those eight rows. So is the payment. ₹37,440 arrives, half as much again as the EMI.
Only the appropriation order changes. Every number below comes from Lokta’s simulator on a modelled account rather than a customer file (full method). The numbered badges give the sequence the engine walked, and each cell shows what that step actually took, so the highlighted cells in every panel add up to the ₹37,440. Each panel opens full size in a new tab.
| Scenario | Principal retired | Leading components | Traversal |
|---|---|---|---|
| 1. Arrears-first (product default) | ₹20,594 | Overdue interest, overdue principal, overdue penal, overdue fees | Installment first |
| 2. Interest-first (product label: court default) | ₹19,662 | Overdue interest, interest, overdue penal, overdue fees | Installment first |
| 3. Borrower-friendly | ₹27,740 | Overdue principal, principal, overdue interest, interest | Installment first |
| 4. Income-first | ₹5,855 | Overdue penal, overdue interest, overdue fees, penal | Component first |
All four allocate the full ₹37,440, and all four are representable in the model. That is the problem. The same borrower, paying the same money on the same day, comes away having retired ₹27,740 of principal or ₹5,855, a difference of nearly five times, and nothing on the screen says which.
Why does income-first reach principal last?
Because almost the whole payment is gone before the order gets there. Sweeping overdue penal charges across EMIs 3 to 5 takes ₹2,813. Sweeping overdue interest across the same three takes ₹21,442, which is those installments’ scheduled interest of ₹20,102 plus ₹1,340 of interest accrued on the arrears themselves. Overdue fees take ₹1,180. Current penal charges rank next and take nothing, because only a past-due installment carries one. Then the interest on EMI 6, the installment due now, takes ₹6,150. That is ₹31,585 before overdue principal is reached at rank seven, leaving ₹5,855 to part-pay EMI 3.
Note what the sweep does not touch. Interest on EMIs 7 to 10 is not yet due, so it is not eligible at that rank, and only the catch-all at the end of the policy could reach it. Nothing does here, because the payment is gone. The order sweeps hard across arrears and stops at the boundary of what is currently payable.
The borrower paid 150% of their EMI, and less than one rupee in six of it reached the balance.
Principal outstanding barely moves, so the next installment’s interest is computed on nearly the same number and the account keeps ageing. That is the kind of outcome that turns a paying customer into a disputing one.
Income-first is not wrong for that. A lender may decide where contractually due charges sit in its recovery hierarchy, subject to its agreement, board-approved policy and accounting treatment. Penal charges carry an additional boundary: RBI’s penal-charges directions require them to be reasonable, disclosed in the key facts statement and the loan agreement, and not used as a revenue-enhancement tool. Either way it is a choice about how the book behaves, made at the level of a dropdown.
What do traversal and grouping actually change?
Two controls sit underneath the ranking. Both change the outcome without changing any component’s rank, and neither usually appears in the policy document.
Traversal is set per component. Installment first settles one installment across every component before starting the next, which concentrates a payment on the oldest arrears. Component first sweeps a single component across every open installment before the next begins, which spreads the payment thin and pulls not-yet-due installments ahead of older ones. Scenarios 1 to 3 settle installment first. Scenario 4 is the only one that sweeps, and it retires the least principal of the four. The names run backwards from the intuition, because the engine names them for the loop on the outside, not for the direction your eye travels across the grid.
Grouping links two or more components so they travel as one block, and it does less than the name suggests. It does not split a payment proportionally. Components that already settle installment first are already settling side by side within an installment, so linking them changes nothing about the money. What a group adds is a boundary: the members move together when someone re-prioritises the stack, and the group settles installment first as a unit. That last part has teeth. Put a sweeping component into a group and it stops sweeping.
How does the appropriation order move RoA?
The order reaches return on assets through three channels at once, which is why a policy document alone is hard to reason from.
The first is how much of what a payment collects becomes recognised income. Where a lender recognises penal and bounce charges on realisation, an order that ranks them first pulls that income forward. Interest on a performing account accrues whether or not a particular payment settled it. The order moves recognised income where that income is realisation-based, and cash allocation everywhere else.
The second is the earning asset. On a reducing-balance product, principal outstanding is the base the next installment’s interest is computed on, so an order that retires principal shrinks it and an order that never reaches principal leaves it intact.
The third is ageing. An account whose principal does not move keeps ageing on the same balance, and classification and provisioning follow the ageing, not the income recognised against the account.
So the same lever pushes recognised income one way and asset quality the other. Which side a product should favour is a product question, not a platform question, and there is no reason two products with different return profiles should share an order because they sit on the same loan management system.
Three appropriation gaps worth testing in an LMS
We walked into the first of these ourselves.
The first is that appropriation is modelled as a single ordered list. Rank the components, save, done. With no traversal setting per component, the component-first dimension does not exist and most of those ten million orders are unreachable whatever the operator draws. We hit this while building: the canvas could express a policy that swept one component across every installment, and the strategy shape it compiled to was a fixed list of allocation rules with nowhere to put that instruction. The drawing was legal and the engine could not run it.
The second follows from the first. Where appropriation is one ordered list, that list serves every kind of payment. A scheduled EMI, a lump sum above what is due, an NPA collection, a foreclosure and a recovery against a written-off loan are five different events, and a single ranked list treats them identically. The worse version is a screen offering a per-type rule the core cannot enforce because it cannot tell the transactions apart, which is configuration that looks saved and never fires. We have that limit today on part payments and foreclosures, and the screen says so on the row instead of pretending otherwise.
The third is that there is no way to see the consequence before committing. The order gets chosen in an implementation workshop from a list of names, and the first real evidence arrives months later as a borrower dispute or a provisioning surprise. Nothing about the mechanics requires that.
It follows from a classification. Appropriation was filed as setup long before anyone could test it.
How Lokta handles it
Four things, and none of them is a bigger dropdown.
Nobody starts from a blank stack. Four named orders ship as protected presets, and editing one branches a copy, so the canon stays intact and every change carries a name and a lineage.
The order is authored visually, eight components ranked with their traversal settings and any linked group, and that drawing compiles into an apportionment expression the core executes verbatim. The screen and the stored policy say the same thing, which is what makes it reviewable by someone who was not in the room when it was drawn.
The engine refuses what it cannot reach. An expression that cannot cover every combination of timing and component is rejected, and the compiled policy ends in a catch-all so no due is stranded. A policy that silently cannot settle something is a defect, not a configuration choice.
And nothing has to go live to be tested. Apply a modelled payment against a modelled account state under a candidate order and read what settles before it goes near a live book. Every figure in this post came out of that simulator.
Treat the order as a credit policy
Ten million configurations is a reason to stop treating the output of that screen as setup. The appropriation order is where a product’s return profile turns into arithmetic on a borrower’s balance, and it deserves the same authorship and the same evidence as any other credit policy.
Frequently asked questions
What is payment appropriation in a loan account?
Payment appropriation is the order in which a received payment is applied across the eight amounts a borrower can owe: principal and overdue principal, interest and overdue interest, fees and overdue fees, penal charges and overdue penal charges. When a payment covers everything due, the order does not matter. When it covers only part, which is the normal case on a delinquent account, it decides which dues settle and which stay outstanding. That makes it a credit decision, not a setup detail.
How does the payment appropriation order affect a loan product's RoA?
Through three channels at once. It moves recognised income where that income is realisation-based: penal and bounce charges are commonly recognised when collected, while interest on a performing account accrues whether or not a payment settled it. It decides the earning asset, because principal outstanding is the base the next installment's interest is computed on. And it decides ageing, because an account whose principal does not move keeps ageing on the same balance, which drives classification and provisioning.
What is the difference between component-first and installment-first traversal?
Installment-first settles one installment completely, across every component, before moving to the next. It concentrates a payment on the oldest arrears. Component-first sweeps a single component across every open installment before starting the next component. It spreads a payment thinly and can pull not-yet-due installments ahead of older ones. The two produce different books from the same ranking, and a credit policy document rarely states which is in force.
How is the arrears-first order different from interest-first?
Less than the ranking suggests. Both lead with overdue interest, which on a past-due installment includes that installment's scheduled interest. Because both settle installment first, each clears EMI 3 entirely before moving on, so they diverge only inside EMI 4: arrears-first reaches its overdue principal before its penal charge, interest-first settles the penal charge first. On one ₹37,440 payment that was a ₹932 difference, ₹20,594 against ₹19,662. Ranking only bites where a payment runs out mid-installment.
Can different payment types use different appropriation orders?
They can where the core can tell the payment types apart. A regular repayment, a collection on an account already classified NPA, and a recovery against a written-off loan are distinguishable, so each can carry its own order. A part payment and a foreclosure are harder, because both post as ordinary repayments. The honest handling is for the screen to say which rules can actually fire rather than saving one that never does.
Read next
- Post-approval lending: where loans actually make money. Why the servicing side carries the economics.
- The loan book that learns. Testing policy changes against the book instead of shipping one a quarter.
- The LMS customization trap. How configuration decisions harden into things nobody will touch.
- Loan management on Lokta. Where appropriation order lives: one versioned product contract, not a configuration row somebody edited once.
How this was simulated
The figures come from Lokta’s payment appropriation simulator, run on an assumed account, the same way we test on non-customer data elsewhere: ₹5,00,000 at 18% p.a. on a reducing balance over 24 months, EMI ₹24,962, installments 3 to 10 open with 3 to 5 past due, ₹2,05,029 scheduled across those eight rows. The ageing, a bounce charge on two past-due installments, a penal charge of 2% of the EMI per month pro-rated by days past due, and overdue interest are assumed rather than read from a live charge register. All four orders allocate the identical ₹37,440. No payment is posted and no customer data is involved.
Chandramouli is the co-founder and CEO of Lokta, the agentic loan servicing platform for the live book. He has spent two decades building AI for decisions that change people’s lives, and has served as an independent director on an NBFC board. He is on LinkedIn.
