SFTP (SSH File Transfer Protocol)

SFTP, the SSH File Transfer Protocol, is a network protocol for transferring and managing files over a connection secured by Secure Shell (SSH). Both the login and the file contents are encrypted in transit. It was designed as a secure successor to the original File Transfer Protocol, which sends data and passwords unprotected.

In payments, SFTP is the standard way to exchange files between institutions. A company uploads a file of payment instructions to its bank, a processor delivers a daily settlement report to a merchant, or a bank drops account statements into a folder for a corporate customer's treasury system. It is the usual transport behind a host-to-host banking connection and sits alongside real-time APIs, which handle individual transactions.

One side runs an SFTP server and the other connects as a client, normally on network port 22. The server proves its identity with a host key, which the client should verify to be sure it has reached the genuine system. The client then authenticates with a username and either a password or, more commonly in banking, an SSH key pair. The client keeps the private key secret and gives the matching public key to the server operator in advance.

Once connected, the client can list directories, upload, download, rename and delete files, within the permissions it has been given. Providers usually create separate inbound and outbound folders for each customer. Connections are commonly restricted to known network addresses through a whitelist, so that stolen credentials cannot be used from elsewhere.

SFTP is often confused with FTPS, which is the old File Transfer Protocol wrapped in Transport Layer Security. The two are different protocols with different ports and certificates, although both protect data in transit.

• Payment instruction files. Bulk credit transfers and direct debits in formats such as pain.001, and an ACH file in the Nacha format in the United States.
• Status and return files. Acknowledgments, rejections and returns that tell the sender what happened to each instruction.
• Statements. End-of-day and intraday account reports such as camt.053, MT940 or BAI2.
• Settlement and reconciliation files. A processor's settlement file or reconciliation file listing transactions, fees and payouts.
• Card program files. Clearing data, card production orders, dispute records and reports from networks and processors.
• Compliance files. Customer lists for screening and regulatory reports.

A company's finance system creates a file of supplier payments each afternoon. A scheduled job encrypts the file, connects to the bank's SFTP server and places it in the inbound folder before the bank's cut-off time. The bank picks up the file, validates its format and totals, and writes an acknowledgment file to the outbound folder. Payments are released into the clearing system. The next morning the company's job downloads a status report and the account statement and loads them into its ledger for matching.

This pattern, known as batch file processing, is reliable and well suited to large volumes. Its drawback is delay. Errors are discovered only when the response file arrives, and the company has no live view of each payment's progress.

The protocol protects data while it travels, but files sitting on a server are only as safe as the server. Banks therefore often require a second layer: each file is encrypted, and frequently signed, with PGP before upload, so that it stays protected at rest and its origin can be verified. A digital signature or control totals guard against tampering and partial uploads.

Other common controls are the use of key authentication in place of passwords, regular cryptographic key rotation, separate credentials for test and live systems, restricted folder permissions, automatic deletion of files after a retention period, and monitoring for missing or duplicate files. Where files contain card numbers, the PCI DSS applies to the systems that store and transmit them.

Newer integrations favor a REST API, which returns an immediate response for each request and supports real-time payments. SFTP has not disappeared. It remains simpler for very large batches, is supported by almost every bank and accounting system, and does not require the customer to build and maintain software against a changing interface. Many providers offer both: an API for creating payments and checking status, and files for bulk runs and for the daily reports that feed reconciliation.