The case for composable banking is now familiar. Break the monolithic core into modular services, select capabilities independently, and make individual components easier to deploy, scale, and replace. Much of that argument is sound. Modular services shorten release cycles, reduce vendor lock-in, and let teams improve one capability without disturbing the rest.

But modularity introduces an architectural decision that matters far more in banking than in most software. Where does authoritative financial state live?

Microservices are usually designed around independent data ownership. Each service holds its own data and manages its own state. That pattern works well when services can tolerate eventual consistency, where different parts of the system are allowed to agree a moment later rather than instantly. It becomes more complicated when a single financial transaction crosses service boundaries.

Consider a transfer that touches a debit service, a fraud check, and a credit service. A debit and its corresponding credit cannot simply become two independently authoritative events that are reconciled after the fact. The bank still needs to know that both belong to the same transaction, that each was validated against the correct balance, and that together they produced one authoritative financial result. When each service owns its own copy of state, the system no longer guarantees that outcome on its own. It reconstructs it afterward, through orchestration that unwinds earlier steps when a later one fails.

This is the distinction between composability and ledger integrity. Services can be independently deployable without making financial state independently authoritative. When balances and transaction state are distributed across multiple systems of record, orchestration and reconciliation are left to restore a consistency the architecture no longer holds in one place. Most of the time that works. The risk lives in the moments it does not, the brief window where a debit has posted, its credit has not, and two services disagree about what is true.

The alternative is not to abandon modularity. It is to keep modular services while giving them a single place to record what actually happened. When modular capabilities operate over one unified financial record, an institution gains:

• One authoritative view of customers, accounts, balances, and transaction state
• Services and products that can evolve independently without fragmenting that record
• Reconciliation handled as an exception rather than a routine repair
• Consistent, current data for compliance, reporting, and AI, drawn from a single source

UniFi is built around this separation of concerns. Modular capabilities operate over a unified financial record, so services and products can evolve freely while the authoritative state of customers, accounts, balances, and transactions stays in one place.

A bank can compose its capabilities across as many services as it likes. It still needs one authoritative place to determine what happened financially.

‍