Event Sourcing in Financial Systems: Why Ledger Integrity Depends on It

Traditional CRUD-based systems lose information. When you update a database record, the previous state is gone. In financial systems, this is unacceptable. Regulators require a complete audit trail. Accountants need to know the state of a transaction at any point in time. Dispute resolution requires reconstructing what happened, not just what the current state is.

Event sourcing stores every change to system state as an immutable event. The current state is derived by replaying events. The full history is preserved by definition. For financial systems, event sourcing is not an architectural preference — it is a compliance requirement.

Who Is This Guide For?

This guide is for fintech CTOs, financial system architects, and engineering leads building or migrating financial platforms. If you need immutable audit trails, temporal queries, or regulatory compliance for transaction processing, this is for you.

By the End of This, You’ll Know…

• Why event sourcing is the natural architecture for financial systems
• How to design an event store that satisfies regulatory requirements
• The practical patterns for event replay, projection, and snapshotting
• How to migrate from CRUD to event sourcing without disrupting production

Why Event Sourcing for Financial Systems

Financial systems have three properties that make event sourcing the natural choice:

1. Immutable audit trail: Every transaction is recorded once and never modified. This satisfies SOX, PCI DSS, and Basel III audit requirements.
2. Temporal queries: You can reconstruct the state of any account at any point in time. This is essential for dispute resolution, regulatory reporting, and reconciliation.
3. Eventual consistency: Financial systems are inherently distributed. Event sourcing provides eventual consistency with strong guarantees — every consumer sees every event in order.

In a CRUD system, the audit trail is a side effect. In an event-sourced system, the audit trail is the system.

The Event Store

The event store is the foundation of an event-sourced system. It is an append-only log of every state change in the system.

Event structure:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

{
  "eventId": "uuid-v4",
  "eventType": "PaymentProcessed",
  "aggregateId": "payment-123",
  "aggregateType": "Payment",
  "timestamp": "2024-12-10T14:30:00Z",
  "version": 3,
  "data": {
    "amount": 1500.00,
    "currency": "USD",
    "payer": "account-456",
    "payee": "account-789",
    "reference": "INV-2024-001"
  },
  "metadata": {
    "correlationId": "req-abc",
    "causationId": "event-def",
    "userId": "user-123"
  }
}

Key properties:

• Immutable: Once written, an event is never modified or deleted.
• Ordered: Events are ordered by version number within an aggregate.
• Complete: The event store contains every state change that ever occurred.

Storage options:

• EventStoreDB: Purpose-built event store with strong consistency guarantees
• PostgreSQL: Append-only tables with proper indexing for temporal queries
• DynamoDB: For serverless event sourcing with automatic scaling

Aggregates and Projections

Aggregates

An aggregate is a entity or group of entities that share a common event stream. For financial systems, common aggregates include:

• Account: All events related to a customer account (opens, closes, balance changes)
• Payment: All events related to a single payment (initiated, processed, settled, disputed)
• Order: All events related to a trading order (submitted, filled, partially filled, cancelled)

Aggregate design principle: An aggregate should be small enough to fit in a single event stream but large enough to provide meaningful consistency boundaries. A payment is a good aggregate. An entire account history is too large.

Projections

Projections derive current state from events. The event store is the source of truth. Projections are derived views optimized for specific queries.

Common projections for financial systems:

• Account balance: Derived from all balance-changing events for an account
• Transaction history: Derived from all events for an account, filtered by date range
• Regulatory report: Derived from all events matching specific criteria (e.g., transactions over $10,000)

Projection rebuild: Because projections are derived, they can be rebuilt from events at any time. This is invaluable for fixing bugs, adding new query patterns, or migrating data.

Temporal Queries

Temporal queries ask “what was the state at time X?” In financial systems, this is essential for:

• Dispute resolution: A customer disputes a transaction from 6 months ago. You need to reconstruct the account state at that time.
• Regulatory reporting: A regulator asks for the state of all accounts at quarter-end. You need to project historical state.
• Audit: An auditor wants to trace the lifecycle of a specific transaction. You need to replay the event stream.

Implementation:

1
2
3
4
5
6
7

-- Current balance
SELECT balance FROM account_balances WHERE account_id = 'account-123';

-- Balance at a specific time
SELECT SUM(amount) FROM account_events 
WHERE account_id = 'account-123' 
AND timestamp <= '2024-06-30T23:59:59Z';

Migration Patterns

Strangler Fig Pattern

Gradually replace CRUD components with event-sourced components:

1. Dual write: New events are written to both the event store and the existing database.
2. Shadow read: Existing queries continue to read from the database. New queries read from projections.
3. Migration: Once the event store is proven, switch reads to projections and decommission the database.

Change Data Capture (CDC)

Use CDC to feed events from existing databases into the event store:

• Debezium: Captures database changes as events. Feed these events into your event store.
• AWS DMS: Database Migration Service captures changes and streams them to Kafka or Kinesis.
• Benefit: No changes to existing application code. Events are captured automatically.

What You Can Actually Use Today

• EventStoreDB: Purpose-built event store with strong consistency. Best for new event-sourced systems.
• PostgreSQL: Append-only tables with temporal indexing. Best for organisations with existing PostgreSQL expertise.
• Kafka: Event streaming platform with durable storage. Best for event-driven architectures that need both event sourcing and event streaming.
• Axon Framework: Java framework for event-sourced applications with built-in CQRS support.

FAQ

Is event sourcing overkill for financial systems?

No. Financial systems require immutable audit trails, temporal queries, and complete transaction history. Event sourcing provides all three by definition. CRUD systems require significant additional infrastructure (audit logs, change tracking) to provide the same guarantees.

How does event sourcing handle GDPR right-to-erasure?

GDPR erasure requests require removing personal data. In event-sourced systems, this is handled by encrypting or removing personal data from events while preserving the event structure. The audit trail remains intact without exposing personal information.

What is the performance impact of event sourcing?

Event sourcing is fast for writes (append-only) but can be slow for reads if projections are not properly designed. Snapshotting — periodically materialising aggregate state — reduces read latency from O(n) to O(1) for aggregates with long event histories.

We help financial institutions design and implement event-sourced systems that satisfy regulatory requirements and provide complete audit trails. If you are evaluating event sourcing for your financial platform, get in touch.