How to Build a Queryable KYC Knowledge Graph From Unstructured Documents

KYC documents are rarely clean. You get handwritten numbers. Half-filled forms. Scanned PDFs. Multi-column layouts. Checkboxes that are not fully ticked. Important details that appear in one filing, then show up again in another with a slightly different structure.

That is exactly the kind of problem Vishal Singh, founder and CEO of Quark Labs, tackled in a recent Memgraph Community Call.

The session was a live showcase of how Quark Labs takes messy investor services documents, extracts structured information from them, creates graph entities, and pushes that context into Memgraph. From there, the graph can answer natural language questions across multiple documents.

Missed the live session? Watch the full From Messy Documents to a Queryable KYC Knowledge Graph Community Call recording to see the full demo, document examples, graph view, and Q&A.

Here are the key takeaways from the session.

Key Takeaway 1: The Problem Is Messy Documents

The session started directly with the demo. Vishal showed the messy source files most KYC workflows have to deal with first. Not polished datasets. Not clean tables. Real documents.

Think scanned PDFs, handwritten values, half-filled forms, multi-column layouts, and grids that look structured to a person but do not behave like tables for a machine. In the demo, Quark Labs used investor services documents to show why extraction breaks when a pipeline assumes every form is neat and predictable.

That is the first problem Vishal walked through. Before you can query anything, the system needs to preserve enough document structure to make the extracted data useful later. Quark Labs connects to document sources such as:

• Amazon S3
• Azure
• Blob Storage
• GitHub
• Box
• Hugging Face
• Local file storage

The point is not to process one perfect PDF. The point is to handle document corpora where new files keep arriving and the format is not guaranteed.

That setup matters because the rest of the workflow depends on it. If the extraction layer loses layout, field meaning, or source context, the graph later receives weak data.

Key Takeaway 2: Extraction Needs Two Outputs

Once the documents are connected, Quark Labs extracts the information into:

• Markdown: for AI workflows to get a readable representation of the document. It keeps the extracted content accessible for an LLM or AI layer that needs to reason over the text.

  

• JSON: for structured systems to get something more deterministic to work with. It helps identify names, PII fields, identifiers, and schema-like structure from the document itself. That JSON output can then feed legacy workflows, warehouses, and graph entity creation in Memgraph.

  

The demo made this difference clear with a handwritten form. The Markdown captured the document content, while the JSON cleaned and structured the extracted values. That distinction becomes important once the pipeline moves from extraction to graph creation.

Key Takeaway 3: Production Needs an Audit Trail

It is easy to overstate a pipeline if it stops once the text is extracted.

This one also covered the boring but important parts, including versioning, deduplication, storage, and deployment controls.

When a new file lands in S3, Quark Labs can pick it up and generate the extracted representation. When a new version of a file appears, the platform keeps the earlier and newer Markdown outputs. That gives teams a way to compare what changed.

The platform also deduplicates identical files, so the same document does not burn extra compute just because it appeared more than once.

For storage and privacy, Vishal mentioned Apache Iceberg in the customer account. He also explained that Quark Labs’ document intelligence model can run air-gapped inside the customer’s environment when sensitive documents cannot leave the account.

That is the part KYC teams will care about. Extraction is only useful if the pipeline can support auditability, privacy, and continuous ingestion.

Key Takeaway 4: The Graph Connects Scattered Facts

After extraction, Quark Labs creates the graph in Memgraph. This is where the workflow moves from “we extracted text” to “we can understand how facts connect.”

In KYC, the answer you need rarely lives in one document. The same customer, passport number, company, address, or transaction detail can appear across several filings. One file may contain the person. Another may contain passport details. A third may contain ownership or transaction context.

That raises the real question of how you know these documents are related in the first place.

Quark Labs uses JSON extraction results to create graph entities in Memgraph. The graph can represent extracted entities from source documents and relationships between them.

That means a user can move beyond document search. They can inspect which segment contained a value, which entity it belongs to, and how it connects to facts found elsewhere.

This is the core reason Memgraph matters in the workflow. It provides the connected context layer between extracted document evidence and the questions users want to ask.

Key Takeaway 5: Provenance Makes Answers Trustworthy

For KYC, an answer without evidence is not enough.

You need to know where it came from.

The demo showed that the graph can store context about document segments, extracted entities, and whether a value came from handwritten content. That matters because handwritten fields are more likely to be ambiguous or misread.

By keeping provenance in the graph, the system can help users inspect:

• Which document contained the information
• Which segment the value came from
• Whether the value was handwritten
• When the information was added
• How it connects to other extracted facts

This is where graph context becomes different from basic retrieval. Similarity search may help find related text, but a graph can show why two filings are connected and which source supports an answer.

The recording is worth watching for this part because the graph view makes the source-to-entity-to-answer flow easier to understand than a written recap can.

Key Takeaway 6: Questions Run Across the Graph

The live demo then moved into natural language questions over the graph.

One question asked for Victor Melnik’s passport details. The answer pulled together details such as Ukrainian passport information, passport number, and issue date. The important part was not the answer itself. It was that the evidence came from three different documents.

That is exactly the type of query where a graph becomes useful. You are not asking for one matching file. You are asking the system to collect connected evidence across filings.

The demo also included questions such as:

• Who is the beneficiary of Creston Holding?
• Was any cash transaction done by Carlos Reyna?
• What did the James Whitfield W-8BEN say?

For the Creston Holding question, Vishal noted that the query was running on the graph, not a vector database. For the James Whitfield W-8BEN question, the system pulled evidence such as ownership, address, TIN, and related form details.

The Carlos Reyna query also showed the reality of a live demo. The answer layer hit an OpenAI-related parsing issue, but the graph still surfaced relevant evidence. That is a useful distinction for AI builders: keep the evidence layer inspectable, so the system does not become a black box when the answer layer fails.

You can see the full query flow in the Community Call recording.

Key Takeaway 7: Entity Resolution Is the Hard Part

Parsing documents is hard. Connecting entities correctly is harder.

At scale, teams need to decide which entities matter and how those entities should be represented in the graph. Quark Labs can work with customer-defined entities, but it can also use JSON extraction results to identify names, identifiers, and other signals automatically.

This is where entity resolution becomes critical.

A name match is not enough. Two people can share the same name but have different passport numbers. Those records should not be merged. On the other hand, a badly handwritten name may still refer to the same person if the passport number or ID matches another document.

The demo discussion mentioned signals such as normalized values, IDs, names, passport numbers, and other identifiers.

That is the difference between a graph that only looks connected and a graph that is actually useful. Bad entity resolution creates false confidence. Good entity resolution gives users a stronger foundation for search, audit, and investigation.

Wrapping Up

The Community Call showed a practical path from messy KYC documents to a queryable knowledge graph.

Quark Labs started with scanned forms, handwritten fields, and structured extraction. It then used JSON outputs to create entities in Memgraph, connected those entities across documents, and answered natural language questions from graph-backed evidence.

The real takeaway is simple: document intelligence becomes more useful when extracted facts are connected, inspectable, and traceable back to source evidence.

If you work with KYC documents, audit public company filings, or any workflow where facts are scattered across messy documents, watch the full From Messy Documents to a Queryable KYC Knowledge Graph Community Call recording. The live demo shows the full loop from raw documents to graph-backed answers.

Q&A

Here’s a compiled list of the questions and answers from the community call Q&A session.

Note that these are paraphrased slightly for brevity. For complete details, watch the full community call recording.

1. What is the approach when the customer does not have an existing ontology?

   • In KYC and other financial use cases, you may not know every entity you need upfront, but you usually know the domain and the core use case. That gives you a starting point. For KYC, common entities can be extracted even if the customer has not explicitly defined all of them in advance.

     If an existing ontology is available, it can be used to speed up the process. If not, the graph can still be built from extracted entities, mentions, classifications, and discovered relationships. A full ontology across millions of documents is hard to define and maintain from day one, so the practical approach is to start with common domain entities or a generic industry ontology, then let the graph evolve as new patterns and use cases appear.

     Because the extracted entities and relationships are already stored in Memgraph, the ontology does not need to be perfect at the start. It can be recreated or extended later based on how the customer’s use case develops.

2. How does entity resolution work when the same or similar entity appears in different places?

   • Entity resolution cannot rely on names alone. Two people may have the same name but different passport numbers, so they should not be merged. At the same time, the same person’s name may be written badly in a handwritten form, but a matching passport number or ID can confirm that the records belong together.

     The resolution process uses multiple signals, including normalized values, IDs, names, passport numbers, and other identifiers. This helps connect the right information across documents while avoiding false matches. In practice, the graph becomes useful because it can link related records through stronger identity signals instead of just matching text that looks similar.

3. Is there a language layer separate from the entity ID layer in the graph? Do you support international languages?

   • The document extraction process supports international languages and has been tested across 20 languages. The important part is that entity resolution can still work even when documents are written in different languages.

     For example, two documents may use different languages but contain the same passport number or ID. In that case, those shared identifiers can connect the documents to the same entity in the graph. The language can vary, but the identity signals still allow the system to link related records.