How to Extract Data for KYB Onboarding

Why document reading is the piece most often underestimated

Registry lookups and screening checks are well-established product categories with mature, easy-to compare vendors — evaluating them is mostly a matter of coverage and pricing. Document reading gets treated as an afterthought by comparison, often assumed to be a quick internal build on top of a general OCR service. That assumption tends to survive right up until real applicant documents — unfamiliar banks, scanned reports, inconsistent formatting — start arriving.

It doesn't help that "document reading" sounds simpler than it is — a human glances at a statement and immediately sees the account holder and the transaction list. Building software that does the same thing reliably, across banks it has never seen and layouts nobody anticipated, is a genuinely different scale of problem than it appears from the outside.

This guide treats document reading with the same seriousness as the other two pieces, because in a compliance-relevant flow, a document-reading gap is just as real a risk as a gap in registry coverage or screening depth.

How to evaluate a document-extraction vendor for this specifically

A general accuracy claim — "99% accurate" — is close to meaningless on its own, since accuracy varies enormously by document type and layout. The concrete way to evaluate a vendor for KYB document reading is to run your own representative sample — a real mix of the bank statements and reports your actual applicants submit — through the vendor's extraction endpoint and check the results field by field, not just document by document.

Worth confirming specifically: does the vendor return per-field confidence, or only a document-level score; does it classify document types automatically or require you to specify one in advance; and does it offer a free way to test before committing, since a vendor that requires a paid contract before you can see real output on your own documents is harder to properly evaluate.

A short pilot on your own document sample, before signing anything, resolves this in an afternoon — far faster than most teams expect going in, and considerably cheaper than discovering a coverage gap after the integration is already live and processing real applicants.

Before building anything, map exactly what your existing registry and screening providers verify — legal existence, registered address, directors, sanctions status. This map tells you precisely what's left for document reading to cover, and prevents the common mistake of trying to make document extraction answer a question a registry lookup already answers better.

In practice this is a short exercise: list every field your registry provider returns, list every check your screening provider runs, and put both lists next to what your risk policy actually asks for at each tier. What's left over — proof of a real operating bank account, evidence of financial standing — is the document-reading gap this guide fills.

Decide, by risk tier, which applicants need to submit a bank statement, which need financial reports, and which need both. A low-risk tier might need neither beyond the registry check; a higher-risk or higher-limit tier typically needs at least a bank statement, sometimes financials too.

This mapping is a compliance and product decision, not a technical one — the API reads whatever document type you send it, so the real work here is deciding your policy, not the integration.

flowparse.io

/validate is free on every plan and confirms your data contract matches what your risk logic expects, before spending anything on real extraction.

curl -X POST https://flowparse.io/api/v1/validate \
  -H "Authorization: Bearer pf_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{ "type": "bank_statement", "data": { "bank_name": "Example Bank",
        "account_holder": "Acme Trading Ltd" } }'
# → { "valid": true, "issues": [] }

Running this against the exact field names your downstream code expects — before writing any of that code against real extraction output — catches contract mismatches early and for free.

Test against real submissions from real applicants — or, pre-launch, real documents from design partners — not just clean sample statements. Include at least one scanned or lower-quality submission, since that's exactly where extraction quality actually gets tested.

A representative test set for this step usually includes: a clean digitally-generated statement, a scanned statement, a statement from a bank you don't expect most applicants to use, and — if your policy requires them — one financial report in whatever format your applicants are likely to submit. Running all four through the same call confirms the classification and extraction hold up across the range you'll actually see in production, not just the easiest case.

flowparse.io

Compare the extracted account holder or entity name against the legal name your registry check already returned. Decide how strict that match needs to be — exact string comparison is usually too rigid given legal suffixes ("Ltd" vs "Limited") and formatting differences, so most teams normalize both names before comparing.

Beyond the name match, the transaction array itself is worth a second, simpler check: does the account show ongoing, varied activity, or does it look dormant or freshly funded right before submission. This isn't a fraud model — it's a basic sanity check your risk logic can run directly on the structured transaction data, without any additional extraction work.

Decide which confidence level allows a document to proceed automatically versus routing to manual review. Start conservative — a relatively high threshold — and observe how many real submissions land in review before loosening it based on actual data rather than a guess.

Because confidence is returned per field rather than as a single document-level score, the threshold decision is actually two decisions: which fields matter enough to gate on at all (account holder name and key transaction data, typically — not every minor field), and what score on those specific fields is low enough to warrant a second look.

flowparse.io

Even a minimal version — a list of flagged documents with the specific uncertain field highlighted — is enough to launch with. Without this queue, documents below your confidence threshold either get silently ignored or silently accepted, neither of which is acceptable in a flow with real compliance weight behind it.

A useful minimal review view shows, per flagged document: the original file, the extracted field that triggered the flag, its confidence score, and the specific comparison that failed (a name mismatch, a totals check that didn't tie out). A reviewer with that context can usually decide in under a minute — far faster than reviewing the raw document from scratch.

Track the share of documents landing in manual review and, separately, the share that get corrected after review — a rising trend in either is the first concrete signal worth investigating, well before it becomes visible as a slower onboarding funnel or a compliance concern.

Worth tracking specifically: review rate by document type (bank statement vs. financial report), since the two can drift differently as your applicant mix shifts, and review rate by the bank or report format most commonly submitted, which can surface a specific source worth a closer look rather than treating accuracy as one undifferentiated number.

Common mistakes in this integration

How long each step takes

Steps 3 and 4 typically take a few hours — the slower part is usually gathering a representative sample of real applicant documents, not the API call itself. Step 7, the review queue, is the most variable: a minimal version is a day of work, a fully polished interface can come later without blocking the rest of the integration.

Steps 1 and 2 — the mapping and policy decisions — often take longer in calendar time than any of the technical steps, simply because they usually require sign-off from a compliance stakeholder who isn't part of the engineering team's day-to-day sprint planning. Starting those conversations early, in parallel with step 3, keeps them from becoming the critical path.

A full onboarding flow, start to finish

A fintech adds document verification to its existing KYB flow, which already runs a registry lookup and sanctions screening.

The document-reading piece slotted in alongside the existing registry and screening checks without requiring changes to either — three independent inputs feeding the same risk decision.

Troubleshooting the first two weeks

Designing the review queue UI, in more detail

The minimal version described in step 7 — a list with the flagged field highlighted — is enough to launch, but a few refinements make a real difference to reviewer speed once volume grows past a handful of documents a day. Sorting the queue by how far a document is below threshold, rather than by submission time, surfaces the genuinely uncertain cases first. Showing the original document side by side with the extracted field, rather than requiring a separate click to view it, cuts the time per review meaningfully.

A reviewer decision should also feed back into your own records — approved, rejected, or escalated, with a note — both for the applicant's own case history and, over time, as a dataset your team can use to sanity-check whether the confidence threshold is still calibrated correctly as volume and applicant diversity grow.

A second example: adding a higher-risk tier

Six months after the initial launch above, the same fintech adds a higher transaction-limit tier that requires financial reports in addition to a bank statement. Because both document types run through the same /extractcall and are classified automatically, this required no new integration work — only a policy update (step 2, revisited) and an extension of the name-match logic (step 5) to also compare the financial report's entity field against the registry name.

This is the practical benefit of scoping the document-reading piece around a single, well-built API rather than a bespoke parser for each document type — extending coverage to a new document type is a policy and matching-logic change, not a new extraction pipeline to build.

A printable checklist

Who this guide is for

If your team already has a working registry and screening integration and is specifically missing the document piece, you can likely skip straight to step 3 — steps 1 and 2 are mostly a formality in that case.

Engineering and product teams at fintechs, embedded finance platforms, marketplaces vetting business sellers, and any B2B platform with a KYB requirement, building or improving the document-verification piece of an onboarding flow — regardless of which registry or screening vendor sits alongside it.

It's equally useful for a team building this for the first time and one auditing an existing, partially-built integration — the eight steps work as a build order in the first case and as a checklist to compare against in the second.

Doing this across growing onboarding volume

The eight steps don't change as volume grows — what changes is how much of the review step is mechanical versus genuinely needing a person's judgment. A well-calibrated confidence threshold keeps the review queue proportional to actual uncertainty rather than growing linearly with application volume, which is exactly what makes this approach hold up from a pilot cohort to full production onboarding.

What does need attention as volume grows is the reviewer headcount behind the queue itself — even a well-tuned threshold produces some review load, and a queue that's well-designed but understaffed becomes the actual bottleneck in an otherwise fast onboarding flow.

When to revisit your threshold and matching rules

A threshold and matching setup that worked well at launch isn't necessarily right forever. Worth a deliberate revisit whenever your platform expands into a new country or currency, whenever your applicant mix shifts toward a different kind of business (more sole proprietors, say, versus established corporations, which can have systematically different document quality), or whenever the review-rate trend from step 8 has moved meaningfully in either direction.

Treating this as a periodic check — quarterly is a reasonable cadence for most platforms — rather than a one-time setup keeps the integration matched to your actual, evolving applicant base instead of the assumptions made during the initial build.

Questions to bring back to your risk or compliance team

A handful of the decisions in the steps above genuinely aren't engineering calls, and it's worth being explicit about which ones need sign-off rather than making the call unilaterally. Specifically: which risk tiers require which documents (step 2), what counts as an acceptable name match (step 5), and where the confidence threshold should sit at launch (step 6). Bringing a concrete proposal for each — not an open-ended question — tends to get a faster, more useful answer than asking your compliance team to design the policy from scratch.

A short glossary

Keeping these three checks conceptually distinct — even when they feed the same overall risk score — is what makes it possible to evaluate, integrate and improve each one independently.

Handing this off to compliance or a consultant

A compliance team reviewing this integration will want to see, concretely, which fields get extracted, how the name-match logic works, and what happens to a document that fails the confidence threshold. Documenting the eight steps above, with your specific thresholds and matching rules filled in, gives them exactly that — a concrete process to review instead of a black box to take on faith.

Worth including in that documentation specifically: a real example of a document that passed, a real example of one that got routed to review, and the reasoning a reviewer applied to resolve it — three concrete cases communicate the process far more effectively than a description of the logic alone.

Frequently asked questions

Keep reading