What the Accounts Don't Account For

The full numbers

On the night of 12 February 2026, Bank of Bhutan switched off its legacy core banking system and switched on its new platform. The migration had been planned for two years. Tata Consultancy Services was the main consultant. The migration window was thirty-six hours; the platform was live across all branches by the morning of 14 February 2026.

One field on one tab in the standing-instructions module did not transfer. The field was labelled “4EOD” — four-letter shorthand for the end-of-day program that swept master-account balances to linked accounts under a customer’s standing instruction. The pre-migration instruction on a particular master account had been: hold a Nu 1,000 minimum balance and sweep the rest, by end-of-day, to a linked account. With the instruction field blank on the new platform, the end-of-day program defaulted to its uninstructed behaviour and transferred approximately Nu 1.5 billion from master account 82 to linked account 13. The accountholder of the linked account — a Thimphu businessman — used Nu 11.2 million via mobile banking (MBoB) despite the source account going into negative balance, plus another approximately Nu 180 million via other payment channels before bank reconciliation detected the discrepancy.

The Royal Monetary Authority response:

• Nu 228 million in penalties imposed on Bank of Bhutan
• Independent third-party assessment with corrective measures required
• Companion supervisory items (ring-fence and parallel matters) brought cumulative supervisory cost to roughly Nu 568 million — about 26% of the bank’s full-year 2025 net profit of Nu 2.19 billion (see paradox #25 for the full supervisory-cost arithmetic)

The Royal Bhutan Police completed its investigation and recommended two charges in the alternative:

• Section 240 of the Penal Code (larceny) — a value-based felony of the second degree at this amount, carrying a sentencing band of 9–15 years
• Section 253 of the Penal Code (larceny of property delivered by mistake) — charged in the alternative as a petty misdemeanour

The case was forwarded to the Office of the Attorney General. The defendant has been in custody awaiting the charge sheet.

Imagine this

It is 3 AM on 13 February 2026 in the Bank of Bhutan data centre. The migration script has run for nine hours. The last batch of legacy account records has been validated against the new core banking platform. The platform sign-off checklist runs to several hundred items. A senior TCS engineer initials the line “SI module migration: complete”. A bank operations manager initials below: “SI module migration: accepted”. The lights stay on. The system reports green across the board. The decision is recorded. By the morning of 14 February, the country’s largest bank is operating on the new platform.

What no one in the room saw — because the checklist did not ask the question — was whether the standing-instruction module had transferred the content of every standing instruction, or merely the presence of each standing-instruction record. The record for account 82 was there. The record had a tab. The tab had a field. The field was labelled 4EOD. The field was blank. The end-of-day program executed against the blank field and transferred Nu 1.5 billion to account 13.

Eleven days later, the businessman holding account 13 noticed the unexpected credit. He moved Nu 11.2 million via mobile banking and Nu 180 million via other channels. Three weeks later, the bank’s reconciliation desk noticed the discrepancy. Three weeks after that, the RBP report was complete. Six weeks after that, the OAG was reviewing the charging memo. The defendant had been in custody since shortly after the initial transactions were identified.

The structural point is not that someone in the bank was negligent. The supervisor enforced. The penalty was proportional. The judicial system absorbed the case. The technical migration team delivered the platform on time. The accountholder of the destination account is in custody facing felony charges. Each layer of the system did its job. None of it protected anyone from a blank field on a tab in a configuration screen.

Where this came from

Three layers of cause compounded:

1. The “successful migration” specification did not include the specific field that mattered. Modern core banking migrations are validated against tens of thousands of checklist items. The 4EOD field — one entry on one tab in one module — was in the specification. It was not in the acceptance test. The migration acceptance test confirmed that the SI module loaded, that records were present, that the program ran. It did not confirm that every individual instruction field carried over its pre-migration content to the new platform. The gap between “module migrated” and “every field within every record migrated correctly” is the gap into which Nu 1.5 billion fell.
2. The default behaviour of the end-of-day program assumed instructed content. Software systems make assumptions about their input. A well-defended end-of-day program would, on encountering a blank instruction field, refuse to execute against that account and flag for human review. The program executed. The assumption was that the field would never be blank, because the migration would never leave it blank. The assumption was wrong on one record. The program ran anyway.
3. The reconciliation cycle was slower than the exploitation cycle. From migration on 12 February to detection took roughly two to three weeks. During that window, an accountholder noticed an unexpected credit and moved a material portion of it before the bank’s daily reconciliation routines caught the discrepancy. In a peer jurisdiction running real-time gross settlement reconciliation, the gap would have been zero. The Bhutanese banking system runs reconciliation on a daily batch cycle; the gap is structural.

Why this matters now

Bank of Bhutan is the country’s largest bank. The new core banking platform will run for at least a decade and will be the platform on which the rest of the sector benchmarks. The migration model — TCS as consultant, 36-hour cutover window, checklist-based acceptance — is the model that the other banks (BNB, BDB, T-Bank, a Bhutanese digital bank) will follow for their own platform upgrades over the next several years.

If the FY 2026 Bank of Bhutan case becomes the reference case for the sector, three things follow:

• Migration acceptance tests must validate field-level content of standing instructions, not just module presence
• End-of-day and batch programs must default to refusing execution on blank instruction fields, with mandatory human review
• Reconciliation cycles must compress from daily to intra-day, at minimum for high-value accounts

The RMA enforcement action and the criminal prosecution are the consequence-side of the system functioning. The structural-fix-side has not yet been articulated as a sector-wide standard.

What it should be

• A regulatory standard for core banking migrations that requires field-level acceptance testing on every standing-instruction field, signed off by both the consultant and the bank’s CTO and Chief Risk Officer
• A regulatory standard for end-of-day and batch programs that requires default-deny behaviour on blank instruction fields, with mandatory human review queues
• A move from daily to intra-day reconciliation on high-value accounts (>Nu 100M balance) across the sector, with a defined transition timeline
• A migration-failure disclosure regime requiring banks to publish post-mortem analyses of any incident producing >Nu 50M of erroneous movement, so the sector learns from one bank’s incident
• A re-examination of TCS’s role as default core-banking consultant for the Bhutanese sector — not because TCS is uniquely problematic, but because monoculture in consultant selection means a single consultant-side blind spot becomes a sector-wide blind spot

How others do it

• Australia (CBA, ANZ core banking upgrades 2010–2018) — APRA requires post-incident root-cause analysis published to the regulator within 90 days; mandatory field-level acceptance testing on standing-instruction modules; sector-wide lessons-learned circulars after material incidents
• United Kingdom (TSB IT migration failure 2018, RBS IT failure 2012) — both incidents produced multi-year FCA investigations, large fines (TSB £48.65M, RBS £56M), and statutory operational-resilience rules now in force across the sector
• Singapore (DBS service-disruption incidents 2023) — MAS imposed additional capital requirements ($1.6bn risk-weighted-asset surcharge) and a six-month moratorium on non-essential IT changes; published findings drove sector-wide operational-resilience tightening
• India (HDFC Bank tech outages 2020–2021) — RBI imposed a moratorium on new digital launches and new credit-card issuance until remediation completed; sector-wide rebuke on tech-resilience governance
• Bhutan: RMA imposed Nu 228M penalty + independent assessment; criminal prosecution proceeding under existing Penal Code provisions; no sector-wide operational-resilience circular yet issued

The question we should be sitting with

Modern Bhutanese banking has the regulatory architecture of a sophisticated jurisdiction. The supervisor enforced. The penalty was proportional. The judicial system absorbed the case. None of it protected anyone from a blank field on a tab in a configuration screen. The paradox is not that the migration failed. By every measure a system engineer would use — platform operating, books reconciled, defrauded amount largely recovered — it succeeded. The paradox is that the technical specification of “successful migration” did not include the one specific field that mattered. The system executed what was in front of it. What was in front of it was blank. When the next migration happens — at BNB, at BDB, at T-Bank, at a Bhutanese digital bank — will the specification have changed?