Role
Lead Product Designer
Duration
6 months
Team
Product, Engineering, Compliance, Key Clients
Outcome
MFA live · Login errors reduced · Compliance reinforced
Strategic Context
A Platform Built for APIs, Now Handling Real-World Risk
BaaSiC is Transfero's Banking as a Service platform — a crypto and FIAT infrastructure layer that enables financial institutions to offer blockchain-based financial services through a single API. In its early stages, most clients interacted with BaaSiC exclusively via API. The web platform was secondary.
As the product matured, that changed. Finance teams, operations staff, and client administrators began accessing the web platform daily to execute settlements, manage payments, and control API access. What was tolerable for a handful of technical users became a liability at scale: there was no second authentication factor, sensitive flows had no confirmation layer, and Secret Keys — the credentials that authorize API transactions — were still being managed manually by Transfero's team.
A compromised account could execute financial transactions with no additional verification. The risk wasn't theoretical.
The Challenge
Three Interconnected Security Problems
Working closely with PM Marcelle Guarisco, I mapped vulnerabilities through heuristic analysis and stakeholder interviews with internal users, key clients, and Engineering. Three interconnected problems emerged — different in nature but compounding each other:
01
No second authentication factor
Sensitive operations — Global Settlement, New Payments, and Secret Key generation — had no MFA gate. A single compromised password was enough to execute irreversible financial transactions.
02
Secret Keys managed manually
API Secret Keys were generated and delivered via One-Time Password by Transfero's team. Clients couldn't rotate or reset their own keys — every change required a manual request, creating operational dependency and a security gap in the handoff process.
03
A binary permission model that didn't reflect reality
The platform had only two roles: admin and viewer. Client companies operate with finance teams, traders, customer support, and account managers — each needing different access. The binary model forced clients to grant admin access broadly, creating systemic over-privilege and inconsistent experiences across roles.
04
No alignment ritual before production
There was no structured channel for internal teams to test and send feedback before a feature went live. Changes shipped to production without validation — creating friction, avoidable support requests, and eroding trust in the release process.
All of this had to ship without halting live operations. BaaSiC clients were running active financial workflows — any redesign had to be incremental and verifiable in a staging environment before going to production.
Design Question
"How might we add a meaningful security layer to BaaSiC's most sensitive flows without disrupting the operational pace of finance and integration teams?"
Approach
Parallel Workstreams, Grounded in Stakeholder Research
I structured the work into three parallel design tracks — MFA, Secret Key self-service, and User Role Architecture — each requiring different research approaches before any design decisions could be made.
For authentication and Secret Keys, I started with a heuristic analysis of the existing platform, then ran stakeholder interviews with internal users (finance, operations, support) and engineering — mapping which security constraints were hard requirements and which were negotiable UX decisions.
For User Profiles, the research went deeper. I needed to understand not just the technical permission model but the real operational roles inside client companies. Interviews with Transfero's own CS and support teams revealed how they used the platform daily. Conversations with client stakeholders — finance managers, operations desk professionals, and customer success teams — surfaced the gap: real workflows required at least five distinct access levels, and the binary admin/viewer model was pushing clients toward over-privileged configurations just to get their work done.
In parallel, I partnered with Marcelle Guarisco to establish a pre-production alignment ritual: a recurring meeting before each major release where all teams could test in the STG environment and send feedback before anything reached production. This became BaaSiC's first structured release communication channel.
The Solution
Three Deliverables, One Principle
The initiative shipped three interconnected pieces, unified by a single principle: security should feel like clarity, not friction.
2FA via Authenticator
- TOTP-based MFA (Google Authenticator / Authy) applied to Global Settlement, New Payments, and Secret Key flows
- QR code setup on first activation — shared OTP secret key synced between device and server
- Time-based 6-digit codes expire every 30 seconds, validated server-side
- Redesigned login with inline error states and explicit session handling
Self-Service Secret Keys
- Clients can generate up to 2 Secret Keys directly on the platform — no manual Transfero request required
- Expiration date visible for each key, enabling proactive rotation
- Reset capability: resetting a key automatically expires the previous one
- Access restricted to Master users only; 2FA required to enter the API Keys section
- Keys never shown in full after generation — only partial fragments displayed to prevent exposure
Release Alignment Process
- Pre-production meetings before each major release, giving internal teams access to test in STG
- Open feedback channel to Marcelle and Julia before anything shipped to production
- Meetings recorded and summarized by email for all stakeholders
- Roadmap previewed at each session: New Login flow, GA analytics via GTM, OTC modularization
Role Architecture
Designing for Real Operational Complexity
The permission model redesign started with a simple question: what do people actually need to do in this platform? The answer revealed that client companies don't have two types of users — they have finance professionals executing payins and payouts, operations desk professionals running OTC trades, customer success teams resolving transaction issues, and account owners managing API access. None of that mapped to admin or viewer.
The result was a system of five predefined roles with fixed permissions in V1, each grounded in a real job function rather than a technical abstraction. The interface adapts to each role — users see only what they can act on.
Administrator
Account owners & technical managers
Full platform access. The only role that can generate API Keys and manage users. Each account requires at least one. Applies to all client types.
Finance
Finance professionals
Advanced permissions without full admin access. Can execute payins, payouts, CSV reports, and payments across all client types.
Trader
Operations desk — OTC only
Scoped to OTC operations. Direct access to the trade dashboard and trade history. Blocked from financial flows and user management.
Support
Customer Success & support teams — Payments only
Problem resolution toolset: verify transaction status, identify issues, generate receipts, process refunds. No access to financial operations.
Viewer
Read-only access — all client types
View-only permissions for users who need visibility without operational access. Applies across Payments, OTC, and Checkout.
The permission matrix — mapping 17 features across 5 roles — was a core design artifact. It made explicit what had been implicit: which actions carry financial risk, which require compliance visibility, and where the privilege boundaries should be. Critically, User Management and API Key Generation were restricted to Administrator only, closing the over-privilege loop that had made the previous model insecure.
One deliberate sequencing decision: user management was shipped in two phases. The first release established the role architecture and permission model — getting the foundations right before adding self-service complexity. The second phase, shipped shortly after, delivered the full user management interface directly in BaaSiC, allowing administrators to add, modify, and remove users from the platform without involving Transfero's team.
Design Decisions
Four Principles That Drove Every Screen
Security as UX layer
MFA was designed to feel native to the product: a two-step flow with TOTP code verification, not a security wall bolted onto an existing interface. Users scan a QR code once; after that, the Authenticator App generates a time-based code that expires every 30 seconds.
Prevention over recovery
Validation and confirmation screens surface before submission, not after. In Global Settlement and New Payments flows, errors have irreversible financial consequences. Catching them at the confirmation step is the design.
Partial exposure by design
Secret Keys are never shown in full after generation — only partial fragments are displayed. This protects against screen recording, shoulder surfing, and accidental leaks without blocking legitimate use.
Audit by design
Every payin and payout step has a confirmation screen with a clear status indicator. Auditability isn't a compliance add-on. It's the interaction pattern itself, carried forward into BaaSiC's design system.
Outcome
Security Is a UX Asset.
MFA closed the most critical authentication gap — sensitive operations like Global Settlement and New Payments now require a time-based second factor before execution. Secret Key management moved from a manual, Transfero-dependent process to a self-service flow that clients control directly, with access scoped to Master users and protected by 2FA.
The pre-production alignment meetings — the first structured release ritual at BaaSiC — created a feedback loop that hadn't existed before. Teams could test in staging, surface issues early, and arrive at production with confidence. This wasn't just a process improvement; it changed how product and internal teams related to each release.
The deeper shift was conceptual. Going in, the assumption was that security and usability were in tension — that adding protection meant adding friction. The delivered product showed the opposite: when security is designed as a UX layer rather than a compliance checkbox, it reduces errors, builds institutional trust, and makes audit-readiness a natural byproduct of good interaction design. The patterns from this project — confirmation screens, status vocabulary, role-based visibility, partial key exposure — became part of BaaSiC's design system and carried forward into subsequent platform work.