TPIC Uses Files.com to Isolate Regulated Claims Data and Destroy It on Demand

The Public Interest Company (TPIC) 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. TPIC'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, and it pursues every recoverable claim rather than only the large ones. Chasing small-dollar recoveries is only economical at machine speed, which is the point of the model.

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 TPIC's clients participate in Medicare Advantage, federal regulatory requirements pass down to TPIC 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 TPIC's Medicare Advantage clients pass down is blunt.

“We have to be able to account for any surface area where their sensitive data touches, and then also be able to delete or destroy that at any time upon request.”

A destruction request can only be honored if TPIC knows with certainty where every client's data went and whose data is whose.

“If it's even possible that the data from one client could be mingled with the data from another client, and then imagine we get a deletion requirement, it's a disaster at that point.”

Before Files.com, nothing in TPIC's architecture provided that certainty. Claims files arrived however each client dictated: credentials on TPIC's own SFTP running on AWS Transfer Family, TPIC pulling from a client's own SFTP server, or content moving through Box. A hand-built layer of AWS Lambda scripts synchronized what arrived, and Box content was pulled down through the API and pushed to S3 as needed. Separation between one client's data and another's existed only in what those scripts happened to do and where a folder convention said things should point. No construct in the platform bound a client's inbound channel to an isolated destination.

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

What the Ingest Layer Had to Guarantee

Separation maintained by scripts and conventions erodes as the thing it guards multiplies. Every new client added another channel and more glue, and the accountability requirement did not scale down to match. TPIC 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.

TPIC selected Files.com to be that ingest layer.

One S3 Bucket and One Files.com Mount Per Client

On Files.com, the isolation boundary stopped being a convention and became the architecture itself.

TPIC 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 TPIC's Files.com site over SFTP, requires TPIC to mount its own SFTP server, or sends content through Box, each inbound path syncs exclusively to that client's bucket.

“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.”

Downstream, the AWS data loader picks each bucket up into Databricks, where TPIC'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.

TPIC 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 recreate exactly the condition Nadel called a disaster: separation that depends on paths staying right rather than on storage being distinct. TPIC 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, TPIC replaced separation maintained by scripts with separation the storage layout enforces.

• When a client demands destruction of its data, TPIC 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 what lets TPIC serve Medicare Advantage clients at all. The federal requirements those clients pass down are answered by the architecture rather than by a policy document.
• The isolation model holds regardless of which channel a client chooses. TPIC-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

Before Files.com, the honest answer to "where has our data been" was a reconstruction: read what the Lambda scripts did, check where the folders pointed, and trust that the conventions held. Now, when a compliance officer at a client health plan asks that question, 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.

TPIC'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 was never 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.