Local LLMs for AML: do they work in practice in 2026?

Back in 2023, we ran a first experiment on Large-Language-Models (LLM) for Anti Money Laundering (AML) and Financial Economic Crime (FEC) compliance challenges (i.e. “Local LLMs for AML”). This followed on the launch of ChatGPT in late 2022, and the conclusions then were somewhat sobering. The honest summary then was that LLMs, as general-purpose instruments, were being asked to do a job that smaller, task-optimised models did better, cheaper, and more reliably.

Fast forward by three years, and a lot has changed. Developments on both frontier models such as Claude (Anthropic) and ChatGPT (OpenAI) have gone into overdrive. Furthermore, local LLM models have become both prolific and much more usable, rivalling closed-source hosted models (e.g. Kimi 2.6 by Moonshot AI). Furthermore, the world is fully on board with the AI hype-train, and set to absorb multiple stock market spectacles which (if successful) will further catapult the Artificial Intelligence (AI) development and buildout of these incumbents.

Contrary to the enthusiasm, real-world headlines on LLM model implementation failures remain. We ourselves have observed AI spending in the AML context running into legacy financial industry challenges, or faced with a rapidly changing cost landscape of hosted frontier models. In fact, frontier AI LLM models may even find themselves facing export restrictions nowadays, further creating an unreliable environment for business continuity.

The ‘build it’ strategy of Local LLMs for AML

Second, pricing is up-front and predictable, making business cases and project management much more straightforward. Third, the enormous volume of operational AML work, potentially even expanded in depth with new AMLR/AMLA regulation and technical standards, lend themselves well to AI augmentation.

Most published LLM-for-AML research either uses synthetic data or measures only performance rather than operational alert handling quality; this study does neither. This article explores a real-world business application of local LLM AI models in the AML domain in 2026. The question we seek to answer here is: can a local LLM AI model in 2026, used in a scoped and specific process-implementation, be a credible accelerator for operational AML work?

Where LLMs apply well to AML

Financial institutions operate automated client and transaction screening and monitoring systems. These generate alerts when a transaction or client potentially matches an entity (person, company, vessel, etc) on a sanctions list or display some sort of behavioural risk typology. These systems are deliberately calibrated to be sensitive, because missing risk signals is detrimental to your income statement and reputation, or may even block a financial institution from launching new products. Naturally, this has resulted in an oversized number of financial industry staff being dedicated to the AML, Sanctions, and compliance domain².

Each alert, customer file, or case, will require a human decision. In practice, an alert handler will typically follow something like the below process flows:

It is these operational end-to-end processes that LLMs are (in theory) well-suited to augment. LLM AI models should have the ability to ingest structured and unstructured data, apply reasoning across it, and produce structured written outputs. The question remains whether such models can do this with the accuracy, consistency, and low degree of missed risk signals the regulated environment demands.

Our approach: building a realistic test dataset

As part of our commercial solutions portfolio, we maintain a database of (counter)parties across the globe with potential AML and sanctions risks. This includes a consolidated sanctions dataset of over 55,000 entries drawn from 12 sources we deem leading in an EU sanctions landscape³. From this dataset, we draw a sample of 300 entities (individuals, vessels, businesses, crypto wallet addresses, etc.)⁴. The sample is human curated to ensure adequate representation across entity types, list sources, and metadata completeness levels. This sample serves as the basis for our alert simulation.

Note that we make this experiment specific for a sanctions compliance challenge. Given the methodology described here, we believe results for L1 (interesting / not interesting) Transaction Monitoring (TM) alert curation should be analogous to the findings of this study, if local LLMs for AML in TM processes are pre-trained with operational guidance specific to the financial institution.

There is a reason sanctions screening and filtering alerts require human review: in practise they are rarely clear-cut cases. Operational analysts are presented with partial matches, transliteration variants, typographic inconsistencies, date-of-birth mismatches, and address fragmentation. To replicate this, we apply five categories of data manipulation to the sampled entities:

• Entity type mismatches: changing the type of entity (individual, vessel, business, crypto wallet, etc) matched
• Date of birth / incorporation mismatches: modification of day or month components, substitution of year digits, and removal of date components to leave only a partial date
• Changing of name elements: character transposition, abbreviation of names, and omission of certain name elements
• Scrambling of business names: changing business legal form, imputing/removing name elements
• Multiple mismatches: combination of some, or all of the above

This all basically mirrors traditional sanctions screening benchmarking services offered by many firms. The added twist is that we do not benchmark the effectiveness of alert generation in this study, but the automated operational handling by local LLMs for AML purposes.

Each entity is scrambled using one or more of these methods, and the resulting entries are labelled with a human-labelled ground truth: true positive (the scrambled entry would constitute a match to a sanctioned entity; this includes a potential match where a conclusion cannot be drawn based on available information) or false positive (the scrambled entry does not match the original sanctioned entity on the available evidence). The question we then test is how closely various LLM models and configurations replicate that human judgement, and what the quality of that judgement is.

Models tested

We strive to both make this test reproducible by compliance teams without access to specialist GPU infrastructure, while testing a several model types⁵. For that reason, we focus our testing on LLM models operable on commercially widely available hardware⁶, available through open-source licensing, which were built with different use cases in mind. The models included are:

Each model receives a similar structured prompt per alert, containing: the scrambled entity data, the relevant sanctions list entry (name, geographies, listed identifiers, etc.), and a request to produce a structured conclusion, including the classification (true positive / false positive) and a short written rationale. Note that the actual prompt is not exactly the same for all models, since we found that reasoning LLM models may react unexpectedly to some prompt constraints (e.g. counterproductively taking a lot of time overthinking explicit word count limits). Thus, each model has a slightly tweaked prompt in order to get at the best answer the model could give. We ran at least 3 prompt variants for each model and display the results from the best run.

Performance of local LLMs for AML

One would be tempted to think that the baseline for these local AI models is 100% adherence to the human judgement benchmark. In practise however, financial institutions set quality acceptance levels at 95% first-time-right analysis conclusions for AML operations (here: accuracy). This goes hand-in-hand with an accepted 5% odds of false-negatives1⁹. Hence, our local LLMs for AML should strive for these levels of performance.

In addition, operational quality of conclusions and investigations is typically monitored on a scale: (1) sufficient, (2) sufficient with observations, and (3) insufficient (rework). Our QA scoring¹⁰ reflects this, where categories 1 and 2 are counted as a passing score. Let’s evaluate:

Outcomes of local LLM AI agent classification of sanctions screening matches¹¹¹²

Observations on the outcomes of the performance data:

• Model selection matters: model testing and selection for AML use cases of LLMs is crucial to arrive at the right fit for the case at hand. Some institutions may favour DeepSeek’s extremely cautious behaviour leading to the lowest level of operational performance gain, whereas other institutions may favour Granite or Qwen’s accuracy, at the cost of a potential extra false negatives if these can be circumvented through other risk mitigants
• Performance gaps can be bridged: At first glance, it appears the models are underperforming AML quality standards (95% accuracy, 5% false negatives). However, the reader should be aware this exercise pertains to non-finetuned models, provided with ‘single-shot’ prompts. Other studies find that accuracy can be increased by an approximate 5-10 percentage points¹³ by providing LLM models with a number of examples worked into prompts. In addition, providing reference documentation input (e.g. in-house policies) for these models may further improve their accuracy.
• Answer quality differs greatly: Qwen’s 3.5 9B answers generally all cite the available data, provide a substantiated reasoning, and a general conclusion. Conversely, Granite 4’s answer quality appears highly sensitive to input. We found allowing for longer answers did not necessarily improve quality, and increased odds of generating general disclaimers and lowering accuracy (i.e. consistently is affected). We also found answer quality differs per type of match manipulation, further indicating that worked examples may help elevate quality.
• Positioning in the workflow dictates operational AML benefits: the actual operational performance gains will depend highly on the model’s positioning in a workflow: as a pre-filter, a first-level analyst requiring QA, or autonomous decision maker. The latter remains unadvised given the upcoming EU AML Regulation prescribes human-in-the-loop standards for AML decision making.¹⁴
• Runtime costs are not equal: As stated in the results table, Qwen 3.5 9B took so much longer to run these samples that it is worthwhile to determine what model has the actual speed of inference required to support your AML process requirements.

Note on the legal (EU) requirements for humans-in-the-loop for AI systems in AML
The EU AI Act lists transaction monitoring and sanctions screening as high-risk AI applications (Annex III), triggering mandatory human oversight obligations under Article 14. The AMLR adds a parallel layer: Article 76(5)(b) refers to “meaningful human intervention” in automated processing, though how broadly this applies to AI-assisted alert handling remains subject to interpretation. We expect AMLA’s forthcoming technical standards to address this explicitly.

A full analysis of the interplay between the EU AML regulations and AI act is beyond the scope of this article. For non-academic purposes, our interpretation of the implication is straightforward: AI-assisted alert handling is permissible. An AI-autonomous alert disposition system without documented human review, has a shaky legal foundation.

Key take-aways for decision makers

It is time to take a step back from the technical details and consider what these findings mean in practise for an AML workflow. We set out to answer: can a local LLM AI model in 2026 be a credible accelerator for operational AML work?

Three aspects determine what the answer to that question should be:

1. Desired outcomes must be well-defined: Our findings show that local LLMs for AML can handle specific tasks with clear outcome expectations quite well when suitable guardrails are in place. Organizations that are willing to invest in rigorous model design, testing, and governance will see results. On the other hand, organizations expecting local LLMs to operate reliably from vague instructions will be disappointed.
2. Solution design needs to be driven by compliance goals: Model selection is crucial to aligning performance with the compliance objectives of the AML workflow being augmented. A model whose answer style or output quality does not meet compliance expectations will introduce new forms of operational AML risk after implementation (false-negatives); not eliminate existing ones.
3. Operational volume is needed to drive the business case: The analysis shows that humans will need to remain in the loop for oversight, decision-making, and QA purposes. That makes local LLMs most optimally suited to high-volume, structured work processes where the efficiency gain is large enough to justify the governance investment.

The above can be treated as a check-off list: answer all three with ‘Yes’, make sure to follow up these three primary findings, and indeed the right Local LLM should be a genuinely viable accelerator to operational AML work.¹⁵

Concluding remarks

So, we get to finally answer our main question of this article: can a local LLM AI model in 2026 be a credible accelerator for operational AML work? In a well-scoped operational process tailored to your financial institution, the honest answer in 2026 is: Yes

---

Interested to find out if local LLM AI models are the right fit to accelerate your AML processes?

Footnotes

1. We did not even even present our findings from benchmarking Llama2 in the AML context back then as they were so underwhelming compared to the other benchmarked models ↩︎
2. As highlighted by the Dutch Financial Times, here: https://fd.nl/opinie/1381326/bij-opsporing-witwassers-zijn-onze-verwachtingen-van-banken-onrealistisch ↩︎
3. Sources include major international programs such as EU Consolidated Lists, UK OFSI, UN Security Council, US OFAC SDN, and other more specialized or regional lists ↩︎
4. We deliberately choose not to mirror the class-imbalance present in actual sanctions screening and transaction filtering settings. Instead, our sample includes approximately 40% true-positive cases, and 60% false-positive cases. This allows us to gauge the performance on both types of outcomes, and understand what drives misclassifications of either for the researched local LLMs ↩︎
5. This also means we do not pre-train or fine-tune these models, but rather test the models straight out-of-the-box. In addition, no additional messages aside from the prompt are passed to the LLM. This effectively makes this performance test a minimum baseline achievable to any financial institution, which can be improved through providing additional context. ↩︎
6. This rules out open source and locally deployable frontier models such as Kimi 2.6, which while competitive with the very best hosted closed-source frontier labs models, will require a hardware setup running multiple H200 GPU’s ↩︎
7. During the process of researching this article, Granite 4.1 has been launched by IBM featuring a competitive 8B parameter model. Reading through various benchmarks, it is expected to improve accuracy with a number of percentage points over the Granite 4 7B (Tiny) model variant used in this analysis ↩︎
8. For further research, see HuggingFace: https://huggingface.co/blog/huggingface/one-year-since-the-deepseek-moment ↩︎
9. For ease of reading and to align with more common AML practice terminology, the ‘precision’ and ‘recall’ terms are not used here ↩︎
10. Quality was scored with a structured approach. Answers by the LLMs which considered all available data, while deriving the correct conclusion score 1, while deriving the wrong conclusion score 2. Answers by the LLMs which considered some available data, while deriving the correct conclusion score 2, and deriving the wrong conclusion score 3. Answers by the LLMs which misinterpret the data or incorrectly re-state the input data score 3. ↩︎
11. Accuracy is defined here as the number of answers classified (true positive/false positive) similar to a human reviewer. This should be comparable to a human reviewer first-time-right score ↩︎
12. False negatives are defined here as the percentage of false negative classifications (prediction as false positive, while it actually should have been a true positive) compared to the total number of predictions in the sample ↩︎
13. For instance, Gyawali, Caragea and Vasenkov (2025) find this improvement in model accuracy when including training examples into prompts (figure 4): https://arxiv.org/html/2510.23464v1#Sx5.F4 ↩︎
14. We have written before on the difficulty of unraveling various new EU legislations, and the interplay between the AI act and the AML Regulation is similarly difficult. Our conclusion here is based on the work of Magdalena Brewczyńska ↩︎
15. Naturally, this should also take into account any other compliance requirements to the fielding of new technology in the AML domain ↩︎
16. See introduction ↩︎