Ripple’s initial stablecoin strategy was split between a white-label SaaS platform and a branded token (RLUSD), lacking a clear operational path for either. I led a Design Due Diligence initiative, prototyping both operational models to stress-test their viability. This evidence-based process drove a critical strategic sequencing decision: prioritizing the immediate launch of RLUSD to capture market share, while documenting the complex multi-tenant requirements that now serve as the foundational blueprint for our upcoming white-label product initiative.
A 6-week discovery sprint mapping minting, redemption, distribution, and compliance workflows across Treasury, Financial Services, and Operations teams.
Two operational models — Stablecoin-as-a-Service and Ripple-branded stablecoin (RLUSD) — to evaluate real-world feasibility and regulatory readiness.
A weighted strategy matrix aligning operational, compliance, and go-to-market trade-offs, enabling executive leadership to pivot product direction with confidence.
Enter password to view full case study
Access to the full design process is restricted to comply with NDA requirements. Please email contact@bryanshi.com to request an access key.
Revealing the human gaps in stablecoin operations
The PRD described a fully automated system — one where minting, distribution, and redemption happened seamlessly across chains. But it never mentioned a user. To uncover what was missing, I launched a 10-day discovery sprint and interviewed six domain leads across payments operations, financial services, treasury, and compliance.
Stablecoins don’t operate themselves — and a stablecoin with no users is a stablecoin no one can operate.
The gaps were immediate and consistent: onboarding spanned legal, technical, and finance teams with no single source of truth. Minting and redemption required coordination across internal accounts, external wallets, and multiple systems—spanning both TradFi and DeFi infrastructure. Collateral visibility was unclear. Compliance workflows were bolted on, not built in.
Competitor analysis confirmed the pattern: while stablecoin transactions are executed via APIs, they still require human oversight—especially under regulatory scrutiny or during transaction failures. Other platforms had similar blind spots, but we had a unique opportunity to design for operational reality.
:: Stablecoin Operations Map showing TradFi & DeFi roles across mint/distribute/redeem.
Mapping fragmented processes and missing visibility
What emerged from the interviews wasn’t just a list of pain points, but a fundamental disconnect between the product vision and operational reality. Minting, redemption, and distribution weren’t seamless or automated — they were fragmented, manual, and spanned a maze of internal departments, tools, and platforms across both traditional finance (TradFi) and decentralized finance (DeFi).
Everyone talked about issuing stablecoins — no one talked about how.
Operators stitched together workflows with spreadsheets, Jira tickets, emails, and Slack — without a central interface or shared operational model.
Even more concerning: while collateral ratios are supposed to guarantee 1:1 backing, no one had a live, trustworthy way to see them. Maintaining the peg depended on visibility — but visibility didn’t exist.
And behind it all, cash management of the reserve fund lived in its own silo. Treasury teams had no central dashboard to monitor flows, exposures, or fund allocations — let alone act on them in real time.
These weren’t just UX gaps — they were structural risks that could block launch readiness or trigger regulatory intervention.
:: Workflow Fragmentation Diagram with ops, treasury, compliance handoffs.
Framing the decision: comparing real operational trade-offs
With clarity on the operational gaps, the next challenge was evaluating which product model—white-label or Ripple-branded—could meet real-world needs most effectively. The product team had already proposed two business directions: a white-labeled Stablecoin-as-a-Service platform, and a Ripple-branded stablecoin (RLUSD). What was missing was clarity on how each option would perform in the real world—specifically, how operations, compliance, and treasury teams would run them day to day.
To move beyond abstract debate, I proposed building two side-by-side prototypes to simulate real operational workflows under each model: onboarding, minting, redemption, reserve management, and compliance oversight. Each prototype would reflect the constraints, roles, and friction points of its business model.
To ensure we were comparing apples to apples, I worked with product and legal leads to align the scenarios across both directions. I also defined evaluation criteria based on three pillars: operational feasibility, regulatory clarity, and implementation complexity. The goal was to surface the operational trade-offs—through experience, not assumption.
We didn’t debate features — we simulated operations.
Treating prototypes as strategic tools — not just UX assets — shifted the conversation from hypotheticals to operational reality.
Clarifying trade-offs via the strategy matrix
With both prototypes scoped, we needed a decision framework rooted in operational realities, not just visual polish. The debate wasn’t about which idea was better, but which was operationally viable right now.
I collaborated with Legal, Compliance, and Engineering leads to create a weighted Strategy Matrix, scoring both models against our critical go-to-market constraints:
- Operational Feasibility (40%): Can our current Ops and Treasury teams manage this day-to-day without new headcount?
- Regulatory Readiness (40%): How much legal surface area does this introduce? Is the governance model clear enough for near-term license approval?
- Implementation Complexity (20%): How quickly can we realistically ship a secure pilot?
Each direction was scored from 0–3 on each criterion, then weighted to reflect strategic priorities (operability and regulatory clarity mattered most at this stage). Here’s how the scores played out:
| Evaluation Criteria | Weight(0-1) | White-label(0-3) | Branded(0-3) |
|---|---|---|---|
| Operational Feasibility | 0.4 | 1.5 | 2.5 |
| Regulatory Readiness | 0.4 | 1.0 | 2.0 |
| Implementation Complexity | 0.2 | 2.5 | 2.0 |
| Weighted Score | - | 0.52 | 0.78 |
While the white-label model offered long-term flexibility, it scored significantly lower on regulatory readiness due to the complexity of multi-tenant governance. RLUSD, by contrast, offered a constrained but high-confidence path to market.
- White-Label: High operational overhead, unclear governance (Riskier for Phase 1).
- RLUSD: Streamlined ops, clear regulatory path (Optimal for Phase 1).
This matrix transformed a subjective debate into a clear strategic sequence: we would execute RLUSD now to secure the market, and defer the white-label platform until our operational infrastructure matured.
Simulating both futures to drive a confident decision
Both prototypes represented the same operational flows—one through the lens of a white-labeled platform, the other through a Ripple-branded RLUSD experience. To help the team make a grounded product decision, I built two clickable prototypes side by side—one for each proposed direction.
- Prototype A simulated the white-labeled Stablecoin-as-a-Service console: a 45-screen flow covering business onboarding, multi-chain minting, role-based permissions, peg monitoring, and crisis controls.
- Prototype B, the RLUSD version, was a focused 15-screen subset with Ripple branding and simplified flows designed around a single stablecoin and more centralized control.
Each walked through core flows—minting, redemption, role assignment, and peg monitoring—to compare how the models felt in practice. This kept the comparison controlled — same scenarios, different business models.
To validate the experience, we ran moderated user tests with external participants recruited via a third-party platform. We recruited both product buyers (CEOs, CTOs) and operational users (Financial Services, Treasury, Compliance, FinOps leads) to mirror real-world personas.
RLUSD just feels ready. We could run this tomorrow.
Participants consistently cited the RLUSD version as more actionable, focused, and operationally trustworthy. The white-label version raised more questions about customization, governance, and rollout sequencing.
I synthesized the findings into a report and shared it with product leadership and key cross-functional leads. With a clear preference from both buyers and operators, and a validated path to execution, the team formally aligned on the branded-stablecoin direction.
:: UI comparison mockups — one white-label screen, one RLUSD screen — side-by-side on the same flow.
De-risking Execution & Architecting the Future
Prototyping operational futures didn’t just answer a design question; it protected the company’s roadmap and created assets for both the present and the future.
- De-risking Market Entry: By exposing the hidden operational overhead of the white-label model (Governance, Compliance, Customization) before code was written, my prototypes gave leadership the confidence to pivot. We aligned on launching RLUSD first, simplifying the operational footprint to accelerate time-to-market by two quarters.
- Operationalizing Internal Tooling: The RLUSD prototype was immediately operationalized. Product and engineering teams repurposed the designs to build the live RLUSD Treasury & Ops Platform, enabling teams to manage minting, redemption, and reserve tracking from Day 1.
- The Blueprint for 2026: Crucially, the “shelved” white-label prototype served as a long-term strategic asset. By mapping the full complexity of multi-tenant issuance in 2024, we effectively wrote the architectural specification for the future. As Ripple re-evaluates the White-Label stablecoin product in 2026, this comprehensive operational map is now the baseline for our new product requirements, saving months of discovery time.
:: Internal tooling dashboard or annotated UI reused from prototype.