Supported Statement Formats & Specifications

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.

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.