Payments are key to the operations of companies across a number of industries such as financial services, insurance, real estate, or temp work. Yet, scaling payment operations is complex and error-prone. In this article, we explain how Numeral abstracts the complexity of initiating, tracking, and reconciling payments by capturing the entire lifecycle of a payment in a payment order.

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

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.).

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.

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.

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.

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.

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.

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.

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.

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.

Mambu 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.