Can Automate for SG, Not for MY

Half of what we shipped to Singapore last year still hasn’t reached Malaysia. Engineering didn’t break. The assumption did.

Early this year I sat in a 1:1 with an engineering lead whose work runs across both markets. We were unpacking the aftermath of a compliance-driven re-verification exercise: a slice of the customer base needed their records re-checked, against a deadline, in two countries at once.

The Singapore half barely registered as engineering work. The flow pulls government-verified identity data through an API, runs the checks, approves. A customer who responds gets cleared in minutes, untouched by human hands. Then he got to the Malaysian half and his voice changed. “For Singapore, we can automate this end to end,” he told me, in effect. “For Malaysia, we can’t.” The same flow, for the same company, dead-ends into a document upload, a manual review, and a queue that an operations team works through by hand while the deadline doesn’t move.

He wasn’t complaining. The infrastructure just doesn’t exist yet — and that fact had been missing from every estimate we’d made about that rollout.

The regional fallacy

There’s a sentence that shows up in roadmap discussions at every company that operates across Southeast Asia: “It works in Singapore — we’ll just turn it on for Malaysia.”

That sentence is a smoke alarm.

Here’s what “turning it on” actually meant for the flow above, and for most flows I’ve watched cross that border: a separate compliance interpretation, because the two regulators read the same risk differently. A different set of acceptable documents, because the national identity ecosystems aren’t equivalent. A different bank-rail integration, because money moves on different pipes here. A different operational fallback, because when automation isn’t possible, a human queue has to exist, be staffed, and be monitored. Different timing assumptions, because a step that’s instant in one market takes days in the other.

None of that is visible in the codebase. The codebase looks 80% shared. That’s what makes the estimate wrong: teams scope the Malaysian rollout as the remaining 20%, and it lands at 60-80% of the original build — sometimes more, because the manual-fallback machinery (admin tooling, queue visibility, ops reporting) is work the Singapore version never needed at all.

The cost isn’t only engineering hours. It’s that the gap gets discovered mid-rollout instead of at scoping. The Singapore launch announces itself as a regional win, the roadmap moves on, and the Malaysian half quietly becomes an ops burden that engineering “will automate later.” Later meets the next roadmap cycle and loses.

And it compounds. Re-verification this quarter, a deposit flow next quarter, an account-maintenance flow after that — every flow that touches identity, money movement, or documents replays the same split. Engineers who have crossed the border once start padding estimates on instinct. The roadmap never learns, because the padding is invisible and the assumption keeps getting written down as “regional”.

Why Malaysia specifically

This isn’t Malaysia being difficult. It’s an infrastructure asymmetry with a date on it.

Singapore has had Singpass and MyInfo for the better part of a decade: government-verified identity data, exposed through APIs, that the regulator explicitly accepts as a reliable source for customer verification. When the government runs the identity rail and the regulator recognizes it, “automate the KYC step” is an integration project. Engineering can build on it the way they build on a payments API.

Malaysia is building the equivalent — MyDigital ID verifies directly against the national registry, registrations crossed ten million in early 2026, and banks have been testing integration readiness in a sandbox. But “in a sandbox in 2026” versus “regulator-recognized API for most of a decade” is the whole story. The rail engineering wants to build on doesn’t exist yet at integration grade. So the same product requirement — verify this customer — resolves to an API call on one side of the causeway and a staffed queue on the other.

And identity is just the visible example. Run the same comparison across payment rails, data-residency rules, document standards, and licensing, and the pattern holds: what product sees as one market, compliance and operations experience as six. Founders who’ve built across Southeast Asia describe needing not a licence but a list of licences. Every fintech operating regionally rediscovers this; most rediscover it after the estimate is committed.

There’s a second-order cost that lands specifically on the Malaysian side of the org chart. When the automatable version ships in Singapore and the manual version ships in Malaysia, the KL team inherits the remainder: the admin tooling, the queue dashboards, the weekly check-ins with an ops team under deadline pressure. That work is real, hard, and customer-protecting — and it photographs terribly. The engineer who integrated the identity API gets a demo at the all-hands. The engineer who built the manual-review queue gets a support rotation. A few cycles of that and your regional teams learn what kind of work gets noticed — and it isn’t theirs.

Here’s the part I care about as a KL-based engineering manager: the engineers in Kuala Lumpur already know all of this. They’re the ones who built the manual queue. They’re the ones who sit closest to the ops team working through it. The knowledge gap isn’t in the region — it’s at headquarters, where a product org anchored in the most automatable market in Southeast Asia keeps writing “regional” on a one-line roadmap item. The bug is at headquarters. The technical work is only the symptom.

What an EM should do with this

The leverage point isn’t technical. It’s the moment a regional feature gets scoped, before any estimate enters the roadmap.

My rule now: when a rollout is described as regional, I make the per-country fan-out cost visible before engineering commits a number. Not a disclaimer — a table. For each market: can this step be automated today, what rail does it depend on, what’s the manual fallback if it can’t, and who staffs it. For the re-verification flow, the Singapore row read identity API, automated, no fallback needed. The Malaysia row read document upload, manual review, ops queue, needs admin tooling that doesn’t exist yet. Same feature. Two different projects. Five minutes per country, and “we’ll just turn it on for Malaysia” stops being an assumption and becomes a line item someone has to defend.

Which leads to the take I’ll defend: “regional” features should be scoped per-country from day one, even when the build is shared. If the scoping doc has one row for a six-country rollout, the doc is lying to you. Six countries, six rows — even if four of them say “same as SG, verified.” The point isn’t paperwork. The point is forcing the verification, because the rows that say “same as SG” without verification are where the next quarter’s surprise lives. Yes, this makes scoping slower. Scoping is the cheapest place to be slow.

The transferable version, for anyone running engineering across this region: a shared codebase is not a shared product. Code crosses borders for free. Compliance, identity rails, bank integrations, and operations queues do not. Estimate the second list, not the first.