What Does It Cost to Build a Custom Fraud Scoring System?

Three numbers, and the feature pipeline is most of one

Custom fraud detection cost splits into a one-time build, a per-transaction run cost, and an ongoing operations cost that teams routinely leave out of planning. The build number is dominated by one thing — the feature pipeline — and the run number is dominated by whether an LLM touches every transaction or only some.

The one-time build

• The feature pipeline. This is the bulk of it: a streaming aggregation layer keeping velocity and behavioural features current, an online store serving them in single-digit milliseconds, train/serve consistency so the model sees identical feature semantics in training and scoring, and point-in-time-correct backfill for building training sets. On our fintech fraud-scoring project this is where the engineering time went — the model itself was a comparatively small part of the build.
• The baseline model. A gradient-boosted model on engineered features — comparatively cheap once the features exist.
• An optional LLM reasoning layer. Adds an evaluation harness and shadow-mode infrastructure to measure it on your traffic before it influences a decision.
• The review console and routing. The three-tier decision surface and the analyst tooling for the borderline band.
• Explainability and audit infrastructure if you're regulated — per-decision attribution, reason codes, versioned append-only logs.

The per-transaction run cost

• Feature store reads on every scored transaction.
• Model inference. Trees are cheap — single-digit milliseconds.
• The LLM call, if there is one. This is the swing variable. A small, real-time-class model runs roughly an order of magnitude cheaper per call than a frontier model, and whether it runs on every transaction or only the ambiguous score band changes the monthly bill substantially.
• Streaming infrastructure for the event log feeding features and audit retention.

The ongoing operations cost

• Retraining on a schedule as labels mature and fraud patterns move.
• Drift monitoring with owners and alert thresholds.
• On-call for a system that sits in the authorization path.
• Audit-log storage for the full regulatory retention window.

What pushes it up

• An LLM call on 100% of traffic rather than the grey band only.
• A regulated audit trail with full per-decision reconstruction.
• A multi-region online feature store.
• Self-hosting the reasoning model instead of using a managed API.

What pulls it down

• Keeping the LLM layer on the ambiguous band only.
• Reusing streaming infrastructure you already run.
• A managed feature store instead of building one.
• Buying the cross-merchant network signal and building only the model for the grey zone where your first-party data matters.

A worked structure (variables, not numbers)

• T = transactions per month, g = share that hit the LLM layer (1.0 if every transaction, or the grey-band fraction).
• Monthly model cost ≈ T × feature-read + T × tree-inference + (T × g) × LLM-call-cost.
• Add streaming infra and audit storage (roughly flat).
• Build cost amortised across two to three years.
• Add the operations cost — retraining, monitoring, on-call — as a recurring line, because it doesn't go to zero.

The variable that swings it is g. Everything else you can bracket up front.

Compare against buying

A managed fraud platform replaces the build number with a per-transaction fee and removes the operations cost entirely. The trade: the fee scales with volume rather than flattening once the system is built, and you inherit the vendor's error profile and reason-code vocabulary. For most businesses buying is the right first move, and often the right permanent one. Building enters the picture when the false-positive cost on legitimate customers is large and specific to your traffic, when you have proprietary signal a vendor can't use, or when per-transaction pricing at your volume has overtaken the loaded cost of owning a model — including the operations line above, which is the part that makes an in-house build a standing commitment rather than a one-time spend.

Where this stops being right

• Low volume or low fraud rate. You won't have the labels or the losses to justify a build — buy, or rules plus manual review.
• Mostly informational risk checks. If there's no real false-positive cost, a lighter tool is enough.
• Estimates age fast. Re-quote model and inference pricing before committing; the LLM line is sensitive to it.

FAQ

Is the model the expensive part? No. The feature pipeline is the largest build cost, and — in a regulated context — the audit trail is second. The model itself is comparatively small.

What's the hidden cost people miss? The operations cost: retraining, drift monitoring, and on-call for a system in the authorization path. It's recurring and it never reaches zero.

Can I predict the run cost before building? Within a range. T is known; the uncertain input is g — what share of transactions actually need the reasoning layer — which a shadow period pins down.

ISTRALLEN scopes and builds custom fraud scoring for fintech teams, sizing build and run cost against real transaction volume first; see AI for Fintech.