Vensure Moved Payroll Transfers to Files.com One Partner at a Time—Without Pausing Payroll

Vensure Employer Solutions is a professional employer organization: businesses hand it their payroll, benefits, workers' compensation, and HR administration, and Vensure runs them. It describes itself as the largest privately held organization in the HR technology and services sector, and its family of companies serves more than 161,000 businesses across all 50 states, processing over $153 billion in annual payroll.

Co-employment puts Vensure in the middle of everything payroll touches. When a client's employees get paid, banking files go to banks. When they enroll in benefits, enrollment files go to insurance carriers. Vendors and clients send and receive EDI and payroll data on their own schedules. None of those endpoints belong to Vensure, and every one of them expects data on its own terms. A PEO at this scale is, structurally, a file exchange operation: payroll, banking, and benefits-enrollment files, nearly all of them carrying PII, moving continuously between Vensure's internal systems and dozens of external banks, carriers, vendors, and clients.

Every Bank, Carrier, and Client Had Its Own Transfer Procedure

That exchange ran on traditional on-premise SFTP procedures and in-house scripts, built one partner at a time. Each connection was its own bespoke build: its own credentials, its own schedule, its own quirks, maintained by the team that created it. Every new partner meant new work. Every new partner requirement meant more: when banking partners mandated PGP encryption, someone had to build it. Sensitive payroll and banking data moved through infrastructure Vensure had to run and patch itself, and the security team had no single place to see it or set policy over it. A failed transfer in this business is not an IT inconvenience; it is a payroll or benefits failure for a downstream employer.

The estate survived because it could not be replaced in one motion. Banks, carriers, and payroll clients each dictate their own protocols, keys, encryption requirements, and processing windows, and none of them will change how they work to suit a vendor's migration schedule. As Vensure grew, the number of external connections kept climbing, and building and maintaining a new procedure for each one stopped being sustainable.

What replaced those procedures had to speak whatever each partner speaks, including SFTP with key authentication, FTPS, and AS2 for EDI counterparties. It had to apply the encryption partners mandate, keep each client's access scoped to its own folders, run on each partner's clock rather than one master schedule, and allow the legacy procedures to move over incrementally. And the security team added one more requirement: it could not become one more place where sensitive data accumulates.

Vensure's DevOps team chose Files.com as that layer and began moving its legacy SFTP procedures onto it one partner at a time, without waiting for a cutover window that its banks and carriers could never share.

One Integration Layer, Operated as a Conduit

Files.com became the single governed layer between Vensure's internal systems and every external endpoint, and Vensure operates it deliberately as a pass-through rather than a repository.

Vensure connected its in-house scripts, Prism payroll platform, and Azure Blob Storage to Files.com. On the external side, it stood up each bank, carrier, and client as its own Files.com Remote Server, with access scoped to that partner and sync cadence tuned to its processing windows.

Partner mandates that once meant custom engineering became configuration. Vensure used Files.com GPG encryption to apply each bank's PGP key as part of delivery, including for files staged from Azure Blob. EDI counterparties connected over AS2, while Files.com Automations renamed inbound files and appended timestamps for downstream systems.

The whole layer runs under one security posture. The security team set a standing goal for files to clear the accounts within 24 hours so the platform would remain a conduit rather than a store of PII. And the site's enforced-SSL configuration gave Vensure its SOC 2 audit evidence for how SFTP traffic is encrypted, drawn from platform settings rather than reconstructed from scripts.

Nearly 80 Partner Connections on One Repeatable Pattern

With Files.com in place, Vensure replaced bespoke transfer procedures as each partner migrated, and the repeatable pattern is what grew.

• Outbound partner connections grew from just under 50 to nearly 80 in a single year. Onboarding the next bank or carrier is now a Remote Server, an exchanged key, scoped folders, and a tuned cadence—not a new procedure an engineer has to build and then own indefinitely.
• The platform absorbed peaks of 120,000 transactions in a single day without the exchange becoming anyone's manual work.
• Deliveries that once depended on scripts now hold fixed cadences; one vendor feed stabilized to a consistent three-hour interval.
• Sensitive data has a designated channel: when a file carries banking or benefits PII, it moves through Files.com under one set of permissions, one audit trail, and one retention posture.

The compounding result was adoption. What the DevOps team introduced for partner transfers spread across the business, and today system operations, infrastructure, accounting, automation development, and payroll teams all run workloads on the platform.

“It took on a life of its own once people knew we had it.”

Moved One Partner at a Time, Without Pausing Payroll

Vensure never had the option of a cutover weekend, because its banks and carriers were never going to move on Vensure's schedule. The lesson in its Files.com deployment is that they didn't need to: a regulated B2B file estate can leave legacy per-partner SFTP one connection at a time, as each partner comes up, while payroll keeps running. And the new layer never became one more place sensitive data lives. Files.com is the layer the files pass through on their way to the banks, carriers, and clients supporting payroll for 161,000 businesses.