Payments Info Architecture.

Mapping the chaos of institutional operations

Through interviews with internal experts and external customers, I investigated how our targeted customers — fintech and crypto-forward companies — actually manage their payment operations.

In fintech ops, the same payment task can sit under Finance, Ops, or Treasury — depending on company size and structure.

These teams weren’t just logging in to track a payment. They were working across complex organizations, switching between tools and juggling responsibilities. To uncover the patterns behind this complexity, I mapped how different roles interact with payments throughout the full transaction lifecycle:

• Initiate: Front-line users submit payment instructions including amount, currency, and recipient.
• Authorize: Finance and compliance teams verify source of funds and assess risk thresholds.
• Transmit: Operations teams track progress and resolve settlement errors.
• Reconcile: Finance teams compare transactions in the UI with internal ledgers.
• Report: Auditors and analysts generate reports for operations, compliance and regulatory insight.

It became clear that every team touched payments, but no one had full visibility. Ripple’s original one-size-fits-all navigation treated these distinct operational phases as a single linear flow. This wasn’t just a UX issue — it was an operational risk, creating a “black box” where client support teams couldn’t track status and compliance teams struggled to find approval queues.

Diagnosing the structural flaw: The Front-Middle-Back gap

Scalable payment ops start by untangling access and aligning navigation to real-world team roles.

To move from scattered insights to action, I diagnosed the root cause: we were designing for “Users,” but institutions operate in “Roles.”

I facilitated cross-functional workshops to restructure our understanding of the problem using the industry-standard Front-Middle-Back Office model. This wasn’t just about grouping features; it was about aligning with the Segregation of Duties (SoD) required by financial auditors:

• Front Office (Initiate): Sales & Support need speed and ease for creating payment instructions.
• Middle Office (Control): Compliance & Risk need visibility into “Maker-Checker” approval workflows.
• Back Office (Record): Treasury & Accounting need distinct access for reconciliation and reporting.

Mapping real operational roles exposed critical UI gaps: misaligned task ownership, poor personalization, and unclear responsibilities. One participant summed it up well:

We struggle to complete operational tasks due to unclear task ownership and fragmented data access.

These findings shaped two priority design challenges:

• Role-Based Context: Users across departments had conflicting goals. Some needed a high-level view of flows, while others required deep access to audit trails.
• Permission-Aware Navigation: Access controls varied, but the legacy UI presented the same “flat” menu to everyone, surfacing actions users could not take.

By grounding the IA in these priorities, the solution became clear: we didn’t need a better menu; we needed a role-based architecture that enforced operational clarity and compliance by design.

Setting IA principles: Task first, role aware, environment smart

Led cross-functional working sessions with Product, Engineering, Operations, and Treasury to reimagine Payments IA — not just reorganizing screens, but crafting a strategic framework for evolving workflows, complex permissions, and seamless cross-team collaboration.

From these discussions, we aligned on a core question:

How might we structure information so that users can focus on their tasks, navigate with context, and collaborate across roles without friction?

Three strategic principles emerged as foundational:

Task-first. Role-aware. Future-proof. Payments IA reimagined for real operations.

• Task-Oriented Organization: Rather than mirroring technical systems or product silos, the IA would reflect how users actually complete their work. This meant anchoring structure in end-to-end tasks like payment tracking, reconciliation, and reporting, tailored to role-specific responsibilities.
• Scalability and Adaptability: The architecture needed to support emerging workflows, and accommodate future expansion. This required a modular structure that could evolve without rework, whether users were in a growing fintech startup or a global payments team.
• Contextual Access and Guidance: With so many roles interacting with the same records in different ways, access to information had to be contextual. The structure would support layered visibility and progressive disclosure, ensuring users see what’s relevant to them without overwhelming complexity.

These principles became the foundation for a scalable, role-aware architecture that mirrors real-world operations. Building on them, we identified solution patterns to support task focus, contextual navigation, and cross-team collaboration within a unified framework.

Docking station architecture for operational scale

We moved away from a rigid, product-based structure to a flexible, role-centric architecture. This new framework acts as a docking station, where features are surfaced based on the user’s operational role rather than hardcoded navigation trees.

• Role-Aligned Context: Instead of showing static menus, the navigation dynamically adjusts. A Compliance Officer sees “Pending Approval” while a Treasury Manager sees “Reconciliation & Reports” This reduces cognitive load and enforces segregation of duties naturally.
• Task-Centric Workflows: We re-anchored navigation around end-to-end jobs (e.g., “Close a Month” or “Approve Batch”) rather than technical objects, cutting friction for high-volume operations.
• Operational Scalability: By decoupling the navigation shell from specific product lines, we created a modular system. This ensures that as Ripple adds new operational capabilities — whether built internally or integrated later — they can plug directly into the relevant Role View (Front, Middle, or Back Office) without breaking the core architecture.

Co-authoring the unified navigation 1.0

With the IA vision finalized, I partnered with multiple product managers across feature domains to co-author the initial scope of a unified, scalable navigation. We aligned on feature structure, entry points, and role-specific access across environments.

I delivered detailed design and specifications that outline structural patterns, task flows, and permission logic. Throughout development, I partnered with engineering to plan the rollout, clarify design intent, and support edge case handling during implementation.

Early usage cuts clicks in half for AP specialists

After beta rollout, I led internal walkthroughs with Customer Success, Finance, and Implementation teams to validate task flows and surface operational gaps. We focused on validating navigation efficiency and relevance across daily operational use.

We cut clicks, streamlined flows, and realigned Payments navigation around how ops teams truly work.

• Task Efficiency Gains: Accounts payable teams reduced friction in accessing core workflows, cutting the average number of clicks per task nearly in half.
• Improved Workflow Clarity: Customer-facing teams could now trace full payment lifecycles without switching tools or surfacing irrelevant data.
• Increased Role Alignment: Personalized dashboards and permission-aware navigation helped users stay focused on tasks that matched their responsibilities.

Based on these findings, I refined layouts, adjusted navigation groupings, and improved contextual entry points to better support day-to-day use. These fast, feedback-driven iterations helped evolve the MVP from a high-level IA concept into a practical system that flexes to real-world operational needs.

From usability fix to ecosystem blueprint

Redefining the Payments IA did more than improve usability metrics; it reshaped our product roadmap and established the architectural logic for Ripple’s future.

• Roadmap Acceleration: The role-based clarity elevated Beneficiary Management and Reconciliation from API-only tasks to core UI priorities, unlocking dedicated engineering squads to build critical post-transaction workflows.
• Operational Efficiency: The Settings Hub consolidated fragmented administration tasks into a centralized control center, significantly reducing support tickets for onboarding and configuration.
• The “One Ripple” Mandate: Most critically, this project proved that organizing architecture by Operational Role (Front/Middle/Back Office) — rather than product silos—is the only way to scale institutional workflows.

The success of this methodology served as the proof point for my 2026 mandate: to apply this same operational mindset to unify Ripple’s entire portfolio (including newly acquired capabilities) into a single Operator Command Center.