Anti-Money Laundering Entity Resolution: Seeing the Person Behind the Data

By Steven Renwick, CEO & co-founder, Tilores.

TL;DR: Money laundering is a problem of disguise — criminals hide who the money belongs to, not just where it sits. Anti-money laundering entity resolution recognises that scattered, messy, deliberately inconsistent records all point back to the same real person or organisation, and it is the foundation every other AML control quietly depends on. When you choose a dedicated engine for it, there are really only two serious options to evaluate — Tilores and Senzing — and the one path you should rule out early is building your own.

AML entity resolution

Resolve who everyone is before you screen them.

See real-time anti-money laundering entity resolution on your own data — clean, connected identity feeding your existing sanctions, KYC and transaction-monitoring tools.

Book a demo Get the evaluation build

Resolution path

Fragmented records

aliases · typos · shells

Tilores API

resolved entity

Screening & monitoring

one clean identity

Money laundering is, at its heart, a problem of disguise. Criminals do not hide the money so much as they hide who the money belongs to and how it moves between people and companies. They open accounts under slight variations of a name, register shell companies in different jurisdictions, recruit networks of intermediaries, and spread activity across several banks so that no single institution ever sees the whole picture. The defence against this is rarely a single clever rule. It is the ability to recognise that scattered, messy, deliberately inconsistent records all point back to the same real-world person or organisation. That capability is called entity resolution, and anti-money laundering entity resolution has become one of the most important building blocks of a modern financial crime programme.

This article explains what entity resolution is, why anti-money laundering (AML) is fundamentally an identity problem, how resolving entities exposes laundering patterns that rules alone miss, and — the question that decides everything downstream — which solution to choose.

• What is entity resolution?
• Why is AML an identity problem first?
• How does entity resolution strengthen an AML programme?
• Which laundering patterns does entity resolution expose?
• Why do real-time resolution and external data matter?
• Which entity resolution solution should you choose for AML?
• Why shouldn’t you build your own?
• FAQ

What is entity resolution?

Entity resolution is the process of taking many separate data records and working out which of them refer to the same real-life entity, meaning a single person, company, or account holder. It pulls together names, addresses, dates of birth, phone numbers, email addresses, bank accounts, company numbers, and identifiers from internal and external sources, and decides whether two records are the same entity, different entities, or possibly related. (For a fuller primer, see What Is Entity Resolution?.)

The hard part is that real data is rarely clean. The same person might appear as “Jon Smith”, “Jonathan Smith”, and “J. Smith” across three systems. A company might be listed with a slightly different spelling, an old address, or a transliterated name. Sometimes the inconsistency is innocent: typos, formatting differences, data entered by different teams over many years. Sometimes it is deliberate, because the person filling in the form does not want to be matched to a record that would raise an alarm.

Good entity resolution handles both cases. It uses fuzzy matching to recognise that near-identical records belong together, and it builds a single, trustworthy view of each entity from all the fragments. In an AML context, that single view is what lets a compliance team answer a deceptively simple question: who is this, really, and what else do we know about them?

Why is AML an identity problem first?

Most AML controls assume you already know who you are dealing with. Sanctions screening checks a customer against watchlists. Transaction monitoring flags suspicious patterns of behaviour. Customer risk rating assigns a score based on who the customer is and what they do. Every one of these controls quietly depends on the institution having correctly identified the customer in the first place. The FATF Recommendations frame customer due diligence around exactly this — identifying and verifying the customer and understanding the relationship — and in the UK, Regulation 28 of the Money Laundering Regulations 2017 makes ongoing monitoring and keeping that information up to date an explicit obligation.

When identity is fragmented, the controls degrade in two directions at once.

The first failure is missed risk. If a sanctioned individual appears in your system under a slightly altered name, and your screening only checks for exact matches, the alert never fires. If a customer who was offboarded for suspicious activity simply re-registers with a new email address and a tweaked spelling of their name, they walk straight back in. Without entity resolution tying the new application back to the old record, each re-registration looks like a brand new, low-risk customer.

The second failure is wasted effort. When systems cannot tell that several records are the same person, they generate duplicate alerts, duplicate cases, and a flood of false positives. Investigators then spend their time reconciling records by hand instead of investigating genuine risk. The cost is enormous: industry estimates have long suggested that the large majority of transaction-monitoring alerts turn out to be false positives, and a significant share of that noise traces back to poor identity data.

So before transaction monitoring, before screening, before risk scoring, there is a foundational layer: do we actually know who our customers are and how they connect to each other? Anti-money laundering entity resolution answers that question, and everything downstream gets sharper as a result. (For the operational detail of how this fits a real-time screening flow, see AML and KYC With Real-Time Entity Resolution.)

How does entity resolution strengthen an AML programme?

A single customer view

The most immediate benefit is a single customer view: one resolved profile that pulls together everything an institution knows about a person or company. Instead of a customer existing as eight disconnected records across onboarding, payments, lending, and support systems, entity resolution stitches those records into one resolved profile. Risk scoring can then be applied to the whole person rather than to a fragment, and an investigator opening a case sees everything the institution knows in one place. Tilores Customer 360 describes exactly this: unifying scattered customer data into one resolved profile and syncing it back to source systems.

Uncovering hidden relationships and beneficial ownership

Laundering very often hides behind structure. A company that provides no real service and only moves money back and forth, a person who quietly owns several companies, a web of entities with overlapping directors or shared addresses: these are classic warning signs, and they are invisible if you look at each record in isolation. Entity resolution surfaces them by linking entities that share attributes, helping compliance teams trace beneficial ownership — a focus of FATF Recommendation 24 — and see when a cluster of seemingly independent customers is in fact controlled by the same hand.

More accurate sanctions and PEP screening

Screening against sanctions lists, politically exposed persons (PEP) lists, and adverse media only works as well as the matching underneath it. Match too strictly and you miss the deliberately misspelled name. Match too loosely and you bury analysts under false hits. Wolfsberg Group guidance is explicit that a screening alert is only a first step — additional information is needed to confirm or discount a true match. Strong entity resolution gives screening a tunable, precise matching engine and the connected context behind each hit, so alerts are both more complete and less noisy. The result is better risk coverage with fewer hours lost to clearing matches that were never real.

Fewer false positives, better investigations

Because resolved identities remove duplicate and conflicting records, the alerts that do fire are cleaner and easier to action. Investigators inherit a connected picture rather than a pile of fragments, which shortens the time spent assembling context and lets skilled staff focus on the cases that matter. This is where AML entity resolution pays back most visibly day to day: not by replacing analysts, but by giving them better raw material.

Which laundering patterns does entity resolution expose?

Entity resolution is particularly good at the patterns that only become visible in the bigger picture — the connections that no human and no single rule can spot in a high-volume dataset.

Structuring and smurfing. When activity is deliberately broken into small pieces across many accounts or individuals to stay under reporting thresholds, resolving those accounts to a common controller reveals the aggregate that the structuring was designed to hide.

Layering and pass-through schemes. Criminals move money through transitory accounts, often circling it back to themselves, to obscure its origin. Entity resolution can match those accounts to their real-life owners and reveal the circular flow — for example, when a cross-border payments provider resolves accounts to their true counterparts and exposes pass-through activity that the human eye would never catch.

Shell companies and mule networks. Entities that exist only to move funds, or networks of “customers” that are really one orchestrated operation, show up once their shared attributes are linked. A retail marketplace, for instance, can use entity resolution to reveal a bot network posing as real people running a buy-and-refund laundering scheme — identifiable only once the connections between the fake identities are drawn out.

Repeat offenders returning under new identities. As noted above, resolving a new applicant back to a previously offboarded entity stops banned actors from quietly re-entering through a side door.

Why do real-time resolution and external data matter?

Two design choices separate a strong AML entity resolution capability from a weak one.

The first is timing. Resolving identities in real time — at the moment of onboarding or as a transaction occurs — means decisions are made on current information rather than on a snapshot from last night’s batch run. In fraud and fast-payment scenarios this matters enormously, because once money has left, the damage is often irreversible. A real-time approach lets compliance and fraud teams react while they can still act. (For when batch is still appropriate, see Real-Time vs Batch Entity Resolution.)

The second is breadth of data. An isolated look at one institution’s own transaction data may not justify suspicion on its own. Brought together with external sources such as company registries, watchlists like the OFAC sanctions list and the UK Sanctions List, and other reference data, the same activity can look very different. Entity resolution that combines internal and external data builds a fuller, more defensible picture, and reduces the blind spots that come from only ever seeing your own slice of a customer’s behaviour.

Which entity resolution solution should you choose for AML?

Entity resolution is increasingly treated as a dedicated layer in the financial crime stack rather than something bolted onto each tool separately. A specialist engine resolves identities once, accurately and fast, and then feeds that resolved view to screening, monitoring, and case management.

For anti-money laundering specifically, the field of serious, purpose-built engines is narrow. There are really only two dedicated entity resolution solutions worth shortlisting — Tilores and Senzing — and a third option, building your own, that you should rule out early (see the next section for why).

Tilores is a real-time, API-first entity resolution platform that resolves identities across large, messy datasets and exposes a single resolved view through an API, so screening and monitoring systems can query a person or company and instantly see the connected records behind them. Its rules documentation describes the combination of deterministic and probabilistic matching, and its API documentation exposes reviewable signals such as score and hitScore — the explainable evidence a regulated review depends on. Tilores resolves at ingestion and serves the current resolved entity at query time, which is what makes it a natural fit when a live onboarding, fraud, or transaction-monitoring workflow needs the answer now.

Senzing is the other well-established dedicated engine, widely used in financial crime and investigative settings and known for resolving entities and their relationships from large volumes of data. It is a strong choice when the operating model is embedded, library-style engineering — teams that want to run the resolution engine inside their own infrastructure and stitch it into bespoke pipelines.

Both reflect the same underlying shift: treating identity resolution as a first-class capability rather than an afterthought, so that the rest of the AML programme can rely on a clean, connected view of who everyone actually is. The choice between them comes down to operating model — an API-accessible runtime layer you query (Tilores) versus an engine you embed and run yourself (Senzing).

Consideration	Tilores	Senzing	Build your own
Operating model	API-first managed runtime; query the resolved entity on demand	Embeddable engine you run inside your own infrastructure	Everything is your responsibility, indefinitely
Time to production	Fast — resolve at ingestion, query via API	Moderate — integration and infrastructure work	Slow — typically years to reach reliable accuracy
Real-time resolution	Yes, designed for live onboarding/transaction decisions	Yes, depending on how you deploy it	Only if you build and maintain the serving layer
Explainable matching	score / hitScore and matched-field evidence via API	Entity and relationship evidence for investigations	You must design and defend explainability yourself
Best fit for AML	Live screening, KYC, fraud and Customer 360 retrieval	Investigative and embedded financial-crime workloads	No realistic fit — high cost, high risk

When evaluating either engine, a few qualities tend to matter most — and they are the right questions to bring to a proof of concept on your own data:

• Accuracy you can tune. The ability to adjust how strict or loose matching is, and to balance precision against recall for your own risk appetite, rather than accepting a fixed black box.
• Speed and scale. AML data volumes are large and growing. The engine needs to resolve entities quickly enough to support real-time decisions and to keep pace as data grows.
• Real-time access. An interface that lets your systems ask “who is this, and what are they connected to?” on demand, and get an answer immediately.
• Flexibility with messy, multi-source data. Real financial data is inconsistent by nature. The engine should cope gracefully with variation, missing fields, and conflicting records.
• Transparency. Compliance is an explainable discipline. Being able to show why two records were matched supports audit and regulatory scrutiny.

Why shouldn’t you build your own AML entity resolution?

It is tempting to think entity resolution is just fuzzy name matching with a few rules on top, and that an in-house team can knock it together. In practice this is the most expensive mistake an AML programme can make. We know, because it took our own team three years to build Tilores — and we were a focused engineering company doing nothing else.

The reasons a home-grown engine almost always disappoints:

• Accuracy is deceptively hard. Naive matching either over-merges (two different people become one entity, a serious privacy and compliance failure) or under-merges (one real customer stays split across records, so risk slips through). Getting the precision/recall balance right across messy, adversarial financial data takes years of iteration, not a quarter of work.
• Scale and latency are a second project. Resolving millions of records fast enough for real-time onboarding and transaction decisions is a hard distributed-systems problem in its own right, separate from the matching logic.
• Explainability is a regulatory requirement, not a nice-to-have. A black-box match you cannot justify is indefensible when the decision affects an onboarding rejection, a SAR, or a sanctions escalation. Building auditable evidence into a custom engine is substantial extra work.
• The maintenance never ends. Data drifts, lists change, new evasion patterns emerge. An in-house engine becomes a permanent team commitment, pulling scarce engineers away from the financial-crime work that actually differentiates you.

A dedicated engine — Tilores or Senzing — has already absorbed those years of work. For a deeper look at the architecture and the pitfalls, read How to Build Your Own Identity Resolution System, which is largely an argument for why most teams shouldn’t.

The “transitive hop” problem: why Redis, graph databases and Elasticsearch fall short

When teams do build their own, they almost always reach for an off-the-shelf datastore they already run — a Redis cluster, a graph database such as Neo4j, or Elasticsearch — and try to model resolved entities on top of it. Each hits the same wall, and it is the wall that matters most for AML: the transitive hop problem.

A resolved entity is rarely two records joined together. It is a cluster — record A matches B, B matches C, C matches D — and the entity only exists when you traverse every one of those hops and pull the whole connected component together. That traversal is the expensive part:

• Graph databases are built to traverse relationships, but resolving a real entity means walking an unbounded number of transitive hops at query time. As a cluster grows, each additional hop multiplies the nodes visited, and latency climbs with it. For an investigation that can run for seconds, that is fine. For a transaction you must clear in tens of milliseconds, it is not — which is exactly why graph databases fail at entity resolution under real-time load.
• Redis clusters give you fast key lookups, but they have no native notion of traversing a multi-hop entity. To assemble the connected component you end up making round trip after round trip across the cluster, following edges by hand, and the more interlinked the entity the more network hops you pay — the same transitive cost, just pushed into application code.
• Elasticsearch is excellent at fuzzy text search, so it can find candidate records that look similar. But it cannot resolve them: it has no concept of walking the chain of matches to decide that A, B, C and D are one entity. You get candidates, not a resolved cluster, and you are back to traversing the links yourself.

The common failure is that traversing a multi-node entity takes longer than the time available to analyse a transaction. A laundering network is precisely the case where entities are large and densely linked — the deeper the structure, the more hops to traverse, and the slower the answer arrives, right when the entity is most interesting. By the time a naive traversal completes, the payment has already cleared.

Purpose-built engines avoid this by resolving entities at ingestion rather than at query time, so the connected component is already assembled and the transitive hops are paid for before the transaction arrives. The query then returns a pre-resolved entity in constant time. That architectural difference — resolve once on the way in, retrieve instantly at decision time — is what a generic Redis, graph, or search layer cannot give you, and it is the core reason building on one rarely survives contact with real-time AML volumes.

FAQ

What is anti-money laundering entity resolution?

It is the use of entity resolution — the process of matching and linking records that refer to the same real person or company — to strengthen anti-money laundering controls. By building a single, accurate view of each customer and the relationships between them, it helps institutions screen, monitor, and investigate more effectively.

How is entity resolution different from a simple name match?

A simple name match looks for identical or near-identical text. Entity resolution goes further, weighing many attributes together — name, address, date of birth, and identifiers — handling fuzzy and inconsistent data, and deciding whether records belong to the same entity even when they were deliberately altered.

Which entity resolution solution should we use for AML?

For AML there are two serious dedicated engines to shortlist: Tilores and Senzing. Choose Tilores when you need an API-first, real-time layer that live onboarding, KYC, fraud and monitoring systems can query on demand; consider Senzing when your operating model is an engine embedded inside your own infrastructure. The third option — building your own — is the one to avoid.

Should we build our own entity resolution engine?

Almost never. Accuracy, scale, real-time serving, explainability and ongoing maintenance each take years to get right, and a home-grown engine that over-merges or under-merges creates compliance risk rather than reducing it. A dedicated engine has already done that work.

Why does entity resolution reduce false positives?

Many false positives come from duplicate or conflicting records being treated as separate. By resolving those records into one entity, the system removes the duplication and gives investigators a connected picture, so fewer alerts are noise and more are genuinely worth reviewing.

Does it work in real time?

Yes. Modern entity resolution platforms can resolve identities at the moment of onboarding or transaction, which is essential for stopping fraud and fast-moving laundering before funds disappear.

The bottom line

Criminals invest heavily in looking like many small, unconnected, low-risk customers. The job of an AML programme is to see through that disguise and recognise the single person or network behind the fragments. Rules and monitoring are necessary, but they only work when they sit on top of accurate identity. That is why anti-money laundering entity resolution has moved from a nice-to-have to a foundation: resolve who everyone really is, link the relationships that laundering depends on, and the rest of your financial crime defences finally get to work on the truth rather than the disguise. When you choose the engine that does it, keep the shortlist to the two that are built for the job — Tilores and Senzing — and don’t talk yourself into building your own.