Regulatory Divergence Is Not a Compliance Project
The organisation that treats every regulatory difference as a new programme will spend continuously and learn almost nothing.
The programme that closed before the rulebook moved
A multinational service organisation completed an 18-month compliance programme in December. Policies were rewritten, 63 controls were mapped, twelve systems were changed and every business unit signed an attestation. The programme closed with a green report.
In January, one jurisdiction issued a new interpretation of customer-record retention. A second changed the evidence expected from outsourced technology providers. A third retained the existing rule but altered its supervisory emphasis. None of the changes invalidated the whole design. Each affected a different combination of process, data, contract and system configuration.
The organisation reopened the programme office.
This composite pattern is increasingly familiar at the start of 2016. Regulatory change is no longer experienced as an occasional interruption followed by a stable state. Financial reform continues to generate implementation detail. European data-protection reform is taking shape. Cybersecurity, tax, consumer protection, reporting and data-location expectations are developing at different speeds across markets. Cloud adoption adds another layer because services, suppliers and information can cross boundaries more easily than legal obligations do.
The evidence points to a difficult conclusion: regulatory divergence is not a sequence of projects to complete. It is a permanent condition to manage.
The organisation that treats every regulatory difference as a new programme will spend continuously and learn almost nothing.
Why divergence persists
Regulation is often discussed as if the destination were eventual harmonisation. There are common standards, international forums and strong economic incentives to reduce unnecessary difference. Yet organisations continue to face divergence for structural reasons.
Rules share objectives but not operating detail
Two jurisdictions may seek the same outcome—customer protection, financial resilience or responsible handling of information—while defining scope, evidence, timing and enforcement differently. A global policy can express the common intent, but local operation still depends on interpretation.
Supervisory practice differs from written law
The formal rule is only one source of obligation. Guidance, precedent, inspection practice and the risk appetite of local management all shape implementation. The same wording can therefore produce different control demands.
Technology centralises while accountability remains local
Shared platforms and cloud services encourage common processes. Local legal entities and accountable officers still answer to domestic authorities. The technology estate moves toward consolidation just as regulatory accountability remains distributed.
Change arrives on different clocks
One jurisdiction consults while another implements. A third delays enforcement. Programmes that seek one global “go-live” either wait for the slowest market or force uncertain requirements into premature design.
Commercial choices create regulatory footprints
Where data is stored, which entity contracts with a customer, which supplier operates a process and how a product is distributed can all change the applicable obligations. Regulation is not merely an external requirement; it is partly shaped by the organisation’s operating model.
Divergence therefore cannot be eliminated by better legal tracking alone. It is produced by the interaction of rules, markets, entities, technology and organisational choices.
The approaches organisations have tried
Three responses dominate, and each contains a valid instinct.
One global standard
The organisation adopts the strictest known requirement as the enterprise baseline. This simplifies training, technology and assurance. It can also build customer confidence and reduce the chance that information or activity crosses into a stronger regime unexpectedly.
The problem is cost and distortion. The strictest rule in one dimension may not be the strictest in another. Combining every maximum can create an operating model that no jurisdiction actually requires. Local businesses then seek exceptions, and the “single standard” becomes a collection of undocumented workarounds.
Separate local programmes
Each jurisdiction interprets and implements its own obligations. Local accountability is clear, and changes can reflect supervisory practice closely.
The problem is duplication. Multiple teams analyse similar rules, commission similar legal opinions and make incompatible changes to shared systems. The central technology team receives several urgent requests that solve the same problem differently. Local precision creates global incoherence.
A central compliance programme
A central team interprets change, produces a common design and coordinates implementation. This improves consistency and gives executives one view of progress.
The problem is temporariness. The programme mobilises around a known package of rules, creates artefacts and then disperses. Knowledge leaves just as interpretation begins to evolve through ordinary supervision and business change. The next requirement starts again with a new team, a new inventory and a new vocabulary.
What works across these models is a common control language, clear local accountability and reusable evidence. What fails is the assumption that one design can freeze a moving landscape.
The strongest case for harmonising upward
There is a serious argument that the simplest answer is to apply one high standard everywhere. Complexity is expensive. Local variants increase testing, training and operational error. If an organisation is already investing in modern systems and consolidated platforms, it should use regulation to accelerate simplification rather than preserve regional exceptions.
This argument is strongest where the control concerns a universal principle and the cost of variation exceeds the cost of the higher standard. Common access control, traceable approval, accurate reporting and tested recovery often benefit from one enterprise baseline.
But harmonising upward is not a complete strategy.
Some rules conflict rather than merely differ in strictness. Data may need to be available centrally for oversight while local expectations restrict movement. Record-retention periods may not align. Customer disclosures, consent, reporting format and legal-entity accountability may require genuine variants. A high global control can also create commercial or operational consequences that local sponsors are unwilling to accept.
The correct goal is not maximum uniformity. It is controlled variability: one visible core, explicit local deltas and a mechanism for deciding when a delta belongs in the core.
A permanent capability, not a permanent programme
The recommended response is to establish a regulatory-divergence capability that sits across legal interpretation, process ownership, technology architecture and programme delivery.
It has five connected components.
A common obligation model
Regulatory text should be translated into a structured obligation model rather than sent directly to projects. Each obligation records:
- intended outcome;
- affected products, customers, entities and jurisdictions;
- triggering activities or data;
- required control or evidence;
- effective date and uncertainty;
- accountable interpreter;
- relationship to existing obligations.
This creates a common unit of analysis. Without it, legal, policy, process and technology teams use different labels for the same concern.
A core-and-delta control architecture
Controls should be separated into:
- enterprise core: the common requirement implemented once;
- jurisdiction delta: a necessary local variation;
- business choice: a stricter position selected by management;
- temporary interpretation: a cautious arrangement pending clarity;
- exception: an approved departure with compensating control and expiry.
The distinction matters. A business choice should not be presented as law, and a temporary interpretation should not harden silently into architecture.
Enduring ownership
Each obligation needs two owners:
- an interpretation owner accountable for legal and regulatory meaning;
- an operational owner accountable for the process, system and evidence.
A central programme manager can coordinate change, but cannot substitute for either. When ownership disappears at project closure, the organisation loses the ability to respond to changed interpretation.
A change-routing mechanism
Not every regulatory development should launch a programme. Changes should be triaged by impact.
- Interpretation only: update guidance and evidence with no control redesign.
- Parameter change: alter a configurable threshold, period, disclosure or report.
- Local process delta: change one jurisdictional process while retaining the core.
- Enterprise control change: modify the common architecture.
- Strategic operating-model decision: reconsider product, entity, supplier or data-location choices.
The routing decision determines governance, funding and delivery method. A small parameter change should not wait for an enterprise programme, while a change affecting the core should not be hidden inside a local release.
An evidence and learning repository
The organisation should retain more than legal memoranda. It needs the connection from obligation to decision, control, system, test and operational evidence. It should also record rejected options and the reason for local variation.
This allows a new requirement to reuse prior reasoning. It also helps assurance teams see whether similar obligations are being controlled consistently across markets.
Regulatory agility is the ability to change a controlled difference without rediscovering the entire organisation.
A worked operating example
Consider a composite organisation offering one business service across eleven markets. Its original design contains a common customer record, one support process and local reporting. A regulatory review identifies fourteen obligations related to record access, retention, outsourcing evidence and customer notification.
The first analysis appears to require fourteen separate workstreams.
Using the common obligation model, the team finds that nine obligations share the same intended outcomes and can be met through four enterprise controls: role-based access, complete audit records, approved retention schedules and supplier-performance evidence. Three obligations require local report formats. One requires a shorter notification period. One remains uncertain pending local guidance.
The core-and-delta design therefore produces:
- four common controls;
- four local configuration variants;
- one temporary interpretation with an expiry date;
- no separate application versions.
The work is led by a regulatory interpretation owner, the customer-record service owner and the platform architect. Local compliance officers approve jurisdiction deltas. A programme team coordinates the initial change, but the enduring owners remain after delivery.
Six months later, a local authority changes the expected reporting frequency. The change is routed as a parameter update. The organisation adjusts one configuration, tests the local output and updates the evidence link. It does not reopen the full programme.
The value is not that regulation became simple. The value is that difference became visible, owned and changeable.
Organisational conditions that make the model work
A regulatory-divergence capability will fail if it is placed entirely inside one function.
Legal teams can interpret obligation but rarely own system change. Technology teams can build configurable controls but should not decide regulatory meaning. Local businesses understand supervisory practice but may optimise for immediate market pressure. Central compliance can create consistency but may be too distant from operational consequence.
The operating model needs a standing forum with authority to decide:
- whether a requirement belongs in the core or a local delta;
- whether uncertainty justifies temporary control;
- who funds a change affecting several markets;
- when a local solution must be retired;
- whether an operating-model choice should change to reduce regulatory complexity.
The forum should be small and decision-led. Its purpose is not to review every rule. It resolves changes that cross ownership boundaries.
Measures should also change. Counting regulations implemented or actions closed says little about capability. Better measures include:
- time from confirmed obligation to routed decision;
- proportion of controls reused across jurisdictions;
- number and age of temporary interpretations;
- local variants without named owners;
- cost and lead time of parameter versus structural change;
- repeated assurance findings caused by inconsistent evidence.
These measures reveal whether the organisation is learning or merely mobilising repeatedly.
Programme management must change with the problem
Programmes still have an important role. A major regulatory package, a new reporting regime or a strategic operating-model change may require concentrated delivery, investment and executive attention. The mistake is not using programmes. It is asking programmes to own a permanent condition.
A regulatory programme should therefore deliver two things:
- the required change by the effective date;
- an improvement in the enduring capability to absorb the next change.
Its completion criteria should include ownership, obligation records, reusable controls, configurable deltas, linked evidence and retirement of temporary arrangements. If the programme delivers compliance but leaves no better change mechanism, it has solved today’s requirement by preserving tomorrow’s cost.
The recommendation
Organisations should treat regulatory divergence as an enduring design constraint and establish controlled variability as an enterprise capability.
This means retaining a common obligation model, separating core controls from local deltas, assigning interpretation and operational owners, routing changes by impact and preserving evidence that can be reused. Programmes should be mobilised for material change, but they should plug into this capability rather than recreate it.
The recommendation is not a call for local complexity. It is a way to reduce complexity without denying legitimate difference.
At the beginning of 2016, organisations are already centralising technology, adopting shared services and moving more information across organisational and national boundaries. Regulation will not move in perfect synchrony with that operating model. The management challenge is therefore not to wait for a stable rulebook.
It is to build an organisation that can see where rules differ, decide which differences matter and change the right layer without rebuilding everything around it.