Fintech PM Metrics: Balancing Fraud, Conversion & Retention
The metrics fintech PMs choose don’t reflect performance — they define it. At a Q3 fraud review with Stripe’s risk leadership, a product manager presented a 22% drop in false positives. The room celebrated — until the head of revenue pointed out a 14% decline in high-risk merchant approvals, worth $3.8M in lost volume. The problem wasn’t the metric; it was the lack of balance. Most PMs optimize one lever — conversion, fraud loss, or retention — and break the others. The ones who succeed use a triage framework: Conversion Velocity, Fraud Exposure Index, and Retention Half-Life. These aren’t vanity stats; they’re forcing functions that expose trade-offs before they hit P&L.
At Google Pay, we rejected 47% of candidate dashboards in HC debriefs because they tracked “fraud rate” and “activation rate” in separate silos. The hiring managers wanted to see how PMs connected them. One candidate passed because she modeled every 10bps reduction in fraud rules against projected churn in emerging markets — using real A/B test data from Brazil. That’s the standard: metrics as decision architecture, not reporting outcomes.
This article isn’t about listing KPIs. It’s about building a system to manage their collisions.
Who This Is For
You’re a product manager — or aspiring to be one — at a fintech company where money moves fast and trust is fragile. You work on checkout, onboarding, payments routing, or account security. You’ve been told to “improve conversion” while “reducing fraud losses” and “keeping users active.” No one explained how to weigh those against each other. You’ve sat in meetings where marketing claims a new flow increased signups by 18%, but risk flags a 5% spike in synthetic identity fraud six weeks later. You need a framework, not more dashboards. This is for PMs at companies processing over $100M in annual transaction volume, where a 1% error in metric design can cost millions.
How do fintech PMs measure conversion without ignoring fraud risk?
Most PMs treat conversion as a funnel metric — 70% of applicants complete onboarding — and stop there. That’s not insight; it’s theater. The real question is: what kind of users are converting, and at what downstream cost? At Square, we ran an A/B test on simplified KYC that boosted completion from 61% to 74%. Great news — until we segmented by fraud cohort and found that 68% of the new conversions fell into high-risk BINs (bank identification numbers) with a 3x higher chargeback rate. The net revenue impact was negative.
The fix: Conversion Velocity. Not percentage completed, but dollar volume of low-risk transactions processed per hour of user effort. We calculated it as (approved transaction value) / (average time to complete flow). In the Square test, despite higher completion, Conversion Velocity dropped 9% because more manual reviews were triggered downstream.
Not completion rate, but economic throughput.
Not drop-off points, but risk-weighted yield.
Not funnel stages, but cost of verification per $1k processed.
In a Q2 HC debate at PayPal, a PM defended a 12% increase in instant verifications by highlighting speed. The committee rejected her because she couldn’t link it to Fraud Exposure Index (FEI) — our second pillar. Without that balance, velocity is just recklessness with a timer.
What metric actually captures fraud impact — not just fraud rate?
Fraud rate — (fraudulent transactions / total transactions) — is the most misused metric in fintech product reviews. It’s a lagging, decontextualized number that encourages bad behavior. One PM at a neobank reduced fraud rate from 0.18% to 0.12% by tightening rules. Volume fell 21%. Their bonus was tied to fraud rate. They got paid. The business lost $2.3M in blocked legitimate transactions.
The better metric: Fraud Exposure Index (FEI). FEI = (fraud losses + cost of false positives + operational review burden) / (total processed value). We assign weights: fraud losses at 1.0, false positives at 0.7 (since most are recoverable), and manual review at $8.50 per hour scaled by team size.
At Adyen, we used FEI to kill a rule that blocked all transactions over $2,500 from newly onboarded merchants. The rule reduced fraud by $40k/month — but blocked $1.2M in legitimate sales and required 3 FTEs to manage appeals. FEI showed a net negative. We replaced it with velocity checks (e.g., 3+ high-value transactions in first 24h) and cut fraud by $32k with only $200k in false positives. FEI improved by 31%.
Not fraud rate, but total exposure.
Not rules count, but cost per dollar protected.
Not detection accuracy, but economic efficiency.
In a debrief at Plaid, a candidate was asked how they’d evaluate a new identity verification vendor. Those who cited “98% fraud detection rate” failed. The ones who asked, “What’s their impact on FEI at scale?” advanced.
How do you measure retention when fintech users are dormant by design?
Consumer fintech PMs obsess over 30-day retention like it’s gospel. But in financial services, many users are event-driven. They use your app to send money once a quarter, pay a bill annually, or cash out after gig work. At Venmo, 41% of users transact less than four times a year. Calling them “churned” at day 30 is nonsense.
The standard retention curve fails because it assumes continuous engagement. It doesn’t. The right metric: Retention Half-Life (RHL). RHL is the median time between first and second transaction, projected across cohorts. We calculate it using survival analysis on transaction logs, not login events.
When we launched instant P2P payouts at Cash App, marketing claimed 89% retention at 7 days. But RHL analysis showed that for non-bitcoin users, the half-life was only 11 days — meaning half the cohort waited over 11 days to send money again. The product team used this to redesign nudges: instead of “Come back!” emails, we triggered SMS reminders when a user’s frequent recipient got paid (using payroll data partnerships). RHL extended to 23 days. Revenue per user increased 34%.
Not DAU/MAU, but transactional recurrence.
Not login frequency, but economic reactivation.
Not engagement, but behavioral half-life.
In a Google PM interview, a candidate was asked to improve retention for Google Wallet. She dismissed 30-day metrics and proposed RHL segmented by use case (peer payments, transit, rewards). The panel approved her case — one of only two that cycle to do so.
How should PMs balance these three metrics in real decisions?
You don’t optimize conversion, fraud, and retention separately. You trade them off using a decision matrix. At Revolut, we used a weighted scorecard for all major product changes: 40% Conversion Velocity, 30% FEI, 30% RHL delta. Any proposal with a net score below 70 was tabled.
Example: We tested disabling 3D Secure for transactions under €50. The fraud team resisted. Our model projected:
- Conversion Velocity: +15% (faster checkout)
- FEI: +0.03% (fraud increase of €12k/month)
- RHL: -6 days (users transacted more frequently due to friction drop)
Score: 82/100. We launched — but with a circuit breaker: if fraud exceeded €18k/month in two consecutive weeks, 3DS would auto-revert. It never triggered.
The framework prevents “metric myopia” — where a PM wins locally but loses globally. One candidate at Klarna failed HC because their A/B test showed better conversion but ignored FEI. The committee asked, “Did you model the cost of the fraud increase?” They said no. They were rejected.
Not standalone metrics, but a trade-off engine.
Not directional improvements, but net economic impact.
Not product wins, but portfolio-level balance.
We used this same model at Stripe to evaluate regional launch strategies. India scored lower on Conversion Velocity due to document complexity, but had 5x higher RHL than Turkey. We prioritized India — correctly. Annual volume there now exceeds Turkey by 4x.
What does the fintech PM interview process look like — and where do candidates fail?
The process is three stages: take-home, behavioral, and on-site case. Companies don’t say it, but they’re filtering for metric fluency from the start.
The take-home: 90% of candidates submit a PRD with “increase conversion” as a goal. They list steps, timelines, mockups. They fail. The ones who pass reframe the prompt as a metrics problem. One candidate at N26 received a prompt to “improve signup flow.” Instead of jumping to design, they wrote: “Assuming current Conversion Velocity is $42/hour and FEI is 0.15, here are three variants with projected impacts.” They included a sensitivity table. They got the job.
Behavioral interviews test for real trade-offs. “Tell me about a time you improved conversion.” Weak answer: “We simplified the form and completion went up 20%.” Strong answer: “We reduced fields from 11 to 6, boosting completion 22%, but fraud attempts rose 8%. We recalibrated our address verification logic and recovered 6% of the loss without hurting conversion. Net Conversion Velocity improved 14%.” The second answer shows system thinking.
On-site cases are stress tests. At PayPal, one candidate was given a dashboard showing rising fraud and flat retention. They diagnosed the issue as underinvestment in step-up authentication. But when asked, “What’s the FEI impact of adding biometrics?”, they couldn’t estimate false rejection rates or support costs. They were dinged.
The hiring committee doesn’t want executors. They want economists in PM clothing.
Preparation Checklist
- Define your core metrics using the triad: Conversion Velocity, FEI, RHL — not industry defaults.
- Build a decision matrix with weighted scores for trade-off evaluation.
- Segment all metrics by user type, region, and transaction risk tier.
- Practice articulating trade-offs: “This change gains X in conversion but costs Y in fraud exposure.”
- Study real debriefs — not mock interviews. Understand how HC panels challenge assumptions.
- Work through a structured preparation system (the PM Interview Playbook covers fintech metric trade-offs with real debrief examples from Stripe, PayPal, and Revolut).
Mistakes to Avoid
BAD: Setting a product goal as “reduce fraud rate by 20%.” This incentivizes blocking legitimate users. One PM at a BNPL startup did this. They tightened underwriting, cut fraud by 25%, but volume dropped 33%. The business missed its quarterly targets. The PM was praised by risk but criticized by revenue leads.
GOOD: “Reduce FEI by 15% while maintaining Conversion Velocity within 5% of baseline.” This forces balanced thinking. The same PM, when re-tasked, introduced dynamic document requests — only high-risk users had to upload IDs. Fraud stayed flat, volume recovered, and FEI improved 18%.
BAD: Measuring retention as “30-day active users” for a bill-pay product. This labels seasonal users as churned. A PM at a utility payments app did this, claimed 40% churn, and proposed expensive re-engagement campaigns. The data was wrong.
GOOD: Using Retention Half-Life. When recalculated, RHL was 54 days — meaning most users returned within two months. The churn panic was unfounded. The team paused campaigns, saved $280k in wasted spend.
BAD: Presenting conversion and fraud metrics on separate slides. In a Q1 HC at Monzo, a PM showed “onboarding up 19%” on slide 5 and “fraud up 7%” on slide 12. The committee didn’t connect them. They asked, “Did you model the relationship?” The PM hadn’t. The project was delayed.
GOOD: Showing a unified impact table. Another PM presented: “Variant B increases Conversion Velocity by 11% but raises FEI by 0.02. Net present value over 12 months: +$1.4M.” The committee approved it immediately.
The book is also available on Amazon Kindle.
Need the companion prep toolkit? The PM Interview Prep System includes frameworks, mock interview trackers, and a 30-day preparation plan.
About the Author
Johnny Mai is a Product Leader at a Fortune 500 tech company with experience shipping AI and robotics products. He has conducted 200+ PM interviews and helped hundreds of candidates land offers at top tech companies.
FAQ
Is fraud rate ever a useful metric?
Only for compliance reporting — never for product decisions. Fraud rate hides the cost of false positives and operational drag. In a regulatory context, you must report it. But for product trade-offs, it’s dangerously incomplete. Use FEI instead.
Should all fintech PMs use the same metrics?
No. High-frequency trading apps need different measures than insurance platforms. But the framework — balancing acquisition, risk, and recurrence — applies universally. Conversion Velocity, FEI, and RHL are starting points, not dogma. Adapt them to your product’s economic model.
How do you get buy-in from risk and marketing teams?
Speak their language, then reframe. Show marketing how Conversion Velocity includes economic yield, not just clicks. Show risk how FEI accounts for false positives. In a meeting at Chime, we presented a change that increased approvals 15% but added $90k in fraud. By showing that the net FEI impact was neutral and RHL improved, both teams agreed. Metrics become negotiation anchors when they’re shared.