Arbiter Launched Multi-Tenant HIPAA Data Ingestion to GCS on Files.com in Weeks

Arbiter is an AI-powered care orchestration platform that emerged from stealth in November 2025 with $52 million in seed funding. It sits between health plans and provider networks, maintaining a longitudinal patient record and running AI workflows that steer patients to the right care: matching referrals to the best-fit provider on cost, quality, and availability, closing quality gaps against the HEDIS measures that feed Medicare Advantage star ratings, and automating authorizations, outreach, and scheduling. At that public launch, its technology was already live with more than 1,000 providers.

But a planned soft beta involving inbound protected health data had a separate prerequisite. Everything Arbiter does depends on receiving data from organizations it does not control: eligibility and claims data from health plans, clinical and scheduling data from provider groups. All of it is protected health information. Every counterparty is an independent business with its own IT department. And none of it can flow until the pipe it flows through satisfies HIPAA. Arbiter needed one repeatable path that gave each counterparty an isolated SFTP credential and folder, then delivered its files to a dedicated Google Cloud Storage bucket.

For Arbiter, an ingestion layer was not a supporting system. It was the precondition for bringing the soft beta to market.

No Soft Beta Without a Compliant Way In

Arbiter’s soft beta could not go live until protected health data could arrive from its payer and provider counterparties compliantly. That meant HIPAA with an executed business associate agreement, audit log retention with forwarding, TLS version pinning, and access geofenced to approved countries. It also meant strict isolation: each counterparty needed its own credential that could see only its own data, from the moment a file arrived through to downstream processing.

The isolation requirement is what made the problem structural rather than a one-time setup. Multi-tenancy multiplies. Every new payer or provider means another credential, another isolation boundary, another storage target, another handoff into processing. Built in-house, that is per-client infrastructure engineering, repeated for every counterparty signed. At a company of roughly 25 people racing to launch a care orchestration platform, every engineering week spent on ingestion plumbing was a week not spent on the product itself. The interim alternative, moving files by hand across distributed teams, could satisfy neither the isolation requirement nor the compliance controls.

The failure mode was not that ingestion would be slow. It was that without it, the beta could not launch.

What the Ingestion Layer Had to Do

The decision criteria followed directly from that constraint: accept files over SFTP, isolate every counterparty from every other one, route each counterparty’s data into its own GCS bucket, satisfy Arbiter’s HIPAA requirements, and use the Google Workspace identity the company already maintained.

Arbiter selected Files.com to be that ingestion layer.

A Credential, a Folder, and a Bucket for Every Counterparty

Files.com became the multi-tenant ingestion layer between Arbiter’s counterparties and its cloud, with the isolation designed in rather than bolted on.

The construct Arbiter’s chief architect specified maps each client to its own GCP project and a dedicated GCS bucket, one to one. Each payer or provider receives its own SFTP credential, authenticated by SSH key and chrooted to its own folder, so one counterparty cannot see another counterparty’s data. Files.com syncs each folder to the matching bucket using that bucket’s own credentials. Move File Automations route files onward, and Arbiter’s event-driven processing takes over inside its own cloud. The result is end-to-end isolation without a new infrastructure build for every client.

The compliance posture is platform capability rather than something Arbiter built. Files.com operates under an executed HIPAA BAA, retains and forwards audit logs, pins TLS versions, and restricts where logins can originate. Internal users sign in through Google Workspace SAML. A Files.com child site gives Arbiter a fully separate development environment that mirrors production without touching live health data.

The team authored the entire configuration, from SSO and the custom domain to the GCS remote servers, counterparty connections, and SFTP users, in under a week after the site was activated in February 2026.

Live Traffic Within Weeks, and a Pattern That Repeats

With the Files.com layer in production, Arbiter replaced a launch-blocking build project with configuration its team completed in days. Counterparty traffic was flowing by mid-March 2026, weeks after activation, with the first payer and provider counterparties each running on a dedicated connection with per-client automations.

The HIPAA posture the soft beta depended on—from the BAA through log retention, TLS pinning, and geofencing—was met as platform capability, with no ingestion infrastructure built in-house. Every counterparty is isolated end to end: its credential sees one folder, that folder feeds one bucket, and that bucket carries its own credentials. The architecture moves 2 to 4 TB of counterparty data a month at its initial run rate.

The under-a-week figure applies to the initial configuration, not each subsequent onboarding. Arbiter has not quantified the time required to add each new counterparty. But the architecture is per-client by construction, so onboarding the next payer or provider means adding another chrooted credential, folder, and bucket connection. It is configuration that repeats an existing pattern, not an engineering project that starts over.

Ingestion as a Property of the Stack, Not a Project

Before Files.com, Arbiter’s soft beta turned on a question of infrastructure: whether a compliant, multi-tenant way to receive protected health data could exist before the beta did. Today that question is closed. When a new health plan or provider network signs, the intake path already exists as a pattern, isolated to that counterparty and covered by controls the platform enforces, and Arbiter’s engineers stay on the work the company was funded to do: orchestrating care. Per-client isolation for regulated counterparties did not require per-client infrastructure. It required Files.com in front of the buckets Arbiter already owned.