How to Send ACH Files to Your Bank via SFTP

Why Banks Use SFTP for ACH Files

When you send a batch of ACH payments to your bank, you are handing over sensitive financial data — account numbers, routing numbers, dollar amounts. Banks take transmission security seriously, and that is why most of them require SFTP rather than email or a web upload portal.

SFTP stands for SSH File Transfer Protocol. It is not the same as regular FTP (which sends data in plain text) and it is different from FTPS (which adds TLS encryption on top of traditional FTP). SFTP uses the SSH protocol to encrypt both the authentication handshake and all file data in transit. If someone intercepts your transmission, they see scrambled noise.

Compare that to:

Email attachments — unencrypted in transit, no delivery guarantee, easy to misdirect
Bank web portals — fine for one-off payments, but manual and not suitable for batch files
FTPS — still offered by some banks, but less common and slightly more complex to configure

SFTP hits the right balance for batch ACH: it is scriptable, auditable, and universally understood by bank treasury teams.

Step 1: Get Your SFTP Credentials from Your Bank

Before you can connect to anything, your bank's treasury or cash management department needs to provision an SFTP account for you. This is not automatic — you usually need to request it when you enroll in ACH origination services.

What you will receive (or be asked to provide) typically includes:

Hostname — something like ach.yourbank.com or sftp.treasurydirect.bankname.com
Port — almost always 22, but some banks use a non-standard port like 2222
Username — assigned by the bank, not one you choose
Authentication method — either a password or an SSH key pair (see below)
Upload directory — the path where files should be placed, such as /incoming/ach/ or /upload/

Write all of this down somewhere secure. You will need every piece of it.

Step 2: Understand SSH Keys vs. Passwords

Many banks support — and some require — SSH key authentication instead of a password. It is worth understanding the difference.

Password Authentication

Simpler to set up. You connect with your username and a password the bank assigns. The downside: passwords can be guessed, phished, or accidentally leaked. Some banks disable password authentication entirely for security reasons.

SSH Key Authentication

You generate a key pair: a private key that stays on your machine and a public key that you share with your bank. When you connect, the server uses your public key to verify that you hold the matching private key — without your private key ever leaving your system.

To generate a key pair, run this from a terminal:

ssh-keygen -t ed25519 -C "your-company-ach-key"

This creates two files: id_ed25519 (private — keep this safe) and id_ed25519.pub (public — send this to your bank). Your bank will register the public key on their SFTP server. Some banks require RSA keys with a specific bit length (2048 or 4096) rather than Ed25519 — ask them what they accept before generating.

A few things to watch for:

Never share your private key. If someone asks for it, that is a red flag.
Store private keys with appropriate file permissions. On Linux/Mac: chmod 600 ~/.ssh/id_ed25519. On Windows, the SSH agent handles this for you.
Some banks require PEM format rather than OpenSSH format. If your connection fails with a key format error, try exporting the key in PEM format: ssh-keygen -p -m PEM -f id_ed25519.

Step 3: Verify the Host Key

The first time you connect to your bank's SFTP server, your SSH client will show you the server's host key fingerprint and ask whether you trust it. Do not skip this step.

Host key verification protects you from man-in-the-middle attacks. If someone intercepts your connection and pretends to be your bank, their server will have a different key — and your client will warn you.

Ask your bank for the expected host key fingerprint before your first connection. Most bank treasury teams can provide this. Compare it against what your SSH client shows. If they match, accept it and your client will remember it for future connections. If they do not match, do not proceed — contact your bank.

Once accepted, the fingerprint is saved in a known_hosts file. Automated scripts should reference this file rather than skipping verification with flags like -o StrictHostKeyChecking=no, which defeats the purpose entirely.

Step 4: Test the Connection

Before you try to send a real ACH file, verify the connection works. Open a terminal and run:

sftp -P 22 youruser@ach.yourbank.com

If you are using a key file in a non-default location:

sftp -P 22 -i /path/to/your/private-key youruser@ach.yourbank.com

Once connected, run ls to confirm you can see the expected directory structure, then cd into your upload directory and run pwd to confirm the path. Log out without uploading anything. You now know the connection works.

Step 5: The Full ACH File Workflow

With the connection confirmed, here is the complete end-to-end process for a typical batch:

1. Generate your NACHA file

Compile your payment data — recipient names, routing numbers, account numbers, amounts, and effective dates. Build or export the NACHA-formatted file. Every record must be exactly 94 characters wide; a single formatting error can cause the bank to reject the entire file.

2. Validate before you send

Run the file through a NACHA validator before transmission. Check that:

Batch hash totals are correct (the sum of all routing numbers in the batch)
Entry and addenda counts match the batch control record
The file control record totals match the sum of all batch control records
Effective dates are valid business days
SEC codes are appropriate for each transaction type

Sending a malformed file wastes time on both sides and can delay payment by a full business day.

3. Connect and upload

Once validated, connect via SFTP and upload the file to your designated directory. Use the exact filename convention your bank requires — many have specific rules about naming (dates, company IDs, sequence numbers). When in doubt, ask.

4. Confirm delivery

After uploading, do not just disconnect and assume everything worked. Check:

The file appears in the upload directory (run ls before disconnecting)
The file size matches what you sent (a truncated upload is a corrupted file)
Your bank's acknowledgment process — some banks send a return file or email confirmation within a few hours

Common Issues and How to Fix Them

"Connection refused" or timeout on port 22 Your firewall may be blocking outbound port 22. Work with your IT team or network provider to open outbound TCP port 22 (or whatever port your bank uses) to the bank's SFTP server IP address. Some banks provide a list of IP addresses to whitelist.

"Host key verification failed" The server's fingerprint has changed, or your known_hosts file has a stale entry. Contact your bank first — banks occasionally rotate host keys, but they should notify you in advance. Do not blindly clear the entry without confirming the change is legitimate.

"Permission denied (publickey)" Your public key was not registered correctly on the bank's server, or you are pointing to the wrong private key file. Confirm with your bank that your public key is active, and double-check your SSH config or command flags.

"No such file or directory" on upload The directory path you are using is wrong. SFTP paths are case-sensitive on most systems. Use ls and pwd after connecting to confirm the exact path.

Key format errors If your bank requires a specific key format (RSA, PEM, OpenSSH) and yours does not match, the handshake will fail with a cryptic error. Ask your bank which key types and formats they support, and regenerate or convert accordingly.

How FiSTWorks Handles This for You

Setting up SFTP from scratch — managing keys, remembering directory paths, scripting the connection — is a meaningful time investment for a small team that just wants to pay vendors.

FiSTWorks has SFTP transmission built in. Enter your bank's credentials once (hostname, port, username, key or password, and upload path), and FiSTWorks handles the connection, upload, and delivery confirmation as part of the same workflow you use to generate and validate the file. No separate scripting, no terminal windows, no manual steps to forget.

If you are ready to stop doing ACH file transmission the hard way, take a look at what FiSTWorks offers.

See plans and pricing →