Mastercard - Policy Manager for Acquirers (PMAQ)
MY ROLE - SOLE UX DESIGNER EMBEDDED IN THE SAFETY NET PRODUCT TEAM, WORKING CROSS-FUNCTIONALLY WITH THE ENGINEERING AND DATA SCIENCE TEAMSDURATION - ONE YEAR (ONGOING)SafetyNet is a fraud-detection application used by banks worldwide to block large-scale fraud attacks, preventing millions of dollars in losses each week and hundreds of millions annually.
I collaborated cross-functionally across 3 teams (product, engineering, and data science), aligned 20+ stakeholders, and led end-to-end design of Policy Manager for Acquirers (PMAQ), an AI-powered fraud-detection and prevention solution within Safety Net’s product suite.
PROBLEM SPACEClosing a Critical Market Gap
This application is built for banks, with financial analysts and bankers as the primary users. Bankers trust familiar interfaces and tend to rely on established patterns, so rather than introducing new patterns or paradigms, I leaned into convention and familiarity.
Analysts and bankers are performing the same tasks repeatedly throughout the workday. Since this is a purely transactional tool, the goal was to reduce friction and streamline workflows. Users just want to come in, do their job efficiently, and move on.
The policy creation flow below is one example of this.
Merchant Details
Analysts will download a transaction report for a merchant to determine whether the signal is genuine fraud (create a policy) or a false positive (dismiss the signal).
When a consumer uses a Mastercard credit or debit card, each transaction is evaluated by multiple fraud-detection systems, including SafetyNet. If a transaction is flagged as high risk, it may be declined to prevent fraud. However, SafetyNet is not a consumer-facing product—its primary users are banks.
While Mastercard currently offers fraud-prevention solutions for issuing banks that serve cardholders, it does not provide any solutions for acquiring banks that serve merchants. Key challenges include:
If a merchant is compromised and under attack by fraudsters, acquiring banks can’t block or decline transactions from that merchant, resulting in millions of dollars in losses.
Financial analysts have limited visibility into their merchant portfolio and no way of getting alerted in real time when suspicious activity occurs on a specific merchant.
IMPACTDriving Alignment to Successful Product Launch
DISCOVERYHow might we define a clear product direction and align cross-functional teams despite research constraints and ambiguous requirements?
The ideal start to this project would have been conducting user interviews with our customers (acquiring banks) to gain a deeper understanding of their workflows and pain points. However, the product team prioritized building a working prototype to present to customers, generate excitement about the product, and gather user feedback. Given these constraints, I began initial discovery by partnering with internal SMEs and cross-functional teams.
I ran workshops with product and engineering to map out features and define a clear prioritization framework. This involved identifying essential MVP functionality, scoping post-MVP enhancements, and aligning on a north star vision for the platform. I prioritized core workflows like creating policies and investigating merchants to ensure the initial release delivered immediate value, while keeping the roadmap scalable for future iterations. Prioritization was based on user pain points, technical feasibility, and potential impact on analyst efficiency.
I identified the top Jobs to Be Done and mapped out key use cases, including policy creation in response to a BIN attack. I started with high-level journeys, then worked through specific interactions with engineering to align on feasibility and logic. The policy creation flow is a good example — we detailed every step from flagging a signal for investigation to defining policy thresholds and parameters, reducing potential user errors along the way. Breaking down these workflows early helped surface gaps and validate usability before moving into designs.
INITIAL ITERATIONS Dashboard
Users can view their recent and most signaled merchants, recent investigations, and recent policies. The initial dashboard served as a placeholder, and I planned to refine it based on user feedback about their preferred landing page or dashboard content.
All Policies
Users can search, filter, sort, view, edit, or delete polices. The approver role can approve or reject pending policies.
RESEARCH & INSIGHTSWhat can we learn from users with limitations to UX research capabilities?
PMAQ was originally conceived in 2021, and two other product designers had worked on it before I joined. The product experienced setbacks due to misalignment between product and engineering on which features to build, leading to previous designs and development being scrapped entirely. I was brought in to align product and engineering teams around a clear direction and drive the end-to-end development and launch of PMAQ.
My impact:
I built allyship, trust, and alignment across product, engineering, and data science, helping bridge communication gaps that had stalled progress. Design is the glue that holds the teams together.
I helped the team re-prioritize features and define a focused scope to restart development.
I used design to lead the product lifecycle end-to-end, moving PMAQ from stalled exploration to successful delivery.
A major challenge in conducting these user feedback sessions was establishing a research-driven approach and focusing more on learning from the users rather than selling to them. The product team led the sessions with a sales mindset, using the prototype to demo PMAQ, promote its features, and ask leading questions, rather than following a structured research methodology. To avoid confirmation bias and ensure we captured actionable insights, I advocated for dedicated time at the end of each session to ask unbiased UX research questions. Despite these limitations, I was able to gather several quality insights:
Users currently assign merchants to analysts and want the ability to search and group merchants in PMAQ by user, risk, or MCC to balance workloads and help analysts focus on high-risk cases.
Users wanted an Alert policy action in addition to Block and Decline, so they could intervene before triggering any hard stops.
Users asked for an Observe mode—a sandbox environment to test policies before going live.
Users did not understand the “Create Policy” threshold fields and felt that several important inputs were missing. They want the ability, during policy creation, to define multiple threshold conditions (count and/or amount), configurable velocity windows, and the ability to block or decline transactions by specific BIN or country. This will give users more flexibility and control over merchant monitoring. Both group-level and single-merchant policies were considered useful.
Dashboard
I updated the dashboard to improve usability and allow banks more visibility into their merchant activity. Users can view metrics and data related to their signals, merchant portfolio, and policies. I plan to refine it further based on usage metrics and feedback gathered during the market test.
FINAL DESIGNSSignals
Based on user feedback around Merchant Search and Merchant Groups, I decided to split Signaled Merchant into two dedicated tabs - Signals and Merchants.
The new Signals tab lets users create policies directly from signals, reducing the steps needed to act on suspicious merchant activity. Investigations were moved under Signals to reflect how analysts naturally move from reviewing a signal to investigating one.
Beyond KPIs: Unlocking Behavioral Insights
Create Policy
The Create Policy modal was redesigned as a side drawer to provide more space for additional templates and fields, giving users a shorter path to completion.
Users can create a policy with four actions: decline, block, alert, or observe. The additional fields let users fine-tune policies to match their specific risk tolerance and merchant portfolio.
Relying solely on high-level KPIs like revenue and user count provides an incomplete picture of product health. While these metrics reflect business outcomes, they do not explain why users behave as they do or where friction occurs within the product experience.
To address this, I created a metrics framework and set up event tracking in Mixpanel, an event-based product analytics platform, to better understand user behavior. By tracking key user flows, I can measure specific interactions, feature adoption rates, and session patterns. Key metrics include conversion rate, funnel completion rate, retention rate, time to first key action, error rate, and average session length.
This approach will enable actionable insights during the market test, allowing the team to move from assumptions to evidence-based decisions, identify usability issues early, and guide the product toward market success.
More Projects
Paycom
Signaled Merchants
Users can view all merchants with active signals in a table. Signals are alerts that highlight unusual or risky merchant activity. I added a Policy Status column to improve visibility and help users prioritize which merchants require action.
Review Policy
Approvers will review the policy details and decide whether to approve or reject. If the policy is rejected, they must select or enter a reason in the next modal.
Create Policy
Analysts can create a policy with two possible actions: decline or block. They can set a threshold amount, define a policy name, and specify a start date and an expiration date.
NEXT STEPSMerchants
Under the new Merchants tab, users can view all merchants with active signals in a table and select multiple to group them or assign policies directly, making it faster to manage merchants in bulk.
Merchant Search and Merchant Groups were added as dedicated sub-tabs, giving users a central place to look up individual merchants and organize them into groups for easier policy management.
CoralTech
Designing for Trust: UX Considerations for a Banking Audience