I have worked on KYC and AML from two opposite ends.

A few years ago, I helped build a digital bank from scratch. It had no branches, no history and no customers, so everyone who signed up was a stranger.

Today, I work on KYC for a large, established bank, and the situation is reversed. The bank has years of transaction history for its clients, data from public registries, and AI agents that search the web for news about them. It is the same acronym, but the engineering work has very little in common.

When the bank knows nothing

A bank with no customers does KYC at a single moment: onboarding. The customer fills in a form and photographs their ID document, and that is all the information you get.

We didn’t build the checks ourselves. We bought them, and the flow looked like this:

1. The customer enters their personal details in the app.
2. They upload a photo of their ID document.
3. We send everything to a third-party KYC provider through its API.
4. The provider runs document verification, face matching, and sanctions and PEP screening.
5. We receive a report with the result and the evidence behind it.
6. Our backend processes the response and approves the customer, rejects them or routes the case to a human reviewer.

The provider maintained document templates for every country, ran the fraud checks and kept the watchlists up to date. For a bank with zero customers, building that in-house would have made no sense.

We still owned the integration and every decision built on top of it. The provider returned a verdict and evidence; we decided which results to accept, what went to manual review, and what to store and for how long. That matters because the regulator holds the bank responsible, whichever provider it uses.

Most of the work was plumbing: asynchronous responses, a customer stuck in a pending state because a callback never arrived, a blurry photo, a name with diacritics that did not match the document. None of it is interesting, but it decides whether onboarding takes three minutes or three days.

The limitation of this model is that it only captures the customer on day one. Once the account is open, you know who the person is, but you have no idea what they will do with it.

When the bank knows too much

An established bank has the opposite problem. It has plenty of data about each client, and the hard part is working out which of it matters.

For an existing client, the bank can see:

• Transactions: where money comes from, where it goes and how those patterns change over time.
• The profile the client declared at onboarding, often years earlier.
• Public registries, including company records, beneficial ownership and insolvency proceedings.
• The web: news articles, court reports and anything else that mentions the client by name.

KYC at this stage runs for as long as the client stays with the bank. Clients are reviewed periodically, or when an event triggers a review, and each review asks whether the client still matches the profile on file and whether anything new has come up that warrants concern.

That is the work we hand to AI agents. One agent searches the web for adverse media, another checks public registries and a third compares transaction behaviour against the declared profile. An analyst reads the combined output and makes the decision.

Large volumes of unstructured text with a human reviewer at the end sound like a good fit for language models, and in many ways they are. The problems, though, are different from the ones at onboarding:

• Name matching. There are a lot of people called Jozef Novák, and the agent has to decide whether an article is about your client or someone else.
• Relevance. A ten-year-old article about a dispute that was settled long ago may or may not be a risk today.
• Nondeterminism. Run the same client through the system twice and you can get two different summaries.
• Explainability. An auditor will not accept “the model rated this client as medium risk” as a reason.

Because the data belongs to the bank, there is no provider to buy this from. The bank has to build it.

How the two compare

	Greenfield bank	Established bank
When	Once, at onboarding	For as long as the client stays
Data	What the customer provides	Everything the bank has collected
Core question	Who are you?	Has anything changed?
Who builds it	The provider	The bank
Hard part	Integration, UX and edge cases	Judgment, noise and consistency
Failure mode	A legitimate customer is stuck or rejected	Real risk is buried in noise

Onboarding KYC is an integration problem with predictable outcomes: you call an API, handle a known set of states and move on. Ongoing KYC asks for judgment on messy, incomplete evidence. Language models help most with that kind of work, and that is also where their mistakes are hardest to spot.

Lessons learned

1. At onboarding, buy the checks and put your effort into the integration and the decisions around it.
2. With existing clients, most of the work is filtering. The useful question is what to leave out of the analyst’s view.
3. Keep a human in the loop who actually reviews the output. The agent gathers and summarises; the analyst decides.
4. Define what a correct output looks like before you build. Without that definition you cannot test the agent, and you cannot tell a bug from intended behaviour.
5. Store the evidence behind every decision, such as a link, a transaction or a registry record, so you can show it later. A score on its own is not enough.

This is the first post in a series on KYC. The next ones cover integrating a KYC provider, adverse media screening with AI agents, transaction data as a KYC signal, and testing a language model that rates customer risk.