Event Sourcing in financial systems: when it's worth the cost

Event sourcing promises an immutable, auditable history of everything that ever happened in a system. In core banking, that promise is especially appealing — but the pattern carries a real complexity cost that needs to be justified.

Where the cost pays off

• Accounting ledger — the very nature of double-entry bookkeeping is already an event log; formalizing it as event sourcing is a natural extension.
• Compliance trails — regulators frequently ask you to "reconstruct what the customer saw on screen on a specific date." Without events, that's log archaeology; with events, it's a projection.
• Reconciliation with the Central Bank — divergences between what the SPI confirms and what the core recorded are resolved by comparing event streams, not table snapshots.

Where it usually doesn't pay off

Customer registration, notification preferences, account settings — data that changes by replacement, not by accumulation of business facts, rarely justifies the overhead of a dedicated event store.

Reference architecture

A durable, log-based queue as the source of truth for domain events, with:

• Materialized read models rebuilt asynchronously.
• Controlled replay, used both to fix projection bugs and for formal audits.
• Versioned event contracts from day one — the biggest mistake in financial event systems is treating the event schema as disposable.

Well-applied event sourcing turns auditing from a painful exercise into a query.