01.03 / Money movement
Movement needs a model.
Different rails create different expectations about timing, availability, finality, and failure. The right architecture makes those differences explicit.
The work
The program behind the product.
We design payment flows around the real behavior of the rails and institutions involved. That means understanding when an instruction is sent, when funds move, when status changes, and what happens when the expected path breaks.
What we consider
Where the decisions sit.
Rail selection
Assess ACH, RTP, FedNow, and other available paths against the program’s requirements for timing, reach, and control.
Orchestration
Define initiation, validation, routing, status handling, and the boundaries between internal systems and external partners.
Liquidity and timing
Account for funding requirements, cutoffs, availability, and the difference between initiation and final settlement.
Returns and exceptions
Design for rejects, returns, retries, investigations, and the records needed to resolve them.
System view
A connected flow.
Every handoff has an implication for accountability, timing, and the records you keep.
Explore further
The adjacent systems.
Start a conversation
Let’s make the movement explainable.
Tell us what you are building and where the complexity sits. We can begin with the architecture, the operating model, or the questions still unresolved.