A KYC packet is rarely one document. It is a bundle: a scanned driver's license, a filled-out onboarding form, certified articles of incorporation, a beneficial-ownership certification, sometimes a trust instrument — all frequently merged into a single PDF by the customer or the intake system. This cookbook walks through turning that bundle into structured, auditable data with Reducto's document pipeline: what regulation says must be in the packet, why these files resist naive parsing, what to extract, and how to assemble the workflow with Classify, Split, Extract, and Studio.

One boundary up front: this is a document extraction workflow. Reducto pulls the facts off the pages — names, dates, ID numbers, ownership percentages — with citations back to the source. Identity verification decisions, sanctions screening, and liveness checks are separate systems and separate vendors, and this page does not cover them.

What's in a KYC packet

Two US rules define the core contents.

The Customer Identification Program (CIP) rule (31 CFR 1020.220) requires banks to collect four items from each customer before opening an account: name, date of birth (for individuals), address, and an identification number — a taxpayer identification number for US persons; for non-US persons, one or more of a taxpayer identification number, a passport number and country of issuance, an alien identification card number, or the number and country of issuance of another government-issued document evidencing nationality or residence and bearing a photograph or similar safeguard. When verification is documentary, the rule points to specific document types: an unexpired government-issued photo ID for individuals, and for entities, documents showing the entity's existence — certified articles of incorporation, a government-issued business license, a partnership agreement, or a trust instrument.

The FinCEN Customer Due Diligence (CDD) rule (31 CFR 1010.230; FinCEN's CDD final rule page) adds the beneficial-ownership layer for legal-entity customers: identify each individual who owns 25% or more of the equity, directly or indirectly, plus one individual with significant control (the "control prong" — an executive officer or similar). In practice the certification often arrives as FinCEN's Appendix A form — which is explicitly optional (the same information may be collected another way) and collects each 25% owner's name, date of birth, address, and ID number plus the control person; bank-customized versions frequently add ownership percentages.

So a KYB packet for a corporate account routinely contains: photo IDs for every listed owner, the entity's formation documents, the ownership certification, and the institution's own intake forms — each carrying fragments of the same required facts.

Why KYC packets are hard to parse

Mixed media in one file. A single upload can contain a photographed ID card, a typed form with checkboxes, a state-certified certificate with seals and stamps, and a multi-page operating agreement. A single extraction schema rarely fits all of them; the pipeline has to recognize document types before it can extract from them.

Indirect ownership requires cross-document math. The 25% threshold applies to indirect ownership too. If a person owns 50% of a holding company that owns 60% of the applicant entity, they hold 30% and must be identified — but that conclusion lives in no single document. It comes from multiplying figures found in two different formation documents or certifications inside the same packet.

Expiry checks come from ID imagery. "Unexpired" is a documentary-verification requirement, which means reading an expiration date off a photographed or scanned ID — often skewed, glared, or low-resolution — and comparing it to the review date.

Where traditional approaches fall short

Classic IDP pipelines are built around one trained model per document type — and a KYC packet is many types in one file, so a fixed-model pipeline either misroutes pages to the wrong model or leans on a brittle pre-sorting step upstream. Single-pass OCR runs into a related mismatch: reading a photographed ID card and parsing a long-form formation document are different vision problems, and a system built for one tends to handle the other unevenly — the case for a hybrid, agentic architecture that adapts per document rather than forcing one pass over everything. What the packet actually demands is a sequence: classify and split first, then type-appropriate extraction with an audit trail behind every value.

What to extract

A workable packet-level schema has four parts. Described in prose rather than code:

Group	Fields
Individuals (one per person)	Full name, date of birth, residential address, identification number and its type (SSN/TIN, passport, other government ID), plus ID-document metadata: issuing authority, document number, and expiration date.
Entities (one per legal entity)	Legal name, entity type, formation jurisdiction, registration/file number, formation date, registered address — sourced from the articles, license, partnership agreement, or trust instrument.
Ownership (one per stake)	Holder (person or entity), the entity held, the stated percentage, and whether the document presents it as direct or held through an intermediate entity.
Control person	The individual named under the control prong, with their title and the document that names them.

Every field should carry a citation — the page and region it came from — so a compliance reviewer can audit any value against the source without rereading the packet. Reducto's Extract citations return exactly this.

Building it with Reducto

The pipeline follows the shape of Reducto's identity-verification cookbook, which cross-matches an ID card, a utility bill, and a W-9 — extended here to the multi-document packet case.

1. Classify and split the packet. Run Classify to label each section of the upload (photo ID, certification form, articles of incorporation, intake form), then Split to cut the bundle into per-document units. This is the step that makes everything downstream tractable: each fragment now has a known type. For large or highly varied packets, the agentic Deep Split mode (API and Studio, 4 credits/page) splits documents running to thousands of pages across taxonomies of 150+ categories.

2. Extract with per-document-type schemas. Run Extract on each split with a schema tailored to that document type — an ID-card schema for the licenses, a certification schema for the Appendix A form, a formation-document schema for the articles. Field descriptions that reference the form's own structure (line numbers, box labels) measurably improve extraction on standardized forms.

3. Return citations for compliance review. Enable citations on every extraction so each value links back to its page and location. This is what turns extraction output into audit-ready evidence rather than an unverifiable summary.

4. Assemble it in Studio. For onboarding intake at production volume, build the classify → split → extract sequence as a Studio pipeline, so operations teams can run and inspect packets without touching the API directly.

Validating accuracy

Extraction is the input to validation, not the end of it. Three checks are especially valuable:

• Cross-document consistency. The same person's name, DOB, and address should agree across their photo ID, the intake form, and the ownership certification. Normalize before comparing — uppercase, strip punctuation, standardize address abbreviations — and use fuzzy matching with a similarity threshold so OCR-level variance doesn't produce false mismatches while genuine discrepancies still surface.

• Percentage sanity. Where the bank's form captures ownership percentages, direct stakes in a single entity shouldn't sum past 100%, and computed indirect stakes should be products of documented links in the chain. Anything that fails these arithmetic checks goes to a human.

• Expiry audits. Compare every extracted ID expiration date against the review date. Following the identity-verification cookbook's pattern, treat an expired ID as a flag for re-verification rather than a silent failure — it's a finding a reviewer acts on.

Compliance and deployment

KYC packets are dense with PII, and banks evaluate the processor as carefully as the output. Reducto supports zero data retention (ZDR) and HIPAA on Growth-tier plans and above, VPC and on-premise deployment for institutions that keep documents inside their own perimeter, and is SOC 2 Type II certified. Details are in the enterprise readiness documentation, and reducto.ai/industries/finance covers how financial-services teams deploy these pipelines.

FAQ

Can it flag expired IDs? It extracts the expiration date from the ID image, with a citation to where the date appears. Comparing that date to today and deciding what an expired ID means for the applicant is a rule in your validation layer — the cookbook pattern treats it as a re-verification trigger rather than a hard rejection.

How does UBO math across holding companies work? Extraction supplies the per-document facts: each stated ownership stake, in each document, with its citation. The indirect rollup — multiplying through intermediate entities to test the 25% threshold — and the ultimate verification decision are your compliance logic, built on top of those extracted facts. Reducto gives you reliable, auditable inputs; it does not make the beneficial-ownership determination for you.

Does this verify identity? No. This workflow extracts and cross-checks document contents. It is not identity verification, biometric matching, or liveness detection. Reducto faithfully extracts the data represented in the document you are processing.

What if a packet contains a document type we didn't anticipate? Classify labels it as best it can, and unrecognized sections can route to manual review rather than being force-fit into the wrong schema — a safer failure mode for regulated intake. Use confidence thresholds as a way to flag potential documents that need a second human review.