Effective-Dated Rules

Regulated products are governed by rules that change repeatedly, and a change applies from a date. A policy issued last year is still governed by last year's rules; a transaction executed under the old disclosure requirement is not retrospectively non-compliant.

A system that cannot express "this record is governed by the rules as at its creation date" must migrate data on every rule change — which is the actual source of the disruption teams attribute to regulation itself.

Why it matters

It converts a category of change from a project into a configuration update. That difference compounds: regulated businesses face many such changes per year, and the ones whose architecture absorbs them ship product while the others run migrations.

It is also a correctness requirement. Recomputing a historical outcome under current rules produces a wrong answer, and in a regulated context a wrong answer to a regulator's retrospective question is a finding.

Implementation patterns

• Rules as versioned configuration with effective-from and effective-to dates, not as code.
• Every record references the rule version it was created under, resolved once at creation rather than looked up at read time — so the answer is stable even if the rule store changes.
• Recomputation uses the record's rule version, never the current one.
• Jurisdiction as a first-class dimension from the first row of data, since rules vary by jurisdiction and retrofitting a partition key into a live schema is one of the genuinely painful migrations. An unused column costs nothing.
• Reporting driven from a stable internal model with a per-regulator mapping layer, so a format change is a mapping change rather than a domain change.
• An audit trail sufficient to demonstrate compliance retrospectively, because the regulator's question is usually about the past rather than the present.

Industry example

Insurance platforms such as Acko and Digit issue products whose terms, disclosures, pricing constraints and claims rules are set by regulation that changes, and whose policies remain in force for years afterwards. The architecture that survives treats the rule set as data with a temporal dimension; the one that does not accumulates conditional logic keyed on issue date, which is the same thing implemented badly.

The same pattern governs lending, payroll, tax and any product with a long-lived record under changing rules.

Failure scenarios

• Rules in code, so a change is a deployment and history is lost.
• Rules in configuration without effective dates, so a change retroactively alters historical records.
• Rule version looked up at read time, so a later configuration change silently alters past outcomes.
• Jurisdiction added later, requiring a migration of every record.
• A rules engine built before the second jurisdiction, generic along the wrong axes and harder to change than the hard-coded version it replaced.

Trade-offs

Effective-dating adds real complexity: every read must resolve a version, testing must cover multiple rule sets simultaneously, and the configuration store becomes a critical system with its own change control.

The alternative is a migration per rule change, plus an inability to answer retrospective questions correctly. For a regulated product with long-lived records that is not a trade, it is a requirement — and the judgement is only about which rules genuinely need it, since applying it to everything imposes the cost where there is no benefit.

Interview question

"A regulator changes a disclosure requirement effective next month. Tell me exactly what changes in your system, and what happens to the two million policies already in force."