Choosing a Third-Party Fraud Prevention Vendor: Four Delivery Models and Eight Providers Compared

Choosing a Third-Party Fraud Prevention Vendor: Four Delivery Models and Eight Providers Compared

People who work on payment risk tend to treat third-party vendors as one category and compare them on price: they all return a risk score, so the question becomes whose model is more accurate. That premise is wrong. Under the same label of fraud prevention, one vendor delivers an advisory, another delivers a verdict and absorbs the loss behind it, a third delivers takeover of an entire workflow, and a fourth only shows up after the money has already been pulled back.

Different delivery models mean four things change completely: who ultimately presses the approve button, who pays for a wrong decision, whether your risk team still has a reason to exist, and what it costs to switch vendors later. None of that appears in a feature table. For how the layers fit together, see how to order 3DS, risk and chargeback layers. This article answers one question only: within that layer, what does each of these eight vendors actually sell, and in what order should you screen them.

1. The first question: are you buying a judgment or an outcome?

1.1 Four delivery models

Placed on one map, the eight fall into four groups:

The column most often skipped is the third one. Who absorbs a wrong decision determines the other three things: the size of your risk team, the approval workflow you need, and whether this purchase sits in your books as a cost or as insurance.

1.2 Why the model matters more than the feature table

A feature table answers "what does it have". The delivery model answers "how will you operate afterwards". The same underlying model capability, delivered as advice, requires someone on call around the clock watching alerts, someone retuning thresholds, and someone accountable for approve decisions. Delivered as a guarantee, those roles can shrink, but you accept two things: you execute the vendor's decision, and your purchase cost floats with your chargeback structure.

Settle the model first, then compare vendors. Reverse that order and the typical outcome is buying an advisory service while expecting guaranteed-model results — you end up with the operational burden and none of the liability transfer.

2. What each of the eight actually covers

2.1 Forter: selling "who is this person"

Forter positions itself as identity intelligence. It does not start from "does this transaction look fraudulent" but from whether the person behind the order is the same person — stitching registration, login, device and order history into one identity view, then judging whether that identity is behaving abnormally.

That produces a genuine advantage: a single merchant's risk information boundary is its own order table, whereas an identity view can see the same identity's behaviour elsewhere. The cost is equally direct — the value of an identity graph comes from cross-merchant signals, so data sharing is a hard prerequisite; you must continuously supply and share consumer behaviour data. Cold start follows from the same logic: with low order volume, or a customer base that barely overlaps with other merchants in the network, the incremental value of the graph shrinks noticeably.

It ships six product lines sharing one judgment layer (fraud management, payment optimisation, dispute management, account protection, abuse prevention and more) and publishes an ROI calculator that lets you run a rough estimate from your own order volume, average order value and current false-decline rate. The point of the calculator is not the answer — it forces you to quantify your false-decline rate, a number most teams simply do not have.

2.2 Riskified: selling "approve the orders you would not dare to approve"

Riskified points in the opposite direction from the rest. Most vendors sell "block more accurately", which implies a tradeoff that over-declining a little is acceptable. Riskified sells the approval of orders that would otherwise be declined, absorbing an agreed share of fraud losses through chargeback liability shifting.

Put differently, it converts unmanageable chargeback risk into a budgetable fixed cost. For a business under growth pressure that conversion is attractive: false declines never show up in any report, but the orders you lost are real.

Two things need thinking through in advance. First, the guarantee is not blanket coverage; contracts define categories, regions, average-order-value ceilings and exclusions, and require you to execute its decisions. The moment your team overrides the model for relationship or experience reasons, the basis for the guarantee disappears. Second, pricing is tied to your chargeback rate, so cost predictability is weaker than a flat-fee design — rates rise when chargeback structure deteriorates, and chargeback structure is driven by category, promotion cadence and shipping speed, not entirely within your control.

2.3 Signifyd: selling a ship-or-decline verdict

Signifyd belongs to the same guaranteed category but pushes the deliverable further: most vendors return a score and leave the merchant to decide whether a human should look; Signifyd returns ship or do not ship, backed by a financial guarantee covering fraud and consumer-abuse losses.

What it genuinely replaces is worth stating plainly — not another rules engine, but the manual review queue. Any business where orders need a human glance carries costs that are not mostly salary: overnight and weekend staffing, inconsistent reviewer standards that create disputes, and the "decline when in doubt" habit reviewers develop for self-protection. A guaranteed model removes all three at once, which is the second source of ROI and the one most often missed.

2.4 Sift: selling "can this account be trusted"

Sift moves the decision subject from the transaction to the account. Transaction-level judgment is discrete — one decision at a time, unconnected; an account-centric view strings registration, login, password change, order and refund into a single trust curve.

For platform businesses that view is close to mandatory: fake accounts created in bulk generate no chargebacks of their own, yet they drain incentives, soak up promotions and pollute data. It also has one practical design choice — the Sift Score API lets teams with an existing in-house decision engine call only for a score without migrating to its console, making "buy the capability, keep the architecture" possible.

Its weakness is equally clear: an account lens does nothing for guest checkout. If most of your orders are placed without login, Account Defense and fake-account blocking barely apply, and you are left with transaction-level judgment — precisely the most commoditised part of the market.

2.5 Ravelin: selling abuse coverage and both sides of a marketplace

Ravelin covers more ground than typical payment risk, across seven areas: online payment fraud, refund abuse, promo abuse, account security and takeover, 3D Secure, marketplace partner fraud and transaction optimisation.

Two differentiators deserve separate mention. First, refund abuse and promo abuse never appear in chargeback reports; the losses are scattered across after-sales cost and marketing spend, and only someone specifically looking at the books will find them. Standard payment risk metrics cannot see them at all. Second, marketplace risk sits on both sides — chargeback fraud on the buyer side, shell merchants and self-dealing on the seller side — and ordinary payment risk only watches the buyer's payment, leaving half the picture dark.

It treats 3DS as an optimisation target rather than a compliance switch, publishing country-level challenge success references. Those figures are reference material, not a commitment: actual results depend on your acquirer, your issuer mix and your customer base.

2.6 Feedzai: selling a full governance stack to regulated institutions

Feedzai does not deliver "a score" but "takeover of a workflow". It puts fraud prevention and financial-crime governance in one framework covering the whole customer lifecycle: onboarding, transactions, account maintenance and suspicious-activity reporting.

The key to understanding it is the customer base: its home ground is banks and acquiring institutions, not merchant checkout pages. An acquirer has to manage merchant onboarding, merchant transaction quality and its own obligations to the card networks — three jobs that simply do not exist in merchant-side payment risk. Its multi-language, multi-region deployment says the same thing: the main battlefield is regulated institutions in Latin America and Europe.

For an ordinary merchant it is overkill — a checkout page needs approve-or-block, while a product designed to regulatory requirements brings heavy data integration and workflow maintenance. The test is blunt: do you need to prove to a regulator that your AML programme is systematic? If yes, this category is justified; if not, it is a burden.

2.7 Sardine: selling modular compliance capability

Sardine sits on the same institutional side as Feedzai but differs in how it is assembled. It unifies fraud prevention, AML compliance and real-time transaction monitoring on one platform, delivered as modular building blocks that customers combine as needed — start with the fraud module to address chargebacks, add the AML modules once the obligation actually lands.

That design addresses a real predicament: regulatory pressure arrives in stages, not all at once. Buying a single-suite platform means paying early for capabilities you need two or three years later, while carrying the integration complexity immediately. The price is that more modules mean more interfaces, and the interactions between thresholds and policies become harder to trace — modular freedom is ultimately paid for with configuration management discipline.

2.8 Chargebacks911: selling recovery after the chargeback

Chargebacks911 occupies a completely different position from the other seven: it is not on the checkout page but after the chargeback has occurred and the money has been pulled back. Pre-authorisation blocking is not its business; it handles evidence, representment, pre-chargeback intervention and recovery.

Its methodology is a three-step loop: reduce chargeback incidence, recover lost revenue, and repair the relationship and reputation with acquirers and card networks. The third step is the most overlooked, yet for merchants whose chargeback rate has already breached thresholds — or who have been placed in a card network monitoring programme — it often determines whether acquiring continues at all. The full path through monitoring and exit is in chargeback rate thresholds and merchant monitoring programmes.

Two commercial constraints need settling up front. First, returns depend heavily on chargeback structure: the higher the share of friendly fraud (the cardholder bought it but claims non-receipt or unauthorised use), the more evidence room exists; where chargebacks are mainly non-delivery or service-quality disputes, the recoverable share is far lower. Second, the basis for linking fees to recoveries must be written into the contract — is "recovered" the gross amount or the net after card network fees, which reason codes count, and whether unsuccessful recovery is still billed. This is where settlement arguments habitually start.

3. The five dimensions that actually decide the choice

3.1 Who absorbs the loss

This is the most expensive dimension and a veto item. Advisory, process and remediation models leave every loss on your books; only the guaranteed model transfers losses within an agreed scope. If your motivation for buying is "reduce losses" but you choose an advisory service, you will end up with a more accurate score and a bill you still pay yourself.

3.2 Whether the subject is a transaction, an account or a merchant

The information structures are entirely different. A transaction lens suits high-value, low-volume business; an account lens suits business with login systems that must stop bulk registration and promo abuse; a merchant lens only holds for platforms and acquiring institutions. Choose the wrong lens and you are working in the wrong coordinate system — a guest-checkout site buying account-based services is simply burning money.

3.3 Whether coverage must extend to abuse and AML

Payment fraud only, or refund abuse, promo abuse and return fraud as well? Are there AML and suspicious-activity reporting obligations? These two questions cut the candidate list to roughly a third. The losses that never reach a chargeback report are usually the ones quietly leaking for years.

3.4 Data-sharing boundaries and exit cost

Nearly every machine-learning risk vendor requires continuous transmission of order, device and behavioural data. Ask three things early: whether the data scope and legal basis hold up (cross-border business triggers personal-information export rules, covered in payment data export compliance); whether the model depends on your own history, and whether you can migrate smoothly if you switch; and what decision criteria you still own on exit — if every rule lives in the vendor's system, switching means rebuilding from zero.

3.5 Your business model narrows the list first

4. False declines and false approvals: pricing an asymmetric tradeoff

Every risk decision can fail in two directions, and the costs are almost never symmetrical:

• False approval (fraud passes): loss equals goods value plus chargeback fee plus card network penalties plus dispute handling labour. Bounded per case, but it accumulates into a chargeback rate that triggers monitoring and reserves.
• False decline (good customer blocked): loss equals gross margin plus customer lifetime value plus, often, a permanent review and churn. Invisible per case, and usually larger in aggregate.

Most teams only measure the first because it comes with a report; the second requires building your own definition. Treat the false-decline rate as a business metric that must be measured: take a sample of declined orders, release a controlled share as a holdout, and observe their actual chargeback and repurchase rates. Without that baseline, no vendor's effect can be evaluated — you cannot even say how much it improved.

For the broader acceptance-rate method see payment success rate optimisation; for policy design see payment fraud prevention strategies.

5. Four contract details that matter for guaranteed models

If you choose the guaranteed route, four items must be on paper, or the word "guarantee" will fail at the first large chargeback:

1. Coverage scope: categories, regions, average-order-value ceilings, shipping methods and trackability requirements. Discounted categories, digital goods and pre-orders usually carry extra limits.
2. Exclusions: commonly non-execution of the decision, late shipment, missing trackable logistics, and — in some contracts — friendly fraud listed separately.
3. Cost escalation mechanics: the formula linking fees to chargeback rate and order value, plus trigger conditions and notice periods.
4. Termination and liability: whether guarantees on historical orders survive termination and for how long, and who carries the burden of proof in a dispute.

Only after those four are settled should you look at model accuracy. The order cannot be reversed — the most accurate model buys you nothing if the terms are unfavourable.

6. When post-event remediation is actually worth it

Remediation applies more narrowly than people assume. It needs two preconditions at once: a meaningful share of chargebacks is provable (friendly fraud, unauthorised use, not-as-described), and you cannot complete evidence within the deadline (card networks impose hard evidence windows, and missing one counts as forfeiting).

If chargebacks come mainly from non-delivery or logistics disputes, recoverable space is limited and the money belongs in fulfilment improvements rather than a recovery service. If you already run a dedicated dispute team that meets the deadlines, the marginal value of an external service shrinks to "reusable cross-channel experience".

Order of judgement: chargeback structure first, internal timeliness second, price last. For how to prepare evidence see the chargeback reason code and evidence playbook; for the overall dispute workflow see refund and dispute handling processes.

7. Rollout order and acceptance metrics

Whichever vendor you pick, roll out in the same order:

1. Establish a baseline first: track false-decline rate, false-approval rate, manual review share and average review time for four consecutive weeks. No baseline means no acceptance criteria.
2. Single-channel pilot: launch in one market or one product line, ramping the share from low to high. Risk misjudgements directly damage real orders, so never cut over in one step.
3. Parallel run: operate the new service alongside existing rules for a period and compare decisions on the same orders, rather than looking only at aggregate metrics.
4. Write the override into the SOP: who may override the model and when, what approval that requires, and how overrides are reviewed. A risk system with no override process will eventually be routed around.
5. Recalculate periodically: once customer base, category or promotion cadence changes, thresholds and policies must be recomputed.

Fix four acceptance metrics: false-decline rate, fraud loss per ten thousand in transaction value, manual review share and on-time dispute response rate. They map to approval quality, loss control, operating cost and post-event capability. Watch all four — a single metric always distorts behaviour.

8. Five common misjudgments

1. Treating the vendor as an acquirer: none of these eight touches funds or participates in clearing. They do not change your settlement cycle or money path; the funds architecture remains a separate design, covered in treasury architecture for platform businesses.
2. Assuming risk tooling replaces 3DS: liability shift after completed authentication and risk blocking are different mechanisms. Blocking transactions that already passed a challenge buys little and costs a lot.
3. Using one composite score instead of layered metrics: a single risk score cannot optimise approval rate and loss rate simultaneously; they must be tracked separately.
4. Ignoring the compliance precondition for data sharing: cross-border transfer of personal information requires a lawful path; signing a contract does not create one.
5. Expecting the vendor to make business decisions for you: category risk, promotion cadence and shipping performance are yours, and a model can only project the operating decisions you have already made.

Source: 16IDC original. Product scope, guarantee terms and pricing for each provider follow official documentation and commercial contracts.