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.