Financial Systems as Composed State Machines: Correctness, Authority, and System Integrity

Financial Systems as Composed State Machines: Correctness, Authority, and System Integrity

# distributedsystems# fintech# systemdesign# backend
Financial Systems as Composed State Machines: Correctness, Authority, and System IntegrityMayckon Giovani

Abstract Modern financial systems are often described in terms of individual components....

Abstract

Modern financial systems are often described in terms of individual components. Ledgers enforce correctness. Custody systems control asset authority. Compliance systems constrain behavior. Orchestration layers coordinate execution.

Each of these components can be designed correctly in isolation.

Yet production failures continue to occur in systems that are individually sound.

This article argues that financial infrastructure must be understood not as a collection of services, but as a composition of interacting state machines. We examine how correctness, authority, and policy enforcement interact across subsystem boundaries, and why system integrity emerges only when these components are composed under strict constraints.

Financial systems do not fail because components are incorrect. They fail because composition is undisciplined.


The illusion of correct systems

It is possible to build a ledger that enforces conservation of value.

It is possible to design custody systems that eliminate single key compromise through threshold cryptography.

It is possible to implement compliance engines that correctly evaluate regulatory constraints.

It is possible to orchestrate transactions across distributed services.

Each of these can be done correctly.

And yet, the system can still fail.

This is the point where most engineering intuition breaks.

Correctness at the component level does not imply correctness at the system level.


From services to state machines

The shift in perspective is subtle but critical.

Financial systems are not services exchanging messages.

They are state machines interacting through transitions.

Each subsystem can be modeled as:

S_i = (State_i, Transition_i)
Enter fullscreen mode Exit fullscreen mode

Where:

  • State_i represents the internal state of subsystem i
  • Transition_i represents the allowed state transitions

For example:

Ledger enforces:

sum(entries(T)) = 0
Enter fullscreen mode Exit fullscreen mode

Custody enforces:

signature(T) requires threshold participation
Enter fullscreen mode Exit fullscreen mode

Compliance enforces:

policy(T, state) = allowed or rejected
Enter fullscreen mode Exit fullscreen mode

Orchestration enforces:

execution(T) follows valid transition sequence
Enter fullscreen mode Exit fullscreen mode

Individually, these systems define local invariants.


Composition defines global behavior

The full financial system can be modeled as:

S = Compose(S_ledger, S_custody, S_compliance, S_orchestration)
Enter fullscreen mode Exit fullscreen mode

The critical property is:

Global correctness != sum of local correctness
Enter fullscreen mode Exit fullscreen mode

Instead:

Global correctness = correctness of composition
Enter fullscreen mode Exit fullscreen mode

This is where failures emerge.

If transitions across subsystems are not properly constrained, global invariants can be violated even when each subsystem behaves correctly.


Boundary violations and implicit coupling

Most real world failures originate at boundaries.

A custody system signs a transaction that was valid at evaluation time but invalid at execution time.

A compliance check passes based on stale state.

An orchestration layer retries an operation without ensuring idempotency across services.

A settlement completes externally but is not reflected internally.

Each subsystem behaves according to its own rules.

The failure occurs in how they interact.

This is not a bug in a component.

It is a failure of composition.


Temporal inconsistency and state divergence

Distributed systems introduce temporal uncertainty.

Different subsystems observe state transitions at different times.

This creates divergence.

A transaction may be:

valid in the ledger
approved by compliance
signed by custody

But still inconsistent globally because these decisions were made against different versions of state.

Without explicit coordination, the system operates on partially ordered events.

Correctness requires more than local validation.

It requires agreement on the context in which validation occurs.


The role of invariants across boundaries

Local invariants are necessary but insufficient.

Systems must enforce cross boundary invariants.

For example:

A transaction must not be signed if it violates compliance constraints at execution time.

A transaction must not be executed if its ledger state has changed since validation.

A transaction must not be retried if it has already been committed externally.

These invariants do not belong to a single subsystem.

They exist across the composition.

This is where most systems are weakest.


Failure is systemic, not local

Failures in financial systems are rarely isolated.

A retry in one service propagates to another.

A delayed message triggers inconsistent decisions.

A partial execution leads to duplicated operations.

The system fails as a whole.

This is why focusing only on component correctness is insufficient.

Engineers must reason about failure propagation across the entire system.


Compositional integrity

A system has compositional integrity when:

  • state boundaries are explicit
  • transitions are constrained across subsystems
  • sequencing is enforced
  • invariants are preserved globally

This requires discipline.

Not just in code, but in architecture.

Interfaces must encode constraints.

Events must carry sufficient context.

Operations must be idempotent across boundaries.

State must be versioned or validated at execution time.

Without these properties, composition becomes fragile.


Observability as proof of composition

One way to evaluate compositional integrity is through observability.

If a system cannot reconstruct the full lifecycle of a transaction across all subsystems, then its composition is not well defined.

Observability provides:

  • traceability across boundaries
  • visibility into sequencing
  • evidence of invariant preservation

It acts as a verification layer for system behavior.


The final model

We can describe a financial system as:

Global State S

Transitions:
  LedgerTransition
  CustodyTransition
  ComplianceTransition
  OrchestrationTransition

System integrity requires:

For all transitions T:
  invariants(S, T) are preserved across composition
Enter fullscreen mode Exit fullscreen mode

This is not enforced by any single component.

It emerges from the architecture.


Conclusion

Financial systems are often engineered as collections of services, each responsible for a specific concern. This perspective is incomplete.

These systems are composed state machines whose correctness depends on the interaction of their components under real world conditions.

Ledger ensures correctness of value.
Custody ensures control of authority.
Compliance ensures validity of behavior.
Orchestration ensures coordination of execution.

But system integrity exists only when these are composed under strict constraints.

Without disciplined composition, even correct components produce incorrect systems.

Financial infrastructure is not defined by its parts.

It is defined by how those parts behave together.