A corporate action is confirmed with an effective date in the past, after you have already struck positions and sent statements. How does your system cope?

The event has two dates and your data model probably has one

A corporate action becomes effective on a date the issuer sets. You find out on a date the custody chain determines, and the two are frequently not the same: terms are revised, a notification is late, an intermediary aggregates before passing detail down, or the event was announced as one thing and confirmed as another. So on Thursday you learn that a two-for-one split took effect on Monday, and every position, valuation and statement produced on Tuesday and Wednesday was computed on a share count that has since been redefined.

If your position store holds one date per row, you now have a choice between two wrong answers. Update the quantities in place and today's report is right while Tuesday's report can no longer be reproduced, so when a client queries the statement they hold you have nothing to show them. Leave history alone and post a correction dated today, and your return series shows an impossible jump on the wrong day and your position was understated for two days with no record of why.

The way out is to store both dates. Effective date says when the world changed. Knowledge date, sometimes called the as-at or recorded date, says when you came to believe it. Every position row carries both, and nothing is ever mutated: a correction is a new row with the same effective date and a later knowledge date.

Position rows for one holding, nothing ever updated in place

  effective_from  known_from   quantity   source
  2026-07-01      2026-07-01      1,000   trade settlement
  2026-07-27      2026-07-30      2,000   split 2 for 1, notified late

Two questions, two correct answers, same table

  "What is the position on 28 July?"
      as at 29 July  ->  1,000   the number the client's statement shows
      as at today    ->  2,000   the number that was always true

  "Why did the statement say 1,000?"
      because on 29 July the second row did not exist yet

The second question is the one that makes the design worth the trouble. Clients, auditors and regulators do not usually ask what the position is; they ask why you said what you said, and only a store that can be queried as at a past moment can answer that without a spreadsheet and a memory.

Which events genuinely force a restatement

Not everything late needs history rewritten, and a candidate who restates indiscriminately has created work rather than accuracy. The test is whether the event redefined the unit or merely added a cash flow.

Ratio events redefine the unit. A split, a consolidation, a bonus issue or a scheme of arrangement changes what one share means, so every quantity, price and derived series that spans the effective date is expressed in units that no longer exist. Comparisons across the date are meaningless until adjusted, which is why the adjusted price series carries a cumulative factor and why that factor has to be applied retrospectively when the event arrives late. A performance number computed across an unadjusted split is not slightly wrong; it is wrong by the ratio.

Cash events usually do not. A dividend confirmed at a different rate, or paid later than expected, changes an accrual and a cash balance. If the amount is inside your materiality policy, it can be recognised with its effective date and reported from today without reissuing anything, because no earlier figure was expressed in the wrong units. That is a judgement, and the useful thing in an interview is to say that the firm has a documented threshold and that engineering implements it rather than invents it.

The fan-out is the real cost

The entitlement posting is arithmetic. What makes this expensive is everything already computed from the quantity that has changed, and naming that list is most of what distinguishes a candidate who has lived through one.

Valuations move, so any net asset value struck in the affected window is potentially misstated, and a fund's error policy will define a threshold above which investors who subscribed or redeemed at the wrong price must be compensated. That turns a data correction into a payment. Collateral and margin were called on the wrong quantity, so a call may have been under or over. Return and risk series need rebuilding across the date rather than appending to. Regulatory position disclosures computed as a percentage of issued share capital used both a numerator and a denominator that the event may have changed, and a threshold crossing you did not report is not fixed by noticing it late. Tax and income reporting inherit the corrected rate. And any open order priced against the old unit is now priced absurdly, which is why a limit order sitting through an unadjusted split is a live trading risk and not a reporting one.

The reason the immutable ledger pays for itself is that each of these consumers can be replayed from the corrected event stream. Systems that mutated position rows in place have to be told individually what changed, by someone who has worked out the difference.

Where the record date makes the answer harder

Entitlement is determined by the holding on the record date, and the holding on the record date is a settled position rather than a traded one. So a purchase executed before the record date but settling after it leaves the buyer economically entitled and the register showing the seller, which is precisely the situation the market claim process exists to resolve: the entitlement is claimed from the counterparty who received it rather than from the issuer.

The interaction with a late notification is unpleasant. You may have to raise a claim for an event you did not know about at the time, against a trade whose settlement has long since completed, on a quantity that has itself been redefined by the same event. This is why the entitlement calculation is done against a reconstructed as-at settled position rather than against today's book, and why a store that cannot reconstruct one leaves the operations team to work it out by hand.

Voluntary events do not get this second chance. If the notification arrives after the election deadline, there is nothing to elect and the default in the terms is what you receive, so the exposure has already crystallised into a claim against whoever in the chain was late. Recording the notification's arrival time is therefore a control rather than a nicety, because it decides which firm carries the loss.

What separates a strong answer here

The adequate answer describes booking the entitlement correctly. The strong one treats the late notification as the normal case rather than the exception, because it is: notifications are revised routinely, and a system designed only for events that arrive before their effective date will be corrected by hand for its entire life. Design for a correction that arrives at any time, keep both dates on every fact, and accept that the goal is not to make yesterday's report right. Yesterday's report was the best available belief and should stay exactly as it was, with the new belief recorded alongside it and a documented reason for the difference.