Role
Lead Designer
Scope
Self-service flows & platform IA
Team
Product, Engineering, FinOps, OTC desk
Outcome
Self-service remittance shipped · OTC desk no longer a mandatory step
Strategic Context
When the Most Valuable Operations Live Outside the Product
BaaSiC is Transfero's Banking as a Service platform — a crypto and FIAT infrastructure layer that lets companies run banking operations (deposits, withdrawals, OTC exchange, payments, and cross-border remittance) through a single API and a web backoffice.
As the platform matured, more of the day-to-day moved to the web backoffice: finance teams, trade operators, and administrators running real financial operations daily. But some of the highest-value operations — particularly international remittance — still happened outside the product, through manual requests to Transfero's settlement desk over chat.
That worked at low volume. At scale it became a ceiling: every remittance depended on a human at the desk, restricted to business hours, with no self-service path — and regulatory traceability was hard to guarantee for operations that lived in chat threads.
The Challenge
Four Interconnected Problems
The redesign tackled the platform's shift from "API-first with a thin web layer" to a self-service backoffice companies could operate on their own. Working with PM Marcelle Guarisco and the settlement and FinOps teams, four interconnected problems emerged:
01
Operations living outside the product
Cross-border remittance ran on manual desk requests over chat, restricted to business hours. No self-service, no audit trail inside the platform, full dependency on the desk's availability.
02
One interface for very different clients
Companies contract different capabilities — payments, exchange, remittance — but the interface didn't adapt to what each client actually had. Users saw modules they couldn't use.
03
Complex flows, irreversible consequences
A remittance involves currency corridors, beneficiary data that varies by country, balance checks, and authentication. Designed badly, it produces costly, sometimes irreversible errors.
04
Traceability as a requirement
Regulatory pressure meant every operation needed a clear, auditable trail — by design, not reconstructed after the fact from chat history.
All of it had to ship without disrupting clients running live financial workflows.
Design Question
"How might we move high-stakes operations — like cross-border remittance — from manual desk requests into a self-service product, without losing the control, accuracy, and traceability the desk provided?"
Approach
Grounded in How the Platform Is Actually Contracted and Used
I structured the work around two realities: how companies contract the platform, and how the manual operation actually ran day to day.
Modular information architecture. The platform's capabilities map to independent, separately contracted modules — payments, exchange, and remittance. I designed the navigation and dashboard to be driven by two independent filters: which modules a company contracts, and the role of the logged-in user. A company sees only what it owns; a user sees only what their role can act on. No "access denied" walls — absent capabilities simply don't appear.
Mapping the real operation. To bring remittance into the product, the manual desk process had to be understood step by step: what the desk asked clients, which data varied by destination, where errors happened. That manual flow became the blueprint for a guided self-service flow — designed with the people who ran it, since the desk and FinOps knew every edge case the manual process absorbed silently.
AI-assisted discovery. Beneficiary requirements vary enormously by country, each driven by its own foreign-exchange and banking structure. The number of variations was too high to map reliably by hand, so I used AI to structure that matrix: the required fields per corridor and country. The dynamic forms were built on a complete picture instead of the handful of cases we would have caught manually. AI did not design the flow; it made discovery exhaustive.
The Solution
A Platform That Adapts, and an Operation Brought In-Product
The redesigned backoffice renders itself from the company's contracted modules and the user's role — the same codebase serving a company that only does remittance and one that does everything, each scoped to its reality. On top of that adaptive foundation, the flagship new capability: a guided flow that lets companies create an international remittance themselves, replacing the manual desk request while preserving the accuracy the desk guaranteed.
Guided remittance wizard
- Corridor selection — origin, destination, beneficiary type, and the method available for the pair
- Amount in both directions — "amount to send" or "amount to receive," the system calculates the other
- Live quote — what's sent, received, fee, and estimated time, refreshed automatically
- Dynamic beneficiary forms — fields adapt by corridor and country, validated field by field
- A second factor required to create the operation, not to browse or quote
History & receipts
- Full record of every remittance, across all of a company's users
- Management receipt with status timeline and complete operation data
- One-click recreate — reopens the wizard pre-filled and fully editable
- Filters by period and grouped status; CSV export
Shared status vocabulary
- Technical states collapsed into clear statuses companies understand: created, processing, completed, refunded, failed
- Email notifications on the events that matter
- A favorites system to reuse trusted originator + beneficiary pairs, shared across a company's team
- Balance shortfalls guide inline to Top Up or Swap instead of dead-ending
After creation, every company gets an auditable, repeatable record — turning what used to be an untraceable chat request into a first-class product action. The same confirmation, status, and role-aware patterns carry across the platform's other self-service flows — settlements, OTC trades, and approval-gated payouts.
Design Foundations
The Token System That Made the Platform Adaptive
An interface that renders differently for every client — by contracted module and by user role — can't be hand-built screen by screen. It needs a foundation where one component can present in different modes from the same source of truth. I built that on a semantic token system: color, type, spacing, radius, elevation, and motion defined once and composed everywhere.
Color — semantic scales
Indigo primary and aqua secondary, each a full tint-to-shade scale, plus status families. Components reference semantic tokens (accent, surface, border) — never raw hex — so a single change cascades platform-wide.
Type — Montserrat scale
One system, two modes
The same components render in a familiar "banking mode" for traditional finance users and an information-dense mode for crypto-native operators — driven by the client's configuration, not by duplicated screens. New corridors, assets, or modules plug into existing patterns instead of requiring new ones.
AI as a lever
AI was central to converging the visual layer across products into this single system: auditing inconsistencies and unifying components, so screens could be assembled faster and stay consistent as new corridors, assets, and modules came online, which is exactly what a capability-driven interface demands.
Design Decisions
Four Principles That Drove Every Screen
Bring the operation in, hide the complexity
The remittance got simpler for the user even though what happens behind it is intricate. Routing and provider logic stay invisible — the user sees a clear price and a guided path, not the plumbing underneath.
Capability-driven interface
Visibility is a first-class design input. What a company sees is decided by two independent filters: the modules it contracts and the role of the logged-in user. The product never shows something a user cannot act on — absent capabilities simply do not appear.
Prevention over recovery
Validation and confirmation surface before submission, not after. In a flow with irreversible financial consequences, balance checks, inline field validation, and an explicit review step are the design — not safety nets bolted on later.
Traceability by design
Every operation carries an auditable trail as a byproduct of good interaction design. Status timelines, management receipts, and a recreate action turned what used to be an untraceable chat request into a first-class, repeatable product record — directly supporting regulatory requirements.
Outcome
Operations That Lived in Chat, Now First-Class Product Flows
Cross-border remittance moved from a manual, desk-dependent process to a self-service product flow with a full audit trail — directly supporting the platform's regulatory traceability goals. To anchor the design, I defined the launch success criteria for the feature:
> 50% within 60 days
Remittances self-served vs. total
> 80%
Wizard completion rate
− 70% vs. baseline
Manual desk-dependent remittances
< 5 min
Average time to create a remittance
One nuance matters: the desk did not disappear. It kept operating, and the desk team itself adopted the TPN flow for their own transactions, the internal experts who knew every edge case chose the self-service tool over their manual process. The shift was not removing the desk; it was that the desk stopped being a mandatory bottleneck, and self-service became the default path for partners and desk alike.
The deeper shift was conceptual. Operations that lived outside the product — in chat, in a person's availability, with no trail — became first-class, self-service, auditable flows inside it. The modular, role-and-contract-driven architecture and the status and confirmation patterns became reusable foundations for the rest of the platform. And because the interface renders from contracted modules and roles rather than hand-built screens, the product kept expanding with the business: every new network absorbed extended reach to more destination countries at lower cost, without a redesign each time.