We stopped copying dummy rows and built a living, 24/7 digital twin of a company as our QA, just to break our software. Here's why.

We run a digital twin of a fictional NBFC. We call it BACO Finance, and it runs 24/7 as our live QA: real time, every day.

It behaves like a live loan book: real borrowers, real repayment schedules, real collections events, real messiness. None of it is real. All of it is realistic. BACO is a South India retail lender with six products, named officers, and a book that moves every day, run by a small fleet of agents while we sleep. We treat it like a production system, because for the purpose of building good software, it is one.

Here is the claim underneath it, from twenty years around data and lending: test data is the most underrated tool in an engineering org. And in lending, the bug you are chasing is usually the data, not the feature.

Why is test data the most underrated tool in engineering?

In twenty years around data and lending, I have watched teams pour care into every part of the stack except the one that decides whether any of it works: the data they test on.

It is almost always an afterthought. A sample. A representative slice. A stale export from months ago, seeded with dummy records and copied, unchanged, from the lower environment to the upper one. The same tired rows turn up in unit tests, in staging, in the demo. Everyone knows the data is not quite right. Nobody owns making it right.

Then it costs you. A ticket comes in: this feature is broken. An engineer picks it up and spends half a day chasing it. The logic is fine. The query is fine. The feature was never broken. The test data was. I have watched that exact afternoon play out more times than I can count, on teams that were excellent at everything except the data they pointed their excellence at.

What is BACO, and why treat it like a real bank?

So we stopped patching sample data and built the thing it was pretending to be. BACO is a digital twin of an NBFC: a fictional lender, built to behave exactly like a real one, with no real customer data in it. Not a bigger sample: a living book. Its customers, loans, repayments, collections, and service requests carry the same structure, the same relationships, and the same textures as a real lender’s, down to the way a single borrower ties back to a branch, an officer, a co-lending partner, and a repayment history.

The mental shift is the whole idea. We do not treat BACO as test data. We treat it as a production system that happens to be fictional. It has a canon, and the canon is law: one borrower is the same borrower in every screen, every spec, and every demo. A book that contradicts itself feels fake, and fake is exactly what we are trying to escape.

BACO is a servicing book, the post-approval half of lending where the money is actually made or lost, and it is built to behave like a real RBI-regulated NBFC. It runs asset classification and expected-loss provisioning in parallel. It tracks borrower-level NPA across co-lenders. It honours the fair-practice rule that collection contact stops after 7 in the evening. It runs a thirty-day ombudsman response clock. It reports to the credit bureaus on the regulator’s cycle, honours cooling-off refunds, and reaches for SARFAESI only where a loan is genuinely secured. Born compliant is not a footnote in a BACO demo. It is part of why the data feels real enough to trust.

How did we design a believable synthetic loan book?

None of this works if the book is not believable, so we did not start with a database. We started with a story, written down. Before a single row existed, we wrote detailed specifications in plain markdown: who BACO lends to, what it lends, where it operates, and who runs it. The seed data is generated from that canon, not the other way around.

The specification is specific on purpose. BACO is a five-year-old, technology-first, centralised-credit retail NBFC, RBI-regulated, run lean on about 105 people. It lends across six products and no others, in rupees, across five South India states, on a hub-and-spoke network of roughly 300 branch locations. It services only: origination is a later chapter, deliberately out of scope. And its clock is pinned to a single day, so every days-past-due and ageing calculation has one fixed reference point.

It also has a named cast. A CFO who runs the daily cleared-cash board, a head of collections who owns escalations, an ops maker-checker who signs off postings and waivers, each with a role and a span of control, the way a real NBFC does. When an engineer writes a use case, the actor is one of these people, by name.

The one we come back to most is a borrower named Ramesh. Personal-loan customer, based in Hubballi, deliberately parked in mid-delinquency: about a month past due, in the early bucket, with a handful of repayments and a few collection events already on his record. He is not a tidy row. He is the borrower who exercises servicing, collections, hardship, and a co-lending split all at once. When a feature can handle Ramesh, it can handle a lot. When it cannot, we find out on our screens, not a lender’s.

What does BACO’s book actually look like?

Realism is not a vibe. It is a book with a real shape, and every part of BACO’s is specified, then generated from the seed. Over its life it has taken on 500 customers and 500 loans. 450 are live today across the six products. The other 50 have already left the book the way real loans do: 27 closed on schedule, 14 foreclosed early, 4 settled, 5 written off. A book with no closures, no foreclosures, and no write-offs is a quiet giveaway that the data was invented.

The mix is deliberately uneven, because real books are.

Look at the last column. The wealth-backed books barely blink: securities and mutual-fund loans sit near zero 90-plus, because there is collateral with a margin call behind them. The unsecured and education books run into the low teens, because that is what unsecured retail credit does. If every product carried the same delinquency, that would be the tell. Across the whole book, 36% of live accounts carry some overdue, and the tail is deliberately deep: a servicing product has to be seen working the hard cases, not only the clean ones.

It is provisioned the way a regulated lender’s book is, in stages: 340 accounts performing, 67 under-performing, 43 impaired. Ind-AS expected loss and the regulator’s IRACP run in parallel, and the higher of the two governs the number that reaches the P&L. None of that is set dressing. It is the difference between a table of loans and a book a CFO would recognise.

One thing to hold in mind: this is the book at its seed. The fleet moves it every day, so any single day’s snapshot, like the executive briefing further down, is a later and busier state of the same canon.

How does co-lending work on BACO?

Just over half the live book is co-lent: 246 of the 450 live loans are shared with a funding partner, across one bank and two NBFCs. Co-lending is not a detail you can fake convincingly, so we built the whole mechanism into the canon. The partner names below are masked. The mechanics are not.

Every co-lent rupee carries its own split lineage. Cash moves through a joint escrow with no inter-mingling, settled on a T+1 file. Delinquency is tracked at the borrower level, so if a loan tags as non-performing it classifies that way for both lenders at once, in line with the January 2026 directions. Losses are shared pari-passu. Fees and penal charges stay 100% with BACO, because BACO does the collection work. And each partner sees only its own slice, in a single-tenant Partner Portal reading one swept-cash truth. Get any of it wrong and a partner catches it in the first reconciliation. Getting it right in a test book is most of why the test book is worth building.

How does BACO hang together?

Under all of it is one connected structure we call the spine, the same data model a real loan management system runs on. Every screen, every aggregate, and every agent reads and writes through it, which is what makes the one-canon rule enforceable rather than aspirational.

Everything joins. A loan hangs off a customer, a branch, and an officer. Repayments, collections, collateral, invoices, and risk decisions all hang off the loan. The audit log covers who did what. Identifiers follow one grammar, so a customer is CUST00001 on every screen and a loan is LN000001 on every screen, never a stray format in one corner of the app. And the headline numbers, the ones that go out at 8 in the morning, are computed from this spine, not typed in by hand. When one of them looks wrong, it can be traced back to the row that produced it.

How do we keep the twin alive?

A book that does not move is just a snapshot with ambitions. The moment you freeze it, it starts drifting from anything a real lender would recognise. So we keep BACO alive the way a real lender’s book stays alive: by letting the lifecycle run.

A small fleet of agents does the work. They are not the product. They are a testing tool: a set of simulators pointed at BACO’s own data, each one mimicking a piece of how borrowers and officers behave day to day. They run through the day and leave the book a little further along each time, so the data is never the same twice, and never stale.

Picture an agent fleet that behaves like a lender’s borrowers and back office, running quietly in the background, keeping the book current. That is what turns a data set into a twin. The book moves the more it runs, and we test on whatever it has become that morning.

What does testing on BACO actually catch?

Every feature we build meets BACO before it meets anyone. During development, and again once it is deployed, we watch it run against a book we know cold. Knowing the book is the point. When you know BACO’s shape by heart, a wrong number has nowhere to hide.

A recent example. We built a feature to send executives a running summary of the loan book on WhatsApp at set times through the day, from the 8 o’clock open to the day-close wrap. The WhatsApp piece worked well: right format, right delivery, on time. The briefing that landed one evening looked clean at a glance.

Then it did not survive a second look. Collected month-to-date came in at ₹8.27 Cr against a reported demand of ₹7.81 Cr, so collection efficiency printed 105.9%. On its own, over 100% can be real: you can recover old overdues on top of the current month’s dues. Not here. The same briefing showed 105.9% efficiency alongside zero recovered from overdue and not one account moving a delinquency bucket, on a book we knew was not that quiet. The numbers did not tie out, because with the data source briefly unreachable the feature had fetched dummy data instead. We caught it in seconds, not because we ran a special test, but because we knew what BACO’s numbers should have said. On a generic sample data set, those figures would have looked as plausible as anything else, and the bug would have shipped to real executives on a real morning.

There is a second thing worth naming, and it is not the bug. The team reacted to BACO’s numbers as if they were real money.

Nobody rallies around a folder of sample rows. They rally around a book that behaves like theirs, and that instinct is exactly what catches the wrong number on a real morning.

That is the return on treating your test book as a living system. Not that your features break less, though they do. It is that when they break, they break in front of you, on data you understand, instead of in front of a lender on data you do not.

Why does production-shaped data matter even more now?

This used to be good hygiene. It is becoming the whole game.

Three things are changing at once. Agents are starting to work the book, taking real actions in servicing and collections, not just rendering screens. Systems are going headless: the interface a human used to eyeball is thinning out, replaced by APIs and agents talking to each other, so there is no dashboard where a wrong number catches your eye. And AI compliance is becoming a mandatory, regulated requirement, not a nice-to-have, which means you have to be able to show what a system did and why, before it ever touches a real borrower.

Put those together and the data you build and evaluate against stops being a convenience. It becomes the thing that decides whether a feature survives contact with production. You cannot eyeball a headless system. You cannot let an agent act on the book unless you have watched it act, on realistic data, first. And you cannot prove an AI system is safe on data that could never occur.

There is a subtler point under this, and it is the one I would underline. The success of an AI feature in production is largely decided by the context it carried through its development. What did it see when it was designed, built, and evaluated? If the answer is toy data at every step, the feature learns a toy world and then meets the real one. Holding a single, realistic context across the whole agent development lifecycle, from version 0.1 to production, is what closes that gap.

That is why BACO is not just a testing database. You will find it across the lifecycle: in our demos, in our internal requirements, which are mostly markdown specifications, and in our evaluation artifacts. Same lender, same borrowers, same canon, from the first spec to the last eval. The context does not change shape as the feature moves toward production, so the feature does not get a nasty surprise when it arrives.

So why don’t more engineering teams do this?

If this is such a good idea, why is it rare? I do not think it is laziness. The obstacles are real, and most teams hit at least one of them.

1. The developer does not have the full business context. You cannot model a lending book you do not understand. Most engineers were never handed the domain, so they build the data they can imagine, which is a thin version of the real thing.
2. Siloed teams see only their slice. When a team owns one service and no more, nobody holds the whole picture of the feature or the system architecture. A twin needs someone who can see the book end to end, and silos are built to prevent exactly that.
3. Production data is off limits, for good reason. Real borrower data is wrapped in privacy rules you should not want to break. So teams either test on a masked snapshot they still cannot spread around freely, or on invented data that bears no resemblance to the real thing.
4. There is no cheap tool for this. You can buy plenty of tools that generate rows. There is nothing off the shelf that stands up a living, regulated, believable digital twin of a business at a prosumer price. We built ours by hand. Honestly, this looks like a real opening for the agentic-testing tools: give teams a twin, not just a data generator.

The takeaway

Here is where I have landed, for now. Most engineering teams treat test data as an afterthought, and then pay for it in lost afternoons, shipped bugs, and features that work in the demo and fall over in production. The data was never the boring part. It was the part that decided everything.

Our answer is a digital twin we treat like a living NBFC. BACO is fictional. Its problems are not. And because we meet those problems first, on a book we know by heart, our lenders will not have to. My 2 cents, from two decades in this: if you want software that survives contact with a real book, start by testing it on something that behaves like one.

Frequently asked questions

Read next:

• Our team is 42. Six of us are human. The agent fleet that builds Lokta, sibling to the fleet that keeps BACO alive.
• The loan book that learns. The same idea, a book that improves as it runs, turned on a lender’s own portfolio.
• Post-approval lending: where loans make money. Why BACO is a servicing book, and why that half is the one worth getting right.

Sources:

• RBI Guidelines on Recovery Agents (Fair Practices Code: conduct and contact hours)
• RBI Integrated Ombudsman Scheme, 2021 (30-day response window)

Chandramouli is co-founder and CEO of Lokta, the AI-native lending stack for post-approval servicing. 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, where BACO gets the occasional mention.