I spent years thinking my job was to block fraud. The reframe that changed everything was that a wrongly declined good customer is a loss too. It just shows up on somebody else's P&L
My first Fraud Risk PM role had exactly one number that mattered: the delta between fraud losses vs permissible loss budget.
I was at JPMorgan Chase, working on the rules engine that decisioned on millions of transactions a day across Chase cards. When we rolled out contactless cards nationwide in 2018, my focus was on defense, which involved minimizing the losses and stopping as many bad actors per month as possible.
The question that changed everything I built
Of course the bank also cared about good customers being caught in the crossfire. There was a whole team of manual agents who could step in and unwind an inaccurate decline in near real time, and we would actively loosen our posture around things like the World Cup or a hurricane, any time we knew a lot of legitimate customers were about to behave in unusual ways. My personal scorecard was still the loss line, and that is the lens through which I saw my everyday work.
Then I moved to Walmart eCommerce , where I took over end to end payments and identity fraud right as COVID hit. Behind every declined transaction was a real person who might just go buy their goods or groceries somewhere else, at a time when that mattered more than usual. That pressure changed how I thought about the role.
I stopped asking “how do we stop more fraud?” and started asking “how do we stop fraud while approving more of the customers we were wrongly turning away?”.
When the fraud PM and the growth PM finally agreed
As an ML Risk Platform PM, I plugged in consortium data to get a better signal on guest customers, the ones our old ML models were basically guessing on. Fraud losses dropped significantly, but the real headline wasthe monthly revenue increase, because it turned out a lot of the people we had been declining were actually fine. We also improved device fingerprinting and picked up our approval rate, and built better ML models that cut chargebacks without adding a single extra step for the customer.
None of those were fraud reduction initiatives like my previous ones had been, but rather precision projects. And that is when my number and a growth PM's number began pointing in the same direction. because I started treating it as a business cost with a real dollar value attached to it.
By the time I got to Sift (digital fraud prevention platform), I wasn't just doing this on my own roadmap anymore. I was trying to bake it into a product that our client’s risk teams would use. RiskWatch, one of the products I led there, was built around this exact tension, giving fraud teams a way to catch more bad actors without just torching approval rates to do it.
The system I built to stop choosing between fraud and revenue
The clearest proof of that was a percentile based scoring system I ended up patenting, to rank risk in real time instead of relying on one static threshold that is either too tight or too loose depending on the day.
Here is what the difference looks like in practice. Under a static threshold, a score of, say, 75 would block a transaction. During a flash sale, legitimate customers buying in bulk could easily get their scores to 76 and get blocked, since the threshold doesn't know it's a flash sale.
Under the percentile model, however, we are not asking "is this score above 75?". We are asking whether this transaction is in the riskiest X% of today's traffic. During the flash sale, those 76 score customers would actually be in the 40th percentile of risk for that moment, well below the block band, meaning they would go through.
For one of our biggest enterprise customers, tuning how we scored and stabilized that percentile band, instead of just cranking a rule tighter or looser, drove a $19M revenue increase in a single quarter. That lift was measured as incremental approved revenue that previously would have been blocked by the static threshold but was now approved and completed successfully. Fraud losses during the same quarter held flat; chargeback rates actually declined slightly, because the improved precision cut some noise from the blocking rules.
We also built something we called a score stabilizer which is a layer that watches both fraud outcomes and score movements in real time and adjusts the blocking threshold only when the data says it should, not every time scores fluctuate. The idea was to stop fraud prevention and customer experience from working against each other, which I will get into in more detail below.
Building it required three decisions we had not explicitly made before.
First, we had to decide what we were comparing each transaction against. The percentile model works by ranking riskiness in real time, pooling together a set group of individuals trying to place an order over a period of time. The riskiest 5% of shoppers on Black Friday is a very different group from the riskiest 5% on a quiet Tuesday afternoon. So we made the lookback window adjustable: a short lookback of one hour let us respond to sudden attacks happening in real time, while a longer window of thirty days helped us catch fraud patterns that were creeping in gradually.
Second, blocking decisions were now based on a percentage of traffic rather than a score cutoff, which forced a completely different conversation with risk leadership about what an acceptable block rate actually was.
Third, we built something we called a score stabilizer. The name sounds technical but the idea is simple: fraud scores move around for reasons that have no relevance to fraud. Fraud scores can fluctuate for reasons completely unrelated to actual malicious activity. Key factors that drive score spikes and cause unnecessary blocks include model updates, changes in the types of shoppers purchasing on a given day, new device types expanding the mix of incoming traffic. Crucially, these triggers elevate risk scores even when underlying fraud rates remain completely unchanged.
So we needed a way to tell a real attack from a false alarm. If the block rate jumped and confirmed fraud jumped with it, that was a real attack in which case we held the threshold. If the block rate jumped but fraud outcomes stayed flat, something else had shifted, and we needed to adjust before real customers started getting declined for no good reason. The stabilizer watched both signals and knew the exact reason for the score fluctuation.
What I would tell every risk PM getting paid to say no
Here's the thing I would tell any risk or fraud PM stuck in this fight right now. The growth PM across the table from you isn't wrong to push back on your declines. Also, you are not wrong to hold your loss threshold, but you are both doing exactly what your metric tells you to do.
What helped us bridge this gap was running quarterly roadmap reviews jointly with the growth team, where both teams brought their top five priorities ranked by dollar impact. Before this, Risk PM would bring a list ordered by loss reduction and growth would bring one ordered by revenue lift. But once we put a dollar value on false declines, the lists started overlapping, and both teams ranked the same initiative. For example, improving guest checkout approval for mobile used to be a precision project for the Risk PM and a conversion issue for the Growth PM, but seeing this through the lens of preventing false declines brought the two into alignment.
The mindset shift that actually changed my career wasn't a smarter model or a bigger dataset, but realizing a wrongly declined good customer is a loss to the company. It just shows up on somebody else's P&L instead of mine. Once I started measuring my own work by how much revenue my precision unlocked, not just how much loss my rules could prevent, conversations with growth PMs stopped being negotiations and started being a shared roadmap.
I still care about the loss line, probably more than most people would like. But I stopped thinking of my job as the person who says no. Now I think of it as the person who says yes more accurately.
