What are Bank Reporting and Payment Formats?

Bank reporting and payment formats, also referred to as payment file formats, bank file formats, bank message formats or simply as bank or payment formats, exchange payment instructions and reporting information between banks and their clients. When companies use direct connectivity solutions, they must ensure they support the most common payment message and bank file formats to automate payment transactions, facilitate payment exchanges and produce payment documentation.

Formats follow a structured arrangement of information required for processing financial transactions and information electronically. Formats specify how payment data should be organized and presented to ensure accurate and efficient processing by banks, financial institutions and payment systems. In return, they also structure how bank statement data is sent back to the clients for reporting and reconciliation purposes.

Payment message formats are critical for seamless Straight-Through-Processing (STP) of corporate payments, which is one of the cornerstones of Payments Clearing across the world. Enterprises building direct connectivity to banks to automate payments initiation, and receive payment reports and bank account statements, must develop multiple message and file formats. Building and testing can take up to six months for setting up one bank, according to Kyriba’s client value engineering data.

These formats vary based on the types of payment, payment systems, industry standards, bank and country-specific requirements. Usually bank reporting and payments formats include fields such as account numbers, beneficiary details, payment amounts, payment dates, currency codes, transaction references, payment types and other necessary information required by the banks or authorities.

Figure 1: An example of information needed for initiating a payment request

Different Types of Bank Reporting and Payments Formats

There are many different types of formats for bank reporting and payments. This section provides an overview of the most common types of file and message formats in the following categories: Delimited, Fixed, JSON (JavaScript Object Notation), Variable and XML.

Delimited Formats

Delimited formats are plain text file structures commonly used for storing and exchanging structured data, especially related to financial transactions and account details. These formats define boundaries between data values using specific characters or sequences of characters called delimiters. Common delimiters encompass commas, tabs, semi-colons, pipes, spaces, and colons.

• CSV (Comma-Separated Values) file is an example of a delimited format. What makes CSV so prevalent is its simplicity, versatility and wide support, making it apt for tabular data storage. This suitability extends to importing data from diverse banking applications into utilities like Microsoft Excel or database systems. However, it’s noteworthy that many CSV formats are proprietary, tailored to meet the specific requirements of certain banking institutions. For instance, HSBC has its iFile, while Citibank uses CitiDirect files.Figure 2: An example of a CitiDirect format
  
• ANSI ASC X12 is a structured format developed for electronic data exchange (EDI). Its structure includes segments, which are groups of related data elements, and data elements within those segments. Used mostly in the U.S., this format supports the exchange of many different types of business transactions, including payment and cash application data, shipping and receiving information, invoicing and order placement and processing.Figure 3: An example of an ANSI ASC X12 format
  
• BAI2 (Bank Administration Institute) format is mostly used in the U.S. as a cash management balance reporting specification. This format is based on text files, with each file having seven sections, or record types, that contain data regarding files headers, group headers, account identifiers and transaction details. Details such as amounts, types and references are specified within each transaction record.

Fixed Formats

Fixed file format refers to a specific way of organizing and encoding data within a digital file to make it machine-readable and interpretable. In a fixed file format, the data is arranged in a systematic and predictable manner, often following a predefined schema or set of rules, which allows software applications to process the data.

• ACH’s NACHA is a U.S. text-based file format. This format is used to clear electronic payments between participating financial institutions in the United States. Types of payments include payroll deposits, business-to-business payments, direct payment of consumer bills (e.g., utility, insurance, mortgages, etc.), government benefit deposits and e-commerce payments.Figure 4: An example of a NACHA format
  
• BACS Standard 18 is used by the U.K.’s Bacs payment network to send local credit transfers or direct debit payments between banks and the Bank of England. Also known as STD 18, this file format is based on text files that hold either single or grouped payment instructions. The STD18 format uses several lines, each starting with a category identifier, such as VOL, HDR1, HDR2, etc. Each line contains a fixed-length set of attributes, with every batch starting with an HDR1 entry and ending with a UTL1 entry.Figure 5: An example of a BACS format
  
• CFONB (also known as AFB) is a French standard defined by the Comité Français d’Organisation et de Normalisation Bancaires/French Committee for Banking Organization and Standardization (CFONB) to meet the needs of the Association Française des Banques/French Association of Banks (AFB). CFONB defines formats used to send local and cross-border payments, payment notifications, direct debit instructions and account statements between customers and their banks. The CFONB/AFB text-based format contains a header and a footer line that provides a basic overview of the message, with the lines in between denoting each entry. For SEPA payment operations, this format will be replaced by the SEPA PAIN (payments initiation).
• FEBRABAN 240 file format is used by banks to transmit data for various services, such as payments, collection, current account statement to bank reconciliation, current account debit, vendor, check custody, extract to cash management, loans and purchasing. Each service follows its own specifications, with a fixed format text and columns outlined by FEBRABAN. Banks follow their own variation within the FEBRABAN standard.Figure 6: An example of a FEBRABAN 240 format
  

JSON

JSON is a type of structured data format that is easy to format and manipulate. With the ability to store substantial amounts of data, it can contain nested, typed properties. JSON format is composed of parameters, where each parameter represents data in different buckets. Originating in the late 1990s, it has been extensively used since the 2000s.

Variable File Formats

Variable file formats have varying lengths, and the fields within them can accommodate different sizes. Because each field is as long as needed to hold the data, variable file formats are useful when storage efficiency and flexibility are more critical than rigid formatting requirements.

• SAP IDoc, short for intermediate document, is a standard data format for transmitting information between application programs operating within the widely used SAP business system, or between an SAP application and an external program. IDocs help transfer data in SAP’s Application Link Enabling (ALE) system.
• SWIFT MT messages used to transmit international, or cross-border, payment instructions and reporting messages between corporate customers and their banks. Financial institutions also use the SWIFT network to send instructions to each other. SWIFT MT messages use a structured TXT file format with the naming convention MTXXX, where the MT is the literal “message type/text” and XXX denotes category, group and type. For example, the MT1 category identifies customer payments and cheques, and the MT2 category indicates financial institution transfers. In use since the 1970s, SWIFT is now replacing the MT format with the MX format, based on the ISO 20022 standard.
• UN/EDIFACT (the United Nations rules for Electronic Data Interchange for Administration, Commerce and Transport) comprise a set of internationally agreed standards, directo­ries and guidelines for the electronic interchange of structured data between independent computerized information systems. EDIFACT is widely used in Europe.Figure 8: An example of a UN/EDIFACT format
  

XML Formats

XML messages, also known as Extensible Markup Language messages, are a type of structured data format. These messages use a “typing system” to identify the format of specific data items, such as amounts, dates or nouns within a maximum character limit. XML messages support nested entries, allowing the storage of complex data structures. Although these messages provide a structured and flexible way to encapsulate data, the XML message format tends to be lengthy, which increases file size. XML messages originated in the 1990s.

• ISO 20022, is a flexible messaging standard that promotes interoperability, supports rich data, improves fraud detection and enhances compliance procedures. ISO 20022 messages usually begin with a set of letters and then a number that relates to their category. For example, a pain.001 message contains PAyment INstructions for corporate-to-bank credit transfers, and the ISO 20022 release 2009 contains the pain.001.001.03 message, the most commonly used messaging format for payment initiation.
• SEPA (Single Euro Payments Area) is an EU payment-integration initiative to simplify bank transfers made in euros. ISO 20022 XML is the messaging standard for SEPA payments. The SEPA region consists of 36 European countries as well as several non-EU countries.

Migration to ISO 20022 XML Formats

While corporate to bank messages are not directly impacted by the SWIFT MT to MX migration, the end of coexistence and the retirement of Categories 1, 2, and 9 of MT messages is scheduled in November 2025 for financial institutions. Globally, this new standard will allow the transmission of rich data in a more structured manner. It will enable end-to-end tracking and reconciliation of payments, which has always been an issue with cross-border payments. Currently, over 70 countries are already in the process of adopting ISO 20022, including China, India and Japan. It is also the standard used by the RTP and FedNow in the US.

Learn more about ISO 20022 XML migration for corporates from our ebook: The Winning Formula for Your ISO 20022 Payments Migration.

How Are APIs Used in Bank Reporting and Payments?

When it comes to bank services, APIs facilitate real-time data retrieval for bank balance and transaction reporting and real-time payments between banks and their corporate clients. When enterprise systems such as ERP are connected to banks via APIs, real-time data exchange can further enable treasury use cases such as cash flow forecasting, FX exposure management and quick reconciliation.

APIs can be closed, shared or open and API communication among systems does not involve any file exchange. They do not currently adhere to any international standards, but many APIs leverage JSON and HTML formats and most developers understand the benefits of following ISO 20022 standards to consistently present data.

Having connected via Bank APIs with more than 20 major banks across the US, EU and APAC regions, Kyriba was the first treasury management system to successfully go live with a customer with Bank of America and J.P. Morgan. Our close collaborations with bank partners have yielded invaluable insights into the myriad challenges and nuances of API integration with banks. For more insights, read the Bank API best practices guide prepared by Kyriba’s Bank API product team.

What Are the Challenges with Developing Bank Formats?

While bank formats are an established and reliable way to automate common financial transactions and reporting, they are also extremely intricate and complex. As a result, there are many challenges involved in developing bank and country-specific formats. Organizations often find it complicated to connect their treasury and payment systems to global banks.

Organizational challenges

• Organizations underestimate the resources, duration and complexity of developing and testing multiple bank formats with multiple bank connections. Typically, it takes 6-12 months to add a new bank.
• Finance and treasury have to manage several, if not dozens, of banking relationships.
• Dedicated, knowledgeable IT resources are a must when building and testing payment formats and flows to banks.

Bank and procedural challenges

• Each bank has its own standards for communications and connectivity.
• Banks are very process-oriented, due to compliance and security requirements, and organizations must follow banks’ strict controls which prolongs the process.
• Banks often become bottlenecks for connectivity projects because they may not prioritize other organization’s connectivity demands.
• Organizations must “get in line” along with all the other entities connecting to banks.
• International banks may operate in different time zones and speak different languages than IT teams, presenting challenges for technical work.
• Even when an organization’s IT team speaks the same native language as the banks, banks use their own terminology and domain expertise, which may be unfamiliar to IT departments.

Technical challenges

• Bank formats, even for the same clearing system, will vary across banks.
• Each bank payment format is complex, with customizations including the bank, initiating branch, receiving branch, payment type, possible FX conversation, urgent or non-urgent payment, the currency and other regional or bank-specific fields.
• The number of payment formats means there are hundreds of format customizations to modify and test in each environment. The magnitude of formats and scenarios that need to be built and tested can be enormous and overwhelming.
• Rigorous testing is required, as a failed payment scenario means a failed payment.
• Payment formats testing takes time, and a test usually fails the first time.
• IT resources will be stretched thin as they test, fix errors, document and re-test each payment format for each bank.

To mitigate these challenges, many organizations take advantage of connectivity-as-a-service solutions to reduce time and costs, take advantage of the latest connectivity options, improve quality of data and allow IT staff to productively focus on initiatives that drive business growth.

Figure 9: Using a payment solution can significantly decrease the time-to-value for formats

How Can Kyriba Open Formats Studio (OFS) Help?

Kyriba Open Formats Studio is a set of self-service tools developed by the Kyriba Payments Product team for advanced corporate users, implementation consultants and other partners to access and customize existing formats with a Sandbox environment and add simple variants of existing scenarios in just minutes. It is part of the Kyriba Payment Hub solution and is available through the Kyriba Developer Portal.

OFS offers a new and open approach to payment formats testing with the possibility to simulate bank file outputs, compare differences between various bank outputs and test different format alias combinations and XML postprocessor rules. OFS also includes the first release of the Alias Assistant, which includes all aliases and descriptions for ISO 20022 pain.001 formats. More content are being added regularly.

Figure 10: Kyriba Open Format Studio’s Bank Format Translation Tool

Using Payment Hub Solutions to Simply Bank Formats Development

Kyriba client Amway implemented a single payment hub to consolidate all its payment activities into one platform, allowing:

• Automatic management of bank reporting and payment formats
• Support of SWIFT connectivity and select host-to-host connectivity protocols for enhanced bank security and encryption
• Integration with the company’s new ERP solution for digitized integration of approved payment files

Figure 11: Amway achieved significant results including savings from payment formats