Effective-Dated Pension Rules Without Rewriting History

This is part of the engineering series behind our group pension administration case study. A spreadsheet invites an operator to change a rate cell and recalculate. That is convenient until the same cell is referenced by prior years, existing benefit work and statements that were already issued. The new rate can silently rewrite the past.

GPAS treats a plan rule as something that was valid for a period, not as a timeless property of the plan. Vesting ladders, fees, retirement ages, entry conditions and calculation choices live in versions. Each financial event supplies a value date, and that date selects the version. The system can change tomorrow without pretending yesterday always used the new answer.

Current configuration is not historical truth

A plan can revise its fee basis, eligibility conditions or vesting schedule. The revision should govern events in its approved period. It should not alter a benefit valued before the revision or a closed scheme year. A single mutable plan row cannot express that requirement because it stores only the latest answer.

We store rule versions with validity windows. Creating a change produces a new version rather than editing the active one in place. The resolver finds the approved version covering the event's value date. If the windows overlap or leave a date that should be covered without a rule, configuration is invalid; the calculation does not guess which record an administrator intended.

This makes historical explanation direct. The system can show the rule version selected, its effective interval and the inputs used. An auditor does not have to compare today's setup with an archived email to infer how the old figure might have been calculated.

Value date and entry date answer different questions

Entry date answers when the organisation recorded something. Value date answers when the event belongs economically. A contribution received for an earlier period can be entered later. A benefit case can be keyed today with a termination date in the past. Using entry date to choose the rule version would make administrative delay change the financial outcome.

The value date selects both the scheme year and the rule version. The entry timestamp remains in the audit record and can reveal late processing, but it does not reprice the member merely because a clerk worked after a new version became active. Keeping the dates separate turns lateness into visible operational information instead of a hidden financial side effect.

Scheme years belong to plans, not the calendar

Group pension plans do not all close in December. Each contract can have its own scheme-year end, so a calendar-year helper is not enough. Given a value date, the system resolves the plan's scheme-year boundary and then the rule version valid inside that period. Reporting, interest and close all use the same temporal vocabulary.

This matters at the edges. A transaction posted on the first day of a new scheme year may be one day after the previous year's close while still being entered in the same calendar month. Encoding scheme-year membership once prevents benefits, contributions and reports from each inventing a slightly different date test.

Vesting is a rule set, not a lookup cell

Employer contributions vest according to plan-specific service bands and the member's reason for leaving. Age can matter for some outcomes. The engine resolves the service measure and applicable ladder from the version at the benefit value date, then applies the percentage only to the employer source. Employee money is not exposed to the same forfeiture rule.

When the ladder changes, an administrator adds a future-effective version. Existing benefit calculations retain their selected version, and a recalculation for an earlier leaver still finds the historical ladder. This is exactly the behaviour a mutable spreadsheet struggles to preserve: the formula can be copied into a dated tab, but nothing prevents a later editor from changing the wrong copy.

Fees arrived in more shapes than the first specification

The early design captured the fee rules described by the initial evidence. Contact with real plan configurations later introduced flat charges, per-member charges, minimum and maximum caps, different billing frequencies and billing dates that have to clamp safely when a month is shorter. Entry rules needed a maximum age and a controlled override. Early retirement introduced a reduction rule.

That late-stage work did not require rewriting the ledger or restating prior periods. The rule schema learned more shapes, each configuration change became another approved version, and the value-date resolver kept old calculations attached to the old representation. The architecture did not predict every plan, but it preserved the mechanism for adding what reality revealed.

There is an important limit here. Configuration should express legitimate variation, not become a programming language embedded in the database. We added concrete fee and eligibility shapes supported by actual plans. Unknown future behaviour remains a product decision and an engine change, not an administrator-authored formula evaluated at runtime.

Calendar configuration needs failure behaviour too

A plan can specify a billing day that does not exist in every month. The rule defines how that date clamps rather than leaving each caller to improvise. Billing frequency and scheme-year boundaries are stored with the plan version, so a schedule generated later uses the period's approved calendar behaviour instead of today's default.

The same applies to eligibility overrides. An entry rule can reject a member while an authorised exception route allows a documented override. The override is not a change to the plan's rule and does not create a secret version. It is an audited exception attached to that member event, preserving both the general rule and the reason it was not followed in one case.

Coupled choices must be valid together

A late alignment review found that the plan's investment model and earnings mode could be configured inconsistently. Both fields were individually valid, yet the pair could instruct the system to apply declared-rate interest while also charging an investment-related fee. The interface showed two reasonable choices and allowed an unreasonable combination.

The correction made the relationship a server-side invariant and derived one choice from the other in the interface. This is a recurring configuration lesson: validation belongs on combinations, not only fields. When two settings describe the same economic model from different angles, accepting each independently is not enough.

Rule changes need four eyes

Rule versions determine future money, so creating one is not ordinary administration. The initial build allowed a single authorised user to change the path that reprices later calculations, contradicting the wider maker-checker model. The correction made a new version a pending draft until a different person approves it.

Approval is identity-based. Giving one login every relevant role does not permit it to create and approve the same version. The workflow records both actors and keeps the old approved version active until the handoff is complete. A partially configured future rule never becomes the current rule because somebody opened an edit screen.

The broader control model—including benefit clearance, contribution approval and annual close—belongs in Maker-Checker Controls Administrators Cannot Bypass. Here the important boundary is temporal: only an approved version can govern a date, and approval cannot be self-issued.

Corrections do not alter the old rule

If a rule version itself contains an error, correcting it requires an explicit decision about the affected period. A future-effective correction is straightforward: approve a new version from the chosen date. A correction intended to cover an earlier period cannot simply overwrite the old row, because calculations and postings may already depend on it.

The system therefore preserves the superseded version and its approval history. Any financial correction follows the ledger's reversal and reposting model, with the revised rule selected deliberately. Temporal versioning does not eliminate hard business decisions about retroactivity; it prevents those decisions from being made accidentally by an edit.

Configuration should explain itself

A calculation result records the version and the material rule inputs it used. An administrator reviewing a benefit can see the service basis, vesting band, fee shape or retirement adjustment without reconstructing the configuration from a current plan screen. The explanation is generated from the resolved version, not from whichever version is active when the result is viewed.

Reason and error codes come from a defined registry instead of free text, which keeps recurring configuration failures comparable across plans. Free text remains available for the human rationale, but machines do not have to infer whether two differently worded errors mean the same rule was missing.

That inspectability helped the correctness audit find mismatched percentage scales, vesting-band edges and proration behaviour. The fixes changed explicit rule handling and added boundary tests; they did not edit historical outputs until they looked plausible.

Testing the boundary dates

Most temporal defects live on the first and last valid day. Tests cover dates immediately before and after a version transition, scheme-year boundaries, late entry with an earlier value date, months without the configured billing day and service values at vesting-band edges. The expected rule identifier is asserted alongside the monetary result so the correct number cannot hide selection of the wrong version.

Historical golden fixtures provide the stronger integration proof. They run known scheme-years through the database and confirm that later rule work has not moved the audited results. Unit tests explain individual boundaries; fixtures prove that the full rule-selection and posting path still reproduces independent historical evidence.

Capture irreversible facts without building the future product

Version one administers defined-contribution plans. It does not contain a defined-benefit calculation pretending to be ready. It does capture salary and employment history, plan-join dates and beneficiary information that a later product may need, because those facts cannot be recreated reliably after years of omission. The calculation seam exists; the out-of-scope formula does not.

This is the same temporal principle at a larger scale. Preserve facts that occur once. Version rules that change. Delay speculative calculations until there is evidence to define them. A system remains extensible not by implementing every future possibility, but by refusing to destroy the history those possibilities would depend on.

The takeaway

Effective dating is not a reporting convenience. It is how a financial system admits that rules change without claiming the past changed with them. Separate economic time from entry time, give plan rules explicit validity, approve new versions through a controlled handoff, validate related settings together and test every boundary. The reward is simple to state: the same historical question keeps the same answer after the next plan amendment.