A fraud model can catch more fraud and still make the business worse.
Lower the threshold and more risky events enter review. The queue grows. Legitimate customers wait. Analysts rush, and the extra alerts bury the cases that mattered.
The useful question is not whether a model is accurate. It is whether the full decision system reduces loss at a customer-friction and review cost the business accepts.
Adjacent transaction proof
- transactions in the first three months
- 10,000
- RaftLabs mobile POS project record
- transactions processed in one test day
- 20,000+
- RaftLabs gas-station platform record
- kept inside a focused first release
- 1 fraud type
- A measurable boundary before expansion
RaftLabs does not currently publish a named fraud-model case study. The transaction figures show experience around payment and operating data; they do not prove fraud-model performance. The first phase must beat the buyer's historical baseline before any production claim is made.
Custom fraud detection earns its cost when the score fits a defined decision policy.
A configured vendor platform is better when it already covers the fraud type, data, and evidence trail.
A fit01Confirmed outcomes and analyst decisions can be linked to historical events.
02Risk owners can define review, hold, verification, approve, decline, and appeal authority.
03The business measures missed fraud, legitimate events delayed, and analyst capacity.
Not a fit01There is no dependable feedback on which past events were fraudulent.
02Automatic blocking is requested before review, escalation, and appeal policies exist.
03A fraud platform already covers the risk type without costly workflow gaps.
Scope
What the first fraud decision needs
01Event, outcome, and label model
The scored event is joined to what the system knew at that time, the eventual
confirmed outcome, and the analyst decision. The audit checks label delay,
missing outcomes, class imbalance, and leakage from future information.
02Rules or models with reasons
Rules handle known patterns that fraud teams must change quickly. A model is
added only when it improves the agreed decision on held-out history. Each
result records its version, score, and leading reasons.
03Analyst review and escalation
The queue carries the event context, evidence, reason codes, similar history,
and available outcomes. Reviewers can request verification, approve, decline,
or escalate according to the policy they own.
04Feedback and monitoring
Confirmed outcomes return to the evaluation set. Monitoring watches fraud
caught, false positives, review volume, decision delay, data drift, and
performance by relevant customer or channel segments.
Configured fraud platform vs custom detection
| Configured platform | Custom software |
|---|
| Best fit | Common fraud types and supported payment or claim flows | Proprietary events, evidence, or review policies |
|---|
| Signals | Vendor network and standard integration fields | Your event history and approved internal data |
|---|
| Decision policy | Configure available rules, scores, and workflows | Design exact thresholds, reasons, review, and escalation |
|---|
| Feedback | Return outcomes through the vendor contract | Control how analyst and confirmed outcomes update evaluation |
|---|
| First test | Trial on historical and shadow traffic | Prove one fraud decision against the current baseline |
|---|
We recommend the established platform when it fits the actual workflow. Custom work is justified only when the proprietary data or decision gap is valuable enough to own.
How it works
From fraud policy to controlled release
The score and the analyst workflow are tested against the same threshold.
- Phase 1
01Define the fraud decision
Agree the fraud type, evidence, possible outcomes, thresholds, review
capacity, appeal path, and owners.
- Phase 2
02Reconstruct historical cases
Join event history with confirmed outcomes and analyst decisions. Inspect
label quality, time leakage, missing data, and imbalance before training.
- Phase 3
03Validate rules and models
Compare candidates on held-out history. Let fraud operations inspect the
resulting queue and test the customer-friction trade-off.
- Phase 4
04Release with control
Integrate scoring and review, record reasons and versions, monitor outcomes,
and put threshold or model changes through an approval path.
The mobile POS platform processed 10,000 transactions in its first three months and included signature-verified webhooks, queued processing, idempotent workers, and reconciliation. The gas-station operations platform processed more than 20,000 transactions in one test day across a rollout that connected 40+ locations during beta.
Both are adjacent transaction-system evidence. Neither is described as a delivered fraud model, catch-rate result, or universal scale promise.
- Accuracy hides the rare class
- A system can approve nearly everything and still look accurate when fraud is rare. Measure precision, recall, loss, and queue effects on the fraud decision.
- Future data leaks into training
- A field created after investigation can make a backtest look excellent while remaining unavailable at decision time. Reconstruct each case as it was known then.
- A score becomes an unexplained decline
- High-impact outcomes need reasons, review ownership, records, and an appeal or verification path appropriate to the context.
- Thresholds never change
- Fraud patterns, channel mix, and analyst capacity move. Monitor them and govern threshold changes instead of silently retraining into a new policy.
Scope and price
A focused fraud-detection release starts at $25,000.
Begin with one fraud type, one decision policy, historical validation, and one analyst review path.
Expand coverage or automation only after the first decision improves on the agreed historical baseline.
Starting investment
Starts at $25,000
A focused first release usually takes 10 to 16 weeks. Real-time decisions, new review tooling, and regulatory obligations move the estimate most.
Baseline before production
The phase compares proposed rules or models with the current decision process
on held-out history. We do not invent an accuracy promise before reviewing the
data.
Fixed-price phase
Once the data, decision policy, acceptance measures, integration, and handover
are agreed, the phase price is locked in writing.
Related services
Where to go next