Poka-yoke in lending: an audit trail is not a control
Toyota drew a line between a mistake and a defect. Lending software mostly ignores it. Here is what the other kind of system looks like, one layer at a time.
Poka-yoke is Toyota’s term for mistake-proofing: design the step so the error cannot become a defect. Loan management systems are rich in detective controls, which report a wrong posting after the ledger has taken it, and thin on preventive ones, which stop it going in. The difference is architectural, and it decides how much autonomy a lender can safely hand to software.
Month-end reconciliation is not a control. It is a report about defects the ledger has already accepted, written by people who had no way to refuse them at the time.
The fault sits in the tooling ops teams were handed rather than in the people running it, and that is the reason I keep coming back to a Japanese word with nothing to do with finance.
In 1961, at a plant assembling electrical switches, workers kept forgetting to put a small spring under one of the buttons. The usual answers had all been tried: retrain, remind, add a checker at the end of the line. An industrial engineer named Shigeo Shingo did something different. He put a small tray next to the bench and had the worker place exactly two springs in it before starting the switch. If a spring was still in the tray when the switch was closed, the worker knew immediately, and fixed it in seconds. The mistake still happened. The defect stopped happening.
Shingo called these devices baka-yoke, fool-proofing, until 1963, when a worker at another plant refused to use one because the name insulted her. He renamed it poka-yoke, mistake-proofing, and the rename is the whole philosophy in one move: the fault is in the design of the step, not the character of the person performing it.
- A mistake and a defect are different things. Errors are inevitable. A defect is an error that reached the record, and that part is a design choice.
- Most lending controls are detective. Audit trails, exception reports and month-end reconciliation all describe a posting the ledger has already accepted.
- The regulator has already made this argument. RBI’s on-site examination found three interest-charging practices, directed corrective action including system level changes, and told lenders to refund the excess interest.
- Prevention is a property of each layer. The screen, the API, the deployment, the migration, the metric definition and the agent each get their own refusal, or the layer below inherits the mess.
- Agents raise the stakes rather than change them. Software that acts at machine speed needs the check to run before the action, because after the action is a different order of magnitude of clean-up.
01 · Mistake and defect: what did Toyota actually solve?
Shingo’s insight, the one English-language guides file under error-proofing, was narrow and it was load-bearing. He argued that errors will not turn into defects if feedback and correction happen at the point of the error. Everything else in the method follows from that sentence.
Lending has the same structure and almost none of the same reflexes. A collections officer selects the wrong charge code. An implementation consultant configures an appropriation order that strands a due. A migration script carries over a schedule that the new engine reads differently. Each of those is a mistake, and every one is forgivable. What decides the cost is whether the system took the instruction.
Take the three practices the RBI named in its circular of 29 April 2024, which applied on issue rather than from a later compliance date. Interest charged from the date of sanction rather than the date the money actually moved. Interest for a full month when the loan was outstanding for part of it. Instalments collected in advance while the full principal kept accruing. Those are not exotic failures. They are ordinary configuration decisions that ran for a long time inside systems that were audited, reconciled and reported on throughout. The audit trail recorded every one of those postings faithfully. It just had no opinion about them.
The instruction the regulator gave is the part worth reading twice. It told lenders to review their practices and take corrective action “including system level changes, as may be necessary”, and to refund the excess. The regulator asked for changes to the thing that accepted the posting, above training or a tighter checklist.
02 · Three inspections: which one is your month-end reconciliation?
Shingo sorted quality control into three kinds of inspection, and the taxonomy transfers to lending almost without translation.
| Inspection type | What it looks like in a lending stack | State of the ledger when it fires |
|---|---|---|
| Judgment | Month-end reconciliation, internal audit, the RBI inspection, the borrower complaint. | Defect booked, often across many accounts, refund run being sized. |
| Informative | Exception reports, daily break lists, dashboards that flag outliers, four-eyes review after posting. | Defect booked, found faster, reversal entry still required. |
| Source | The screen that will not submit. The API that rejects the payload. The build that fails. The engine that refuses the policy. | Nothing booked. The error never became a defect. |
Judgment inspection is the one Shingo spent his career arguing against, because sorting good output from bad at the end of the line is the most expensive place to find anything. Informative inspection is better, and it is where most lending platforms have concentrated their investment, because a dashboard demonstrates well and ships in a sprint. Source inspection is the one that requires the platform to have been designed for it, which is why it is rare.
Your auditors already have vocabulary for this. They call the first two detective controls and the third preventive, and the standard guidance is to weight a control environment toward prevention, on the plain economics that designing a problem out costs less than remediating it. The quality world puts a number on the same idea with the 1:10:100 rule, credited to Labovitz and Chang in 1992: roughly one unit to prevent, ten to detect, a hundred once it reaches the customer. Treat it as a rule of thumb rather than a measurement. The ordering is the part that has held up.
Every vendor demo shows you the audit trail. Almost none of them shows you the refusal. That test applies to us as much as to anyone we compete with.
03 · The UI: can a screen refuse a posting the policy forbids?
The first place a defect enters a loan book is usually a form in the loan management system.
Most lending screens are built as data capture with validation bolted on. Required fields, a regex on the PAN (India’s tax ID), a date picker. The screen collects, the backend decides, and the operator finds out they were wrong from a red toast message after the fact, or from a colleague, or from a report. That is informative inspection wearing a nice font.
Field validation catches typos. It does not catch a disbursal dated before the funds moved, an appropriation order that cannot settle every combination of dues, or a waiver above the operator’s authority. Those are properties of the whole action, so the check has to sit on the submit, and the submit has to be able to say no.
Four-eyes review is the oldest poka-yoke in banking and the easiest to hollow out. Approve after the entry has hit the ledger and it is a reversal workflow with a nicer name. In our maker-checker the sensitive mutation waits in a pending state and the record does not change until the checker acts.
There is a design cost to this and I would rather name it than hide it. A system that refuses things is, in week one, more annoying than a system that accepts everything and complains later. Operators feel it. The trade is that the annoyance is bounded and visible, while the alternative surfaces as a borrower dispute nine months on, when nobody remembers the configuration workshop.
The unglamorous mechanics matter here too. When the screen cannot proceed, it has to say what is wrong in the operator’s language and what would make it right, otherwise the refusal becomes a support ticket instead of a correction. A poka-yoke that stops the line without explaining itself is just an outage.
04 · The API: what stops the same instruction being applied twice?
An API is a much better place for a poka-yoke than a screen, because an API can make a bad instruction inexpressible rather than merely rejected.
The lending industry already trusts this idea in a form it rarely names. A card number carries a Luhn check digit, so a mistyped digit fails arithmetic before it reaches a payment network. An IBAN carries mod-97 check digits that catch essentially every single-character slip and almost every transposition. Nobody calls these controls. They are pure poka-yoke: a cheap structural property that makes a common human error fail loudly and immediately.
The same instruction applied twice leaves the book in the same state as applying it once, so a retrying client cannot double-charge, double-disburse or double-book. This is not a nicety once software is the caller: retry is the default behaviour of every network client ever written.
Money as a decimal type with a declared scale, never a float. States as a closed set with named transitions, never a free-text status column. A transition nobody defined is one the caller cannot request, which removes an entire category of reconciliation work rather than reporting on it.
A caller names the contract version it was built against, and a change that would break it fails at the boundary instead of arriving as a subtly different number in someone’s month-end. The integration that breaks loudly on day one is the cheap one.
We sized the platform this way because of who the caller is now. Our working estimate is that agentic operations generate roughly 5-10× more backend calls per account than human ones, a design assumption rather than a measured industry figure: an agent asks more questions per decision and never stops to eat lunch. At that volume an API whose correctness depends on the caller behaving well has no contract behind it, only hope.
05 · Deployment: can a change reach production without its rollback?
The layer nobody demos is the one where the most expensive defects are actually prevented.
Our modules have hard compile-time boundaries. If one domain reaches into another’s persistence layer, the build refuses. Nobody has to catch it in review, and nobody can approve it under deadline pressure. Every module carries its own migration changelog, and schema changes go through it rather than around it, which means a database change that arrives without a reviewable, ordered, reversible definition cannot be applied at all, risky or otherwise.
Tenants are separated at the schema level in Postgres rather than by a filter in application code. That is a deliberate poka-yoke against the worst defect a multi-tenant lending platform can produce, which is one lender seeing another’s book. A WHERE tenant_id = ? that a developer can forget to write is a control that depends on memory. A separate schema is a control that does not.
A constraint that fails the build costs an engineer an hour. The same defect found at month-end costs a refund run and a conversation with the board.
Chandramouli C SCo-founder & CEO, LoktaEngineers push back on this, and the pushback is honest: constraints slow you down. They do, in the moment. What they buy is that a whole class of defect stops being possible for every engineer who joins afterwards, including the ones who were not in the room when the rule was agreed. Written policy decays. A failing build does not.
06 · Data migration: what does a spring left in the tray look like at cutover?
This is the one I have watched go wrong most often, in a previous life and this one.
A lending migration is the single highest-consequence data movement a lender ever performs, and the industry’s standard control for it is a reconciliation report reviewed by tired people at two in the morning on a Sunday. The defects it produces are quiet. A schedule that carries over with the wrong day-count convention does not fail. It produces a slightly wrong EMI, the equated monthly instalment, on every future due date. An accrual that transfers as a balance rather than a formula does not error. It quietly stops accruing. Nobody finds these at cutover. They surface as a borrower dispute, or a provisioning surprise, or an inspection finding.
- Recompute, do not copy. The new engine derives the schedule, the outstanding and the accrual from the loan’s own terms, and the migrated figure has to match what it derives. A number that only agrees with itself has proved nothing.
- Halt on the first break. An account that does not reconcile stops the run. Logging it and continuing is how a hundred silent breaks reach a live book with a green tick next to them.
- Nothing left in the tray. Every source account lands in exactly one of matched, quarantined, or explicitly waived by a named person. There is no fourth bucket, and no unattributed variance.
We are building a migration agent on exactly this shape, and what it does is unglamorous: read the source book, recompute every loan against the new engine, and produce a reconciled position where each account is matched or quarantined with a reason a human can act on. The agent does the reading and the reconciling, which is the part that does not scale with people. Refusing to proceed on an unexplained break is the rule the agent runs inside, never a judgment call it gets to make.
07 · Insights: how does a number drift when nobody edits it?
Reporting has a mistake-proofing problem that looks like nothing until you go looking.
Ask four teams in a lender what the delinquency rate was last month and you will often get four numbers. Not because anyone is careless, but because collections counts from the due date, finance counts from the accounting calendar, the board pack was pulled a week earlier, and one of the four quietly excludes restructured accounts. Nobody edited anything. The definition drifted because it lived in four places.
The poka-yoke here is boring and it is structural: one definition, computed once, in the platform, versioned. Every surface that shows the number reads that definition rather than reimplementing it, and when the definition changes, it changes with a version and a date so that a figure in an old board pack still means what it meant when it was printed. A metric that cannot be recomputed the way it was originally computed is not evidence. It is a screenshot.
This is also the layer where the self-improving book either works or quietly lies. Strategy testing is only worth something if the measurement that decides which strategy won is stable. Let the definition drift and the loop learns from noise, at speed, with confidence.
08 · Workflow agents: why does an agent need this more than a person does?
Everything above is worth doing in loan servicing without a single agent in the picture. The reason we did it first is that we knew what we were going to put on top.
An agent differs from a faster person in ways that matter for control design. A person who misreads a collections policy makes a few wrong calls before someone notices at the daily huddle. An agent applies the same misreading across the book before the huddle happens. A person who gets a timeout gives up and raises a ticket. An agent retries, which is how one intended action becomes two postings.
- Bounded actions. An agent can pull a specific, approved set of levers, not a general authority over the book.
- Proposal, not posting. The agent proposes. It does not write to the ledger. The deterministic core evaluates the instruction against policy and either performs it or refuses it.
- Maker-checker on anything that crosses policy. The gate is the same one a human maker faces, for the same reason.
- Idempotency on every write path. A retry cannot double-post, whether the caller is an agent, an integration or a person double-clicking.
- Every attempt on the record. Actions, refusals and rollbacks, with the actor and the evidence, which is what makes audit-by-design mean something at agent volume.
- Arithmetic stays in the core. Schedules, interest and appropriation are computed, never generated.
This is where the post’s opening claim resolves rather than contradicts itself. The record still matters, and at agent volume it matters more, because it is the only way a lender can answer for what software did. But the record proves what happened. The design decides what can happen. “Autonomy you can audit” needs both halves, and the industry keeps selling the first as though it were the second.
09 · Vendor questions: what should a lender ask about prevention?
Five questions. They work on us, and they work on anyone we compete with, which is rather the point.
- Show me a refusal, not a report. Ask for a live demo of the system declining an instruction that violates policy, and watch whether the refusal happens before or after the posting.
- What happens when the same API call arrives twice? If the answer involves the caller sending a unique reference and the platform “usually” handling it, that is a convention, not a control.
- Which of your controls are preventive and which are detective? A vendor who has never sorted their own controls that way has not thought about this, and the answer takes about ten seconds to evaluate.
- What stops a bad migration reaching the live book? Ask specifically what halts the run, not what the reconciliation report contains.
- Who owns the definition of the numbers? One computed definition with a version, or each surface computing its own.
Ask these in an RFP and you learn more about a platform than any feature matrix will tell you. Most of the answers arrive as an apology, and the apology is the finding.
The takeaway: design decides what can happen
You have three honest options for the errors your book produces, and only one of them is new.
The trade-off on Path B, stated plainly: a system that refuses bad input will refuse some good input in the first weeks, while your policy is being expressed properly in it, and that friction lands on the people doing the work. It is a real cost and it is front-loaded. What you get for it is that a category of defect stops being possible rather than becoming someone’s monthly job.
The proof I would put weight on is the rails rather than a customer number. This team built Apache Fineract, the open-source lending core a large part of the industry runs on, and then spent years watching what an architecture permits turn into what an operator eventually does.1 Poka-yoke is what you build after you have seen the same defect arrive through the same gap in enough books to stop blaming whoever happened to be standing in front of it.
Shingo’s tray cost almost nothing. That was never the hard part. The hard part is deciding that the defect belongs to the system rather than the operator, and then designing as though you meant it.
- ↑ Apache Fineract is an Apache Software Foundation project and a UN-recognised Digital Public Good. Any reach attributed to it is the aggregate footprint of the Mifos and Fineract ecosystem, not work Lokta performed for those institutions. Lokta is not affiliated with or endorsed by the ASF.
Frequently asked questions
What does poka-yoke mean, and how does it apply to lending software?
Poka-yoke is Japanese for mistake-proofing. Shigeo Shingo formalised it inside the Toyota Production System in the 1960s, on the principle that errors are inevitable but defects are not, because a defect is only an error that got through. In lending software it means the platform checks the conditions for a correct posting before the posting runs, rather than reporting the wrong one afterwards. A screen that cannot submit a disbursal date earlier than the funds transfer is a poka-yoke. A month-end report listing the accounts where it happened is not.
Is an audit trail a preventive control or a detective control?
Detective. An audit trail records what happened and proves it later, which is why regulators require one and why every serious lending platform keeps one. It does not decide what is allowed to happen. The distinction is standard in internal-control practice, where preventive controls stop an error occurring and detective controls surface it afterwards, and auditors weight programmes toward prevention because remediation costs more than design. A lending platform needs both. The failure is treating the trail as though it were the control.
How do you mistake-proof a loan data migration?
By refusing the cutover rather than reporting on it. A migration is mistake-proofed when every loan carries a balance, a schedule and an accrual that the new engine recomputes to the same figure as the source, and the run halts on the first account that does not reconcile instead of logging it and continuing. Shingo's original device was a tray holding exactly two springs, so a spring still in the tray told the worker the switch in front of them was incomplete, while it was still in their hands. A migration needs the same property: something left over must stop the line, because a silent break surfaces months later as a borrower dispute.
Why do AI agents in loan servicing need mistake-proofing more than people do?
Because an agent operates at machine speed against controls designed for human speed. A person who misreads a policy makes a handful of wrong calls before someone notices at the daily huddle. An agent applies the same misreading across the book before the huddle happens, and it retries on failure, which is how one instruction becomes two postings. The answer is bounded actions, idempotent writes so a retry cannot double-post, maker-checker on anything that crosses policy, and a deterministic core that refuses an instruction the policy does not permit.
Read next
- Why your LMS ledger should never be model-guessed. The arithmetic layer this post keeps deferring to, and why it is computed rather than generated.
- Payment appropriation is a configuration science. One screen, more than ten million orderings, and what happens when the engine cannot refuse an unreachable one.
- We built a living digital twin of an NBFC to break our own software. How we find the defects before a lender’s book does.
Sources
- Fair Practices Code for Lenders, charging of interest (RBI/2024-25/30, 29 April 2024)
- Poka-yoke: origin, the baka-yoke rename, and the three device types
- Poka-yoke chronology: the 1961 switch-assembly device and the 1963 baka-yoke rename at Arakawa Body
- Shingo’s three inspection types: judgment, informative, and source inspection
- Preventive versus detective controls in an internal control environment
- The 1:10:100 rule, its 1992 attribution, and a critical review of the evidence
- Luhn check digits and the errors they are designed to catch
Chandramouli is the co-founder and CEO of Lokta, the agentic loan servicing platform. 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 collects mistake-proofing devices the way other people collect stamps, and posts about them on LinkedIn.
