A Claims-Recovery Firm Uses Files.com to Isolate Regulated Claims Data and Destroy It on Demand

A US healthcare claims-recovery firm recovers money that health insurers should never have paid. When a patient is treated after an accident, their health plan usually picks up the bill even when another insurer is actually responsible. The firm's predictive data science and machine learning find those claims across a client's entire book, and its legal advocates recover the money from the insurers that owe it rather than from patients. The firm does this for health plans, risk-bearing provider groups, self-funded employers, and public sector organizations.

None of it works until a client hands over its claims data. Every engagement begins with claims files containing protected health information under HIPAA, alongside records covered by the Driver Privacy Protection Act. And because many of the firm's clients participate in Medicare Advantage, federal regulatory requirements pass down to the firm directly. The business rests on being trusted with some of the most regulated data in the country, and on being able to answer for every place that data has been so it can destroy one client's data without touching another's.

Account for Every Surface, Destroy on Demand

The requirement the firm's Medicare Advantage clients pass down is blunt.

Honoring a destruction request means knowing with certainty where every client's data went and whose data is whose.

Before Files.com, intake ran on the firm's own SFTP on AWS Transfer Family, with a hand-built layer of AWS Lambda scripts moving what arrived into S3, and content clients sent through Box was pulled down through the API the same way. As the client list grew, the firm wanted client isolation to be a property of the storage layout itself, enforced once at the transfer layer.

The constraint that made this hard is that the firm does not control the sending side. Each client chooses its own channel, and the firm's job is to accept all of them. Isolation had to hold across inbound paths the firm did not pick, and it had to keep holding as every new client added another one.

What the Ingest Layer Had to Guarantee

Every new client adds another channel, and the accountability requirement does not scale down to match. The firm needed an ingest layer that would bind each client's inbound path, whichever channel the client chose, to storage only that client's data could reach. The full set of surfaces a client's data touched had to be enumerable. Destruction had to be possible without touching any other client's data. And the whole path had to carry a regulated posture: key-based authentication, audit logging on every transfer, and a business associate agreement covering the protected health information in flight.

The firm selected Files.com to be that ingest layer.

One S3 Bucket and One Files.com Mount Per Client

On Files.com, the isolation boundary is the architecture itself.

The firm runs one AWS S3 bucket per client. Each bucket is connected to Files.com through its own Remote Server integration. Whether a client connects to the firm's Files.com site over SFTP, requires the firm to mount its own SFTP server, or sends content through Box, each inbound path syncs exclusively to that client's bucket.

Downstream, the AWS data loader picks each bucket up into Databricks, where the firm's analysis runs. Files.com sits in front as the governed layer: nearly all of the movement is transfer rather than resident storage, so a client's data does not accumulate on a middle tier. It passes through into that client's bucket. Every transfer lands in Files.com's activity and audit logs, and a business associate agreement with Files.com covers the HIPAA-regulated data.

The firm has since weighed the cheaper alternative and rejected it. Consolidating clients into folders inside a single shared bucket, behind a single S3 integration, would cut the number of connections. It would also collapse the guarantee, because folders in a shared bucket make separation depend on paths staying right rather than on storage being distinct. The firm kept the bucket-per-client model deliberately, choosing more connections over any possibility of commingling.

Destruction Is Isolated by Design

With the Files.com architecture in production, every client's data has exactly one destination, and no other client shares it.

• When a client demands destruction of its data, the firm can enumerate every surface that data has touched: the client's inbound folder or mounted server, the client's bucket, and the log of every transfer between them. Destroying it touches nothing belonging to any other client, because no other client shares any of those surfaces.
• That guarantee is how the firm answers the federal requirements its Medicare Advantage clients pass down: with the architecture rather than a policy document.
• The isolation model holds regardless of which channel a client chooses. Firm-hosted SFTP, client-hosted SFTP, and Box all bind to the same per-client boundary, so accepting a new client's preferred method never weakens it.
• Onboarding the next regulated client is the pattern applied again: a bucket, a mount, and a credential. Connections now span per-client S3 buckets, client-owned SFTP servers, and Box, and each was added without revisiting the design.

The pattern holds at production scale. Client feeds arrive in CSVs running to millions of rows and hundreds of columns.

Isolation Enforced at the Transfer Layer

When a compliance officer at a client health plan asks where their data has been, the answer is a property of the architecture. Their data came in through their channel, landed in their bucket, and appears in a log of every step in between.

The firm's clients hand over data as regulated as any in the country, and what makes that a routine transaction is where the isolation lives. It is not rebuilt inside each pipeline or promised in a policy. It is enforced once, at the transfer layer, where Files.com binds every client's channel to that client's storage and nothing else's.