Banks and clearing systems were built around files long before real-time APIs, and much payment volume still moves that way. A payroll provider paying 4,000 employees uploads one file with every beneficiary, amount and reference; the bank validates it, debits the total and releases the individual credits into the scheme. Card acquiring works similarly: a POS terminal closes the day's authorised transactions into a settlement batch, which the acquirer submits for clearing.

A US automated clearing house (ACH) file follows the Nacha format: fixed-width 94-character records, opening with a file header (record type 1), then batches, each with a batch header (5), entry details (6) and a batch control (8), and closing with a file control (9). Control records carry entry counts and totals, so an altered or truncated file fails validation.

In the Single Euro Payments Area (SEPA), corporate files use ISO 20022 XML: pain.001 for credit transfers and pain.008 for direct debit collections.

The bank checks structure and signatures, rejects duplicates, validates each entry and submits accepted payments at the next cut-off. Status returns later as a report listing accepted, rejected and returned items. That lag is the core trade-off of batch processing: low cost per payment, results hours or days later. A control total mismatch or wrong date format rejects the whole file; an IBAN with a bad check digit usually rejects only that entry.

A batch identifier is the unique reference for a group of payments submitted or settled together. It sits above individual transaction references and links them to their file, terminal close or settlement run. A transaction identifier points to one payment; a bank credit of €84,300 on a merchant statement usually carries only the batch reference, so reconciliation teams match the credit to the batch, then the batch to its transactions, fees and refunds.

In Nacha files, the batch number in each batch header is repeated in its batch control record, and a file ID modifier separates several files sent the same day. In pain.001, the Message Identification labels the whole file and must be unique per sender, while the Payment Information Identification labels each block; both allow 35 characters. Card terminals increment a batch number at every close, printed on the end-of-day report next to the terminal ID.

The sender builds the identifier from a date and sequence, such as "PAY-20260915-003" for the third run on 15 September 2026. The bank stores it and quotes it in every status report. Many banks reject a file whose message ID was already processed, which stops a re-uploaded 1,200-line supplier run from being paid twice, the file-level equivalent of an API idempotency key.