Compliance teams spend most of their review time reading and writing: pulling facts out of onboarding documents, piecing together a customer's history, and turning alerts into a narrative an examiner can follow. Large language models are good at that work. It is also work where a confident, wrong sentence can end up in a regulatory filing.
This post is for compliance leads and product owners deciding where an LLM belongs in KYC and AML reviews, as part of SI in fintech products. It covers the useful jobs, the decisions that must stay with people, what US regulators have said, and the controls to build in before a pilot. It is engineering guidance, not legal advice: your BSA officer and counsel decide what your program requires.
Where LLMs help in KYC and AML work
The pattern that works is narrow: the model reads, extracts, summarises and drafts, and an analyst checks and decides. Five uses fit that pattern well.
- Summarising customer due diligence files. An onboarding or periodic review file can run to dozens of documents. A model can produce a structured summary (ownership, business activity, expected transaction profile, open questions) with every statement linked to the page it came from, so the analyst starts from a map rather than a pile.
- Extracting entities from documents. Names, dates of birth, registration numbers, addresses, directors and beneficial owners can be pulled from certificates of incorporation, statements and invoices into the fields your screening and case systems already use. Extraction is easier to test than free text, because each field is either right or wrong.
- Drafting alert narratives and SAR-style case summaries. The model assembles a first draft of who, what, when, where and why from the case record, in your house format. The analyst edits it, adds judgement and owns the final text. A draft that spares the analyst a blank page is the goal; a draft that is filed unread is the risk.
- Triaging alert queues. A model can group related alerts, attach context and suggest an order of review. It should change the order in which people look at alerts, not whether anyone looks. Closing alerts automatically on a model's say-so is a different and much higher-risk design.
- Explaining why a rule fired. Monitoring rules are often opaque to the analyst working the alert. Given the rule logic and the triggering transactions, a model can explain in plain English what the rule detected.
Each of these leaves a person in charge of the outcome. A quick test for any proposed use: what happens when the model is wrong? If an analyst would notice and fix it, you are on safe ground. If nobody would know, redesign it.
Can LLMs be used in KYC and AML reviews?
Yes, for reading and drafting work that an analyst checks: summarising customer due diligence files, extracting entities from documents, drafting alert narratives and SAR-style case summaries, ordering alert queues and explaining why a monitoring rule fired. Decisions with legal accountability, such as filing a suspicious activity report, closing an account or setting a customer risk rating, should stay with named people and be enforced in the system. Build in an audit trail, source citations, recorded sign-off, bias testing, confidentiality and data residency checks, and model risk governance.
The decisions that must stay with accountable people
Some decisions carry legal accountability that belongs to named people and to the institution, not to a vendor's model. Three come up in almost every review.
- Whether to file a suspicious activity report. Under FinCEN's rules, a bank must file a SAR no later than 30 calendar days after it first detects facts that may justify one. The decision to file or not, and the reasoning behind it, belong to your investigators and your BSA/AML function. A model can draft; it should not decide, and it should never submit.
- Closing or restricting an account. Exiting a customer affects their access to financial services and carries legal and reputational consequences. The model can assemble the evidence; a person with the authority makes the call and records why.
- Setting or changing a customer risk rating. Risk ratings drive the depth of due diligence and monitoring for the life of the relationship. A model can point out factors the analyst may have missed, but the rating should come from your methodology and be approved by a person.
Enforce this in the system, not only in policy. The model should have no tool that files, closes or re-rates anything. Those actions sit behind a separate permission held by named roles, with the model's draft shown next to the sources it used. The approval patterns in human-in-the-loop design for SI agents apply directly: require an explicit decision, show the evidence, and make rejecting a draft as easy as accepting it.
The model can prepare the case. A person signs it.
What US regulators have said about innovation in AML
US regulators have encouraged new technology in AML for several years while leaving the obligations themselves unchanged. Three statements are worth knowing precisely.
- In December 2018, FinCEN and the federal banking agencies issued a joint statement encouraging banks to consider and responsibly implement innovative approaches to BSA/AML compliance, naming artificial intelligence among them. It says pilot programs should not in themselves attract supervisory criticism even if they fail, while banks must keep meeting their obligations and weigh information security, third-party risk and privacy.
- In April 2026, FinCEN proposed a rule to refocus AML/CFT programs on effectiveness. One factor its Director would consider before an enforcement or significant supervisory action is whether a bank is using innovative tools such as artificial intelligence that demonstrate the effectiveness of its program. This is a proposal: comments closed on 9 June 2026, so check whether a final rule has been issued before you rely on it.
- Also in April 2026, the OCC, Federal Reserve and FDIC replaced their 2011 model risk guidance and withdrew a 2021 interagency statement on model risk for BSA/AML systems. The new guidance leaves generative and agentic models outside its scope, and the agencies have said a request for information on banks' use of these models is planned. FinCEN's proposal separately notes industry concerns about applying model risk principles to AML programs.
Read together, the message is encouragement with conditions. Regulators welcome tools that make a program more effective, but nothing in these statements moves the filing decision, accountability for the program or its records away from the institution.
Controls to build in from the first pilot
These are cheaper to design in than to retrofit after an examiner asks.
- An audit trail. For every summary and draft, record the inputs, the prompt template and model version, the sources retrieved, the output, and the analyst's edits and approval, all under one case id. We cover the detail in what an LLM audit trail in fintech should record.
- Source citations. Every factual statement in a summary or narrative should point to a document, page or transaction id. Reject outputs that cite nothing, and test that each citation actually supports the sentence it sits under.
- Human sign-off. Record who approved, what they saw and what they changed. Watch how heavily analysts edit drafts over time: a falling edit rate can mean better drafts or less careful review, and you need to know which.
- Bias testing. Names, nationalities, languages and document quality vary widely in KYC work. Test whether extraction accuracy, summary quality and triage order differ across those groups, and keep the results with the model's documentation.
- Confidentiality and data residency. Under FinCEN's rules, a SAR and any information that would reveal its existence are confidential, and existing rules and guidance generally prohibit sharing SARs with personnel outside the United States except in limited circumstances. Before case data reaches any model, settle with counsel where the model runs, which provider staff could see the data, whether it is retained or used for training, and which regions may process it.
- Model risk governance. Generative models sit outside the new interagency guidance, but they still belong in your model inventory, tested before release, monitored in use and changed under control. Treat a prompt change or a provider model update as a change that needs evaluation evidence, as in an eval-first release process.
One risk is specific to document work: customer-supplied files can contain text written to steer the model, such as an instruction hidden in a bank statement. Test for it with something like our prompt injection testing checklist before any upload reaches a model.
Questions to settle before a pilot
- Which single task are we piloting, and what does a good output look like? Write it down with worked examples before anyone builds.
- Who owns the decision downstream of the model, and how will we show they reviewed the draft rather than approving it unread?
- What test set will we use? Include past cases your senior analysts have already worked, with their outcomes, and the awkward ones.
- What data will the model see, where is it processed, and has counsel signed off on SAR confidentiality?
- What would make us stop? Agree the error rates and failure types that pause the pilot before it starts.
- How will the pilot run alongside existing processes, so the program does not depend on it until it has proved itself?
The build itself is an ordinary LLM application with tighter controls. The harder work is agreeing these answers with compliance and risk first.
Where Octalcode fits
Octalcode is a studio in Lahore, with a US presence in Austin, that builds LLM applications, SI agents and RAG systems. For review assistants like these, we design for the model to draft and the analyst to decide, with citations, audit trails and evaluation planned from the start.
Given the confidentiality rules above, expect any offshore team, ours included, to build and test on synthetic or masked data while live case data stays in your environment. We sign an NDA before seeing any client data and limit access to the project team. If you are weighing a pilot, we are glad to work through the questions above with your compliance team first.