File Interfaces That Still Run Banks

Let us be honest about something. When you imagine a modern, cutting-edge banking system, you probably do not picture a flat file. You picture REST APIs, event streams, real-time dashboards, and AI-powered analytics. You picture the future.

But the future runs on flat files.

Every T24 bank — every single one — runs critical business processes through file interfaces. Regulatory reports are generated as files and sent to central banks. Data warehouses are fed by nightly file extracts. Reconciliation systems compare files from multiple sources. Payment files are sent to clearing houses. Statement files are sent to customers.

File interfaces are not glamorous. They are not modern. But they are reliable, auditable, and they work. And in banking, reliable and auditable beats modern every time.

Why files still matter

1. Volume

Files can handle volume that real-time interfaces cannot. A single file can contain 100,000 transactions. Sending 100,000 individual API calls would take minutes and create significant load on T24. Sending one file takes seconds.

2. Auditability

A file is a permanent record. You can archive it. You can replay it. You can compare it with the output file to verify that every record was processed correctly. Try doing that with an API call.

3. Resilience

Files do not time out. Files do not get lost in network failures. If the file transfer fails, you retry it. If the file is corrupted, you regenerate it. Files are the most resilient integration mechanism available.

4. Simplicity

A flat file is the simplest possible data format. Every system can read and write flat files. You do not need special libraries, special protocols, or special skills. You need a file format specification and a file transfer mechanism.

The file types that run banks

The flat file (CSV, delimited)

The flat file is the workhorse of T24 integration. It is a simple text file with one record per line and fields separated by a delimiter.

CUSTOMER_ID|CUSTOMER_NAME|ACCOUNT_TYPE|BALANCE|CURRENCY
12345|John Smith|SAVINGS|15000.00|USD
12346|Jane Doe|CURRENT|25000.00|GBP

Why it works: Every system can read it. Every system can write it. It is human-readable. It is easy to debug.

The gotcha: No schema enforcement. If the file format changes, the receiving system breaks. File format versioning is essential.

The fixed-width file

Each field has a fixed width, and fields are defined by their position in the line. Common in mainframe environments.

Why it works: No delimiter ambiguity. If a field contains a comma, it does not break the file.

The gotcha: If a field is too long for its allocated width, the data is truncated. Changing the format requires updating every system.

The XML file

XML uses tags to define fields and supports hierarchical data — multi-values, sub-values, nested structures.

Why it works: XML supports complex data structures. It has schema validation (XSD). It is self-describing.

The gotcha: XML is verbose. A 1 MB flat file becomes a 5 MB XML file. XML parsing is slower than flat file parsing.

The SWIFT MT/MX file

SWIFT files are the standard for interbank communication. MT files are fixed-width with a specific format. MX files are XML-based.

Why it works: Every bank in the world can send and receive SWIFT files.

The gotcha: SWIFT file formats are rigid and complex. A single formatting error can cause the file to be rejected.

The file transfer mechanisms

FTP/SFTP

The most common file transfer mechanism. T24 writes a file to a directory, and an FTP/SFTP transfer moves it to the receiving system.

Pros: Simple, widely supported, works across networks.

Cons: FTP is not encrypted (use SFTP). File transfer failures need to be monitored.

Shared file system

T24 and the receiving system share a file system — typically NAS or cloud storage.

Pros: No file transfer needed. Files are available immediately.

Cons: Performance issues. File locking needs to be handled carefully.

MQ file transfer

The file is split into messages, sent through MQ, and reassembled on the receiving end.

Pros: Guaranteed delivery. Asynchronous. Reliable.

Cons: Complex to set up. Large files need to be split into multiple messages.

The R24 perspective

R24 does not change the fundamental role of file interfaces, but it does provide some enhancements:

• Global Processing mode supports multi-company, multi-calendar batch processing, making file-based batch processing more powerful.
• OFS API hooks (IN.MSG.RTN, OUT.MSG.RTN) can be used to transform file data into OFS messages and vice versa.
• IRIS event publishing can trigger file generation — when an event is published, a file can be generated and transferred.

The bottom line

File interfaces are not going away. They are not being replaced by APIs. They are not being replaced by event-driven architecture. They are being supplemented by these technologies, but they remain the backbone of T24 integration.

If you are a T24 integration architect, you need to be good at file interfaces. You need to understand file formats, file transfer mechanisms, error handling, and file monitoring. You need to know when to use a flat file and when to use XML. You need to know how to design a file format that is robust, extensible, and easy to debug.

Because when the real-time API goes down — and it will — the file interface will still be running. And the bank will still be processing payments.

The humble flat file does not get the respect it deserves. But it keeps the banking system running, day after day, year after year. And that is worth respecting.