An overview of the most common bank file and message formats

Companies that use direct connectivity solutions to automate sending and receiving payments, and generate payment reports and account statements, need to support multiple message and file formats.

In this article, we deep dive into the most common file and message formats used by banks.

Common file formats

First, let’s recap the most common file formats that exist in the banking world:

1. TXT

Text-based messages (sometimes referred to as Fixed Record Length) are one of the oldest message formats that exist. They are flexible and let users exchange detailed information in a relatively compact format. Each set of data can often be extracted on a per-line basis (for instance 1 payment per line), surrounded by a header and footer line. Each line usually stores multiple pieces of information that can be extracted using a pre-defined offset and length (for instance, at position 1 with a length of 3, at position 4 with a length of 10, etc.).

2. XML

XML files were born in the 1990s and let users store structured data. One of the most interesting features of this format is its typing system, which indicates the format of a given piece of information (for instance, a date, an amount, a noun with a maximum length of 35 characters, etc.). It can contain multiple, nested entries, which makes it convenient to store intricate data structures. One drawback of this message format is that it can be quite verbose, which increases its weight.

3. JSON

JSON is a structured message format from the end of the 90s. Easy to format and manipulate, it can store large volumes of data and can contain nested, typed properties. This format has been widely used by the Web since the 2000s.

Common message formats

Now that we’re familiar with the most common file formats, let’s take a closer look at the most used payment messages in the banking ecosystem.

1. Swift MT messages

The Swift MT format is used to transmit cross-border payment instructions and reporting messages between a corporate customer and its bank. It’s also used by financial institutions to transmit instructions to each other on the Swift network.

This structured TXT file format uses the naming convention MTXXX where the XXX contains different categories of messages expressed as 3 numbers. For instance, the MT1XX category contains payment and cheque instructions (such as the MT101 single credit transfer message), and the MT9XX category holds cash management and customer reporting messages (like the MT940 instruction that contains account statements).

Since 2022, the MT format is being progressively phased out by Swift and replaced by the MX format, based on the ISO 20022 standard.

2. ISO 20022 messages

The ISO 20022 standard is probably one of the most common and future-proof message formats of the late 2010s. Based on structured XML files, its messages can be used to transmit a wide range of payment instructions between corporates and their banks, but also between financial institutions.

ISO 20022 messages usually start with a short set of letters and a number that corresponds to their category. For instance, pain.001 messages (PAIN standing for PAyment INtructions) include corporate-to-bank credit transfer payment instructions, while camt.056 messages (CAMT standing for CAsh ManagemenT) include bank-to-bank payment recalls. Check our detailed article about SEPA messages for more information.

ISO 20022 is the standard widely used in the SEPA payment scheme, the UK’s CHAPS real-time gross settlement system, the US' Real-Time Payments  (RTP) system, and the Swiss Payment Standards (SPS), and will be soon adopted by Swift, FedNow in the US, and the New Payment Architecture (NPA) in the UK.

3. CFONB files

The CFONB file type (also known as AFB) is a French text-based file format used to transmit local and international payments, direct debit instructions, payment notifications, and account statements between a customer and their bank.

This type of text file contains a header and a footer line that gives high-level information about the message and contains multiple lines in-between that represent each entry (for instance N transactions in an account statement). Each line has a fixed length of Y characters, that rules the name of the message, such as CFONB 160 or CFONB 320 (respectively for a length of 160 and 320 characters). For instance, in the CFONB 120 account statement files, the amount of each transaction line is located at position 91 and has a length of 14 characters.

4. BAI / BAI2

The BAI (for Bank Administration Institute) format dates from the 1970s and is mainly used in the US to transmit account statements and balances. An improved version was released in the early 80s, BAI2, which is the version still used today.

Based on text files, each file contains 7 sections (also called record types) that hold a different kind of information, such as a file header, a group header, an account identifier, or transaction details. Each transaction record contains various information like an amount, type, and reference, separated by a comma.

5. Bacs Standard 18 (UK)

Standard 18 (also known as STD18) is the file format used by the UK’s Bacs payment network to transmit local credit transfer or direct debit payment instructions between banks and the Bank of England.

Based on text files, STD18 can contain single or grouped payment instructions. STD18 uses multiple lines that start with a category (for instance “VOL”, “HDR1”, “HDR2”, etc.), and a set of fixed-length attributes for each line. Every batch starts with an “HDR1” record and ends with a “UTL1” record. The actual payment lines are located between the “UHL” and “EOF1” lines of each batch.

6. ACH’s NACHA (US)

The NACHA text file format, eponymous with the US NACHA payment network, is used to transmit ACH payment instructions.

Like Bacs’ Standard 18, BAI2, and CFONB, the NACHA format is composed of 5 main record types that are the header, the trailer, the batch header and trailer, and the detailed transaction records. Each line is 94 characters long and holds information separated by a fixed number of characters.

7. APIs

Since the late 2000s, application programming interfaces (APIs) have been booming globally, both in the corporate world and the banking world.

Such APIs bring real-time capabilities on top of already robust banking systems and thus enable new use cases. Banks and financial institutions are launching new APIs every day for corporates as well as PSD2-regulated third-party providers.

Banking APIs are usually proprietary and don’t strictly follow a global standard as of today, although most of them try to leverage JSON and XML payloads and converge towards ISO 20022 principles.

Using bank messages in practice

Since the 1950s and the arrival of computers, the banking industry has seen multiple file formats and message types being adopted to exchange payment instructions and reporting data between banks and their customers. These message standards are extensive and reliable, yet require a tremendous amount of engineering work to make sure that their content is sound and accurate.

Businesses creating payment instructions and receiving status reports and account statements in return need to ensure that the data that flows in and out of such files is correctly formatted and interpreted to avoid any costly mistakes.

Numeral provides a single API that connects all payment methods and banks across Europe. It abstracts all payment files, messages, security mechanisms, and connectivity channels into a unified and secure API.