US vs. Global Financial Calculators: Why This Product Starts Domestic

Every added jurisdiction is a permanent maintenance calendar, not a feature flag. The honest catalog ships only what it can maintain.

A recurring question about any US-first financial-model catalog is when it will support other jurisdictions. The honest answer is that the registry and the models are US-federal by design today, and another jurisdiction would enter only when its constants can be maintained with the same discipline the US constants receive. This piece is the neutral comparison between a US-focused catalog and a global one, and why the choice to start domestic is a scope discipline rather than an oversight.

The regulatory surface

US financial computations sit on top of a specific and well-documented regulatory surface. IRS revenue procedures publish inflation-adjusted contribution and deduction constants on a predictable annual cadence.^[1] SSA POMS documents the current benefit-computation factors. Federal and state agencies publish the constants that consumer-facing calculators consume; the sources are primary, dated, and cited-in-place.

Global scope requires reproducing this discipline across every added jurisdiction. UK pension contribution allowances have their own annual cadence and their own primary sources. Canadian RRSP and TFSA limits move on Canada Revenue Agency's calendar. Australian superannuation caps move on the Australian Taxation Office's calendar. Each jurisdiction is a maintenance calendar; adding one is not adding a feature, it is adding a permanent commitment.

The constant registries

A US constants registry maintained to primary-source discipline is a durable artifact once it exists. Multiplying that discipline across jurisdictions is not linear. Each added jurisdiction needs a maintainer familiar with its regulatory sources, its publication cadence, and its terminology; a Canadian TFSA is not the same object as a US Roth IRA even where the tax-treatment analogy is close. A global registry that flattens the differences quietly encodes errors in exactly the places sophisticated users notice.

The alternative — a registry that faithfully preserves the differences — requires a jurisdiction-specific data model, jurisdiction-specific naming conventions, and jurisdiction-specific documentation. This is the correct approach, and it is a substantial engineering investment per jurisdiction added. Rushing it produces a registry that misrepresents the jurisdictions it claims to cover.

The model specs

Financial-model specs are jurisdiction-bound whether they say so or not. A refinance-break-even model written in a US context assumes US closing-cost conventions and does not consider UK stamp-duty land tax. A Social Security timing model does not translate to a Canadian CPP or UK State Pension; the reduction and credit factors are entirely different, and the underlying benefit structures are different enough that a common spec would mislead more than it would help.

The honest architectural choice is one spec per jurisdiction where the underlying rules differ, and shared specs only where the rules are genuinely universal. Arithmetic — amortization, present-value, IRR — is universal. Regulatory-touching models are not. A catalog that ships US-scoped specs today and adds jurisdiction-specific ones over time is a catalog that stays honest at each stage. A catalog that promises global coverage today under a single spec per model is a catalog that hides the jurisdictional differences from callers.

Why starting domestic is a discipline

Starting domestic is not a preference for one country over others. It is a discipline about not shipping what cannot be maintained to the discipline the rest of the catalog is held to. Each added jurisdiction has to earn its way in by producing a registry, a set of specs, and a verification-case set of the same quality as the US artifacts. The alternative is a catalog whose quality varies by jurisdiction, which is worse for every caller than a smaller catalog whose quality is uniform.

The comparison for callers

A caller whose product is US-only is well-served by a US-focused catalog with primary-source discipline. A caller whose product is global should evaluate the vendor's per-jurisdiction depth rather than the vendor's jurisdiction count. Ten jurisdictions covered thinly is worse for the caller than three jurisdictions covered to primary-source depth; the ten will fail in ways the caller cannot easily debug, while the three will fail only outside their disclosed scope.

The comparison for callers also depends on the caller's substitution options. Where a jurisdiction is not covered, can the caller substitute a local vendor? An OSS library plus a locally-maintained constants set? A regional-specialty vendor? The evaluation is not whether the primary catalog is global; it is whether the caller has a defensible path for every jurisdiction the caller ships in.

“Global scope is not a feature. Faithful per-jurisdiction scope is. The difference is a decade of maintenance work per jurisdiction added.”

What adding a jurisdiction would take

A jurisdiction becomes ready for the catalog when three conditions hold: a maintained registry of that jurisdiction’s constants can be produced to the same discipline as the US registry; specs for the jurisdiction-touching models can be authored and dual-implemented; and verification cases can be produced against primary-source authorities in that jurisdiction. Each condition is a real engineering commitment. There is no international item on the roadmap today — the registry and the models are US-federal by design. If the catalog ever adds a jurisdiction, it will be when those commitments are made, not by rebranding US models in the meantime.

What global-first architectures often get wrong

A global-first architecture tends to converge toward per-jurisdiction depth once the failure modes become visible. A single model claiming to compute retirement outcomes across ten jurisdictions typically embeds one jurisdiction’s assumptions and applies them by analogy elsewhere. Callers in the non-primary jurisdictions receive numbers that look reasonable and are quietly wrong at the edges. The remediation is either a per-jurisdiction spec or the removal of the claimed coverage. Both remediations are expensive; the first is expensive engineering, the second is expensive to the caller’s trust.

How callers can adapt when the catalog is not yet global

A caller shipping in a jurisdiction the primary catalog does not cover has three defensible options. First, source a specialist vendor for that jurisdiction and integrate at the same abstraction level as the primary catalog. Second, build a local implementation that reads from a locally-maintained registry and produces envelopes matching the primary catalog’s shape. Third, disclose that the jurisdiction is not covered and route users to primary-source calculators the agency itself publishes. All three are honest; the choice depends on how much of the caller’s user base is in the uncovered jurisdiction and how central the arithmetic is to the caller’s product.