Designing for the compromised user
CPF Anti-scam products
Jul - sep 2023
When a sudden surge of malware scams compromised Singapore citizens' Singpass credentials in 2023, I was assembled into an emergency task force at CPF Board. We rolled out Singpass Face Verification, 12-hour cooling periods and daily withdrawal limits under immense pressure.
Company
Central Provident Fund Board
Role
Coordinating product designer
Contribution
Cross-functional communication, Design ops, Product design, Product management, Project management, Prototyping, Research
Team
4 product designers (including myself as the coordinator), 1 project manager, 1 product owner, several developer squads, several operations teams, several policy teams, officers from GovTech
Background
In the first half of 2023, Singapore saw a sharp rise in malware-related scams, with over 700 reports and approximately $8 million in losses. Victims were lured into downloading malicious apps onto their mobile devices that could steal credentials and remotely control their devices. This allowed scammers to act on their behalf without their knowledge.
Challenge
Scammers began targeting CPF savings, using stolen Singpass credentials to access CPF e-services and initiate withdrawals. There were at least eight scam cases involving CPF savings between January and June in 2023, with losses amounting to S$124,000.
CPF Board needed to introduce friction into the scammer journey, without compromising the experience for legitimate members. There was massive pressure to do this fast to address public concerns and protect members’ savings as soon as possible. Because this was a sudden crisis, there was no product blueprint, no dedicated product owner initially, and no established systems. We were simply an emergency group of people assembled to figure out how to address this problem.
Strategy
Tasked to be the coordinating designer for our pod of four designers, I worked closely with policy and product to rationalise our strategy. To introduce friction as strategically as possible, we broke our approach down into two distinct parts:
Phase 1 (Month 1): Form Protection. Implementing GovTech’s Singpass Face Verification (SFV) directly onto withdrawal e-services to block scammers from executing outflows of CPF monies.
Phase 2 (Months 2-3): Account Settings Protection. Further bolstering security by implementing SFV and a 12-hour cooling period to delay critical changes to personal settings. Also introducing a daily withdrawal limit and withdrawal lock inspired by standard financial world practices.
I assigned the other three designers as dedicated points of contact for individual flows (e.g. contact detail changes), while I took direct ownership of the daily withdrawal limit flow and acted as the overarching coordinating designer for this entire project.
Execution
Streamlining the core interaction flow
After mapping the journeys for all affected e-services, our first priority was establishing a unified integration pattern for SFV. I aligned the broader team around a critical architectural decision: prioritise a clear intent-to-act signal from the user over bundling all verification steps at the start of a session. This ensured that legitimate members were only prompted for biometric verification at the exact moment they attempted a critical transaction, minimising unnecessary friction during casual browsing.
I mapped out a universal flowchart to standardise exactly where SFV triggers across all e-services, establishing a consistent blueprint.
Orchestrating alignment across fragmented teams
While establishing the core flow was straightforward, the real challenge lay in navigating high technical ambiguity and fragmented team structures under intense time pressure. Because individual account flows were owned by different product owners, I instituted regular cross-pod syncs with our designers. This governance gave me visibility over parallel tracks, enabling me to synthesise insights and enforce unified design patterns across the entire product ecosystem.
To maintain pattern consistency across siloed teams, I established master components and structural section boundaries within our shared Figma files.
Interfacing with systems that were not visible
Because SFV is an external platform owned by GovTech, we could not see its inner workings and had to treat it as a technical “black box.” Working within this constraint, I facilitated discussions to interface their authentication system with our backend infrastructure. Crucially, we mapped out clear UI entry points so users would instantly know whether to contact GovTech or CPF for support if they got stuck.
Visualising the trade-offs of wrapping the third-party GovTech SFV flow within the CPF header and footer to maintain brand trust and user orientation
Thinking through the unhappy flows
My team and I dedicated significant effort to mapping out technical edge cases. Our most critical alignment sessions centered on system resilience: what happens if GovTech’s external system experiences an outage, and how does our backend detect it? I also ran a sanity check across our broader customer service ecosystem to ensure our operational support teams were fully equipped to handle members experiencing this new friction.
We mapped unhappy flows to determine system behaviour during external server outages, ensuring fallback options were always available to members.
Communicating the friction
Because we were deliberately injecting friction, we designed clear signposts notifying users that their actions would require biometric checks or trigger a 12-hour cooling period before execution. Crucially, we optimised background alerts so that if a scammer initiated a change, the legitimate member would instantly receive an external notification.
Mitigating risk from launching without testing
Operating under an emergency timeline meant we could not run traditional user testing. To mitigate this risk, I conducted desk research into established banking and financial sector practices. Our eventual design decisions were informed by studying patterns that Singapore citizens were already familiar with in their daily banking apps, and applying it to our own context.
Benchmarking similar flows such as withdrawal limit adjustments in commercial banking apps to ground our designs in familiar mental models.
Outcome
Phase 1 was fully deployed within an intense 1-month window, followed immediately by the execution and launch of the Phase 2 account services protection suite over the next two months. Since its rollout, this anti-scam suite has remained active in production. Furthermore, a dedicated anti-scam unit has since been established to build upon our pioneering team’s foundational work. This permanent squad continues to roll out advanced security features, allowing members to dynamically customise their level of account protection based on their personal circumstances and preferences.
While specific technical hit rates and business metrics remain confidential, CPF Board has not had any reports of serious scams since these flows were implemented, proving that our strategy successfully fortified the system and has since been protecting members’ retirement savings.
Takeaways
This project was a masterclass in rapid cross-functional coordination during a crisis. Product design within a security and high-stakes environment requires moving quickly to manage ambiguous technical constraints, policy requirements, and fragmented operational moving parts. My impact came from acting as the coordinating glue across siloed product pods, communicating technical constraints and designing blueprints that worked across systems, creating a system that protects our members while not compromising on their experience.