FINTECH · SECURITY UX
Designing MFA for a pension app
Designed Multi-Factor Authentication that unlocked a Big Tech contract — then rolled out across all users, with a mandatory variant for select client companies.
CONTEXT
The product
- CompanyOnze
- IndustryFintech • Private pension
- ProductOnze app
- UsersEmployees accessing their corporate pension benefits
- StakesMFA was a non-negotiable contract requirement from a Big Tech client. The team scoped it not just to close the deal, but to raise security standards across the entire user base.
- Role
- Senior Product Designer
- Team
- Security Tech • Engineering • QA • Product
- Scope
- MFA Enrollment + Validation
- Year
- 2025
THE PROBLEM
Why MFA had to ship — under tough constraints
A Big Tech client made Multi-Factor Authentication a non-negotiable requirement to sign a contract with Onze. The feature had to ship — but within hard technical and time constraints that shaped every design decision.
01
Onze contract on the line
MFA was the gating condition on a major Big Tech contract — missing the requirement meant losing the deal.
02
Tight technical constraints
No external partners could be hired. Only validations already built into the app could be used. The solution had to fit within minimal engineering capacity.
03
No user testing window
Speed-to-market eliminated traditional user research — design needed alternative validation strategies that didn't compromise quality.
BUSINESS SIGNAL
MFA wasn't just security UX — it was the gating condition on a Big Tech contract. The design had to satisfy an external client's bar, the team's roadmap, and a tight engineering envelope at once.
MY CONTRIBUTION
What I owned end-to-end
I designed the MFA enrollment and login validation flows for the Onze app — leveraging the existing Design System to minimize engineering effort and ship within scope
I led requirement-gathering meetings with the Security Tech team to identify which security characteristics were non-negotiable, translating their constraints into clear design decisions
I iterated the design across the team's QA validation cycles run by Q.A. and through the restricted-cohort rollout — refining flows based on findings before full launch
I shaped the V1 scope — phone, email, biometrics, trusted device — as the simplest viable security baseline that satisfied Security Tech team requirements while minimizing engineering effort
PROCESS
How I got there
W 1–4
Research & Alignment
W 5–10
Design & Validation
W 11–16
Build & Hardening
RESEARCH ARTIFACT
Market benchmark of MFA flows — confirming that established patterns offered the strongest path under our time constraint.
SOLUTION
A layered factor model balancing protection and friction
| FACTOR | TYPE | ROLE IN THE SYSTEM | STATUS |
|---|---|---|---|
| Phone + Email | Primary | Default validators for MFA enrollment and login. Industry-standard, recoverable. | V1 — Live |
| Biometrics | Inherent (per AWS) | Strong protection that lets users skip MFA validation when registered — reduces friction without compromising security. | V1 — Live |
| Trusted device | Contextual | Once a device is marked as trusted, MFA validation is skipped for a defined period — calibrated for an app that isn't used daily. | V1 — Live |
| 4-digit PIN | Knowledge | Targeted at sensitive operations like fund withdrawals, where the surface is most likely to be attacked. | V2 — Planned |
ENROLLMENT
MFA enrollment flow
VALIDATION
MFA validation during login
OUTCOME
What shipped — and what it unlocked
FINTECH CONTRACT
1
Big Tech client approved the implementation and signed the contract with Onze
USER REACH
All
MFA available across the entire user base post-rollout
BEFORE
No multi-factor authentication in the app
Couldn't satisfy Fintech-grade security requirements
Big Tech contract on hold, dependent on this feature
Account access protected only by CPF + password
AFTER
MFA available to all users — phone, email, biometrics, trusted device
Big Tech contract closed
New mandatory MFA flow live for select client companies
Layered factor model with V2 PIN planned for sensitive ops
LEARNINGS
What this taught me
Strong design decisions sometimes mean replicating, not innovating. MFA is a standardized industry flow — leaning on established patterns and AWS guidelines was the strategic choice given the time constraint, not a fallback. QA cycles run by the team compensated for the absence of user testing on patterns where the broader industry had already done that research.
Error states and security edge cases — like rate-limiting on validation attempts to block brute-force attacks — surfaced during QA testing and Backend observations, not during design. User testing wouldn't have caught them anyway since the behavior was server-side. Next time, I'd stress-test every scenario — both positive and negative paths — as a core design phase, not an afterthought.
Want to dig into the constraint navigation or factor architecture decisions?
Happy to walk through the trade-offs and how I structured validation without user testing.
CONTINUE READING
