Building Predictable AI Economics for Banking Fraud and AML Investigations

Context.

Banks and payment providers already have systems that flag suspicious activity. The expensive part comes next: investigators must review transactions, sanctions data, ownership records, adverse media and jurisdictional context before making a defensible human decision. An AI-native investigation platform was helping these teams assemble evidence and case summaries, processing approximately 2,000 cases a day with a target of at least 5,000 cases a day.

For sanctions screening, the platform had fine-tuned a 9 billion parameter model. A managed custom-model path was estimated at $49,405 per month under sustained target load, while an H100-based option was roughly $118K a year for compute alone. Inference architecture had therefore become a business decision, shaping cost per case, enterprise pricing, gross margin, response-time commitments and dependence on model-hosting providers.

Problem Statement.

AI infrastructure was priced in the wrong unit: Providers expose tokens, compute units and GPU hours. Banking customers buy completed, reviewable investigations. The platform needed a credible cost and capacity model per fraud or AML case

Growth could not come with linear margin erosion: Moving from 2,000 to 5,000 daily cases would be commercially attractive only if model-serving cost remained predictable as customer volume increased.

Token throughput did not represent customer experience: The useful measures were end-to-end turnaround, concurrent case handling, failures and completed requests per day. A fast isolated response could still produce a poor multi-tenant investigation service

Control had to coexist with governance: Self-hosting could improve economics and provider leverage, but performance work could not replace sanctions-model evaluation, evidence provenance or the final human investigation decision.

Outcome/Impact.

180,000 model requests per day benchmarked: A single 48 GB L40S sustained the equivalent daily request capacity at 64 concurrent cases in the selected profile.

Approximately 16-second turnaround: The high-throughput profile established a concrete service-level trade-off rather than relying on theoretical GPU specifications or peak token rates.

Material headroom above the 5,000-case target: The benchmark created a growth path without making premium training-class hardware the default inference choice

A credible alternative to the $49.4K monthly managed path: The team gained evidence to challenge an expensive hosting assumption and evaluate infrastructure in terms of cost per investigation.

Business and engineering aligned on the same AI metrics: Case economics, turnaround, capacity headroom and provider risk became shared inputs to customer pricing, margin planning and bank onboarding

Solution.

We treated the engagement as the design of an AI operating model for financial-crime investigations, not as a GPU procurement exercise.
The business workload came first; model, runtime and infrastructure choices were then tested against it.

Defined the commercial service unit: The benchmark was anchored to a 5,000-case daily target, the expected sanctions-screening execution pattern and client-visible turnaround. This created a common language for product, engineering and finance.
Right-sized the model and hardware together: The BF16 fine-tuned model was loaded with online 8-bit quantisation to reduce memory pressure. A single 48 GB NVIDIA L40S on AWS was evaluated before defaulting to an H100-first architecture.
Benchmarked investigation-shaped workloads: The team tested 16, 32, 64 and 128-way concurrency across single and multi-instance profiles. Request-level reports captured time to first token, end-to-end turnaround, request rate, errors and projected
daily capacity.
Optimised the serving path systematically: The inference runtime, attention backend, model loading and quantisation settings were tuned as measurable variables rather than one-off configuration choices.
Preserved model and provider optionality: The fine-tuned artifacts, serving stack and benchmark evidence remained under the customer's control, creating a repeatable basis for comparing future GPU, runtime and hosting options.

Result.

The result was not simply a faster model. It was a commercially usable operating model for AI-assisted fraud and AML investigations. The platform could plan growth against measured capacity, price services around completed casework and retain leverage over hosting choices, while keeping model-quality validation, evidence provenance and human approval as release gates. The 180,000 figure represents benchmarked model requests; completed investigation capacity depends on the number of model calls used by each workflow.

Take a look at our other work.

Read Case Study

Migrating Monolith Application to Cloud Native Stack.

The client provides cloud and on-premise based Hospital Management Services (HMS) SaaS platform. This HMS serves 800+ B2B customers (tenants), including large hospital chains across the Middle East, Africa, and APAC region. The tech stack for the application is a Java-based backend, JSP-based server rendered UI, Redis, and MySQL as datastores. The HMS platform is deployed as a SaaS and in customers' cloud environments and on-premise data centers.