AML and KYC With Real-Time Entity Resolution

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

TL;DR: Real-time entity resolution helps AML and KYC teams screen the right customer, not a pile of fragmented records. It links identities at ingestion, retrieves current resolved context at query time, shows why records matched, and leaves analysts with the evidence they need to decide, escalate and document the outcome.

See it on your data: book a demo to walk through real-time entity resolution for AML and KYC, or get the evaluation build to try resolved customer records locally — then explore the Tilores entity resolution software to see how it supports fraud, KYC and AML controls while your screening tools keep their case logic.

Check	What real-time resolution contributes	What an analyst still decides	Audit-log artifact
Customer due diligence	Resolves duplicates, aliases and linked records into one customer context.	Whether the evidence is sufficient for verification and risk rating.	Resolved entity ID, source record IDs, matched fields and verification status.
Sanctions and PEP screening	Screens the current customer context rather than isolated fragments.	Whether the candidate is a true match, false positive or escalation.	List source, matched attributes, confidence signal, analyst rationale.
Adverse-media and fraud checks	Connects related accounts, devices, addresses and relationship clues where permitted.	Whether the pattern is suspicious, explainable or already known.	Relationship evidence, reviewed signals, action taken or no-action reason.
Ongoing KYC monitoring	Updates the resolved context as new records arrive or existing records change.	Whether a change triggers refresh, enhanced review or no case action.	Change event, previous context, new evidence and review result.
Audit and supervisory review	Keeps match evidence, entity context and decision artifacts tied together.	Whether the control operated as policy intended.	Policy version, match evidence, decision owner and timestamp.

How does entity resolution help AML and KYC teams?

Entity resolution helps AML and KYC teams by making the screening subject clear. A financial institution is not only asking whether a name appears on a list. It is asking which person, business, account, beneficial owner or related party the record represents, and whether the evidence is strong enough to act on.

Customer due diligence (CDD) obligations are framed around identifying and verifying customers, understanding the business relationship and conducting ongoing monitoring. In the UK, Regulation 28 explicitly includes ongoing monitoring, transaction scrutiny and keeping CDD information up to date. A resolved customer record gives those controls one current entity to work from.

The practical benefit is fewer disconnected decisions. Onboarding, fraud, sanctions, support and operations can all refer to the same resolved entity ID, while the AML or KYC system still owns its own screening logic and case decision.

What should real-time KYC screening look like in 2026?

Real-time KYC screening should resolve the customer first, then screen the resolved context. That means the system checks the current customer, known aliases, linked records, ownership clues and relationship evidence before returning a screening candidate to an analyst or downstream control.

This matters because official-list data and customer data both change. OFAC publishes sanctions data through its Sanctions List Service; the UK maintains the UK Sanctions List; and the EU publishes a consolidated financial sanctions list. Screening stale or partial customer records against current lists creates avoidable ambiguity.

Real time does not mean automatic approval. It means the screening decision starts from the latest resolved facts. The analyst still decides whether the candidate is a true match, false positive, escalation or no-action case.

How should resolved customer records support sanctions and fraud checks?

Resolved records should support sanctions and fraud checks by preserving the evidence behind the customer view. The screening system needs names and aliases, but it also needs dates, addresses, documents, accounts, devices, source-system IDs, linked businesses and known relationship edges where those fields are permitted and relevant.

Wolfsberg sanctions screening guidance describes screening as comparing customer or transaction records with sanctions data, while making clear that an alert is only a first step. Additional information is needed to confirm or discount a true sanctions match.

That is where entity resolution changes the quality of the review. Instead of a single noisy field match, the analyst can see which records were linked, which fields matched, which fields conflict and whether the relationship graph suggests the person or business is already known elsewhere.

What makes matching explainable enough for regulated review?

Explainable matching means the reviewer can see why the entity was returned. The evidence should show the source records, matched fields, conflict fields, relationship edges, confidence signals and the rule or model context behind the match. A black-box match that cannot be explained is hard to defend when the decision affects onboarding, payment release, fraud review or sanctions escalation.

This does not work well when constrained to one matching style. Real customer data contains misspellings, aliases, transliteration, address variation and incomplete identifiers. Tilores documentation describes probabilistic matching and the combination of probabilistic and deterministic matching, while its rules documentation explains that linking happens during the assembly process after records are submitted.

Tilores also exposes reviewable API signals. The Tilores API documentation shows submit, search and entity operations, and search results can include score and hitScore. In that documentation, score reflects overall match quality within an entity, while hitScore reflects alignment with the search parameters. Those signals should inform policy; they should not be treated as universal thresholds without calibration.

Where should Tilores sit next to AML, KYC and data platforms?

Tilores should sit next to AML, KYC, sanctions-screening, fraud, MDM, CDP, data-governance and warehouse tooling. It is the entity-resolution layer that feeds resolved customer context to those systems while each system keeps its own operating role.

For customer context, Tilores Customer 360 describes unifying scattered customer data and syncing complete profiles back to source systems. For AI and retrieval use cases, Tilores IdentityRAG focuses on giving systems the right customer data rather than semantically similar fragments. The same distinction applies in compliance: the screening tool should receive the right resolved customer, not a broad search result set.

Resolution happens at ingestion. Query time is for retrieving the current resolved entity context through controlled operations. That distinction keeps the identity decision governed, repeatable and separate from the screening tool’s final case logic.

What is the auditable screening flow?

A real-time AML and KYC architecture should be simple enough to audit. The flow below is intentionally narrow: resolve first, screen second, explain the candidate third, and write the decision trail fourth.

Resolve the customer or counterparty at ingestion. Submit new and changed records into the entity-resolution layer so duplicates, aliases and relationships are connected before the screening request.
Screen the resolved context. Run sanctions, PEP, adverse-media and fraud checks against the current entity, including known aliases and permitted relationship evidence.
Return explainable decision evidence. Show matched fields, conflicts, source records, score or hitScore-style signals where available, and the reason the candidate was returned.
Record the audit entry. Store the resolved entity ID, screening sources checked, analyst action, escalation reason, false-positive rationale or closure rationale.

What should analysts still own?

Analysts still own the judgment. Entity resolution can make the subject clearer and the evidence easier to inspect, but it should not silently turn every match into an action. Ambiguous matches, weak identifiers, jurisdictional issues, conflict fields and high-impact decisions need review.

The right operating model is evidence-led. The system resolves records and retrieves the current entity context. The analyst decides whether the match is a true match, a false positive, an escalation, a hold or a clean close. The audit log should make that distinction visible after the fact.

For a deeper technical pattern on keeping AI systems and downstream workflows from mixing customer context, read How to Stop AI Agents Confusing Two Customers.

FAQ

How does entity resolution help AML and KYC teams?

Entity resolution connects records that refer to the same person, business or account relationship before screening decisions are made. That gives AML and KYC teams a current, explainable customer view for sanctions, PEP, adverse-media and fraud checks.

Does real-time entity resolution take over from AML or KYC screening tools?

No. Entity resolution sits next to AML, KYC, sanctions-screening, MDM, CDP, data-governance and warehouse tooling. It feeds those systems cleaner resolved customer context; those systems still own their rules, case management, regulatory logic and analyst decisions.

Should sanctions screening rely on one matching style?

No. Regulated matching usually needs deterministic rules alongside probabilistic or fuzzy matching because names, aliases, addresses, dates and identifiers vary across systems. The important requirement is explainable evidence, calibrated thresholds and human review for ambiguous cases.

When should the entity be resolved in a real-time KYC workflow?

Resolution should happen at ingestion, as customer and event records enter the identity-resolution layer. At query time, the screening or analyst workflow retrieves the current resolved entity context rather than assembling identity from raw fragments.

What should an audit log capture for entity-resolution-supported AML decisions?

The audit log should capture the resolved entity ID, source records used, fields that matched, confidence signals such as score or hitScore where available, screening lists or fraud signals checked, the analyst decision and the reason for escalation or closure.