From 7826043c6981082c61c3aa712711baa06ce59ca9 Mon Sep 17 00:00:00 2001 From: Sebastien Rousseau Date: Sun, 1 Nov 2026 18:13:34 +0000 Subject: [PATCH 1/6] build: build the site with ssg 0.0.72 The release workflow, devcontainer, AGENTS.md and DEVELOPMENT.md pinned ssg 0.0.69 and the README badge named 0.0.63, while the workspace rule is to build every ssg site with the latest release. Move every pin to 0.0.72, the current release on crates.io. A local build with 0.0.72 passes make verify with no template changes. Assisted-by: Claude Code:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 Signed-off-by: Sebastien Rousseau --- .devcontainer/devcontainer.json | 2 +- .github/workflows/release.yml | 2 +- AGENTS.md | 2 +- DEVELOPMENT.md | 2 +- README.md | 6 +++--- supply-chain/README.md | 2 +- 6 files changed, 8 insertions(+), 8 deletions(-) diff --git a/.devcontainer/devcontainer.json b/.devcontainer/devcontainer.json index b5d5fe8..823bc6c 100644 --- a/.devcontainer/devcontainer.json +++ b/.devcontainer/devcontainer.json @@ -9,5 +9,5 @@ "version": "24" } }, - "postCreateCommand": "cargo install ssg --locked --version 0.0.69 && make verify" + "postCreateCommand": "cargo install ssg --locked --version 0.0.72 && make verify" } diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 4445f26..748affe 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -17,7 +17,7 @@ permissions: contents: read env: - SSG_VERSION: 0.0.69 + SSG_VERSION: 0.0.72 jobs: release: diff --git a/AGENTS.md b/AGENTS.md index 3ec44fb..aa82d7b 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -2,7 +2,7 @@ - Read `README.md`, `DEVELOPMENT.md`, and `/Users/seb/Code/REPO-STANDARD.md` before modifying this repository. -- Use locally installed `ssg` 0.0.69 for every build. +- Use locally installed `ssg` 0.0.72 for every build. - Never edit generated output in `public/` directly. Source of truth is `_posts/` for content and `_layouts/` for Tera templates. - Preserve WCAG 2.2 AAA accessibility, zero findings, and 100 Lighthouse diff --git a/DEVELOPMENT.md b/DEVELOPMENT.md index 1e628de..b47c458 100644 --- a/DEVELOPMENT.md +++ b/DEVELOPMENT.md @@ -2,7 +2,7 @@ ## Prerequisites -- Rust and `ssg` 0.0.69: `cargo install ssg --locked --version 0.0.69` +- Rust and `ssg` 0.0.72: `cargo install ssg --locked --version 0.0.72` - Python 3.12 or later - Node.js 24 or later diff --git a/README.md b/README.md index 302ad07..1ee6dbd 100644 --- a/README.md +++ b/README.md @@ -16,7 +16,7 @@ Docs OpenSSF Scorecard License: Apache-2.0 OR MIT - Built with Rust SSG + Built with Rust SSG

--- @@ -118,7 +118,7 @@ The `bankstatementparser` suite provides end-to-end tooling for financial docume | Area | Capability | Status | | :--- | :--- | :--- | -| Static Generation | Rust SSG v0.0.63 + Tera template compilation | Active | +| Static Generation | Rust SSG v0.0.72 + Tera template compilation | Active | | Accessibility | 100% WCAG 2.2 Level AAA compliance (>= 7.0:1 contrast) | Verified | | Content Security | Strict Content-Security-Policy (CSP) with zero inline scripts | Enforced | | Integrity | SHA-384 Subresource Integrity (SRI) on all scripts and styles | Active | @@ -143,7 +143,7 @@ Audit and regression suites are executed continuously on every commit: | Scenario | Result | Environment | | :--- | ---: | :--- | -| Full Site Compilation (20 Pages) | < 2.0s | Rust `ssg` 0.0.63, 32 plugins | +| Full Site Compilation (20 Pages) | < 2.0s | Rust `ssg` 0.0.72, 32 plugins | | Worst Light Mode Contrast Ratio | 17.79:1 | WCAG 2.2 AAA (Threshold >= 7.0:1) | | Worst Dark Mode Contrast Ratio | 8.08:1 | WCAG 2.2 AAA (Threshold >= 7.0:1) | | Lighthouse Performance / A11y | 100 / 100 | Clean ECMAScript, zero heavy runtimes | diff --git a/supply-chain/README.md b/supply-chain/README.md index 73785c9..f0fb4d2 100644 --- a/supply-chain/README.md +++ b/supply-chain/README.md @@ -8,7 +8,7 @@ This directory documents the supply-chain controls enforced across `bankstatemen * **GitHub Actions**: Every workflow under [`.github/workflows/`](../.github/workflows/) pins third-party actions to full 40-character commit SHAs. * **Python Verification Environment**: Pinned with SHA-256 hashes in [`requirements/ci.txt`](../requirements/ci.txt). -* **Static Site Generator**: Deterministically built with `ssg --locked --version 0.0.69`. +* **Static Site Generator**: Deterministically built with `ssg --locked --version 0.0.72`. --- From 64718874c89be3d886df28be12c38038b31599ff Mon Sep 17 00:00:00 2001 From: Sebastien Rousseau Date: Sun, 1 Nov 2026 18:14:09 +0000 Subject: [PATCH 2/6] refactor: keep Python under complexity ceilings run_regression (cyclomatic 22, cognitive 38) and validate_readme's validate (cyclomatic 13, cognitive 19) were over the workspace ceilings, and nothing stopped new offenders. Split both into small checks with identical output: an old-versus-new run on good and mutated inputs gave byte-identical reports. tests/test_complexity.py now fails CI when any function in scripts/, tests/ or audit/ exceeds cyclomatic 10, Halstead difficulty 30 or 60 lines, or a file exceeds 500 lines. It failed on the two functions before the split and passes after. No baseline is needed: there are no remaining offenders (complexipy also reports cognitive <= 15). requirements/test.txt is regenerated with uv pip compile --generate-hashes to add radon 6.0.1 and its two dependencies, colorama 0.4.6 and mando 0.7.1; existing pins are unchanged and pip-audit reports no known vulnerabilities. Assisted-by: Claude Code:claude-opus-5-5 radon complexipy pip-audit Co-Authored-By: Claude Opus 5.5 Signed-off-by: Sebastien Rousseau --- requirements/test.in | 1 + requirements/test.txt | 20 +++++++++- scripts/regression-test.py | 82 +++++++++++++++++++++++--------------- scripts/validate_readme.py | 22 +++++----- tests/test_complexity.py | 46 +++++++++++++++++++++ 5 files changed, 127 insertions(+), 44 deletions(-) create mode 100644 tests/test_complexity.py diff --git a/requirements/test.in b/requirements/test.in index b62d7fb..0052645 100644 --- a/requirements/test.in +++ b/requirements/test.in @@ -1,3 +1,4 @@ # Property-based tests for the build scripts (tests/). pytest==9.1.1 hypothesis==6.170.8 +radon==6.0.1 diff --git a/requirements/test.txt b/requirements/test.txt index 68d9a9a..bc45b2f 100644 --- a/requirements/test.txt +++ b/requirements/test.txt @@ -1,5 +1,9 @@ # This file was autogenerated by uv via the following command: # uv pip compile --generate-hashes --python-version 3.12 requirements/test.in -o requirements/test.txt +colorama==0.4.6 \ + --hash=sha256:08695f5cb7ed6e0531a20572697297273c47b8cae5a63ffc6d6ed5c201be6e44 \ + --hash=sha256:4f1d9991f5acc0ca119f9d443620b77f9d6b33703e51011c16baf57afb285fc6 + # via radon hypothesis==6.170.8 \ --hash=sha256:00ef96c93eb67ffcb474da90fdf003c6a2f53b2f2d9c1d3f7096e51f2b2a81be \ --hash=sha256:00ef96c93eb67ffcb474da90fdf003c6a2f53b2f2d9c1d3f7096e51f2b2a81be \ @@ -167,11 +171,15 @@ hypothesis==6.170.8 \ --hash=sha256:fbed3d33ed19488e9d1eba5bf72101bd791c73b1155fc6af3f269a4dc107ddf8 \ --hash=sha256:fe3175068fe99decd7258cd38bb5421b11c3d4d1dd2ea992df54ce1198735c07 \ --hash=sha256:fe3175068fe99decd7258cd38bb5421b11c3d4d1dd2ea992df54ce1198735c07 - # via -r test.in + # via -r requirements/test.in iniconfig==2.3.0 \ --hash=sha256:c76315c77db068650d49c5b56314774a7804df16fee4402c1f19d6d15d8c4730 \ --hash=sha256:f631c04d2c48c52b84d0d0549c99ff3859c98df65b3101406327ecc7d53fbf12 # via pytest +mando==0.7.1 \ + --hash=sha256:18baa999b4b613faefb00eac4efadcf14f510b59b924b66e08289aa1de8c3500 \ + --hash=sha256:26ef1d70928b6057ee3ca12583d73c63e05c49de8972d620c278a7b206581a8a + # via radon packaging==26.3 \ --hash=sha256:94edc256424af38762eb31306eed28beb9f0efc50a8837492c9d6fd6004aed79 \ --hash=sha256:d7193f7c8e4e93f444fde0262bf90af30e16fa0ad0ad44cb553c87339b23cd1c @@ -187,7 +195,15 @@ pygments==2.21.0 \ pytest==9.1.1 \ --hash=sha256:1088fbde8f2b49d95a549a195707afa7a76a3ce9bcadc26b6d71f0ffda5fe313 \ --hash=sha256:37a86b45efb9a47a61a36449063e8e18d0cab3161329fc099eb21783169c4f0c - # via -r test.in + # via -r requirements/test.in +radon==6.0.1 \ + --hash=sha256:632cc032364a6f8bb1010a2f6a12d0f14bc7e5ede76585ef29dc0cecf4cd8859 \ + --hash=sha256:d1ac0053943a893878940fedc8b19ace70386fc9c9bf0a09229a44125ebf45b5 + # via -r requirements/test.in +six==1.17.0 \ + --hash=sha256:4721f391ed90541fddacab5acf947aa0d3dc7d27b2e1e8eda2be8970586c3274 \ + --hash=sha256:ff70335d468e7eb6ec65b95b99d3a2836546063f63acc5171de367e834932a81 + # via mando sortedcontainers==2.4.0 \ --hash=sha256:25caa5a06cc30b6b83d11423433f65d1f9d76c4c6a0c90e3379eaa43b9bfdb88 \ --hash=sha256:a163dcaede0f1c021485e957a39245190e74249897e2ae4b2aa38595db237ee0 diff --git a/scripts/regression-test.py b/scripts/regression-test.py index 786beca..bae05ba 100755 --- a/scripts/regression-test.py +++ b/scripts/regression-test.py @@ -3,54 +3,72 @@ # SPDX-License-Identifier: Apache-2.0 OR MIT import os, sys -def run_regression(): - repo_path = os.path.dirname(os.path.dirname(os.path.abspath(__file__))) - docs_dir = os.path.join(repo_path, "docs") - errors = [] +REQUIRED_FILES = ["robots.txt", "sitemap.xml", "manifest.json", "rss.xml", "search-index.json", "CNAME", "llms.txt", "llms-full.txt", "sw.js", "humans.txt"] +SECURITY_FIELDS = ("Contact:", "Expires:", "Canonical: https://bankstatementparser.com/.well-known/security.txt") +CLIENT_FEATURES = {"applyTheme": "Theme Switcher", "searchModal": "Search Engine", "navbarToggle": "Mobile Nav toggle"} + + +def read_text(path): + with open(path, "r", encoding="utf-8", errors="ignore") as fp: + return fp.read() - print(f"Running Automated Regression Test on: {repo_path}") - required_files = ["robots.txt", "sitemap.xml", "manifest.json", "rss.xml", "search-index.json", "CNAME", "llms.txt", "llms-full.txt", "sw.js", "humans.txt"] - for rf in required_files: +def check_required_files(docs_dir): + errors = [] + for rf in REQUIRED_FILES: fpath = os.path.join(docs_dir, rf) if not os.path.isfile(fpath) or os.path.getsize(fpath) == 0: errors.append(f"Missing or empty essential file: {rf}") + return errors + +def check_security_txt(docs_dir): # RFC 9116: the disclosure file must be served, complete, at both the # standard location and the legacy root path. + errors = [] for rel in (".well-known/security.txt", "security.txt"): fpath = os.path.join(docs_dir, rel) - txt = "" - if os.path.isfile(fpath): - with open(fpath, encoding="utf-8") as fp: - txt = fp.read() - for field in ("Contact:", "Expires:", "Canonical: https://bankstatementparser.com/.well-known/security.txt"): - if field not in txt: - errors.append(f"{rel} is missing '{field}'") - - js_files = [f for f in os.listdir(docs_dir) if (f.startswith("main.") and f.endswith(".js")) or f == "main.js"] + txt = read_text(fpath) if os.path.isfile(fpath) else "" + errors += [f"{rel} is missing '{field}'" for field in SECURITY_FIELDS if field not in txt] + return errors + + +def is_client_script(name): + return (name.startswith("main.") and name.endswith(".js")) or name == "main.js" + + +def check_client_script(docs_dir): + js_files = [f for f in os.listdir(docs_dir) if is_client_script(f)] if not js_files: - errors.append("Missing client engine script (main.js)") - else: - for js_f in js_files: - with open(os.path.join(docs_dir, js_f), "r", errors="ignore") as fp: - txt = fp.read() - if "applyTheme" not in txt: - errors.append(f"{js_f} is missing Theme Switcher") - if "searchModal" not in txt: - errors.append(f"{js_f} is missing Search Engine") - if "navbarToggle" not in txt: - errors.append(f"{js_f} is missing Mobile Nav toggle") - - html_files = glob_html(docs_dir) - for hf in html_files: + return ["Missing client engine script (main.js)"] + errors = [] + for js_f in js_files: + txt = read_text(os.path.join(docs_dir, js_f)) + errors += [f"{js_f} is missing {label}" for marker, label in CLIENT_FEATURES.items() if marker not in txt] + return errors + + +def check_html_pages(docs_dir): + errors = [] + for hf in glob_html(docs_dir): rel = os.path.relpath(hf, docs_dir) - with open(hf, "r", errors="ignore") as fp: - c = fp.read() + c = read_text(hf) if ' list[str]: + issues = [] + if "{{" in text or "}}" in text: issues.append("unresolved template variables remain") + return issues + [f"missing structure: {m}" for m in REQUIRED_STRUCTURE if m not in text] + +def heading_issues(required: list[str], actual: list[str]) -> list[str]: + if actual == required: return [] + missing = [f"missing heading: ## {h}" for h in required if h not in actual] + return missing + [f"unexpected heading: ## {h}" for h in actual if h not in required] + def validate(path: Path) -> list[str]: if not path.is_file(): return [f"{path} is missing"] text = path.read_text(encoding="utf-8") - issues = [] - if "{{" in text or "}}" in text: issues.append("unresolved template variables remain") - for m in REQUIRED_STRUCTURE: - if m not in text: issues.append(f"missing structure: {m}") + issues = structure_issues(text) match = re.search(r"

([^<]+)

", text) if not match: return issues + ["missing h1"] project = match.group(1).strip() required = [h.format(project=project) for h in REQUIRED_HEADINGS] actual = re.findall(r"(?m)^## ([^\n]+)$", text) - if actual != required: - for h in required: - if h not in actual: issues.append(f"missing heading: ## {h}") - for h in actual: - if h not in required: issues.append(f"unexpected heading: ## {h}") - return issues + return issues + heading_issues(required, actual) if __name__ == "__main__": p = Path(sys.argv[1]) if len(sys.argv) > 1 else Path("README.md") diff --git a/tests/test_complexity.py b/tests/test_complexity.py new file mode 100644 index 0000000..f8e3afb --- /dev/null +++ b/tests/test_complexity.py @@ -0,0 +1,46 @@ +# SPDX-FileCopyrightText: 2024-2026 Sebastien Rousseau +# SPDX-License-Identifier: Apache-2.0 OR MIT +"""Complexity ceilings for every Python function in the repository. + +Ceilings per function: cyclomatic 10, Halstead difficulty 30, 60 lines; +500 lines per file. No baseline of offenders exists: every function is +within the ceilings, and this test keeps it that way. +""" + +import ast +from pathlib import Path + +import pytest +from radon.complexity import cc_visit +from radon.metrics import h_visit + +ROOT = Path(__file__).resolve().parents[1] +SOURCES = sorted( + p for d in ("scripts", "tests", "audit") for p in (ROOT / d).glob("*.py") +) +MAX_CYCLOMATIC = 10 +MAX_HALSTEAD_DIFFICULTY = 30 +MAX_FUNCTION_LINES = 60 +MAX_FILE_LINES = 500 + + +def function_lengths(source: str) -> dict[str, int]: + return { + node.name: node.end_lineno - node.lineno + 1 + for node in ast.walk(ast.parse(source)) + if isinstance(node, (ast.FunctionDef, ast.AsyncFunctionDef)) + } + + +@pytest.mark.parametrize("path", SOURCES, ids=lambda p: str(p.relative_to(ROOT))) +def test_functions_stay_within_complexity_ceilings(path): + source = path.read_text(encoding="utf-8") + assert len(source.splitlines()) <= MAX_FILE_LINES + over = [f"{b.name}: cyclomatic {b.complexity}" for b in cc_visit(source) if b.complexity > MAX_CYCLOMATIC] + over += [ + f"{name}: Halstead difficulty {rep.difficulty:.1f}" + for name, rep in h_visit(source).functions + if rep.difficulty > MAX_HALSTEAD_DIFFICULTY + ] + over += [f"{name}: {n} lines" for name, n in function_lengths(source).items() if n > MAX_FUNCTION_LINES] + assert not over, over From 4aefcd9d443855387c951430cd10aef61dba5797 Mon Sep 17 00:00:00 2001 From: Sebastien Rousseau Date: Sun, 1 Nov 2026 18:14:16 +0000 Subject: [PATCH 3/6] fix: format release title and checksums scripts/release_notes.py titled releases "BSP v0.0.9" and fenced the checksums without the "SHA-256 of every asset attached to this release:" line or a text fence. The portfolio release format requires " " with no leading v, which is why v0.0.8's title had to be corrected by hand after publishing. Title releases "bankstatementparser.com 0.0.9" and build the checksum block in its own function. tests/test_release_notes.py covers both; the title test fails against the previous script. Fixes: 2ff6124a Assisted-by: Claude Code:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 Signed-off-by: Sebastien Rousseau --- scripts/release_notes.py | 10 +++++++--- tests/test_release_notes.py | 24 ++++++++++++++++++++++++ 2 files changed, 31 insertions(+), 3 deletions(-) create mode 100644 tests/test_release_notes.py diff --git a/scripts/release_notes.py b/scripts/release_notes.py index cab88b5..1a4f3df 100755 --- a/scripts/release_notes.py +++ b/scripts/release_notes.py @@ -15,7 +15,7 @@ BULLET = re.compile(r"^\* \*\*[^*]+\*\*: \S") def fail(msg: str) -> None: raise SystemExit(f"[release-notes] {msg}") -def title(tag: str) -> str: return f"BSP {tag}" +def title(tag: str) -> str: return f"{PROJECT} {tag.removeprefix('v')}" def highlights(tag: str) -> str: path = NOTES / f"{tag}.md" @@ -53,17 +53,21 @@ def first_release_changes(tag: str) -> str: ] return "## What's Changed\n" + "\n".join(lines) + "\n" +def checksums(sums: str) -> str: + intro = "SHA-256 of every asset attached to this release:" + return f"## Checksums\n\n{intro}\n\n```text\n{sums.strip()}\n```\n" + def compose(tag: str, sums: str) -> str: prev = previous_tag(tag) body = generated(tag, prev) cl = re.search(r"^\*\*Full Changelog\*\*: \S+$", body, re.MULTILINE) - if not cl: fail(f"missing Full Changelog in generated notes") + if not cl: fail("missing Full Changelog in generated notes") sections = body[:cl.start()].strip() if not sections.startswith("## What's Changed"): if sections: fail(f"unexpected generated notes: {sections[:60]!r}") sections = first_release_changes(tag).strip() parts = [highlights(tag), sections + "\n"] - if sums.strip(): parts.append("## Checksums\n\n```\n" + sums.strip() + "\n```\n") + if sums.strip(): parts.append(checksums(sums)) parts.append(cl.group(0) + "\n") return "\n".join(parts) diff --git a/tests/test_release_notes.py b/tests/test_release_notes.py new file mode 100644 index 0000000..8ad0392 --- /dev/null +++ b/tests/test_release_notes.py @@ -0,0 +1,24 @@ +# SPDX-FileCopyrightText: 2024-2026 Sebastien Rousseau +# SPDX-License-Identifier: Apache-2.0 OR MIT +"""Release title and checksum block follow the portfolio release format.""" + +import importlib.util +from pathlib import Path + +_SPEC = importlib.util.spec_from_file_location( + "release_notes", Path(__file__).resolve().parents[1] / "scripts" / "release_notes.py" +) +rn = importlib.util.module_from_spec(_SPEC) +_SPEC.loader.exec_module(rn) + + +def test_title_is_project_name_and_bare_version(): + assert rn.title("v0.0.9") == "bankstatementparser.com 0.0.9" + + +def test_checksums_block_is_introduced_and_fenced_as_text(): + sums = f"{'a' * 64} bankstatementparser-site-v0.0.9.tar.gz\n" + assert rn.checksums(sums) == ( + "## Checksums\n\nSHA-256 of every asset attached to this release:\n\n" + f"```text\n{sums.strip()}\n```\n" + ) From ec07e2cf023f5db7db3a28ed6c79b35872957b7c Mon Sep 17 00:00:00 2001 From: Sebastien Rousseau Date: Sun, 1 Nov 2026 18:15:21 +0000 Subject: [PATCH 4/6] fix: link pages by their canonical URLs Every page canonicalises to its trailing-slash URL (/formats/), but the header, footer, home page, FAQs and 404 page linked to the /formats/index.html duplicate: 20 links on every page from the header and footer, 28 on the home page. Search Console reports such duplicates as "Alternative page with proper canonical tag", and crawl budget goes on URLs that are never indexed. Link to the canonical URL instead. tests/test_site_urls.py (next commit) fails on all 20 built pages before this change and passes after. Fixes: 13c47db4 Assisted-by: Claude Code:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 Signed-off-by: Sebastien Rousseau --- _layouts/footer.html | 30 +++++++++++++++--------------- _layouts/header.html | 10 +++++----- _posts/404.md | 2 +- _posts/faqs.md | 6 +++--- _posts/index.md | 16 ++++++++-------- 5 files changed, 32 insertions(+), 32 deletions(-) diff --git a/_layouts/footer.html b/_layouts/footer.html index 7f73171..6c3e005 100644 --- a/_layouts/footer.html +++ b/_layouts/footer.html @@ -13,31 +13,31 @@ diff --git a/_layouts/header.html b/_layouts/header.html index 1d783ab..7becd87 100644 --- a/_layouts/header.html +++ b/_layouts/header.html @@ -13,11 +13,11 @@ diff --git a/_posts/404.md b/_posts/404.md index b0579fe..7cc21af 100644 --- a/_posts/404.md +++ b/_posts/404.md @@ -23,5 +23,5 @@ The requested financial documentation page does not exist or has been moved.
Return to Homepage → -View Documentation +View Documentation
diff --git a/_posts/faqs.md b/_posts/faqs.md index a395e3c..45d9c68 100644 --- a/_posts/faqs.md +++ b/_posts/faqs.md @@ -262,7 +262,7 @@ lead: "Comprehensive guidance covering specifications, zero-telemetry local exec
-

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

+

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

@@ -280,9 +280,9 @@ lead: "Comprehensive guidance covering specifications, zero-telemetry local exec

Have a question not listed here?

Our core engineering team and community stewards are available to assist. Explore the documentation guides, join our GitHub community discussions, or contact our solutions engineers directly.

-Getting Started Guide +Getting Started Guide GitHub Discussions -Contact Support +Contact Support
diff --git a/_posts/index.md b/_posts/index.md index 0ff0d56..885b565 100644 --- a/_posts/index.md +++ b/_posts/index.md @@ -22,8 +22,8 @@ banner_alt: "Bank Statement Parser — High-Throughput Financial Document Parsin

Parse 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 Formats +Install CLI & SDK +Explore Supported Formats
  • Deterministic Rust Core
    • @@ -66,7 +66,7 @@ banner_alt: "Bank Statement Parser — High-Throughput Financial Document Parsin

    Corporate Treasury Automation

    Automated Reconciliation for Modern Treasury

    Eliminate 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 +View Treasury Playbook @@ -141,7 +141,7 @@ banner_alt: "Bank Statement Parser — High-Throughput Financial Document Parsin

    High-Performance Pipeline

    Deterministic Execution at Enterprise Scale

    Engineered for high-frequency financial platforms requiring bounded latency, zero-allocation loops, and strict ISO 20022 data models.

    -View Architecture Blueprint +View Architecture Blueprint @@ -153,8 +153,8 @@ banner_alt: "Bank Statement Parser — High-Throughput Financial Document Parsin

    Install via Cargo, Pip, or Homebrew in Seconds

    Deploy 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 +Full Documentation → +API Reference
    @@ -184,7 +184,7 @@ banner_alt: "Bank Statement Parser — High-Throughput Financial Document Parsin

    Your 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 +Read Security & Privacy Architecture @@ -223,7 +223,7 @@ banner_alt: "Bank Statement Parser — High-Throughput Financial Document Parsin

    Get started in minutes with the Rust CLI or Python package across Linux, macOS, and Windows.

    -Install Bank Statement Parser +Install Bank Statement Parser
    From 8dd2b99cee2ef3a117c00bc74d65a4475fd85e7d Mon Sep 17 00:00:00 2001 From: Sebastien Rousseau Date: Sun, 1 Nov 2026 18:16:17 +0000 Subject: [PATCH 5/6] fix: list only canonical pages and redirect moves Search Console reports 483 URLs not indexed against 33 indexed. All sampled 5xx and 404 URLs come from the 28-locale site that dae79d26 replaced on 2026-07-28 (its sitemap listed 364 URLs, canonicals in /page/index.html form), plus English pages it renamed: /faq/ is now /faqs/ and /contribute/ is /contributing/. Today they all return 404, and the current sitemap lists only the 18 live pages. Three generator changes in scripts/post-build.py: - The sitemap keeps a page only if it is not noindex, not a redirect and is its own canonical, so no future page can advertise a URL Google will refuse. Before, any built HTML file was listed. - config/redirects.json maps moved URLs to their new home; a meta-refresh page with a canonical to the target is written at each old URL, since GitHub Pages cannot send HTTP redirects. - The 404 page is also published at /404.html, the path GitHub Pages serves for any missing URL; it was only at /404/, so dead links got GitHub's generic page. Removed translations stay 404: the site has been English-only since dae79d26 and has no same-language page to send them to. tests/test_site_urls.py checks the deployed docs/ tree: every sitemap URL maps to a built, indexable, self-canonical page; every same-site URL in a page resolves; internal links avoid index.html; each redirect lands on a built page; /404.html exists. It failed 23 cases on the previous build and passes on this one. A unit test shows the old collector listing noindex, redirect and non-canonical pages. Fixes: dae79d26 Assisted-by: Claude Code:claude-opus-5-5 html-validate Co-Authored-By: Claude Opus 5.5 Signed-off-by: Sebastien Rousseau --- config/redirects.json | 4 ++ scripts/post-build.py | 88 +++++++++++++++++++++++++++++++++++++-- tests/test_frontmatter.py | 20 ++++++++- tests/test_site_urls.py | 84 +++++++++++++++++++++++++++++++++++++ 4 files changed, 192 insertions(+), 4 deletions(-) create mode 100644 config/redirects.json create mode 100644 tests/test_site_urls.py diff --git a/config/redirects.json b/config/redirects.json new file mode 100644 index 0000000..3c1a4e1 --- /dev/null +++ b/config/redirects.json @@ -0,0 +1,4 @@ +{ + "/contribute/": "/contributing/", + "/faq/": "/faqs/" +} diff --git a/scripts/post-build.py b/scripts/post-build.py index 308fd60..1e4bc19 100755 --- a/scripts/post-build.py +++ b/scripts/post-build.py @@ -34,6 +34,39 @@ "made-with-ssg", } KEEP_DOCS = {"adr", "ARCHITECTURE.md", "packaging.md", "releases", ".git"} +REDIRECTS_FILE = os.path.join("config", "redirects.json") +CANONICAL_RE = re.compile(r']*>') +OG_IMAGE_RE = re.compile(r' + + + + +Page moved | Bank Statement Parser + +{csp} + + + + + + + + + + + +
    +

    This page has moved

    +

    Continue to {target}.

    +
    + + +""" UNWRAP_TAGS = (" tuple[str, str, str] | None: return (f"{base_url}/{norm_path}", "0.7", "weekly") +def is_indexable(html_path: str, loc: str) -> bool: + """True when a page is neither noindex nor a redirect and is its own canonical.""" + with open(html_path, encoding="utf-8") as handle: + html = handle.read() + canonical = CANONICAL_RE.search(html) + if NOT_INDEXABLE_RE.search(html) or not canonical: + return False + return canonical.group(1) == loc + + def collect_sitemap_urls( output_dir: str, base_url: str ) -> list[tuple[str, str, str]]: @@ -112,9 +155,12 @@ def collect_sitemap_urls( for fname in files: if not fname.endswith(".html"): continue - rel_path = os.path.relpath(os.path.join(root, fname), output_dir) + html_path = os.path.join(root, fname) + rel_path = os.path.relpath(html_path, output_dir) entry = classify_url(base_url, rel_path) - if entry and entry[0] not in seen: + if not entry or entry[0] in seen: + continue + if is_indexable(html_path, entry[0]): seen.add(entry[0]) urls.append(entry) urls.sort(key=lambda item: item[0]) @@ -341,6 +387,40 @@ def update_manifests(output_dir: str) -> None: json.dump(m_data, handle, indent=2) +def write_redirects(output_dir: str, base_url: str) -> int: + """Write a meta-refresh page at each moved URL listed in REDIRECTS_FILE. + + GitHub Pages cannot send HTTP redirects; Google treats an immediate meta + refresh as a permanent redirect and the canonical names the new URL. + """ + with open(REDIRECTS_FILE, encoding="utf-8") as handle: + redirects = json.load(handle) + # Reuse the home page's CSP and share image so every page stays uniform. + home = Path(output_dir, "index.html").read_text(encoding="utf-8") + shared = { + "csp": CSP_META_RE.search(home).group(0), + "image": OG_IMAGE_RE.search(home).group(1), + } + for source, target in redirects.items(): + page_dir = os.path.join(output_dir, source.strip("/")) + if os.path.exists(os.path.join(page_dir, "index.html")): + raise SystemExit(f"redirect source {source} is a built page") + os.makedirs(page_dir, exist_ok=True) + Path(page_dir, "index.html").write_text( + REDIRECT_PAGE.format(target=f"{base_url}{target}", **shared), + encoding="utf-8", + ) + return len(redirects) + + +def write_root_404(output_dir: str) -> None: + """Publish the 404 page at /404.html, the path GitHub Pages serves.""" + shutil.copy2( + os.path.join(output_dir, "404", "index.html"), + os.path.join(output_dir, "404.html"), + ) + + def sync_to_docs(output_dir: str, docs_dir: str) -> None: """Synchronize compiled output_dir into docs_dir while preserving KEEP_DOCS.""" os.makedirs(docs_dir, exist_ok=True) @@ -366,9 +446,11 @@ def sync_to_docs(output_dir: str, docs_dir: str) -> None: def post_build(output_dir: str = "public", docs_dir: str = "docs") -> None: """Run all post-build optimizations on output_dir and sync once to docs_dir.""" - url_count = write_sitemap(output_dir, BASE_URL) write_static_meta(output_dir, BASE_URL) + write_redirects(output_dir, BASE_URL) + write_root_404(output_dir) process_html_files(output_dir, BASE_URL) + url_count = write_sitemap(output_dir, BASE_URL) update_manifests(output_dir) sync_to_docs(output_dir, docs_dir) print(f"Post-build optimization complete ({url_count} URLs).") diff --git a/tests/test_frontmatter.py b/tests/test_frontmatter.py index 9b56553..3b25147 100644 --- a/tests/test_frontmatter.py +++ b/tests/test_frontmatter.py @@ -90,7 +90,9 @@ def test_encode_raw_amp_preserves_script_blocks(): def test_write_sitemap_removes_news_sitemaps_and_update_manifests_normalizes(tmp_path): - (tmp_path / "index.html").write_text("", encoding="utf-8") + (tmp_path / "index.html").write_text( + '', encoding="utf-8" + ) news_sm = tmp_path / "news-sitemap.xml" news_sm.write_text("", encoding="utf-8") manifest = tmp_path / "manifest.json" @@ -106,3 +108,19 @@ def test_write_sitemap_removes_news_sitemaps_and_update_manifests_normalizes(tmp assert data["theme_color"] == "#5b287b" assert data["background_color"] == "#ffffff" + + +def test_sitemap_skips_noindex_redirect_and_non_canonical_pages(tmp_path): + base = "https://bankstatementparser.com" + pages = { + "kept": f'', + "noindex": f'', + "moved": f'', + "alias": f'', + "bare": "", + } + for name, html in pages.items(): + (tmp_path / name).mkdir() + (tmp_path / name / "index.html").write_text(html, encoding="utf-8") + urls = [loc for loc, _, _ in pb.collect_sitemap_urls(str(tmp_path), base)] + assert urls == [f"{base}/kept/"] diff --git a/tests/test_site_urls.py b/tests/test_site_urls.py new file mode 100644 index 0000000..d9d2370 --- /dev/null +++ b/tests/test_site_urls.py @@ -0,0 +1,84 @@ +# SPDX-FileCopyrightText: 2024-2026 Sebastien Rousseau +# SPDX-License-Identifier: Apache-2.0 OR MIT +"""URL integrity of the deployed docs/ tree, as search engines see it. + +Every sitemap entry must be a built, indexable page whose canonical is the +entry itself; internal links must use canonical URLs; every same-site URL a +page advertises must resolve; and pages that moved must redirect. +""" + +import json +import re +from pathlib import Path + +import pytest + +ROOT = Path(__file__).resolve().parents[1] +DOCS = ROOT / "docs" +BASE = "https://bankstatementparser.com" +REDIRECTS = json.loads((ROOT / "config" / "redirects.json").read_text()) + +LOC = re.compile(r"([^<]+)") +CANONICAL = re.compile(r' list[Path]: + return sorted(p for p in DOCS.rglob("*.html") if "/." not in str(p)) + + +def target_file(url: str) -> Path: + path = url.removeprefix(BASE).lstrip("/") + candidate = DOCS / path + return candidate / "index.html" if candidate.is_dir() or not path else candidate + + +def sitemap_locs() -> list[str]: + return LOC.findall((DOCS / "sitemap.xml").read_text(encoding="utf-8")) + + +def test_sitemap_is_not_empty(): + assert sitemap_locs() + + +@pytest.mark.parametrize("loc", sitemap_locs()) +def test_sitemap_lists_only_indexable_canonical_pages(loc): + page = target_file(loc) + assert page.is_file(), f"{loc} has no built file" + html = page.read_text(encoding="utf-8") + assert not NOINDEX.search(html), f"{loc} is noindex" + assert CANONICAL.search(html).group(1) == loc, f"{loc} canonical differs" + assert not REFRESH.search(html), f"{loc} is a redirect" + + +@pytest.mark.parametrize("page", html_pages(), ids=lambda p: str(p.relative_to(DOCS))) +def test_same_site_urls_resolve_to_built_files(page): + html = page.read_text(encoding="utf-8") + missing = {u for u in SITE_URL.findall(html) if not target_file(u).is_file()} + assert not missing, f"dangling same-site URLs: {sorted(missing)}" + + +@pytest.mark.parametrize("page", html_pages(), ids=lambda p: str(p.relative_to(DOCS))) +def test_internal_links_use_canonical_urls(page): + html = page.read_text(encoding="utf-8") + links = re.findall(r']*href="([^"]*)"', html) + assert not [u for u in links if u.endswith("index.html")] + + +@pytest.mark.parametrize("source", sorted(REDIRECTS)) +def test_moved_pages_redirect_to_a_built_page(source): + stub = target_file(source) + assert stub.is_file(), f"{source} has no redirect page" + html = stub.read_text(encoding="utf-8") + target = BASE + REDIRECTS[source] + assert REFRESH.search(html).group(1) == target + assert CANONICAL.search(html).group(1) == target + assert target_file(target).is_file() + assert target not in REDIRECTS + + +def test_root_404_page_is_served_and_noindex(): + html = (DOCS / "404.html").read_text(encoding="utf-8") + assert NOINDEX.search(html) From 40632030d5810fbd7cb6568ef64ba00bdc5fc7a1 Mon Sep 17 00:00:00 2001 From: Sebastien Rousseau Date: Sun, 1 Nov 2026 18:17:35 +0000 Subject: [PATCH 6/6] chore: release v0.0.9 Bump VERSION, CITATION.cff and the service worker cache name to 0.0.9, add the 0.0.9 CHANGELOG section and release Highlights, and add the missing 0.0.8 and new 0.0.9 entries to the site changelog. docs/ and public/ are regenerated with make build (ssg 0.0.72 and scripts/post-build.py), not edited by hand. Beyond version strings and build dates, the output changes are: canonical internal links on every page, the /faq/ and /contribute/ redirect pages, /404.html, and ssg 0.0.72's serialisation of the per-page rss.xml files. sitemap.xml still lists the same 18 URLs. Assisted-by: Claude Code:claude-opus-5-5 Co-Authored-By: Claude Opus 5.5 Signed-off-by: Sebastien Rousseau --- CHANGELOG.md | 26 +++++++++++++ CITATION.cff | 4 +- VERSION | 2 +- _posts/changelog.md | 10 +++++ docs/.meta/changelog.meta.json | 4 +- docs/.ssg-cache/depgraph.json | 2 +- docs/.ssg-plugin-cache.json | 40 +++++++++---------- docs/.well-known/mcp.json | 2 +- docs/404.html | 64 +++++++++++++++++++++++++++++++ docs/404/index.html | 4 +- docs/404/rss.xml | 2 +- docs/about/index.html | 4 +- docs/about/rss.xml | 2 +- docs/accessibility/index.html | 4 +- docs/accessibility/rss.xml | 2 +- docs/api/agents/index.json | 2 +- docs/api/agents/posts.json | 2 +- docs/api/index.html | 4 +- docs/api/rss.xml | 2 +- docs/architecture/index.html | 4 +- docs/architecture/rss.xml | 2 +- docs/benchmarks/index.html | 4 +- docs/benchmarks/rss.xml | 2 +- docs/changelog/index.html | 4 +- docs/changelog/rss.xml | 2 +- docs/contact/index.html | 4 +- docs/contact/rss.xml | 2 +- docs/contribute/index.html | 25 ++++++++++++ docs/contributing/index.html | 4 +- docs/contributing/rss.xml | 2 +- docs/faq/index.html | 25 ++++++++++++ docs/faqs/index.html | 4 +- docs/faqs/rss.xml | 2 +- docs/formats/index.html | 4 +- docs/formats/rss.xml | 2 +- docs/getting-started/index.html | 4 +- docs/getting-started/rss.xml | 2 +- docs/index.html | 4 +- docs/llms-full.txt | 32 ++++++++++------ docs/made-with-ssg/index.html | 4 +- docs/made-with-ssg/rss.xml | 2 +- docs/offline/index.html | 4 +- docs/offline/rss.xml | 2 +- docs/privacy/index.html | 4 +- docs/privacy/rss.xml | 2 +- docs/releases/v0.0.9.md | 5 +++ docs/sbom.cdx.json | 12 +++--- docs/search-index.json | 2 +- docs/security/index.html | 4 +- docs/security/rss.xml | 2 +- docs/sitemap.xml | 36 ++++++++--------- docs/sw.js | 2 +- docs/terms/index.html | 4 +- docs/terms/rss.xml | 2 +- docs/thanks/index.html | 4 +- docs/thanks/rss.xml | 2 +- docs/use-cases/index.html | 4 +- docs/use-cases/rss.xml | 2 +- public/.meta/changelog.meta.json | 4 +- public/.ssg-cache/depgraph.json | 2 +- public/.ssg-plugin-cache.json | 40 +++++++++---------- public/.well-known/mcp.json | 2 +- public/404.html | 64 +++++++++++++++++++++++++++++++ public/404/index.html | 4 +- public/404/rss.xml | 2 +- public/about/index.html | 4 +- public/about/rss.xml | 2 +- public/accessibility/index.html | 4 +- public/accessibility/rss.xml | 2 +- public/api/agents/index.json | 2 +- public/api/agents/posts.json | 2 +- public/api/index.html | 4 +- public/api/rss.xml | 2 +- public/architecture/index.html | 4 +- public/architecture/rss.xml | 2 +- public/benchmarks/index.html | 4 +- public/benchmarks/rss.xml | 2 +- public/changelog/index.html | 4 +- public/changelog/rss.xml | 2 +- public/contact/index.html | 4 +- public/contact/rss.xml | 2 +- public/contribute/index.html | 25 ++++++++++++ public/contributing/index.html | 4 +- public/contributing/rss.xml | 2 +- public/faq/index.html | 25 ++++++++++++ public/faqs/index.html | 4 +- public/faqs/rss.xml | 2 +- public/formats/index.html | 4 +- public/formats/rss.xml | 2 +- public/getting-started/index.html | 4 +- public/getting-started/rss.xml | 2 +- public/index.html | 4 +- public/llms-full.txt | 32 ++++++++++------ public/made-with-ssg/index.html | 4 +- public/made-with-ssg/rss.xml | 2 +- public/offline/index.html | 4 +- public/offline/rss.xml | 2 +- public/privacy/index.html | 4 +- public/privacy/rss.xml | 2 +- public/sbom.cdx.json | 12 +++--- public/search-index.json | 2 +- public/security/index.html | 4 +- public/security/rss.xml | 2 +- public/sitemap.xml | 36 ++++++++--------- public/sw.js | 2 +- public/terms/index.html | 4 +- public/terms/rss.xml | 2 +- public/thanks/index.html | 4 +- public/thanks/rss.xml | 2 +- public/use-cases/index.html | 4 +- public/use-cases/rss.xml | 2 +- sw.js | 2 +- 112 files changed, 537 insertions(+), 248 deletions(-) create mode 100644 docs/404.html create mode 100644 docs/contribute/index.html create mode 100644 docs/faq/index.html create mode 100644 docs/releases/v0.0.9.md create mode 100644 public/404.html create mode 100644 public/contribute/index.html create mode 100644 public/faq/index.html diff --git a/CHANGELOG.md b/CHANGELOG.md index c32888c..a5a777a 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -6,6 +6,32 @@ All notable changes to this website are documented here. The format follows ## [Unreleased] +## [0.0.9] - 2026-11-01 + +### Fixed + +- Linked every page by its canonical URL (`/formats/`, not + `/formats/index.html`) in `_layouts/header.html`, `_layouts/footer.html` + and `_posts/`, so internal links no longer point at duplicates of + canonical pages. +- Made `scripts/post-build.py` list only indexable pages in `sitemap.xml`: + a page that is `noindex`, a redirect, or not its own canonical is left + out. +- Redirected the moved pages `/faq/` and `/contribute/` to `/faqs/` and + `/contributing/` with meta-refresh pages generated from + `config/redirects.json`, and published the 404 page at `/404.html`, + the path GitHub Pages serves for a missing URL. +- Titled releases `bankstatementparser.com ` and introduced the + checksum block in `scripts/release_notes.py`, per the release format. + +### Changed + +- Built the site with `ssg` 0.0.72 locally, in the release workflow and in + the devcontainer. +- Split `scripts/regression-test.py` and `scripts/validate_readme.py` into + small checks, and added `tests/test_complexity.py` so CI holds every + Python function to the complexity ceilings. + ## [0.0.8] - 2026-10-31 ### Fixed diff --git a/CITATION.cff b/CITATION.cff index 3d4eed9..3572590 100644 --- a/CITATION.cff +++ b/CITATION.cff @@ -2,8 +2,8 @@ cff-version: 1.2.0 message: "If you reference the Bank Statement Parser documentation, please cite it as below." title: "bankstatementparser.com: Fast, secure financial statement parsing documentation" type: software -version: 0.0.8 -date-released: 2026-10-31 +version: 0.0.9 +date-released: 2026-11-01 authors: - family-names: Rousseau given-names: Sebastien diff --git a/VERSION b/VERSION index d169b2f..c5d54ec 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.0.8 +0.0.9 diff --git a/_posts/changelog.md b/_posts/changelog.md index 974c0c7..66fc46e 100644 --- a/_posts/changelog.md +++ b/_posts/changelog.md @@ -21,6 +21,16 @@ lead: "Deterministic versioning history, security audits, and functional enhance All notable changes to **Bank Statement Parser** are documented in this file following strict Semantic Versioning. +## [0.0.9] - 2026-11-01 +### Fixed +- Linked pages by their canonical URLs, kept non-indexable pages out of `sitemap.xml`, redirected `/faq/` and `/contribute/` to `/faqs/` and `/contributing/`, and served the 404 page for missing URLs. +### Changed +- Built the site with `ssg` 0.0.72. + +## [0.0.8] - 2026-10-31 +### Fixed +- Restored the search widget assets and styles, and aligned the footer on a four-column grid. + ## [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`. diff --git a/docs/.meta/changelog.meta.json b/docs/.meta/changelog.meta.json index 1e51af4..bbdc20a 100644 --- a/docs/.meta/changelog.meta.json +++ b/docs/.meta/changelog.meta.json @@ -13,8 +13,8 @@ "logo": "https://cloudcdn.pro/bankstatementparser/v1/logos/bankstatementparser.svg", "name": "Bank Statement Parser", "permalink": "https://bankstatementparser.com/changelog/", - "reading_time": 1, + "reading_time": 2, "short_name": "bankstatementparser", "title": "Changelog & Semantic Version History: Release Notes", - "word_count": 371 + "word_count": 437 } \ No newline at end of file diff --git a/docs/.ssg-cache/depgraph.json b/docs/.ssg-cache/depgraph.json index cfc0a23..3b2b76b 100644 --- a/docs/.ssg-cache/depgraph.json +++ b/docs/.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":"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 +{"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":"2b508ed2118dcc9a1bbc3cb10f3a47f83f451bc92673bb57847b3f493af9810a","_layouts/header.html":"57779e3e7552597c6b285f9f2a9f1089a7b4263e23dcf2ebee54ad147b57c411","_layouts/index.html":"1011c37cf9a923ebe4e8e777d90c0211db95bf789d245e0f5a44c31f1f8e15b0","_layouts/offline.html":"17192422da99d87d32ba2d575456e0d304ae9f52e3d7b9f7813e65c23e8919c6","_layouts/page.html":"cde4e4ff156a75852c740d4ac98d8cc80b30fe9c267344bc27279241aaa9c3df","_posts/404.md":"78b457b95ce23818d9c7a295cb21502c510864b9278f23929c3d8cfced447796","_posts/about.md":"13194ab6c87d444d2a8e647b0a248eb8194a616e2667f464516d50edb5baa37a","_posts/accessibility.md":"b791c5a0c010756d7c94af08a3ad2a1942cf78b7297ae96bc6946fa9a5b3997b","_posts/api.md":"d56ea4a068ab062bcdb074e90a76375c9d246ce07510e9ad3dea43b0d716980d","_posts/architecture.md":"bee13f62aebbea7f768c1ccae09402bc9d3720cbbe2704828305f0c57e182164","_posts/benchmarks.md":"4c838792a32c88f09a74300063c6ade24ab89c9f55b6ab415589fdfa59431bee","_posts/changelog.md":"7c8ca16dfc1ad3c58a080d6f53eb250d03931ac455385b6b4f67b92fd3b616be","_posts/contact.md":"d1e789015df47d82215f1e6b483242c785509e84cc57760070537fd1692e0f39","_posts/contributing.md":"b85023503834959a5b6160ba1121708d2c5e0cfe2eb2641a9042891b834daabc","_posts/faqs.md":"9d57037632b02e9315b31c6da3ef890e4a7c084e76b51a44304f017d742295d6","_posts/formats.md":"1ea659800531779d2ec03c4a1cd37b4d687fff0afe8d46023bb1f12c4f4148fe","_posts/getting-started.md":"7f6af1169dc7c0fcc294d68a06e1d93e7b33b40fdaf7368e9a4e9f6a1e9174ae","_posts/index.md":"bdf93e711dfa2af73e87782fbc5667e541721b809572210799fac6e497b0bd06","_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/docs/.ssg-plugin-cache.json b/docs/.ssg-plugin-cache.json index e8ff198..bbccee0 100644 --- a/docs/.ssg-plugin-cache.json +++ b/docs/.ssg-plugin-cache.json @@ -1,22 +1,22 @@ { - "public/404/index.html": 7259093385209876975, - "public/about/index.html": 12949456559420021308, - "public/accessibility/index.html": 5713522207449664177, - "public/api/index.html": 11397964784032987743, - "public/architecture/index.html": 6915802455650842912, - "public/benchmarks/index.html": 2021468413810795982, - "public/changelog/index.html": 18270345507824245213, - "public/contact/index.html": 10355855238041785199, - "public/contributing/index.html": 12520701021490290597, - "public/faqs/index.html": 11983471379327613372, - "public/formats/index.html": 1052158472452750897, - "public/getting-started/index.html": 1865910444430193385, - "public/index.html": 2989877783651903019, - "public/made-with-ssg/index.html": 2015761978985704885, - "public/offline/index.html": 6011093415955977822, - "public/privacy/index.html": 11811363588876036415, - "public/security/index.html": 14062708075236181358, - "public/terms/index.html": 141328437173614684, - "public/thanks/index.html": 8068784464901517319, - "public/use-cases/index.html": 15672533206450610668 + "public/404/index.html": 13575494870109021346, + "public/about/index.html": 6508004739747421000, + "public/accessibility/index.html": 1233551637845003055, + "public/api/index.html": 5254844140031320193, + "public/architecture/index.html": 851663481959891218, + "public/benchmarks/index.html": 12428704316268835746, + "public/changelog/index.html": 4625699870060108302, + "public/contact/index.html": 18071238935048083563, + "public/contributing/index.html": 6166182101035381425, + "public/faqs/index.html": 17038668637138867659, + "public/formats/index.html": 9589336268441412383, + "public/getting-started/index.html": 15910223332452642413, + "public/index.html": 11284954332199492997, + "public/made-with-ssg/index.html": 17700426430641059077, + "public/offline/index.html": 18253695968690479186, + "public/privacy/index.html": 11765054087992996563, + "public/security/index.html": 15702541847127712516, + "public/terms/index.html": 5924430751302939600, + "public/thanks/index.html": 16339271470989256153, + "public/use-cases/index.html": 5376738131758539388 } \ No newline at end of file diff --git a/docs/.well-known/mcp.json b/docs/.well-known/mcp.json index ccdc287..dc15ecb 100644 --- a/docs/.well-known/mcp.json +++ b/docs/.well-known/mcp.json @@ -15,7 +15,7 @@ "resources": [], "serverInfo": { "name": "Bank Statement Parser", - "version": "0.0.69" + "version": "0.0.72" }, "tools": [], "transport": { diff --git a/docs/404.html b/docs/404.html new file mode 100644 index 0000000..d68d4d1 --- /dev/null +++ b/docs/404.html @@ -0,0 +1,64 @@ + Page Not Found (404 Error) | Bank Statement Parser +
    Bank Statement Parser Logo Bank Statement Parser

    Error 404

    Page Not Found

    The financial documentation resource you requested could not be located on this server.

    The requested financial documentation page does not exist or has been moved.

    Return to Homepage → View Documentation
    + +
    + + + + +
    + \ No newline at end of file diff --git a/docs/404/index.html b/docs/404/index.html index ea533b0..d68d4d1 100644 --- a/docs/404/index.html +++ b/docs/404/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    Error 404

    Page Not Found

    The financial documentation resource you requested could not be located on this server.

    The requested financial documentation page does not exist or has been moved.

    Return to Homepage → View Documentation
    diff --git a/docs/404/rss.xml b/docs/404/rss.xml index d111142..ed972ce 100644 --- a/docs/404/rss.xml +++ b/docs/404/rss.xml @@ -1 +1 @@ -Page Not Found (404 Error) | Bank Statement Parserhttps://bankstatementparser.com/404/The requested financial documentation page could not be located. Browse the documentation index, supported format specifications, or return to the homepage.en-GB \ No newline at end of file +Page Not Found (404 Error) | Bank Statement Parserhttps://bankstatementparser.com/404/The requested financial documentation page could not be located. Browse the documentation index, supported format specifications, or return to the homepage.en-GB \ No newline at end of file diff --git a/docs/about/index.html b/docs/about/index.html index 61a380c..05ed3ad 100644 --- a/docs/about/index.html +++ b/docs/about/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    Engineering & Leadership

    About Sebastien Rousseau

    Principal engineer building high-assurance, privacy-first financial infrastructure and cryptographic document tooling.

    Sebastien Rousseau

    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.
    diff --git a/docs/about/rss.xml b/docs/about/rss.xml index 61dc4e5..0835882 100644 --- a/docs/about/rss.xml +++ b/docs/about/rss.xml @@ -1 +1 @@ -About Sebastien Rousseau | Bank Statement Parser Authorhttps://bankstatementparser.com/about/Read the background and 19-year financial systems architecture history of Sebastien Rousseau, creator of the open-source Bank Statement Parser engine and tools.en-GB \ No newline at end of file +About Sebastien Rousseau | Bank Statement Parser Authorhttps://bankstatementparser.com/about/Read the background and 19-year financial systems architecture history of Sebastien Rousseau, creator of the open-source Bank Statement Parser engine and tools.en-GB \ No newline at end of file diff --git a/docs/accessibility/index.html b/docs/accessibility/index.html index 957eb35..2940785 100644 --- a/docs/accessibility/index.html +++ b/docs/accessibility/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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.
    diff --git a/docs/accessibility/rss.xml b/docs/accessibility/rss.xml index 83bf5a0..bfe0278 100644 --- a/docs/accessibility/rss.xml +++ b/docs/accessibility/rss.xml @@ -1 +1 @@ -Accessibility Statement: WCAG 2.2 Level AAA Compliancehttps://bankstatementparser.com/accessibility/Official accessibility statement confirming full WCAG 2.2 Level AAA compliance, high-contrast color ratios, and keyboard-first navigation across all platforms.en-GB \ No newline at end of file +Accessibility Statement: WCAG 2.2 Level AAA Compliancehttps://bankstatementparser.com/accessibility/Official accessibility statement confirming full WCAG 2.2 Level AAA compliance, high-contrast color ratios, and keyboard-first navigation across all platforms.en-GB \ No newline at end of file diff --git a/docs/api/agents/index.json b/docs/api/agents/index.json index 0d4d5ae..09435bc 100644 --- a/docs/api/agents/index.json +++ b/docs/api/agents/index.json @@ -17,5 +17,5 @@ "title": "Bank Statement Parser | Fast, Secure Financial Data Extraction", "url": "https://bankstatementparser.com" }, - "version": "0.0.69" + "version": "0.0.72" } diff --git a/docs/api/agents/posts.json b/docs/api/agents/posts.json index 8a601d6..597b555 100644 --- a/docs/api/agents/posts.json +++ b/docs/api/agents/posts.json @@ -51,7 +51,7 @@ "tags": [], "title": "Changelog & Semantic Version History: Release Notes", "url": "https://bankstatementparser.com/changelog/", - "wordCount": 371 + "wordCount": 437 }, { "date": "2026-09-01", diff --git a/docs/api/index.html b/docs/api/index.html index 0de37ab..b87019e 100644 --- a/docs/api/index.html +++ b/docs/api/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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. Sensitive financial documents and banking statements remain strictly confined within your own compute environment.

    Air-gapped high-throughput financial document engineering architecture
    Air-gapped execution architecture: banking statements are tokenized and validated entirely within local memory with zero external telemetry.
    diff --git a/docs/api/rss.xml b/docs/api/rss.xml index a7589f5..45ea95b 100644 --- a/docs/api/rss.xml +++ b/docs/api/rss.xml @@ -1 +1 @@ -API Reference: Rust Crate & Python SDK Guidehttps://bankstatementparser.com/api/Complete API reference for Bank Statement Parser in Rust and Python with parameter schemas, zero-copy buffers, balance proofs, and transaction stream examples.en-GB \ No newline at end of file +API Reference: Rust Crate & Python SDK Guidehttps://bankstatementparser.com/api/Complete API reference for Bank Statement Parser in Rust and Python with parameter schemas, zero-copy buffers, balance proofs, and transaction stream examples.en-GB \ No newline at end of file diff --git a/docs/architecture/index.html b/docs/architecture/index.html index c0c9ee2..b9e5e40 100644 --- a/docs/architecture/index.html +++ b/docs/architecture/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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 <?xml version="1.0" to branch into streaming parser trees.
    • SWIFT MT940 / MT942: Checks for field delimiter sequences (:20:, :25:, :28C:) to route into deterministic line tokenizers.
    • CSV Delimited Files: Evaluates entropy across candidate delimiters (comma, semicolon, tab, pipe) over the first 50 rows to infer column geometry without full-file scans.

    Stage 2: Spatial Layout Tokenization

    For unstructured formats such as digital PDF statements, standard text extraction destroys critical vertical alignment. Bank Statement Parser utilizes a deterministic coordinate-clustering engine:

    • Glyph Extraction: Maps character matrices, font bounding boxes, and baseline coordinates from content stream operators (BT, ET, Tj, TJ, Tm).
    • Row Clustering: Groups glyphs with overlapping vertical tolerances into discrete lines, preventing footnote and header collision.
    • Column Geometric Alignment: Computes vertical whitespace gutters to delineate Booking Date, Value Date, Narrative, Amount, and Running Balance columns.
    • Multi-line Narrative Stitching: Heuristically associates wrapped description text back to the initiating transaction row.
    Bank Statement Parser — Pipeline Architecture and High-Throughput Engine
    High-assurance statement parsing: zero-copy memory mapping, deterministic tokenization, and ISO 20022 message synthesis.

    Stage 3: Field Normalization & Standard Mapping

    Extracted raw string tokens are converted into strongly-typed canonical primitives:

    • Date Canonicalization: Resolves 24 regional date formats (including DD/MM/YYYY, MM/DD/YYYY, YYYY-MM-DD, and multi-lingual month names) into ISO 8601 UTC timestamps.
    • Monetary Amounts: Parses European period/comma inversion (e.g., 1.234,56 vs 1,234.56), preserving scale as exact 64-bit fixed-point integers to eliminate IEEE 754 floating-point rounding drift.
    • Account & Bank Identifiers: Verifies ISO 13616 International Bank Account Numbers (IBAN) using mod-97 arithmetic (ISO 7064) and validates ISO 9362 Business Identifier Codes (BIC).
    • Transaction Code Classification: Maps proprietary transaction labels to standardized ISO 20022 Bank Transaction Codes (BTC), distinguishing card settlements, direct debits, credit transfers, and fee deductions.

    Stage 4: Mathematical Validation & Schema Synthesis

    Before any extracted statement is emitted, the engine evaluates strict balance invariants to guarantee data integrity:

    mathematical-invariant — balance check
    Invariant Equation: Opening_Balance + Sum(Credits) - Sum(Debits) == Closing_Balance
    # If Delta != 0.00, extraction fails with explicit discrepancy error and line offset

    Upon invariant satisfaction, the engine streams the normalized data tree into target schemas:

    • ISO 20022 CAMT.053: Generates conforming camt.053.001.08 Bank-to-Customer Statement XML messages ready for direct core banking and treasury ingest.
    • Canonical JSON: Emits clean, strongly-typed JSON with ISO 8601 dates and exact decimal numbers for downstream API consumption.
    • Reconciliation CSV: Serializes standardized transaction rows with consistent column headers for enterprise ERP systems.
    diff --git a/docs/architecture/rss.xml b/docs/architecture/rss.xml index c815a8d..d27c68c 100644 --- a/docs/architecture/rss.xml +++ b/docs/architecture/rss.xml @@ -1 +1 @@ -Architecture Blueprint: Deterministic Financial Parsinghttps://bankstatementparser.com/architecture/Explore the four-stage streaming architecture of Bank Statement Parser: zero-copy ingestion, lexical tokenization, balance proofs, and ISO 20022 emission.en-GB \ No newline at end of file +Architecture Blueprint: Deterministic Financial Parsinghttps://bankstatementparser.com/architecture/Explore the four-stage streaming architecture of Bank Statement Parser: zero-copy ingestion, lexical tokenization, balance proofs, and ISO 20022 emission.en-GB \ No newline at end of file diff --git a/docs/benchmarks/index.html b/docs/benchmarks/index.html index 87ca3d4..11f67ff 100644 --- a/docs/benchmarks/index.html +++ b/docs/benchmarks/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    Performance Metrics

    Performance Benchmarks & Throughput

    Empirical throughput and memory benchmarks comparing Bank Statement Parser against legacy Python and Java parser engines.

    Benchmarked on Apple Silicon (M-series) and Linux x86_64 server hardware across 50,000 multi-page banking statements.

    10,450
    Pages / Minute
    0.72 ms
    Average Latency
    18 MB
    Peak Memory (RSS)
    01

    Comparative Benchmark Matrix

    Empirical performance comparison processing standard 10-page commercial PDF bank statements with 150 transaction rows:

    Parser Engine Language Throughput (Pages/sec) Memory (RSS) Balance Check
    Bank Statement Parser Rust / Native 174 pages/sec 18 MB Mathematical (100%)
    PDFMiner.six Python (Pure) 3.8 pages/sec 145 MB None (Raw text)
    Camelot (Lattice) Python / OpenCV 1.2 pages/sec 380 MB None (Visual only)
    Tabula (Java) Java / JVM 8.4 pages/sec 512 MB None (Table grid)
    Apache PDFBox Java / JVM 14.1 pages/sec 290 MB None (Text layout)
    02

    Multi-Core Scaling & Parallelism

    Linear thread scalability benchmark across AMD EPYC 7763 (64-core) cloud instance ingesting batch directories:

    bash — benchmark throughput
    # Run benchmark suite over 10,000 statements with 16 parallel workers
    $bankstatementparser --benchmark --batch-dir ./dataset/ --threads 16
     
    Results: 10,000 files (48,200 pages) processed in 4.61 seconds
    Aggregate Throughput: 10,455.5 pages/min (174.2 pages/sec)
    Balance Validation Invariant: 100% passed (0 discrepancies)
    03

    Hardware Architecture Benchmark Callout

    The parser utilizes cache-friendly memory layouts, zero heap allocations in inner tokenizer loops, and SIMD vectorization for delimiter and byte scanning.

    High-throughput hardware benchmarks and low-latency processing
    Sub-millisecond processing: cache-friendly coordinate tokenization and linear multi-core scaling.
    diff --git a/docs/benchmarks/rss.xml b/docs/benchmarks/rss.xml index a729d16..e4a6587 100644 --- a/docs/benchmarks/rss.xml +++ b/docs/benchmarks/rss.xml @@ -1 +1 @@ -Performance Benchmarks: Latency & Throughputhttps://bankstatementparser.com/benchmarks/Empirical latency and throughput benchmarks demonstrating 10,000+ pages per minute and sub-millisecond bank statement parsing with zero memory leak overhead.en-GB \ No newline at end of file +Performance Benchmarks: Latency & Throughputhttps://bankstatementparser.com/benchmarks/Empirical latency and throughput benchmarks demonstrating 10,000+ pages per minute and sub-millisecond bank statement parsing with zero memory leak overhead.en-GB \ No newline at end of file diff --git a/docs/changelog/index.html b/docs/changelog/index.html index 06477b8..5517393 100644 --- a/docs/changelog/index.html +++ b/docs/changelog/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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.9] - 2026-11-01

    Fixed

    • Linked pages by their canonical URLs, kept non-indexable pages out of sitemap.xml, redirected /faq/ and /contribute/ to /faqs/ and /contributing/, and served the 404 page for missing URLs.

    Changed

    • Built the site with ssg 0.0.72.

    [0.0.8] - 2026-10-31

    Fixed

    • Restored the search widget assets and styles, and aligned the footer on a four-column grid.

    [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.
    • Documented Apache Parquet streaming (ParquetStreamWriter) and batch export alongside plain-text ledger models (hledger, beancount, ledger-cli).
    • Implemented Generative Engine Optimization (GEO) architecture with direct-answer BLUF headers and entity-based knowledge graphs.
    • Documented two-way bank reconciliation (reconcile_payments_and_statements), treasury analytics, and PDF forensics.

    Changed

    • Upgraded Static Site Generator (SSG) compilation and audit pipeline to the latest local version.
    • Linked copyright notice directly to author Sebastien Rousseau at https://sebastienrousseau.com/ across all layouts.

    [0.0.2] - 2026-09-27

    Fixed

    • 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/changelog/rss.xml b/docs/changelog/rss.xml index a61a9fd..6dfce55 100644 --- a/docs/changelog/rss.xml +++ b/docs/changelog/rss.xml @@ -1 +1 @@ -Changelog & Semantic Version History: Release Noteshttps://bankstatementparser.com/changelog/Comprehensive release notes and semantic versioning history for Bank Statement Parser, detailing new format dialects, performance fixes, and security patches.en-GB \ No newline at end of file +Changelog & Semantic Version History: Release Noteshttps://bankstatementparser.com/changelog/Comprehensive release notes and semantic versioning history for Bank Statement Parser, detailing new format dialects, performance fixes, and security patches.en-GB \ No newline at end of file diff --git a/docs/contact/index.html b/docs/contact/index.html index 9e70371..b7ca110 100644 --- a/docs/contact/index.html +++ b/docs/contact/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    Get in Touch

    Contact & Enterprise Support

    Engage with our core engineering team for custom banking dialects, high-throughput SLAs, or enterprise licensing.

    Have a specialized bank statement format, high-volume batch requirement, or proprietary ERP integration?

    diff --git a/docs/contact/rss.xml b/docs/contact/rss.xml index 872f634..6934448 100644 --- a/docs/contact/rss.xml +++ b/docs/contact/rss.xml @@ -1 +1 @@ -Contact & Enterprise Inquiries | Bank Statement Parserhttps://bankstatementparser.com/contact/Get in touch with the Bank Statement Parser engineering team for custom bank dialect support, private cloud deployments, advisory, and enterprise integrations.en-GB \ No newline at end of file +Contact & Enterprise Inquiries | Bank Statement Parserhttps://bankstatementparser.com/contact/Get in touch with the Bank Statement Parser engineering team for custom bank dialect support, private cloud deployments, advisory, and enterprise integrations.en-GB \ No newline at end of file diff --git a/docs/contribute/index.html b/docs/contribute/index.html new file mode 100644 index 0000000..8eee17a --- /dev/null +++ b/docs/contribute/index.html @@ -0,0 +1,25 @@ + + + + + +Page moved | Bank Statement Parser + + + + + + + + + + + + + +
    +

    This page has moved

    +

    Continue to https://bankstatementparser.com/contributing/.

    +
    + + diff --git a/docs/contributing/index.html b/docs/contributing/index.html index c9bf500..d8e61fb 100644 --- a/docs/contributing/index.html +++ b/docs/contributing/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    Community & Code

    Contributing to Bank Statement Parser

    Guidelines for bug reporting, code contributions, DCO sign-offs, and test-driven verification.

    Thank you for your interest in contributing to Bank Statement Parser. We welcome contributions for new regional statement dialects, zero-copy performance optimizations, parser rulebook definitions, and documentation improvements.

    01

    Local Development Environment Setup

    Bank Statement Parser is built in Rust with companion Python bindings. Ensure you have the stable Rust toolchain and Python 3.10+ installed:

    bash — clone & setup
    # Fork and clone repository
    $git clone https://github.com/YOUR_USERNAME/bankstatementparser.git
    $cd bankstatementparser
     
    # Build debug binary
    $cargo build
    02

    Test-Driven Verification & Invariants

    Every pull request must pass the automated test suite, clippy linter checks, and formatting verification. 100% test coverage on new parsing dialects is required:

    bash — test suite
    # Execute full test suite across all dialects
    $cargo test
     
    # Run strict Clippy linter with all features enabled
    $cargo clippy --all-targets --all-features -- -D warnings
     
    # Verify formatting conforms to rustfmt
    $cargo fmt --check
    03

    Sample Data & PII Sanitization Invariant

    To protect privacy and comply with data sovereignty regulations, never submit real-world bank statements containing Personally Identifiable Information (PII) or authentic account details:

    Data Field Invariant Requirement Verification Method
    IBAN Checksums Must use valid ISO 7064 Mod-97 test numbers Verified by test_sample_data_valid.rs
    SWIFT / BIC Structurally valid 8 or 11-char test BICs ISO 9362 structural regex validation
    Customer PII Synthetic names, anonymized street addresses Zero real customer records permitted
    Currencies Standard ISO 4217 currency identifiers (EUR, GBP, USD) Matched against official currency table
    04

    Commit Standards, DCO & Signing

    All contributions must follow Conventional Commits, be SSH/GPG signed, and carry a Developer Certificate of Origin (DCO) Signed-off-by trailer:

    bash — commit conventions
    # Commit with DCO sign-off (-s) and cryptographic signature (-S)
    $git commit -s -S -m "feat(dialect): add barclays corporate pdf extractor"
    diff --git a/docs/contributing/rss.xml b/docs/contributing/rss.xml index 5b26716..e2df733 100644 --- a/docs/contributing/rss.xml +++ b/docs/contributing/rss.xml @@ -1 +1 @@ -Contributing Guide: Code Standards & Testinghttps://bankstatementparser.com/contributing/Contributor guidelines for Bank Statement Parser covering Rust code conventions, mod-97 sample data verification, DCO signoffs, and automated test execution.en-GB \ No newline at end of file +Contributing Guide: Code Standards & Testinghttps://bankstatementparser.com/contributing/Contributor guidelines for Bank Statement Parser covering Rust code conventions, mod-97 sample data verification, DCO signoffs, and automated test execution.en-GB \ No newline at end of file diff --git a/docs/faq/index.html b/docs/faq/index.html new file mode 100644 index 0000000..6d490d2 --- /dev/null +++ b/docs/faq/index.html @@ -0,0 +1,25 @@ + + + + + +Page moved | Bank Statement Parser + + + + + + + + + + + + + +
    +

    This page has moved

    +

    Continue to https://bankstatementparser.com/faqs/.

    +
    + + diff --git a/docs/faqs/index.html b/docs/faqs/index.html index fba5811..30643dc 100644 --- a/docs/faqs/index.html +++ b/docs/faqs/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    Questions & Answers

    Frequently Asked Questions

    Comprehensive guidance covering specifications, zero-telemetry local execution, performance, and commercial licensing.

    Showing 16 of 16 questions
    Architecture How does Bank Statement Parser achieve sub-millisecond parsing throughput?

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

    Formats Which bank statement standards and specifications are natively supported?

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

    • PDF Statements: Digital and scanned PDF 1.4–2.0 coordinate mapping, table boundaries, and offline OCR fallback.
    • CSV & Delimited: RFC 4180 auto-detecting delimiters (comma, semicolon, tab), date ordering, and decimal notations.
    • BAI2 Cash Management: North American standard (Records 01–99) with status codes and record 88 continuation lines.
    • SWIFT MT940 / MT942: End-of-day and interim intraday statements with structured field :86: sub-tag parsing.
    • ISO 20022 CAMT (052/053/054): Bank-to-customer statements, intraday reports, and credit/debit notifications.
    • ISO 20022 PAIN.001: Customer credit transfer initiation messages parsed for automated two-way reconciliation.
    • OFX / QFX: Open Financial Exchange SGML (1.x) and XML (2.x) banking and credit card statements.
    • Parquet & Ledger Exports: Columnar Apache Parquet streaming, and plain-text ledgers (hledger, beancount, ledger-cli).
    Architecture How are corrupted, malformed, or ambiguous statement entries handled?

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

    Formats Does Bank Statement Parser support scanned paper statements using OCR?

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

    Security Does Bank Statement Parser send financial documents or telemetry to remote servers?

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

    Privacy How can enterprise compliance teams verify zero-network egress in air-gapped environments?

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

    Security Are bank statements or parsed transaction records cached or written to disk?

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

    Supply Chain How are release artifacts, dependencies, and SBOMs cryptographically verified?

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

    Rust How do I integrate Bank Statement Parser into an existing Rust application?

    Add the dependency to your Cargo.toml:

    [dependencies]
bankstatementparser = "0.0.2"

    Then parse any statement file into strongly-typed structures:

    use bankstatementparser::Parser;
use std::path::Path;
fn main() -> Result<(), Box<dyn std::error::Error>> {
    let parser = Parser::new();
    let statement = parser.parse_file(Path::new("statement.pdf"))?;
    println!("Account: {}, Balance: {}", statement.account_id, statement.closing_balance);
    Ok(())
}
    Python Is there a native Python SDK, and does it require a local Rust toolchain?

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

    pip install bankstatementparser

    And use it in Python:

    from bankstatementparser import parse_statement
statement = parse_statement("statement.pdf")
print(f"Transactions parsed: {len(statement.transactions)}")
    Docker Can I execute Bank Statement Parser as a containerized microservice or Docker image?

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

    docker run --rm -v $(pwd):/data ghcr.io/sebastienrousseau/bankstatementparser:latest --input /data/statement.pdf --format json
    Performance How does parallel multi-threading scale across large statement directories?

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

    Licensing Can Bank Statement Parser be embedded in commercial enterprise software?

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

    ISO 20022 How does the validation engine verify ISO 20022 CAMT.053 schemas and balance proofs?

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

    Enterprise Is custom bank statement dialect or bespoke layout template mapping supported?

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

    Support What enterprise support options, service level agreements (SLAs), and custom integrations are available?

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

    No matching questions found

    Try searching for broader terms such as “Docker”, “ISO 20022”, “Python”, or “OCR”.

    Have a question not listed here?

    Our core engineering team and community stewards are available to assist. Explore the documentation guides, join our GitHub community discussions, or contact our solutions engineers directly.

    Getting Started Guide GitHub Discussions Contact Support
    diff --git a/docs/faqs/rss.xml b/docs/faqs/rss.xml index 5faa497..728f4b8 100644 --- a/docs/faqs/rss.xml +++ b/docs/faqs/rss.xml @@ -1 +1 @@ -Frequently Asked Questions: Bank Statement Parser FAQhttps://bankstatementparser.com/faqs/Get clear answers regarding Bank Statement Parser format dialects, zero-telemetry security, ISO 20022 schemas, local OCR modules, and enterprise SDK licensing.en-GB \ No newline at end of file +Frequently Asked Questions: Bank Statement Parser FAQhttps://bankstatementparser.com/faqs/Get clear answers regarding Bank Statement Parser format dialects, zero-telemetry security, ISO 20022 schemas, local OCR modules, and enterprise SDK licensing.en-GB \ No newline at end of file diff --git a/docs/formats/index.html b/docs/formats/index.html index 97ce30e..99d218a 100644 --- a/docs/formats/index.html +++ b/docs/formats/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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 during multi-account batch ingestion.

    5. Delimited CSV Statements

    CSV is the most ubiquitous yet least standardized financial format. Bank Statement Parser implements a statistical dialect inference engine that automatically determines:

    • Delimiter Detection: Comma (,), semicolon (;), tab (\t), or pipe (|).
    • Date Formatting: ISO 8601 (YYYY-MM-DD), European (DD/MM/YYYY), and US (MM/DD/YYYY) formats inferred from semantic date distributions.
    • Number & Currency Notation: Automatic handling of periods vs. commas for thousand separators and decimal points (e.g. 1,234.56 vs. 1.234,56).
    • Amount Semantics: Automatic detection of unified signed amount columns or split Debit / Credit column layouts.

    6. Digital and Scanned PDF Statements

    Financial institutions frequently deliver statements in PDF format. Bank Statement Parser provides a dual-mode engine for complete document recovery:

    • Digital / Vector PDFs: High-speed extraction directly from internal text streams and spatial coordinates, preserving table columns across multi-page boundaries with sub-millisecond execution.
    • Scanned Image Statements: Optional local, offline OCR and vision fallback models parse bitmap PDFs (TIFF, PNG, scanned documents) into layout-aware bounding boxes without sending a single byte outside your private network.
    • Forensics & Tamper Verification: Automated PDF forensics check for font anomalies, metadata discrepancies, and hidden modification layers to detect altered statements.

    7. Analytical & Accounting Export Targets

    In addition to strongly-typed JSON and CSV, Bank Statement Parser supports industrial streaming analytics and plain-text accounting ledger pipelines:

    • Streaming Apache Parquet (ParquetStreamWriter): High-performance, columnar Parquet export with snappy or zstd compression. Supports streaming hundreds of thousands of transactions directly to disk or S3 with constant memory usage.
    • Plain-Text Accounting (PTA): Native export formats for hledger, beancount, and ledger-cli double-entry bookkeeping systems.
    • Pandas & Polars DataFrames: Zero-copy integration into Polars and Pandas analytics pipelines via bankstatementparser[parquet] and bankstatementparser[polars] extras.
    diff --git a/docs/formats/rss.xml b/docs/formats/rss.xml index aff3498..6dff633 100644 --- a/docs/formats/rss.xml +++ b/docs/formats/rss.xml @@ -1 +1 @@ -Supported Statement Formats: PDF, CSV, OFX, MT940, CAMT, BAI2https://bankstatementparser.com/formats/Comprehensive format specifications for 8 structured financial formats: CAMT (052/053/054), PAIN.001, MT940, MT942, OFX/QFX, BAI2, CSV, and PDF statements.en-GB \ No newline at end of file +Supported Statement Formats: PDF, CSV, OFX, MT940, CAMT, BAI2https://bankstatementparser.com/formats/Comprehensive format specifications for 8 structured financial formats: CAMT (052/053/054), PAIN.001, MT940, MT942, OFX/QFX, BAI2, CSV, and PDF statements.en-GB \ No newline at end of file diff --git a/docs/getting-started/index.html b/docs/getting-started/index.html index 5155c7b..244d90f 100644 --- a/docs/getting-started/index.html +++ b/docs/getting-started/index.html @@ -38,7 +38,7 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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<dyn std::error::Error>> {
        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:

    High-throughput financial document engineering architecture
    Air-gapped execution architecture: banking statements are tokenized and validated entirely within local memory with zero external telemetry.
    diff --git a/docs/getting-started/rss.xml b/docs/getting-started/rss.xml index 497751f..a5462a2 100644 --- a/docs/getting-started/rss.xml +++ b/docs/getting-started/rss.xml @@ -1 +1 @@ -Getting Started: Install CLI & Native Python/Rust SDKhttps://bankstatementparser.com/getting-started/Step-by-step installation instructions for Bank Statement Parser via Cargo, Pip, Homebrew, and Docker with immediate CLI execution and Python code examples.en-GB \ No newline at end of file +Getting Started: Install CLI & Native Python/Rust SDKhttps://bankstatementparser.com/getting-started/Step-by-step installation instructions for Bank Statement Parser via Cargo, Pip, Homebrew, and Docker with immediate CLI execution and Python code examples.en-GB \ No newline at end of file diff --git a/docs/index.html b/docs/index.html index f760772..35819b6 100644 --- a/docs/index.html +++ b/docs/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    Financial Document Engineering · Open Source

    Parse 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 Formats
    • Deterministic Rust Core
    • Zero Cloud Dependencies
    • 100% Air-Gapped Privacy
    • 10,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 and real-time financial ledger analytics dashboard in modern banking operations

    Corporate Treasury Automation

    Automated Reconciliation for Modern Treasury

    Eliminate 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 Architecture

    Engineered for absolute accuracy.

    Industrial-grade financial parsing combining memory-safe Rust execution, native Python bindings, and dual Apache/MIT licensing.

    01

    Multi-Format Dialect Engine

    Deterministic 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.

    02

    Arithmetic Balance Verification

    Strict mathematical balance validation ensures opening balance plus net credits and debits precisely equals closing balance to the penny before record emission.

    03

    ISO 20022 Harmonization

    Normalize 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 Pipeline

    From raw bank document to validated ledger transactions.

    1

    Ingest

    Stream PDF bytes, CSV feeds, BAI2 files, or SWIFT MT940/MT942 messages into memory-safe zero-copy buffers.

    Sub-millisecond stream loading
    2

    Tokenize

    Deterministic lexical analysis identifies account metadata, booking dates, line items, and structured :86: sub-tags.

    Deterministic layout analysis
    3

    Verify

    Arithmetic balance reconciliation confirms credit/debit integrity, checks PDF forensics, and validates IBAN checksums.

    Mod-97 and balance proofs
    4

    Emit

    Output strongly-typed JSON, streaming Apache Parquet, Plain-Text Ledgers (hledger, beancount), or ISO 20022 messages.

    Ready for ERP, Lakehouse & GL
    Iconic financial architecture of London at night, highlighting high-assurance parsing infrastructure

    High-Performance Pipeline

    Deterministic Execution at Enterprise Scale

    Engineered for high-frequency financial platforms requiring bounded latency, zero-allocation loops, and strict ISO 20022 data models.

    View Architecture Blueprint

    Developer Quickstart

    Install via Cargo, Pip, or Homebrew in Seconds

    Deploy 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 Privacy

    Your 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 Answers

    Frequently Asked Questions

    Does 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 engine extracts structured text streams directly with zero loss. For scanned image statements, an optional local OCR module performs deterministic optical layout parsing with zero external cloud API dependencies.

    Is the project open source and available for commercial use?

    Yes. Bank Statement Parser is dual-licensed under the Apache-2.0 and MIT open-source licenses. You can freely integrate it into commercial SaaS products, enterprise backends, and internal financial pipelines.

    Developer Quickstart

    Financial data is mission-critical.
    Your parsing pipeline should be instant.

    Get started in minutes with the Rust CLI or Python package across Linux, macOS, and Windows.

    Install Bank Statement Parser
    diff --git a/docs/llms-full.txt b/docs/llms-full.txt index b84a952..24ab1f4 100644 --- a/docs/llms-full.txt +++ b/docs/llms-full.txt @@ -39,8 +39,8 @@

    Parse 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 Formats +Install CLI & SDK +Explore Supported Formats
    • Deterministic Rust Core
      • @@ -83,7 +83,7 @@

      Corporate Treasury Automation

      Automated Reconciliation for Modern Treasury

      Eliminate 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 +View Treasury Playbook
    @@ -158,7 +158,7 @@

    High-Performance Pipeline

    Deterministic Execution at Enterprise Scale

    Engineered for high-frequency financial platforms requiring bounded latency, zero-allocation loops, and strict ISO 20022 data models.

    -View Architecture Blueprint +View Architecture Blueprint
    @@ -170,8 +170,8 @@

    Install via Cargo, Pip, or Homebrew in Seconds

    Deploy 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 +Full Documentation → +API Reference
    @@ -201,7 +201,7 @@

    Your 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 +Read Security & Privacy Architecture
    @@ -240,7 +240,7 @@

    Get started in minutes with the Rust CLI or Python package across Linux, macOS, and Windows.

    -Install Bank Statement Parser +Install Bank Statement Parser
    @@ -1661,7 +1661,7 @@ Financial statement data demands strict confidentiality, rigorous boundary isola
    -

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

    +

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

    @@ -1679,9 +1679,9 @@ Financial statement data demands strict confidentiality, rigorous boundary isola

    Have a question not listed here?

    Our core engineering team and community stewards are available to assist. Explore the documentation guides, join our GitHub community discussions, or contact our solutions engineers directly.

    -Getting Started Guide +Getting Started Guide GitHub Discussions -Contact Support +Contact Support
    @@ -1716,6 +1716,16 @@ 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.9] - 2026-11-01 +### Fixed +- Linked pages by their canonical URLs, kept non-indexable pages out of `sitemap.xml`, redirected `/faq/` and `/contribute/` to `/faqs/` and `/contributing/`, and served the 404 page for missing URLs. +### Changed +- Built the site with `ssg` 0.0.72. + +## [0.0.8] - 2026-10-31 +### Fixed +- Restored the search widget assets and styles, and aligned the footer on a four-column grid. + ## [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`. diff --git a/docs/made-with-ssg/index.html b/docs/made-with-ssg/index.html index e395ee9..1788332 100644 --- a/docs/made-with-ssg/index.html +++ b/docs/made-with-ssg/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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.
    diff --git a/docs/made-with-ssg/rss.xml b/docs/made-with-ssg/rss.xml index 49b5bac..86d1ff0 100644 --- a/docs/made-with-ssg/rss.xml +++ b/docs/made-with-ssg/rss.xml @@ -1 +1 @@ -Made with Static Site Generator (SSG) | Web Platformhttps://bankstatementparser.com/made-with-ssg/Learn how the Bank Statement Parser documentation site is built using Rust Static Site Generator (SSG), featuring strict CSP, WCAG AAA audits, and fast builds.en-GB \ No newline at end of file +Made with Static Site Generator (SSG) | Web Platformhttps://bankstatementparser.com/made-with-ssg/Learn how the Bank Statement Parser documentation site is built using Rust Static Site Generator (SSG), featuring strict CSP, WCAG AAA audits, and fast builds.en-GB \ No newline at end of file diff --git a/docs/offline/index.html b/docs/offline/index.html index 1df4722..ca4d189 100644 --- a/docs/offline/index.html +++ b/docs/offline/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    Network Disconnected

    You Are Currently Offline

    Documentation is cached locally via service worker for uninterrupted offline engineering.

    Bank Statement Parser documentation has been cached for offline availability. Check your internet connection to refresh live data feeds.

    diff --git a/docs/offline/rss.xml b/docs/offline/rss.xml index 8060850..5b8597b 100644 --- a/docs/offline/rss.xml +++ b/docs/offline/rss.xml @@ -1 +1 @@ -Offline Documentation Access | Bank Statement Parserhttps://bankstatementparser.com/offline/Offline documentation fallback for Bank Statement Parser. Access cached developer guides, format specifications, and API references with zero network access.en-GB \ No newline at end of file +Offline Documentation Access | Bank Statement Parserhttps://bankstatementparser.com/offline/Offline documentation fallback for Bank Statement Parser. Access cached developer guides, format specifications, and API references with zero network access.en-GB \ No newline at end of file diff --git a/docs/privacy/index.html b/docs/privacy/index.html index bd23b44..4d04a63 100644 --- a/docs/privacy/index.html +++ b/docs/privacy/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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:

    1. 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.
    2. No Tracking Cookies: This documentation website does not use tracking cookies, analytics pixels, or third-party behavioral scripts.
    3. Data Protection Compliance: Fully compliant with GDPR, UK Data Protection Act 2018, and California Consumer Privacy Act (CCPA).
    diff --git a/docs/privacy/rss.xml b/docs/privacy/rss.xml index 65378a9..e97a1f1 100644 --- a/docs/privacy/rss.xml +++ b/docs/privacy/rss.xml @@ -1 +1 @@ -Zero-Telemetry Privacy Guarantee & Data Protectionhttps://bankstatementparser.com/privacy/Official privacy policy confirming Bank Statement Parser collects zero telemetry, uses zero cookies, and executes completely air-gapped on your infrastructure.en-GB \ No newline at end of file +Zero-Telemetry Privacy Guarantee & Data Protectionhttps://bankstatementparser.com/privacy/Official privacy policy confirming Bank Statement Parser collects zero telemetry, uses zero cookies, and executes completely air-gapped on your infrastructure.en-GB \ No newline at end of file diff --git a/docs/releases/v0.0.9.md b/docs/releases/v0.0.9.md new file mode 100644 index 0000000..8c1fa1d --- /dev/null +++ b/docs/releases/v0.0.9.md @@ -0,0 +1,5 @@ +## Highlights ⭐️ + +* **Search engines see only real pages**: `sitemap.xml` now lists only indexable pages that are their own canonical, and every internal link uses the canonical URL instead of `/page/index.html`. +* **Moved pages redirect**: `/faq/` and `/contribute/` forward to `/faqs/` and `/contributing/`, and missing URLs get the site's own 404 page instead of the GitHub Pages default. +* **Built with ssg 0.0.72**: local builds, the release workflow and the devcontainer use the latest `ssg`, and CI now holds every Python function to the complexity ceilings. diff --git a/docs/sbom.cdx.json b/docs/sbom.cdx.json index 100c17a..a3941c8 100644 --- a/docs/sbom.cdx.json +++ b/docs/sbom.cdx.json @@ -2,7 +2,7 @@ "bomFormat": "CycloneDX", "components": [ { - "bom-ref": "ssg@0.0.69", + "bom-ref": "ssg@0.0.72", "description": "Static site generator", "externalReferences": [ { @@ -27,9 +27,9 @@ } ], "name": "ssg", - "purl": "pkg:cargo/ssg@0.0.69", + "purl": "pkg:cargo/ssg@0.0.72", "type": "application", - "version": "0.0.69" + "version": "0.0.72" } ], "metadata": { @@ -39,16 +39,16 @@ "name": "static-site", "type": "application" }, - "timestamp": "2026-10-31T13:37:48Z", + "timestamp": "2026-11-01T18:16:42Z", "tools": [ { "name": "ssg", "vendor": "SSG Contributors", - "version": "0.0.69" + "version": "0.0.72" } ] }, - "serialNumber": "urn:uuid:c9b5a42b-b246-894b-aaba-b6c56cacad79", + "serialNumber": "urn:uuid:49b38c7b-aebc-8e4e-ae00-71397b125911", "specVersion": "1.5", "version": 1 } \ No newline at end of file diff --git a/docs/search-index.json b/docs/search-index.json index 671a2e6..7d4a137 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/docs/security/index.html b/docs/security/index.html index f04393c..c0d94d4 100644 --- a/docs/security/index.html +++ b/docs/security/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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 security architecture and air-gapped statement parsing
    Cryptographic integrity: every binary is Sigstore-signed, air-gapped, and accompanied by a CycloneDX SBOM.
    diff --git a/docs/security/rss.xml b/docs/security/rss.xml index f928810..f136167 100644 --- a/docs/security/rss.xml +++ b/docs/security/rss.xml @@ -1 +1 @@ -Security Architecture: Air-Gapped & Memory-Safe Parsinghttps://bankstatementparser.com/security/Examine the zero-telemetry security model of Bank Statement Parser: memory-safe Rust execution, air-gapped processing, Sigstore signing, and CycloneDX SBOMs.en-GB \ No newline at end of file +Security Architecture: Air-Gapped & Memory-Safe Parsinghttps://bankstatementparser.com/security/Examine the zero-telemetry security model of Bank Statement Parser: memory-safe Rust execution, air-gapped processing, Sigstore signing, and CycloneDX SBOMs.en-GB \ No newline at end of file diff --git a/docs/sitemap.xml b/docs/sitemap.xml index dde58b5..0c60fac 100644 --- a/docs/sitemap.xml +++ b/docs/sitemap.xml @@ -2,109 +2,109 @@ https://bankstatementparser.com/ - 2026-10-31 + 2026-11-01 daily 1.0 https://bankstatementparser.com/about/ - 2026-10-31 + 2026-11-01 weekly 0.8 https://bankstatementparser.com/accessibility/ - 2026-10-31 + 2026-11-01 monthly 0.5 https://bankstatementparser.com/api/ - 2026-10-31 + 2026-11-01 weekly 0.9 https://bankstatementparser.com/architecture/ - 2026-10-31 + 2026-11-01 weekly 0.9 https://bankstatementparser.com/benchmarks/ - 2026-10-31 + 2026-11-01 weekly 0.9 https://bankstatementparser.com/changelog/ - 2026-10-31 + 2026-11-01 weekly 0.8 https://bankstatementparser.com/contact/ - 2026-10-31 + 2026-11-01 weekly 0.8 https://bankstatementparser.com/contributing/ - 2026-10-31 + 2026-11-01 monthly 0.5 https://bankstatementparser.com/faqs/ - 2026-10-31 + 2026-11-01 weekly 0.9 https://bankstatementparser.com/formats/ - 2026-10-31 + 2026-11-01 weekly 0.9 https://bankstatementparser.com/getting-started/ - 2026-10-31 + 2026-11-01 weekly 0.9 https://bankstatementparser.com/made-with-ssg/ - 2026-10-31 + 2026-11-01 monthly 0.5 https://bankstatementparser.com/privacy/ - 2026-10-31 + 2026-11-01 monthly 0.5 https://bankstatementparser.com/security/ - 2026-10-31 + 2026-11-01 weekly 0.9 https://bankstatementparser.com/terms/ - 2026-10-31 + 2026-11-01 monthly 0.5 https://bankstatementparser.com/thanks/ - 2026-10-31 + 2026-11-01 monthly 0.5 https://bankstatementparser.com/use-cases/ - 2026-10-31 + 2026-11-01 weekly 0.9 diff --git a/docs/sw.js b/docs/sw.js index d37b698..b7b648b 100644 --- a/docs/sw.js +++ b/docs/sw.js @@ -6,7 +6,7 @@ 'use strict'; -var CACHE_NAME = 'bsp-docs-v0.0.8'; +var CACHE_NAME = 'bsp-docs-v0.0.9'; var OFFLINE_URL = '/offline/index.html'; var PRECACHE_URLS = [ '/', diff --git a/docs/terms/index.html b/docs/terms/index.html index 371c064..3501f55 100644 --- a/docs/terms/index.html +++ b/docs/terms/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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.

    diff --git a/docs/terms/rss.xml b/docs/terms/rss.xml index 697462b..13b0a68 100644 --- a/docs/terms/rss.xml +++ b/docs/terms/rss.xml @@ -1 +1 @@ -Terms of Use & Dual Open-Source License Specificationshttps://bankstatementparser.com/terms/Terms of use and dual open-source licensing guidelines governing Bank Statement Parser under Apache-2.0 and MIT terms for community and enterprise developers.en-GB \ No newline at end of file +Terms of Use & Dual Open-Source License Specificationshttps://bankstatementparser.com/terms/Terms of use and dual open-source licensing guidelines governing Bank Statement Parser under Apache-2.0 and MIT terms for community and enterprise developers.en-GB \ No newline at end of file diff --git a/docs/thanks/index.html b/docs/thanks/index.html index a1065cd..3c78199 100644 --- a/docs/thanks/index.html +++ b/docs/thanks/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    Message Dispatched

    Thank You for Your Message

    Your inquiry has been securely routed to our engineering team. We will respond within one business day.

    We have received your inquiry regarding Bank Statement Parser. A systems engineer will respond within one business day.

    Return to Homepage →
    diff --git a/docs/thanks/rss.xml b/docs/thanks/rss.xml index 035b3d2..cba6bc8 100644 --- a/docs/thanks/rss.xml +++ b/docs/thanks/rss.xml @@ -1 +1 @@ -Thank You for Your Inquiry | Bank Statement Parserhttps://bankstatementparser.com/thanks/Thank you for contacting Bank Statement Parser. Our financial infrastructure engineering team will review your statement dialect requirements and respond soon.en-GB \ No newline at end of file +Thank You for Your Inquiry | Bank Statement Parserhttps://bankstatementparser.com/thanks/Thank you for contacting Bank Statement Parser. Our financial infrastructure engineering team will review your statement dialect requirements and respond soon.en-GB \ No newline at end of file diff --git a/docs/use-cases/index.html b/docs/use-cases/index.html index 0d87e80..b21b444 100644 --- a/docs/use-cases/index.html +++ b/docs/use-cases/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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
    Historical Batch Throughput Limited by cloud API rate-limits & cost 10,450 pages/minute on workstation hardware
    IBAN & BIC Validation Unchecked strings with OCR transcription drift ISO 13616 Mod-97 and ISO 9362 structural validation
    Evidentiary Audit Trail Lossy, potentially hallucinated text Deterministic byte-exact coordinate provenance
    bash — air-gapped aml extraction
    # Air-gapped forensic extraction to normalized JSON stream
    $bankstatementparser --offline --extract-counterparties --format jsonl ./seized_records/ > aml_graph.jsonl
     
    Audit Log: Processed 54,200 pages in 5.18 seconds
    Entities Extracted: 3,412 unique IBANs, 194 distinct BICs validated
    05

    Enterprise Deployment Architecture

    Bank Statement Parser deploys flexibly across enterprise architectures: as a standalone native CLI binary, a zero-overhead microservice sidecar in Kubernetes clusters, or an embedded library in Python, Rust, and WebAssembly applications.

    Enterprise corporate treasury and automated banking workflow architecture
    Enterprise orchestration: zero-network document ingestion for real-time treasury and audit operations.
    diff --git a/docs/use-cases/rss.xml b/docs/use-cases/rss.xml index 89a0820..667582d 100644 --- a/docs/use-cases/rss.xml +++ b/docs/use-cases/rss.xml @@ -1 +1 @@ -Fintech Use Cases: Treasury & Reconciliationhttps://bankstatementparser.com/use-cases/Discover enterprise deployment architectures for corporate treasury automation, lending underwriting, ledger reconciliation, and forensic accounting pipelines.en-GB \ No newline at end of file +Fintech Use Cases: Treasury & Reconciliationhttps://bankstatementparser.com/use-cases/Discover enterprise deployment architectures for corporate treasury automation, lending underwriting, ledger reconciliation, and forensic accounting pipelines.en-GB \ No newline at end of file diff --git a/public/.meta/changelog.meta.json b/public/.meta/changelog.meta.json index 1e51af4..bbdc20a 100644 --- a/public/.meta/changelog.meta.json +++ b/public/.meta/changelog.meta.json @@ -13,8 +13,8 @@ "logo": "https://cloudcdn.pro/bankstatementparser/v1/logos/bankstatementparser.svg", "name": "Bank Statement Parser", "permalink": "https://bankstatementparser.com/changelog/", - "reading_time": 1, + "reading_time": 2, "short_name": "bankstatementparser", "title": "Changelog & Semantic Version History: Release Notes", - "word_count": 371 + "word_count": 437 } \ No newline at end of file diff --git a/public/.ssg-cache/depgraph.json b/public/.ssg-cache/depgraph.json index cfc0a23..3b2b76b 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":"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 +{"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":"2b508ed2118dcc9a1bbc3cb10f3a47f83f451bc92673bb57847b3f493af9810a","_layouts/header.html":"57779e3e7552597c6b285f9f2a9f1089a7b4263e23dcf2ebee54ad147b57c411","_layouts/index.html":"1011c37cf9a923ebe4e8e777d90c0211db95bf789d245e0f5a44c31f1f8e15b0","_layouts/offline.html":"17192422da99d87d32ba2d575456e0d304ae9f52e3d7b9f7813e65c23e8919c6","_layouts/page.html":"cde4e4ff156a75852c740d4ac98d8cc80b30fe9c267344bc27279241aaa9c3df","_posts/404.md":"78b457b95ce23818d9c7a295cb21502c510864b9278f23929c3d8cfced447796","_posts/about.md":"13194ab6c87d444d2a8e647b0a248eb8194a616e2667f464516d50edb5baa37a","_posts/accessibility.md":"b791c5a0c010756d7c94af08a3ad2a1942cf78b7297ae96bc6946fa9a5b3997b","_posts/api.md":"d56ea4a068ab062bcdb074e90a76375c9d246ce07510e9ad3dea43b0d716980d","_posts/architecture.md":"bee13f62aebbea7f768c1ccae09402bc9d3720cbbe2704828305f0c57e182164","_posts/benchmarks.md":"4c838792a32c88f09a74300063c6ade24ab89c9f55b6ab415589fdfa59431bee","_posts/changelog.md":"7c8ca16dfc1ad3c58a080d6f53eb250d03931ac455385b6b4f67b92fd3b616be","_posts/contact.md":"d1e789015df47d82215f1e6b483242c785509e84cc57760070537fd1692e0f39","_posts/contributing.md":"b85023503834959a5b6160ba1121708d2c5e0cfe2eb2641a9042891b834daabc","_posts/faqs.md":"9d57037632b02e9315b31c6da3ef890e4a7c084e76b51a44304f017d742295d6","_posts/formats.md":"1ea659800531779d2ec03c4a1cd37b4d687fff0afe8d46023bb1f12c4f4148fe","_posts/getting-started.md":"7f6af1169dc7c0fcc294d68a06e1d93e7b33b40fdaf7368e9a4e9f6a1e9174ae","_posts/index.md":"bdf93e711dfa2af73e87782fbc5667e541721b809572210799fac6e497b0bd06","_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 e8ff198..bbccee0 100644 --- a/public/.ssg-plugin-cache.json +++ b/public/.ssg-plugin-cache.json @@ -1,22 +1,22 @@ { - "public/404/index.html": 7259093385209876975, - "public/about/index.html": 12949456559420021308, - "public/accessibility/index.html": 5713522207449664177, - "public/api/index.html": 11397964784032987743, - "public/architecture/index.html": 6915802455650842912, - "public/benchmarks/index.html": 2021468413810795982, - "public/changelog/index.html": 18270345507824245213, - "public/contact/index.html": 10355855238041785199, - "public/contributing/index.html": 12520701021490290597, - "public/faqs/index.html": 11983471379327613372, - "public/formats/index.html": 1052158472452750897, - "public/getting-started/index.html": 1865910444430193385, - "public/index.html": 2989877783651903019, - "public/made-with-ssg/index.html": 2015761978985704885, - "public/offline/index.html": 6011093415955977822, - "public/privacy/index.html": 11811363588876036415, - "public/security/index.html": 14062708075236181358, - "public/terms/index.html": 141328437173614684, - "public/thanks/index.html": 8068784464901517319, - "public/use-cases/index.html": 15672533206450610668 + "public/404/index.html": 13575494870109021346, + "public/about/index.html": 6508004739747421000, + "public/accessibility/index.html": 1233551637845003055, + "public/api/index.html": 5254844140031320193, + "public/architecture/index.html": 851663481959891218, + "public/benchmarks/index.html": 12428704316268835746, + "public/changelog/index.html": 4625699870060108302, + "public/contact/index.html": 18071238935048083563, + "public/contributing/index.html": 6166182101035381425, + "public/faqs/index.html": 17038668637138867659, + "public/formats/index.html": 9589336268441412383, + "public/getting-started/index.html": 15910223332452642413, + "public/index.html": 11284954332199492997, + "public/made-with-ssg/index.html": 17700426430641059077, + "public/offline/index.html": 18253695968690479186, + "public/privacy/index.html": 11765054087992996563, + "public/security/index.html": 15702541847127712516, + "public/terms/index.html": 5924430751302939600, + "public/thanks/index.html": 16339271470989256153, + "public/use-cases/index.html": 5376738131758539388 } \ No newline at end of file diff --git a/public/.well-known/mcp.json b/public/.well-known/mcp.json index ccdc287..dc15ecb 100644 --- a/public/.well-known/mcp.json +++ b/public/.well-known/mcp.json @@ -15,7 +15,7 @@ "resources": [], "serverInfo": { "name": "Bank Statement Parser", - "version": "0.0.69" + "version": "0.0.72" }, "tools": [], "transport": { diff --git a/public/404.html b/public/404.html new file mode 100644 index 0000000..d68d4d1 --- /dev/null +++ b/public/404.html @@ -0,0 +1,64 @@ + Page Not Found (404 Error) | Bank Statement Parser +
    Bank Statement Parser Logo Bank Statement Parser

    Error 404

    Page Not Found

    The financial documentation resource you requested could not be located on this server.

    The requested financial documentation page does not exist or has been moved.

    Return to Homepage → View Documentation
    + +
    + + + + +
    + \ No newline at end of file diff --git a/public/404/index.html b/public/404/index.html index ea533b0..d68d4d1 100644 --- a/public/404/index.html +++ b/public/404/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    Error 404

    Page Not Found

    The financial documentation resource you requested could not be located on this server.

    The requested financial documentation page does not exist or has been moved.

    Return to Homepage → View Documentation
    diff --git a/public/404/rss.xml b/public/404/rss.xml index d111142..ed972ce 100644 --- a/public/404/rss.xml +++ b/public/404/rss.xml @@ -1 +1 @@ -Page Not Found (404 Error) | Bank Statement Parserhttps://bankstatementparser.com/404/The requested financial documentation page could not be located. Browse the documentation index, supported format specifications, or return to the homepage.en-GB \ No newline at end of file +Page Not Found (404 Error) | Bank Statement Parserhttps://bankstatementparser.com/404/The requested financial documentation page could not be located. Browse the documentation index, supported format specifications, or return to the homepage.en-GB \ No newline at end of file diff --git a/public/about/index.html b/public/about/index.html index 61a380c..05ed3ad 100644 --- a/public/about/index.html +++ b/public/about/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    Engineering & Leadership

    About Sebastien Rousseau

    Principal engineer building high-assurance, privacy-first financial infrastructure and cryptographic document tooling.

    Sebastien Rousseau

    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.
    diff --git a/public/about/rss.xml b/public/about/rss.xml index 61dc4e5..0835882 100644 --- a/public/about/rss.xml +++ b/public/about/rss.xml @@ -1 +1 @@ -About Sebastien Rousseau | Bank Statement Parser Authorhttps://bankstatementparser.com/about/Read the background and 19-year financial systems architecture history of Sebastien Rousseau, creator of the open-source Bank Statement Parser engine and tools.en-GB \ No newline at end of file +About Sebastien Rousseau | Bank Statement Parser Authorhttps://bankstatementparser.com/about/Read the background and 19-year financial systems architecture history of Sebastien Rousseau, creator of the open-source Bank Statement Parser engine and tools.en-GB \ No newline at end of file diff --git a/public/accessibility/index.html b/public/accessibility/index.html index 957eb35..2940785 100644 --- a/public/accessibility/index.html +++ b/public/accessibility/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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.
    diff --git a/public/accessibility/rss.xml b/public/accessibility/rss.xml index 83bf5a0..bfe0278 100644 --- a/public/accessibility/rss.xml +++ b/public/accessibility/rss.xml @@ -1 +1 @@ -Accessibility Statement: WCAG 2.2 Level AAA Compliancehttps://bankstatementparser.com/accessibility/Official accessibility statement confirming full WCAG 2.2 Level AAA compliance, high-contrast color ratios, and keyboard-first navigation across all platforms.en-GB \ No newline at end of file +Accessibility Statement: WCAG 2.2 Level AAA Compliancehttps://bankstatementparser.com/accessibility/Official accessibility statement confirming full WCAG 2.2 Level AAA compliance, high-contrast color ratios, and keyboard-first navigation across all platforms.en-GB \ No newline at end of file diff --git a/public/api/agents/index.json b/public/api/agents/index.json index 0d4d5ae..09435bc 100644 --- a/public/api/agents/index.json +++ b/public/api/agents/index.json @@ -17,5 +17,5 @@ "title": "Bank Statement Parser | Fast, Secure Financial Data Extraction", "url": "https://bankstatementparser.com" }, - "version": "0.0.69" + "version": "0.0.72" } diff --git a/public/api/agents/posts.json b/public/api/agents/posts.json index 8a601d6..597b555 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": 371 + "wordCount": 437 }, { "date": "2026-09-01", diff --git a/public/api/index.html b/public/api/index.html index 0de37ab..b87019e 100644 --- a/public/api/index.html +++ b/public/api/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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. Sensitive financial documents and banking statements remain strictly confined within your own compute environment.

    Air-gapped high-throughput financial document engineering architecture
    Air-gapped execution architecture: banking statements are tokenized and validated entirely within local memory with zero external telemetry.
    diff --git a/public/api/rss.xml b/public/api/rss.xml index a7589f5..45ea95b 100644 --- a/public/api/rss.xml +++ b/public/api/rss.xml @@ -1 +1 @@ -API Reference: Rust Crate & Python SDK Guidehttps://bankstatementparser.com/api/Complete API reference for Bank Statement Parser in Rust and Python with parameter schemas, zero-copy buffers, balance proofs, and transaction stream examples.en-GB \ No newline at end of file +API Reference: Rust Crate & Python SDK Guidehttps://bankstatementparser.com/api/Complete API reference for Bank Statement Parser in Rust and Python with parameter schemas, zero-copy buffers, balance proofs, and transaction stream examples.en-GB \ No newline at end of file diff --git a/public/architecture/index.html b/public/architecture/index.html index c0c9ee2..b9e5e40 100644 --- a/public/architecture/index.html +++ b/public/architecture/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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 <?xml version="1.0" to branch into streaming parser trees.
    • SWIFT MT940 / MT942: Checks for field delimiter sequences (:20:, :25:, :28C:) to route into deterministic line tokenizers.
    • CSV Delimited Files: Evaluates entropy across candidate delimiters (comma, semicolon, tab, pipe) over the first 50 rows to infer column geometry without full-file scans.

    Stage 2: Spatial Layout Tokenization

    For unstructured formats such as digital PDF statements, standard text extraction destroys critical vertical alignment. Bank Statement Parser utilizes a deterministic coordinate-clustering engine:

    • Glyph Extraction: Maps character matrices, font bounding boxes, and baseline coordinates from content stream operators (BT, ET, Tj, TJ, Tm).
    • Row Clustering: Groups glyphs with overlapping vertical tolerances into discrete lines, preventing footnote and header collision.
    • Column Geometric Alignment: Computes vertical whitespace gutters to delineate Booking Date, Value Date, Narrative, Amount, and Running Balance columns.
    • Multi-line Narrative Stitching: Heuristically associates wrapped description text back to the initiating transaction row.
    Bank Statement Parser — Pipeline Architecture and High-Throughput Engine
    High-assurance statement parsing: zero-copy memory mapping, deterministic tokenization, and ISO 20022 message synthesis.

    Stage 3: Field Normalization & Standard Mapping

    Extracted raw string tokens are converted into strongly-typed canonical primitives:

    • Date Canonicalization: Resolves 24 regional date formats (including DD/MM/YYYY, MM/DD/YYYY, YYYY-MM-DD, and multi-lingual month names) into ISO 8601 UTC timestamps.
    • Monetary Amounts: Parses European period/comma inversion (e.g., 1.234,56 vs 1,234.56), preserving scale as exact 64-bit fixed-point integers to eliminate IEEE 754 floating-point rounding drift.
    • Account & Bank Identifiers: Verifies ISO 13616 International Bank Account Numbers (IBAN) using mod-97 arithmetic (ISO 7064) and validates ISO 9362 Business Identifier Codes (BIC).
    • Transaction Code Classification: Maps proprietary transaction labels to standardized ISO 20022 Bank Transaction Codes (BTC), distinguishing card settlements, direct debits, credit transfers, and fee deductions.

    Stage 4: Mathematical Validation & Schema Synthesis

    Before any extracted statement is emitted, the engine evaluates strict balance invariants to guarantee data integrity:

    mathematical-invariant — balance check
    Invariant Equation: Opening_Balance + Sum(Credits) - Sum(Debits) == Closing_Balance
    # If Delta != 0.00, extraction fails with explicit discrepancy error and line offset

    Upon invariant satisfaction, the engine streams the normalized data tree into target schemas:

    • ISO 20022 CAMT.053: Generates conforming camt.053.001.08 Bank-to-Customer Statement XML messages ready for direct core banking and treasury ingest.
    • Canonical JSON: Emits clean, strongly-typed JSON with ISO 8601 dates and exact decimal numbers for downstream API consumption.
    • Reconciliation CSV: Serializes standardized transaction rows with consistent column headers for enterprise ERP systems.
    diff --git a/public/architecture/rss.xml b/public/architecture/rss.xml index c815a8d..d27c68c 100644 --- a/public/architecture/rss.xml +++ b/public/architecture/rss.xml @@ -1 +1 @@ -Architecture Blueprint: Deterministic Financial Parsinghttps://bankstatementparser.com/architecture/Explore the four-stage streaming architecture of Bank Statement Parser: zero-copy ingestion, lexical tokenization, balance proofs, and ISO 20022 emission.en-GB \ No newline at end of file +Architecture Blueprint: Deterministic Financial Parsinghttps://bankstatementparser.com/architecture/Explore the four-stage streaming architecture of Bank Statement Parser: zero-copy ingestion, lexical tokenization, balance proofs, and ISO 20022 emission.en-GB \ No newline at end of file diff --git a/public/benchmarks/index.html b/public/benchmarks/index.html index 87ca3d4..11f67ff 100644 --- a/public/benchmarks/index.html +++ b/public/benchmarks/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    Performance Metrics

    Performance Benchmarks & Throughput

    Empirical throughput and memory benchmarks comparing Bank Statement Parser against legacy Python and Java parser engines.

    Benchmarked on Apple Silicon (M-series) and Linux x86_64 server hardware across 50,000 multi-page banking statements.

    10,450
    Pages / Minute
    0.72 ms
    Average Latency
    18 MB
    Peak Memory (RSS)
    01

    Comparative Benchmark Matrix

    Empirical performance comparison processing standard 10-page commercial PDF bank statements with 150 transaction rows:

    Parser Engine Language Throughput (Pages/sec) Memory (RSS) Balance Check
    Bank Statement Parser Rust / Native 174 pages/sec 18 MB Mathematical (100%)
    PDFMiner.six Python (Pure) 3.8 pages/sec 145 MB None (Raw text)
    Camelot (Lattice) Python / OpenCV 1.2 pages/sec 380 MB None (Visual only)
    Tabula (Java) Java / JVM 8.4 pages/sec 512 MB None (Table grid)
    Apache PDFBox Java / JVM 14.1 pages/sec 290 MB None (Text layout)
    02

    Multi-Core Scaling & Parallelism

    Linear thread scalability benchmark across AMD EPYC 7763 (64-core) cloud instance ingesting batch directories:

    bash — benchmark throughput
    # Run benchmark suite over 10,000 statements with 16 parallel workers
    $bankstatementparser --benchmark --batch-dir ./dataset/ --threads 16
     
    Results: 10,000 files (48,200 pages) processed in 4.61 seconds
    Aggregate Throughput: 10,455.5 pages/min (174.2 pages/sec)
    Balance Validation Invariant: 100% passed (0 discrepancies)
    03

    Hardware Architecture Benchmark Callout

    The parser utilizes cache-friendly memory layouts, zero heap allocations in inner tokenizer loops, and SIMD vectorization for delimiter and byte scanning.

    High-throughput hardware benchmarks and low-latency processing
    Sub-millisecond processing: cache-friendly coordinate tokenization and linear multi-core scaling.
    diff --git a/public/benchmarks/rss.xml b/public/benchmarks/rss.xml index a729d16..e4a6587 100644 --- a/public/benchmarks/rss.xml +++ b/public/benchmarks/rss.xml @@ -1 +1 @@ -Performance Benchmarks: Latency & Throughputhttps://bankstatementparser.com/benchmarks/Empirical latency and throughput benchmarks demonstrating 10,000+ pages per minute and sub-millisecond bank statement parsing with zero memory leak overhead.en-GB \ No newline at end of file +Performance Benchmarks: Latency & Throughputhttps://bankstatementparser.com/benchmarks/Empirical latency and throughput benchmarks demonstrating 10,000+ pages per minute and sub-millisecond bank statement parsing with zero memory leak overhead.en-GB \ No newline at end of file diff --git a/public/changelog/index.html b/public/changelog/index.html index 06477b8..5517393 100644 --- a/public/changelog/index.html +++ b/public/changelog/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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.9] - 2026-11-01

    Fixed

    • Linked pages by their canonical URLs, kept non-indexable pages out of sitemap.xml, redirected /faq/ and /contribute/ to /faqs/ and /contributing/, and served the 404 page for missing URLs.

    Changed

    • Built the site with ssg 0.0.72.

    [0.0.8] - 2026-10-31

    Fixed

    • Restored the search widget assets and styles, and aligned the footer on a four-column grid.

    [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.
    • Documented Apache Parquet streaming (ParquetStreamWriter) and batch export alongside plain-text ledger models (hledger, beancount, ledger-cli).
    • Implemented Generative Engine Optimization (GEO) architecture with direct-answer BLUF headers and entity-based knowledge graphs.
    • Documented two-way bank reconciliation (reconcile_payments_and_statements), treasury analytics, and PDF forensics.

    Changed

    • Upgraded Static Site Generator (SSG) compilation and audit pipeline to the latest local version.
    • Linked copyright notice directly to author Sebastien Rousseau at https://sebastienrousseau.com/ across all layouts.

    [0.0.2] - 2026-09-27

    Fixed

    • 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/changelog/rss.xml b/public/changelog/rss.xml index a61a9fd..6dfce55 100644 --- a/public/changelog/rss.xml +++ b/public/changelog/rss.xml @@ -1 +1 @@ -Changelog & Semantic Version History: Release Noteshttps://bankstatementparser.com/changelog/Comprehensive release notes and semantic versioning history for Bank Statement Parser, detailing new format dialects, performance fixes, and security patches.en-GB \ No newline at end of file +Changelog & Semantic Version History: Release Noteshttps://bankstatementparser.com/changelog/Comprehensive release notes and semantic versioning history for Bank Statement Parser, detailing new format dialects, performance fixes, and security patches.en-GB \ No newline at end of file diff --git a/public/contact/index.html b/public/contact/index.html index 9e70371..b7ca110 100644 --- a/public/contact/index.html +++ b/public/contact/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    Get in Touch

    Contact & Enterprise Support

    Engage with our core engineering team for custom banking dialects, high-throughput SLAs, or enterprise licensing.

    Have a specialized bank statement format, high-volume batch requirement, or proprietary ERP integration?

    diff --git a/public/contact/rss.xml b/public/contact/rss.xml index 872f634..6934448 100644 --- a/public/contact/rss.xml +++ b/public/contact/rss.xml @@ -1 +1 @@ -Contact & Enterprise Inquiries | Bank Statement Parserhttps://bankstatementparser.com/contact/Get in touch with the Bank Statement Parser engineering team for custom bank dialect support, private cloud deployments, advisory, and enterprise integrations.en-GB \ No newline at end of file +Contact & Enterprise Inquiries | Bank Statement Parserhttps://bankstatementparser.com/contact/Get in touch with the Bank Statement Parser engineering team for custom bank dialect support, private cloud deployments, advisory, and enterprise integrations.en-GB \ No newline at end of file diff --git a/public/contribute/index.html b/public/contribute/index.html new file mode 100644 index 0000000..8eee17a --- /dev/null +++ b/public/contribute/index.html @@ -0,0 +1,25 @@ + + + + + +Page moved | Bank Statement Parser + + + + + + + + + + + + + +
    +

    This page has moved

    +

    Continue to https://bankstatementparser.com/contributing/.

    +
    + + diff --git a/public/contributing/index.html b/public/contributing/index.html index c9bf500..d8e61fb 100644 --- a/public/contributing/index.html +++ b/public/contributing/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    Community & Code

    Contributing to Bank Statement Parser

    Guidelines for bug reporting, code contributions, DCO sign-offs, and test-driven verification.

    Thank you for your interest in contributing to Bank Statement Parser. We welcome contributions for new regional statement dialects, zero-copy performance optimizations, parser rulebook definitions, and documentation improvements.

    01

    Local Development Environment Setup

    Bank Statement Parser is built in Rust with companion Python bindings. Ensure you have the stable Rust toolchain and Python 3.10+ installed:

    bash — clone & setup
    # Fork and clone repository
    $git clone https://github.com/YOUR_USERNAME/bankstatementparser.git
    $cd bankstatementparser
     
    # Build debug binary
    $cargo build
    02

    Test-Driven Verification & Invariants

    Every pull request must pass the automated test suite, clippy linter checks, and formatting verification. 100% test coverage on new parsing dialects is required:

    bash — test suite
    # Execute full test suite across all dialects
    $cargo test
     
    # Run strict Clippy linter with all features enabled
    $cargo clippy --all-targets --all-features -- -D warnings
     
    # Verify formatting conforms to rustfmt
    $cargo fmt --check
    03

    Sample Data & PII Sanitization Invariant

    To protect privacy and comply with data sovereignty regulations, never submit real-world bank statements containing Personally Identifiable Information (PII) or authentic account details:

    Data Field Invariant Requirement Verification Method
    IBAN Checksums Must use valid ISO 7064 Mod-97 test numbers Verified by test_sample_data_valid.rs
    SWIFT / BIC Structurally valid 8 or 11-char test BICs ISO 9362 structural regex validation
    Customer PII Synthetic names, anonymized street addresses Zero real customer records permitted
    Currencies Standard ISO 4217 currency identifiers (EUR, GBP, USD) Matched against official currency table
    04

    Commit Standards, DCO & Signing

    All contributions must follow Conventional Commits, be SSH/GPG signed, and carry a Developer Certificate of Origin (DCO) Signed-off-by trailer:

    bash — commit conventions
    # Commit with DCO sign-off (-s) and cryptographic signature (-S)
    $git commit -s -S -m "feat(dialect): add barclays corporate pdf extractor"
    diff --git a/public/contributing/rss.xml b/public/contributing/rss.xml index 5b26716..e2df733 100644 --- a/public/contributing/rss.xml +++ b/public/contributing/rss.xml @@ -1 +1 @@ -Contributing Guide: Code Standards & Testinghttps://bankstatementparser.com/contributing/Contributor guidelines for Bank Statement Parser covering Rust code conventions, mod-97 sample data verification, DCO signoffs, and automated test execution.en-GB \ No newline at end of file +Contributing Guide: Code Standards & Testinghttps://bankstatementparser.com/contributing/Contributor guidelines for Bank Statement Parser covering Rust code conventions, mod-97 sample data verification, DCO signoffs, and automated test execution.en-GB \ No newline at end of file diff --git a/public/faq/index.html b/public/faq/index.html new file mode 100644 index 0000000..6d490d2 --- /dev/null +++ b/public/faq/index.html @@ -0,0 +1,25 @@ + + + + + +Page moved | Bank Statement Parser + + + + + + + + + + + + + +
    +

    This page has moved

    +

    Continue to https://bankstatementparser.com/faqs/.

    +
    + + diff --git a/public/faqs/index.html b/public/faqs/index.html index fba5811..30643dc 100644 --- a/public/faqs/index.html +++ b/public/faqs/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    Questions & Answers

    Frequently Asked Questions

    Comprehensive guidance covering specifications, zero-telemetry local execution, performance, and commercial licensing.

    Showing 16 of 16 questions
    Architecture How does Bank Statement Parser achieve sub-millisecond parsing throughput?

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

    Formats Which bank statement standards and specifications are natively supported?

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

    • PDF Statements: Digital and scanned PDF 1.4–2.0 coordinate mapping, table boundaries, and offline OCR fallback.
    • CSV & Delimited: RFC 4180 auto-detecting delimiters (comma, semicolon, tab), date ordering, and decimal notations.
    • BAI2 Cash Management: North American standard (Records 01–99) with status codes and record 88 continuation lines.
    • SWIFT MT940 / MT942: End-of-day and interim intraday statements with structured field :86: sub-tag parsing.
    • ISO 20022 CAMT (052/053/054): Bank-to-customer statements, intraday reports, and credit/debit notifications.
    • ISO 20022 PAIN.001: Customer credit transfer initiation messages parsed for automated two-way reconciliation.
    • OFX / QFX: Open Financial Exchange SGML (1.x) and XML (2.x) banking and credit card statements.
    • Parquet & Ledger Exports: Columnar Apache Parquet streaming, and plain-text ledgers (hledger, beancount, ledger-cli).
    Architecture How are corrupted, malformed, or ambiguous statement entries handled?

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

    Formats Does Bank Statement Parser support scanned paper statements using OCR?

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

    Security Does Bank Statement Parser send financial documents or telemetry to remote servers?

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

    Privacy How can enterprise compliance teams verify zero-network egress in air-gapped environments?

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

    Security Are bank statements or parsed transaction records cached or written to disk?

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

    Supply Chain How are release artifacts, dependencies, and SBOMs cryptographically verified?

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

    Rust How do I integrate Bank Statement Parser into an existing Rust application?

    Add the dependency to your Cargo.toml:

    [dependencies]
bankstatementparser = "0.0.2"

    Then parse any statement file into strongly-typed structures:

    use bankstatementparser::Parser;
use std::path::Path;
fn main() -> Result<(), Box<dyn std::error::Error>> {
    let parser = Parser::new();
    let statement = parser.parse_file(Path::new("statement.pdf"))?;
    println!("Account: {}, Balance: {}", statement.account_id, statement.closing_balance);
    Ok(())
}
    Python Is there a native Python SDK, and does it require a local Rust toolchain?

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

    pip install bankstatementparser

    And use it in Python:

    from bankstatementparser import parse_statement
statement = parse_statement("statement.pdf")
print(f"Transactions parsed: {len(statement.transactions)}")
    Docker Can I execute Bank Statement Parser as a containerized microservice or Docker image?

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

    docker run --rm -v $(pwd):/data ghcr.io/sebastienrousseau/bankstatementparser:latest --input /data/statement.pdf --format json
    Performance How does parallel multi-threading scale across large statement directories?

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

    Licensing Can Bank Statement Parser be embedded in commercial enterprise software?

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

    ISO 20022 How does the validation engine verify ISO 20022 CAMT.053 schemas and balance proofs?

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

    Enterprise Is custom bank statement dialect or bespoke layout template mapping supported?

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

    Support What enterprise support options, service level agreements (SLAs), and custom integrations are available?

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

    No matching questions found

    Try searching for broader terms such as “Docker”, “ISO 20022”, “Python”, or “OCR”.

    Have a question not listed here?

    Our core engineering team and community stewards are available to assist. Explore the documentation guides, join our GitHub community discussions, or contact our solutions engineers directly.

    Getting Started Guide GitHub Discussions Contact Support
    diff --git a/public/faqs/rss.xml b/public/faqs/rss.xml index 5faa497..728f4b8 100644 --- a/public/faqs/rss.xml +++ b/public/faqs/rss.xml @@ -1 +1 @@ -Frequently Asked Questions: Bank Statement Parser FAQhttps://bankstatementparser.com/faqs/Get clear answers regarding Bank Statement Parser format dialects, zero-telemetry security, ISO 20022 schemas, local OCR modules, and enterprise SDK licensing.en-GB \ No newline at end of file +Frequently Asked Questions: Bank Statement Parser FAQhttps://bankstatementparser.com/faqs/Get clear answers regarding Bank Statement Parser format dialects, zero-telemetry security, ISO 20022 schemas, local OCR modules, and enterprise SDK licensing.en-GB \ No newline at end of file diff --git a/public/formats/index.html b/public/formats/index.html index 97ce30e..99d218a 100644 --- a/public/formats/index.html +++ b/public/formats/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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 during multi-account batch ingestion.

    5. Delimited CSV Statements

    CSV is the most ubiquitous yet least standardized financial format. Bank Statement Parser implements a statistical dialect inference engine that automatically determines:

    • Delimiter Detection: Comma (,), semicolon (;), tab (\t), or pipe (|).
    • Date Formatting: ISO 8601 (YYYY-MM-DD), European (DD/MM/YYYY), and US (MM/DD/YYYY) formats inferred from semantic date distributions.
    • Number & Currency Notation: Automatic handling of periods vs. commas for thousand separators and decimal points (e.g. 1,234.56 vs. 1.234,56).
    • Amount Semantics: Automatic detection of unified signed amount columns or split Debit / Credit column layouts.

    6. Digital and Scanned PDF Statements

    Financial institutions frequently deliver statements in PDF format. Bank Statement Parser provides a dual-mode engine for complete document recovery:

    • Digital / Vector PDFs: High-speed extraction directly from internal text streams and spatial coordinates, preserving table columns across multi-page boundaries with sub-millisecond execution.
    • Scanned Image Statements: Optional local, offline OCR and vision fallback models parse bitmap PDFs (TIFF, PNG, scanned documents) into layout-aware bounding boxes without sending a single byte outside your private network.
    • Forensics & Tamper Verification: Automated PDF forensics check for font anomalies, metadata discrepancies, and hidden modification layers to detect altered statements.

    7. Analytical & Accounting Export Targets

    In addition to strongly-typed JSON and CSV, Bank Statement Parser supports industrial streaming analytics and plain-text accounting ledger pipelines:

    • Streaming Apache Parquet (ParquetStreamWriter): High-performance, columnar Parquet export with snappy or zstd compression. Supports streaming hundreds of thousands of transactions directly to disk or S3 with constant memory usage.
    • Plain-Text Accounting (PTA): Native export formats for hledger, beancount, and ledger-cli double-entry bookkeeping systems.
    • Pandas & Polars DataFrames: Zero-copy integration into Polars and Pandas analytics pipelines via bankstatementparser[parquet] and bankstatementparser[polars] extras.
    diff --git a/public/formats/rss.xml b/public/formats/rss.xml index aff3498..6dff633 100644 --- a/public/formats/rss.xml +++ b/public/formats/rss.xml @@ -1 +1 @@ -Supported Statement Formats: PDF, CSV, OFX, MT940, CAMT, BAI2https://bankstatementparser.com/formats/Comprehensive format specifications for 8 structured financial formats: CAMT (052/053/054), PAIN.001, MT940, MT942, OFX/QFX, BAI2, CSV, and PDF statements.en-GB \ No newline at end of file +Supported Statement Formats: PDF, CSV, OFX, MT940, CAMT, BAI2https://bankstatementparser.com/formats/Comprehensive format specifications for 8 structured financial formats: CAMT (052/053/054), PAIN.001, MT940, MT942, OFX/QFX, BAI2, CSV, and PDF statements.en-GB \ No newline at end of file diff --git a/public/getting-started/index.html b/public/getting-started/index.html index 5155c7b..244d90f 100644 --- a/public/getting-started/index.html +++ b/public/getting-started/index.html @@ -38,7 +38,7 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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<dyn std::error::Error>> {
        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:

    High-throughput financial document engineering architecture
    Air-gapped execution architecture: banking statements are tokenized and validated entirely within local memory with zero external telemetry.
    diff --git a/public/getting-started/rss.xml b/public/getting-started/rss.xml index 497751f..a5462a2 100644 --- a/public/getting-started/rss.xml +++ b/public/getting-started/rss.xml @@ -1 +1 @@ -Getting Started: Install CLI & Native Python/Rust SDKhttps://bankstatementparser.com/getting-started/Step-by-step installation instructions for Bank Statement Parser via Cargo, Pip, Homebrew, and Docker with immediate CLI execution and Python code examples.en-GB \ No newline at end of file +Getting Started: Install CLI & Native Python/Rust SDKhttps://bankstatementparser.com/getting-started/Step-by-step installation instructions for Bank Statement Parser via Cargo, Pip, Homebrew, and Docker with immediate CLI execution and Python code examples.en-GB \ No newline at end of file diff --git a/public/index.html b/public/index.html index f760772..35819b6 100644 --- a/public/index.html +++ b/public/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    Financial Document Engineering · Open Source

    Parse 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 Formats
    • Deterministic Rust Core
    • Zero Cloud Dependencies
    • 100% Air-Gapped Privacy
    • 10,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 and real-time financial ledger analytics dashboard in modern banking operations

    Corporate Treasury Automation

    Automated Reconciliation for Modern Treasury

    Eliminate 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 Architecture

    Engineered for absolute accuracy.

    Industrial-grade financial parsing combining memory-safe Rust execution, native Python bindings, and dual Apache/MIT licensing.

    01

    Multi-Format Dialect Engine

    Deterministic 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.

    02

    Arithmetic Balance Verification

    Strict mathematical balance validation ensures opening balance plus net credits and debits precisely equals closing balance to the penny before record emission.

    03

    ISO 20022 Harmonization

    Normalize 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 Pipeline

    From raw bank document to validated ledger transactions.

    1

    Ingest

    Stream PDF bytes, CSV feeds, BAI2 files, or SWIFT MT940/MT942 messages into memory-safe zero-copy buffers.

    Sub-millisecond stream loading
    2

    Tokenize

    Deterministic lexical analysis identifies account metadata, booking dates, line items, and structured :86: sub-tags.

    Deterministic layout analysis
    3

    Verify

    Arithmetic balance reconciliation confirms credit/debit integrity, checks PDF forensics, and validates IBAN checksums.

    Mod-97 and balance proofs
    4

    Emit

    Output strongly-typed JSON, streaming Apache Parquet, Plain-Text Ledgers (hledger, beancount), or ISO 20022 messages.

    Ready for ERP, Lakehouse & GL
    Iconic financial architecture of London at night, highlighting high-assurance parsing infrastructure

    High-Performance Pipeline

    Deterministic Execution at Enterprise Scale

    Engineered for high-frequency financial platforms requiring bounded latency, zero-allocation loops, and strict ISO 20022 data models.

    View Architecture Blueprint

    Developer Quickstart

    Install via Cargo, Pip, or Homebrew in Seconds

    Deploy 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 Privacy

    Your 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 Answers

    Frequently Asked Questions

    Does 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 engine extracts structured text streams directly with zero loss. For scanned image statements, an optional local OCR module performs deterministic optical layout parsing with zero external cloud API dependencies.

    Is the project open source and available for commercial use?

    Yes. Bank Statement Parser is dual-licensed under the Apache-2.0 and MIT open-source licenses. You can freely integrate it into commercial SaaS products, enterprise backends, and internal financial pipelines.

    Developer Quickstart

    Financial data is mission-critical.
    Your parsing pipeline should be instant.

    Get started in minutes with the Rust CLI or Python package across Linux, macOS, and Windows.

    Install Bank Statement Parser
    diff --git a/public/llms-full.txt b/public/llms-full.txt index b84a952..24ab1f4 100644 --- a/public/llms-full.txt +++ b/public/llms-full.txt @@ -39,8 +39,8 @@

    Parse 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 Formats +Install CLI & SDK +Explore Supported Formats
    • Deterministic Rust Core
      • @@ -83,7 +83,7 @@

      Corporate Treasury Automation

      Automated Reconciliation for Modern Treasury

      Eliminate 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 +View Treasury Playbook
    @@ -158,7 +158,7 @@

    High-Performance Pipeline

    Deterministic Execution at Enterprise Scale

    Engineered for high-frequency financial platforms requiring bounded latency, zero-allocation loops, and strict ISO 20022 data models.

    -View Architecture Blueprint +View Architecture Blueprint
    @@ -170,8 +170,8 @@

    Install via Cargo, Pip, or Homebrew in Seconds

    Deploy 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 +Full Documentation → +API Reference
    @@ -201,7 +201,7 @@

    Your 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 +Read Security & Privacy Architecture
    @@ -240,7 +240,7 @@

    Get started in minutes with the Rust CLI or Python package across Linux, macOS, and Windows.

    -Install Bank Statement Parser +Install Bank Statement Parser
    @@ -1661,7 +1661,7 @@ Financial statement data demands strict confidentiality, rigorous boundary isola
    -

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

    +

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

    @@ -1679,9 +1679,9 @@ Financial statement data demands strict confidentiality, rigorous boundary isola

    Have a question not listed here?

    Our core engineering team and community stewards are available to assist. Explore the documentation guides, join our GitHub community discussions, or contact our solutions engineers directly.

    -Getting Started Guide +Getting Started Guide GitHub Discussions -Contact Support +Contact Support
    @@ -1716,6 +1716,16 @@ 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.9] - 2026-11-01 +### Fixed +- Linked pages by their canonical URLs, kept non-indexable pages out of `sitemap.xml`, redirected `/faq/` and `/contribute/` to `/faqs/` and `/contributing/`, and served the 404 page for missing URLs. +### Changed +- Built the site with `ssg` 0.0.72. + +## [0.0.8] - 2026-10-31 +### Fixed +- Restored the search widget assets and styles, and aligned the footer on a four-column grid. + ## [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`. diff --git a/public/made-with-ssg/index.html b/public/made-with-ssg/index.html index e395ee9..1788332 100644 --- a/public/made-with-ssg/index.html +++ b/public/made-with-ssg/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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.
    diff --git a/public/made-with-ssg/rss.xml b/public/made-with-ssg/rss.xml index 49b5bac..86d1ff0 100644 --- a/public/made-with-ssg/rss.xml +++ b/public/made-with-ssg/rss.xml @@ -1 +1 @@ -Made with Static Site Generator (SSG) | Web Platformhttps://bankstatementparser.com/made-with-ssg/Learn how the Bank Statement Parser documentation site is built using Rust Static Site Generator (SSG), featuring strict CSP, WCAG AAA audits, and fast builds.en-GB \ No newline at end of file +Made with Static Site Generator (SSG) | Web Platformhttps://bankstatementparser.com/made-with-ssg/Learn how the Bank Statement Parser documentation site is built using Rust Static Site Generator (SSG), featuring strict CSP, WCAG AAA audits, and fast builds.en-GB \ No newline at end of file diff --git a/public/offline/index.html b/public/offline/index.html index 1df4722..ca4d189 100644 --- a/public/offline/index.html +++ b/public/offline/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    Network Disconnected

    You Are Currently Offline

    Documentation is cached locally via service worker for uninterrupted offline engineering.

    Bank Statement Parser documentation has been cached for offline availability. Check your internet connection to refresh live data feeds.

    diff --git a/public/offline/rss.xml b/public/offline/rss.xml index 8060850..5b8597b 100644 --- a/public/offline/rss.xml +++ b/public/offline/rss.xml @@ -1 +1 @@ -Offline Documentation Access | Bank Statement Parserhttps://bankstatementparser.com/offline/Offline documentation fallback for Bank Statement Parser. Access cached developer guides, format specifications, and API references with zero network access.en-GB \ No newline at end of file +Offline Documentation Access | Bank Statement Parserhttps://bankstatementparser.com/offline/Offline documentation fallback for Bank Statement Parser. Access cached developer guides, format specifications, and API references with zero network access.en-GB \ No newline at end of file diff --git a/public/privacy/index.html b/public/privacy/index.html index bd23b44..4d04a63 100644 --- a/public/privacy/index.html +++ b/public/privacy/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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:

    1. 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.
    2. No Tracking Cookies: This documentation website does not use tracking cookies, analytics pixels, or third-party behavioral scripts.
    3. Data Protection Compliance: Fully compliant with GDPR, UK Data Protection Act 2018, and California Consumer Privacy Act (CCPA).
    diff --git a/public/privacy/rss.xml b/public/privacy/rss.xml index 65378a9..e97a1f1 100644 --- a/public/privacy/rss.xml +++ b/public/privacy/rss.xml @@ -1 +1 @@ -Zero-Telemetry Privacy Guarantee & Data Protectionhttps://bankstatementparser.com/privacy/Official privacy policy confirming Bank Statement Parser collects zero telemetry, uses zero cookies, and executes completely air-gapped on your infrastructure.en-GB \ No newline at end of file +Zero-Telemetry Privacy Guarantee & Data Protectionhttps://bankstatementparser.com/privacy/Official privacy policy confirming Bank Statement Parser collects zero telemetry, uses zero cookies, and executes completely air-gapped on your infrastructure.en-GB \ No newline at end of file diff --git a/public/sbom.cdx.json b/public/sbom.cdx.json index 100c17a..a3941c8 100644 --- a/public/sbom.cdx.json +++ b/public/sbom.cdx.json @@ -2,7 +2,7 @@ "bomFormat": "CycloneDX", "components": [ { - "bom-ref": "ssg@0.0.69", + "bom-ref": "ssg@0.0.72", "description": "Static site generator", "externalReferences": [ { @@ -27,9 +27,9 @@ } ], "name": "ssg", - "purl": "pkg:cargo/ssg@0.0.69", + "purl": "pkg:cargo/ssg@0.0.72", "type": "application", - "version": "0.0.69" + "version": "0.0.72" } ], "metadata": { @@ -39,16 +39,16 @@ "name": "static-site", "type": "application" }, - "timestamp": "2026-10-31T13:37:48Z", + "timestamp": "2026-11-01T18:16:42Z", "tools": [ { "name": "ssg", "vendor": "SSG Contributors", - "version": "0.0.69" + "version": "0.0.72" } ] }, - "serialNumber": "urn:uuid:c9b5a42b-b246-894b-aaba-b6c56cacad79", + "serialNumber": "urn:uuid:49b38c7b-aebc-8e4e-ae00-71397b125911", "specVersion": "1.5", "version": 1 } \ No newline at end of file diff --git a/public/search-index.json b/public/search-index.json index 671a2e6..7d4a137 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/public/security/index.html b/public/security/index.html index f04393c..c0d94d4 100644 --- a/public/security/index.html +++ b/public/security/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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 security architecture and air-gapped statement parsing
    Cryptographic integrity: every binary is Sigstore-signed, air-gapped, and accompanied by a CycloneDX SBOM.
    diff --git a/public/security/rss.xml b/public/security/rss.xml index f928810..f136167 100644 --- a/public/security/rss.xml +++ b/public/security/rss.xml @@ -1 +1 @@ -Security Architecture: Air-Gapped & Memory-Safe Parsinghttps://bankstatementparser.com/security/Examine the zero-telemetry security model of Bank Statement Parser: memory-safe Rust execution, air-gapped processing, Sigstore signing, and CycloneDX SBOMs.en-GB \ No newline at end of file +Security Architecture: Air-Gapped & Memory-Safe Parsinghttps://bankstatementparser.com/security/Examine the zero-telemetry security model of Bank Statement Parser: memory-safe Rust execution, air-gapped processing, Sigstore signing, and CycloneDX SBOMs.en-GB \ No newline at end of file diff --git a/public/sitemap.xml b/public/sitemap.xml index dde58b5..0c60fac 100644 --- a/public/sitemap.xml +++ b/public/sitemap.xml @@ -2,109 +2,109 @@ https://bankstatementparser.com/ - 2026-10-31 + 2026-11-01 daily 1.0 https://bankstatementparser.com/about/ - 2026-10-31 + 2026-11-01 weekly 0.8 https://bankstatementparser.com/accessibility/ - 2026-10-31 + 2026-11-01 monthly 0.5 https://bankstatementparser.com/api/ - 2026-10-31 + 2026-11-01 weekly 0.9 https://bankstatementparser.com/architecture/ - 2026-10-31 + 2026-11-01 weekly 0.9 https://bankstatementparser.com/benchmarks/ - 2026-10-31 + 2026-11-01 weekly 0.9 https://bankstatementparser.com/changelog/ - 2026-10-31 + 2026-11-01 weekly 0.8 https://bankstatementparser.com/contact/ - 2026-10-31 + 2026-11-01 weekly 0.8 https://bankstatementparser.com/contributing/ - 2026-10-31 + 2026-11-01 monthly 0.5 https://bankstatementparser.com/faqs/ - 2026-10-31 + 2026-11-01 weekly 0.9 https://bankstatementparser.com/formats/ - 2026-10-31 + 2026-11-01 weekly 0.9 https://bankstatementparser.com/getting-started/ - 2026-10-31 + 2026-11-01 weekly 0.9 https://bankstatementparser.com/made-with-ssg/ - 2026-10-31 + 2026-11-01 monthly 0.5 https://bankstatementparser.com/privacy/ - 2026-10-31 + 2026-11-01 monthly 0.5 https://bankstatementparser.com/security/ - 2026-10-31 + 2026-11-01 weekly 0.9 https://bankstatementparser.com/terms/ - 2026-10-31 + 2026-11-01 monthly 0.5 https://bankstatementparser.com/thanks/ - 2026-10-31 + 2026-11-01 monthly 0.5 https://bankstatementparser.com/use-cases/ - 2026-10-31 + 2026-11-01 weekly 0.9 diff --git a/public/sw.js b/public/sw.js index d37b698..b7b648b 100644 --- a/public/sw.js +++ b/public/sw.js @@ -6,7 +6,7 @@ 'use strict'; -var CACHE_NAME = 'bsp-docs-v0.0.8'; +var CACHE_NAME = 'bsp-docs-v0.0.9'; var OFFLINE_URL = '/offline/index.html'; var PRECACHE_URLS = [ '/', diff --git a/public/terms/index.html b/public/terms/index.html index 371c064..3501f55 100644 --- a/public/terms/index.html +++ b/public/terms/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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.

    diff --git a/public/terms/rss.xml b/public/terms/rss.xml index 697462b..13b0a68 100644 --- a/public/terms/rss.xml +++ b/public/terms/rss.xml @@ -1 +1 @@ -Terms of Use & Dual Open-Source License Specificationshttps://bankstatementparser.com/terms/Terms of use and dual open-source licensing guidelines governing Bank Statement Parser under Apache-2.0 and MIT terms for community and enterprise developers.en-GB \ No newline at end of file +Terms of Use & Dual Open-Source License Specificationshttps://bankstatementparser.com/terms/Terms of use and dual open-source licensing guidelines governing Bank Statement Parser under Apache-2.0 and MIT terms for community and enterprise developers.en-GB \ No newline at end of file diff --git a/public/thanks/index.html b/public/thanks/index.html index a1065cd..3c78199 100644 --- a/public/thanks/index.html +++ b/public/thanks/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    Message Dispatched

    Thank You for Your Message

    Your inquiry has been securely routed to our engineering team. We will respond within one business day.

    We have received your inquiry regarding Bank Statement Parser. A systems engineer will respond within one business day.

    Return to Homepage →
    diff --git a/public/thanks/rss.xml b/public/thanks/rss.xml index 035b3d2..cba6bc8 100644 --- a/public/thanks/rss.xml +++ b/public/thanks/rss.xml @@ -1 +1 @@ -Thank You for Your Inquiry | Bank Statement Parserhttps://bankstatementparser.com/thanks/Thank you for contacting Bank Statement Parser. Our financial infrastructure engineering team will review your statement dialect requirements and respond soon.en-GB \ No newline at end of file +Thank You for Your Inquiry | Bank Statement Parserhttps://bankstatementparser.com/thanks/Thank you for contacting Bank Statement Parser. Our financial infrastructure engineering team will review your statement dialect requirements and respond soon.en-GB \ No newline at end of file diff --git a/public/use-cases/index.html b/public/use-cases/index.html index 0d87e80..b21b444 100644 --- a/public/use-cases/index.html +++ b/public/use-cases/index.html @@ -38,12 +38,12 @@ ] } -
    Bank Statement Parser Logo Bank Statement Parser

    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
    Historical Batch Throughput Limited by cloud API rate-limits & cost 10,450 pages/minute on workstation hardware
    IBAN & BIC Validation Unchecked strings with OCR transcription drift ISO 13616 Mod-97 and ISO 9362 structural validation
    Evidentiary Audit Trail Lossy, potentially hallucinated text Deterministic byte-exact coordinate provenance
    bash — air-gapped aml extraction
    # Air-gapped forensic extraction to normalized JSON stream
    $bankstatementparser --offline --extract-counterparties --format jsonl ./seized_records/ > aml_graph.jsonl
     
    Audit Log: Processed 54,200 pages in 5.18 seconds
    Entities Extracted: 3,412 unique IBANs, 194 distinct BICs validated
    05

    Enterprise Deployment Architecture

    Bank Statement Parser deploys flexibly across enterprise architectures: as a standalone native CLI binary, a zero-overhead microservice sidecar in Kubernetes clusters, or an embedded library in Python, Rust, and WebAssembly applications.

    Enterprise corporate treasury and automated banking workflow architecture
    Enterprise orchestration: zero-network document ingestion for real-time treasury and audit operations.
    diff --git a/public/use-cases/rss.xml b/public/use-cases/rss.xml index 89a0820..667582d 100644 --- a/public/use-cases/rss.xml +++ b/public/use-cases/rss.xml @@ -1 +1 @@ -Fintech Use Cases: Treasury & Reconciliationhttps://bankstatementparser.com/use-cases/Discover enterprise deployment architectures for corporate treasury automation, lending underwriting, ledger reconciliation, and forensic accounting pipelines.en-GB \ No newline at end of file +Fintech Use Cases: Treasury & Reconciliationhttps://bankstatementparser.com/use-cases/Discover enterprise deployment architectures for corporate treasury automation, lending underwriting, ledger reconciliation, and forensic accounting pipelines.en-GB \ No newline at end of file diff --git a/sw.js b/sw.js index d37b698..b7b648b 100644 --- a/sw.js +++ b/sw.js @@ -6,7 +6,7 @@ 'use strict'; -var CACHE_NAME = 'bsp-docs-v0.0.8'; +var CACHE_NAME = 'bsp-docs-v0.0.9'; var OFFLINE_URL = '/offline/index.html'; var PRECACHE_URLS = [ '/',