What actually needs reading in a KYB flow
A know-your-business flow bundles together two genuinely different problems, and it's easy to conflate them. The first is confirming a business legally exists — registration number, status, directors, registered address. That data lives in a government or commercial registry, and a registry-lookup API answers it directly; no document reading is involved. The second problem is verifying the documents a business actually hands over during onboarding — a bank statement to prove it operates a real account, a set of financials when the risk tier calls for it. That second problem is a document-reading problem, and it's the one this API solves.
This page describes reading and structuring exactly those documents — bank statements and financial reports — with a confidence score on every field, so a KYB platform gets clean data to check against what it already knows about a business, instead of building that reading layer itself.
Why this gets confused with registry lookups
"KYB API" gets used loosely enough in vendor marketing that it's reasonable for a team scoping an onboarding flow to expect one product to cover everything — legal existence, UBO structure, sanctions screening, and document verification, all from one call. In practice these are built by entirely different kinds of companies, using entirely different data sources: registry data comes from government and commercial databases, screening comes from curated sanctions and PEP lists, and document verification comes from actually reading the PDF a business uploaded.
Most teams end up integrating two or three providers for a complete flow, not one — and the document-reading piece specifically is the one most often underestimated, because a bank statement or a financial report looks, at a glance, like "just another PDF," when reading it reliably at scale is its own real engineering problem.
What this API doesn't decide
Doesn't confirm legal existence or registration status
That's registry data — company number, incorporation date, registered address, filing status — which comes from a company registry API, not from reading a document.
Doesn't read incorporation certificates or articles of association
Those are structured legal filings with jurisdiction-specific formats this API doesn't attempt to parse. It reads bank statements and financial reports.
Doesn't run sanctions, PEP or watchlist screening
Screening against curated lists is a separate, specialized check run by dedicated providers — this API only structures the documents themselves.
Doesn't decide your risk score or approval outcome
It returns structured, confidence-scored data. Where that data pushes a risk score, and what threshold triggers manual review, is entirely your platform's logic.
Where this sits next to a registry API and a screening provider
A complete KYB flow typically layers three kinds of checks: a registry lookup confirms the business exists and pulls its official details, a screening service checks the business and its principals against sanctions and watchlists, and this API reads the financial documents the business submits alongside those checks — a bank statement, a set of financials, whatever the risk tier requires.
None of the three replaces the others, and none of them is optional for a platform that wants a genuinely complete picture. This API is deliberately scoped to the third piece, done well, rather than attempting a shallow version of all three.
Why it works without a template for every bank
A common early assumption about document extraction is that it needs a template per bank or accounting system — a mapping of "this bank's statement puts the account number here, that bank puts it there." That approach breaks the moment an applicant submits a statement from a bank nobody built a template for, which for a KYB platform onboarding businesses across many countries and banking relationships is not an edge case — it's a routine occurrence.
Extraction here works from the document's own printed structure instead — reading a statement's layout the way a person would, rather than matching it against a fixed template for one specific bank. A statement from a bank processed for the first time is read the same way as one from a bank seen a thousand times before, which matters directly for a KYB platform whose applicant pool isn't limited to a handful of well-known banking relationships.
The same holds for financial reports — an entity's income statement, balance sheet or multi-section report is read from its own printed section structure and totals, not from a template tied to one accounting package's export format.
The calls that matter
Four endpoints cover the extraction workflow, documented in full on the API docs page— the shape below is what you'll actually call from an onboarding pipeline.
curl -X POST https://flowparse.io/api/v1/extract \
-H "Authorization: Bearer pf_live_xxx" \
-H "Content-Type: application/json" \
-d '{ "file": "JVBERi0xLjcK...", "filename": "business-account-statement.pdf" }'
# → { "type":"bank_statement", "pages":3, "billedPages":3,
# "price": { "eur":0.10, "perPageEur":0.035, "complexity":"standard" },
# "data": { "type":"bank_statement", "data": {
# "bank_name":"Example Bank", "account_holder":"Acme Trading Ltd",
# "statement_period":"2026-06-01 to 2026-06-30",
# "transactions":[ ... ] } } }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": [] }/validate is free on every plan, the right place to prototype your data contract before spending anything on real extraction volume.
What gets read
| Document type | What comes back |
|---|---|
| Bank statement | Bank name, account holder, account number (masked), IBAN/BIC when printed, statement period, every transaction with date, amount and running balance |
| Financial report | Entity name, reporting period, currency, every line-item section, plus a check on whether the document's own totals tie out |
Both document types are classified automatically — the same /extractcall handles whichever one a business actually submitted, without your platform needing to know in advance which type it's sending.
Verification signals this actually gives you
Account holder name match
The bank statement's account_holder field can be compared directly against the legal entity name already on file from your registry check — a mismatch is a concrete signal worth a closer look.
Genuine trading activity
A transaction history with regular, varied activity looks structurally different from a dormant or newly-funded account — the raw transaction data lets your platform build that check itself.
Financial report internal consistency
The report_check verdict confirms whether the submitted financials' own printed totals actually tie to the line items — a real check on internal consistency, not a judgment on accuracy.
Statement recency and continuity
The statement_period field lets your platform confirm a submitted statement is recent enough and, across multiple submissions, that periods aren't suspiciously gapped.
None of these four signals is a verdict on its own — each is a data point your platform's risk logic weighs alongside the registry and screening checks, not a pass/fail decision this API makes for you.
How pricing works
Extraction is billed per page, in complexity tiers — a clean, single-page bank statement costs less than a dense multi-page financial report or a lower-quality scan. No per-seat licensing, no minimum monthly commitment to start.
curl https://flowparse.io/api/v1/usage \
-H "Authorization: Bearer pf_live_xxx"
# → { "plan":"PRO", "pageRangeEur": { "minEur":0.01, "maxEur":0.15 },
# "balance": { "pages":812, "monthlyRemaining":712, "bonusPages":100 },
# "thisMonth": { "requests":143, "pages":288, "spendEur":8.18 } }For an onboarding flow, this maps cleanly onto a per-application cost — the cost of verifying one business's submitted documents becomes a known, predictable number you can build directly into your own onboarding pricing or cost model.
How it fits into an onboarding flow
A business uploads a document during onboarding
A bank statement or a set of financials, wherever your platform already collects onboarding documents.
Your pipeline calls /extract
One POST with the file; structured JSON with fields, transactions or sections, and confidence scores comes back.
Your platform cross-checks the data
Account holder name against the registry-verified legal name, transaction activity against your own risk rules.
The result feeds your risk decision
Alongside the registry and screening checks — this API's output is one input among several, not the final call.
A worked example: a new business account
A fintech onboarding flow receives a registered business name of "Acme Trading Ltd" from its registry check, then asks the applicant to upload a recent bank statement. The statement comes back from /extractwith account holder "ACME TRADING LIMITED" and 47 transactions spanning the full statement period, overall confidence 0.98.
| Check | Result |
|---|---|
| Extraction | 0.4 seconds, 3 pages, $0.10 |
| Name match against registry data | Close match after normalizing legal suffix — passed |
| Transaction activity | 47 transactions, regular pattern, no gaps in the period |
| Human review needed | No — passed straight through to the risk decision |
A second applicant's statement comes back with an account holder name that doesn't match the registered business at all — flagged for manual review, not auto-rejected, since a legitimate explanation (a recently renamed entity, a parent-company account) is entirely possible and worth a human looking at it.
Build vs. buy
| Building it yourself | Calling this API |
|---|---|
| A general OCR service plus your own field parsing, transaction table reconstruction and confidence logic | One typed schema back from a single call |
| Engineering time measured in months, plus ongoing maintenance as new bank and report layouts appear | Integration typically working within a day or two |
| Infrastructure to host, monitor and scale yourself | No infrastructure — usage-based pricing, no servers to run |
| Your team owns every accuracy regression during a compliance-sensitive flow | Extraction quality is this API's core product, improved independently of your release cycle |
The stakes are higher here than in most document-extraction use cases — a KYB flow's document verification step is often compliance-relevant, which makes an accuracy regression from an under-maintained in-house parser a genuinely bigger problem than in a purely internal accounting workflow.
Common integration mistakes
Treating a low confidence score as a rejection
A low score on one field means that field is genuinely uncertain and worth a human look — not that the whole document, or the applicant, should be rejected outright. Most teams route by field-level confidence, not a single document verdict.
Comparing names with a strict exact match
“Acme Trading Ltd” and “ACME TRADING LIMITED” are the same entity. A name-matching step that normalizes case, punctuation and legal suffixes before comparing avoids a wave of false mismatches that have nothing to do with actual risk.
Skipping /validate during development
Testing your data contract against the free /validate endpoint before running real extraction volume catches integration bugs — a missing field your code expects, a type mismatch — without spending on extraction while you're still debugging your own pipeline.
Assuming report_check false means a fraudulent document
A totals mismatch can come from a page that didn't scan cleanly just as easily as from a genuinely altered document. It's a strong signal for review, not proof of anything on its own.
Accuracy and confidence scoring
Field accuracy sits around 99% on standard bank statement and financial report layouts — documents generated digitally by a bank's own online banking export or a company's accounting software. A scanned or photographed submission can vary more, which is exactly why every field carries its own confidence score.
That per-field granularity matters specifically for onboarding — a submission with one uncertain field doesn't need the same manual review effort as one where extraction genuinely struggled throughout, which keeps your review queue proportional to actual risk instead of growing with every borderline submission.
Export formats
Beyond raw JSON for direct integration, the same extracted document can be exported to xlsx or csv — useful if your compliance team needs a file to attach to a case file rather than raw structured data.
curl -X POST https://flowparse.io/api/v1/export \
-H "Authorization: Bearer pf_live_xxx" \
-H "Content-Type: application/json" \
-d '{ "format": "xlsx", "type": "bank_statement", "data": { ... } }'
# → { "format":"xlsx", "filename":"statement.xlsx",
# "encoding":"base64", "content":"UEsDBB..." }Errors and rate limits
| Code | Meaning |
|---|---|
| 400 | Malformed request body or unsupported format |
| 401 | Missing, invalid or revoked API key |
| 422 | No extractable data in the supplied document |
| 429 | Page balance exhausted — top up to continue |
| 500 | Unexpected error generating the response |
There's no request-per-second throttling to design around — the only limit is your page balance, which tops up instantly on payment confirmation, so a burst of applications arriving together doesn't need special-cased handling in your onboarding pipeline.
From a pilot to full onboarding volume
A platform integrating this for the first time typically starts by routing a handful of test submissions through /extract manually, confirms the schema matches what its risk logic expects, then wires it into the real onboarding pipeline once the confidence-threshold routing is tuned to its own risk tolerance.
From there, volume scales without any change to the integration itself — the same call handles ten applications a day or ten thousand, since pricing and throughput are usage-based rather than tied to a fixed infrastructure tier.
Who this is for
Fintech and neobank onboarding teams
The document-reading layer of a KYB flow, without building bank statement and financial report parsing in-house.
Business verification and KYB platforms
A concrete API to integrate alongside your registry and screening providers, covering exactly the document piece.
Embedded finance and BaaS platforms
Document verification for business accounts opened through your own onboarding surface.
Compliance and risk engineering teams
Confidence-scored, auditable extraction output that traces every field back to the submitted document.
Why document verification keeps getting rebuilt badly
A first version of document reading for onboarding usually looks deceptively finished — a demo against a handful of clean test statements works fine, and it's easy to conclude the hard part is done. The actual difficulty shows up once real applicants submit real documents: a statement from a bank nobody tested against, a financial report in an unfamiliar layout, a scan taken at an angle on a phone.
In a compliance-adjacent flow, that gap matters more than in most document-processing contexts — an extraction error here doesn't just cost time to fix, it can mean a genuine business gets wrongly flagged, or a real risk signal gets silently missed because a field was misread. Treating extraction accuracy as a specialized, continuously-improved product rather than a side project inside a KYB platform's own engineering team is what most teams conclude after running the in-house version for a while.
Get your API key
Grab a free API key and run a real bank statement or financial report through /extract before committing to anything — no credit card required to see the response shape.
Security and privacy
Uploads are encrypted with TLS from end to end.
Processing runs on infrastructure with SOC 2-aligned controls.
Original documents are deleted shortly after processing.
Nothing you upload is ever used to train AI models.
For documents submitted during a KYB flow, this matters directly to your own compliance posture — full details are on the security page.