Infrastructure & Reliability · Middleware — File transfer · Chapter 31 of 33
Bank file flows: salaries, schemes, statements and the mainframe
Corporate host-to-host payments, national scheme files, SWIFT FileAct, overnight mainframe batch and regulatory returns — traced end to end, with the cut-off clock that governs every one and the duplicate file that every bank has paid twice for.
The previous chapter explained the machinery — managed file transfer (MFT), the SSH File Transfer Protocol (SFTP) and Pretty Good Privacy (PGP) encryption. This one follows the files. Almost every bank file flow has the same three properties: it carries money or evidence of money, it is governed by a cut-off time, and it is exchanged with someone outside the bank.
Flow 1 — a corporate client’s bulk payments, host to host
Large corporate clients do not key payments into a web portal. Their finance systems send payment files directly to the bank — host-to-host (H2H) connectivity. The modern format is ISO 20022, the XML financial-message standard from the messaging chapters, whose message families for this purpose are worth knowing by name:
| Message | Direction | What it carries |
|---|---|---|
| pain.001 | Client to bank | Payment initiation: the instructions to pay |
| pain.002 | Bank to client | Status report: accepted, rejected, and why |
| camt.052 | Bank to client | Intraday account report |
| camt.053 | Bank to client | End-of-day statement, used to reconcile |
The flow: the client’s system produces a pain.001 file, signs and encrypts it with PGP, and sends it over SFTP to the bank’s MFT gateway. The MFT server verifies the signature against the key registered for that client, decrypts, scans, validates the XML, checks it is not a duplicate, and hands it to the payments engine — which answers with a pain.002 status file back along the same route. At the end of the day a camt.053 statement follows, and the client reconciles.
Flow 2 — the national scheme files
Payment schemes settle bulk payments between banks from files. The formats and timings are scheme-specific and non-negotiable:
- US — ACH. Banks send NACHA-format files to an ACH operator — the Federal Reserve’s FedACH or The Clearing House’s EPN (Electronic Payments Network) — which sorts and forwards them to the receiving banks.
- UK — Bacs. Files enter through Bacstel-IP, a channel secured with a public key infrastructure, on the three-day cycle.
- India — NACH. The National Automated Clearing House, run by the National Payments Corporation of India (NPCI), carries bulk credits — salaries, dividends, government benefit transfers — and mandated debits such as loan repayments. The wider landscape is in payments.
Flow 3 — files over SWIFT
SWIFT carries individual payment messages, but it also has a file service, FileAct, for bulk exchanges between institutions — batches of payments, reports, statements and regulatory submissions that are too large or too numerous to send as single messages. To the MFT team, FileAct is one more channel with its own gateway, keys and cut-offs.
Flow 4 — the overnight batch between data centres
The mainframe’s overnight batch produces files — posted transactions, interest accruals, statement runs — that other systems and the second data centre need by morning. These move over IBM Sterling Connect:Direct, which banks keep for three reasons: it runs natively on the mainframe, it restarts huge transfers from a checkpoint instead of from zero, and its processes — small scripts describing a transfer and what to do on success or failure — slot into the batch scheduler that already runs the night.
Flow 5 — regulators, bureaux and suppliers
Returns to the central bank, data submissions to credit bureaux, statement files to print-and-mail suppliers, card-scheme clearing and settlement files arriving every day: the bank’s obligations to the outside world are, overwhelmingly, files. Each has an owner outside the middleware team, and each is a place where the MFT team is accountable for delivery but not for content — a line worth drawing clearly in any operating model.
The incident every bank has had: the duplicate file
A client’s system hiccups and sends yesterday’s payroll file again. Nothing about the file is wrong — it is valid, signed and on time — and without a control, 4,000 employees are paid twice. Recovering the money is slow, public and expensive. The controls are layered:
| Control | How it works |
|---|---|
| File sequence numbers | Each client numbers its files; the bank rejects a number it has seen before |
| Content hashing | The MFT server computes a hash of every file and flags an exact repeat, whatever its name |
| Business duplicate checks | The payments engine compares totals, counts and value dates against recent files from the same client |
| Maker-checker for bulk files | Above a value threshold, a second person must approve release — the same principle as in risk and controls |
The controls that apply to every flow
| Control | Which failure it prevents |
|---|---|
| Expected-file monitoring | A file that never arrives — invisible to any log of files that did |
| Duplicate detection at file and payment level | Paying twice |
| Signature verification against a registered key | A forged file from a compromised partner account |
| Format validation before release | A malformed file rejected by the scheme after the cut-off, when there is no time left to fix it |
| Acknowledgement tracking | A file sent but never processed at the far end |
| Minimal retention | Months of sensitive files sitting on an internet-facing server — the subject of the next chapter |
Three acknowledgements, often confused
When a client asks “did you get my file?”, there are three different true answers, and most file-flow disputes come from mixing them up:
| Level | What it confirms | Who produces it |
|---|---|---|
| Technical | The bytes arrived intact and were stored | The MFT platform, within seconds |
| Functional | The file is well-formed, correctly signed, in the agreed format and not a duplicate | The validation step, within minutes |
| Business | Each payment in it was accepted or rejected, and why — in ISO 20022, the pain.002 status report | The payments engine, before the cut-off |
A technical acknowledgement is not a promise that anyone will be paid. An operations team that reports ‘file received’ to a client whose payments were then rejected has told the truth and still caused the incident.
Worked incident: twelve bad payments at 14:20
A corporate’s salary file of 4,000 payments arrives at 13:55, five minutes inside the cut-off. Technical and functional checks pass by 14:05. At 14:20 the payments engine rejects 12 payments: the account numbers do not exist. What happens next is decided by the client agreement, not by the engineer on shift, and it should be written down before the day it happens:
- Whole-file or item-level rejection? Most banks process the 3,988 valid payments and reject only the 12; some agreements require the whole file to be held.
- The status report goes back at once — a pain.002 listing the 12 with reason codes — so the client can correct them.
- Can the corrections still make today’s run? Only if the corrected file arrives before the next internal cut-off; the scheme’s window does not move for one client.
- Reconciliation closes the loop: the next morning’s statement should show 3,988 debits, and the 12 must appear either as re-sent payments or as confirmed exceptions.
Check yourself