The Operator Portal
The second product customers never see — RockWallet 2.0's internal portal for Compliance, Fraud, and Payments operators, treated as a first-class product, not a backstage tool.
The second product customers never see
Every customer-facing fintech has a second product that customers never see. RockWallet's is the Operator Portal — the internal web app that Compliance, Payments, Fraud, and Customer Success operators use to investigate accounts, adjust limits, enable or disable features, trace transactions across vendors, and act on the alerts that drive day-to-day operations. It is the connective tissue between Sardine flags, SumSub verifications, Spreedly transactions, Cybrid orchestration, and the user-facing wallet.
RW 1.0 had an Operator Portal that worked the way operator tooling usually works in a young company: built incrementally, optimised for whoever shouted loudest, slow at scale, and inconsistent enough that operators kept private spreadsheets to compensate. The 2.0 rebuild gave us the opportunity to ship a clean, scalable, role-aware operator surface alongside the consumer redesign.
Bad operator tools are invisible, and they cost everything
Operator tools are usually designed badly — and the cost of that bad design is invisible to the customer but enormous to the company. An operator who needs ninety seconds instead of fifteen to resolve a chargeback investigation, multiplied by a thousand investigations a month, is six person-weeks of lost productivity a year. Bad operator tools also produce bad customer outcomes: a flag investigated slowly is a customer locked out longer; a limit changed without an audit trail is a compliance gap.
For RW 2.0 the specific problem was four-fold: (1) the 1.0 portal couldn't scale to the data volumes 2.0 would produce; (2) RW 2.0 architecturally changed the data model (Trade ID instead of separate Trade/Transaction IDs), so the portal couldn't be lifted-and-shifted; (3) we were adding new vendors (Spreedly, SumSub replacing Veriff) whose data needed first-class portal surfaces; (4) Compliance and the regulator both required granular, immutable audit trails on every operator action that touched a customer account.
The first artefact wasn't a wireframe — it was a journey map of the three highest-volume operator workflows: investigate a flagged transaction, resolve a KYC escalation, adjust a customer's limits or feature enablement. Each of those crosses multiple tabs in the portal. Designing around the tabs makes the portal feel like a database browser; designing around the workflow makes it feel like a tool. The journey maps drove the customer detail page layout and the cross-tab filtering model.
Tab + widget composition. Six primary tabs (Customers, Buy/Sell, Trades, Send/Receive, Spreads, Swap) and a customer detail page composed of widgets: Verification, Limits, Feature Enablement, Audit Trail, Wallet Address, Payment Methods, Geolocation. The widget model came directly from the consumer wallet's home screen — same architectural primitive, different content. One composition system serving two products, and operators get the same mental model as customers: a person made of widgets, each widget owns a slice of state, each widget has consistent actions.
Every operator action that mutates customer state — enable/disable Buy ACH, Buy Card, Sell, Swap, limit changes, payment validation, liveness toggles, geolocation overrides — fires an audit event with reason, actor, timestamp, and pre/post values. I designed the audit drawer as a reverse-chronological card list with the reason inline, not buried — partly because Compliance needs that for regulatory defence, partly because operators learn from each other's reasoning.
Feature Enablement Widget as the operator's escape valve. When something goes wrong with a customer — a chargeback, a fraud flag, a region mismatch — the first thing an operator needs is the ability to disable specific transaction types surgically, not nuclear-option freeze the whole account. Per-feature toggles (Buy ACH, Buy Card, Sell, Swap, Send, Receive) wired to the same rules engine the consumer app reads from. Geo-restrictions display "Location Restricted" instead of toggles when the user's region drives the block — prevents operators from accidentally overriding a regulatory rule.
Key decisions
- Widget composition shared with the consumer app's home screen. Same architectural primitive. Trade-off: more upfront design-system work; payoff: one composition system serving two products.
- Audit trail as a designed subsystem, not a log. Every mutating action emits an event; every event has a reason; every reason is visible to the next operator. Compliance defensibility plus operator-to-operator knowledge transfer.
- Per-feature disable, not per-account. Granularity > nuclear option. More state to manage; dramatically better customer outcomes during investigations.
- Geo-restrictions display as "Location Restricted" rather than togglable. Operators can't accidentally override a regulatory rule. Less flexibility; zero Compliance incidents from accidental overrides.
- Vendor data as first-class widgets. SumSub risk in Verification, Sardine risk in trade rows, Spreedly token + gateway transaction IDs as searchable columns. The Gateway Transaction ID column alone closed a real reconciliation gap operators had been working around manually.
- Keep the IA broadly similar to 1.0. Reduces retraining cost. Doesn't fix every 1.0 IA wart; gives the operator team a soft landing.
- MVP ships without SSO, Liveness, ACH Linking, Geolocation Override. Hard call. Documented exactly what's not in MVP so operators wouldn't assume parity. Each on the roadmap.
Operator Portal MVP, in numbers
Surfaces operators actually use
Reflection — a sprint of copy would have saved a quarter of bugs
What I'd do differently: invest a sprint on copy quality before launch. The post-launch bug list is dominated by Title Case → sentence-case fixes, "Trade Id" → "Trade ID", label disagreements between tabs. None of those are individually catastrophic; collectively they signal a hurried final week. A dedicated copy pass with the operator team would have eliminated 80% of those tickets pre-launch.
What I underestimated: how much the absence of features matters to operator UX. The "will not be able to" list at launch — Liveness, ACH Linking, Geolocation Override, Customer Payment Method management, SSO — is where operators feel the MVP-ness most acutely. Designing the "this is coming, here's the workaround" surface inside the portal would have been a smaller investment than the support load those gaps produce. That's a pattern I'd reapply on the next MVP I ship.
What I wouldn't change: treating the Operator Portal as a first-class product, not as a backstage tool. The widget composition, the audit-trail design, the vendor-data integration as widgets — these are not where most companies invest design time on internal tools, and the leverage is real. Every minute saved per operator investigation is a minute of customer trust preserved.