Fixed-Width Files and Why Banks Still Use Them

Open a payment file from a large bank's batch system and you may find no commas, no tags, no JSON braces — just dense rows of characters where every field lives at a fixed column position. These are fixed-width (or positional) files, and despite decades of newer formats, they remain the backbone of payroll, direct debit, and bulk-payment processing at many institutions. Understanding why they endure is a lesson in how banking technology actually evolves.

What a fixed-width file is

In a fixed-width format, each field occupies a predetermined range of character positions within a line, and there are no delimiters between fields. A record might specify that positions 1–2 hold a record type, 3–12 hold an account number, 13–24 hold an amount, and so on. To parse it, you do not split on a separator — you slice the string at known offsets defined by a file specification.

Amounts are typically stored as integers in the smallest currency unit (cents or pence) with implied decimal places, right-justified and zero-padded. Text fields are left-justified and space-padded to fill their width. Because every record is the same length, files often carry a header record, many detail records, and a trailer record with control totals — a count of records and a sum of amounts — so the receiver can verify nothing was lost or corrupted.

Formats you will still meet

Fixed-width is not a single standard but a family of scheme- and bank-specific layouts. The US ACH (Nacha) file format is a classic example: 94-character records, with a file header (record type 1), batch headers (5), entry detail records (6), addenda (7), batch control (8), and file control (9). The UK's Bacs Standard 18 format is another positional layout for direct debits and credits. Many card schemes, clearing systems, and core banking platforms define their own positional formats for bulk exchange.

Why banks still use them

Given richer alternatives exist, the persistence of fixed-width files comes down to concrete engineering realities:

• Compactness. No tags or delimiters means less overhead per record — meaningful when processing millions of transactions in a nightly batch.
• Deterministic parsing. Fixed offsets are trivial and fast to read in any language, including the COBOL that still runs core banking. There is no parser ambiguity.
• Stability. These formats have been stable for decades. Systems, contracts, and reconciliation tooling are built around them, and the cost and risk of changing a format touched by dozens of downstream systems is enormous.
• Mainframe fit. Fixed-length records map naturally to how mainframe and COBOL copybook data structures work, avoiding costly transformation at the boundary.

The trade-offs

Fixed-width formats pay for their efficiency in flexibility. Adding a field usually means expanding record widths and coordinating a change across every system that reads the file — a slow, high-risk process. They carry no self-description: a file is meaningless without its written specification, so a wrong offset or an undocumented variant silently corrupts data. Character encoding matters intensely, since a single extra byte shifts every subsequent field. And they lack the structured, richly typed remittance data that ISO 20022 offers, which is a major reason schemes are migrating.

Working with them safely

If you have to integrate with fixed-width files, a few practices prevent pain. Drive parsing from a declarative field map (name, start, length, type) rather than hard-coded slices, so the spec lives in one place. Always validate the trailer control totals — record count and amount sum — before trusting a file. Be strict about padding and justification when generating files, because a misaligned field will be accepted and misread rather than rejected. And treat encoding explicitly; assume nothing about ASCII versus EBCDIC when the counterparty is a mainframe. The broader industry is moving toward ISO 20022, but fixed-width will remain in production for years, so treating it as a first-class integration format — not a legacy afterthought — is the pragmatic stance.

Key takeaways

• Fixed-width files place each field at fixed character positions with no delimiters; you parse by offset, not by splitting.
• Records typically come as header/detail/trailer, with control totals (count and amount sum) for integrity checking.
• Common examples: US ACH (Nacha 94-character records) and UK Bacs Standard 18.
• They persist for compactness, deterministic parsing, decades of stability, and a natural fit with mainframe/COBOL systems.
• Drive parsing from a declarative field map, validate trailer totals, and be strict about padding and encoding.