Know Your Client: Documents, Risk and Checks

Know your client is the risk-based duty to identify the customer, verify that identity, and retain evidence that supports a reasonable belief in who they are. The useful output isn't a completed form, but a versioned evidence file that remains defensible when customer facts change.

The operational stakes are substantial: KYC-related fines increased 102% to US$51 million in the first half of 2024, according to Fenergo's analysis of global regulatory penalties. Reading documents faster helps only when teams can explain which evidence they accepted, which checks they performed, and who approved exceptions.

What Know Your Client Requires You to Prove

Know your client is an evidence-backed process, not document collection. A know your client file should distinguish what the customer claimed, what the organization verified, and why the organization accepted the result.

The U.S. framework makes this an operating control. The USA PATRIOT Act of 2001 required Treasury to establish customer-identification rules; the final Customer Identification Program rule was issued on May 9, 2003, became effective June 9, 2003, and generally required implementation by October 1, 2003, as documented in the Federal Register's final CIP rule. Its scope included banks, savings associations, credit unions, private banks, and trust companies.

Minimum know your client data and retention

FinCEN's customer-identification guidance describes the core identifying information, risk-based verification approach, and retention split summarized below: identifying information is generally retained for five years after account closure, while verification records are retained for five years after the record is made.

Data point	Who it covers	How it is checked	Retention
Name	Customer	Documentary or non-documentary methods, by risk	5 years after account closure
Date of birth	Individuals	Documentary or non-documentary methods, by risk	5 years after account closure
Address	Customer	Documentary or non-documentary methods, by risk	5 years after account closure
Identification number	Customer	Government identification or another permitted number, with risk-based verification	5 years after account closure
Beneficial owner identity	Each beneficial owner	Same core verification elements as individual CIP	Verification records kept 5 years after the record is made
Verification evidence	Covered account	Procedures supporting a reasonable belief in identity	5 years after the record is made

Documentary checks examine evidence such as a passport. Non-documentary checks corroborate identity through other permitted methods, such as an authoritative record. Institutions can combine them according to their written procedures and customer risk.

Beneficial-owner verification needs its own evidence trail. A corporate registration document doesn't establish the identity of every person who ultimately owns or controls the customer.

Keep claims separate from decisions

One flattened JSON object is a weak audit file if it mixes customer attributes, owner details, and approval decisions without distinguishing their sources. JSON itself isn't the problem. The problem is an absent evidence structure.

Store source-document references, extracted values, normalization changes, validation results, timestamps, reviewer overrides, and retention metadata as distinguishable records. The distinction between collecting attributes and verifying identity helps teams decide which fields need corroboration.

Practical check: Compare your onboarding form with the core CIP fields. Mark any required element that exists only inside an unread image.

Where Manual Know Your Client Breaks Down

In 2024, 67% of global banks reported losing clients during KYC onboarding, up from 48% in 2023, according to Fenergo's survey of more than 450 C-suite executives, reported by Fintech News Philippines. That finding concerns onboarding attrition, not proof that manual transcription alone caused each loss.

The operating problem is still recognizable. Customers submit documents, staff request replacements, and applications wait while someone reconciles inconsistent names or an unreadable identification number.

The hidden stack of rework

An analyst rarely performs only one task when processing an identity document. The actual work includes:

• Transcription: Copying names, dates, addresses, and document numbers into several systems.
• Document chasing: Requesting clearer images, missing pages, or current evidence.
• Reconciliation: Resolving differences between an application, passport, and corporate extract.
• Evidence retrieval: Reopening files because nobody recorded which page supported an accepted field.

Traditional OCR can recognize characters without supplying the surrounding workflow. If its output is an undifferentiated text block, another person still has to identify the document, locate fields, apply checks, and attach the evidence.

A correctly read passport number can also be copied into the wrong customer record. Character recognition doesn't prevent that operational error.

Budget pressure doesn't fix file design

In 2025, 87% of surveyed organizations expected enhanced-due-diligence budgets to increase over the following twelve months, with an average expected increase of 5.2%, according to LSEG's survey of 550 compliance and risk decision-makers. Separately, more than 40% of respondents expected KYC remediation costs to rise in KYC360's 2025 survey of 116 compliance professionals.

These surveys describe expectations, not guaranteed spending outcomes. They nevertheless give operators a reason to examine where work repeats rather than adding reviewers.

The same concern reaches beyond banks: Juniper Research projected non-financial businesses' global spending on KYC and KYB systems at US$9.2 billion in 2024.

A faster scan without an exception path can move unresolved problems downstream. Measure how many files staff reopen, why they reopen them, and whether the original evidence is immediately available.

Risk Tiers That Change the Evidence

One document pack shouldn't be demanded of every customer. Start with the obligations the relationship creates, then choose evidence strong enough to satisfy them. A risk tier changes three things: how thoroughly you prove identity, how far you trace ownership, and how often you refresh the file. The tier is a version control rule for evidence, not a permanent label.

A customer who moves country, changes controller, or adds a new beneficial owner has a new version of the file, even if the old passport scan still looks clean. Customer due diligence extends beyond identification. The IMF's account of the FATF standards and their 2003 and 2012 revisions describes stronger international requirements, enhanced measures for higher-risk relationships, and coverage of designated nonfinancial businesses and professions.

The practical duties are to:

• Identify and verify the customer.
• Identify and verify the beneficial owner.
• Understand the purpose and intended nature of the relationship.
• Conduct ongoing due diligence and scrutinize transactions.

Identity assurance levels for know your client

NIST defines three identity assurance levels in its identity-proofing guidance. The table maps what each level requires and where it usually appears in a KYC file.

Level	What must be true	How proofing happens	Typical KYC use
IAL1	Attributes may be self-asserted, without validation or verification	No identity evidence required	Low-consequence services, not a substitute for mandatory customer verification
IAL2	The real-world identity exists and the applicant is linked to it	Remote or in person	A useful reference for regulated remote-onboarding design, subject to applicable rules
IAL3	Stronger proofing includes physical-document examination	In person, by an authorized representative	Highest-assurance identity-proofing cases

Use the levels to plan proofing confidence, not to replace the customer's money-laundering risk rating. Identity assurance concerns confidence in who someone is. Customer risk also concerns what they do, where they operate, and how they intend to use the service. A confidence score from OCR is not an assurance level either. It tells you how clearly characters were read, not whether the person presenting the document is the customer.

For a corporate customer, separate directors, representatives, and beneficial owners. A company arrangement such as an Irish company with a nominee resident director can make ownership hard to read because the person named as director may not be the person who controls the company. The file should establish each person's role rather than infer ownership from a director's name.

Proportionate evidence needs a fallback

NIST's enrollment and identity-proofing publication frames assurance selection around the risks of proofing failure, the population served, and the intended service outcome. A universal document setting ignores those differences.

A customer without a stable address, smartphone, or standard identification needs a written fallback where permitted. Define acceptable evidence combinations, accessible submission methods, human review, and recorded reasons for the decision.

A high automated acceptance rate isn't an inclusion measure if customers who need alternative evidence can't enter the review queue.

For higher-risk relationships, document who can request stronger corroboration, beneficial-owner evidence, source-of-funds information, and senior approval. Keep adverse media screening connected to those escalation decisions rather than treating it as another identity field.

Write the intended assurance level beside each product before choosing its document requirements.

How AI Turns Identity Documents into Records

Document data extraction converts information in files into structured fields that software can use. For KYC, those fields must remain connected to the evidence and checks that justify their use.

OCR reads characters. Classification identifies the document type. Validation tests extracted values against defined rules, and workflow automation determines what happens next.

A pipeline compliance and engineering can share

1. Classify the upload. Identify passports, national identification cards, Spanish foreigner identification documents known as NIE documents, proof of address, corporate extracts, and unrelated files. Split mixed PDFs into logical documents before assigning fields.
2. Extract the required attributes. Capture the name, date of birth, document number, expiry, or address needed for the chosen workflow. Don't collect every visible word merely because the software can read it.
3. Validate the result. Check field formats, document expiry, name consistency across pages, and checksums where the document type supports them. Treat an unsupported check differently from a failed check.
4. Preserve provenance. Store the source image, page, extraction confidence, validation status, and escalation rule with each field. Record transformations, such as converting a printed date into the system's standard format.
5. Route the decision. Send validated fields to the customer system and unresolved cases to a review queue. Show reviewers the source image beside the structured result, with a clear place to accept, correct, or reject it.

A high OCR confidence score means the text was read with confidence, not that the person is real.

Judge identity assurance separately

FATF's digital identity guidance recommends evaluating identity proofing, authentication, technology, architecture, and governance against the customer, product, jurisdiction, and associated risks. A document-extraction score covers only part of that assessment.

Lower-risk workflows may combine extraction, authenticity checks, and database corroboration. Higher-risk cases may need liveness detection, biometric or authoritative-record matching, manual review, and more intensive monitoring.

Those checks shouldn't be inferred from successful extraction. A field marked “validated” should say whether that means its format passed, its value matched another record, or a reviewer accepted the supporting evidence.

Matil does not guarantee 100% accuracy. Results must always be supervised and expressly accepted by the client.

The audit test is practical: can an examiner move from an accepted field to its source image, see the transformation applied, and identify the person who overrode a failed check?

Where Matil Fits a Know Your Client File

Matil isn't only OCR. Its API combines document classification, extraction, validation, and workflow orchestration, allowing PDFs, images, and multi-page packs to become structured JSON in seconds.

Pretrained models cover identity cards, NIE documents, passports, and neighboring evidence such as bank statements. Clients can use these models without conducting training or maintaining model infrastructure.

For documents outside the pretrained set, a visual model builder lets the client define the fields and output structure without writing machine-learning code. Custom models can be ready in days, and accuracy above 99% across multiple use cases is reported, not a guarantee for every document or field.

Make the integration serve the evidence file

The useful integration is not just “upload PDF, receive JSON.” It maps each extracted value to a customer, a source document, and a defined business rule.

For example, an identity number should feed the customer record without losing the page that supports it. A failed expiry check should create a review task rather than disappear into an application log.

Define the handoff explicitly:

• Customer-system mapping: Specify the destination for each accepted attribute.
• Exception ownership: Assign the person or team responsible for unresolved checks.
• Evidence storage: Preserve the source documents and decision history in the client's controlled record system.
• Acceptance logging: Record corrections and the client's express acceptance of results.

For teams working within South Africa's framework, Zaro's resource on ways to improve FICA compliance with Zaro offers useful jurisdiction-specific context. Keep those compliance decisions separate from the technical act of extracting a field.

Personal data and the processor role

When processing personal data, we act as a processor under the GDPR, following only the client's instructions as controller. The client retains rights over uploaded documents and the structured JSON results.

We don't use clients' personal or confidential document data to train public generative models or models shared with other clients. Enterprise controls cited for the platform include ISO 27001, AICPA SOC, zero data retention, and an availability SLA above 99.99%.

Zero data retention doesn't remove the client's obligation to retain required KYC evidence. Design the integration so the client's authorized systems receive and preserve the documents, results, and acceptance records they need.

That division matters to legal and engineering alike. The processor handles the instructed document operation; the controller determines the purpose, required evidence, access rules, and retention arrangements.

KYC Moments That Need a Fresh Document

A customer uploads a passport and proof of address in one PDF. Instead of asking an analyst to split and retype it, classification separates the files and extraction prepares the required fields. The reviewer resolves mismatches before accepting a traceable onboarding record.

Later, a new beneficial owner appears. If the team waits for the next scheduled review, it may continue relying on a file that no longer describes the customer. An ownership-change trigger should request the new owner's identity evidence and route it for verification.

KYC events and the evidence to request

Use an event matrix to make document requests predictable. The paths below are operational examples to adapt to applicable law and written policy.

Event	Evidence to collect	Path
New account	Identity document and CIP data appropriate to the product's assurance requirements	Extract, validate, then screen
Ownership change	Identity pack for each new beneficial owner	Re-verify owners; senior approval if high risk
Expired ID	Current identity document	Re-extract and create a new version without deleting historical evidence
Address change	New address evidence	Update the address and rescreen if required
Adverse information	Source material plus a written decision	Enhanced due diligence
Unusual transaction	Purpose and source of funds where required	Monitoring escalation
Standard-risk refresh	Updated customer information	Scheduled review under the applicable EU refresh rule
Enhanced-risk refresh	Fuller due-diligence pack	More frequent review under the applicable EU refresh rule
Transaction meeting the EU threshold	Transaction-specific customer due diligence	Apply the threshold when within scope

The new EU AML framework introduces a EUR 10,000 transaction-specific customer-due-diligence threshold and customer-information refresh intervals of at least every five years for standard-risk customers and one year for customers subject to enhanced due diligence, as explained in Baker McKenzie's guide to the EU AML framework. These are planning requirements for the new framework, not a reason to assume every provision already applies to every current relationship.

Version the evidence rather than overwrite it

A fresh passport should create a new evidence version linked to the previous record. Parsing the machine-readable zone on a passport can support field checks, but the replacement still needs the applicable verification and acceptance process.

A firm can be within its review cycle while its customer-risk facts have already changed.

Keep the event, requested evidence, resulting decision, and reviewer visible together. Circle the event that creates the most rework today, then give it a defined request and escalation path.

Invoices, Payroll and Logistics Files

The same classify, extract, and validate pattern applies beyond identity documents. The fields and acceptance rules change, however, so a KYC configuration shouldn't be copied into accounts payable or customs processing.

Invoices and payroll

Invoices: A supplier sends a scanned PDF, and an accounts-payable analyst retypes supplier details, tax identifiers, totals, and line items. Extraction can prepare those fields, compare line sums with totals, and route mismatches before an approved entry reaches the accounting system.

Structured fields don't automatically satisfy tax obligations. The European Commission's explanation of e-invoicing and digital reporting distinguishes electronically issuing and receiving invoices from digitally submitting transaction data to authorities.

Payroll: Staff may need to reconcile gross pay, deductions, net pay, and contribution bases from payslips. Extract those components and apply the payroll-specific arithmetic, including any additions or adjustments, rather than assuming every document follows the same calculation.

The result is reconciliation against structured values instead of another round of manual entry.

Logistics documents

A bill of lading or customs declaration, including a DUA, may require staff to enter the same shipment details into several systems. Capture the relevant cargo, consignee, shipment-reference, and tariff fields where present, then check completeness before the filing handoff.

Use document-specific controls:

• Bills of lading: Check parties, transport references, and package or cargo details against the shipment record.
• Customs declarations: Check required declaration fields and classification data before submission.
• Supporting documents: Link invoices and delivery evidence to the correct shipment rather than accepting them as isolated uploads.

These workflows don't require an identity-assurance decision. They need their own financial, payroll, transport, or customs validation rules.

What Accurate Extraction Changes for Teams

Accurate extraction changes how analysts spend their attention. Instead of copying every field, they can work from a queue organized around failed checks and missing evidence.

A review workspace should make the source document and decision status easy to inspect.

Outcomes an operations lead can test

• Time: Analysts stop retyping accepted names and dates, and handle the cases that need judgment.
• Errors: Format and expiry checks can catch problems before staff accept the record.
• Scale: Routine document processing can accommodate more applications without requiring proportional transcription effort.
• Traceability: Reviewers retrieve the source page and override history rather than search email attachments.
• Automation: The customer platform, screening service, and case system can consume the same accepted structured values.

Measure these outcomes at queue level. Compare correction work, unresolved exceptions, document requests, and retrieval effort rather than treating extraction throughput as the only success measure.

The following video provides another format for exploring the document workflow.

Extraction doesn't set the customer's risk rating, approve a high-risk relationship, or replace sanctions screening. It removes copying work so the people making those decisions have usable evidence.

Start with the Documents You Already Reopen

Pick one live queue: expired identity documents, beneficial-owner updates, or mixed onboarding packs. Choose the queue where staff repeatedly reopen files because the required evidence or acceptance decision isn't clear.

Write a small acceptance specification

• Required fields: Name the attributes that must reach the customer record.
• Assurance requirement: State the proofing standard appropriate to the product and applicable rules.
• Exception owner: Identify the person authorized to resolve mismatches and accept the result.

Test complete files alongside awkward ones. Include unreadable pages, inconsistent names, missing evidence, and customers who need an accessible fallback.

We contact prospects within 24 hours after they leave details on the contact form to study how we can help with their case. Exploring whether a queue fits is enough; there's no need to redesign the entire onboarding process first.

Software doesn't satisfy a regulator by itself, and the client remains responsible for accepting each record. The job of the file is a reasonable belief, backed by a document a reviewer can still open.

---

Matil offers document classification, structured extraction, validation, and workflow automation for identity-document processing. Visit Matil to explore your existing KYC queue and leave your details for a personalized case review, starting with the documents your team already has to reopen.