Banks move a surprising amount of money as files. Not API calls, not real-time messages — plain files, sent on a schedule, between the bank and the outside systems it relies on. The most common of these is the ACH file. ACH stands for Automated Clearing House: the U.S. network that moves money between bank accounts in batches, the rails behind direct deposit, payroll, and the auto-pay that pulls your electric bill each month. ACH runs are governed by NACHA — the National Automated Clearing House Association, the nonprofit that writes the rulebook every participating bank follows.

When the bank wants to send a batch of ACH payments, it doesn't send them one at a time. It packages them into a single file in a fixed format (the "NACHA file"), and that file gets handed to an ACH processor — the vendor or clearing partner that submits the batch into the network. File transfer, in this context, just means moving that file from one computer to another over a network, securely and on time. This post walks through how those transfers actually work inside a bank, and what the IT team running them has to get right.

Why Banks Still Move Money as Files

It's fair to ask why, in an era of instant payments and APIs, so much of banking still runs on files dropped in folders. The short answer: the systems on both ends were built that way, and they handle enormous volume reliably.

A "core banking system" is the software of record that holds every account balance and posts every transaction. Most banks don't write their own — they license one from a core vendor (FIS, Fiserv, and Jack Henry are the big three in the U.S.). These cores were designed around batch processing: instead of posting transactions the instant they happen, the system collects them and posts them in scheduled runs, reading and writing files as it goes. A file with ten thousand transactions in it is cheaper and more predictable to process than ten thousand separate live requests.

So the file becomes the unit of work. A NACHA file is a batch of ACH payments. A settlement file is the record of what cleared. A reconciliation file lets two systems check that they agree on the numbers. These files move between the bank and its partners on a defined cadence — some hourly, some nightly, some only at month-end — and the whole machine depends on each one arriving where it's supposed to, when it's supposed to.

How a Banking File Transfer Workflow Operates

A bank rarely talks to just one outside system. A typical institution exchanges files with its core vendor, one or more ACH processors, a digital-banking platform, fraud-screening services, and corporate customers who originate their own payments. File transfer is the bridge that connects all of them, and the traffic runs in both directions.

Inbound: Files Arriving at the Bank

Inbound transfers happen when an outside system sends a file to the bank. A few everyday examples:

• A corporate customer uploads an ACH origination file — a batch of payroll deposits it wants the bank to send out.
• A vendor delivers a reconciliation or reporting file.
• A digital-banking platform drops transaction data for the bank to ingest.

These files almost always arrive over a secure protocol. SFTP (the SSH File Transfer Protocol — file transfer wrapped in the same encryption that protects a remote login) is the workhorse; FTPS (FTP with TLS encryption added), HTTPS, and AS2 (a protocol that signs and encrypts each file and returns a signed receipt proving it arrived) show up too. Each connection lands in a defined folder — a "landing zone" — where the file is checked and held before anything processes it. Authentication and access rules make sure only the right system can drop a file in the right place. A mid-size bank often runs many of these inbound endpoints at once, one per customer group or partner.

Outbound: Forwarding to Processors and Getting Files Back

Once a file lands, the bank usually has to move it again. An incoming ACH origination file gets routed to the ACH processor that submits it into the network. A typical path looks like this:

1. A corporate customer uploads an ACH file to the bank.
2. The bank validates and stages it in the landing zone.
3. The bank forwards it to the ACH processor or core vendor.
4. The processor submits the batch and sends results back.

That last step matters: the workflow is two-way. After processing, the vendor returns files to the bank — confirmed ACH transactions, settlement data, reconciliation reports, the records the core banking system needs to post and balance the day. Because files move both directions on a schedule, the bank needs reliable automation and monitoring so that nothing stalls silently. A payroll file that doesn't reach the processor before the cutoff is a missed payday for someone, and the IT team won't get a second chance to make that deadline.

What Banking IT Teams Should Evaluate in File Transfer Workflows

When a bank's IT team looks at how to run these transfers — whether they're replacing an aging in-house FTP server or consolidating a tangle of one-off scripts — a few capabilities matter more than the rest.

• It fits the systems already in place. The bank can't rip out its core or re-onboard every partner. Whatever runs the transfers has to speak the protocols partners already use and connect to the storage and systems the bank already has.

• One place to see everything. Operations needs a single view of every inbound and outbound transfer: where each file came from, where it went, and whether it completed. Hunting through five separate servers to find one stuck file is how cutoffs get missed.

• Proof that each file moved. For payment workflows, "it probably arrived" is not good enough. The team needs a record showing each file was delivered, retrieved, and processed. That same record — a complete audit log of who touched which file and when — is what an examiner asks for during a regulatory review.

• Automation instead of manual handling. The routing, the encryption, the scheduling — all of it should run on its own. Every file a person moves by hand is a chance to drop one, send it twice, or send it late. For the deeper version of this, see automating financial file transfers without breaking compliance.

Running Banking File Transfers on a Modern Platform

Most banks that outgrow a rack of standalone SFTP servers and the scripts gluing them together move to a single platform that does the whole job in one place. Files.com is the cloud-native File Orchestration Platform: one system that replaces the stack of legacy tools IT teams run to move files — SFTP and FTP servers, managed file transfer suites, and the custom scripts holding them together. It speaks every protocol partners expect, connects to 50+ cloud and on-prem systems, automates every transfer, and keeps a complete audit trail of all of it.

For a bank, that means consolidating every inbound SFTP, FTPS, HTTPS, and AS2 connection behind one front door, then using workflow automation to route each file to the right processor or vendor and ingest the results — no scripts to maintain, no box to patch. When an ACH file lands, the platform can validate it, forward it, watch for the return file, and post an alert if anything misses its window. Every step is logged for examiners, with SOC 2 Type II, HIPAA, PCI DSS, and GDPR controls built in. TowneBank runs its file exchange this way — their team's experience is written up in the TowneBank customer story.

Files.com runs at 99.9% uptime across eight global data-residency zones, so a bank can keep regulated data in the region it must stay in. If your storage already lives in a customer's own cloud bucket — including an AWS GovCloud bucket — Files.com connects to it as a target without moving the data out.

See how it handles secure, automated banking transfers on the managed file transfer page, or start a free trial — no credit card, live in minutes.