An Industrial Services Company Meets Banks’ SFTP Requirements on Files.com—Without Building a Server

An industrial equipment services company repairs, maintains, and remanufactures electric motors, generators, and power distribution equipment for utilities and heavy industry. It does that work across more than a hundred locations.

Nothing about that business requires hosting file-transfer infrastructure. The company's IT organization exists to support repair shops and field crews, not to operate protocol servers for outside counterparties. Then one of the company's banking partners asked for exactly that.

A Bank Needed Somewhere Secure to Drop Files

The requirement came from the partner's side: the bank needed a secure file transfer location it could deposit files into continuously, and the company needed to retrieve those files as they arrived. Not a one-time transfer. A standing exchange.

The company had no hosted SFTP capability of any kind. No server, no endpoint, no compliant location a financial counterparty could be pointed at. Until one existed, the exchange could not happen at all.

The ask was small on paper and large in practice. “A place to drop files” means a hardened protocol surface exposed to the internet, kept secure and available for as long as the bank continues depositing files.

SFTP a Bank Would Accept, Without a Server to Own

The conventional answer is to build that surface yourself: stand up an SFTP server, harden it, patch it, and keep it running for as long as the relationship lasts. For an IT team at an industrial-services firm, that is a permanent infrastructure job created to serve what is, from the company's side, a receive-and-retrieve workflow.

And the bar was set by who the counterparties are. Banks do not accept “a place to put files.” The endpoint had to speak SFTP and nothing weaker, authenticate partners with SSH keys, wall each counterparty into its own space, and get the permissions right from the first file. It also had to be administrable by the generalists the company already employed, because there was no file-transfer team to hand it to.

The company selected Files.com to be that endpoint: SFTP hosted as a service, with the company keeping only the administration.

One Login and One Restricted Home Folder per Partner

On Files.com, the server is Files.com's problem. The company's share of the work shrank to accounts, folders, and permissions.

Each banking partner received its own Files.com login, restricted to its own home folder. A partner that authenticates sees only its own drop location and nothing else on the site. The company built out the folder tree and permission model at setup, so access boundaries were in place before the first deposit landed.

The protocol posture matches the counterparties. Partner accounts authenticate with SSH public keys, and plain FTP is disabled across the entire site, so no connection reaches the company's exchange unencrypted.

Administration stayed inside the existing team. The company's IT director held site admin from the first hour, and day-to-day partner logins were handed to a SQL programmer, who manages accounts, credentials, and downloads as part of an ordinary workload.

The Next Counterparty Costs a Login and a Folder

With the exchange live on Files.com, the same generalist team could extend it. Onboarding another counterparty is a pattern, not a project: create a login, restrict it to a new home folder, and set the permissions. The design that isolates the first bank isolates every one after it.

A Standing Answer When the Next Bank Asks

Today, when a financial counterparty asks the company where to put its files, the answer already exists, and the person giving it is a SQL programmer creating a login rather than an IT department scoping an infrastructure build. Meeting a bank's hosted-SFTP requirement never turned the company into an operator of file-transfer infrastructure. Files.com is the host; what the company owns is the part only it can own, which is deciding who connects and what each of them can reach. For the company, that is the right division of labor.