Every team touched payments, but no one could see the whole thing.
A payment is never one team's job. Front-line operators submit it, compliance clears it, operations chases settlement, finance reconciles it, and auditors report on it. Through interviews with internal experts and institutional customers, I mapped how these roles interact with a payment across its full operational lifecycle:
- Initiate: front-line operators submit a payment instruction: amount, asset, and recipient.
- Authorize: finance and compliance verify source of funds and assess risk thresholds.
- Transmit: operations teams track progress and resolve settlement errors.
- Reconcile: finance teams match transactions against the internal ledger.
- Report: auditors and analysts generate operational, compliance, and regulatory reports.
The same payment belongs to Finance, Operations, or Treasury at once, depending on who's looking at it.
Every team touched the payment; none had full visibility. Ripple Payments shipped one navigation for all of them, treating these distinct phases as a single linear flow. That was an operational risk, not an inconvenience. It created a black box: support teams could not trace a payment's status, and compliance officers could not find their approval queue.
The deeper fault was a unit-of-design error. We had designed for users, but institutions operate in roles. A role carries its own tasks, permissions, and accountability, and financial auditors enforce that separation as segregation of duties. A flat interface that ignores roles does more than frustrate operators; it works against the controls the business is required to keep.
Front, Middle, and Back Office, rendered on one docking-station shell.
I reorganized the system around how financial institutions are actually structured. The research kept returning the same shape: a front, middle, and back office, with the middle one appearing only where operations had grown complex enough to need it. Grouping by office is not a taxonomy exercise; it maps navigation onto the segregation of duties auditors already require:
- Front Office: payment operations and customer support, who need speed to submit instructions and trace their status.
- Middle Office: compliance and risk, who need maker-checker approval queues and a clear view of what is pending.
- Back Office: treasury and accounting, who need reconciliation, settlement, and reporting.
Three principles held the architecture together:
- Task-first: anchor structure in the end-to-end jobs operators perform, not in the technical objects underneath.
- Role-aware: surface only the tasks a role owns, and only the actions its permissions allow.
- Future-proof: keep the shell modular so new capabilities plug in without re-architecting it.
Build a shell, not a menu tree: new capabilities dock in instead of forcing a rebuild.
The structure is a docking station. Instead of a fixed, product-shaped menu tree, the navigation is a shell into which capabilities dock, surfaced by the operator's context rather than hardcoded into one path. One shell, rendered differently to every operator who opens it.
The tradeoff was deliberate. Dynamic, context-rendered navigation is harder to build and reason about than a single flat menu, but a flat menu shows every operator actions they can never take and buries the ones they need. I bet that rendering to context would pay for its complexity in clarity and in compliance, and that the shell would absorb capabilities the roadmap had not yet named.
It stopped being a payments problem.
Go behind the build for the role-aware system in motion, what changed once operators had it, and the standard it set for the platform.