NODES AI 2026 - Building a Cross-Border KG: AI Powered Entity Resolution & Risk Detection

In this talk, Artem Zemskov, founder and CTO of Clear Pick, discusses the use of knowledge graphs to automate compliance checks in high-risk commodities markets, particularly in Central Asia. He highlights the challenges of data inconsistency across different country registries and the inefficiency of traditional relational databases and large language models in managing these complexities. Zemskov explains the five stages of their process, which includes data ingestion, natural language processing, graph creation, analysis, and actionable insights delivery. By combining NLP with graph structures, Clear Pick successfully identifies hidden connections and conducts KYC checks swiftly, turning days-long evaluations into mere minutes. The speaker emphasizes the importance of explainability and the structured nature of knowledge graphs in mitigating risks associated with data ambiguity and inconsistency.

[music] >> Hi everyone and welcome. My name is Artem Zemskov. I'm founder and CTO at Clear Pick and Clear Pick is screening platform focused on high-risk commodities markets in Central Asia and the Caspian region. And our platform helps automate counterparty due diligence and know your customer procedures. And today I want to I want to tell you about how a knowledge graph helps find hidden connections in data.

For example, how long does it take a compliance team to check one company in Central Asia? I will tell you what our clients told us before they came to us. It's one or two days. Uh we get it done in 10 minutes and let me show you how. So, but first, let me tell you about the Central Asia. So, each country has its own business registry. Sometimes

not one, two or three because different government agencies run their own registries. Uh no direct access, no standardization, no proper search and the data itself is also quite messy. For example, the same person in one registry is Halima and another is Halimov G and in a third it's spelled and spelled in Latin, not in Cyrillic. So, what we have here, it's like the same person, three different

spellings and zero connection in a government database. And it gets worse. For example, five years ago, it's spelled one way, two years later without the patronymic name. Right now with it. So, that breaks any system which will try to connect all the dots from different data sets. And basically that's enough to disappear from a standard compliance check. And that's why let me show why standard tools fail

here. you can ask me, why can we just use a relational database for this use case? Um try to find all entities connected through three intermediaries across millions of records with different name variations and addressing consistencies. Your query explodes. Your join becomes a nightmare. Uh okay, you can say, what about LLMs? Right? LLMs are great. They flexible, powerful, but there is only one problem, they hallucinate. They

will confidently confidently tell you two companies are connected with no evidence. And they will tell you the opposite also quite confidently. Also without evidence. And there is deeper problem. Right cannot guarantee transitive closure. For example, if A connects to B and B connects to C, right will not reliably find that A connects to C across a number of records. And for compliance or for investigations or even

for basic KYC checks, that's uh not a feature, that's a liability. Uh and we needed something that thinks in relationships, not rows. And here is what we built. Uh five stages. First, we ingest data from hundreds of data sources. It's different data sources. Second, uh we run NLP and entity resolution. For example, fuzzy matching, deduplication, name entity extraction, you name it. Third, everything goes into our knowledge

graph and mapping. Fourth, we do analysis, graph algorithms, custom risk scoring. For example, link prediction or centrality detection. It's really helpful. And fifth, it's actionable insights about companies, about businesses that are delivered to compliance teams through our web platform. And what can I say here? NLP gives us flexibility and graph gives us speed and consistency. And that combination is what makes it work at scale. let's have

a quick look what is a knowledge graph. I believe everyone here knows about uh knowledge graphs. But uh let me make sure that we on the same page. So, a knowledge graph has two things. It's basically nodes, the entities, and for example, person, company, address, court case, uh contract, etc. And relationships. So, it's connection between those entities. They can be typed, directed, with properties. So, for example,

in our use case, a person who owns a company, a share, if he has a share, 51%. So, that's it. And a bit of theory behind of the concept of uh knowledge graph. So, knowledge graph is basically contains items, two um two entities, too. So, it's ontology, like the conceptual blueprint, the rules, and the taxonomy. It's can be called a linguistic model, for example, handling terms, synonyms,

transliteration, like also a set of a set of rules that describe uh our data. And the data graph itself, the actual instance data. So, for us, it's useful because a it stores facts. And the knowledge graph, it stores meaning. why it help helps us? Because it resolves ambiguity across sources, different sources, because we have uh sources in different languages from different um and we need to resolve

this ambiguity. And also knowledge graph breaks down silos between structured data, documents, media, even you can continue this list. And also knowledge graph grounds LLMs in verified facts. Like it excludes any hallucinations. So, for us, the graph is a ground truth. And that's the structure. Now, let me show what we put into it. where does our data come from? Earlier I said that we have different sources,

uh but uh right now I can call it different layers. So, first first layer is public registers. For example, corporate records, ownership structures, like list of directors, shareholders, procurement records, sanctions list, local watch lists from from all jurisdictions that we cover. Uh second layer is court records. Um we have like a lot of a lot of uh records on court cases. It's uh unstructured data. It It's

It's published in PDF in the local languages. So, it's unstructured text in Uzbek, Tajik, Mongolian, Azerbaijan languages. Pretty hard to digest, pretty hard to analyze. And that's why we run NLP pipeline. So, we extract parties, case types, amounts, outcomes, dates, and then we transform unstructured legal text into structured graph data. Why does it matter? If a director has been a defendant in 40 cases from three countries,

that's a signal. A registry will never show you that. And a court database will, but it's different sources. They hold different type of data, they provide it in a different way. Uh and we need it to be unified. And this third layer, it's media and open sources. So, news articles, press releases, investigative journalism. We extract named entities, people, companies, events, addresses, contacts, and we link them to

what's already in in the graph. So, when you query company, you don't just see who owns it. You see who's suing it, who wrote about it, who and what they said. Uh, and it saves our clients time, big time, big time. They don't need to Google a company or a person in an unfamiliar language, local language. It's already in our system. So, every new data source, add

a new type of edge. The more edges, the harder to hide. we have three layers of data. Now, how do do we connect them? And there is the hard part. how do you know that that person, Halima in Kazakhstan, is the same person as the Halima G in Uzbekistan? Exact match [snorts] says, "No, it's it's it's different, uh, different entities." Our system says, "Probably yes, and here

is the confidence score." we use creative mix for it. It's uh, phonetic matching, Soundex and Metaphone. We adapted it for Cyrillic and local Latin scripts, for example, like Azerbaijan or Uzbekistan, because in Uzbekistan, they have uh, scripts, Cyrillic and Latin, and they use them both. And uh, this phonetic matching, it handles transliteration variations. also, we use contextual embeddings from fast text and BERT. Same address context, same

same registration period, for example, or some [snorts] similar surname, uh, different uh, spellings of company names, etc. So, the more these embeddings, the higher confidence. And the third one is probabilistic It's a number between zero and one. So, for example, if we have a name similarity and address overlap, and some registration align or registration data alignment, it means higher score. the real challenge here is uh, not

the algorithm itself. It's the data that is bad by design, uh, one change in a name, uh, dropped patronymic name in a full it's basically enough to break exact match. And but it's not enough to fool probabilistic scoring, because it's really powerful. the graph is built, looks it should has been to I wanted to describe like that, like nodes, edges, query capabilities, etc. And it's that's um,

real screenshot from our system. each node is verified, duplicated, real world entity. And each edge is a typed relationship with a confidence weight and a time type time stamp. For example, a owns a company, the company is registered to an address, and that address connects to a nice company. And you can click through the graph and understand all the connections. And this is what a KYC check

looks like when you stop searching a rose and start traversing a knowledge graph. uh, we can, for example, enlarge it. And see it's like there is a pretty clear a lot of connection, for example, from one person to other companies and to addresses. And it's really really helpful. okay, so that's the structure. And now, what does it actually find? Um, here is like a quick quick description,

>> [clears throat] >> uh, our graph allows us and our customers to in this uh, messy data. And um, that's like a real scheme from Neo4j. And uh, this scheme I really love showing customers. And uh, this one is circular ownership. So, a company owns a shell, which owns another another shell, and which owns the original company. So, the company owns itself through a layer of intermediaries

across two countries. And that's the pattern that can hide billions and assets. and the square query will never find from for example, one source or even with different sources, because it will be like a lot of joins, a lot of joins. But our graph finds it automatically. And we also can find ultimate beneficiary ownership chains, like the real person behind layers of shells. This person, and he

owns that company. what we can also use, for example, uh, it's shared identifiers, shared entities, too. For example, 10 unrelated they sharing one address, it can mean that um, it's a coordinated structure. So, it's flagged instantly in And when we cross reference with court records, for example, a director of this company can be appearing in court cases across the region. And what took investigators first weeks, our

graph does in under a minute. So, finding connections is one thing, but explaining them is another. Um, because that's the problem we kept running into. Compliance teams, they don't trust uh, black box scores. You cannot say the company has a risk score 0.79. They will ask, "Why? Show me the Show me how you got that number." So, that's why we are building Graph Rake. and here is

how it works. So, user asks, "Summarize compliance risk for company X." And graph finds all verified connections, ownership chains, court history, media mentions, procurement records, watch lists, and memberships, the structured, verified context. Not the raw internet, not its training data that can be potentially corrupted or poisoned, like deliberately. It's the graph. It's like our verified connection that is connected to real sources that we can trace. And

the LLM never invents, never hallucinates some connection. It can only explain what the graph has already verified. And for investigators, for compliance team, for regulators, that audibility is everything. a vector search finds what is similar. And Graph Rake finds what is connected. And the difference between a search engine and basically that's the difference [clears throat] an intelligence And um, um the intelligence platform has its own engineering

reality. And let me be honest about how this works in production. So, our full graph is around 500 GB in memory. Uh we can do a three-hop traversal queries like in sub seconds. We can extract pretty easily. Uh but it's also has some trade-offs. the classic trade trade-off about recall and precision. So, we lowered our confidence threshold to 0.85. And we accept uh false positives in this

case. why? Um because uh real-time updates break transitive closures because it's it's noise. But for us, consistency over freshness for compliance, for example, that's the right call. And um also, one of the hardest part for us is encoding normalization because we handle seven languages. And one language can use Cyrillic and Latin simultaneously. Also, some Also, old-style spellings versus modern native spellings. As I told Halima or Halimov

John, it's For for the computers, we have different names, different persons. in reality, it's it's the same person but different surnames across time. And also, we used our own uh trained data because we labeled uh 500 clusters like exclusively by us. even more, maybe one maybe 1,000. Yeah, it's it was was a lot of work to do. And engineers who say that they have zero false positive

in their systems are lying, basically, because honest trade-offs are what make a system trustworthy. so, what we did produce. so, we have more than 25 millions uh data points from corporate records, and they are unified in one graph. And we get a 40% increase in hidden in hidden risk detection uh versus tradition traditional methods of investigations. And we have a pretty dramatically reduction in investigation time. Uh

that saves a lot of time for our clients. And also, we automatically identify more than 15 financial crime patterns. So, what uh I can say, so checks before, it was days. Right now, it's minutes. And a single graph query gives you court history, litigation records, uh procurement involvement, watchlist status, full ownership clusters, And everything one query in a few seconds. Yeah. But those are the numbers. These

results are great, but here's what we learned building them. here's what we learned. It's uh hybrid always beats pure. So, NLP plus graph beats pure LLM and pure SQL. Uh because we are working in a noisy multilingual environments, so we invent something. Also, probabilistic is more important than binary. In highest noisy noise data, confidence scores are more powerful than yes or no. And explainability is not an

is not optional because compliance teams, they need to see the path through the data, they not just the score. And the knowledge graph deliver explainability natively because like that's that's not a feature, basically. That's that's a product. courts and media, they uh are underused signals because um they will tell you what actually happened. They will add more context to corporate registries because corporate registries sometimes can be

impartial, they can be corrupted, etc. So, [snorts] graph is never finished. We always working on it. We add incremental updates, trying to add real-time real-time update on We also trying to build auto detection of adversarial obfuscation because some bad actors deliberately uh poison records to await detection. And we expanded to new jurisdictions and data types. And if you are working on entity resolution at scale, graph architecture

for compliance or for financial intelligence, I'd love to talk. Thank you. >> [music]