Frequently Asked Questions

Bank Statement Parser is engineered entirely in high-assurance native Rust with zero-copy stream processing, SIMD-accelerated string scanners, and direct memory layout mapping. By avoiding intermediate object allocations and skipping heavy browser engines or JVM runtimes, the tokenizer parses complex PDF text streams and multi-megabyte CSV files in under 0.8 ms per statement on standard multi-core hardware.

The parser provides native, deterministic parsers for the primary banking standards worldwide:

• PDF Statements: Digital PDF 1.4–2.0 native layout coordinate mapping and multi-column transaction extraction.
• CSV & Delimited: RFC 4180 auto-detecting delimiters (comma, semicolon, tab), date ordering (DMY, MDY, YMD), and decimal notations.
• OFX / QFX: Open Financial Exchange SGML (1.x) and XML (2.x) banking and credit card formats.
• SWIFT MT940 / MT942: Tagged financial statement messages with field 61 sub-fields and balance reconciliation.
• ISO 20022 CAMT.053: XML cash management customer statement messages conforming to SEPA rulebooks.

The engine implements strict deterministic error boundaries. When an ambiguous date format or corrupted record is encountered, the parser isolates the specific record rather than failing the entire document batch. It attaches a structured diagnostic warning to the output while verifying opening and closing balance arithmetic to alert compliance operators if amounts fail reconciliation.

Yes. When compiled with the optional --features ocr flag, Bank Statement Parser leverages local, offline optical character recognition models. Scanned bitmap PDFs or image statements (TIFF, PNG) are converted to bounding-box coordinates and passed to the lexical tokenizer without transmitting any image data over the network.

Zero network egress, guaranteed. Bank Statement Parser is 100% self-contained and operates exclusively in local memory. It contains zero telemetry, zero analytics beacons, zero crash reporters, and zero background network calls. All document ingestion, tokenization, and schema validation execute strictly within your local process sandbox.

Security teams can verify our zero-egress guarantee through multiple standard controls: running the binary inside a network-isolated Linux namespace (unshare -n), deploying within a Docker container configured with --network none, or inspecting socket activity via strace / lsof. In all scenarios, zero socket binds or DNS resolutions occur.

No. Bank Statement Parser operates strictly in volatile memory. Statement byte buffers are allocated during stream processing and immediately scrubbed upon completion. No temporary files, swap caches, or intermediate scratch artifacts are written to persistent disk unless explicitly directed by the caller via the --output parameter.

Every release includes a machine-readable CycloneDX Software Bill of Materials (SBOM) and SHA256 checksums recorded in SHA256SUMS. All Git release tags and binaries are signed using SSH maintainer keys published in KEYS.asc. You can verify any asset using shasum -a 256 -c SHA256SUMS.

Add the dependency to your Cargo.toml:

[dependencies]
bankstatementparser = "0.0.2"

Then parse any statement file into strongly-typed structures:

use bankstatementparser::Parser;
use std::path::Path;
fn main() -> Result<(), Box<dyn std::error::Error>> {
 let parser = Parser::new();
 let statement = parser.parse_file(Path::new("statement.pdf"))?;
 println!("Account: {}, Balance: {}", statement.account_id, statement.closing_balance);
 Ok(())
}

Pre-compiled binary wheels (compiled with PyO3 and Maturin) are distributed on PyPI for Linux, macOS (Apple Silicon and Intel), and Windows. No Rust compiler is required on your servers. Install via pip:

pip install bankstatementparser

And use it in Python:

from bankstatementparser import parse_statement
statement = parse_statement("statement.pdf")
print(f"Transactions parsed: {len(statement.transactions)}")

Yes. Minimal, non-root container images are published on GitHub Container Registry. Mount your local statement directory to run extraction in an isolated container:

docker run --rm -v $(pwd):/data ghcr.io/sebastienrousseau/bankstatementparser:latest --input /data/statement.pdf --format json

The CLI and SDK include a Rayon-based work-stealing parallel engine. Processing thousands of statement files scales linearly across available CPU threads without lock contention. Passing --threads 8 allows 10,000 statements to be ingested, normalized, and validated in under 8.2 seconds.

Yes. The project is dual-licensed under the Apache License 2.0 and the MIT License. You are permitted to select either license, enabling full commercial use, private modification, and closed-source redistribution without copyleft obligations.

During extraction, every account IBAN is verified against ISO 7064 Mod-97 checksums, and bank identifiers are validated against ISO 9362 BIC structures. The engine enforces double-entry arithmetic proofs (Opening Balance + Credits - Debits == Closing Balance). If a balance mismatch is detected, a deterministic reconciliation discrepancy record is emitted.

Yes. In addition to native parsers for major global banking institutions, Bank Statement Parser supports external YAML/JSON configuration files. Treasury teams can define custom table coordinates, regular expression transaction anchors, and date/currency mappings without modifying the underlying engine.

We provide institutional support agreements including custom bank dialect model training, prioritized issue response SLAs, dedicated security audit consultations, and bespoke ERP/TMS integration adapters. Inquire via our Contact Page.