Bank statement extractionfrom any bank.
Account data, balances and complete transaction tables from any bank's statement format, without per-bank templates. Built for lending, KYC and finance workflows where the numbers must reconcile.
Credit and finance teams work with clean transaction data, whatever bank the statement comes from.
What MiruIQ extracts from a bank statement.
The typical statement schema. Adjust it to your process in minutes.
| Field | What it captures |
|---|---|
| Account holder | Name and address of the account owner. |
| IBAN / account number | Account identifier, validated for format. |
| Bank and BIC | Issuing institution and its identifier. |
| Statement period | Start and end date the statement covers. |
| Opening balance | Balance at period start. |
| Closing balance | Balance at period end, cross-checked against transactions. |
| Transaction dates | Booking and value date per transaction. |
| Counterparty and description | Who the money went to or came from, with the booking text. |
| Amounts | Debit and credit per transaction, sign-normalized. |
| Running balance | Balance after each transaction, verified for continuity. |
Not a pre-trained model, a schema you control.
Every bank formats statements differently; the schema does not care. Define the fields once and extract from any institution, including ones you have never seen.
Consistency checks do the heavy lifting: opening balance plus transactions must equal closing balance, and running balances must be continuous. Statements where the math does not close park for review, which is exactly where document fraud shows at the data level.
Statement extraction questions
What lending and finance teams ask most.
Schema-driven extraction reads the account data and the full transaction table from any bank's layout, then validates: opening balance plus transactions must equal the closing balance, and running balances must be continuous. Statements that fail park for human review. Results deliver as structured data to your systems.
Yes. Multi-page tables, mixed formats and dense layouts extract row by row, and interpretive notes are applied: a header note saying amounts are in thousands, or that trailing zeros are cut off on purpose, changes how the numbers are read. That interpretation step is where naive table extraction silently produces wrong data.
All of them, because there is no per-bank template to build: extraction is generic and driven by your schema, not by a catalog of supported institutions. A statement from a small regional bank processes the same way as one from a global institution, in any of the languages the pipeline handles.
See it on your own documents.
The 14-day free trial covers 200 documents: enough to define your schemas, run real files and measure the results before anyone calls you.