A fraud team narrows its counterparty lookback from ninety days to thirty. The stated reason is noise. The real reason, once you read the scheduler logs, is that the nightly screening batch stopped finishing before the analyst shift started, and thirty days was the largest window that fit. Nobody wrote that decision down as a detection change. It was filed as a tuning change.

That substitution — an infrastructure constraint arriving dressed as a modelling judgement — is the single most common way detection quality quietly degrades in a bank. It is worth separating the two questions properly, because they have different owners, different fixes, and very different costs.

Two questions that look like one

When fraud or anti-money-laundering detection underperforms, there are two independent explanations, and teams routinely conflate them.

The first is a modelling question: is detection limited by the model architecture and the labels available to train it? Fraud labels are late, partial, and biased by whatever the previous system caught. Money-laundering labels are worse — a suspicious activity report is a filing, not a confirmed outcome, and the true prevalence of laundering in a transaction population is unknown by construction.

The second is a capacity question: is detection limited by how much scoring the pipeline can afford to run before its deadline? Every real fraud stack makes compromises here. Some fraction of transactions gets scored on a reduced feature set. Some graph traversals stop at one hop instead of three. Some segments get scored on a sampled basis rather than in full.

Sampling transactions, shortening feature windows, and truncating graph traversals are detection-quality decisions, and they are almost always made for compute reasons. That is the sentence worth taking away. The model card records none of it; the model card describes what the model would do given full features, not what the pipeline actually fed it at three in the morning under load.

We see this pattern regularly when we are brought in on a scoring pipeline that is “slow.” The first useful output of the engagement is usually not a speedup. It is a written list of the fidelity compromises already in production that nobody had inventoried.

How AI detects fraud and money laundering

The mechanics differ enough between the two that treating them as one workload is the second common error.

Authorisation-time fraud scoring is a low-latency, high-volume classification problem. A card or payment authorisation arrives, and a decision — approve, decline, step up to additional verification — has to be returned inside a budget that is typically tens of milliseconds for the model call, sitting inside a wider network round trip the scheme controls. The features are computed against a feature store: velocity counters (how many transactions from this card in the last minute, hour, day), device and session signals, merchant-side aggregates, and behavioural deltas against the account’s own baseline. Gradient-boosted trees remain extremely common here because they are fast, calibrate well on tabular data, and are explainable enough to survive a model-risk review. Deep sequence models over transaction histories are increasingly used alongside them, particularly where the account’s own ordering carries signal.

AML screening is a different shape entirely. It runs mostly in batch, over a window measured in hours, and its unit of analysis is not the single transaction but the pattern: structuring, layering through intermediaries, round-tripping, mule networks. That makes it inherently a graph problem. The counterparty graph — accounts as nodes, transfers as edges, with time and amount on the edges — is where the signal lives, and traversal depth is a direct detection parameter. A two-hop neighbourhood catches a different class of typology than a four-hop one. Graph neural networks and graph feature extraction (community detection, motif counting, centrality over time slices) sit on top of that structure, usually feeding a downstream classifier or a risk score that populates an alert queue.

The evidence requirement diverges too. A declined authorisation needs a reason code. A suspicious activity report needs a narrative an investigator can defend to a regulator, which means the pipeline has to retain and surface the specific traversal and the specific transactions that drove the score — not just the score.

What features do AI models use that rules engines do not?

A rules engine encodes a hypothesis: amount over a threshold, country on a list, velocity above a count. It is auditable, cheap, and static. Its weakness is that every rule is a line an adversary can find by probing, and rule sets accrete until nobody can reason about their interactions.

The learned models add three things rules struggle with. They use continuous interactions rather than thresholds — the combination of a moderate amount, an unusual hour, and a slightly-off device fingerprint, none of which trips a rule alone. They use relative baselines — the transaction is unusual for this account, not unusual in absolute terms. And in the AML case they use relational structure — this account is two hops from a cluster that already generated confirmed filings, a fact no per-transaction rule can express.

In practice the two coexist. Rules stay for the hard regulatory constraints and the known-bad lists; the model handles the ranking problem underneath. The realistic goal is not replacing the rules engine but reducing the alert volume it generates while keeping recall, because the alert queue is where the operating cost actually lives.

Fraud scoring vs AML screening: what actually differs

Dimension	Authorisation-time fraud	AML screening
Latency budget	Tens of milliseconds, per transaction	Hours, per batch window
Unit of analysis	Single transaction in context	Counterparty subgraph over time
Dominant compute shape	High-QPS small-batch inference, feature-store lookups	Sparse graph traversal, large sparse matrix operations
Primary fidelity compromise under load	Reduced feature set, cached aggregates	Shortened lookback, truncated traversal depth, segment sampling
Label quality	Late but eventually real (chargebacks, confirmed fraud)	Filings, not confirmed outcomes; true prevalence unknown
Evidence requirement	Reason code	Defensible investigative narrative with supporting transactions
What “too slow” means	Timeout, transaction declined by default path	Batch overruns the window, alerts arrive after shift start

The two share a scoring pipeline in many banks and are budgeted as one line item. They should not be tuned as one workload. The fraud path is latency-bound at small batch sizes; the AML path is throughput-bound on sparse and irregular structures. Optimisations that help one frequently do nothing for the other.

Where the compute ceiling actually sits

Once you accept that fidelity is being traded for time, the useful question becomes where the time is going. In the pipelines we have profiled, the answer is rarely “the model is too big.”

Sparse and irregular structure dominates the AML side. Counterparty graphs are extremely sparse, and the naive implementation — dense adjacency, or gather operations with poor locality — wastes most of the memory bandwidth it consumes. Sparse-matrix routing, better partitioning of the graph across devices to keep traversals local, and batching neighbourhoods by degree rather than by arrival order tend to be the highest-leverage changes. This is an algorithmic gain, not a micro-optimisation, and it is where the profile-first approach to GPU performance engineering earns its keep.

Tensor-core utilisation is often far below what the hardware allows. Tabular and graph workloads frequently run in FP32 out of habit, on shapes that do not align to the tensor-core tiling requirements, through kernels that were never fused. Moving eligible parts of the graph to mixed precision, letting torch.compile or a TensorRT engine fuse the elementwise chains around the matrix multiplies, and padding shapes to alignment often recovers a large multiple on the affected kernels — with the caveat that on a fraud path any precision change has to be validated against score stability, because a shifted decision boundary is a compliance event, not a rounding error.

Multi-GPU scheduling is usually where the batch window is lost. A nightly AML run that overruns is frequently not saturating its devices at all; it is serialising on feature materialisation, waiting on host-to-device transfers over a PCIe topology nobody checked, or leaving devices idle between graph partitions because the scheduler is naive. NCCL collectives across a poorly-mapped topology, or a NUMA-oblivious data loader feeding four devices from one socket, will cap throughput well below what the accelerators can deliver.

Evidence class for this section: observed pattern across GPU performance engagements, not a published benchmark. The specific split between these three causes varies substantially by stack, and the ordering above should be treated as where to look first, not as a distribution.

How do you tell hardware capacity from kernel inefficiency?

This is the diagnostic that determines whether the next spend is hardware or engineering. Run it before the procurement conversation, not after.

Diagnostic checklist — capacity-bound or inefficiency-bound?

1. Measure achieved occupancy and memory throughput on the dominant kernels. If the scoring kernels are running at a small fraction of achievable memory bandwidth and the SMs are largely idle, the ceiling is not the device.
2. Check the arithmetic intensity of the graph stage. Sparse gather/scatter that is bandwidth-starved will not improve with a faster device of the same memory class. It improves with better data layout.
3. Time the non-model stages separately. Feature materialisation, joins against the feature store, serialisation, and host-device transfer are frequently the majority of wall-clock in an AML batch. Adding GPUs does nothing for any of them.
4. Plot utilisation across all devices for the full batch window. Idle gaps and staircase patterns mean scheduling, not capacity.
5. Confirm the precision actually executing. A model nominally in mixed precision but falling back to FP32 for unaligned shapes is common and invisible without a kernel-level trace.
6. Establish what fidelity is currently being dropped. Sampled segments, truncated hops, shortened windows — quantified. Without this you cannot price the throughput you recover.
7. Only then size the hardware. If steps 1–6 come back clean and the pipeline is genuinely saturating its devices at full fidelity, the constraint is real capacity and the spend is justified.

The order matters. A team that runs step 7 first buys capacity that gets absorbed by the same inefficiency, and returns to the same conversation a year later with a larger footprint.

What this buys you

The measurable outcomes are specific enough to put in an engagement scope. The share of transactions scored at full feature fidelity rather than sampled. The false-positive rate per alert queue and the analyst hours that queue consumes. Whether the nightly AML batch finishes inside its window with margin, or finishes by having been trimmed.

Where sparse graph and feature routing is done properly, teams typically get to keep longer lookback windows and wider counterparty traversals at the same hardware footprint — an observed pattern in our engagement work rather than a benchmarked figure, and one that depends heavily on how naive the starting implementation was. The recovered throughput has to be spent deliberately: on fidelity, on coverage, or on cost. If it is not allocated explicitly it will be absorbed by the next model version.

This is the same discipline that governs other high-volume scoring workloads in a bank. The compute economics of probability-of-default credit-risk models look different in shape — periodic rather than continuous, with a heavier validation burden — but the underlying question of whether the model or the pipeline sets the ceiling is identical. On the latency-critical end, AI algorithms for stock trading push the same tension to its extreme, where microseconds rather than milliseconds set the budget.

FAQ

How does AI detect fraud and money laundering in financial services?

Fraud detection scores individual transactions in real time against learned baselines — velocity, device, behavioural deltas, merchant context — usually with gradient-boosted trees or sequence models, returning a decision inside a millisecond-scale budget. AML detection works on the counterparty graph in batch, looking for structuring, layering, and mule-network patterns across multi-hop neighbourhoods over a time window. Both produce a risk score that feeds a queue or a decision path; the difference is the unit of analysis and the deadline.

What signals do AI fraud detection models use that rules engines do not?

Rules encode fixed thresholds and lists; learned models add continuous interactions between weak signals, relative baselines specific to each account rather than absolute cutoffs, and — in the AML case — relational structure such as proximity to a cluster that has already generated filings. In practice the two coexist: rules cover hard regulatory constraints and known-bad lists, while the model ranks underneath to cut alert volume without losing recall.

How is fraud detection different from AML detection in latency and evidence terms?

Fraud scoring runs per transaction inside tens of milliseconds and needs a reason code. AML screening runs in a batch window measured in hours, operates over subgraphs rather than single transactions, and must retain the specific traversal and transactions behind a score so an investigator can write a defensible narrative. They are often budgeted as one pipeline; they should not be tuned as one workload, because one is latency-bound at small batch and the other throughput-bound on sparse structures.

What limits detection quality — labels, drift, or the compute budget?

All three, but the compute budget is the one that gets misattributed. Label scarcity and concept drift are real and are handled as modelling problems. Sampling, shortened lookback windows, and truncated graph traversals are also detection-quality decisions, and they are usually made to fit a deadline rather than for statistical reasons — which means they never appear in the model documentation.

How do you tell whether a fraud/AML pipeline is hardware-bound or kernel-bound?

Profile before you procure. Measure occupancy and achieved memory bandwidth on the dominant kernels, separate the non-model stages (feature materialisation, joins, transfers) from model time, plot per-device utilisation across the full batch window to expose scheduling gaps, and confirm which precision is actually executing. Only if the pipeline is genuinely saturating its devices at full fidelity is the constraint real capacity.

Where does sparse and multi-GPU work recover the most throughput?

On the AML side, sparse-matrix routing and graph partitioning that keeps traversals local usually give the largest algorithmic gain, because naive dense or poorly-localised implementations waste most of the bandwidth they consume. Tensor-core alignment and kernel fusion recover more where tabular scoring dominates. Multi-GPU scheduling — topology-aware placement, avoiding NUMA-oblivious data loading, eliminating idle gaps between partitions — is frequently where an overrunning nightly batch loses its window.

What should a bank check before buying hardware to hit an AML deadline?

Work through the seven-step diagnostic above in order: kernel occupancy and bandwidth, arithmetic intensity of the graph stage, timing of non-model stages, per-device utilisation across the window, actual executing precision, and a written inventory of the fidelity currently being dropped. Hardware sizing is step seven, not step one. Buying capacity ahead of that inventory means the new footprint absorbs the same inefficiency.

The decision nobody writes down

Somewhere in most fraud and AML stacks there is a configuration value — a lookback in days, a traversal depth, a sampling rate — that was set to make a deadline and has never been revisited. It is a detection parameter being used as a throttle, and it is invisible in every artefact the model-risk function reviews.

Finding those values, pricing what they cost in coverage, and establishing whether the compute ceiling behind them is real or self-inflicted is a bounded piece of work. If your fraud or AML scoring pipeline is sampling transactions or shortening feature windows because of a compute ceiling rather than a detection decision, a GPU Performance Audit separates the two before the next infrastructure spend.