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

A national professional employer organization runs payroll, benefits, workers' compensation, and HR administration for the businesses that hand those functions to it. Its family of companies serves businesses across the United States.

Co-employment puts the PEO 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 the PEO, 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 the company'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. The PEO wanted one governed path for payroll and banking data, with one place to see every transfer and 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 the company 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: the layer had to be a conduit, not a place where sensitive data accumulates.

The PEO'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 the PEO's internal systems and every external endpoint, and the company operates it deliberately as a pass-through rather than a repository.

The PEO connected its in-house scripts, its 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. The company 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 a short window so the platform would remain a conduit rather than a store of PII. And the site's enforced-SSL configuration gave the PEO its SOC 2 audit evidence for how SFTP traffic is encrypted, drawn from platform settings rather than reconstructed from scripts.

Dozens of Partner Connections on One Repeatable Pattern

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

• Outbound partner connections grew sharply 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 more than a hundred thousand 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 interval.
• Files carrying banking or benefits PII move through Files.com under permissions scoped to each partner, with every transfer in the audit log and every file cleared on the schedule the security team set.

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.

Moved One Partner at a Time, Without Pausing Payroll

The PEO never had the option of a cutover weekend, because its banks and carriers were never going to move on its 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 a 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 the businesses the PEO serves.