Fraud Prevention for High-Risk Merchants: Balancing Fraud Losses and Lost Sales
A MEASURED DEPLOYMENT PROCESS FOR HIGH-RISK MERCHANTS

An approved payment can become a chargeback. A blocked payment can be a lost customer. Fraud prevention has to account for both.
For high-risk merchants, higher approval rates or lower VAMP (Visa Acquirer Monitoring Program) ratios do not, by themselves, show that fraud controls are improving the business. The financial test is how much revenue remains after refunds and chargebacks, weighed against the cost of fraud prevention and the legitimate sales lost to blocking or added friction.
Every fraud setting has a revenue cost
Fraud detection uses transaction and customer signals to assess risk, but no system can perfectly distinguish fraud from legitimate purchases. Stricter controls can stop more fraud while also blocking more good sales. More permissive controls can preserve good sales while allowing more fraud through.
In our analysis of an online merchant in a high-risk vertical, three control settings produced the following transaction-time estimates:
Setting | Transactions blocked | Estimated fraud identified | Estimated legitimate purchase value blocked |
More permissive | 11.6% | 41% | $ x |
Moderate | 17.5% | 55% | $ 1.27x |
Stricter | 27.3% | 71% | $ 2.69x |
The stricter setting identified an estimated 71% of fraud versus 41% for the more permissive setting. It also blocked approximately 2.7 times as much estimated legitimate purchase value. Few merchants would run the stricter setting for long, but it shows how quickly good revenue disappears as controls tighten.
That is the trade-off the merchant faces. These figures are model predictions, not measured results. They estimate how much fraud each setting would stop and how much legitimate purchase value it would block. The next step is to test those predictions against actual payment outcomes and subsequent chargebacks to establish how accurately the model predicts risk and how much revenue the merchant retains.
The right operating point depends on the merchant’s current risk position and risk appetite
A merchant with a low VAMP ratio can loosen controls within its acquirer's risk tolerance to preserve good sales. A merchant already in remediation may need to sacrifice more immediate revenue to cut fraud and recover its ability to process payments. The same threshold is unlikely to serve both.
Issuer behavior adds uncertainty. In traffic we monitor, elevated VAMP periods have coincided with more declines on legitimate-looking transactions. This does not establish causation, but it reinforces why a fixed setting and an approval-rate target are insufficient.
Our data-driven deployment process makes the tradeoff explicit
At Idenza, the model and the deployment process work together. We use five stages to choose, deploy and calibrate the operating point.
1. Train on historical outcomes
We use as much relevant historical data as is available, linking transaction signals to known fraud and dispute outcomes. A risk model then estimates each transaction’s likelihood of fraud. We calibrate the model by comparing its predictions with known historical outcomes. During deployment, those estimates guide whether to allow a payment, step it up to 3-D Secure authentication, or block it, based on the merchant’s chosen risk tolerance.
2. Score live traffic before enforcing decisions
During observation, we score live transactions without changing the payment flow. We compare our risk predictions with issuer approvals and declines to understand where our assessments agree and where they differ. We also estimate the purchase value our proposed controls would block or subject to additional verification. Subsequent fraud reports and chargebacks help validate those assessments and refine the model.
3. Agree on the revenue and risk tradeoff
Once predictions align sufficiently with observed outcomes, we map candidate settings against estimated fraud losses prevented and legitimate revenue lost to false positives or added friction. We work with the merchant to select the current operating point, accounting for their VAMP position and acquirer requirements. Low risk payments proceed, uncertain ones are stepped up to 3-D Secure authentication, and the riskiest are blocked.
4. Expand enforcement through a canary rollout
We first apply those decisions to a limited share of traffic, then progressively increase coverage as results support expansion. We track completed payments, authentication abandonment and emerging fraud outcomes. Early approval gains cannot substitute for mature chargeback results.
5. Keep a control group and measure the benefit
Even after full rollout, we retain a small, representative control group following the merchant's baseline payment flow without additional Idenza interventions. Comparing equivalent traffic and observation periods helps measure the incremental benefit and preserves visibility into outcomes the model would otherwise filter out.
Keep tuning after deployment
Retained revenue is the money the merchant keeps from completed sales after refunds and chargeback losses, including any money recovered from successfully contested chargebacks. To assess the overall financial benefit, we also account for fraud and dispute fees and authentication costs.
As disputes mature, we connect them to the original scores and decisions. As traffic, issuer responses and the merchant's VAMP position change, we revisit the operating point. Improving conditions may justify recovering sales previously sacrificed; deteriorating conditions may require tighter controls.
Merchants should expect visibility into both the losses prevented and the good revenue sacrificed. The model provides a risk estimate. The deployment process shows whether acting on that estimate is improving the business.
If you are managing a VAMP ratio and want to see where your own trade-off sits, we can run the observation stage on your traffic before anything changes in your payment flow. Contact us to learn more about how Idenza can help you manage your revenues while staying compliant under the new VAMP rules.



Comments