A global enterprise application must satisfy different regulatory regimes per market. Where should regulatory logic live?

Why branching in application code fails

Regulatory conditionals scattered through business logic become impossible to audit. Nobody can answer "what does this system do for a subject in this jurisdiction" without reading every code path, and a new market means touching every file that has a conditional in it.

It also puts a compliance requirement in a place where an ordinary refactor can silently break it.

Why forking per jurisdiction fails

Forks diverge. Two years later the markets differ in ways nobody intended, a security fix has to be applied several times, and the effort of adding a market scales linearly with the number of existing ones.

What works

• Invariants in the platform: encryption, audit logging, access control, retention floors — properties a configuration cannot switch off.
• Jurisdiction as data: residency, retention periods, consent categories, permitted purposes, and disclosure requirements expressed as policy rather than as code.
• A policy decision point the application consults, so the answer to "may I do this with this data" is evaluated centrally and logged.
• Evidence generated automatically, because manual evidence collection across markets does not scale and is what makes audits expensive.

The distinction that makes it tractable

Separate what must be universally true from what legitimately varies. Universal properties belong in the platform. Everything else is configuration with a default, and the default should be the most restrictive regime rather than the least — so a new market is a relaxation with a stated justification, not an omission nobody noticed.