A Benefits Administrator Automated File Intake Around Unchanged Legacy Applications With the Files.com .NET SDK

A US benefits administrator runs consumer-directed health benefits for employers: FSA, HSA, and HRA accounts, COBRA administration, and benefit-enrollment processing.

All of it is wired into other people’s systems. Enrollment data reaches the administrator from employer HR systems and vendor partners on their schedules, not its own. Nearly everything arrives as a file. The data is HIPAA-regulated, and COBRA insurance files carry statutory processing deadlines. For a benefits administrator, file intake is the front door of the operation, and every new employer group is another feed through it.

A Manual Check Every 10 Minutes, Around Every Partner File

Behind that front door sat a manual layer. The company’s legacy processing applications could each read files from only a single delivery location, and rebuilding them was not on the table. So people did the intake work the applications couldn’t. A checking process ran every 10 minutes against the delivery locations to see whether partner files had landed. Staff picked up what arrived, moved it to processing, and handled file exchanges with partners by hand.

The cost was not the poll. It was everything hanging on it. Every daily EDI job, every open-enrollment batch, and every COBRA file with its statutory deadline depended on a person noticing a file and carrying it to the system that needed it. The layer also taxed growth. Each new employer group or vendor partner meant more locations to watch and more files to carry, and the requirement was climbing toward hundreds of partner and internal accounts within a year. A checking process scales one way: by adding people who check.

The company needed somewhere for the intake logic to live other than in people. The platform had to speak SFTP to the partner systems that already sent that way. It had to keep every partner’s files separate and operate under a HIPAA Business Associate Agreement. And it had to do the thing the old self-hosted server never could: expose the entire file store to the company’s own code, so that finding, routing, and archiving could be written as software instead of performed as chores.

The company selected Files.com to be that layer: the SFTP intake point for its partners, and the platform its own developers would build the pipeline on. Within a year, the account base more than doubled without bringing the manual checking layer back.

Jailed SFTP Intake, SDK Pickup, and a Synced Archive

Each partner connected over SFTP to its own Files.com account, jailed to its own root folder and limited to IP addresses the partner supplied. Employer-side systems, including Workday connectors, dropped enrollment files directly onto the endpoint, with partner isolation and a HIPAA BAA governing the regulated workflow.

Pickup ran as code. The finding and routing people used to do became a set of scheduled jobs on the company’s production application server, written against the Files.com .NET SDK. The jobs searched the entire site for PGP-encrypted files, filtered the results to the file type being processed, and downloaded each file as a stream to the processing server. That site-wide search dissolved the single-location constraint: the SDK found a file wherever a partner dropped it, and the legacy application received it in the one place it could read. Nothing in the applications changed.

After processing, Files.com Sync mirrored files into Google Drive across dozens of client folders. Files.com File Expiration deleted files from the intake layer after a set period, enforcing retention through the platform rather than relying on someone to remember it.

The 10-Minute Check Is Gone

With the pipeline in production for daily EDI jobs and open-enrollment processing, the company replaced an intake process built on people checking and carrying files with one that runs as code its own developers own.

• Nobody checks delivery locations anymore. The 10-minute check, and the pickup and hand-routing behind it, is gone. The SDK jobs find the files they are configured to process and deliver them on their own.
• Deadline work rides on the pipeline, not on vigilance. Daily EDI jobs, open-enrollment batches, and COBRA files move from partner to processor to archive with no one in the path.
• Growth stopped costing manual effort. The account base more than doubled within a year without the checking layer coming back. Onboarding another partner is an account, a jailed folder, and an IP allow-list.
• Archiving and cleanup happen on schedule. Dozens of client folders flow into Google Drive through Files.com Sync, and file expiration keeps regulated data from accumulating at the intake point.

The pipeline also turned out to be a pattern rather than a one-off. Through 2025, the company’s development team converted two more application processes onto the same CLI and .NET SDK approach. The team runs its governance the same way: access reports across users, groups, folder assignments, and per-account IP restrictions come off the Files.com CLI on its own schedule, and inactive accounts are disabled automatically.

The File Layer Their Developers Own

The company never had to re-architect its applications to escape their one-location limit. It moved the logic onto Files.com and let its developers write it.