Integrated Power Services Meets Banks’ SFTP Requirements on Files.com—Without Building a Server

Integrated Power Services (IPS) repairs, maintains, and remanufactures electric motors, generators, and power distribution equipment for utilities and heavy industry. It does that work across 115 locations.

Nothing about that business requires hosting file-transfer infrastructure. IPS'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 IPS needed to retrieve those files as they arrived. Not a one-time transfer. A standing exchange.

IPS 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 IPS'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 IPS already employed, because there was no file-transfer team to hand it to.

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

One Login and One Restricted Home Folder per Partner

On Files.com, the server is Files.com's problem. IPS'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. IPS 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 IPS's exchange unencrypted.

Administration stayed inside the existing team. IPS's IT Director of Operations 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 IPS 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 IPS into an operator of file-transfer infrastructure. Files.com is the host; what IPS owns is the part only IPS can own, which is deciding who connects and what each of them can reach. For IPS, that is the right division of labor.