To strengthen fraud prevention across omnichannel touchpoints, I proposed and led the design of a new internal platform for frontline employees to report and check fraud cases. Through API integration, the system triggers cross-channel alerts and transaction governance, significantly improving the company's ability to protect clients at every point of interaction.
This platform has been successfully launched within the company. 🎉
My role
Product Manager &
Service Designer
Company
Cathay Life Insurance, Customer Support Branch Development Team
Deliverable
Product Requirement Document
User Flow
High-Fidelity Prototype
Test Cases
Duration
Feb. 2025 - May. 2025
⚠️ Note: This project is under a Non-Disclosure Agreement (NDA). While I am unable to share specific details or final designs, I will demonstrate how I identified the problem, as well as my design process and decision-making.
01 - Background
As scams became increasingly prevalent in Taiwan, insurance services were exploited as a money-transfer channel. Scammers usually contact victims through social media or messaging platforms, using investment or romance scams to manipulate clients into initiating insurance transactions, such as policy surrenders or high-value policy loans. Although these transactions are technically valid, they are carried out under deception and ultimately enable funds to be transferred to scammers.
To mitigate this risk, frontline employees at physical service counters conduct detailed screening and interviews to assess clients' transaction intent. When fraud is suspected, transactions are declined to protect clients. Through these interventions, the company prevents over USD 3 million in customer asset losses each year.
02 - Problem
📊 What I Discovered
While analyzing fraud cases, I noticed an unusual pattern: after transactions were declined at physical counters due to suspected fraud, some clients completed the same risky transactions shortly afterward through self-service online channels. The timing and repetition strongly suggested continued manipulation by fraudsters.
🔍 Why This Happened
This critical gap occurred because fraud signals were not shared across offline and online touchpoints, leaving online channels unaware of clients’ prior risk.
03 - Solution Concept Preview
1️⃣ Frontline Employee Identify At-Risk Clients & Report through Platform
At physical service counters, frontline employees assess clients’ transaction requests and identify potential scam risks through direct interaction. When a high-risk case is identified, the employee declines the transaction as usual. However, a new step is introduced: frontline employees enter the case into the Fraud Protection Platform and submit.
This allows the client’s protection status to be shared across all service channels, enabling coordinated follow-up and preventing repeated high-risk transactions.
2️⃣ Online Transactions Are Automatically Blocked for At-Risk Clients
When a client attempts to complete the transaction online, the transaction module checks the client’s protection status with the Fraud Protection Platform via API.
If the client has been flagged as high risk, the online transaction is automatically declined. A message is displayed asking the client to visit a physical service counter for further assistance, ensuring the client remains protected across both online and offline channels.
Storyboard: From Offline Fraud Detection to Online Protection
04 - Research
Defining Requirements Through Cross-Functional Collaboration
🧐 Defined Required Case Information with Stakeholders
After deciding to build a new platform, I proactively collaborated with stakeholders from both offline service counters and online transaction teams. We discussed how fraud cases might be governed in the future, as these decisions would directly shape what information the platform needed to collect.
For example, if governance rules were time-based, such as restricting certain transactions within a specific time window, the platform would need to capture timestamps. Similarly, if future follow-up required identifying which frontline employee initially reported the case, employee IDs would need to be recorded. These discussions helped us turn governance requirements into data fields for the platform.
✍🏻 Interview Frontline Employees to Understand Current Workflow
Because frontline employees previously relied on reporting methods that were only visible within service counters, the new platform required a significant shift in their workflow. To ensure the platform fit their existing practices, I interviewed frontline employees to understand their current fraud prevention processes, reporting timing, and decision-making criteria.
I also asked them to walk me through their actual workflow step by step. These insights allowed me to design reporting flows and interfaces that aligned with their habits, lowering the learning curve for adoption.
👩🏻💻 Validated Feasibility with Software Engineers
In parallel, I discussed the feasibility with software engineers by sharing the overall goal of cross-channel fraud prevention. Together, we explored how the new platform could integrate with existing systems, how fraud case data should be structured in the database, and whether the proposed data collection and APIs were technically viable. These discussions ensured that the platform design was not only user-centered but also technically feasible and scalable.
05 - Design
Turning Insights into Actionable Workflows and Interfaces
🧵 User Flow
I mapped user flows to illustrate how frontline employees report fraud cases and how these reports affect online transactions. This helped align stakeholders on the end-to-end process and ensured the new step fit seamlessly into existing workflows.
🎨 Interface Design
I designed the reporting interface to be fast and easy to use in time-sensitive situations. By choosing appropriate input types, such as checkboxes, dropdowns, and text fields, I balanced data accuracy with minimal cognitive load for frontline employees.
User Testing & Handoff
I conducted multiple testing sessions with frontline employees and iterated on the design based on feedback. Once the design was finalized, I translated the outcomes into a detailed Product Requirements Document (PRD) and worked closely with engineers to confirm feasibility and supported development by outlining testing scenarios.
06 - Implement
Launching the New Platform
🔍 Acceptance Testing
👩🏻💻 Training Frontline Employees
I conducted training sessions to help frontline employees understand when and how to use the new platform in real scenarios.
👥 Follow-up Coordination
I worked with online teams to confirm API integration, ensuring fraud protection was consistently enforced across channels.
07 - Retrospective
My Takeaways and Reflection
Working on fraud prevention service design at Cathay Life Insurance for nearly two years, this project was the first time I owned an end to end big project - from identifying the problem, shaping the solution, and aligning stakeholders, to designing and launching a real product. It left a particularly strong impression on me.
Through the process, I realized the most challenging part was not the design itself, but collaboration, such as building consensus across teams, navigating different perspectives, and keeping the project moving forward. I am deeply grateful for my managers’ support and for giving me the autonomy to experiment and learn through doing.
Seeing the final product adopted by frontline employees and knowing that at-risk clients are now better protected gave me a strong sense of accomplishment. It reaffirmed my belief that thoughtful service design can make a difference in people’s lives. 🪄