Testi

A practitioner’s view on what happens after the ribbon-cutting

UPI now runs live in nine countries. Zero of those nine corridors share a common settlement standard.

That’s the sentence that should stop any BFSI tester mid-scroll, because it’s the plain technical truth sitting underneath a much bigger diplomatic story. This week, Prime Minister Modi is in Indonesia as part of a six-day Act East tour, and one item quietly on that agenda is a link being finalised between UPI and QRIS, Indonesia’s national QR standard — alongside a wider handover of India’s digital public infrastructure playbook, from ONDC-style commerce networks to welfare-delivery systems. That government-to-government momentum is exactly why the corridor count keeps climbing: Bhutan, France, Mauritius, Nepal, Qatar, Singapore, Sri Lanka, the UAE, and, as of June 2026, Cambodia, with Indonesia, Malaysia, Thailand, Japan, the Maldives and Greece somewhere in the pipeline.

The diplomacy explains why this is accelerating. It doesn’t answer the question that actually matters to those of us who test and certify these systems: what have we actually signed up to validate, and does our testing discipline scale at the pace politics is now setting?

Each corridor is a bespoke integration — which means a bespoke testing surface

It’s worth being precise about what these announcements actually deliver. Each one is a discrete, bilaterally negotiated bridge between two national payment systems, engineered and tested independently:

Cambodia:  UPI plugged into Bakong’s KHQR standard via ACLEDA Bank. Phase one is one-directional — Indian travellers paying into Cambodian merchant rails. Phase two introduces a reverse corridor, which means a second, distinct settlement and reconciliation path to validate, not a mirror of the first.

Nepal:  A direct link between UPI and Nepal’s National Payments Interface, live since June 2026, and the first corridor to support two-way peer-to-peer transfer rather than merchant-only payment. That’s real-time settlement replacing a correspondent-banking flow that used to take one to three business days — a materially different failure-mode profile to test against than a same-day merchant QR payment.

Indonesia (in progress):  The UPI-QRIS link being finalised this week sits inside a broader Indonesia Stack build-out, including ONDC-modelled commerce rails. That’s a different regulatory and compliance environment again, layered on top of a payments integration that doesn’t yet exist in production.

Nine live corridors is not one payment rail to certify — it’s nine independent reconciliation architectures, each with its own settlement semantics, currency-conversion logic, retry behaviour, and regulatory sign-off. The technology brand is shared. The failure modes are not.

Where the real risk lives: the settlement layer, not the QR code

Scanning a QR code and seeing “payment successful” is the easy 10% of this problem. The hard 90% is everything that has to reconcile correctly, invisibly, behind that confirmation screen — and it’s where testing effort should concentrate:

Currency-conversion rounding:  Every cross-border leg introduces a conversion boundary. Rounding logic that’s individually correct on both sides of a corridor can still produce a reconciliation mismatch in aggregate once volume scales — the kind of defect that’s invisible in unit testing and only shows up in production ledgers weeks later.

Partial settlement and timeout handling:  

In a two-way corridor like Nepal’s, what happens when one leg of a transaction confirms and the other times out? Two banks’ retry and idempotency logic, designed independently, now have to interoperate under load — and neither institution originally built that logic with the other’s edge cases in mind.

Cross-timezone reconciliation windows:  Nine corridors, nine banking-day calendars, no shared clock authority. Reconciliation jobs that assume a single end-of-day cutover need to be re-validated for every new corridor, not templated from the last one.

Compliance divergence:  AML/KYC thresholds, transaction limits, and reporting obligations differ by jurisdiction, and none of that is visible at the UX layer where the diplomacy and marketing conversation stays parked.

Bilateral vs. multilateral: a testing-cost problem, not just a policy one

There’s a competing architecture worth watching closely for exactly this reason: Project Nexus, the Bank for International Settlements initiative to interlink multiple countries’ fast-payment systems against one shared multilateral standard, rather than one bilateral wire at a time. India, Malaysia, Thailand, the Philippines and Singapore are founding members, Indonesia’s central bank sits in as a special observer, and the platform is expected to go live in 2026.

The commentary around Nexus usually frames it as a rival model to India’s bilateral approach. From a testing standpoint, the more useful framing is cost: a bilateral model means the full settlement, compliance, and reconciliation validation cycle gets rebuilt from scratch for every new country pair. A shared multilateral standard means validating against one spec once, then certifying new participants against that same baseline. One approach scales diplomatically faster; the other scales in test-and-certification effort. Neither has fully proven itself yet — which is exactly why this is the space to watch, not settle, over the next two years.

A question worth putting to the room

Here’s where I’ll leave this open, because I think it’s a fair question for anyone in payments right now: a considerable share of the cross-border payments conversation this year has gone toward stablecoins as the future of settlement — new rails, new compliance frameworks, new testing disciplines, largely built from zero. At the same time, a real-time, interoperable, already-proven rail is being extended corridor by corridor, live in nine countries, processing over 14 billion transactions a month domestically, with a testing and reconciliation discipline that, while imperfect, already exists and is being refined in production, not in a whitepaper.

Is it fair to ask why so much of the industry’s attention and engineering effort is going toward reinventing settlement rails from scratch, when a proven, working, real-time model is already being extended, tested, and adopted at sovereign scale? I don’t think the answer is simple — stablecoins solve for programmability and permissionless settlement in ways a bank-mediated rail like UPI structurally doesn’t, and that’s a genuine trade-off, not a flaw to dismiss. But it’s worth asking out loud, especially for those of us who spend our working hours validating that these systems actually hold up under real load: are we chasing the harder problem before we’ve finished proving out the one we’ve already mostly solved?

5-Point Quick Read

1. The $6M warning. A widely reported QA industry account describes a company that replaced its QA team with an AI pipeline and reportedly suffered a $6M production failure. Whether verified incident or cautionary example, the message for banking is clear: in financial systems, the equivalent failure is a mispriced trade or a failed sanctions check.
2. The evidence is increasingly clear. Industry studies find AI-assisted code carries higher defect density than human-written code. Security vulnerabilities trend meaningfully higher where human review is absent. Release cycles are accelerating anyway.
3. The bottleneck moved. AI didn’t eliminate the testing problem — it shifted it squarely into QA. Governed test data, regulatory accountability, and human sign-off are now the missing pieces.
4. Humans stay in the loop. The teams getting this right are not removing QA engineers — they’re repositioning them at the moments that matter: intent review, data governance, risk-based decisions.
5. Tristha is ready.  In regulated banking environments, institutions must be able to evidence who approved critical changes, what was tested, what risks were accepted, and whether the release decision had accountable human oversight. Tristha brings the requirements traceability, human-reviewed test generation, governed BFSI test data, risk-based regression selection, and auditable release sign-off that banking QA teams need to meet that standard with confidence.