Fixed CSS entity escape sequence for .hr-blurred:after in base layout template.
Rebuilt native static site generator assets and synced release version metadata.
[0.0.1] - 2026-09-01
Added
Initial release of the Bank Statement Parser documentation portal.
Static Site Generator (SSG) native compilation pipeline.
Multi-format support specifications (PDF, CSV, OFX, QIF, MT940, CAMT.053).
WCAG 2.2 Level AAA compliant design system.
Zero-telemetry security documentation and CycloneDX SBOM provenance.
+
Release History
Changelog
Deterministic versioning history, security audits, and functional enhancements across every release.
All notable changes to Bank Statement Parser are documented in this file following strict Semantic Versioning.
[0.0.7] - 2026-10-30
Fixed
Resolved CodeQL code scanning alerts 41 and 42 (py/empty-except) in scripts/post-build.py and tightened exception handling in scripts/validate_spdx_headers.py.
[0.0.6] - 2026-10-30
Added
Generated llms-full.txt alongside llms.txt for single-request LLM and coding agent ingestion.
Expanded property-based test coverage for deterministic SOURCE_DATE_EPOCH builds and URL classification.
Changed
Trusted second maintainer SSH signing key (rousseau-mbp-m1) in KEYS.asc and .github/allowed_signers.
Upgraded CI to Node.js 24 and ssg 0.0.69, and pruned 40 unused legacy template files.
Fixed
Reformatted KEYS.asc into valid OpenSSH allowed-signers format and honoured SOURCE_DATE_EPOCH in sitemap.xml generation.
[0.0.5] - 2026-10-11
Changed
Upgraded SSG compiler pin in release automation and standardized build and audit sequencing for byte-for-byte reproducible release archives.
Fixed
Resolved CodeQL alert 39 in scripts/post-build.py by permitting whitespace and attributes in closing script tags.
[0.0.4] - 2026-10-11
Added
Injected Schema.org BreadcrumbList structured data across all subpages.
Changed
Standardized sitemap.xml and canonical permalinks to trailing directory slashes and excluded 404/ and offline/ utility routes.
[0.0.3] - 2026-10-10
Added
Expanded format specifications covering all 8 banking formats: CAMT (052/053/054), PAIN.001, MT940, MT942, OFX/QFX, BAI2, CSV, and PDF.
Fixed CSS entity escape sequence for .hr-blurred:after in base layout template.
Rebuilt native static site generator assets and synced release version metadata.
[0.0.1] - 2026-09-01
Added
Initial release of the Bank Statement Parser documentation portal.
Static Site Generator (SSG) native compilation pipeline.
Multi-format support specifications (PDF, CSV, OFX, QIF, MT940, CAMT.053).
WCAG 2.2 Level AAA compliant design system.
Zero-telemetry security documentation and CycloneDX SBOM provenance.
diff --git a/docs/llms-full.txt b/docs/llms-full.txt
index 974f3f9..b84a952 100644
--- a/docs/llms-full.txt
+++ b/docs/llms-full.txt
@@ -1716,6 +1716,10 @@ Financial statement data demands strict confidentiality, rigorous boundary isola
All notable changes to **Bank Statement Parser** are documented in this file following strict Semantic Versioning.
+## [0.0.7] - 2026-10-30
+### Fixed
+- Resolved CodeQL code scanning alerts 41 and 42 (`py/empty-except`) in `scripts/post-build.py` and tightened exception handling in `scripts/validate_spdx_headers.py`.
+
## [0.0.6] - 2026-10-30
### Added
- Generated `llms-full.txt` alongside `llms.txt` for single-request LLM and coding agent ingestion.
diff --git a/docs/releases/v0.0.7.md b/docs/releases/v0.0.7.md
new file mode 100644
index 0000000..598a820
--- /dev/null
+++ b/docs/releases/v0.0.7.md
@@ -0,0 +1,4 @@
+## Highlights ⭐️
+
+* **CodeQL Static Analysis Remediation**: Resolved CodeQL alerts 41 and 42 (`py/empty-except`, CWE-390) in `scripts/post-build.py` by replacing silent exception blocks with `Path.unlink(missing_ok=True)` and strict `manifest.json` validation.
+* **SPDX Header Validation Hardening**: Removed broad exception suppression in `scripts/validate_spdx_headers.py` and added unit test coverage for `write_sitemap` and `update_manifests` in `tests/test_frontmatter.py`.
diff --git a/docs/sbom.cdx.json b/docs/sbom.cdx.json
index ccfdc4f..87f6fb8 100644
--- a/docs/sbom.cdx.json
+++ b/docs/sbom.cdx.json
@@ -39,7 +39,7 @@
"name": "static-site",
"type": "application"
},
- "timestamp": "2026-10-30T21:41:20Z",
+ "timestamp": "2026-10-30T22:21:28Z",
"tools": [
{
"name": "ssg",
@@ -48,7 +48,7 @@
}
]
},
- "serialNumber": "urn:uuid:87b74e5b-a794-860c-9d76-5ede8bbe7c6a",
+ "serialNumber": "urn:uuid:8b052de0-7a8e-804f-af4e-f63ee19ed76a",
"specVersion": "1.5",
"version": 1
}
\ No newline at end of file
diff --git a/docs/search-index.json b/docs/search-index.json
index a237326..671a2e6 100644
--- a/docs/search-index.json
+++ b/docs/search-index.json
@@ -1 +1 @@
-{"entries":[{"title":"About Sebastien Rousseau | Bank Statement Parser Author","url":"/about/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Engineering & Leadership About Sebastien Rousseau Principal engineer building high-assurance, privacy-first financial infrastructure and cryptographic document tooling. Sebastien Rousseau Principal Financial Systems Architect · 19 Years in Production Banking Infrastructure Sebastien Rousseau has spent nearly two decades architecting, building, and securing high-volume transaction processing systems, institutional payment rails, and cryptographic protocols across global financial centres. Explore his work, publications, and advisory at sebastienrousseau.com. Engineering Pedigree & Domain Expertise With nineteen years of hands-on systems engineering across tier-1 investment banking, clearing gateways, and treasury infrastructures in London and international financial hubs, Sebastien specializes in high-throughput document tokenization, payment message harmonization, and post-quantum cryptographic security. 19 Years in Production Finance: Architecture of mission-critical systems across Corporate & Investment Banking (CIB), SWIFT payment gateways, SEPA clearing schemes, and real-time treasury ledger reconciliation. Author of Sovereign Open-Source Libraries: Creator of Bank Statement Parser, KyberLib (FIPS 203 ML-KEM module lattice-based key encapsulation), hsh, and ISO 20022 message engines with over 45.7M+ total package downloads. Standards & Protocol Conformance: Deep domain mastery of SWIFT Standards Release 2026 (MT940, MT942, field :86: sub-tags), ISO 20022 cash management (CAMT.052, CAMT.053, CAMT.054), payment initiation (PAIN.001), and North American BAI2 cash reporting. Zero-Telemetry Sovereign Architecture: Committed to building air-gapped, sovereign financial tools that execute locally with zero telemetry, preserving absolute banking confidentiality and data sovereignty. Personal Website & Keynotes: Visit sebastienrousseau.com for technical white papers, research monographs, and conference addresses on financial engineering and cryptographic assurance.","headings":["About Sebastien Rousseau","Sebastien Rousseau","Engineering Pedigree & Domain Expertise","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Accessibility Statement: WCAG 2.2 Level AAA Compliance","url":"/accessibility/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Inclusive Engineering Accessibility Statement Dedicated to achieving WCAG 2.2 Level AAA compliance across all digital documentation and interactive financial tooling. Bank Statement Parser is committed to digital accessibility, conforming strictly to WCAG 2.2 Level AAA guidelines: Contrast Ratios: Text colors achieve contrast ratios exceeding 17:1 in light mode and 18:1 in dark mode (well above the 7.0:1 AAA standard). Keyboard Navigation: Full keyboard operability with prominent focus indicators across all interactive elements. Screen Reader Support: Semantic HTML5 landmarks (nav, main, article, footer) and ARIA live regions.","headings":["Accessibility Statement","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"API Reference: Rust Crate & Python SDK Guide","url":"/api/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Developer Reference API & SDK Reference Complete programming interfaces, types, and error handling for Rust, Python, and CLI pipelines. Bank Statement Parser exposes deterministic, zero-allocation interfaces across both native Rust and PyO3-powered Python bindings. Every function executes strictly in-process with zero network telemetry, complete memory safety, and mathematical balance verification. 01 Rust Core Library Interface (lib.rs) Integrate the native Rust crate directly into your backend services for maximum CPU throughput, sub-millisecond document parsing, and zero heap duplication: rust — crate interface use bankstatementparser::{Parser, Statement, Transaction}; use std::path::Path; # Configure thread-safe parser with dialect auto-detection let parser = Parser::builder() .detect_dialects(true) .strict_balance_validation(true) .build(); # Parse byte stream directly from memory or disk let statement: Statement = parser.parse_file(Path::new(\"statement.pdf\"))?; # Access verified balance invariants and transactions println!(\"Account IBAN: {}\", statement.account_id); println!(\"Closing Balance: {} {}\", statement.closing_balance, statement.currency); for tx in statement.transactions { println!(\"{} | {:>10.2} | {}\", tx.date, tx.amount, tx.description); } Core data types provided by the native crate: Type / Symbol Signature Description Parser struct Parser Thread-safe parser engine supporting zero-copy byte slice and file ingestion. ParserBuilder struct ParserBuilder Configures parallel threads, balance invariants, and dialect heuristics. Statement struct Statement Normalized document model containing account ID, balances, currency, and transactions. Transaction struct Transaction Individual ledger item with booking date, value date, signed amount, and narrative. StatementFormat enum StatementFormat Output target variants: Json, Csv, Ofx, Qif, and Camt053. 02 Python SDK Interface (PyO3) Pre-compiled binary wheels for Linux, macOS, and Windows provide native Rust speed directly inside Python data science, pandas, and web application workflows: python — sdk quickstart from bankstatementparser import ( BankStatementParser, CamtParser, Bai2Parser, Mt940Parser, ParquetStreamWriter, reconcile_payments_and_statements, ) # 1. Parse statement into strongly-typed Transaction models parser = BankStatementParser() statement = parser.parse_file(\"statement.pdf\") # 2. Stream transactions directly to Apache Parquet with ParquetStreamWriter(\"transactions.parquet\") as writer: writer.write_batch(statement.transactions) # 3. Inspect verified balance proof print(f\"Closing Balance: {statement.closing_balance} {statement.currency}\") for tx in statement.transactions: print(f\"{tx.date} | {tx.amount:>10.2f} | {tx.description}\") Core parsers and analytical tools exported by the module: Symbol Type / Signature Purpose & Description BankStatementParser Class Primary document engine for PDF layout extraction, OCR fallback, and multi-format routing. Bai2Parser Class Dedicated state machine parser for BAI2 corporate cash management files. CamtParser Class High-speed XML parser for ISO 20022 CAMT.052, CAMT.053, and CAMT.054 statements. Pain001Parser Class Parser for ISO 20022 PAIN.001 customer credit transfer payment instructions. Mt940Parser / Mt942Parser Class SWIFT MT940 end-of-day and MT942 intraday tag-based message parsers. ParquetStreamWriter ContextManager Streams batches of transactions directly to Apache Parquet with Snappy/Zstd compression. reconcile_payments_and_statements Function Two-way automated reconciliation matching payment orders against statement postings. inspect_pdf_forensics Function Audits PDF statements for font discrepancies, metadata modifications, and tampering findings. analyze_statement_transactions Function Computes cash flow summaries, average daily balances, NSF fees, and recurring cadences. 03 Deterministic Error Handling & Diagnostics All processing pipelines isolate corrupt documents, unsupported regional dialects, and balance arithmetic discrepancies into typed error exceptions without panics or unhandled crashes: python — error handling from bankstatementparser import parse_statement from bankstatementparser.exceptions import ( BalanceMismatchError, UnsupportedDialectError, CorruptedDocumentError, ) try: statement = parse_statement(\"statement.pdf\") except BalanceMismatchError as exc: # Arithmetic discrepancy: opening + sum(credits) - sum(debits) != closing print(f\"Audit failed: expected delta {exc.expected_delta}, found {exc.actual_delta}\") except UnsupportedDialectError as exc: # Document signature unrecognized print(f\"Unsupported bank layout: {exc.detected_signature}\") except CorruptedDocumentError as exc: print(f\"Malformed file stream: {exc.details}\") 04 Zero-Telemetry Execution Guarantees Bank Statement Parser makes zero outbound network calls, transmits no analytical telemetry, and requires no external SaaS API keys.","headings":["API & SDK Reference","Rust Core Library Interface (lib.rs)","Python SDK Interface (PyO3)","Deterministic Error Handling & Diagnostics","Zero-Telemetry Execution Guarantees","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Architecture Blueprint: Deterministic Financial Parsing","url":"/architecture/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Engine Internals Architecture & Pipeline Specifications High-throughput tokenization, deterministic stream parsing, and ISO 20022 message synthesis with zero runtime allocations. Bank Statement Parser is architected around a deterministic, four-stage extraction and validation pipeline. Every stage executes in-process with zero outbound telemetry, zero heap allocation in the critical path, and strict mathematical balance verification before emitting ISO 20022 messages. Four-Stage Processing Pipeline 01 Stream Ingest Zero-copy memory mapping (mmap) of input statement bytes with instant magic-byte format detection (PDF, CSV, OFX, MT940, CAMT.053). < 0.2 ms Ingest Latency 02 Layout Tokenizer Spatial coordinate mapping and multi-column tabular boundary reconstruction, preserving text flow across complex multi-page financial tables. Zero Heap Allocations 03 Field Normalizer Canonical standardization of 24 global date dialects, ISO 4217 currencies, and mod-97 IBAN checksum verification. ISO 20022 BTC Mapping 04 Schema Validator Mathematical invariant verification (Opening + ΣCredits - ΣDebits = Closing) before emitting validated JSON or ISO 20022 XML. 100% Invariant Check Deterministic Pipeline Execution Trace The trace below demonstrates the sub-millisecond execution lifecycle of the four-stage engine processing a multi-page PDF statement into validated ISO 20022 CAMT.053 XML: pipeline-trace — bankstatementparser v0.0.2 $bankstatementparser --input statement.pdf --trace --format camt053 [0.00ms] [ingest] Zero-copy mmap statement.pdf (142,896 bytes) • Magic: %PDF-1.7 [0.18ms] [tokenizer] Spatial scan complete: 4 tables detected, 128 transaction rows clustered [0.45ms] [normalizer] Currency: GBP (ISO 4217) • Account: GB29BARC20000012345678 (mod-97 OK) [0.72ms] [validator] Opening: 14,250.00 | Credits: +8,300.50 | Debits: -3,120.25 | Closing: 19,430.25 [0.89ms] [validator] Invariant Check: 14,250.00 + 5,180.25 == 19,430.25 [PASS: Delta = 0.0000] [1.12ms] [synthesis] Emitted ISO 20022 camt.053.001.08 XML (42,810 bytes, schema valid) Status: 200 OK • Latency: 1.12ms • Memory: 1.4 MB • Telemetry: Zero Outbound Stage 1: Zero-Copy Stream Ingestion The ingestion subsystem interfaces directly with the host filesystem via memory-mapped files (mmap), bypassing kernel-to-userspace buffer duplication. Byte slices are analyzed using non-backtracking magic-byte sniffers: PDF Documents: Validates file header prefix %PDF- and reads the cross-reference table (xref) directly from the trailer offset. OFX Streams: Sniffs OFXHEADER SGML tags or XML prologue Result<(), Box> { let parser = Parser::new(); let statement = parser.parse_file(Path::new(\"statement.pdf\"))?; println!(\"Account: {}, Balance: {}\", statement.account_id,","headings":["Frequently Asked Questions","No matching questions found","Have a question not listed here?","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Supported Statement Formats: PDF, CSV, OFX, MT940, CAMT, BAI2","url":"/formats/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Specifications Matrix Supported Statement Formats & Specifications Deterministic multi-standard document ingestion with automated schema normalization across 8 financial formats, Parquet streaming, and ledger exports. Bank Statement Parser provides deterministic, zero-telemetry ingestion and mathematical balance verification across eight primary banking standards worldwide. Every format is normalized into strongly-typed Transaction and Statement models ready for ERP integration, corporate treasury, automated reconciliation, and OLAP analytics. Format Standard / Specification Extraction Method Validation Engine PDF Statements Adobe PDF 1.4–2.0 (Vector & Scanned) Spatial coordinate tokenizer & local OCR/vision fallback Mathematical balance verification & IBAN Mod-97 checksum CSV & Delimited RFC 4180 with Dialect Auto-Detect Statistical delimiter, decimal, and date header inference Column type inference & date format normalization BAI2 Cash Management Bank Administration Institute (BAI2) Deterministic record state machine (Records 01–99) Account status balance codes & record 88 continuation validation SWIFT MT940 SWIFT Standards Release 2026 (End-of-Day) Tag-based state machine parser (:20:, :25:, :60F:, :61:, :62F:) Opening/closing balance arithmetic (Fields 60F/62F) SWIFT MT942 SWIFT Standards Release 2026 (Interim) Intraday credit/debit transaction stream parser Field 34F floor limit & summary amount reconciliation ISO 20022 CAMT camt.052, camt.053, and camt.054 (v2–v12) Zero-copy XML streaming parser W3C XML Schema (XSD) & opening/closing balance proofs ISO 20022 PAIN.001 pain.001.001.03–11 (Customer Credit Transfer) Deterministic XML payment initiation parser Payment control sum & transaction count verification OFX & Quicken QFX Open Financial Exchange (1.02–2.2 SGML & XML) Robust tree parser with SGML unclosed-tag repair Standard banking DTD & transaction UID deduplication 1. ISO 20022 Messaging Standard (CAMT & PAIN.001) ISO 20022 is the global standard for electronic data interchange between financial institutions. Bank Statement Parser supports canonical cash management messages (CAMT) and payment initiation instructions (PAIN.001) across all published versions (v2 through v12): CAMT.053 (Bank-to-Customer Statement): Detailed end-of-day electronic account statement reporting opening balance, booked entries, batches, and closing available balance. CAMT.052 (Bank-to-Customer Account Report): Intraday or interim statement providing real-time cash position updates. CAMT.054 (Bank-to-Customer Debit/Credit Notification): Granular transaction-level debit or credit notifications used for instant settlement verification. PAIN.001 (Customer Credit Transfer Initiation): Payment instructions parsed for two-way automated reconciliation against incoming CAMT or MT940 statement postings. 2. SWIFT Telecommunication Formats (MT940 & MT942) The parser provides native tag-based state machines for legacy SWIFT MT formats without reliance on regular expressions: SWIFT MT940: The electronic bank statement message containing field :20: (Transaction Reference), :25: (Account Identification), :28C: (Statement/Sequence Number), :60F: (Opening Balance), :61: (Statement Line), :86: (Information to Account Owner), and :62F: (Closing Balance). SWIFT MT942: Interim transaction report tracking intraday movements with field :34F: minimum amount specification. Structured Field :86: Sub-Tag Parser: Automated extraction of German SEPA, EPC, and international structured tags including /EREF/ (End-to-End Reference), /PREF/ (Payment Reference), /REMI/ (Remittance Info), /IBAN/, and /BIC/. 3. BAI2 Corporate Cash Management BAI2 is the North American standard created by the Bank Administration Institute for corporate account reporting. Bank Statement Parser deterministically parses the hierarchical record sequence: Record 01: File Header (sender, receiver, creation date/time, file ID). Record 02: Group Header (ultimate receiver, originator, group status). Record 03: Account Identifier (account number, currency, type codes, status amounts). Record 16: Transaction Detail (type code, amount, funds availability, bank reference). Record 88: Continuation Record (extended remittance and transaction descriptions). Records 49, 98, 99: Account, Group, and File Trailer checksums ensuring zero record omission. 4. Open Financial Exchange (OFX & QFX) Open Financial Exchange (OFX) and Quicken Financial Exchange (QFX) formats are widely used by retail and commercial banks across North America and Europe: OFX 1.02–1.6: SGML-based format with unclosed tags and legacy header key-value blocks. The parser repairs malformed SGML tag hierarchies without memory buffering overhead. OFX 2.x: Clean W3C XML documents containing BANKMSGSRSV1, STMTTRNRS, and STMTRS aggregates. Transaction Deduplication: Unique FITID (Financial Institution Transaction ID) hashing prevents duplicate booking entries","headings":["Supported Statement Formats & Specifications","1. ISO 20022 Messaging Standard (CAMT & PAIN.001)","2. SWIFT Telecommunication Formats (MT940 & MT942)","3. BAI2 Corporate Cash Management","4. Open Financial Exchange (OFX & QFX)","5. Delimited CSV Statements","6. Digital and Scanned PDF Statements","7. Analytical & Accounting Export Targets","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Getting Started: Install CLI & Native Python/Rust SDK","url":"/getting-started/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Installation & Guide Getting Started with Bank Statement Parser Installation instructions for Rust, Python, Docker, and CLI alongside step-by-step extraction quickstarts. Bank Statement Parser is an open-source, high-throughput financial document engine engineered in Rust with native Python bindings. Follow this guide to install the binary, process multi-format statement documents, or embed the SDK directly into your application stack. Rust (Cargo) Crate v0.0.28 Native library integration and standalone CLI compiled directly from source for maximum CPU throughput. cargo install bankstatementparser Python (Pip) PyPI v0.0.28 Pre-compiled PyO3 binary wheels for Linux, macOS (Apple Silicon and Intel), and Windows with optional Parquet extras. pip install bankstatementparser # Optional: Apache Parquet and Polars streaming support pip install \"bankstatementparser[parquet]\" pip install \"bankstatementparser[polars]\" Docker Engine OCI Container Minimal, non-root container image published on GitHub Container Registry for air-gapped CI/CD execution. docker pull ghcr.io/sebastienrousseau/bankstatementparser:latest Homebrew Tap macOS & Linux Pre-built standalone CLI binary distributed via official Homebrew tap for immediate terminal workstation access. brew install sebastienrousseau/tap/bankstatementparser 01 Command Line Interface (CLI) Extraction The standalone binary provides fast parsing for individual bank statement files across digital PDF, CSV, OFX, and QIF formats, emitting standard JSON, CSV, or ISO 20022 CAMT.053 XML: bash — cli quickstart # Extract statement PDF to standard JSON $bankstatementparser --input statement.pdf --output statement.json # Convert OFX banking file to CSV $bankstatementparser --input statement.ofx --output statement.csv --format csv # Transform PDF statement into ISO 20022 CAMT.053 XML $bankstatementparser --input statement.pdf --output statement.xml --format camt053 For high-volume transaction processing, enable multi-threaded batch ingestion to parse entire directories in parallel: bash — batch processing # Process all statements in a directory using 8 parallel worker threads $bankstatementparser --batch-dir ./statements/ --output-dir ./extracted_json/ --threads 8 02 Rust Library Integration Add the dependency to your Cargo.toml: Cargo.toml [dependencies] bankstatementparser = \"0.0.28\" Parse any statement into strongly-typed transaction structs with compile-time memory safety: main.rs use bankstatementparser::{Parser, StatementFormat}; use std::path::Path; fn main() -> Result<(), Box> { let parser = Parser::new(); let statement = parser.parse_file(Path::new(\"statement.pdf\"))?; println!(\"Account: {}\", statement.account_id); println!(\"Balance: {} {}\", statement.closing_balance, statement.currency); for tx in statement.transactions { println!(\"{} | {} | {}\", tx.date, tx.amount, tx.description); } Ok(()) } 03 Python SDK Integration Extract and validate transaction records within your Python data science and finance workflows with zero native compilation: python — main.py from bankstatementparser import ( BankStatementParser, CamtParser, Bai2Parser, ParquetStreamWriter, ) # 1. Parse statement into strongly-typed Transaction models parser = BankStatementParser() statement = parser.parse_file(\"statement.pdf\") # 2. Stream transactions directly to Apache Parquet with ParquetStreamWriter(\"transactions.parquet\") as writer: writer.write_batch(statement.transactions) print(f\"Extracted {len(statement.transactions)} transactions into Parquet.\") 04 Zero-Telemetry Execution Guarantees Every extraction pipeline executes exclusively within local process memory. Bank Statement Parser makes zero outbound network calls, transmits no analytical telemetry, and requires no external SaaS API keys: Air-gapped execution architecture: banking statements are tokenized and validated entirely within local memory with zero external telemetry.","headings":["Getting Started with Bank Statement Parser","Rust (Cargo)","Python (Pip)","Docker Engine","Homebrew Tap","Command Line Interface (CLI) Extraction","Rust Library Integration","Python SDK Integration","Zero-Telemetry Execution Guarantees","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Bank Statement Parser: High-Throughput Financial Engine","url":"/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Financial Document Engineering · Open SourceParse any bank statement in milliseconds.Zero cloud dependencies. Zero telemetry.An open-source, high-throughput financial document parsing engine engineered in Rust with native Python bindings. Converts CAMT, PAIN.001, MT940, MT942, OFX/QFX, BAI2, CSV, and PDF bank statements into validated JSON, Apache Parquet, and ISO 20022 transaction streams entirely on your own infrastructure.Install CLI & SDK Explore Supported FormatsDeterministic Rust CoreZero Cloud Dependencies100% Air-Gapped Privacy10,000+ Pages/Min Deterministic multi-threaded streaming throughput with zero lock contention.< 0.8 ms Latency Zero-copy tokenization designed for real-time ledger reconciliation.100% Zero Telemetry Runs fully air-gapped on your private VPC or local host with zero network calls.8 Banking Standards Unified extraction across CAMT (052/053/054), PAIN.001, MT940, MT942, OFX/QFX, BAI2, CSV, and PDF. Corporate Treasury AutomationAutomated Reconciliation for Modern TreasuryEliminate manual statement keying, error-prone spreadsheets, and expensive cloud OCR APIs. Normalize multi-bank statements directly into your general ledger, ERP, and treasury management workflows with sub-second turnaround.View Treasury Playbook ↗Engine ArchitectureEngineered for absolute accuracy.Industrial-grade financial parsing combining memory-safe Rust execution, native Python bindings, and dual Apache/MIT licensing.01Multi-Format Dialect EngineDeterministic state machines parse digital and scanned PDFs, irregular CSV layouts, SGML OFX/QFX, BAI2 cash management, and SWIFT MT940/MT942 messages without brittle regex or external cloud OCR.02Arithmetic Balance VerificationStrict mathematical balance validation ensures opening balance plus net credits and debits precisely equals closing balance to the penny before record emission.03ISO 20022 HarmonizationNormalize disparate bank statements directly into canonical ISO 20022 CAMT.053 XML envelopes, Apache Parquet streams, or strongly-typed JSON schemas ready for ERP, GL, and accounting ingestion.The Processing PipelineFrom raw bank document to validated ledger transactions.1IngestStream PDF bytes, CSV feeds, BAI2 files, or SWIFT MT940/MT942 messages into memory-safe zero-copy buffers.Sub-millisecond stream loading2TokenizeDeterministic lexical analysis identifies account metadata, booking dates, line items, and structured :86: sub-tags.Deterministic layout analysis3VerifyArithmetic balance reconciliation confirms credit/debit integrity, checks PDF forensics, and validates IBAN checksums.Mod-97 and balance proofs4EmitOutput strongly-typed JSON, streaming Apache Parquet, Plain-Text Ledgers (hledger, beancount), or ISO 20022 messages.Ready for ERP, Lakehouse & GL High-Performance PipelineDeterministic Execution at Enterprise ScaleEngineered for high-frequency financial platforms requiring bounded latency, zero-allocation loops, and strict ISO 20022 data models.View Architecture Blueprint ↗Developer QuickstartInstall via Cargo, Pip, or Homebrew in SecondsDeploy as a standalone CLI tool, embed as a high-assurance Rust crate in your microservices, or integrate into Python data pipelines with zero external runtime overhead.Full Documentation → API Reference bash — bankstatementparser# 1. Install standalone CLI or Python library$cargo install bankstatementparser$pip install bankstatementparser# 2. Parse statement with arithmetic balance verification$bankstatementparser --input statement.pdf --format json# 3. Deterministic output verification (< 0.8 ms){ \"status\": \"VALIDATED\", \"duration_ms\": 0.72, \"balance_proof\": \"EXACT_MATCH\" }Zero-Telemetry PrivacyYour financial data never leaves your infrastructure.Bank Statement Parser is 100% self-contained and operates entirely on your local machine, private VPC, or air-gapped on-premise servers. Zero analytics, zero telemetry, and zero outbound network calls—guaranteeing complete GDPR, GLBA, and banking confidentiality compliance.Read Security & Privacy Architecture ↓Clear AnswersFrequently Asked QuestionsDoes Bank Statement Parser send data to the cloud or external servers?No. Bank Statement Parser is 100% self-contained and operates entirely on your local machine or private cloud server. It contains zero analytics, zero telemetry, and zero outbound network calls, ensuring complete compliance with GDPR, HIPAA, GLBA, and banking confidentiality regulations.Which bank statement file formats are supported?Bank Statement Parser natively supports eight primary banking formats: ISO 20022 CAMT (camt.052, camt.053, camt.054), ISO 20022 PAIN.001 (Credit Transfer), SWIFT MT940 and MT942 messages, BAI2 (Bank Administration Institute), Open Financial Exchange (OFX 1.x/2.x and QFX), CSV files (with automatic delimiter and date detection), and digital/scanned PDF statements.How does the parser handle scanned or image-based statements?For digital and vector PDFs, the","headings":["Parse any bank statement in milliseconds.Zero cloud dependencies. Zero telemetry.","Automated Reconciliation for Modern Treasury","Engineered for absolute accuracy.","From raw bank document to validated ledger transactions.","Deterministic Execution at Enterprise Scale","Install via Cargo, Pip, or Homebrew in Seconds","Your financial data never leaves your infrastructure.","Frequently Asked Questions","Financial data is mission-critical.Your parsing pipeline should be instant.","Documentation & API","Solutions & Workflows","Trust & Legal","Multi-Format Dialect Engine","Arithmetic Balance Verification","ISO 20022 Harmonization","Ingest","Tokenize","Verify","Emit"]},{"title":"Made with Static Site Generator (SSG) | Web Platform","url":"/made-with-ssg/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Static Architecture Made with Static Site Generator (SSG) Why Bank Statement Parser documentation is statically generated for uncompromising security, WCAG AAA accessibility, and instant loading. This site is natively compiled using the high-performance Static Site Generator (SSG) written in Rust. Source of Truth: Content authored in Markdown (_posts/*.md) with Tera templates (_layouts/*.html). Compilation Speed: Full site generation in under 0.5 seconds with zero runtime JavaScript framework dependencies. Security: Strict Subresource Integrity (SRI) and Content Security Policy (CSP) headers.","headings":["Made with Static Site Generator (SSG)","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Zero-Telemetry Privacy Guarantee & Data Protection","url":"/privacy/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Trust & Governance Privacy Policy Our foundational commitment: zero tracking, zero analytics, zero external network requests, and complete local processing. Last updated: 1 September 2026 Bank Statement Parser is built on a strict zero-telemetry, zero-cookie architecture: No External Data Transmission: The Bank Statement Parser software operates entirely on the user's infrastructure. No document content, transaction records, or telemetry data are ever collected or transmitted. No Tracking Cookies: This documentation website does not use tracking cookies, analytics pixels, or third-party behavioral scripts. Data Protection Compliance: Fully compliant with GDPR, UK Data Protection Act 2018, and California Consumer Privacy Act (CCPA).","headings":["Privacy Policy","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Security Architecture: Air-Gapped & Memory-Safe Parsing","url":"/security/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Zero-Telemetry Model Security Architecture & Trust Guarantees Strict zero-telemetry guarantees, memory safety verification, and Sigstore-signed releases for compliance-critical pipelines. Financial statement data demands strict confidentiality, rigorous boundary isolation, and deterministic mathematical verification. Bank Statement Parser is architected from the foundation up to operate securely within air-gapped sovereign environments. 0 KB Telemetry Ingest 100% Safe Rust Core Cosign Sigstore Verified 01 Air-Gapped Sovereign Execution Model Bank Statement Parser binds no listening network ports and initiates no outbound TCP, UDP, or HTTP connections. All parsing, coordinate tokenization, and schema validation execute entirely within local process memory. Security Vector Implementation Standard Verification Audit Network Socket Access Zero outbound or listening sockets initialized Enforced via eBPF / seccomp system call filter Heap Memory Sanitization Zero sensitive statement data written to temporary disks Cleared immediately upon statement struct deallocation Third-Party SaaS Telemetry Zero third-party analytics or error tracking SDKs Static binary symbol inspection in CI Subresource Integrity SHA-384 cryptographic digests on all assets Enforced by W3C Content Security Policy (CSP) 02 Software Supply Chain & SBOM Provenance Every release artifact is cryptographically signed and independently auditable using SLSA Level 3 build provenance. A CycloneDX SBOM is published with every release to track transitive dependencies and vulnerability CVE states: bash — verify release provenance # Verify binary release signature using Sigstore Cosign $cosign verify-blob --certificate certificate.pem --signature bankstatementparser.sig bankstatementparser # Audit CycloneDX SBOM for dependency vulnerabilities $cyclonedx validate --input-file sbom.cdx.json 03 Cryptographic Isolation & Architecture Callout The system is purpose-built for financial institutions, hedge funds, sovereign banks, and regulated audit firms requiring verifiable isolation from public cloud APIs. Cryptographic integrity: every binary is Sigstore-signed, air-gapped, and accompanied by a CycloneDX SBOM.","headings":["Security Architecture & Trust Guarantees","Air-Gapped Sovereign Execution Model","Software Supply Chain & SBOM Provenance","Cryptographic Isolation & Architecture Callout","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Terms of Use & Dual Open-Source License Specifications","url":"/terms/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Legal Framework Terms of Use Clear, transparent terms governing the use of Bank Statement Parser open source software and enterprise documentation. Bank Statement Parser is distributed under the dual Apache License 2.0 and MIT License. You may use, modify, distribute, and integrate the software into commercial and open-source applications subject to the terms of either license.","headings":["Terms of Use","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Fintech Use Cases: Treasury & Reconciliation","url":"/use-cases/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Production Blueprints Enterprise Use Cases & Deployment Patterns High-throughput statement extraction powering corporate treasury automation, automated reconciliation, SME credit underwriting, and forensic audit screening. High-throughput statement extraction powers critical automated financial backends with zero cloud dependencies, air-gapped security, and deterministic precision. 99.8% Reconciliation STP Rate < 1 ms Underwriting Ingestion 100% Air-Gapped & Private 01 Corporate Treasury Automation Enterprise treasuries manage accounts across dozens of global banking partners (Citi, JPMorgan Chase, BNP Paribas, HSBC, Deutsche Bank). Each bank issues disparate statement formats with varying column orders, multi-currency balance headers, and non-standard narrative formatting. Bank Statement Parser unifies incoming statement feeds into canonical ISO 20022 camt.053 XML and JSON structures for real-time liquidity management. Operational Dimension Legacy Manual / OCR Workflow Bank Statement Parser Engine Processing Latency 30–45 minutes per multi-page statement < 5 milliseconds per statement Balance Verification Manual human calculation or unverified Mathematical proof (Opening + Transactions = Closing) Liquidity Visibility T+1 or T+2 retrospective reporting Continuous real-time intraday cash positioning Transcription Error Rate 2.1% – 3.5% human keying errors 0.00% deterministic spatial coordinate extraction bash — treasury batch ingestion pipeline # Batch-process multi-bank intraday statements with strict balance invariant check $bankstatementparser --batch-dir ./treasury/incoming/ --verify-balance --output-dir ./tms/ready/ Ingested: 128 PDF statements (Citi, HSBC, BNP, JPM) Transactions: 14,892 records parsed, normalized, and balanced Balance Proof: 128/128 passed [Opening + sum(credits) - sum(debits) == Closing] 02 Automated Bank Reconciliation Finance operations teams reconcile millions of bank transaction lines against general ledger (GL) entries every fiscal period. Irregular descriptions, truncated transaction codes, and disparate currency notations typically create enormous manual exception queues. Bank Statement Parser normalizes reference numbers, counterparty names, and structured remittance data to drive straight-through processing (STP) rates above 99.8%. Reconciliation Metric Generic PDF Scraper Bank Statement Parser Engine Payee Normalization Raw truncated strings with bank noise Clean entity names with stripped routing prefixes Reference Code Extraction Brittle regex frequently drops end tokens Coordinate-aware token bounding for full invoice codes STP Match Rate 60% – 75% (heavy manual review) 99.8% automated straight-through processing Multi-Currency Handling String-level assumptions ISO 4217 validation with decimal-exact precision python — high-throughput reconciliation stream from bankstatementparser import parse_statement # Ingest PDF statement directly into reconciliation pipeline statement = parse_statement(\"statements/october_operations.pdf\") for tx in statement.transactions: match = ledger.reconcile(reference=tx.reference, amount=tx.amount, date=tx.booking_date) assert statement.balanced, \"Statement balances must be mathematically proven\" 03 Fintech SME Credit Underwriting Modern commercial lenders and merchant cash advance platforms require rapid, accurate extraction of 12 to 24 months of applicant bank statements. The engine calculates net operating cash flows, recurring revenue, non-sufficient funds (NSF) events, and average daily balances in milliseconds—enabling instant credit decisions while applicants are still on the lender's application portal. Underwriting Parameter Human Document Review Bank Statement Parser Turnaround Time 24 to 72 hours per dossier < 500 milliseconds for 24 months Dossier Volume Sampled 3 months due to cost 12–24 months fully ingested and analyzed Document Tampering Detection Subjective visual check Mathematical invariant verification detects doctored numbers Cost per Application $25 – $50 in human labor $0.00 (Self-hosted native engine) rust — applicant dossier analysis use bankstatementparser::{Engine, Config}; let engine = Engine::new(Config::strict_validation()); let report = engine.parse_applicant_dossier(&[\"m1.pdf\", \"m2.pdf\", \"m3.pdf\"])?; println!(\"Net Cashflow: {}, Overdrafts: {}\", report.net_cashflow(), report.nsf_count()); 04 Forensic Audit & Sanctions Screening Forensic accountants and AML investigators examine thousands of historical bank statements during restructuring, corporate acquisitions, bankruptcy inquiries, and regulatory investigations. The parser's air-gapped, zero-network architecture guarantees that sensitive banking data never leaves local customer infrastructure or secure enclaves. Investigation Capability Cloud OCR Services Bank Statement Parser Data Sovereignty & Privacy Customer data sent to external cloud APIs 100% on-premises / air-gapped execution","headings":["Enterprise Use Cases & Deployment Patterns","Corporate Treasury Automation","Automated Bank Reconciliation","Fintech SME Credit Underwriting","Forensic Audit & Sanctions Screening","Enterprise Deployment Architecture","Documentation & API","Solutions & Workflows","Trust & Legal"]}]}
\ No newline at end of file
+{"entries":[{"title":"About Sebastien Rousseau | Bank Statement Parser Author","url":"/about/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Engineering & Leadership About Sebastien Rousseau Principal engineer building high-assurance, privacy-first financial infrastructure and cryptographic document tooling. Sebastien Rousseau Principal Financial Systems Architect · 19 Years in Production Banking Infrastructure Sebastien Rousseau has spent nearly two decades architecting, building, and securing high-volume transaction processing systems, institutional payment rails, and cryptographic protocols across global financial centres. Explore his work, publications, and advisory at sebastienrousseau.com. Engineering Pedigree & Domain Expertise With nineteen years of hands-on systems engineering across tier-1 investment banking, clearing gateways, and treasury infrastructures in London and international financial hubs, Sebastien specializes in high-throughput document tokenization, payment message harmonization, and post-quantum cryptographic security. 19 Years in Production Finance: Architecture of mission-critical systems across Corporate & Investment Banking (CIB), SWIFT payment gateways, SEPA clearing schemes, and real-time treasury ledger reconciliation. Author of Sovereign Open-Source Libraries: Creator of Bank Statement Parser, KyberLib (FIPS 203 ML-KEM module lattice-based key encapsulation), hsh, and ISO 20022 message engines with over 45.7M+ total package downloads. Standards & Protocol Conformance: Deep domain mastery of SWIFT Standards Release 2026 (MT940, MT942, field :86: sub-tags), ISO 20022 cash management (CAMT.052, CAMT.053, CAMT.054), payment initiation (PAIN.001), and North American BAI2 cash reporting. Zero-Telemetry Sovereign Architecture: Committed to building air-gapped, sovereign financial tools that execute locally with zero telemetry, preserving absolute banking confidentiality and data sovereignty. Personal Website & Keynotes: Visit sebastienrousseau.com for technical white papers, research monographs, and conference addresses on financial engineering and cryptographic assurance.","headings":["About Sebastien Rousseau","Sebastien Rousseau","Engineering Pedigree & Domain Expertise","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Accessibility Statement: WCAG 2.2 Level AAA Compliance","url":"/accessibility/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Inclusive Engineering Accessibility Statement Dedicated to achieving WCAG 2.2 Level AAA compliance across all digital documentation and interactive financial tooling. Bank Statement Parser is committed to digital accessibility, conforming strictly to WCAG 2.2 Level AAA guidelines: Contrast Ratios: Text colors achieve contrast ratios exceeding 17:1 in light mode and 18:1 in dark mode (well above the 7.0:1 AAA standard). Keyboard Navigation: Full keyboard operability with prominent focus indicators across all interactive elements. Screen Reader Support: Semantic HTML5 landmarks (nav, main, article, footer) and ARIA live regions.","headings":["Accessibility Statement","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"API Reference: Rust Crate & Python SDK Guide","url":"/api/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Developer Reference API & SDK Reference Complete programming interfaces, types, and error handling for Rust, Python, and CLI pipelines. Bank Statement Parser exposes deterministic, zero-allocation interfaces across both native Rust and PyO3-powered Python bindings. Every function executes strictly in-process with zero network telemetry, complete memory safety, and mathematical balance verification. 01 Rust Core Library Interface (lib.rs) Integrate the native Rust crate directly into your backend services for maximum CPU throughput, sub-millisecond document parsing, and zero heap duplication: rust — crate interface use bankstatementparser::{Parser, Statement, Transaction}; use std::path::Path; # Configure thread-safe parser with dialect auto-detection let parser = Parser::builder() .detect_dialects(true) .strict_balance_validation(true) .build(); # Parse byte stream directly from memory or disk let statement: Statement = parser.parse_file(Path::new(\"statement.pdf\"))?; # Access verified balance invariants and transactions println!(\"Account IBAN: {}\", statement.account_id); println!(\"Closing Balance: {} {}\", statement.closing_balance, statement.currency); for tx in statement.transactions { println!(\"{} | {:>10.2} | {}\", tx.date, tx.amount, tx.description); } Core data types provided by the native crate: Type / Symbol Signature Description Parser struct Parser Thread-safe parser engine supporting zero-copy byte slice and file ingestion. ParserBuilder struct ParserBuilder Configures parallel threads, balance invariants, and dialect heuristics. Statement struct Statement Normalized document model containing account ID, balances, currency, and transactions. Transaction struct Transaction Individual ledger item with booking date, value date, signed amount, and narrative. StatementFormat enum StatementFormat Output target variants: Json, Csv, Ofx, Qif, and Camt053. 02 Python SDK Interface (PyO3) Pre-compiled binary wheels for Linux, macOS, and Windows provide native Rust speed directly inside Python data science, pandas, and web application workflows: python — sdk quickstart from bankstatementparser import ( BankStatementParser, CamtParser, Bai2Parser, Mt940Parser, ParquetStreamWriter, reconcile_payments_and_statements, ) # 1. Parse statement into strongly-typed Transaction models parser = BankStatementParser() statement = parser.parse_file(\"statement.pdf\") # 2. Stream transactions directly to Apache Parquet with ParquetStreamWriter(\"transactions.parquet\") as writer: writer.write_batch(statement.transactions) # 3. Inspect verified balance proof print(f\"Closing Balance: {statement.closing_balance} {statement.currency}\") for tx in statement.transactions: print(f\"{tx.date} | {tx.amount:>10.2f} | {tx.description}\") Core parsers and analytical tools exported by the module: Symbol Type / Signature Purpose & Description BankStatementParser Class Primary document engine for PDF layout extraction, OCR fallback, and multi-format routing. Bai2Parser Class Dedicated state machine parser for BAI2 corporate cash management files. CamtParser Class High-speed XML parser for ISO 20022 CAMT.052, CAMT.053, and CAMT.054 statements. Pain001Parser Class Parser for ISO 20022 PAIN.001 customer credit transfer payment instructions. Mt940Parser / Mt942Parser Class SWIFT MT940 end-of-day and MT942 intraday tag-based message parsers. ParquetStreamWriter ContextManager Streams batches of transactions directly to Apache Parquet with Snappy/Zstd compression. reconcile_payments_and_statements Function Two-way automated reconciliation matching payment orders against statement postings. inspect_pdf_forensics Function Audits PDF statements for font discrepancies, metadata modifications, and tampering findings. analyze_statement_transactions Function Computes cash flow summaries, average daily balances, NSF fees, and recurring cadences. 03 Deterministic Error Handling & Diagnostics All processing pipelines isolate corrupt documents, unsupported regional dialects, and balance arithmetic discrepancies into typed error exceptions without panics or unhandled crashes: python — error handling from bankstatementparser import parse_statement from bankstatementparser.exceptions import ( BalanceMismatchError, UnsupportedDialectError, CorruptedDocumentError, ) try: statement = parse_statement(\"statement.pdf\") except BalanceMismatchError as exc: # Arithmetic discrepancy: opening + sum(credits) - sum(debits) != closing print(f\"Audit failed: expected delta {exc.expected_delta}, found {exc.actual_delta}\") except UnsupportedDialectError as exc: # Document signature unrecognized print(f\"Unsupported bank layout: {exc.detected_signature}\") except CorruptedDocumentError as exc: print(f\"Malformed file stream: {exc.details}\") 04 Zero-Telemetry Execution Guarantees Bank Statement Parser makes zero outbound network calls, transmits no analytical telemetry, and requires no external SaaS API keys.","headings":["API & SDK Reference","Rust Core Library Interface (lib.rs)","Python SDK Interface (PyO3)","Deterministic Error Handling & Diagnostics","Zero-Telemetry Execution Guarantees","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Architecture Blueprint: Deterministic Financial Parsing","url":"/architecture/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Engine Internals Architecture & Pipeline Specifications High-throughput tokenization, deterministic stream parsing, and ISO 20022 message synthesis with zero runtime allocations. Bank Statement Parser is architected around a deterministic, four-stage extraction and validation pipeline. Every stage executes in-process with zero outbound telemetry, zero heap allocation in the critical path, and strict mathematical balance verification before emitting ISO 20022 messages. Four-Stage Processing Pipeline 01 Stream Ingest Zero-copy memory mapping (mmap) of input statement bytes with instant magic-byte format detection (PDF, CSV, OFX, MT940, CAMT.053). < 0.2 ms Ingest Latency 02 Layout Tokenizer Spatial coordinate mapping and multi-column tabular boundary reconstruction, preserving text flow across complex multi-page financial tables. Zero Heap Allocations 03 Field Normalizer Canonical standardization of 24 global date dialects, ISO 4217 currencies, and mod-97 IBAN checksum verification. ISO 20022 BTC Mapping 04 Schema Validator Mathematical invariant verification (Opening + ΣCredits - ΣDebits = Closing) before emitting validated JSON or ISO 20022 XML. 100% Invariant Check Deterministic Pipeline Execution Trace The trace below demonstrates the sub-millisecond execution lifecycle of the four-stage engine processing a multi-page PDF statement into validated ISO 20022 CAMT.053 XML: pipeline-trace — bankstatementparser v0.0.2 $bankstatementparser --input statement.pdf --trace --format camt053 [0.00ms] [ingest] Zero-copy mmap statement.pdf (142,896 bytes) • Magic: %PDF-1.7 [0.18ms] [tokenizer] Spatial scan complete: 4 tables detected, 128 transaction rows clustered [0.45ms] [normalizer] Currency: GBP (ISO 4217) • Account: GB29BARC20000012345678 (mod-97 OK) [0.72ms] [validator] Opening: 14,250.00 | Credits: +8,300.50 | Debits: -3,120.25 | Closing: 19,430.25 [0.89ms] [validator] Invariant Check: 14,250.00 + 5,180.25 == 19,430.25 [PASS: Delta = 0.0000] [1.12ms] [synthesis] Emitted ISO 20022 camt.053.001.08 XML (42,810 bytes, schema valid) Status: 200 OK • Latency: 1.12ms • Memory: 1.4 MB • Telemetry: Zero Outbound Stage 1: Zero-Copy Stream Ingestion The ingestion subsystem interfaces directly with the host filesystem via memory-mapped files (mmap), bypassing kernel-to-userspace buffer duplication. Byte slices are analyzed using non-backtracking magic-byte sniffers: PDF Documents: Validates file header prefix %PDF- and reads the cross-reference table (xref) directly from the trailer offset. OFX Streams: Sniffs OFXHEADER SGML tags or XML prologue Result<(), Box> { let parser = Parser::new(); let statement = parser.parse_file(Path::new(\"statement.pdf\"))?; println!(\"Account: {}, Balance: {}\", statement.account_id,","headings":["Frequently Asked Questions","No matching questions found","Have a question not listed here?","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Supported Statement Formats: PDF, CSV, OFX, MT940, CAMT, BAI2","url":"/formats/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Specifications Matrix Supported Statement Formats & Specifications Deterministic multi-standard document ingestion with automated schema normalization across 8 financial formats, Parquet streaming, and ledger exports. Bank Statement Parser provides deterministic, zero-telemetry ingestion and mathematical balance verification across eight primary banking standards worldwide. Every format is normalized into strongly-typed Transaction and Statement models ready for ERP integration, corporate treasury, automated reconciliation, and OLAP analytics. Format Standard / Specification Extraction Method Validation Engine PDF Statements Adobe PDF 1.4–2.0 (Vector & Scanned) Spatial coordinate tokenizer & local OCR/vision fallback Mathematical balance verification & IBAN Mod-97 checksum CSV & Delimited RFC 4180 with Dialect Auto-Detect Statistical delimiter, decimal, and date header inference Column type inference & date format normalization BAI2 Cash Management Bank Administration Institute (BAI2) Deterministic record state machine (Records 01–99) Account status balance codes & record 88 continuation validation SWIFT MT940 SWIFT Standards Release 2026 (End-of-Day) Tag-based state machine parser (:20:, :25:, :60F:, :61:, :62F:) Opening/closing balance arithmetic (Fields 60F/62F) SWIFT MT942 SWIFT Standards Release 2026 (Interim) Intraday credit/debit transaction stream parser Field 34F floor limit & summary amount reconciliation ISO 20022 CAMT camt.052, camt.053, and camt.054 (v2–v12) Zero-copy XML streaming parser W3C XML Schema (XSD) & opening/closing balance proofs ISO 20022 PAIN.001 pain.001.001.03–11 (Customer Credit Transfer) Deterministic XML payment initiation parser Payment control sum & transaction count verification OFX & Quicken QFX Open Financial Exchange (1.02–2.2 SGML & XML) Robust tree parser with SGML unclosed-tag repair Standard banking DTD & transaction UID deduplication 1. ISO 20022 Messaging Standard (CAMT & PAIN.001) ISO 20022 is the global standard for electronic data interchange between financial institutions. Bank Statement Parser supports canonical cash management messages (CAMT) and payment initiation instructions (PAIN.001) across all published versions (v2 through v12): CAMT.053 (Bank-to-Customer Statement): Detailed end-of-day electronic account statement reporting opening balance, booked entries, batches, and closing available balance. CAMT.052 (Bank-to-Customer Account Report): Intraday or interim statement providing real-time cash position updates. CAMT.054 (Bank-to-Customer Debit/Credit Notification): Granular transaction-level debit or credit notifications used for instant settlement verification. PAIN.001 (Customer Credit Transfer Initiation): Payment instructions parsed for two-way automated reconciliation against incoming CAMT or MT940 statement postings. 2. SWIFT Telecommunication Formats (MT940 & MT942) The parser provides native tag-based state machines for legacy SWIFT MT formats without reliance on regular expressions: SWIFT MT940: The electronic bank statement message containing field :20: (Transaction Reference), :25: (Account Identification), :28C: (Statement/Sequence Number), :60F: (Opening Balance), :61: (Statement Line), :86: (Information to Account Owner), and :62F: (Closing Balance). SWIFT MT942: Interim transaction report tracking intraday movements with field :34F: minimum amount specification. Structured Field :86: Sub-Tag Parser: Automated extraction of German SEPA, EPC, and international structured tags including /EREF/ (End-to-End Reference), /PREF/ (Payment Reference), /REMI/ (Remittance Info), /IBAN/, and /BIC/. 3. BAI2 Corporate Cash Management BAI2 is the North American standard created by the Bank Administration Institute for corporate account reporting. Bank Statement Parser deterministically parses the hierarchical record sequence: Record 01: File Header (sender, receiver, creation date/time, file ID). Record 02: Group Header (ultimate receiver, originator, group status). Record 03: Account Identifier (account number, currency, type codes, status amounts). Record 16: Transaction Detail (type code, amount, funds availability, bank reference). Record 88: Continuation Record (extended remittance and transaction descriptions). Records 49, 98, 99: Account, Group, and File Trailer checksums ensuring zero record omission. 4. Open Financial Exchange (OFX & QFX) Open Financial Exchange (OFX) and Quicken Financial Exchange (QFX) formats are widely used by retail and commercial banks across North America and Europe: OFX 1.02–1.6: SGML-based format with unclosed tags and legacy header key-value blocks. The parser repairs malformed SGML tag hierarchies without memory buffering overhead. OFX 2.x: Clean W3C XML documents containing BANKMSGSRSV1, STMTTRNRS, and STMTRS aggregates. Transaction Deduplication: Unique FITID (Financial Institution Transaction ID) hashing prevents duplicate booking entries","headings":["Supported Statement Formats & Specifications","1. ISO 20022 Messaging Standard (CAMT & PAIN.001)","2. SWIFT Telecommunication Formats (MT940 & MT942)","3. BAI2 Corporate Cash Management","4. Open Financial Exchange (OFX & QFX)","5. Delimited CSV Statements","6. Digital and Scanned PDF Statements","7. Analytical & Accounting Export Targets","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Getting Started: Install CLI & Native Python/Rust SDK","url":"/getting-started/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Installation & Guide Getting Started with Bank Statement Parser Installation instructions for Rust, Python, Docker, and CLI alongside step-by-step extraction quickstarts. Bank Statement Parser is an open-source, high-throughput financial document engine engineered in Rust with native Python bindings. Follow this guide to install the binary, process multi-format statement documents, or embed the SDK directly into your application stack. Rust (Cargo) Crate v0.0.28 Native library integration and standalone CLI compiled directly from source for maximum CPU throughput. cargo install bankstatementparser Python (Pip) PyPI v0.0.28 Pre-compiled PyO3 binary wheels for Linux, macOS (Apple Silicon and Intel), and Windows with optional Parquet extras. pip install bankstatementparser # Optional: Apache Parquet and Polars streaming support pip install \"bankstatementparser[parquet]\" pip install \"bankstatementparser[polars]\" Docker Engine OCI Container Minimal, non-root container image published on GitHub Container Registry for air-gapped CI/CD execution. docker pull ghcr.io/sebastienrousseau/bankstatementparser:latest Homebrew Tap macOS & Linux Pre-built standalone CLI binary distributed via official Homebrew tap for immediate terminal workstation access. brew install sebastienrousseau/tap/bankstatementparser 01 Command Line Interface (CLI) Extraction The standalone binary provides fast parsing for individual bank statement files across digital PDF, CSV, OFX, and QIF formats, emitting standard JSON, CSV, or ISO 20022 CAMT.053 XML: bash — cli quickstart # Extract statement PDF to standard JSON $bankstatementparser --input statement.pdf --output statement.json # Convert OFX banking file to CSV $bankstatementparser --input statement.ofx --output statement.csv --format csv # Transform PDF statement into ISO 20022 CAMT.053 XML $bankstatementparser --input statement.pdf --output statement.xml --format camt053 For high-volume transaction processing, enable multi-threaded batch ingestion to parse entire directories in parallel: bash — batch processing # Process all statements in a directory using 8 parallel worker threads $bankstatementparser --batch-dir ./statements/ --output-dir ./extracted_json/ --threads 8 02 Rust Library Integration Add the dependency to your Cargo.toml: Cargo.toml [dependencies] bankstatementparser = \"0.0.28\" Parse any statement into strongly-typed transaction structs with compile-time memory safety: main.rs use bankstatementparser::{Parser, StatementFormat}; use std::path::Path; fn main() -> Result<(), Box> { let parser = Parser::new(); let statement = parser.parse_file(Path::new(\"statement.pdf\"))?; println!(\"Account: {}\", statement.account_id); println!(\"Balance: {} {}\", statement.closing_balance, statement.currency); for tx in statement.transactions { println!(\"{} | {} | {}\", tx.date, tx.amount, tx.description); } Ok(()) } 03 Python SDK Integration Extract and validate transaction records within your Python data science and finance workflows with zero native compilation: python — main.py from bankstatementparser import ( BankStatementParser, CamtParser, Bai2Parser, ParquetStreamWriter, ) # 1. Parse statement into strongly-typed Transaction models parser = BankStatementParser() statement = parser.parse_file(\"statement.pdf\") # 2. Stream transactions directly to Apache Parquet with ParquetStreamWriter(\"transactions.parquet\") as writer: writer.write_batch(statement.transactions) print(f\"Extracted {len(statement.transactions)} transactions into Parquet.\") 04 Zero-Telemetry Execution Guarantees Every extraction pipeline executes exclusively within local process memory. Bank Statement Parser makes zero outbound network calls, transmits no analytical telemetry, and requires no external SaaS API keys: Air-gapped execution architecture: banking statements are tokenized and validated entirely within local memory with zero external telemetry.","headings":["Getting Started with Bank Statement Parser","Rust (Cargo)","Python (Pip)","Docker Engine","Homebrew Tap","Command Line Interface (CLI) Extraction","Rust Library Integration","Python SDK Integration","Zero-Telemetry Execution Guarantees","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Bank Statement Parser: High-Throughput Financial Engine","url":"/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Financial Document Engineering · Open SourceParse any bank statement in milliseconds.Zero cloud dependencies. Zero telemetry.An open-source, high-throughput financial document parsing engine engineered in Rust with native Python bindings. Converts CAMT, PAIN.001, MT940, MT942, OFX/QFX, BAI2, CSV, and PDF bank statements into validated JSON, Apache Parquet, and ISO 20022 transaction streams entirely on your own infrastructure.Install CLI & SDK Explore Supported FormatsDeterministic Rust CoreZero Cloud Dependencies100% Air-Gapped Privacy10,000+ Pages/Min Deterministic multi-threaded streaming throughput with zero lock contention.< 0.8 ms Latency Zero-copy tokenization designed for real-time ledger reconciliation.100% Zero Telemetry Runs fully air-gapped on your private VPC or local host with zero network calls.8 Banking Standards Unified extraction across CAMT (052/053/054), PAIN.001, MT940, MT942, OFX/QFX, BAI2, CSV, and PDF. Corporate Treasury AutomationAutomated Reconciliation for Modern TreasuryEliminate manual statement keying, error-prone spreadsheets, and expensive cloud OCR APIs. Normalize multi-bank statements directly into your general ledger, ERP, and treasury management workflows with sub-second turnaround.View Treasury Playbook ↗Engine ArchitectureEngineered for absolute accuracy.Industrial-grade financial parsing combining memory-safe Rust execution, native Python bindings, and dual Apache/MIT licensing.01Multi-Format Dialect EngineDeterministic state machines parse digital and scanned PDFs, irregular CSV layouts, SGML OFX/QFX, BAI2 cash management, and SWIFT MT940/MT942 messages without brittle regex or external cloud OCR.02Arithmetic Balance VerificationStrict mathematical balance validation ensures opening balance plus net credits and debits precisely equals closing balance to the penny before record emission.03ISO 20022 HarmonizationNormalize disparate bank statements directly into canonical ISO 20022 CAMT.053 XML envelopes, Apache Parquet streams, or strongly-typed JSON schemas ready for ERP, GL, and accounting ingestion.The Processing PipelineFrom raw bank document to validated ledger transactions.1IngestStream PDF bytes, CSV feeds, BAI2 files, or SWIFT MT940/MT942 messages into memory-safe zero-copy buffers.Sub-millisecond stream loading2TokenizeDeterministic lexical analysis identifies account metadata, booking dates, line items, and structured :86: sub-tags.Deterministic layout analysis3VerifyArithmetic balance reconciliation confirms credit/debit integrity, checks PDF forensics, and validates IBAN checksums.Mod-97 and balance proofs4EmitOutput strongly-typed JSON, streaming Apache Parquet, Plain-Text Ledgers (hledger, beancount), or ISO 20022 messages.Ready for ERP, Lakehouse & GL High-Performance PipelineDeterministic Execution at Enterprise ScaleEngineered for high-frequency financial platforms requiring bounded latency, zero-allocation loops, and strict ISO 20022 data models.View Architecture Blueprint ↗Developer QuickstartInstall via Cargo, Pip, or Homebrew in SecondsDeploy as a standalone CLI tool, embed as a high-assurance Rust crate in your microservices, or integrate into Python data pipelines with zero external runtime overhead.Full Documentation → API Reference bash — bankstatementparser# 1. Install standalone CLI or Python library$cargo install bankstatementparser$pip install bankstatementparser# 2. Parse statement with arithmetic balance verification$bankstatementparser --input statement.pdf --format json# 3. Deterministic output verification (< 0.8 ms){ \"status\": \"VALIDATED\", \"duration_ms\": 0.72, \"balance_proof\": \"EXACT_MATCH\" }Zero-Telemetry PrivacyYour financial data never leaves your infrastructure.Bank Statement Parser is 100% self-contained and operates entirely on your local machine, private VPC, or air-gapped on-premise servers. Zero analytics, zero telemetry, and zero outbound network calls—guaranteeing complete GDPR, GLBA, and banking confidentiality compliance.Read Security & Privacy Architecture ↓Clear AnswersFrequently Asked QuestionsDoes Bank Statement Parser send data to the cloud or external servers?No. Bank Statement Parser is 100% self-contained and operates entirely on your local machine or private cloud server. It contains zero analytics, zero telemetry, and zero outbound network calls, ensuring complete compliance with GDPR, HIPAA, GLBA, and banking confidentiality regulations.Which bank statement file formats are supported?Bank Statement Parser natively supports eight primary banking formats: ISO 20022 CAMT (camt.052, camt.053, camt.054), ISO 20022 PAIN.001 (Credit Transfer), SWIFT MT940 and MT942 messages, BAI2 (Bank Administration Institute), Open Financial Exchange (OFX 1.x/2.x and QFX), CSV files (with automatic delimiter and date detection), and digital/scanned PDF statements.How does the parser handle scanned or image-based statements?For digital and vector PDFs, the","headings":["Parse any bank statement in milliseconds.Zero cloud dependencies. Zero telemetry.","Automated Reconciliation for Modern Treasury","Engineered for absolute accuracy.","From raw bank document to validated ledger transactions.","Deterministic Execution at Enterprise Scale","Install via Cargo, Pip, or Homebrew in Seconds","Your financial data never leaves your infrastructure.","Frequently Asked Questions","Financial data is mission-critical.Your parsing pipeline should be instant.","Documentation & API","Solutions & Workflows","Trust & Legal","Multi-Format Dialect Engine","Arithmetic Balance Verification","ISO 20022 Harmonization","Ingest","Tokenize","Verify","Emit"]},{"title":"Made with Static Site Generator (SSG) | Web Platform","url":"/made-with-ssg/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Static Architecture Made with Static Site Generator (SSG) Why Bank Statement Parser documentation is statically generated for uncompromising security, WCAG AAA accessibility, and instant loading. This site is natively compiled using the high-performance Static Site Generator (SSG) written in Rust. Source of Truth: Content authored in Markdown (_posts/*.md) with Tera templates (_layouts/*.html). Compilation Speed: Full site generation in under 0.5 seconds with zero runtime JavaScript framework dependencies. Security: Strict Subresource Integrity (SRI) and Content Security Policy (CSP) headers.","headings":["Made with Static Site Generator (SSG)","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Zero-Telemetry Privacy Guarantee & Data Protection","url":"/privacy/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Trust & Governance Privacy Policy Our foundational commitment: zero tracking, zero analytics, zero external network requests, and complete local processing. Last updated: 1 September 2026 Bank Statement Parser is built on a strict zero-telemetry, zero-cookie architecture: No External Data Transmission: The Bank Statement Parser software operates entirely on the user's infrastructure. No document content, transaction records, or telemetry data are ever collected or transmitted. No Tracking Cookies: This documentation website does not use tracking cookies, analytics pixels, or third-party behavioral scripts. Data Protection Compliance: Fully compliant with GDPR, UK Data Protection Act 2018, and California Consumer Privacy Act (CCPA).","headings":["Privacy Policy","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Security Architecture: Air-Gapped & Memory-Safe Parsing","url":"/security/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Zero-Telemetry Model Security Architecture & Trust Guarantees Strict zero-telemetry guarantees, memory safety verification, and Sigstore-signed releases for compliance-critical pipelines. Financial statement data demands strict confidentiality, rigorous boundary isolation, and deterministic mathematical verification. Bank Statement Parser is architected from the foundation up to operate securely within air-gapped sovereign environments. 0 KB Telemetry Ingest 100% Safe Rust Core Cosign Sigstore Verified 01 Air-Gapped Sovereign Execution Model Bank Statement Parser binds no listening network ports and initiates no outbound TCP, UDP, or HTTP connections. All parsing, coordinate tokenization, and schema validation execute entirely within local process memory. Security Vector Implementation Standard Verification Audit Network Socket Access Zero outbound or listening sockets initialized Enforced via eBPF / seccomp system call filter Heap Memory Sanitization Zero sensitive statement data written to temporary disks Cleared immediately upon statement struct deallocation Third-Party SaaS Telemetry Zero third-party analytics or error tracking SDKs Static binary symbol inspection in CI Subresource Integrity SHA-384 cryptographic digests on all assets Enforced by W3C Content Security Policy (CSP) 02 Software Supply Chain & SBOM Provenance Every release artifact is cryptographically signed and independently auditable using SLSA Level 3 build provenance. A CycloneDX SBOM is published with every release to track transitive dependencies and vulnerability CVE states: bash — verify release provenance # Verify binary release signature using Sigstore Cosign $cosign verify-blob --certificate certificate.pem --signature bankstatementparser.sig bankstatementparser # Audit CycloneDX SBOM for dependency vulnerabilities $cyclonedx validate --input-file sbom.cdx.json 03 Cryptographic Isolation & Architecture Callout The system is purpose-built for financial institutions, hedge funds, sovereign banks, and regulated audit firms requiring verifiable isolation from public cloud APIs. Cryptographic integrity: every binary is Sigstore-signed, air-gapped, and accompanied by a CycloneDX SBOM.","headings":["Security Architecture & Trust Guarantees","Air-Gapped Sovereign Execution Model","Software Supply Chain & SBOM Provenance","Cryptographic Isolation & Architecture Callout","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Terms of Use & Dual Open-Source License Specifications","url":"/terms/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Legal Framework Terms of Use Clear, transparent terms governing the use of Bank Statement Parser open source software and enterprise documentation. Bank Statement Parser is distributed under the dual Apache License 2.0 and MIT License. You may use, modify, distribute, and integrate the software into commercial and open-source applications subject to the terms of either license.","headings":["Terms of Use","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Fintech Use Cases: Treasury & Reconciliation","url":"/use-cases/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Production Blueprints Enterprise Use Cases & Deployment Patterns High-throughput statement extraction powering corporate treasury automation, automated reconciliation, SME credit underwriting, and forensic audit screening. High-throughput statement extraction powers critical automated financial backends with zero cloud dependencies, air-gapped security, and deterministic precision. 99.8% Reconciliation STP Rate < 1 ms Underwriting Ingestion 100% Air-Gapped & Private 01 Corporate Treasury Automation Enterprise treasuries manage accounts across dozens of global banking partners (Citi, JPMorgan Chase, BNP Paribas, HSBC, Deutsche Bank). Each bank issues disparate statement formats with varying column orders, multi-currency balance headers, and non-standard narrative formatting. Bank Statement Parser unifies incoming statement feeds into canonical ISO 20022 camt.053 XML and JSON structures for real-time liquidity management. Operational Dimension Legacy Manual / OCR Workflow Bank Statement Parser Engine Processing Latency 30–45 minutes per multi-page statement < 5 milliseconds per statement Balance Verification Manual human calculation or unverified Mathematical proof (Opening + Transactions = Closing) Liquidity Visibility T+1 or T+2 retrospective reporting Continuous real-time intraday cash positioning Transcription Error Rate 2.1% – 3.5% human keying errors 0.00% deterministic spatial coordinate extraction bash — treasury batch ingestion pipeline # Batch-process multi-bank intraday statements with strict balance invariant check $bankstatementparser --batch-dir ./treasury/incoming/ --verify-balance --output-dir ./tms/ready/ Ingested: 128 PDF statements (Citi, HSBC, BNP, JPM) Transactions: 14,892 records parsed, normalized, and balanced Balance Proof: 128/128 passed [Opening + sum(credits) - sum(debits) == Closing] 02 Automated Bank Reconciliation Finance operations teams reconcile millions of bank transaction lines against general ledger (GL) entries every fiscal period. Irregular descriptions, truncated transaction codes, and disparate currency notations typically create enormous manual exception queues. Bank Statement Parser normalizes reference numbers, counterparty names, and structured remittance data to drive straight-through processing (STP) rates above 99.8%. Reconciliation Metric Generic PDF Scraper Bank Statement Parser Engine Payee Normalization Raw truncated strings with bank noise Clean entity names with stripped routing prefixes Reference Code Extraction Brittle regex frequently drops end tokens Coordinate-aware token bounding for full invoice codes STP Match Rate 60% – 75% (heavy manual review) 99.8% automated straight-through processing Multi-Currency Handling String-level assumptions ISO 4217 validation with decimal-exact precision python — high-throughput reconciliation stream from bankstatementparser import parse_statement # Ingest PDF statement directly into reconciliation pipeline statement = parse_statement(\"statements/october_operations.pdf\") for tx in statement.transactions: match = ledger.reconcile(reference=tx.reference, amount=tx.amount, date=tx.booking_date) assert statement.balanced, \"Statement balances must be mathematically proven\" 03 Fintech SME Credit Underwriting Modern commercial lenders and merchant cash advance platforms require rapid, accurate extraction of 12 to 24 months of applicant bank statements. The engine calculates net operating cash flows, recurring revenue, non-sufficient funds (NSF) events, and average daily balances in milliseconds—enabling instant credit decisions while applicants are still on the lender's application portal. Underwriting Parameter Human Document Review Bank Statement Parser Turnaround Time 24 to 72 hours per dossier < 500 milliseconds for 24 months Dossier Volume Sampled 3 months due to cost 12–24 months fully ingested and analyzed Document Tampering Detection Subjective visual check Mathematical invariant verification detects doctored numbers Cost per Application $25 – $50 in human labor $0.00 (Self-hosted native engine) rust — applicant dossier analysis use bankstatementparser::{Engine, Config}; let engine = Engine::new(Config::strict_validation()); let report = engine.parse_applicant_dossier(&[\"m1.pdf\", \"m2.pdf\", \"m3.pdf\"])?; println!(\"Net Cashflow: {}, Overdrafts: {}\", report.net_cashflow(), report.nsf_count()); 04 Forensic Audit & Sanctions Screening Forensic accountants and AML investigators examine thousands of historical bank statements during restructuring, corporate acquisitions, bankruptcy inquiries, and regulatory investigations. The parser's air-gapped, zero-network architecture guarantees that sensitive banking data never leaves local customer infrastructure or secure enclaves. Investigation Capability Cloud OCR Services Bank Statement Parser Data Sovereignty & Privacy Customer data sent to external cloud APIs 100% on-premises / air-gapped execution","headings":["Enterprise Use Cases & Deployment Patterns","Corporate Treasury Automation","Automated Bank Reconciliation","Fintech SME Credit Underwriting","Forensic Audit & Sanctions Screening","Enterprise Deployment Architecture","Documentation & API","Solutions & Workflows","Trust & Legal"]}]}
\ No newline at end of file
diff --git a/public/.meta/changelog.meta.json b/public/.meta/changelog.meta.json
index b153502..1e51af4 100644
--- a/public/.meta/changelog.meta.json
+++ b/public/.meta/changelog.meta.json
@@ -16,5 +16,5 @@
"reading_time": 1,
"short_name": "bankstatementparser",
"title": "Changelog & Semantic Version History: Release Notes",
- "word_count": 347
+ "word_count": 371
}
\ No newline at end of file
diff --git a/public/.ssg-cache/depgraph.json b/public/.ssg-cache/depgraph.json
index ff690c1..cfc0a23 100644
--- a/public/.ssg-cache/depgraph.json
+++ b/public/.ssg-cache/depgraph.json
@@ -1 +1 @@
-{"version":2,"deps":{"_layouts/404.html":["_layouts/base.html"],"_layouts/contact.html":["_layouts/base.html"],"_layouts/faqs.html":["_layouts/base.html"],"_layouts/index.html":["_layouts/base.html"],"_layouts/offline.html":["_layouts/base.html"],"_layouts/page.html":["_layouts/base.html"],"_posts/404.md":["_layouts/404.html","_posts/404.md"],"_posts/about.md":["_layouts/page.html","_posts/about.md"],"_posts/accessibility.md":["_layouts/page.html","_posts/accessibility.md"],"_posts/api.md":["_layouts/page.html","_posts/api.md"],"_posts/architecture.md":["_layouts/page.html","_posts/architecture.md"],"_posts/benchmarks.md":["_layouts/page.html","_posts/benchmarks.md"],"_posts/changelog.md":["_layouts/page.html","_posts/changelog.md"],"_posts/contact.md":["_layouts/contact.html","_posts/contact.md"],"_posts/contributing.md":["_layouts/page.html","_posts/contributing.md"],"_posts/faqs.md":["_layouts/faqs.html","_posts/faqs.md"],"_posts/formats.md":["_layouts/page.html","_posts/formats.md"],"_posts/getting-started.md":["_layouts/page.html","_posts/getting-started.md"],"_posts/index.md":["_layouts/index.html","_posts/index.md"],"_posts/made-with-ssg.md":["_layouts/page.html","_posts/made-with-ssg.md"],"_posts/offline.md":["_layouts/offline.html","_posts/offline.md"],"_posts/privacy.md":["_layouts/page.html","_posts/privacy.md"],"_posts/security.md":["_layouts/page.html","_posts/security.md"],"_posts/terms.md":["_layouts/page.html","_posts/terms.md"],"_posts/thanks.md":["_layouts/page.html","_posts/thanks.md"],"_posts/use-cases.md":["_layouts/page.html","_posts/use-cases.md"]},"outputs":{"_posts/404.md":["public/404/index.html"],"_posts/about.md":["public/about/index.html"],"_posts/accessibility.md":["public/accessibility/index.html"],"_posts/api.md":["public/api/index.html"],"_posts/architecture.md":["public/architecture/index.html"],"_posts/benchmarks.md":["public/benchmarks/index.html"],"_posts/changelog.md":["public/changelog/index.html"],"_posts/contact.md":["public/contact/index.html"],"_posts/contributing.md":["public/contributing/index.html"],"_posts/faqs.md":["public/faqs/index.html"],"_posts/formats.md":["public/formats/index.html"],"_posts/getting-started.md":["public/getting-started/index.html"],"_posts/index.md":["public/index.html"],"_posts/made-with-ssg.md":["public/made-with-ssg/index.html"],"_posts/offline.md":["public/offline/index.html"],"_posts/privacy.md":["public/privacy/index.html"],"_posts/security.md":["public/security/index.html"],"_posts/terms.md":["public/terms/index.html"],"_posts/thanks.md":["public/thanks/index.html"],"_posts/use-cases.md":["public/use-cases/index.html"]},"hashes":{"_layouts/404.html":"17192422da99d87d32ba2d575456e0d304ae9f52e3d7b9f7813e65c23e8919c6","_layouts/base.html":"aff2f682e4472908f808fd01638a4a727d8059a43b6901c50b830df141cf3c8f","_layouts/contact.html":"cde4e4ff156a75852c740d4ac98d8cc80b30fe9c267344bc27279241aaa9c3df","_layouts/faqs.html":"cde4e4ff156a75852c740d4ac98d8cc80b30fe9c267344bc27279241aaa9c3df","_layouts/footer.html":"fda75df2bc96446008d288512ab6ae7c54d93c5bf3beb48d02c3627262fca06c","_layouts/header.html":"0ca4077ec04f4ad9759ac28004c4bcad052c9a3e8a89b33ba435afb06bfa9ea3","_layouts/index.html":"1011c37cf9a923ebe4e8e777d90c0211db95bf789d245e0f5a44c31f1f8e15b0","_layouts/offline.html":"17192422da99d87d32ba2d575456e0d304ae9f52e3d7b9f7813e65c23e8919c6","_layouts/page.html":"cde4e4ff156a75852c740d4ac98d8cc80b30fe9c267344bc27279241aaa9c3df","_posts/404.md":"b97fd2c4ea654a1c820c1f988edd3ed433cb6bb8b6abc3f2147665fa4acc13b0","_posts/about.md":"13194ab6c87d444d2a8e647b0a248eb8194a616e2667f464516d50edb5baa37a","_posts/accessibility.md":"b791c5a0c010756d7c94af08a3ad2a1942cf78b7297ae96bc6946fa9a5b3997b","_posts/api.md":"d56ea4a068ab062bcdb074e90a76375c9d246ce07510e9ad3dea43b0d716980d","_posts/architecture.md":"bee13f62aebbea7f768c1ccae09402bc9d3720cbbe2704828305f0c57e182164","_posts/benchmarks.md":"4c838792a32c88f09a74300063c6ade24ab89c9f55b6ab415589fdfa59431bee","_posts/changelog.md":"a2ce1281a7a780b4983bdb192ecdc48c942704b4b02d3067ef1512c16e9afede","_posts/contact.md":"d1e789015df47d82215f1e6b483242c785509e84cc57760070537fd1692e0f39","_posts/contributing.md":"b85023503834959a5b6160ba1121708d2c5e0cfe2eb2641a9042891b834daabc","_posts/faqs.md":"ddf4eab90358d3729b61efc25ea612a7994d398659dacd2acc58d03a38dba742","_posts/formats.md":"1ea659800531779d2ec03c4a1cd37b4d687fff0afe8d46023bb1f12c4f4148fe","_posts/getting-started.md":"7f6af1169dc7c0fcc294d68a06e1d93e7b33b40fdaf7368e9a4e9f6a1e9174ae","_posts/index.md":"da861797f6c3de6d8b7d58fc2c5bee995bfda5dcfa0b5830eabde1be81d10d16","_posts/made-with-ssg.md":"c4fe1809ffce25fbee2d5929a807c91aad9adc954d08ebae1016bb2a7901fd4e","_posts/offline.md":"8952c7c61dbaf573475c4b503dda11871e7aa54eb9e25cc02c70c44267b095da","_posts/privacy.md":"e9583cd2a7d275aefc56daa151fcf4df28c435f1b0c000456ea8bc6b66ec0026","_posts/security.md":"7cf9a0140c29db3f136418d16b558e2d00b3f7e546ec669b286ca380e44d0eab","_posts/terms.md":"c1a1bc49d3c2abfcb6ca4a36b101cd2ff89d561c0cc1466cf009a3a080dfadfa","_posts/thanks.md":"640778d610fb767da4034ad8e6497550acf1594980698f7bf44b7ab13ebe8ec2","_posts/use-cases.md":"98f5d7adab2414c2c1aa0cf7959c294ca38bc8a4ccd67df30b97d43d4954c47e"}}
\ No newline at end of file
+{"version":2,"deps":{"_layouts/404.html":["_layouts/base.html"],"_layouts/contact.html":["_layouts/base.html"],"_layouts/faqs.html":["_layouts/base.html"],"_layouts/index.html":["_layouts/base.html"],"_layouts/offline.html":["_layouts/base.html"],"_layouts/page.html":["_layouts/base.html"],"_posts/404.md":["_layouts/404.html","_posts/404.md"],"_posts/about.md":["_layouts/page.html","_posts/about.md"],"_posts/accessibility.md":["_layouts/page.html","_posts/accessibility.md"],"_posts/api.md":["_layouts/page.html","_posts/api.md"],"_posts/architecture.md":["_layouts/page.html","_posts/architecture.md"],"_posts/benchmarks.md":["_layouts/page.html","_posts/benchmarks.md"],"_posts/changelog.md":["_layouts/page.html","_posts/changelog.md"],"_posts/contact.md":["_layouts/contact.html","_posts/contact.md"],"_posts/contributing.md":["_layouts/page.html","_posts/contributing.md"],"_posts/faqs.md":["_layouts/faqs.html","_posts/faqs.md"],"_posts/formats.md":["_layouts/page.html","_posts/formats.md"],"_posts/getting-started.md":["_layouts/page.html","_posts/getting-started.md"],"_posts/index.md":["_layouts/index.html","_posts/index.md"],"_posts/made-with-ssg.md":["_layouts/page.html","_posts/made-with-ssg.md"],"_posts/offline.md":["_layouts/offline.html","_posts/offline.md"],"_posts/privacy.md":["_layouts/page.html","_posts/privacy.md"],"_posts/security.md":["_layouts/page.html","_posts/security.md"],"_posts/terms.md":["_layouts/page.html","_posts/terms.md"],"_posts/thanks.md":["_layouts/page.html","_posts/thanks.md"],"_posts/use-cases.md":["_layouts/page.html","_posts/use-cases.md"]},"outputs":{"_posts/404.md":["public/404/index.html"],"_posts/about.md":["public/about/index.html"],"_posts/accessibility.md":["public/accessibility/index.html"],"_posts/api.md":["public/api/index.html"],"_posts/architecture.md":["public/architecture/index.html"],"_posts/benchmarks.md":["public/benchmarks/index.html"],"_posts/changelog.md":["public/changelog/index.html"],"_posts/contact.md":["public/contact/index.html"],"_posts/contributing.md":["public/contributing/index.html"],"_posts/faqs.md":["public/faqs/index.html"],"_posts/formats.md":["public/formats/index.html"],"_posts/getting-started.md":["public/getting-started/index.html"],"_posts/index.md":["public/index.html"],"_posts/made-with-ssg.md":["public/made-with-ssg/index.html"],"_posts/offline.md":["public/offline/index.html"],"_posts/privacy.md":["public/privacy/index.html"],"_posts/security.md":["public/security/index.html"],"_posts/terms.md":["public/terms/index.html"],"_posts/thanks.md":["public/thanks/index.html"],"_posts/use-cases.md":["public/use-cases/index.html"]},"hashes":{"_layouts/404.html":"17192422da99d87d32ba2d575456e0d304ae9f52e3d7b9f7813e65c23e8919c6","_layouts/base.html":"aff2f682e4472908f808fd01638a4a727d8059a43b6901c50b830df141cf3c8f","_layouts/contact.html":"cde4e4ff156a75852c740d4ac98d8cc80b30fe9c267344bc27279241aaa9c3df","_layouts/faqs.html":"cde4e4ff156a75852c740d4ac98d8cc80b30fe9c267344bc27279241aaa9c3df","_layouts/footer.html":"fda75df2bc96446008d288512ab6ae7c54d93c5bf3beb48d02c3627262fca06c","_layouts/header.html":"0ca4077ec04f4ad9759ac28004c4bcad052c9a3e8a89b33ba435afb06bfa9ea3","_layouts/index.html":"1011c37cf9a923ebe4e8e777d90c0211db95bf789d245e0f5a44c31f1f8e15b0","_layouts/offline.html":"17192422da99d87d32ba2d575456e0d304ae9f52e3d7b9f7813e65c23e8919c6","_layouts/page.html":"cde4e4ff156a75852c740d4ac98d8cc80b30fe9c267344bc27279241aaa9c3df","_posts/404.md":"b97fd2c4ea654a1c820c1f988edd3ed433cb6bb8b6abc3f2147665fa4acc13b0","_posts/about.md":"13194ab6c87d444d2a8e647b0a248eb8194a616e2667f464516d50edb5baa37a","_posts/accessibility.md":"b791c5a0c010756d7c94af08a3ad2a1942cf78b7297ae96bc6946fa9a5b3997b","_posts/api.md":"d56ea4a068ab062bcdb074e90a76375c9d246ce07510e9ad3dea43b0d716980d","_posts/architecture.md":"bee13f62aebbea7f768c1ccae09402bc9d3720cbbe2704828305f0c57e182164","_posts/benchmarks.md":"4c838792a32c88f09a74300063c6ade24ab89c9f55b6ab415589fdfa59431bee","_posts/changelog.md":"869e055c4168fa20dcca07ee7a505a6a5c97dc164ccc68161072bb30200d0e35","_posts/contact.md":"d1e789015df47d82215f1e6b483242c785509e84cc57760070537fd1692e0f39","_posts/contributing.md":"b85023503834959a5b6160ba1121708d2c5e0cfe2eb2641a9042891b834daabc","_posts/faqs.md":"ddf4eab90358d3729b61efc25ea612a7994d398659dacd2acc58d03a38dba742","_posts/formats.md":"1ea659800531779d2ec03c4a1cd37b4d687fff0afe8d46023bb1f12c4f4148fe","_posts/getting-started.md":"7f6af1169dc7c0fcc294d68a06e1d93e7b33b40fdaf7368e9a4e9f6a1e9174ae","_posts/index.md":"da861797f6c3de6d8b7d58fc2c5bee995bfda5dcfa0b5830eabde1be81d10d16","_posts/made-with-ssg.md":"c4fe1809ffce25fbee2d5929a807c91aad9adc954d08ebae1016bb2a7901fd4e","_posts/offline.md":"8952c7c61dbaf573475c4b503dda11871e7aa54eb9e25cc02c70c44267b095da","_posts/privacy.md":"e9583cd2a7d275aefc56daa151fcf4df28c435f1b0c000456ea8bc6b66ec0026","_posts/security.md":"7cf9a0140c29db3f136418d16b558e2d00b3f7e546ec669b286ca380e44d0eab","_posts/terms.md":"c1a1bc49d3c2abfcb6ca4a36b101cd2ff89d561c0cc1466cf009a3a080dfadfa","_posts/thanks.md":"640778d610fb767da4034ad8e6497550acf1594980698f7bf44b7ab13ebe8ec2","_posts/use-cases.md":"98f5d7adab2414c2c1aa0cf7959c294ca38bc8a4ccd67df30b97d43d4954c47e"}}
\ No newline at end of file
diff --git a/public/.ssg-plugin-cache.json b/public/.ssg-plugin-cache.json
index 615daaf..fe8a351 100644
--- a/public/.ssg-plugin-cache.json
+++ b/public/.ssg-plugin-cache.json
@@ -5,7 +5,7 @@
"public/api/index.html": 16738817662723772396,
"public/architecture/index.html": 2547062936051338519,
"public/benchmarks/index.html": 9264854718161004577,
- "public/changelog/index.html": 14453374707306954863,
+ "public/changelog/index.html": 7719752161556317238,
"public/contact/index.html": 15851191858446219194,
"public/contributing/index.html": 12888048974157366658,
"public/faqs/index.html": 2804181515689989929,
diff --git a/public/api/agents/posts.json b/public/api/agents/posts.json
index c12ff0c..8a601d6 100644
--- a/public/api/agents/posts.json
+++ b/public/api/agents/posts.json
@@ -51,7 +51,7 @@
"tags": [],
"title": "Changelog & Semantic Version History: Release Notes",
"url": "https://bankstatementparser.com/changelog/",
- "wordCount": 347
+ "wordCount": 371
},
{
"date": "2026-09-01",
diff --git a/public/changelog/index.html b/public/changelog/index.html
index 30f364b..386df23 100644
--- a/public/changelog/index.html
+++ b/public/changelog/index.html
@@ -43,7 +43,7 @@
SearchK
-
Release History
Changelog
Deterministic versioning history, security audits, and functional enhancements across every release.
All notable changes to Bank Statement Parser are documented in this file following strict Semantic Versioning.
[0.0.6] - 2026-10-30
Added
Generated llms-full.txt alongside llms.txt for single-request LLM and coding agent ingestion.
Expanded property-based test coverage for deterministic SOURCE_DATE_EPOCH builds and URL classification.
Changed
Trusted second maintainer SSH signing key (rousseau-mbp-m1) in KEYS.asc and .github/allowed_signers.
Upgraded CI to Node.js 24 and ssg 0.0.69, and pruned 40 unused legacy template files.
Fixed
Reformatted KEYS.asc into valid OpenSSH allowed-signers format and honoured SOURCE_DATE_EPOCH in sitemap.xml generation.
[0.0.5] - 2026-10-11
Changed
Upgraded SSG compiler pin in release automation and standardized build and audit sequencing for byte-for-byte reproducible release archives.
Fixed
Resolved CodeQL alert 39 in scripts/post-build.py by permitting whitespace and attributes in closing script tags.
[0.0.4] - 2026-10-11
Added
Injected Schema.org BreadcrumbList structured data across all subpages.
Changed
Standardized sitemap.xml and canonical permalinks to trailing directory slashes and excluded 404/ and offline/ utility routes.
[0.0.3] - 2026-10-10
Added
Expanded format specifications covering all 8 banking formats: CAMT (052/053/054), PAIN.001, MT940, MT942, OFX/QFX, BAI2, CSV, and PDF.
Fixed CSS entity escape sequence for .hr-blurred:after in base layout template.
Rebuilt native static site generator assets and synced release version metadata.
[0.0.1] - 2026-09-01
Added
Initial release of the Bank Statement Parser documentation portal.
Static Site Generator (SSG) native compilation pipeline.
Multi-format support specifications (PDF, CSV, OFX, QIF, MT940, CAMT.053).
WCAG 2.2 Level AAA compliant design system.
Zero-telemetry security documentation and CycloneDX SBOM provenance.
+
Release History
Changelog
Deterministic versioning history, security audits, and functional enhancements across every release.
All notable changes to Bank Statement Parser are documented in this file following strict Semantic Versioning.
[0.0.7] - 2026-10-30
Fixed
Resolved CodeQL code scanning alerts 41 and 42 (py/empty-except) in scripts/post-build.py and tightened exception handling in scripts/validate_spdx_headers.py.
[0.0.6] - 2026-10-30
Added
Generated llms-full.txt alongside llms.txt for single-request LLM and coding agent ingestion.
Expanded property-based test coverage for deterministic SOURCE_DATE_EPOCH builds and URL classification.
Changed
Trusted second maintainer SSH signing key (rousseau-mbp-m1) in KEYS.asc and .github/allowed_signers.
Upgraded CI to Node.js 24 and ssg 0.0.69, and pruned 40 unused legacy template files.
Fixed
Reformatted KEYS.asc into valid OpenSSH allowed-signers format and honoured SOURCE_DATE_EPOCH in sitemap.xml generation.
[0.0.5] - 2026-10-11
Changed
Upgraded SSG compiler pin in release automation and standardized build and audit sequencing for byte-for-byte reproducible release archives.
Fixed
Resolved CodeQL alert 39 in scripts/post-build.py by permitting whitespace and attributes in closing script tags.
[0.0.4] - 2026-10-11
Added
Injected Schema.org BreadcrumbList structured data across all subpages.
Changed
Standardized sitemap.xml and canonical permalinks to trailing directory slashes and excluded 404/ and offline/ utility routes.
[0.0.3] - 2026-10-10
Added
Expanded format specifications covering all 8 banking formats: CAMT (052/053/054), PAIN.001, MT940, MT942, OFX/QFX, BAI2, CSV, and PDF.
Fixed CSS entity escape sequence for .hr-blurred:after in base layout template.
Rebuilt native static site generator assets and synced release version metadata.
[0.0.1] - 2026-09-01
Added
Initial release of the Bank Statement Parser documentation portal.
Static Site Generator (SSG) native compilation pipeline.
Multi-format support specifications (PDF, CSV, OFX, QIF, MT940, CAMT.053).
WCAG 2.2 Level AAA compliant design system.
Zero-telemetry security documentation and CycloneDX SBOM provenance.
diff --git a/public/llms-full.txt b/public/llms-full.txt
index 974f3f9..b84a952 100644
--- a/public/llms-full.txt
+++ b/public/llms-full.txt
@@ -1716,6 +1716,10 @@ Financial statement data demands strict confidentiality, rigorous boundary isola
All notable changes to **Bank Statement Parser** are documented in this file following strict Semantic Versioning.
+## [0.0.7] - 2026-10-30
+### Fixed
+- Resolved CodeQL code scanning alerts 41 and 42 (`py/empty-except`) in `scripts/post-build.py` and tightened exception handling in `scripts/validate_spdx_headers.py`.
+
## [0.0.6] - 2026-10-30
### Added
- Generated `llms-full.txt` alongside `llms.txt` for single-request LLM and coding agent ingestion.
diff --git a/public/sbom.cdx.json b/public/sbom.cdx.json
index ccfdc4f..87f6fb8 100644
--- a/public/sbom.cdx.json
+++ b/public/sbom.cdx.json
@@ -39,7 +39,7 @@
"name": "static-site",
"type": "application"
},
- "timestamp": "2026-10-30T21:41:20Z",
+ "timestamp": "2026-10-30T22:21:28Z",
"tools": [
{
"name": "ssg",
@@ -48,7 +48,7 @@
}
]
},
- "serialNumber": "urn:uuid:87b74e5b-a794-860c-9d76-5ede8bbe7c6a",
+ "serialNumber": "urn:uuid:8b052de0-7a8e-804f-af4e-f63ee19ed76a",
"specVersion": "1.5",
"version": 1
}
\ No newline at end of file
diff --git a/public/search-index.json b/public/search-index.json
index a237326..671a2e6 100644
--- a/public/search-index.json
+++ b/public/search-index.json
@@ -1 +1 @@
-{"entries":[{"title":"About Sebastien Rousseau | Bank Statement Parser Author","url":"/about/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Engineering & Leadership About Sebastien Rousseau Principal engineer building high-assurance, privacy-first financial infrastructure and cryptographic document tooling. Sebastien Rousseau Principal Financial Systems Architect · 19 Years in Production Banking Infrastructure Sebastien Rousseau has spent nearly two decades architecting, building, and securing high-volume transaction processing systems, institutional payment rails, and cryptographic protocols across global financial centres. Explore his work, publications, and advisory at sebastienrousseau.com. Engineering Pedigree & Domain Expertise With nineteen years of hands-on systems engineering across tier-1 investment banking, clearing gateways, and treasury infrastructures in London and international financial hubs, Sebastien specializes in high-throughput document tokenization, payment message harmonization, and post-quantum cryptographic security. 19 Years in Production Finance: Architecture of mission-critical systems across Corporate & Investment Banking (CIB), SWIFT payment gateways, SEPA clearing schemes, and real-time treasury ledger reconciliation. Author of Sovereign Open-Source Libraries: Creator of Bank Statement Parser, KyberLib (FIPS 203 ML-KEM module lattice-based key encapsulation), hsh, and ISO 20022 message engines with over 45.7M+ total package downloads. Standards & Protocol Conformance: Deep domain mastery of SWIFT Standards Release 2026 (MT940, MT942, field :86: sub-tags), ISO 20022 cash management (CAMT.052, CAMT.053, CAMT.054), payment initiation (PAIN.001), and North American BAI2 cash reporting. Zero-Telemetry Sovereign Architecture: Committed to building air-gapped, sovereign financial tools that execute locally with zero telemetry, preserving absolute banking confidentiality and data sovereignty. Personal Website & Keynotes: Visit sebastienrousseau.com for technical white papers, research monographs, and conference addresses on financial engineering and cryptographic assurance.","headings":["About Sebastien Rousseau","Sebastien Rousseau","Engineering Pedigree & Domain Expertise","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Accessibility Statement: WCAG 2.2 Level AAA Compliance","url":"/accessibility/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Inclusive Engineering Accessibility Statement Dedicated to achieving WCAG 2.2 Level AAA compliance across all digital documentation and interactive financial tooling. Bank Statement Parser is committed to digital accessibility, conforming strictly to WCAG 2.2 Level AAA guidelines: Contrast Ratios: Text colors achieve contrast ratios exceeding 17:1 in light mode and 18:1 in dark mode (well above the 7.0:1 AAA standard). Keyboard Navigation: Full keyboard operability with prominent focus indicators across all interactive elements. Screen Reader Support: Semantic HTML5 landmarks (nav, main, article, footer) and ARIA live regions.","headings":["Accessibility Statement","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"API Reference: Rust Crate & Python SDK Guide","url":"/api/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Developer Reference API & SDK Reference Complete programming interfaces, types, and error handling for Rust, Python, and CLI pipelines. Bank Statement Parser exposes deterministic, zero-allocation interfaces across both native Rust and PyO3-powered Python bindings. Every function executes strictly in-process with zero network telemetry, complete memory safety, and mathematical balance verification. 01 Rust Core Library Interface (lib.rs) Integrate the native Rust crate directly into your backend services for maximum CPU throughput, sub-millisecond document parsing, and zero heap duplication: rust — crate interface use bankstatementparser::{Parser, Statement, Transaction}; use std::path::Path; # Configure thread-safe parser with dialect auto-detection let parser = Parser::builder() .detect_dialects(true) .strict_balance_validation(true) .build(); # Parse byte stream directly from memory or disk let statement: Statement = parser.parse_file(Path::new(\"statement.pdf\"))?; # Access verified balance invariants and transactions println!(\"Account IBAN: {}\", statement.account_id); println!(\"Closing Balance: {} {}\", statement.closing_balance, statement.currency); for tx in statement.transactions { println!(\"{} | {:>10.2} | {}\", tx.date, tx.amount, tx.description); } Core data types provided by the native crate: Type / Symbol Signature Description Parser struct Parser Thread-safe parser engine supporting zero-copy byte slice and file ingestion. ParserBuilder struct ParserBuilder Configures parallel threads, balance invariants, and dialect heuristics. Statement struct Statement Normalized document model containing account ID, balances, currency, and transactions. Transaction struct Transaction Individual ledger item with booking date, value date, signed amount, and narrative. StatementFormat enum StatementFormat Output target variants: Json, Csv, Ofx, Qif, and Camt053. 02 Python SDK Interface (PyO3) Pre-compiled binary wheels for Linux, macOS, and Windows provide native Rust speed directly inside Python data science, pandas, and web application workflows: python — sdk quickstart from bankstatementparser import ( BankStatementParser, CamtParser, Bai2Parser, Mt940Parser, ParquetStreamWriter, reconcile_payments_and_statements, ) # 1. Parse statement into strongly-typed Transaction models parser = BankStatementParser() statement = parser.parse_file(\"statement.pdf\") # 2. Stream transactions directly to Apache Parquet with ParquetStreamWriter(\"transactions.parquet\") as writer: writer.write_batch(statement.transactions) # 3. Inspect verified balance proof print(f\"Closing Balance: {statement.closing_balance} {statement.currency}\") for tx in statement.transactions: print(f\"{tx.date} | {tx.amount:>10.2f} | {tx.description}\") Core parsers and analytical tools exported by the module: Symbol Type / Signature Purpose & Description BankStatementParser Class Primary document engine for PDF layout extraction, OCR fallback, and multi-format routing. Bai2Parser Class Dedicated state machine parser for BAI2 corporate cash management files. CamtParser Class High-speed XML parser for ISO 20022 CAMT.052, CAMT.053, and CAMT.054 statements. Pain001Parser Class Parser for ISO 20022 PAIN.001 customer credit transfer payment instructions. Mt940Parser / Mt942Parser Class SWIFT MT940 end-of-day and MT942 intraday tag-based message parsers. ParquetStreamWriter ContextManager Streams batches of transactions directly to Apache Parquet with Snappy/Zstd compression. reconcile_payments_and_statements Function Two-way automated reconciliation matching payment orders against statement postings. inspect_pdf_forensics Function Audits PDF statements for font discrepancies, metadata modifications, and tampering findings. analyze_statement_transactions Function Computes cash flow summaries, average daily balances, NSF fees, and recurring cadences. 03 Deterministic Error Handling & Diagnostics All processing pipelines isolate corrupt documents, unsupported regional dialects, and balance arithmetic discrepancies into typed error exceptions without panics or unhandled crashes: python — error handling from bankstatementparser import parse_statement from bankstatementparser.exceptions import ( BalanceMismatchError, UnsupportedDialectError, CorruptedDocumentError, ) try: statement = parse_statement(\"statement.pdf\") except BalanceMismatchError as exc: # Arithmetic discrepancy: opening + sum(credits) - sum(debits) != closing print(f\"Audit failed: expected delta {exc.expected_delta}, found {exc.actual_delta}\") except UnsupportedDialectError as exc: # Document signature unrecognized print(f\"Unsupported bank layout: {exc.detected_signature}\") except CorruptedDocumentError as exc: print(f\"Malformed file stream: {exc.details}\") 04 Zero-Telemetry Execution Guarantees Bank Statement Parser makes zero outbound network calls, transmits no analytical telemetry, and requires no external SaaS API keys.","headings":["API & SDK Reference","Rust Core Library Interface (lib.rs)","Python SDK Interface (PyO3)","Deterministic Error Handling & Diagnostics","Zero-Telemetry Execution Guarantees","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Architecture Blueprint: Deterministic Financial Parsing","url":"/architecture/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Engine Internals Architecture & Pipeline Specifications High-throughput tokenization, deterministic stream parsing, and ISO 20022 message synthesis with zero runtime allocations. Bank Statement Parser is architected around a deterministic, four-stage extraction and validation pipeline. Every stage executes in-process with zero outbound telemetry, zero heap allocation in the critical path, and strict mathematical balance verification before emitting ISO 20022 messages. Four-Stage Processing Pipeline 01 Stream Ingest Zero-copy memory mapping (mmap) of input statement bytes with instant magic-byte format detection (PDF, CSV, OFX, MT940, CAMT.053). < 0.2 ms Ingest Latency 02 Layout Tokenizer Spatial coordinate mapping and multi-column tabular boundary reconstruction, preserving text flow across complex multi-page financial tables. Zero Heap Allocations 03 Field Normalizer Canonical standardization of 24 global date dialects, ISO 4217 currencies, and mod-97 IBAN checksum verification. ISO 20022 BTC Mapping 04 Schema Validator Mathematical invariant verification (Opening + ΣCredits - ΣDebits = Closing) before emitting validated JSON or ISO 20022 XML. 100% Invariant Check Deterministic Pipeline Execution Trace The trace below demonstrates the sub-millisecond execution lifecycle of the four-stage engine processing a multi-page PDF statement into validated ISO 20022 CAMT.053 XML: pipeline-trace — bankstatementparser v0.0.2 $bankstatementparser --input statement.pdf --trace --format camt053 [0.00ms] [ingest] Zero-copy mmap statement.pdf (142,896 bytes) • Magic: %PDF-1.7 [0.18ms] [tokenizer] Spatial scan complete: 4 tables detected, 128 transaction rows clustered [0.45ms] [normalizer] Currency: GBP (ISO 4217) • Account: GB29BARC20000012345678 (mod-97 OK) [0.72ms] [validator] Opening: 14,250.00 | Credits: +8,300.50 | Debits: -3,120.25 | Closing: 19,430.25 [0.89ms] [validator] Invariant Check: 14,250.00 + 5,180.25 == 19,430.25 [PASS: Delta = 0.0000] [1.12ms] [synthesis] Emitted ISO 20022 camt.053.001.08 XML (42,810 bytes, schema valid) Status: 200 OK • Latency: 1.12ms • Memory: 1.4 MB • Telemetry: Zero Outbound Stage 1: Zero-Copy Stream Ingestion The ingestion subsystem interfaces directly with the host filesystem via memory-mapped files (mmap), bypassing kernel-to-userspace buffer duplication. Byte slices are analyzed using non-backtracking magic-byte sniffers: PDF Documents: Validates file header prefix %PDF- and reads the cross-reference table (xref) directly from the trailer offset. OFX Streams: Sniffs OFXHEADER SGML tags or XML prologue Result<(), Box> { let parser = Parser::new(); let statement = parser.parse_file(Path::new(\"statement.pdf\"))?; println!(\"Account: {}, Balance: {}\", statement.account_id,","headings":["Frequently Asked Questions","No matching questions found","Have a question not listed here?","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Supported Statement Formats: PDF, CSV, OFX, MT940, CAMT, BAI2","url":"/formats/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Specifications Matrix Supported Statement Formats & Specifications Deterministic multi-standard document ingestion with automated schema normalization across 8 financial formats, Parquet streaming, and ledger exports. Bank Statement Parser provides deterministic, zero-telemetry ingestion and mathematical balance verification across eight primary banking standards worldwide. Every format is normalized into strongly-typed Transaction and Statement models ready for ERP integration, corporate treasury, automated reconciliation, and OLAP analytics. Format Standard / Specification Extraction Method Validation Engine PDF Statements Adobe PDF 1.4–2.0 (Vector & Scanned) Spatial coordinate tokenizer & local OCR/vision fallback Mathematical balance verification & IBAN Mod-97 checksum CSV & Delimited RFC 4180 with Dialect Auto-Detect Statistical delimiter, decimal, and date header inference Column type inference & date format normalization BAI2 Cash Management Bank Administration Institute (BAI2) Deterministic record state machine (Records 01–99) Account status balance codes & record 88 continuation validation SWIFT MT940 SWIFT Standards Release 2026 (End-of-Day) Tag-based state machine parser (:20:, :25:, :60F:, :61:, :62F:) Opening/closing balance arithmetic (Fields 60F/62F) SWIFT MT942 SWIFT Standards Release 2026 (Interim) Intraday credit/debit transaction stream parser Field 34F floor limit & summary amount reconciliation ISO 20022 CAMT camt.052, camt.053, and camt.054 (v2–v12) Zero-copy XML streaming parser W3C XML Schema (XSD) & opening/closing balance proofs ISO 20022 PAIN.001 pain.001.001.03–11 (Customer Credit Transfer) Deterministic XML payment initiation parser Payment control sum & transaction count verification OFX & Quicken QFX Open Financial Exchange (1.02–2.2 SGML & XML) Robust tree parser with SGML unclosed-tag repair Standard banking DTD & transaction UID deduplication 1. ISO 20022 Messaging Standard (CAMT & PAIN.001) ISO 20022 is the global standard for electronic data interchange between financial institutions. Bank Statement Parser supports canonical cash management messages (CAMT) and payment initiation instructions (PAIN.001) across all published versions (v2 through v12): CAMT.053 (Bank-to-Customer Statement): Detailed end-of-day electronic account statement reporting opening balance, booked entries, batches, and closing available balance. CAMT.052 (Bank-to-Customer Account Report): Intraday or interim statement providing real-time cash position updates. CAMT.054 (Bank-to-Customer Debit/Credit Notification): Granular transaction-level debit or credit notifications used for instant settlement verification. PAIN.001 (Customer Credit Transfer Initiation): Payment instructions parsed for two-way automated reconciliation against incoming CAMT or MT940 statement postings. 2. SWIFT Telecommunication Formats (MT940 & MT942) The parser provides native tag-based state machines for legacy SWIFT MT formats without reliance on regular expressions: SWIFT MT940: The electronic bank statement message containing field :20: (Transaction Reference), :25: (Account Identification), :28C: (Statement/Sequence Number), :60F: (Opening Balance), :61: (Statement Line), :86: (Information to Account Owner), and :62F: (Closing Balance). SWIFT MT942: Interim transaction report tracking intraday movements with field :34F: minimum amount specification. Structured Field :86: Sub-Tag Parser: Automated extraction of German SEPA, EPC, and international structured tags including /EREF/ (End-to-End Reference), /PREF/ (Payment Reference), /REMI/ (Remittance Info), /IBAN/, and /BIC/. 3. BAI2 Corporate Cash Management BAI2 is the North American standard created by the Bank Administration Institute for corporate account reporting. Bank Statement Parser deterministically parses the hierarchical record sequence: Record 01: File Header (sender, receiver, creation date/time, file ID). Record 02: Group Header (ultimate receiver, originator, group status). Record 03: Account Identifier (account number, currency, type codes, status amounts). Record 16: Transaction Detail (type code, amount, funds availability, bank reference). Record 88: Continuation Record (extended remittance and transaction descriptions). Records 49, 98, 99: Account, Group, and File Trailer checksums ensuring zero record omission. 4. Open Financial Exchange (OFX & QFX) Open Financial Exchange (OFX) and Quicken Financial Exchange (QFX) formats are widely used by retail and commercial banks across North America and Europe: OFX 1.02–1.6: SGML-based format with unclosed tags and legacy header key-value blocks. The parser repairs malformed SGML tag hierarchies without memory buffering overhead. OFX 2.x: Clean W3C XML documents containing BANKMSGSRSV1, STMTTRNRS, and STMTRS aggregates. Transaction Deduplication: Unique FITID (Financial Institution Transaction ID) hashing prevents duplicate booking entries","headings":["Supported Statement Formats & Specifications","1. ISO 20022 Messaging Standard (CAMT & PAIN.001)","2. SWIFT Telecommunication Formats (MT940 & MT942)","3. BAI2 Corporate Cash Management","4. Open Financial Exchange (OFX & QFX)","5. Delimited CSV Statements","6. Digital and Scanned PDF Statements","7. Analytical & Accounting Export Targets","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Getting Started: Install CLI & Native Python/Rust SDK","url":"/getting-started/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Installation & Guide Getting Started with Bank Statement Parser Installation instructions for Rust, Python, Docker, and CLI alongside step-by-step extraction quickstarts. Bank Statement Parser is an open-source, high-throughput financial document engine engineered in Rust with native Python bindings. Follow this guide to install the binary, process multi-format statement documents, or embed the SDK directly into your application stack. Rust (Cargo) Crate v0.0.28 Native library integration and standalone CLI compiled directly from source for maximum CPU throughput. cargo install bankstatementparser Python (Pip) PyPI v0.0.28 Pre-compiled PyO3 binary wheels for Linux, macOS (Apple Silicon and Intel), and Windows with optional Parquet extras. pip install bankstatementparser # Optional: Apache Parquet and Polars streaming support pip install \"bankstatementparser[parquet]\" pip install \"bankstatementparser[polars]\" Docker Engine OCI Container Minimal, non-root container image published on GitHub Container Registry for air-gapped CI/CD execution. docker pull ghcr.io/sebastienrousseau/bankstatementparser:latest Homebrew Tap macOS & Linux Pre-built standalone CLI binary distributed via official Homebrew tap for immediate terminal workstation access. brew install sebastienrousseau/tap/bankstatementparser 01 Command Line Interface (CLI) Extraction The standalone binary provides fast parsing for individual bank statement files across digital PDF, CSV, OFX, and QIF formats, emitting standard JSON, CSV, or ISO 20022 CAMT.053 XML: bash — cli quickstart # Extract statement PDF to standard JSON $bankstatementparser --input statement.pdf --output statement.json # Convert OFX banking file to CSV $bankstatementparser --input statement.ofx --output statement.csv --format csv # Transform PDF statement into ISO 20022 CAMT.053 XML $bankstatementparser --input statement.pdf --output statement.xml --format camt053 For high-volume transaction processing, enable multi-threaded batch ingestion to parse entire directories in parallel: bash — batch processing # Process all statements in a directory using 8 parallel worker threads $bankstatementparser --batch-dir ./statements/ --output-dir ./extracted_json/ --threads 8 02 Rust Library Integration Add the dependency to your Cargo.toml: Cargo.toml [dependencies] bankstatementparser = \"0.0.28\" Parse any statement into strongly-typed transaction structs with compile-time memory safety: main.rs use bankstatementparser::{Parser, StatementFormat}; use std::path::Path; fn main() -> Result<(), Box> { let parser = Parser::new(); let statement = parser.parse_file(Path::new(\"statement.pdf\"))?; println!(\"Account: {}\", statement.account_id); println!(\"Balance: {} {}\", statement.closing_balance, statement.currency); for tx in statement.transactions { println!(\"{} | {} | {}\", tx.date, tx.amount, tx.description); } Ok(()) } 03 Python SDK Integration Extract and validate transaction records within your Python data science and finance workflows with zero native compilation: python — main.py from bankstatementparser import ( BankStatementParser, CamtParser, Bai2Parser, ParquetStreamWriter, ) # 1. Parse statement into strongly-typed Transaction models parser = BankStatementParser() statement = parser.parse_file(\"statement.pdf\") # 2. Stream transactions directly to Apache Parquet with ParquetStreamWriter(\"transactions.parquet\") as writer: writer.write_batch(statement.transactions) print(f\"Extracted {len(statement.transactions)} transactions into Parquet.\") 04 Zero-Telemetry Execution Guarantees Every extraction pipeline executes exclusively within local process memory. Bank Statement Parser makes zero outbound network calls, transmits no analytical telemetry, and requires no external SaaS API keys: Air-gapped execution architecture: banking statements are tokenized and validated entirely within local memory with zero external telemetry.","headings":["Getting Started with Bank Statement Parser","Rust (Cargo)","Python (Pip)","Docker Engine","Homebrew Tap","Command Line Interface (CLI) Extraction","Rust Library Integration","Python SDK Integration","Zero-Telemetry Execution Guarantees","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Bank Statement Parser: High-Throughput Financial Engine","url":"/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Financial Document Engineering · Open SourceParse any bank statement in milliseconds.Zero cloud dependencies. Zero telemetry.An open-source, high-throughput financial document parsing engine engineered in Rust with native Python bindings. Converts CAMT, PAIN.001, MT940, MT942, OFX/QFX, BAI2, CSV, and PDF bank statements into validated JSON, Apache Parquet, and ISO 20022 transaction streams entirely on your own infrastructure.Install CLI & SDK Explore Supported FormatsDeterministic Rust CoreZero Cloud Dependencies100% Air-Gapped Privacy10,000+ Pages/Min Deterministic multi-threaded streaming throughput with zero lock contention.< 0.8 ms Latency Zero-copy tokenization designed for real-time ledger reconciliation.100% Zero Telemetry Runs fully air-gapped on your private VPC or local host with zero network calls.8 Banking Standards Unified extraction across CAMT (052/053/054), PAIN.001, MT940, MT942, OFX/QFX, BAI2, CSV, and PDF. Corporate Treasury AutomationAutomated Reconciliation for Modern TreasuryEliminate manual statement keying, error-prone spreadsheets, and expensive cloud OCR APIs. Normalize multi-bank statements directly into your general ledger, ERP, and treasury management workflows with sub-second turnaround.View Treasury Playbook ↗Engine ArchitectureEngineered for absolute accuracy.Industrial-grade financial parsing combining memory-safe Rust execution, native Python bindings, and dual Apache/MIT licensing.01Multi-Format Dialect EngineDeterministic state machines parse digital and scanned PDFs, irregular CSV layouts, SGML OFX/QFX, BAI2 cash management, and SWIFT MT940/MT942 messages without brittle regex or external cloud OCR.02Arithmetic Balance VerificationStrict mathematical balance validation ensures opening balance plus net credits and debits precisely equals closing balance to the penny before record emission.03ISO 20022 HarmonizationNormalize disparate bank statements directly into canonical ISO 20022 CAMT.053 XML envelopes, Apache Parquet streams, or strongly-typed JSON schemas ready for ERP, GL, and accounting ingestion.The Processing PipelineFrom raw bank document to validated ledger transactions.1IngestStream PDF bytes, CSV feeds, BAI2 files, or SWIFT MT940/MT942 messages into memory-safe zero-copy buffers.Sub-millisecond stream loading2TokenizeDeterministic lexical analysis identifies account metadata, booking dates, line items, and structured :86: sub-tags.Deterministic layout analysis3VerifyArithmetic balance reconciliation confirms credit/debit integrity, checks PDF forensics, and validates IBAN checksums.Mod-97 and balance proofs4EmitOutput strongly-typed JSON, streaming Apache Parquet, Plain-Text Ledgers (hledger, beancount), or ISO 20022 messages.Ready for ERP, Lakehouse & GL High-Performance PipelineDeterministic Execution at Enterprise ScaleEngineered for high-frequency financial platforms requiring bounded latency, zero-allocation loops, and strict ISO 20022 data models.View Architecture Blueprint ↗Developer QuickstartInstall via Cargo, Pip, or Homebrew in SecondsDeploy as a standalone CLI tool, embed as a high-assurance Rust crate in your microservices, or integrate into Python data pipelines with zero external runtime overhead.Full Documentation → API Reference bash — bankstatementparser# 1. Install standalone CLI or Python library$cargo install bankstatementparser$pip install bankstatementparser# 2. Parse statement with arithmetic balance verification$bankstatementparser --input statement.pdf --format json# 3. Deterministic output verification (< 0.8 ms){ \"status\": \"VALIDATED\", \"duration_ms\": 0.72, \"balance_proof\": \"EXACT_MATCH\" }Zero-Telemetry PrivacyYour financial data never leaves your infrastructure.Bank Statement Parser is 100% self-contained and operates entirely on your local machine, private VPC, or air-gapped on-premise servers. Zero analytics, zero telemetry, and zero outbound network calls—guaranteeing complete GDPR, GLBA, and banking confidentiality compliance.Read Security & Privacy Architecture ↓Clear AnswersFrequently Asked QuestionsDoes Bank Statement Parser send data to the cloud or external servers?No. Bank Statement Parser is 100% self-contained and operates entirely on your local machine or private cloud server. It contains zero analytics, zero telemetry, and zero outbound network calls, ensuring complete compliance with GDPR, HIPAA, GLBA, and banking confidentiality regulations.Which bank statement file formats are supported?Bank Statement Parser natively supports eight primary banking formats: ISO 20022 CAMT (camt.052, camt.053, camt.054), ISO 20022 PAIN.001 (Credit Transfer), SWIFT MT940 and MT942 messages, BAI2 (Bank Administration Institute), Open Financial Exchange (OFX 1.x/2.x and QFX), CSV files (with automatic delimiter and date detection), and digital/scanned PDF statements.How does the parser handle scanned or image-based statements?For digital and vector PDFs, the","headings":["Parse any bank statement in milliseconds.Zero cloud dependencies. Zero telemetry.","Automated Reconciliation for Modern Treasury","Engineered for absolute accuracy.","From raw bank document to validated ledger transactions.","Deterministic Execution at Enterprise Scale","Install via Cargo, Pip, or Homebrew in Seconds","Your financial data never leaves your infrastructure.","Frequently Asked Questions","Financial data is mission-critical.Your parsing pipeline should be instant.","Documentation & API","Solutions & Workflows","Trust & Legal","Multi-Format Dialect Engine","Arithmetic Balance Verification","ISO 20022 Harmonization","Ingest","Tokenize","Verify","Emit"]},{"title":"Made with Static Site Generator (SSG) | Web Platform","url":"/made-with-ssg/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Static Architecture Made with Static Site Generator (SSG) Why Bank Statement Parser documentation is statically generated for uncompromising security, WCAG AAA accessibility, and instant loading. This site is natively compiled using the high-performance Static Site Generator (SSG) written in Rust. Source of Truth: Content authored in Markdown (_posts/*.md) with Tera templates (_layouts/*.html). Compilation Speed: Full site generation in under 0.5 seconds with zero runtime JavaScript framework dependencies. Security: Strict Subresource Integrity (SRI) and Content Security Policy (CSP) headers.","headings":["Made with Static Site Generator (SSG)","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Zero-Telemetry Privacy Guarantee & Data Protection","url":"/privacy/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Trust & Governance Privacy Policy Our foundational commitment: zero tracking, zero analytics, zero external network requests, and complete local processing. Last updated: 1 September 2026 Bank Statement Parser is built on a strict zero-telemetry, zero-cookie architecture: No External Data Transmission: The Bank Statement Parser software operates entirely on the user's infrastructure. No document content, transaction records, or telemetry data are ever collected or transmitted. No Tracking Cookies: This documentation website does not use tracking cookies, analytics pixels, or third-party behavioral scripts. Data Protection Compliance: Fully compliant with GDPR, UK Data Protection Act 2018, and California Consumer Privacy Act (CCPA).","headings":["Privacy Policy","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Security Architecture: Air-Gapped & Memory-Safe Parsing","url":"/security/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Zero-Telemetry Model Security Architecture & Trust Guarantees Strict zero-telemetry guarantees, memory safety verification, and Sigstore-signed releases for compliance-critical pipelines. Financial statement data demands strict confidentiality, rigorous boundary isolation, and deterministic mathematical verification. Bank Statement Parser is architected from the foundation up to operate securely within air-gapped sovereign environments. 0 KB Telemetry Ingest 100% Safe Rust Core Cosign Sigstore Verified 01 Air-Gapped Sovereign Execution Model Bank Statement Parser binds no listening network ports and initiates no outbound TCP, UDP, or HTTP connections. All parsing, coordinate tokenization, and schema validation execute entirely within local process memory. Security Vector Implementation Standard Verification Audit Network Socket Access Zero outbound or listening sockets initialized Enforced via eBPF / seccomp system call filter Heap Memory Sanitization Zero sensitive statement data written to temporary disks Cleared immediately upon statement struct deallocation Third-Party SaaS Telemetry Zero third-party analytics or error tracking SDKs Static binary symbol inspection in CI Subresource Integrity SHA-384 cryptographic digests on all assets Enforced by W3C Content Security Policy (CSP) 02 Software Supply Chain & SBOM Provenance Every release artifact is cryptographically signed and independently auditable using SLSA Level 3 build provenance. A CycloneDX SBOM is published with every release to track transitive dependencies and vulnerability CVE states: bash — verify release provenance # Verify binary release signature using Sigstore Cosign $cosign verify-blob --certificate certificate.pem --signature bankstatementparser.sig bankstatementparser # Audit CycloneDX SBOM for dependency vulnerabilities $cyclonedx validate --input-file sbom.cdx.json 03 Cryptographic Isolation & Architecture Callout The system is purpose-built for financial institutions, hedge funds, sovereign banks, and regulated audit firms requiring verifiable isolation from public cloud APIs. Cryptographic integrity: every binary is Sigstore-signed, air-gapped, and accompanied by a CycloneDX SBOM.","headings":["Security Architecture & Trust Guarantees","Air-Gapped Sovereign Execution Model","Software Supply Chain & SBOM Provenance","Cryptographic Isolation & Architecture Callout","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Terms of Use & Dual Open-Source License Specifications","url":"/terms/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Legal Framework Terms of Use Clear, transparent terms governing the use of Bank Statement Parser open source software and enterprise documentation. Bank Statement Parser is distributed under the dual Apache License 2.0 and MIT License. You may use, modify, distribute, and integrate the software into commercial and open-source applications subject to the terms of either license.","headings":["Terms of Use","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Fintech Use Cases: Treasury & Reconciliation","url":"/use-cases/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Production Blueprints Enterprise Use Cases & Deployment Patterns High-throughput statement extraction powering corporate treasury automation, automated reconciliation, SME credit underwriting, and forensic audit screening. High-throughput statement extraction powers critical automated financial backends with zero cloud dependencies, air-gapped security, and deterministic precision. 99.8% Reconciliation STP Rate < 1 ms Underwriting Ingestion 100% Air-Gapped & Private 01 Corporate Treasury Automation Enterprise treasuries manage accounts across dozens of global banking partners (Citi, JPMorgan Chase, BNP Paribas, HSBC, Deutsche Bank). Each bank issues disparate statement formats with varying column orders, multi-currency balance headers, and non-standard narrative formatting. Bank Statement Parser unifies incoming statement feeds into canonical ISO 20022 camt.053 XML and JSON structures for real-time liquidity management. Operational Dimension Legacy Manual / OCR Workflow Bank Statement Parser Engine Processing Latency 30–45 minutes per multi-page statement < 5 milliseconds per statement Balance Verification Manual human calculation or unverified Mathematical proof (Opening + Transactions = Closing) Liquidity Visibility T+1 or T+2 retrospective reporting Continuous real-time intraday cash positioning Transcription Error Rate 2.1% – 3.5% human keying errors 0.00% deterministic spatial coordinate extraction bash — treasury batch ingestion pipeline # Batch-process multi-bank intraday statements with strict balance invariant check $bankstatementparser --batch-dir ./treasury/incoming/ --verify-balance --output-dir ./tms/ready/ Ingested: 128 PDF statements (Citi, HSBC, BNP, JPM) Transactions: 14,892 records parsed, normalized, and balanced Balance Proof: 128/128 passed [Opening + sum(credits) - sum(debits) == Closing] 02 Automated Bank Reconciliation Finance operations teams reconcile millions of bank transaction lines against general ledger (GL) entries every fiscal period. Irregular descriptions, truncated transaction codes, and disparate currency notations typically create enormous manual exception queues. Bank Statement Parser normalizes reference numbers, counterparty names, and structured remittance data to drive straight-through processing (STP) rates above 99.8%. Reconciliation Metric Generic PDF Scraper Bank Statement Parser Engine Payee Normalization Raw truncated strings with bank noise Clean entity names with stripped routing prefixes Reference Code Extraction Brittle regex frequently drops end tokens Coordinate-aware token bounding for full invoice codes STP Match Rate 60% – 75% (heavy manual review) 99.8% automated straight-through processing Multi-Currency Handling String-level assumptions ISO 4217 validation with decimal-exact precision python — high-throughput reconciliation stream from bankstatementparser import parse_statement # Ingest PDF statement directly into reconciliation pipeline statement = parse_statement(\"statements/october_operations.pdf\") for tx in statement.transactions: match = ledger.reconcile(reference=tx.reference, amount=tx.amount, date=tx.booking_date) assert statement.balanced, \"Statement balances must be mathematically proven\" 03 Fintech SME Credit Underwriting Modern commercial lenders and merchant cash advance platforms require rapid, accurate extraction of 12 to 24 months of applicant bank statements. The engine calculates net operating cash flows, recurring revenue, non-sufficient funds (NSF) events, and average daily balances in milliseconds—enabling instant credit decisions while applicants are still on the lender's application portal. Underwriting Parameter Human Document Review Bank Statement Parser Turnaround Time 24 to 72 hours per dossier < 500 milliseconds for 24 months Dossier Volume Sampled 3 months due to cost 12–24 months fully ingested and analyzed Document Tampering Detection Subjective visual check Mathematical invariant verification detects doctored numbers Cost per Application $25 – $50 in human labor $0.00 (Self-hosted native engine) rust — applicant dossier analysis use bankstatementparser::{Engine, Config}; let engine = Engine::new(Config::strict_validation()); let report = engine.parse_applicant_dossier(&[\"m1.pdf\", \"m2.pdf\", \"m3.pdf\"])?; println!(\"Net Cashflow: {}, Overdrafts: {}\", report.net_cashflow(), report.nsf_count()); 04 Forensic Audit & Sanctions Screening Forensic accountants and AML investigators examine thousands of historical bank statements during restructuring, corporate acquisitions, bankruptcy inquiries, and regulatory investigations. The parser's air-gapped, zero-network architecture guarantees that sensitive banking data never leaves local customer infrastructure or secure enclaves. Investigation Capability Cloud OCR Services Bank Statement Parser Data Sovereignty & Privacy Customer data sent to external cloud APIs 100% on-premises / air-gapped execution","headings":["Enterprise Use Cases & Deployment Patterns","Corporate Treasury Automation","Automated Bank Reconciliation","Fintech SME Credit Underwriting","Forensic Audit & Sanctions Screening","Enterprise Deployment Architecture","Documentation & API","Solutions & Workflows","Trust & Legal"]}]}
\ No newline at end of file
+{"entries":[{"title":"About Sebastien Rousseau | Bank Statement Parser Author","url":"/about/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Engineering & Leadership About Sebastien Rousseau Principal engineer building high-assurance, privacy-first financial infrastructure and cryptographic document tooling. Sebastien Rousseau Principal Financial Systems Architect · 19 Years in Production Banking Infrastructure Sebastien Rousseau has spent nearly two decades architecting, building, and securing high-volume transaction processing systems, institutional payment rails, and cryptographic protocols across global financial centres. Explore his work, publications, and advisory at sebastienrousseau.com. Engineering Pedigree & Domain Expertise With nineteen years of hands-on systems engineering across tier-1 investment banking, clearing gateways, and treasury infrastructures in London and international financial hubs, Sebastien specializes in high-throughput document tokenization, payment message harmonization, and post-quantum cryptographic security. 19 Years in Production Finance: Architecture of mission-critical systems across Corporate & Investment Banking (CIB), SWIFT payment gateways, SEPA clearing schemes, and real-time treasury ledger reconciliation. Author of Sovereign Open-Source Libraries: Creator of Bank Statement Parser, KyberLib (FIPS 203 ML-KEM module lattice-based key encapsulation), hsh, and ISO 20022 message engines with over 45.7M+ total package downloads. Standards & Protocol Conformance: Deep domain mastery of SWIFT Standards Release 2026 (MT940, MT942, field :86: sub-tags), ISO 20022 cash management (CAMT.052, CAMT.053, CAMT.054), payment initiation (PAIN.001), and North American BAI2 cash reporting. Zero-Telemetry Sovereign Architecture: Committed to building air-gapped, sovereign financial tools that execute locally with zero telemetry, preserving absolute banking confidentiality and data sovereignty. Personal Website & Keynotes: Visit sebastienrousseau.com for technical white papers, research monographs, and conference addresses on financial engineering and cryptographic assurance.","headings":["About Sebastien Rousseau","Sebastien Rousseau","Engineering Pedigree & Domain Expertise","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Accessibility Statement: WCAG 2.2 Level AAA Compliance","url":"/accessibility/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Inclusive Engineering Accessibility Statement Dedicated to achieving WCAG 2.2 Level AAA compliance across all digital documentation and interactive financial tooling. Bank Statement Parser is committed to digital accessibility, conforming strictly to WCAG 2.2 Level AAA guidelines: Contrast Ratios: Text colors achieve contrast ratios exceeding 17:1 in light mode and 18:1 in dark mode (well above the 7.0:1 AAA standard). Keyboard Navigation: Full keyboard operability with prominent focus indicators across all interactive elements. Screen Reader Support: Semantic HTML5 landmarks (nav, main, article, footer) and ARIA live regions.","headings":["Accessibility Statement","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"API Reference: Rust Crate & Python SDK Guide","url":"/api/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Developer Reference API & SDK Reference Complete programming interfaces, types, and error handling for Rust, Python, and CLI pipelines. Bank Statement Parser exposes deterministic, zero-allocation interfaces across both native Rust and PyO3-powered Python bindings. Every function executes strictly in-process with zero network telemetry, complete memory safety, and mathematical balance verification. 01 Rust Core Library Interface (lib.rs) Integrate the native Rust crate directly into your backend services for maximum CPU throughput, sub-millisecond document parsing, and zero heap duplication: rust — crate interface use bankstatementparser::{Parser, Statement, Transaction}; use std::path::Path; # Configure thread-safe parser with dialect auto-detection let parser = Parser::builder() .detect_dialects(true) .strict_balance_validation(true) .build(); # Parse byte stream directly from memory or disk let statement: Statement = parser.parse_file(Path::new(\"statement.pdf\"))?; # Access verified balance invariants and transactions println!(\"Account IBAN: {}\", statement.account_id); println!(\"Closing Balance: {} {}\", statement.closing_balance, statement.currency); for tx in statement.transactions { println!(\"{} | {:>10.2} | {}\", tx.date, tx.amount, tx.description); } Core data types provided by the native crate: Type / Symbol Signature Description Parser struct Parser Thread-safe parser engine supporting zero-copy byte slice and file ingestion. ParserBuilder struct ParserBuilder Configures parallel threads, balance invariants, and dialect heuristics. Statement struct Statement Normalized document model containing account ID, balances, currency, and transactions. Transaction struct Transaction Individual ledger item with booking date, value date, signed amount, and narrative. StatementFormat enum StatementFormat Output target variants: Json, Csv, Ofx, Qif, and Camt053. 02 Python SDK Interface (PyO3) Pre-compiled binary wheels for Linux, macOS, and Windows provide native Rust speed directly inside Python data science, pandas, and web application workflows: python — sdk quickstart from bankstatementparser import ( BankStatementParser, CamtParser, Bai2Parser, Mt940Parser, ParquetStreamWriter, reconcile_payments_and_statements, ) # 1. Parse statement into strongly-typed Transaction models parser = BankStatementParser() statement = parser.parse_file(\"statement.pdf\") # 2. Stream transactions directly to Apache Parquet with ParquetStreamWriter(\"transactions.parquet\") as writer: writer.write_batch(statement.transactions) # 3. Inspect verified balance proof print(f\"Closing Balance: {statement.closing_balance} {statement.currency}\") for tx in statement.transactions: print(f\"{tx.date} | {tx.amount:>10.2f} | {tx.description}\") Core parsers and analytical tools exported by the module: Symbol Type / Signature Purpose & Description BankStatementParser Class Primary document engine for PDF layout extraction, OCR fallback, and multi-format routing. Bai2Parser Class Dedicated state machine parser for BAI2 corporate cash management files. CamtParser Class High-speed XML parser for ISO 20022 CAMT.052, CAMT.053, and CAMT.054 statements. Pain001Parser Class Parser for ISO 20022 PAIN.001 customer credit transfer payment instructions. Mt940Parser / Mt942Parser Class SWIFT MT940 end-of-day and MT942 intraday tag-based message parsers. ParquetStreamWriter ContextManager Streams batches of transactions directly to Apache Parquet with Snappy/Zstd compression. reconcile_payments_and_statements Function Two-way automated reconciliation matching payment orders against statement postings. inspect_pdf_forensics Function Audits PDF statements for font discrepancies, metadata modifications, and tampering findings. analyze_statement_transactions Function Computes cash flow summaries, average daily balances, NSF fees, and recurring cadences. 03 Deterministic Error Handling & Diagnostics All processing pipelines isolate corrupt documents, unsupported regional dialects, and balance arithmetic discrepancies into typed error exceptions without panics or unhandled crashes: python — error handling from bankstatementparser import parse_statement from bankstatementparser.exceptions import ( BalanceMismatchError, UnsupportedDialectError, CorruptedDocumentError, ) try: statement = parse_statement(\"statement.pdf\") except BalanceMismatchError as exc: # Arithmetic discrepancy: opening + sum(credits) - sum(debits) != closing print(f\"Audit failed: expected delta {exc.expected_delta}, found {exc.actual_delta}\") except UnsupportedDialectError as exc: # Document signature unrecognized print(f\"Unsupported bank layout: {exc.detected_signature}\") except CorruptedDocumentError as exc: print(f\"Malformed file stream: {exc.details}\") 04 Zero-Telemetry Execution Guarantees Bank Statement Parser makes zero outbound network calls, transmits no analytical telemetry, and requires no external SaaS API keys.","headings":["API & SDK Reference","Rust Core Library Interface (lib.rs)","Python SDK Interface (PyO3)","Deterministic Error Handling & Diagnostics","Zero-Telemetry Execution Guarantees","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Architecture Blueprint: Deterministic Financial Parsing","url":"/architecture/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Engine Internals Architecture & Pipeline Specifications High-throughput tokenization, deterministic stream parsing, and ISO 20022 message synthesis with zero runtime allocations. Bank Statement Parser is architected around a deterministic, four-stage extraction and validation pipeline. Every stage executes in-process with zero outbound telemetry, zero heap allocation in the critical path, and strict mathematical balance verification before emitting ISO 20022 messages. Four-Stage Processing Pipeline 01 Stream Ingest Zero-copy memory mapping (mmap) of input statement bytes with instant magic-byte format detection (PDF, CSV, OFX, MT940, CAMT.053). < 0.2 ms Ingest Latency 02 Layout Tokenizer Spatial coordinate mapping and multi-column tabular boundary reconstruction, preserving text flow across complex multi-page financial tables. Zero Heap Allocations 03 Field Normalizer Canonical standardization of 24 global date dialects, ISO 4217 currencies, and mod-97 IBAN checksum verification. ISO 20022 BTC Mapping 04 Schema Validator Mathematical invariant verification (Opening + ΣCredits - ΣDebits = Closing) before emitting validated JSON or ISO 20022 XML. 100% Invariant Check Deterministic Pipeline Execution Trace The trace below demonstrates the sub-millisecond execution lifecycle of the four-stage engine processing a multi-page PDF statement into validated ISO 20022 CAMT.053 XML: pipeline-trace — bankstatementparser v0.0.2 $bankstatementparser --input statement.pdf --trace --format camt053 [0.00ms] [ingest] Zero-copy mmap statement.pdf (142,896 bytes) • Magic: %PDF-1.7 [0.18ms] [tokenizer] Spatial scan complete: 4 tables detected, 128 transaction rows clustered [0.45ms] [normalizer] Currency: GBP (ISO 4217) • Account: GB29BARC20000012345678 (mod-97 OK) [0.72ms] [validator] Opening: 14,250.00 | Credits: +8,300.50 | Debits: -3,120.25 | Closing: 19,430.25 [0.89ms] [validator] Invariant Check: 14,250.00 + 5,180.25 == 19,430.25 [PASS: Delta = 0.0000] [1.12ms] [synthesis] Emitted ISO 20022 camt.053.001.08 XML (42,810 bytes, schema valid) Status: 200 OK • Latency: 1.12ms • Memory: 1.4 MB • Telemetry: Zero Outbound Stage 1: Zero-Copy Stream Ingestion The ingestion subsystem interfaces directly with the host filesystem via memory-mapped files (mmap), bypassing kernel-to-userspace buffer duplication. Byte slices are analyzed using non-backtracking magic-byte sniffers: PDF Documents: Validates file header prefix %PDF- and reads the cross-reference table (xref) directly from the trailer offset. OFX Streams: Sniffs OFXHEADER SGML tags or XML prologue Result<(), Box> { let parser = Parser::new(); let statement = parser.parse_file(Path::new(\"statement.pdf\"))?; println!(\"Account: {}, Balance: {}\", statement.account_id,","headings":["Frequently Asked Questions","No matching questions found","Have a question not listed here?","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Supported Statement Formats: PDF, CSV, OFX, MT940, CAMT, BAI2","url":"/formats/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Specifications Matrix Supported Statement Formats & Specifications Deterministic multi-standard document ingestion with automated schema normalization across 8 financial formats, Parquet streaming, and ledger exports. Bank Statement Parser provides deterministic, zero-telemetry ingestion and mathematical balance verification across eight primary banking standards worldwide. Every format is normalized into strongly-typed Transaction and Statement models ready for ERP integration, corporate treasury, automated reconciliation, and OLAP analytics. Format Standard / Specification Extraction Method Validation Engine PDF Statements Adobe PDF 1.4–2.0 (Vector & Scanned) Spatial coordinate tokenizer & local OCR/vision fallback Mathematical balance verification & IBAN Mod-97 checksum CSV & Delimited RFC 4180 with Dialect Auto-Detect Statistical delimiter, decimal, and date header inference Column type inference & date format normalization BAI2 Cash Management Bank Administration Institute (BAI2) Deterministic record state machine (Records 01–99) Account status balance codes & record 88 continuation validation SWIFT MT940 SWIFT Standards Release 2026 (End-of-Day) Tag-based state machine parser (:20:, :25:, :60F:, :61:, :62F:) Opening/closing balance arithmetic (Fields 60F/62F) SWIFT MT942 SWIFT Standards Release 2026 (Interim) Intraday credit/debit transaction stream parser Field 34F floor limit & summary amount reconciliation ISO 20022 CAMT camt.052, camt.053, and camt.054 (v2–v12) Zero-copy XML streaming parser W3C XML Schema (XSD) & opening/closing balance proofs ISO 20022 PAIN.001 pain.001.001.03–11 (Customer Credit Transfer) Deterministic XML payment initiation parser Payment control sum & transaction count verification OFX & Quicken QFX Open Financial Exchange (1.02–2.2 SGML & XML) Robust tree parser with SGML unclosed-tag repair Standard banking DTD & transaction UID deduplication 1. ISO 20022 Messaging Standard (CAMT & PAIN.001) ISO 20022 is the global standard for electronic data interchange between financial institutions. Bank Statement Parser supports canonical cash management messages (CAMT) and payment initiation instructions (PAIN.001) across all published versions (v2 through v12): CAMT.053 (Bank-to-Customer Statement): Detailed end-of-day electronic account statement reporting opening balance, booked entries, batches, and closing available balance. CAMT.052 (Bank-to-Customer Account Report): Intraday or interim statement providing real-time cash position updates. CAMT.054 (Bank-to-Customer Debit/Credit Notification): Granular transaction-level debit or credit notifications used for instant settlement verification. PAIN.001 (Customer Credit Transfer Initiation): Payment instructions parsed for two-way automated reconciliation against incoming CAMT or MT940 statement postings. 2. SWIFT Telecommunication Formats (MT940 & MT942) The parser provides native tag-based state machines for legacy SWIFT MT formats without reliance on regular expressions: SWIFT MT940: The electronic bank statement message containing field :20: (Transaction Reference), :25: (Account Identification), :28C: (Statement/Sequence Number), :60F: (Opening Balance), :61: (Statement Line), :86: (Information to Account Owner), and :62F: (Closing Balance). SWIFT MT942: Interim transaction report tracking intraday movements with field :34F: minimum amount specification. Structured Field :86: Sub-Tag Parser: Automated extraction of German SEPA, EPC, and international structured tags including /EREF/ (End-to-End Reference), /PREF/ (Payment Reference), /REMI/ (Remittance Info), /IBAN/, and /BIC/. 3. BAI2 Corporate Cash Management BAI2 is the North American standard created by the Bank Administration Institute for corporate account reporting. Bank Statement Parser deterministically parses the hierarchical record sequence: Record 01: File Header (sender, receiver, creation date/time, file ID). Record 02: Group Header (ultimate receiver, originator, group status). Record 03: Account Identifier (account number, currency, type codes, status amounts). Record 16: Transaction Detail (type code, amount, funds availability, bank reference). Record 88: Continuation Record (extended remittance and transaction descriptions). Records 49, 98, 99: Account, Group, and File Trailer checksums ensuring zero record omission. 4. Open Financial Exchange (OFX & QFX) Open Financial Exchange (OFX) and Quicken Financial Exchange (QFX) formats are widely used by retail and commercial banks across North America and Europe: OFX 1.02–1.6: SGML-based format with unclosed tags and legacy header key-value blocks. The parser repairs malformed SGML tag hierarchies without memory buffering overhead. OFX 2.x: Clean W3C XML documents containing BANKMSGSRSV1, STMTTRNRS, and STMTRS aggregates. Transaction Deduplication: Unique FITID (Financial Institution Transaction ID) hashing prevents duplicate booking entries","headings":["Supported Statement Formats & Specifications","1. ISO 20022 Messaging Standard (CAMT & PAIN.001)","2. SWIFT Telecommunication Formats (MT940 & MT942)","3. BAI2 Corporate Cash Management","4. Open Financial Exchange (OFX & QFX)","5. Delimited CSV Statements","6. Digital and Scanned PDF Statements","7. Analytical & Accounting Export Targets","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Getting Started: Install CLI & Native Python/Rust SDK","url":"/getting-started/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Installation & Guide Getting Started with Bank Statement Parser Installation instructions for Rust, Python, Docker, and CLI alongside step-by-step extraction quickstarts. Bank Statement Parser is an open-source, high-throughput financial document engine engineered in Rust with native Python bindings. Follow this guide to install the binary, process multi-format statement documents, or embed the SDK directly into your application stack. Rust (Cargo) Crate v0.0.28 Native library integration and standalone CLI compiled directly from source for maximum CPU throughput. cargo install bankstatementparser Python (Pip) PyPI v0.0.28 Pre-compiled PyO3 binary wheels for Linux, macOS (Apple Silicon and Intel), and Windows with optional Parquet extras. pip install bankstatementparser # Optional: Apache Parquet and Polars streaming support pip install \"bankstatementparser[parquet]\" pip install \"bankstatementparser[polars]\" Docker Engine OCI Container Minimal, non-root container image published on GitHub Container Registry for air-gapped CI/CD execution. docker pull ghcr.io/sebastienrousseau/bankstatementparser:latest Homebrew Tap macOS & Linux Pre-built standalone CLI binary distributed via official Homebrew tap for immediate terminal workstation access. brew install sebastienrousseau/tap/bankstatementparser 01 Command Line Interface (CLI) Extraction The standalone binary provides fast parsing for individual bank statement files across digital PDF, CSV, OFX, and QIF formats, emitting standard JSON, CSV, or ISO 20022 CAMT.053 XML: bash — cli quickstart # Extract statement PDF to standard JSON $bankstatementparser --input statement.pdf --output statement.json # Convert OFX banking file to CSV $bankstatementparser --input statement.ofx --output statement.csv --format csv # Transform PDF statement into ISO 20022 CAMT.053 XML $bankstatementparser --input statement.pdf --output statement.xml --format camt053 For high-volume transaction processing, enable multi-threaded batch ingestion to parse entire directories in parallel: bash — batch processing # Process all statements in a directory using 8 parallel worker threads $bankstatementparser --batch-dir ./statements/ --output-dir ./extracted_json/ --threads 8 02 Rust Library Integration Add the dependency to your Cargo.toml: Cargo.toml [dependencies] bankstatementparser = \"0.0.28\" Parse any statement into strongly-typed transaction structs with compile-time memory safety: main.rs use bankstatementparser::{Parser, StatementFormat}; use std::path::Path; fn main() -> Result<(), Box> { let parser = Parser::new(); let statement = parser.parse_file(Path::new(\"statement.pdf\"))?; println!(\"Account: {}\", statement.account_id); println!(\"Balance: {} {}\", statement.closing_balance, statement.currency); for tx in statement.transactions { println!(\"{} | {} | {}\", tx.date, tx.amount, tx.description); } Ok(()) } 03 Python SDK Integration Extract and validate transaction records within your Python data science and finance workflows with zero native compilation: python — main.py from bankstatementparser import ( BankStatementParser, CamtParser, Bai2Parser, ParquetStreamWriter, ) # 1. Parse statement into strongly-typed Transaction models parser = BankStatementParser() statement = parser.parse_file(\"statement.pdf\") # 2. Stream transactions directly to Apache Parquet with ParquetStreamWriter(\"transactions.parquet\") as writer: writer.write_batch(statement.transactions) print(f\"Extracted {len(statement.transactions)} transactions into Parquet.\") 04 Zero-Telemetry Execution Guarantees Every extraction pipeline executes exclusively within local process memory. Bank Statement Parser makes zero outbound network calls, transmits no analytical telemetry, and requires no external SaaS API keys: Air-gapped execution architecture: banking statements are tokenized and validated entirely within local memory with zero external telemetry.","headings":["Getting Started with Bank Statement Parser","Rust (Cargo)","Python (Pip)","Docker Engine","Homebrew Tap","Command Line Interface (CLI) Extraction","Rust Library Integration","Python SDK Integration","Zero-Telemetry Execution Guarantees","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Bank Statement Parser: High-Throughput Financial Engine","url":"/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Financial Document Engineering · Open SourceParse any bank statement in milliseconds.Zero cloud dependencies. Zero telemetry.An open-source, high-throughput financial document parsing engine engineered in Rust with native Python bindings. Converts CAMT, PAIN.001, MT940, MT942, OFX/QFX, BAI2, CSV, and PDF bank statements into validated JSON, Apache Parquet, and ISO 20022 transaction streams entirely on your own infrastructure.Install CLI & SDK Explore Supported FormatsDeterministic Rust CoreZero Cloud Dependencies100% Air-Gapped Privacy10,000+ Pages/Min Deterministic multi-threaded streaming throughput with zero lock contention.< 0.8 ms Latency Zero-copy tokenization designed for real-time ledger reconciliation.100% Zero Telemetry Runs fully air-gapped on your private VPC or local host with zero network calls.8 Banking Standards Unified extraction across CAMT (052/053/054), PAIN.001, MT940, MT942, OFX/QFX, BAI2, CSV, and PDF. Corporate Treasury AutomationAutomated Reconciliation for Modern TreasuryEliminate manual statement keying, error-prone spreadsheets, and expensive cloud OCR APIs. Normalize multi-bank statements directly into your general ledger, ERP, and treasury management workflows with sub-second turnaround.View Treasury Playbook ↗Engine ArchitectureEngineered for absolute accuracy.Industrial-grade financial parsing combining memory-safe Rust execution, native Python bindings, and dual Apache/MIT licensing.01Multi-Format Dialect EngineDeterministic state machines parse digital and scanned PDFs, irregular CSV layouts, SGML OFX/QFX, BAI2 cash management, and SWIFT MT940/MT942 messages without brittle regex or external cloud OCR.02Arithmetic Balance VerificationStrict mathematical balance validation ensures opening balance plus net credits and debits precisely equals closing balance to the penny before record emission.03ISO 20022 HarmonizationNormalize disparate bank statements directly into canonical ISO 20022 CAMT.053 XML envelopes, Apache Parquet streams, or strongly-typed JSON schemas ready for ERP, GL, and accounting ingestion.The Processing PipelineFrom raw bank document to validated ledger transactions.1IngestStream PDF bytes, CSV feeds, BAI2 files, or SWIFT MT940/MT942 messages into memory-safe zero-copy buffers.Sub-millisecond stream loading2TokenizeDeterministic lexical analysis identifies account metadata, booking dates, line items, and structured :86: sub-tags.Deterministic layout analysis3VerifyArithmetic balance reconciliation confirms credit/debit integrity, checks PDF forensics, and validates IBAN checksums.Mod-97 and balance proofs4EmitOutput strongly-typed JSON, streaming Apache Parquet, Plain-Text Ledgers (hledger, beancount), or ISO 20022 messages.Ready for ERP, Lakehouse & GL High-Performance PipelineDeterministic Execution at Enterprise ScaleEngineered for high-frequency financial platforms requiring bounded latency, zero-allocation loops, and strict ISO 20022 data models.View Architecture Blueprint ↗Developer QuickstartInstall via Cargo, Pip, or Homebrew in SecondsDeploy as a standalone CLI tool, embed as a high-assurance Rust crate in your microservices, or integrate into Python data pipelines with zero external runtime overhead.Full Documentation → API Reference bash — bankstatementparser# 1. Install standalone CLI or Python library$cargo install bankstatementparser$pip install bankstatementparser# 2. Parse statement with arithmetic balance verification$bankstatementparser --input statement.pdf --format json# 3. Deterministic output verification (< 0.8 ms){ \"status\": \"VALIDATED\", \"duration_ms\": 0.72, \"balance_proof\": \"EXACT_MATCH\" }Zero-Telemetry PrivacyYour financial data never leaves your infrastructure.Bank Statement Parser is 100% self-contained and operates entirely on your local machine, private VPC, or air-gapped on-premise servers. Zero analytics, zero telemetry, and zero outbound network calls—guaranteeing complete GDPR, GLBA, and banking confidentiality compliance.Read Security & Privacy Architecture ↓Clear AnswersFrequently Asked QuestionsDoes Bank Statement Parser send data to the cloud or external servers?No. Bank Statement Parser is 100% self-contained and operates entirely on your local machine or private cloud server. It contains zero analytics, zero telemetry, and zero outbound network calls, ensuring complete compliance with GDPR, HIPAA, GLBA, and banking confidentiality regulations.Which bank statement file formats are supported?Bank Statement Parser natively supports eight primary banking formats: ISO 20022 CAMT (camt.052, camt.053, camt.054), ISO 20022 PAIN.001 (Credit Transfer), SWIFT MT940 and MT942 messages, BAI2 (Bank Administration Institute), Open Financial Exchange (OFX 1.x/2.x and QFX), CSV files (with automatic delimiter and date detection), and digital/scanned PDF statements.How does the parser handle scanned or image-based statements?For digital and vector PDFs, the","headings":["Parse any bank statement in milliseconds.Zero cloud dependencies. Zero telemetry.","Automated Reconciliation for Modern Treasury","Engineered for absolute accuracy.","From raw bank document to validated ledger transactions.","Deterministic Execution at Enterprise Scale","Install via Cargo, Pip, or Homebrew in Seconds","Your financial data never leaves your infrastructure.","Frequently Asked Questions","Financial data is mission-critical.Your parsing pipeline should be instant.","Documentation & API","Solutions & Workflows","Trust & Legal","Multi-Format Dialect Engine","Arithmetic Balance Verification","ISO 20022 Harmonization","Ingest","Tokenize","Verify","Emit"]},{"title":"Made with Static Site Generator (SSG) | Web Platform","url":"/made-with-ssg/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Static Architecture Made with Static Site Generator (SSG) Why Bank Statement Parser documentation is statically generated for uncompromising security, WCAG AAA accessibility, and instant loading. This site is natively compiled using the high-performance Static Site Generator (SSG) written in Rust. Source of Truth: Content authored in Markdown (_posts/*.md) with Tera templates (_layouts/*.html). Compilation Speed: Full site generation in under 0.5 seconds with zero runtime JavaScript framework dependencies. Security: Strict Subresource Integrity (SRI) and Content Security Policy (CSP) headers.","headings":["Made with Static Site Generator (SSG)","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Zero-Telemetry Privacy Guarantee & Data Protection","url":"/privacy/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Trust & Governance Privacy Policy Our foundational commitment: zero tracking, zero analytics, zero external network requests, and complete local processing. Last updated: 1 September 2026 Bank Statement Parser is built on a strict zero-telemetry, zero-cookie architecture: No External Data Transmission: The Bank Statement Parser software operates entirely on the user's infrastructure. No document content, transaction records, or telemetry data are ever collected or transmitted. No Tracking Cookies: This documentation website does not use tracking cookies, analytics pixels, or third-party behavioral scripts. Data Protection Compliance: Fully compliant with GDPR, UK Data Protection Act 2018, and California Consumer Privacy Act (CCPA).","headings":["Privacy Policy","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Security Architecture: Air-Gapped & Memory-Safe Parsing","url":"/security/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Zero-Telemetry Model Security Architecture & Trust Guarantees Strict zero-telemetry guarantees, memory safety verification, and Sigstore-signed releases for compliance-critical pipelines. Financial statement data demands strict confidentiality, rigorous boundary isolation, and deterministic mathematical verification. Bank Statement Parser is architected from the foundation up to operate securely within air-gapped sovereign environments. 0 KB Telemetry Ingest 100% Safe Rust Core Cosign Sigstore Verified 01 Air-Gapped Sovereign Execution Model Bank Statement Parser binds no listening network ports and initiates no outbound TCP, UDP, or HTTP connections. All parsing, coordinate tokenization, and schema validation execute entirely within local process memory. Security Vector Implementation Standard Verification Audit Network Socket Access Zero outbound or listening sockets initialized Enforced via eBPF / seccomp system call filter Heap Memory Sanitization Zero sensitive statement data written to temporary disks Cleared immediately upon statement struct deallocation Third-Party SaaS Telemetry Zero third-party analytics or error tracking SDKs Static binary symbol inspection in CI Subresource Integrity SHA-384 cryptographic digests on all assets Enforced by W3C Content Security Policy (CSP) 02 Software Supply Chain & SBOM Provenance Every release artifact is cryptographically signed and independently auditable using SLSA Level 3 build provenance. A CycloneDX SBOM is published with every release to track transitive dependencies and vulnerability CVE states: bash — verify release provenance # Verify binary release signature using Sigstore Cosign $cosign verify-blob --certificate certificate.pem --signature bankstatementparser.sig bankstatementparser # Audit CycloneDX SBOM for dependency vulnerabilities $cyclonedx validate --input-file sbom.cdx.json 03 Cryptographic Isolation & Architecture Callout The system is purpose-built for financial institutions, hedge funds, sovereign banks, and regulated audit firms requiring verifiable isolation from public cloud APIs. Cryptographic integrity: every binary is Sigstore-signed, air-gapped, and accompanied by a CycloneDX SBOM.","headings":["Security Architecture & Trust Guarantees","Air-Gapped Sovereign Execution Model","Software Supply Chain & SBOM Provenance","Cryptographic Isolation & Architecture Callout","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Terms of Use & Dual Open-Source License Specifications","url":"/terms/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Legal Framework Terms of Use Clear, transparent terms governing the use of Bank Statement Parser open source software and enterprise documentation. Bank Statement Parser is distributed under the dual Apache License 2.0 and MIT License. You may use, modify, distribute, and integrate the software into commercial and open-source applications subject to the terms of either license.","headings":["Terms of Use","Documentation & API","Solutions & Workflows","Trust & Legal"]},{"title":"Fintech Use Cases: Treasury & Reconciliation","url":"/use-cases/index.html","content":"Skip to main content Bank Statement Parser Menu Change colour theme System Production Blueprints Enterprise Use Cases & Deployment Patterns High-throughput statement extraction powering corporate treasury automation, automated reconciliation, SME credit underwriting, and forensic audit screening. High-throughput statement extraction powers critical automated financial backends with zero cloud dependencies, air-gapped security, and deterministic precision. 99.8% Reconciliation STP Rate < 1 ms Underwriting Ingestion 100% Air-Gapped & Private 01 Corporate Treasury Automation Enterprise treasuries manage accounts across dozens of global banking partners (Citi, JPMorgan Chase, BNP Paribas, HSBC, Deutsche Bank). Each bank issues disparate statement formats with varying column orders, multi-currency balance headers, and non-standard narrative formatting. Bank Statement Parser unifies incoming statement feeds into canonical ISO 20022 camt.053 XML and JSON structures for real-time liquidity management. Operational Dimension Legacy Manual / OCR Workflow Bank Statement Parser Engine Processing Latency 30–45 minutes per multi-page statement < 5 milliseconds per statement Balance Verification Manual human calculation or unverified Mathematical proof (Opening + Transactions = Closing) Liquidity Visibility T+1 or T+2 retrospective reporting Continuous real-time intraday cash positioning Transcription Error Rate 2.1% – 3.5% human keying errors 0.00% deterministic spatial coordinate extraction bash — treasury batch ingestion pipeline # Batch-process multi-bank intraday statements with strict balance invariant check $bankstatementparser --batch-dir ./treasury/incoming/ --verify-balance --output-dir ./tms/ready/ Ingested: 128 PDF statements (Citi, HSBC, BNP, JPM) Transactions: 14,892 records parsed, normalized, and balanced Balance Proof: 128/128 passed [Opening + sum(credits) - sum(debits) == Closing] 02 Automated Bank Reconciliation Finance operations teams reconcile millions of bank transaction lines against general ledger (GL) entries every fiscal period. Irregular descriptions, truncated transaction codes, and disparate currency notations typically create enormous manual exception queues. Bank Statement Parser normalizes reference numbers, counterparty names, and structured remittance data to drive straight-through processing (STP) rates above 99.8%. Reconciliation Metric Generic PDF Scraper Bank Statement Parser Engine Payee Normalization Raw truncated strings with bank noise Clean entity names with stripped routing prefixes Reference Code Extraction Brittle regex frequently drops end tokens Coordinate-aware token bounding for full invoice codes STP Match Rate 60% – 75% (heavy manual review) 99.8% automated straight-through processing Multi-Currency Handling String-level assumptions ISO 4217 validation with decimal-exact precision python — high-throughput reconciliation stream from bankstatementparser import parse_statement # Ingest PDF statement directly into reconciliation pipeline statement = parse_statement(\"statements/october_operations.pdf\") for tx in statement.transactions: match = ledger.reconcile(reference=tx.reference, amount=tx.amount, date=tx.booking_date) assert statement.balanced, \"Statement balances must be mathematically proven\" 03 Fintech SME Credit Underwriting Modern commercial lenders and merchant cash advance platforms require rapid, accurate extraction of 12 to 24 months of applicant bank statements. The engine calculates net operating cash flows, recurring revenue, non-sufficient funds (NSF) events, and average daily balances in milliseconds—enabling instant credit decisions while applicants are still on the lender's application portal. Underwriting Parameter Human Document Review Bank Statement Parser Turnaround Time 24 to 72 hours per dossier < 500 milliseconds for 24 months Dossier Volume Sampled 3 months due to cost 12–24 months fully ingested and analyzed Document Tampering Detection Subjective visual check Mathematical invariant verification detects doctored numbers Cost per Application $25 – $50 in human labor $0.00 (Self-hosted native engine) rust — applicant dossier analysis use bankstatementparser::{Engine, Config}; let engine = Engine::new(Config::strict_validation()); let report = engine.parse_applicant_dossier(&[\"m1.pdf\", \"m2.pdf\", \"m3.pdf\"])?; println!(\"Net Cashflow: {}, Overdrafts: {}\", report.net_cashflow(), report.nsf_count()); 04 Forensic Audit & Sanctions Screening Forensic accountants and AML investigators examine thousands of historical bank statements during restructuring, corporate acquisitions, bankruptcy inquiries, and regulatory investigations. The parser's air-gapped, zero-network architecture guarantees that sensitive banking data never leaves local customer infrastructure or secure enclaves. Investigation Capability Cloud OCR Services Bank Statement Parser Data Sovereignty & Privacy Customer data sent to external cloud APIs 100% on-premises / air-gapped execution","headings":["Enterprise Use Cases & Deployment Patterns","Corporate Treasury Automation","Automated Bank Reconciliation","Fintech SME Credit Underwriting","Forensic Audit & Sanctions Screening","Enterprise Deployment Architecture","Documentation & API","Solutions & Workflows","Trust & Legal"]}]}
\ No newline at end of file
diff --git a/scripts/post-build.py b/scripts/post-build.py
index a905510..189b4b8 100755
--- a/scripts/post-build.py
+++ b/scripts/post-build.py
@@ -8,6 +8,7 @@
import glob
import json
import os
+from pathlib import Path
import re
import shutil
@@ -147,10 +148,7 @@ def write_sitemap(output_dir: str, base_url: str) -> int:
# Remove unwanted news-sitemap.xml generated for non-news pages
for ns in glob.glob(f"{output_dir}/**/news-sitemap.xml", recursive=True):
- try:
- os.remove(ns)
- except OSError:
- pass
+ Path(ns).unlink(missing_ok=True)
return len(urls)
@@ -333,16 +331,13 @@ def update_manifests(output_dir: str) -> None:
for manifest_file in glob.glob(
f"{output_dir}/**/manifest.json", recursive=True
):
- try:
- with open(manifest_file, "r", encoding="utf-8") as handle:
- m_data = json.load(handle)
- m_data["theme_color"] = "#5b287b"
- if not m_data.get("background_color"):
- m_data["background_color"] = "#ffffff"
- with open(manifest_file, "w", encoding="utf-8") as handle:
- json.dump(m_data, handle, indent=2)
- except (OSError, json.JSONDecodeError, KeyError):
- pass
+ with open(manifest_file, "r", encoding="utf-8") as handle:
+ m_data = json.load(handle)
+ m_data["theme_color"] = "#5b287b"
+ if not m_data.get("background_color"):
+ m_data["background_color"] = "#ffffff"
+ with open(manifest_file, "w", encoding="utf-8") as handle:
+ json.dump(m_data, handle, indent=2)
def sync_to_docs(output_dir: str, docs_dir: str) -> None:
diff --git a/scripts/validate_spdx_headers.py b/scripts/validate_spdx_headers.py
index 1816718..0fc591d 100755
--- a/scripts/validate_spdx_headers.py
+++ b/scripts/validate_spdx_headers.py
@@ -22,10 +22,8 @@ def tracked() -> list[str]:
return [f for f in out.splitlines() if SOURCE.search(f) and not EXEMPT.search(f)]
def missing(path: str) -> list[str]:
- try:
- with open(path, encoding="utf-8", errors="replace") as h:
- head = "".join(h.readline() for _ in range(10))
- except Exception: return []
+ with open(path, encoding="utf-8", errors="replace") as h:
+ head = "".join(h.readline() for _ in range(10))
return [t.rstrip(":") for t in TAGS if t not in head]
def main() -> int:
diff --git a/tests/test_frontmatter.py b/tests/test_frontmatter.py
index bac0e84..9b56553 100644
--- a/tests/test_frontmatter.py
+++ b/tests/test_frontmatter.py
@@ -87,3 +87,22 @@ def test_classify_url_excludes_utility_routes():
def test_encode_raw_amp_preserves_script_blocks():
html = '