The Public Interest Company Replaced AWS Transfer Family with Files.com—No Code Push Required for Client Onboarding

The Public Interest Company (TPIC) works on one of healthcare's most persistent cost problems: claims paid by the wrong insurer. When another insurer should have covered a bill, after an accident for example, the health plan usually pays it anyway, and the cost lands on employers, taxpayers, and members. TPIC applies machine learning and predictive data science, backed by legal advocates, to find those claims and recover the money for health plans, risk-bearing provider groups, self-funded employers, and public-sector organizations. Its stated principle is that no claim is too small. It pursues every recovery opportunity rather than only the large ones, which is only economical at machine speed.

Machine speed starts with data. TPIC's work begins the moment a client's claims data arrives, and that arrival is governed twice over. The files are HIPAA-protected PHI, often combined with data covered by the Driver Privacy Protection Act, and many clients participate in Medicare Advantage, which passes federal requirements down to TPIC directly. Each client also decides how its data will travel. Some upload through a web portal. Some want credentials on TPIC's SFTP server. Some require TPIC to pull from their own SFTP server. Some send through Box. In business-to-business health data exchange, the sender sets the terms, and TPIC has to meet every client where it stands.

The heaviest cost sat at the front door of the business. TPIC ran its entire environment as infrastructure-as-code, so issuing SFTP credentials to a new client meant a CloudFormation push, and only the CTO could make one. A prospective client ready to send data had to wait for a code deployment before anyone could hand over a credential. On a lean team, that put client onboarding, the step that turns a prospect into revenue, in line behind whatever else engineering was shipping that week.

Every New Client Was an Infrastructure Project

Before Files.com, each of those inbound paths was hand-built. SFTP hosting ran on AWS Transfer Family, wrapped in a custom layer of Lambda synchronization scripts. Box content reached S3 through ad-hoc API scripting: pull the file down, push it back up. And when a client with strict IP whitelisting required TPIC to pull from the client's own server, the answer was a dedicated EC2 instance with a static IP, stood up so that one connection could originate from one approved address.

Jeffrey Nadel, TPIC's CEO, described what that looked like in practice:

“They have really strict IP whitelisting, so we had to spin up an EC2 instance with a static IP.”

None of this was carelessness. Infrastructure-as-code is how a small team keeps a HIPAA environment reproducible, and no shortcut was acceptable: anything that provisioned access to claims data had to be secure, locked down, and audited by default. So the estate grew the only way it could, one more Lambda, one more single-purpose server, every time a new client arrived with new terms. As the client base grew, so did the pile.

What the Ingest Layer Had to Do

TPIC needed one layer standing between its clients and its AWS environment. It had to provision a new client without a deployment: a folder and a credential, created directly, by someone other than the CTO. It had to speak SFTP in both directions, hosting keys for clients who push and reaching client-owned servers behind IP whitelists for clients who insist TPIC pull. It had to connect natively to Box and to S3. And because everything moving through it is PHI, it had to come out secure, locked down, and audited by default, with a business associate agreement behind it.

TPIC selected Files.com to be that layer. Within minutes of receiving access, before the first onboarding session, Nadel had created a folder, mounted Box as a remote drive, created a user, and connected over SFTP.

One Governed Layer in Front of the S3-to-Databricks Pipeline

Files.com became the single layer between clients sending claims data and the AWS environment that analyzes it.

Inbound, each client gets its own folder on TPIC's Files.com site and connects over SFTP with SSH key-pair authentication and IP whitelisting. Clients who prefer a browser use the web interface on the same site. Where a client requires TPIC to use the client's own SFTP server instead, Files.com mounts that server as a remote location and syncs from it. Dedicated Files.com IP addresses satisfy the client's whitelisting rules, so the requirement that once cost TPIC a standing EC2 instance now costs an address on the platform.

Downstream, TPIC deliberately runs one S3 bucket per client, with a matching Files.com remote server integration for each bucket. Whatever path a client's files arrive by, they sync into that client's own bucket, where AWS data loading carries them into Databricks for processing. The isolation is the point. Medicare Advantage requirements, passed down from the federal government, mean TPIC must be able to account for every surface a client's sensitive data touches and destroy it on request. One bucket per client, one connection per bucket, makes that an answerable question instead of a forensic exercise.

Files.com syncs move unstructured content, including PDFs from signature workflows, out of Box and into S3 for pipeline processing, and replicate selected data back into Box for data-science users. That native Box-to-S3 synchronization retired the ad-hoc API scripts.

Around all of it sits the governance the data demands. Every movement lands in Files.com's activity and audit logs. Internal access runs through Okta single sign-on with SCIM provisioning, so accounts follow the company directory. PHI moves under a business associate agreement with Files.com.

From Code Pushes to Configuration

With the Files.com workflow in production, TPIC replaced a transfer estate assembled from Transfer Family, Lambda scripts, and single-purpose EC2 instances with one repeatable pattern for every client.

• Onboarding a new claims-data client is configuration, not deployment. A folder, a key pair, and a whitelist entry are provisioned directly in Files.com, with no CloudFormation push and no call on the CTO.
• A client's IP whitelisting requirement no longer costs a server. Dedicated Files.com IPs replaced the EC2-instance-per-partner workaround.
• One architecture serves every connection, whichever side hosts the SFTP server.
• Deletion requests have a defensible answer. Each client's data lands only in that client's bucket, through that client's connection, with an audit trail behind it: the accounting Medicare Advantage requires.

“One of the things that's been nice is being able to have a consistent architecture and process regardless of whether the client wants us to use their SFTP or whether they want to use ours.”

The pattern has absorbed real growth. In January 2026, monthly transfer volume grew from 5 TB to more than 7.5 TB. Each new client is another folder and credential, or another mounted server, on the same platform.

The Front Door Is No Longer an Engineering Project

Today, a new client's transfer requirements are settings, not systems. Push or pull, key pair or whitelist, portal or Box: the person onboarding the client configures the connection in Files.com, and the data lands in that client's own bucket with the analytics pipeline waiting behind it. What used to open with a request to the CTO for a code deployment now opens with the data arriving.

TPIC never loosened a control to get there. The provisioning that once waited on a deployment now happens in minutes, and it comes out of Files.com secure and audited by default—the discipline the old estate enforced through code pushes, without the code pushes.