Content Brief: MT940 vs BAI2

**Target URL:** `/learn/banking-statement-formats-mt940-vs-bai2`
**Target Query:** mt940 vs bai2
**Intent:** Understanding the differences between the two most common bank statement formats to inform parser development and treasury reconciliation strategies.

---

1. Direct Answer Paragraph
*To be placed immediately after H1.*

When evaluating electronic bank statement formats, the primary difference between MT940 and BAI2 is their regional origin and structural design. **MT940** is a SWIFT international standard built on a tag-based architecture (e.g., `:61:` for transactions) that dominates global and European banking. In contrast, **BAI2** was developed by the Bank Administration Institute and is the standard for North American corporate banking, utilizing a hierarchical, comma-delimited record structure (e.g., `16` for transaction details). While MT940 relies heavily on a single free-text field (Tag 86) for transaction context, BAI2 uses highly granular, 3-digit type codes to specifically identify different credits, debits, and balance types like ledger and float, making it better suited for complex US cash management.

2. Architecture Diagram
**Image Type:** SVG/PNG
**Alt Text:** Structural comparison of MT940 and BAI2 bank statement files. The MT940 side illustrates a flat, tag-based block showing opening balance, a transaction line, and unstructured narrative text in Tag 86. The BAI2 side depicts a hierarchical structure flowing from a File Header (01) down to Account Identifiers (03), granular Transaction Details (16) with 3-digit type codes, and Continuation Records (88).

3. H2 Sections

H2: The Global Standard: MT940
Developed by SWIFT, the MT940 (Customer Statement Message) is the benchmark for international bank-to-customer reporting. It is designed to deliver end-of-day account snapshots across borders.
*(Expand on its strict tag-based structure, the reliance on opening (`:60F:`) and closing (`:62F:`) balances, and why it is the default for multi-currency, multi-national treasury operations).*

H2: The North American Standard: BAI2
BAI2 is the dominant format for US domestic cash management. Its record-based, comma-delimited architecture allows banks to report highly detailed intra-day and end-of-day activity.
*(Expand on the hierarchical nesting of records—File, Group, Account, Detail—and how it handles complex US banking requirements like One-Day Float and Closing Available balances).*

H2: Parsing Complexities and Reconciliation
Building parsers for these formats presents distinct engineering challenges. MT940 requires robust logic to extract structured data (like invoice numbers or counterparties) out of the unstructured free-text `:86:` tag. Conversely, BAI2 parsers must maintain state across hierarchical rows and correctly handle `88` continuation records that split data across multiple lines.
*(Expand on how NAYA's reconciliation engine normalizes these disparate structures into a single canonical ledger format).*

4. Comparison Table
| Feature | MT940 | BAI2 |
| :--- | :--- | :--- |
| **Primary Region** | Global / Europe / Asia | North America |
| **Governing Body** | SWIFT | Bank Administration Institute |
| **File Structure** | Flat, Tag-based (e.g., `:61:`) | Hierarchical, Record-based (e.g., `16`) |
| **Transaction Detail** | Unstructured (packed in Tag 86) | Granular (3-digit Type Codes) |
| **Balance Reporting** | Opening and Closing | Ledger, Available, Float, etc. |
| **Customization** | Strict / Standardized | Highly bank-specific variations |

5. Edge Cases & Gotchas
### H2: Integration Edge Cases & Gotchas
- **Tag 86 Parsing Hell (MT940):** Because Tag 86 is unstructured, different banks (or even different branches of the same bank) will pack counterparty names, references, and fees into it differently. Your parser must rely on bank-specific regex patterns or AI-assisted extraction.
- **BAI2 Continuation Records (88):** In BAI2, if a transaction description exceeds a certain length, it wraps to a new line starting with `88`. Parsers must proactively look ahead and concatenate these records before processing the transaction.
- **Bank Dialects (BAI2):** While BAI2 has standard 3-digit type codes (e.g., `108` for Credit Memo), banks frequently invent custom codes or misuse standard ones. You must build a translation layer that maps bank-specific dialects to your canonical transaction types.
- **Intra-day vs End-of-day:** BAI2 natively supports rich intra-day reporting, whereas MT940 is traditionally end-of-day. If you require real-time visibility, ensure your MT940 feed is supplemented by MT942 (intra-day) messages.

6. FAQ Schema
*(To be encoded as JSON-LD FAQPage Schema)*

**Q: Can a company use MT940 in the US?**
A: Yes, but it is less common. Large US banks can provide MT940 statements for international corporate clients, but BAI2 remains the native and more detailed standard for domestic US accounts.

**Q: How does BAI2 handle transaction details differently than MT940?**
A: BAI2 uses specific 3-digit type codes to categorize transactions (e.g., identifying a check deposit vs. a wire transfer). MT940 relies on a more generic code and places the specific details in an unstructured free-text field (Tag 86).

**Q: What is a BAI2 continuation record?**
A: Because BAI2 lines have length limits, long transaction details wrap to the next line. These wrapped lines start with the code `88` and must be combined with the preceding transaction record by your parser.

**Q: Are these formats being replaced?**
A: Yes, both MT940 and BAI2 are gradually being phased out in favor of the newer, XML-based ISO 20022 standard (specifically the camt.053 format), though the transition will take many years.

**Q: Why is parsing MT940 difficult?**
A: The main difficulty lies in Tag 86, which contains the narrative description of the transaction. Because it lacks strict sub-fields, extracting structured data like invoice numbers requires complex, bank-specific parsing rules.

7. Author Schema
- **Author Name:** Engineering Team
- **Credentials:** NAYA Infrastructure Engineering
- **LinkedIn:** https://www.linkedin.com/company/naya-finance

8. Internal Links
1. `/platform/reconciliation`
2. `/platform/ledger`
3. `/glossary/iso-20022`
4. `/glossary/bank-reconciliation`