Why We Build One Model Per Jurisdiction, Not One Global Model

The default approach, and why it's tempting

The fast way to build a multi-jurisdiction tax platform is to build one core model — one representation of "how tax works" — and adapt it per jurisdiction with parameters, exceptions, and translation layers. It's tempting because it's faster to ship, and because most engineering instincts favor a single, reusable core over fourteen separate ones.

It's also, in miniature, the exact structural problem behind why Asia and the Middle East have historically been served by adapted versions of Western tax practice rather than something engineered for their own pace and complexity. Grant Thornton, Crowe, and BDO are excellent firms — for the tax regimes they were built inside. Their systems, incentives, and fee models were shaped by decades in the United States and Western Europe. The rest of the world gets the same playbook, translated, arriving a cycle behind the regulation it's meant to address.

What a global model optimizes for

A single global model, however well engineered, is implicitly optimized around the jurisdiction it was designed against first — usually whichever market the founding team originally built for, or whichever regime is easiest to generalize from. Every other jurisdiction becomes a set of exceptions layered on top of that base case. That works fine right up until a jurisdiction's own structure doesn't fit the base case's assumptions cleanly — which, across fourteen structurally different regulatory environments spanning South Asia, the Gulf, Southeast Asia, the Caucasus, and Africa, is closer to the rule than the exception.

The UAE's federal corporate tax, barely two years old, doesn't share deep structural assumptions with India's GST-and-income-tax system, which in turn looks nothing like Georgia's flat-rate, minimal-bureaucracy regime or Switzerland's AEOI-era private-wealth disclosure requirements. Treating all four as configurations of one underlying model means every one of them inherits some assumption that was never built for it.

The cost of doing it separately, and why it's worth paying

Building fully separate, jurisdiction-native models is slower. There's no way around that — it means the Interpret stage of our platform's loop has to happen from scratch, in depth, for each of our 14 founding markets, rather than once with local parameters bolted on. It means a regulatory change in Oman's newly legislated personal income tax doesn't get handled by the same code path that handles a change to Malaysia's e-invoicing mandate, because those two changes don't resemble each other structurally, even though both are "tax law changes" at a glance.

What that buys back is traceability and trust: if the platform tells you why a filing looks the way it does, it can point to the exact regulation behind that answer, in that jurisdiction's own terms — not a generic answer translated backward from a shared global model. For a domain where a wrong or unexplainable position carries real regulatory and reputational consequences, that traceability isn't a nice-to-have. It's the entire reason a platform built this way is worth building at all.