Banking File Formats – Common Types & Their Structure Explained

Introduction. Digital Transformation in Banking and Financial Data.

When it comes to financial data streams, paper as a medium has irreversibly lost the battle with e-formats decades ago. “Digital” does not mean only paperless, but above all being able to structure and analyze the heaps of scattered data in a technology environment. Businesses and organizations have put tremendous efforts to digitize their financial data and take productivity to a new level.  Electronic files can be transferred, stored and processed in a convenient, fast, and secure manner. Admittedly, the largest “stakeholders” in the global digital infrastructure for financial data exchange are the banking institutions.

In the most general sense, the cash balance reporting involves two parties – the customer and the depository institution. But as the customer may have contractual relationships with a dozen of depository institutions (originators of the financial statements), a sensible option would be the involvement of intermediaries such as third-party data processing firms to serve as a focal point for information streams prior to consolidating them in a single report emitted towards the customer for his convenience. Apparently, this multiplies the paths of financial data flow.

Transaction Banking Survey 2016 shows that only 7% of corporates have chosen to work with only one banking partner. The bigger the client, the more bank relationships it maintains, generally. Also, 60% are serviced by 2 to 10 banks. More than half of the interviewed companies above the $5 billion revenue threshold, use 20+ banking partners at a time. As per bank accounts, 40% of corporate respondents operate with 150+ accounts, while 20% belong to the 1-20 accounts bucket.

Operating in an environment of multiple counterpart relationships, including partnerships with banks, poses the formidable challenge to stay on top of the company’s cash position – 41% testify to that fact. Furthermore, respondents identify as problematic “manual processes/spreadsheets in key workflows” (39%) and hampered access to banking data for decision making (38%). It’s worth noting that 17% cite multiple accounts reconciliation as an issue and 29% admit that subsidiary accounts reconciliation is problematic. (See Transaction Banking Survey 2017)

Bank associations at national and regional level deploy and govern banking communication infrastructure. They are also responsible for the development and universal adoption of communication standards by member entities. Usually, these standards are aligned with the business requirements of the local financial industry and reflect local market specifics. Therefore international and country-specific formats have emerged, so have certain technical challenges and their associated costs.

Depending on the payment type, geography, regulatory requirements, banking systems characteristics and many other factors (fees, delivery time, and reliability among others), businesses inevitably face the necessity to convert the electronic banking statement into a format readable for the company’s ERP system and the average human alike. Accurate reporting and development costs motivate format unification efforts. It is reported that a significant portion of corporate spending on bank services is allotted to information reporting and integration of the corporate financial systems with the banking platforms.

There is a myriad of file formats out there. This series intends to make a brief inventory featuring the most common standards supported by the ReconArt reconciliation tool: SWIFT MT, ACH, FIRD,and BAI. Financial data reconciliation specialists’ daily routine largely revolve around those; accountants, controllers, and system analysts know them all too well. Let’s have them deciphered:

ACH

ACH stands for Automated Clearing House. The National Automated Clearing House Association (NACHA) is behind the development of ACH financial information infrastructure. The NACHA file format is applicable for corporate-to-consumer (PPDs – Prearranged Payments & Deposits) as well as corporate-to-corporate (CCDs – Cash Concentration & Disbursement, and CTX – Corporate Trade Exchange) class of transactions. Estimated 25 billion transaction worth $43 trillion are handled by the system each year. Those include government transfers such as social security and benefits, insurance premiums, payroll, mortgage payments and utility bills, e-commerce, transactions between corporates and/or individuals.

The collaborative mechanism of batch processing, store and forward of payments involve 4 principle participants:

• Originator,
• Originating Depository Financial institution (ODFI)
• ACH Operators – the Federal Reserve or the Clearing House
• Receiving Depository Financial Institution (RDFI)

The standard file structure in NACHA format consists of 6 types of records, each containing up to 94 characters, alpha/numeric, arranged in fixed/maximum length fields, with strictly defined positions. Each field within the record is designated as mandatory, required or optional.

• File Header – 13 fields identifying both the origin and the destination of the entries (name and routing number / Fed ID), file creation date and time, plus other files prerequisites such as ID, record size and type code, etc.
• Batch Header – 13 fields identifying the originating party by company name and Fed ID, and the transaction details such as debit and/or credit codes, class of transaction code (consumer or corporate – PPD, CCD, CTX, TEL, and WEB), record type code, effective entry date (of settlement), etc.
• Entry Detail – the 13 fields relate the entry to the recipient by name / individual ID, bank account number, and payment amount. The record also contains transaction code determining debit/credit operation to a specified type of account (saving, checking, loan, GL, etc.).
• Entry Detail Addenda – the only optional record here. Primary used for corporate-to-corporate class of transactions. Usually contains additional information referring to the prior Entry Detail record.
• Batch Control – describes the batch in terms of transactional operations (debit/credit), entry counts, entry hash, total dollar amounts (debits and credits), company identification number, and batch number.
• File Control – as a final check, the 8 fields of the record summarize dollar, entry and hash totals accumulated in the Company / Batch record, also counting blocks and batches.

The file structure is based on batches. A batch binds together Entry Details in groups of 10s. There can be multiple batches in one file. Each batch has a Batch Header (on the top) and a Batch Control (at the bottom). On the other hand, there is only one set of File Header and File Control records which envelopes the file (top and bottom, respectively).

To be continued