A Regional Bank Makes Every New Vendor SFTP Connection a Files.com Configuration—Without Opening Its Network

A US regional bank runs a full retail and commercial franchise spanning personal banking, mortgage lending, and commercial finance.

A bank operating at that scale runs on outside providers. A vendor platform records its customer calls. A servicing partner works its mortgage book. Payments and lending-services vendors carry their own feeds. Every one of those relationships comes down to the same thing: files that have to move between a third party and systems sitting behind the bank's firewall. Rather than make each connection a new infrastructure project, the bank needed a repeatable way to bring those files inside without bringing the vendor onto its network.

An SFTP Server the Bank Refused to Host

In early 2023 the need was concrete. Five9, the platform that records the bank's customer calls, needed an SFTP destination to deliver those recordings to, and the bank had none. The standard answer is to stand up an SFTP server. For a bank, that answer carries a cost most businesses never have to price: the server sits on the perimeter, open to a third party, and it has to be patched, monitored, and defended for as long as the vendor relationship lasts. The bank's IT leadership runs the environment on least privilege. Handing an outside platform a path to internal infrastructure was not on the table.

The problem was also bigger than one vendor. The mortgage operation exchanges files with the bank's servicing partner in both directions, on tight schedules. Other vendors deliver on their own windows, including one that drops files in the early hours of Monday morning that the bank needs soon after. Without an endpoint of its own, every new counterparty presented the same choice: open the bank's network to an outsider, or take the files in some way that was not automated at all. And whatever received them, the files still had to end up on the bank's on-premises file servers, the systems of record, behind a firewall the bank had no intention of opening.

What the Endpoint Had to Be

As the vendor relationships multiplied, the bank needed a standing answer rather than a decision per counterparty. The endpoint had to be controlled by the bank but hosted by no one at the bank. It had to give each vendor its own credential, locked to a single folder and accepted only from that vendor's IP addresses. It had to reach out to counterparties' own servers from fixed addresses they could whitelist in return. And it had to move files onward to internal storage without opening a single inbound port.

The bank selected Files.com to be that endpoint.

One Endpoint, a Different Lock for Every Vendor

Each vendor that delivers to the bank gets its own SFTP user on the bank's Files.com site, restricted to one folder and accepted only from that vendor's whitelisted IP addresses. A credential works from exactly one place, on exactly one folder, and nowhere else. The call-recording platform has delivered recordings into that endpoint ever since.

The bank used the same isolated-access pattern for a higher-intensity mortgage servicing exchange. Partner folders were mirrored one-to-one against the folders the servicing partner used. Files.com Syncs moved files in both directions on a schedule and cleared the partner side after each transfer so nothing was picked up twice.

Where the counterparty hosted the server instead, the bank reversed the connection. Files.com Remote Server integrations connected out from the site's dedicated IP addresses, so the partner could whitelist a fixed address rather than open its server to the internet. The early-Monday delivery is retrieved by a scheduled pull and is in the bank's hands when it is needed, with no one watching for it.

The Path Inward Opens No Ports

Files.com Agents installed on the bank's Windows file servers hold outbound-only connections to Files.com. Nothing inbound crosses the firewall, and no firewall rule names a vendor. Syncs and Automations use those connections to move each vendor's files from its Files.com folder onto the internal systems of record, and carry outbound files the other way.

The scoping runs in both directions. Each Agent is limited to the specific directories its workflows need, so even Files.com itself reaches no more of the bank's storage than the work requires. Vendors deliver to Files.com. The Agents reach in from the inside. At no point does a third party have a path past the perimeter.

The Second Vendor Was a Configuration, Not a Project

With the Files.com endpoint in production, the bank replaced a per-vendor infrastructure decision with a per-vendor configuration.

The compounding result is the one the first integration paid for. Onboarding the next vendor is a new SFTP user, a folder, and an IP whitelist entry, wired to the same Agents already running. Each counterparty after the first was set up as a repetition of an established pattern, and the bank's own network team now stands up new vendor connections by pointing at the last one.

A Perimeter Question That No Longer Gets Asked

Today, when a new vendor needs to exchange files with the bank, the question that used to hang over the conversation—whether the bank would open its network to this counterparty—does not come up. The bank got automated file exchange with its vendors, and the SFTP server those vendors connect to was never the bank's to host. That is the part that travels: a bank does not have to choose between a closed perimeter and automated vendor exchange, because the endpoint its vendors deliver to does not have to be its own.