arXiv 2605.11232v1May 11, 2026

Rethinking LLMOps for Fraud and AML: Building a Compliance-Grade LLM Serving Stack

Prathamesh Vasudeo Naik, Naresh Dintakurthi, Yue Wang

Brief context

Publication timing, weekly edition context, and source links for this brief.

Published

May 11, 2026, 8:47 PM

Current score

84

Original paper

The executive brief below is grounded in the source paper and linked back to the arXiv abstract.

Fraud detection and anti-money-laundering (AML) compliance are high-value domains for large language models (LLMs), but their serving requirements differ sharply from generic chat workloads. Compliance prompts are often prefix-heavy, schema-constrained, and evidence-rich, combining reusable policy instructions, risk taxonomies, transaction or document context, and short structured outputs such as JSON labels or risk factors. These properties make prefix reuse, KV-cache efficiency, runtime tuning, model orchestration, and output validation first-order systems concerns. This paper introduces a workload-aware LLMOps stack for fraud and AML workloads using self-hosted open-weight models such as Meta Llama and Alibaba Qwen. The stack combines vLLM-style runtime tuning, PagedAttention, Automatic Prefix Caching, multi-adapter serving, adapter and prompt-length-aware batching, sleep/wake lifecycle management, speculative decoding, and optional prefill/decode disaggregation. To avoid exposing institution-specific data, the reproducibility track converts public synthetic AML datasets, including IBM AML and SAML-D, into prefix-heavy compliance prompts with reusable policy text, transaction evidence, typology definitions, and schema-constrained outputs. We also incorporate an LLM-as-judge quality gate using deterministic compliance checks, reference metrics, expert-adjudicated calibration data where available, and multi-judge rubric scoring. Across public-synthetic AML workloads and controlled serving benchmarks, workload-aware tuning improved throughput from 612-650 to 3,600 requests/hour, reduced P99 latency from 31-38 seconds to 6.4-8.7 seconds, and increased GPU utilization from 12% to 78%. These results show that regulated LLM performance is a workload-design, serving-optimization, and quality-gating problem, not only a model-selection problem.

Score 84Full-paper briefinferenceinframodelsdata

Executive brief

A short business-reader brief that explains why the paper matters now and what to watch or do next.

Why this is worth your attention

Fraud and AML LLM deployments may be bottlenecked less by model choice than by serving design: repeated policy text, long evidence packets, and short JSON outputs create a workload that generic chat stacks waste GPU time on. The paper reports that tuning around that shape—prefix caching, paged memory, adapter-aware batching, and output validation—lifted throughput about 5.5–5.9× and pushed P99 latency from half a minute to single digits on synthetic AML workloads. If this holds on real bank traffic, compliance teams get a more credible path to self-hosted LLM assistants without linear GPU spend; the open question is whether the same gains survive institution-specific data, controls, and investigator workflows.

  • The practical implication is not just faster AML prompts; it is that some compliance LLM capacity may be unlocked by serving engineering rather than buying more GPUs or switching models. The paper’s controlled benchmark projects roughly 10 GPUs falling to 3–4 for the same workload shape, but that projection needs validation against real traffic.
  • For fraud and AML use cases, ask whether a vendor supports prefix caching, paged memory, adapter-aware and prompt-length-aware batching, and schema-valid goodput reporting. Raw tokens per second is the wrong buying metric if malformed JSON or unsupported risk factors still create manual rework.
  • A serious deployment should show pre-production gating, investigator adjudication, deterministic schema checks, rollback criteria, and shadow monitoring—not just a model accuracy score. The paper is strongest when it treats LLM outputs as regulated workflow artifacts that must be validated before they hit operations.
  • The strongest evidence is serving-stack efficiency on public synthetic data, not field proof that models make better fraud or AML decisions. LLM-as-judge and small quality pilots are useful screening tools, but the paper itself leaves human adjudication and recalibration in the loop.
  • If long evidence-heavy requests and short JSON outputs share the same serving lane, latency can be dominated by queueing and head-of-line blocking. The next useful signal is whether platforms make prefill/decode separation and cross-worker cache reuse stable enough for regulated production, not just benchmarkable.

Evidence ledger

The strongest claims in the brief, along with the confidence and citation depth behind them.

capabilityhighp.1p.3

Fraud and AML LLM serving has a distinct workload shape: long repeated policy/evidence prefixes and short structured outputs, making generic chat-serving assumptions inefficient.

inferencehighp.5

Workload-aware serving optimizations produced large throughput, latency, and utilization gains in controlled public-synthetic AML benchmarks.

strategichighp.4

The proposed stack treats output validation and release gating as first-order requirements for regulated workflows.

caveathighp.1

The main external-validity caveat is that the reproducible evidence uses public synthetic AML data rather than proprietary institution data.

Related briefs

More plain-English summaries from the archive with nearby topics or operator relevance.

cs.DC

Compliance-Scored Best-of-N Guardrail Orchestration for Multimodal Document Generation in Payments Dispute Defense

Nataraj Agaram Sundar, Tejas Morabia

cs.LG

FlowBank: Query-Adaptive Agentic Workflows Optimization through Precompute-and-Reuse

Lingzhi Yuan et al.

cs.AI

Cascading Hallucination in Agentic RAG: The CHARM Framework for Detection and Mitigation

Saroj Mishra

cs.CV

Cosmos 3: Omnimodal World Models for Physical AI

Aditi et al.

Thank you to arXiv for use of its open access interoperability. This product was not reviewed or approved by, nor does it necessarily express or reflect the policies or opinions of, arXiv.
LightDark