Every payment system accumulates a compliance burden over time: regulators asking for transaction histories at specific timestamps, fraud teams querying what the system believed when a suspicious transaction cleared, audit committees requesting evidence that a reversal happened in the correct sequence. In most banks, these questions are answered by a patchwork of archive tables, audit triggers, and CDC export jobs that were added reactively, one at a time, every time an examiner asked a question the current system couldn’t answer.
Event sourcing is the architecture that answers all of those questions structurally — by design, from day one, without bolt-ons. The event log is the transaction record. The audit trail is the data model. The temporal query (“what did the system know at 14:32:05 on the day the transaction cleared?”) is a replay operation against an immutable sequence, not a forensic reconstruction across three archive schemas.
But this is not a free upgrade. Event sourcing introduces real costs that the architecture team will correctly identify and that leadership needs to weigh honestly: a steeper engineering model, eventual consistency in query results, projection rebuild cycles when the read schema changes, and a growing event store that you are committed to retaining for a decade. The VP’s job is not to know how Axon Framework handles snapshotting — it is to decide whether the compliance benefit justifies those costs for the specific domain in question, and to set the governance conditions that make the pattern sustainable once adopted.
The compliance case
SAMA’s Technology Risk Management framework is explicit: financial institutions must maintain a complete, tamper-evident record of all material transactions, with the ability to reconstruct any transaction state at any point in time, retained for at least ten years. The word “tamper-evident” is where conventional audit log implementations typically fall short. A trigger-based audit trail in a CRUD database is writable by any database administrator with sufficient privilege; a shadow table populated by application code can be bypassed by any process that updates the primary table directly. Neither satisfies the spirit of the requirement, even if both technically produce a log.
An event store implemented as an append-only table — where the application user has INSERT but not UPDATE or DELETE — is structurally tamper-evident at the database layer. Any SAMA examiner can verify the immutability constraint by querying the role privileges directly. This is the kind of evidence that survives a Technology Risk examination without requiring an explanation of your audit log architecture.
Beyond compliance, the fraud team’s use case is equally compelling. Fraud pattern analysis depends heavily on temporal reconstruction: “on this account, what was the velocity of payment initiations in the ten minutes before this fraudulent transaction cleared?” With CRUD, that question requires joining the current transactions table against an audit log, interpreting status transitions from timestamps, and hoping the archive is complete. With event sourcing, it is a replay bounded by a sequence range and a time window — a query pattern that generalises to any forensic question the fraud model needs answered.
The event store does not just record what happened. It records what was decided, and what each decision was based on. That distinction — between recording outcomes and recording the decision sequence — is what separates an audit trail from a transaction log.
What the trade-off looks like to the business
There are three costs that leadership needs to be prepared for, because they will not go away and cannot be engineered around.
The first is write-side complexity. An event-sourced payment system requires engineers who understand the aggregate model, the command/event separation, and the projection pattern. This is not difficult to learn, but it requires deliberate training and a period of reduced velocity while the team internalises the model. Budget three to six months of slower delivery on the first event-sourced service. The velocity recovers as the pattern becomes habitual; it does not recover faster than that.
The second is eventual consistency in the read model. Query results for payment status, account balance, and settlement state are derived from event projections, which update asynchronously. In a well-tuned system, the lag is seconds. But “seconds of lag” means that a customer who initiates a payment and immediately queries their balance may see the pre-payment balance for a brief window. The product team needs to know this and design the UX accordingly — typically a “pending” state that resolves cleanly once the projection catches up. This is solvable at the product level, but it requires the product and engineering conversation to happen early.
The third is storage growth. An append-only event store grows linearly with transaction volume and never shrinks. For a bank processing hundreds of thousands of payments per day, the event store will accumulate hundreds of millions of rows per year. SAMA’s ten-year retention requirement means you are committing to a decade of unbounded growth. This is a budgeted storage commitment, not a technical surprise — it should be in the architecture decision record and in the infrastructure cost model from the outset.
Where to apply it
Event sourcing is the right architecture for domains where audit completeness, temporal queries, or reversibility are hard requirements — and the wrong architecture for domains where none of those apply. The payment ledger and the settlement instruction flow are the clearest candidates in a KSA bank. The account master data service, the product catalogue, and the customer preference store are not — they are better served by CRUD, and introducing event sourcing there adds complexity without adding compliance value.
The decision about which domains get event sourcing should be made at the programme architecture level and documented explicitly. Leaving it to individual teams to decide independently will produce inconsistency: some teams will adopt it for domains that don’t need it; others will avoid it for domains that do. The output of the architecture decision should be a list: these contexts use event sourcing; these do not; here is why.
What the team needs from leadership to ship it
The engineering team adopting event sourcing for the first time needs three things from leadership that are not on the backlog.
First, protected time for the learning curve. The team will not deliver at the same pace as a CRUD service for the first quarter. Leadership needs to absorb that in the schedule, not pressure the team into taking shortcuts — shortcuts in event sourcing typically mean mixing command handlers and state mutations, which breaks the audit trail guarantees that justified the pattern in the first place.
Second, a compliance sponsor. The SAMA audit trail benefit is only realised if the compliance team accepts the event store as evidence. This requires a conversation between engineering and compliance before the service goes to production, not a governance review after the first examiner asks a question the new system can’t answer. The VP needs to facilitate that conversation at programme start.
Third, a clear boundary for the first deployment. The first event-sourced service should be narrow in scope, high in audit value, and not on the critical customer transaction path during the initial delivery period. Payment initiation and status tracking is the right first target: the business value is clear, the audit requirement is unambiguous, and the failure mode (a slow projection) is visible rather than silent. Payment settlement instruction — which involves multi-step coordination with IPS — is a better second service once the pattern is proven.
For the engineering depth behind this pattern — aggregate design, CQRS projection implementation, ISO 20022 event schema, idempotency, SAMA-compliant event store DDL, and Kafka fan-out architecture — see the companion Lab article: Event Sourcing & CQRS in Payments.