AI Fraud Detection in Banking: An AML Solution Case Study

Every large bank runs a transaction monitoring engine that flags suspicious activity, and almost every one of them drowns in noise. AI fraud detection in banking became urgent for our client because their legacy rules were producing alerts that were 96 percent false positives. That single number was quietly costing them millions in wasted investigator hours every year.

When a leading financial services enterprise approached KriraAI, its financial crime team was reviewing tens of thousands of alerts each month by hand. Most alerts led nowhere, yet each still demanded a documented disposition for the regulator. The genuine laundering typologies were buried under noise, and examiners had begun asking hard questions. This blog is the full account of the production system KriraAI designed, built, and delivered to fix that, covering the problem, the architecture, the technology, the delivery journey, and the measured results.

The Problem KriraAI Was Called In To Solve

The bank was operating a transaction monitoring stack that had been layered together over more than a decade. It ran on static, threshold-based rules bolted onto a legacy vendor platform. Every rule fired independently, and every firing became an alert that a human had to clear.

The core failure was not detection; it was discrimination. The rules could not tell a genuinely suspicious pattern apart from ordinary customer behaviour. A salaried customer receiving a slightly larger bonus triggered the same alert weight as a genuine structuring attempt. As a result, investigators spent most of their day closing alerts that were never risky in the first place.

The scale of the waste was severe and measurable. The program generated roughly 41,000 alerts per month against a monitored base of over 40 million daily transactions. Around 96 percent of those alerts were closed as false positives after manual review. Each alert consumed an average of four hours of investigator time across triage, evidence gathering, and disposition notes.

The data that could have solved this already existed, but it was scattered and unused. Customer risk ratings lived in one system, transaction histories in the core banking platform, and counterparty information in a separate correspondent banking database. Nobody had ever connected these into a single behavioural view. The relationships between accounts, the thing that actually reveals laundering networks, were invisible to a rules engine that scored one transaction at a time.

The human cost compounded the technical one. Skilled investigators were burning out on repetitive clearing work instead of genuine investigation. Alert backlogs stretched past the internal service level, which created regulatory exposure on the timely filing of suspicious activity reports. Hiring more analysts only scaled the cost, never the intelligence.

Competitive and regulatory pressure made the status quo unsustainable. The bank's most recent examination had flagged both the false positive rate and the inconsistency of investigator dispositions. Peer institutions were already piloting a machine learning development approach to triage, and the board wanted a defensible, auditable path forward. This was the operational reality when KriraAI began the engagement, and it is a reality that most compliance leaders in finance will recognise instantly as their own.

What KriraAI Built

KriraAI is an AI solutions company that builds and deploys production-grade systems for regulated enterprises, and this engagement sat squarely in that discipline. We designed and delivered a hybrid AI risk scoring layer that sits between the bank's raw transaction feeds and its investigator case management system. It did not replace the regulatory rules, which must remain auditable, but it augmented them with intelligent scoring and triage.

The system does three things in sequence. First, it scores every alert for genuine risk using a behavioural model rather than a static threshold. Second, it maps each alerted entity into its surrounding transaction network to surface hidden relationships. Third, it generates a structured, evidence-backed narrative that gives the investigator a head start on disposition.

At the heart of the AML transaction monitoring solution are three complementary model families working together. A gradient-boosted tabular model handles per-alert risk scoring across engineered behavioural features. A relational graph neural network analyzes the transaction graph to detect structuring, layering, and mule network patterns that single transaction rules cannot see. A retrieval-augmented large language model assembles the investigator's narrative from policy documents, prior cases, and the entity's own history.

The graph component is what made the system genuinely powerful. Traditional rules score transactions in isolation, but money laundering lives in the relationships between accounts. Our use of graph neural networks for fraud detection lets the model reason over multi-hop paths of funds movement across the customer base. It learned to recognise fan-in and fan-out topologies, circular flows, and rapid pass-through behaviour that rules had always missed.

Data flows through the platformend-to-endd in near real time. Transactions stream in from the core banking system as they settle, and features are computed on the fly against both historical and live context. When the legacy rules raise an alert, the scoring service enriches it with a risk probability, a network risk contribution, and the top contributing features. That enriched alert then reaches the investigator with an auto-drafted narrative attached.

The output reaches the people who act on it through the bank's existing case management tool. Investigators did not have to learn a new system; they simply saw smarter, pre-triaged alerts inside the interface they already used. High-confidence, low-risk alerts were bundled for streamlined review, while high-risk alerts surfaced first with full network context. This design choice, delivering intelligence inside existing workflows, is central to how KriraAI approaches AI solutions for the finance industry.

The Solution Architecture Behind AI Fraud Detection in Banking

The architecture was designed as a production system from day one, not a proof of concept. It runs on the bank's private cloud tenancy inside an isolated virtual private cloud with no public endpoints. Every layer was chosen for auditability, low latency, and the ability to survive regulatory scrutiny. The sections below walk through each layer, the design decisions behind it, and how the layers connect.

Data Ingestion and Pipeline

The ingestion layer had to unify streaming and batch sources without ever losing an event. We used change data capture from the core banking database through Debezium, publishing every committed transaction onto Apache Kafka topics. Reference and slowly changing data, such as customer risk ratings and sanctions lists, arrived through scheduled batch extracts from the ERP and correspondent banking systems.

Stream processing was handled by Apache Flink, which computed temporal features over sliding windows as transactions arrived. Batch orchestration for training data and historical backfills ran on Apache Airflow directed acyclic graphs. This split gave us fresh online features for scoring and reproducible offline features for training from the same logical definitions.

Transformation logic was deliberately explicit rather than implicit. The pipeline performed schema normalisation across systems, entity resolution to unify customer identities, and temporal feature engineering for velocity and periodicity signals. Entity embeddings were generated at ingestion time, so the graph layer always had current vector representations to work with.

AI and Machine Learning Core

The machine learning core combined three model families because no single architecture solves AML alone. The tabular scorer used LightGBM trained on several hundred engineered behavioural features. It was chosen for its strength on heterogeneous financial features and its native support for explainability through feature attributions.

The network model was a relational graph neural network built with PyTorch Geometric using a GraphSAGE-style message-passing design. It learned node-level risk representations by aggregating signals across multi-hop neighbourhoods in the transaction graph. Contrastive learning aligned entity embeddings so that structurally similar laundering patterns clustered together in vector space.

The narrative layer used a domain-adapted large language model served through vLLM with quantized weights for cost-efficient inference. It was grounded through retrieval-augmented generation against a vector index of policy documents, typology guides, and prior case dispositions. The vector store used HNSW indexing for low-latency approximate nearest neighbour search over those embeddings.

Integration Layer

The integration layer connected AI outputs to the systems that act on them without disrupting existing workflows. Scoring was exposed through a versioned REST and GraphQL API contract, while internal service-to-service calls used gRPC for low-latency communication. An event-driven design, built on Kafka topics and message queues, decoupled scoring from delivery so neither could block the other.

Delivery into the case management platform was handled through a webhook-based trigger system. When an alert finished scoring, a webhook pushed the enriched payload and drafted narrative into the investigator queue. This pattern lets KriraAI ship intelligence into a legacy tool without rewriting the bank's core operations.

Monitoring and Observability

Monitoring was treated as a first-class part of the system, not an afterthought. Data drift was tracked using a population stability index and KL divergence against training distributions, with alerts on any feature that shifted materially. Model performance was measured continuously against a held-out, human-labelled evaluation set to catch silent degradation.

Operational health was tracked through latency percentiles at p50, p95, and p99, with the scoring service holding p99 latency under 200 milliseconds at production volume. Prometheus and Grafana handled metrics and dashboards, while Evidently produced drift and quality reports. Automated retraining triggers fired when performance crossed defined thresholds, and MLflow governed model versioning and the registry.

Security and Compliance

Security in a banking environment is non-negotiable, the same discipline seen in how banks use voice AI to detect fraud faster, so it was designed into every layer. Access was governed by role-based access control with attribute-level data masking,g so investigators saw only what their role permitted. Model inputs and outputs were encrypted end-to-end, and every scoring decision was written to an immutable, append-only audit store.

Compliance was built around the model risk management expectations of SR 11-7 and the bank's obligations under the Bank Secrecy Act and FinCEN reporting rules. The deployment ran entirely inside a private virtual private cloud with no public endpoints. Full lineage from raw transaction to final score was reproducible, which is exactly what an examiner asks to see.

User Interface and Delivery Mechanism

The delivery mechanism prioritised adoption over novelty. Instead of a new dashboard, the enriched alerts and drafted narratives appeared inside the bank's existing case management interface. A lightweight investigator copilot panel, built as a React component, surfaced the risk score, the top contributing features, and the network view on demand.

This approach removed the change management burden that sinks many AI projects. Investigators kept their existing muscle memory and simply gained better information. That decision was a core reason the system reached full adoption within weeks rather than months.

Technology Stack

Every technology in the stack was chosen for a specific reason given the bank's scale, constraints, and existing environment. The choices below reflect deliberate engineering trade-offs, not defaults.

• Apache Kafka and Debezium were selected for ingestion because change data capture guarantees that no committed transaction is ever missed, which is essential for a monitored base of above 40 million daily transactions.

• Apache Flink was chosen over a micro-batch engine because AML velocity features demand true event-time windowing with low latency, not periodic recomputation.

• LightGBM was preferred over deep tabular networks because it delivers strong accuracy on heterogeneous financial features while remaining fast to retrain and straightforward to explain to model risk validators.

• PyTorch Geometric powered the graph neural networks for fraud detection because it offered mature GraphSAGE-style message passing and scaled to the bank's large, sparse transaction graph.

• vLLM was selected for serving the narrative model because quantized, batched inference kept large language model costs predictable while holding response latency low.

• An HNSW-indexed vector database was chosen for retrieval because approximate nearest neighbour search kept policy grounding fast enough for interactive investigator use.

• MLflow, Evidently, Prometheus, and Grafana together formed the observability and governance backbone, which was mandatory for a regulated deployment.

• Terraform and Kubernetes underpinned the infrastructure because reproducible, declarative deployment inside a private virtual private cloud was a hard requirement for audit and security.

The stack was intentionally boring where reliability mattered and advanced only where advantage justified it. KriraAI holds to that principle across every enterprise AI implementation in finance, because regulated systems reward predictability far more than novelty. The result was a platform the bank's own engineers could operate and defend.

How We Delivered It: The Implementation Journey

The full engagement ran from the first discovery session to production go-live in 22 weeks. KriraAI structured delivery into six disciplined phases so that risk was retired early and surprises did not surface near launch. Each phase produced a concrete artefact the bank could review and sign off.

The delivery phases were sequenced as follows.

1. Discovery and requirements, where we mapped every data source, every existing rule, and the exact regulatory constraints the system had to satisfy.

2. Architecture design, where we produced the layered blueprint, latency budgets, and the model risk documentation plan.

3. Development, where the ingestion, scoring, graph, and narrative services were built and integrated.

4. Testing and validation, where models were evaluated against labelled historical alerts and stress-tested at production volume.

5. Deployment, where the system was rolled out in shadow mode alongside the existing rules.

6. Handover, where the bank's own MLOps and compliance teams were trained to operate and defend the platform.

Real challenges surfaced during delivery, and honest reflection matters more than a tidy story. The first was label scarcity. Confirmed laundering cases were rare, which is normal in AML, so a naive supervised model would have overfit. We addressed this with careful class weighting, synthetic augmentation of typology patterns, and heavy reliance on the unsupervised graph signal.

The second challenge was data quality in the legacy core banking feed. Counterparty fields were inconsistently populated, which broke early entity resolution. We resolved it by building a probabilistic resolution step with deterministic overrides, then validating the merged identities against a sample that the bank's team reviewed manually.

The third challenge was the regulatory defensibility of a black box graph model. Examiners will not accept a score they cannot interrogate. KriraAI solved this by pairing every graph score with human-readable feature attributions and a documented model risk package aligned to SR 11-7. That combination lets the bank explain any individual decision on demand.

The final challenge was proving safety before trusting the system. We ran the platform in shadow mode for eight weeks, scoring live alerts without changing any disposition. Only after the shadow results matched or beat the labelled ground truth did the bank move to production suppression of low-risk alerts.

Results the Client Achieved

The measured outcomes confirmed the business case within the first quarter of production operations. The headline result was a 68 percent reduction in false positive alerts reaching investigators. That directly attacked the 96 percent noise problem the bank had lived with for years.

Investigator efficiency improved just as sharply, echoing how AI is streamlining everyday finance and lending operations elsewhere in banking. Average time to disposition an alert fell from four hours to 35 minutes once the drafted narrative and network context were attached. Across the team, this freed the equivalent of thousands of investigator hours per quarter for genuine, higher-value investigation work.

Detection quality rose even as volume fell, which is the outcome that matters most to a regulator. The graph layer surfaced several previously undetected mule networks that the old rules had never connected. The bank saw a measurable lift in the quality and consistency of its suspicious activity report filings.

The financial and operational picture was equally clear.

• False positive alert volume dropped by 68 percent within the first three months of go-live.

• Average alert investigation time fell by roughly 85 percent, from four hours to 35 minutes.

• The scoring service sustained p99 latency under 200 milliseconds across more than 40 million daily transactions.

• The bank avoided a planned expansion of its investigation team, redeploying capacity to complex casework instead.

These were confirmed outcomes from a completed, in-production engagement, measured over the first full quarter after launch. The bank's examiners responded positively to the auditability and consistency the system introduced. What had been a compliance liability became a defensible, data-driven program.

What This Architecture Makes Possible Next

The platform was engineered to scale and evolve, not to solve one problem and freeze. As transaction volume grows, the Kafka and Flink ingestion layer scales horizontally without redesign, and the model serving tier scales through additional replicas behind the same API contract. The bank can double its monitored volume without touching the core architecture.

New use cases can be added to the existing foundation rather than rebuilt from scratch. The same feature store, graph, and serving infrastructure already support the roadmap for sanctions screening optimisation and customer risk rating refresh. Because the AML transaction monitoring solution was built as reusable layers, each new financial crime use case reuses most of the platform.

The client's two- to three-year AI roadmap now builds directly on this base. Planned extensions include real-time payment fraud scoring, an expanded investigator copilot with conversational case search, and automated quality assurance on filed reports. Each of these plugs into the existing ingestion, graph, and retrieval layers with limited new engineering.

Other financial institutions can apply the same architectural pattern to their own environment. The transferable principle is to augment auditable rules with a graph-aware scoring layer rather than replacing regulated logic outright. Any bank facing high false positive rates and hidden network risk can adopt this blueprint, and KriraAI has designed it to be portable across core banking platforms.

Conclusion

Three insights define this engagement. The technical insight is that money laundering is a network problem, and only a graph-aware model reveals the relationships that isolated rules will always miss. The operational insight is that adoption depends on delivering intelligence inside existing workflows, which is why smarter alerts inside the bank's own case tool reached full adoption in weeks. The strategic insight is that AI fraud detection in banking succeeds only when it is auditable by design, because a score an examiner cannot interrogate has no place in a regulated program.

KriraAI brings this same engineering rigour and delivery discipline to every client engagement, from discovery through model risk documentation to production handover. We build hardened systems that survive regulatory scrutiny and real workloads, not pilots that stall after a demo. That standard is why this leading financial services enterprise moved a compliance liability into a defensible, data-driven advantage. If you are facing a costly, high-stakes AI challenge in your own operations, bring it to KriraAI and let us design the production system that solves it.