Two Dedicated Files.com IPs Let Vensure Move Regulated Transfers Off Legacy SFTP

Vensure Employer Solutions is a professional employer organization. Under the PEO co-employment model, Vensure runs payroll, benefits, workers' compensation, and HR compliance on behalf of its clients. It operates across the U.S., Canada, and Latin America.

That model makes file exchange the business itself, not a task beside it. Every pay cycle and every enrollment window produces files bound for outside institutions: direct-deposit and tax files to banks, enrollment data to insurance providers, premium and claims data to workers' compensation carriers. Much of it carries employee PII. And the institutions receiving it are among the most security-conscious counterparties a company can have. They set the terms on which anyone connects to them.

Banks Whitelist Source IPs, and a Shared Cloud Has Hundreds

One of those terms is IP whitelisting. Before a bank, insurer, or carrier accepts sensitive data, its network team requires the specific addresses the data will come from, and it opens its firewall to those addresses and nothing else.

A static on-premise SFTP server answers that requirement trivially. It has one address, written into the partner's firewall once. That is a large part of why regulated counterparty transfers stay pinned to aging servers long after everything else in a company has moved to the cloud.

Vensure was retiring exactly those servers. Its DevOps team was moving legacy on-premise SFTP procedures onto Files.com, partner by partner, as each connection came up. That migration surfaced the cloud side of the trade: a multi-tenant platform runs on shared infrastructure, and its default pool of possible source addresses runs to the hundreds. Presenting a bank with that list means asking its network team to allow traffic from hundreds of third-party addresses in order to receive a payroll file. Security-minded network teams refuse that ask, and the refusal lands on exactly the wrong partners. The banks, insurers, and carriers the whole exchange exists to serve would have been the hardest ones to connect at all.

The Fix Had to Change What Partners See on the Wire

The requirement was imposed by the partners, not by Vensure. No cipher setting or permission change on Vensure's own side touches what a bank's firewall team will accept. The further the migration reached into banking and insurance counterparties, the more often this one question decided whether a workload could leave the old server.

That set the requirements. Vensure needed a source identity that was small, fixed, and permanent: addresses that never change, regardless of what infrastructure runs underneath. It needed that identity under its own name, because the files are Vensure's obligations to its clients. And it needed the encryption those partners separately demand, on the connection and, for banking partners, on the file contents themselves.

Vensure got all of it as a platform capability: it runs its Files.com site on its own branded domain with dedicated IP addresses.

Two Dedicated Addresses Under Vensure's Own Domain

With Files.com Dedicated IP Addresses bound to its custom domain, every transfer the platform makes on Vensure's behalf originates from the same two addresses. The shared infrastructure underneath can grow and shift, and the partner never sees any of it. A bank's network team whitelists two entries, once. It is the same conversation a server in Vensure's own rack would have required.

The rest of the exchange runs on top of that identity. Vensure set up each counterparty as its own remote server connection across dozens of client, vendor, and carrier SFTP and AS2 endpoints. Files.com also met the partners' transport- and file-encryption requirements. Its enforced-SSL configuration supplied evidence for Vensure's SOC 2 auditors, while Files.com applied GPG encryption to file contents for banking partners that required it.

Two Whitelist Entries for Banks, Insurers, and Carriers

With the dedicated-IP identity in place, Vensure replaced a firewall request most partners would have refused with a two-entry whitelist that never changes.

• Partners that whitelist source IPs list two addresses instead of hundreds. It is the same ask an on-premise server would have made, with a cloud platform behind it.
• Onboarding the next regulated partner starts with a simpler network conversation. The addresses never change, so the partner's firewall work is limited to the same two entries while Vensure exchanges credentials and keys and sets the delivery schedule.
• The most sensitive transfers moved onto the platform instead of staying behind on legacy servers. Payroll, banking, and benefits-enrollment files carrying PII run through Files.com as the standard path.
• The deployment behind those addresses runs at real scale: Vensure has peaked at 120,000 transactions through Files.com in a single day.

Cloud File Transfer on Terms a Bank Will Accept

Every connection with an IP-whitelisting requirement used to carry an architecture question: could this transfer leave the building at all? One counterparty's firewall policy was enough to pin a whole workload to a static server. A partner's whitelisting requirement no longer decides where Vensure's file transfer runs.