Starwood Capital Brings Operator Data Collection In-House With Files.com and Direct-to-Azure Delivery

Starwood Capital Group is one of the largest private investment firms in global real estate. It manages roughly $130 billion of assets and has invested in virtually every category of property across more than 35 countries. The firm's operating model has a structural consequence for its data: Starwood owns the assets, but third-party property management and operating companies run them day to day. The rent rolls, general ledgers, P&Ls, and lease files that describe how the portfolio is actually performing originate outside the firm, at those operators, and arrive as files, mostly Excel, mostly on a monthly cycle. Starwood brought that collection in-house with a Files.com portal that kept intake simple for operators while routing files directly into a structured Azure Blob hierarchy for its own validation pipeline.

Rent Rolls From Operators, Through Channels the Firm Didn't Own

Starwood did not control the intake of the data its investment analysis depended on. A third-party data services vendor handled file collection, validation, and transformation for much of the operator estate. What arrived directly came through fragmented channels: Excel attachments over email routed by an Azure Logic App, including files carrying PII and PHI; a basic Azure-portal SFTP endpoint for a handful of more technical vendors, each requiring firewall IP whitelisting and hand-managed passwords or SSH keys; and manual uploads.

The cost showed up in what the pipeline could do with what arrived. Submissions came in inconsistently formatted across 10 to 15 operators, and a file with no month or asset attached to it could not be classified for automated processing.

“We can't automatically do anything with it.”

The volume made manual handling untenable. A single operator can manage a dozen properties, each submitting several file types per cycle, so one counterparty alone could generate three dozen files in a reporting period.

The Insourcing Problem: Simple for Operators, Structured for the Pipeline

Under a new CTO, Starwood was rebuilding its data infrastructure from the ground up, and it decided to bring operator file collection in-house rather than keep outsourcing it. The rebuild raised the stakes: as projects kicked off across new asset classes, the team kept surfacing more data sources it needed to bring in, so intake had to be a repeatable pattern rather than per-vendor plumbing.

The obvious ways to insource failed at opposite ends. Starwood had already walked the build-it path: an internal Streamlit app running in Snowflake handled uploads, and extending that approach meant owning partner-facing UX, authentication, and external user administration forever. Exposing raw SFTP or cloud storage to the operators failed at the other end, because the people submitting the files are property managers, not engineers.

“Unfortunately, people that provide data are not always data people.”

Operators export files from their systems by hand, and asking them to navigate a deep folder hierarchy, where a file dropped in the wrong place breaks the pipeline, was never going to hold across a growing partner set.

One more constraint ruled out most packaged portals: Starwood refused a second data estate. Files had to land directly in the firm's existing Azure Blob Storage as a single governed copy, feeding the schema validation functions and Snowflake pipeline its own team was building.

So the front end had to do four things at once: be simple enough for a non-technical property manager to use without training, write uploads straight into the Blob hierarchy the pipeline expects, keep every operator's submissions apart, and hand each arriving file to Starwood's own validation code. Starwood selected Files.com to be that ingestion layer.

A Flat Drop Zone in Front, Starwood's Azure Hierarchy Behind

What Starwood built with Files.com is a governed front door between its operators and its analytics pipeline, and its defining design choice is inversion: the partner-facing view is deliberately flat, and the storage behind it is deliberately deep.

“I don't want them to even know about the folder structure. That's for us, but the front end I want to make stupid simple.”

Operators sign in to a white-labeled upload portal on Starwood's own domain and see a few labeled locations for their submissions. Files.com Partner Channels remap each of those flat upload locations into the deep Azure Blob hierarchy keyed by operator, asset, and file type. The connection writes directly to Blob, so a file lands in Starwood's own storage the moment it is uploaded and no second governed copy accumulates in a separate system.

Classification is enforced at the door. Files.com filename rules stop files that cannot be classified, while rename rules stamp a timestamp and the operator's name onto every file as it arrives. The context that used to make a submission dead on arrival now travels with the file automatically.

Validation stays Starwood's own code. A Files.com webhook triggers the firm's Azure Functions to check each file's column structure before anything enters the Snowflake load path. A file that passes moves on, and a file that fails is rejected back to its provider.

Internal data team users come from Okta, while each operator gets siloed accounts scoped to its own drop zone. That replaced firewall whitelists and hand-managed SSH keys as the price of connecting a counterparty. The front end was delivered by configuration: a single systems manager stood up the custom domain, the Okta connection, and the Azure Blob link, while Starwood's engineering effort stayed confined to its own validation functions.

Intake the Firm Owns, on a Single Copy of the Data

With the portal in production, Files.com replaced the outsourced vendor's collection process, retired the internal upload app, and gave operator submissions that had arrived ad hoc over email a governed path instead. Collection and classification now run through an intake layer Starwood controls, with submissions carrying PII and PHI landing as a single copy in the firm's Azure Blob Storage rather than riding in as email attachments.

Files arrive with the operator, asset, and file-type context the pipeline needs, so Starwood's systems can act on a submission instead of waiting for a person to decipher it. Onboarding the next operator is provisioning, not an integration project: a new partner needs an account and a drop zone rather than a firewall change, a credential exchange, or custom plumbing. That is what lets the pattern absorb the new asset classes and data sources the rebuild keeps surfacing.

The Front Door Starwood Controls

Today, a property manager at one of Starwood's operators signs in to a page carrying Starwood's name, drops a rent roll into a labeled box, and is done. Behind that box, Files.com has already routed the file into the right branch of the firm's Azure hierarchy, stamped it with the context the pipeline needs, and handed it to Starwood's own validators on its way toward Snowflake. Before, that same file was an attachment in an inbox, or a step inside an outsourced vendor's process.

The lesson travels well beyond real estate. Starwood insourced partner data collection without building a portal and without teaching its counterparties anything about its architecture. Files.com let the firm give non-technical partners a stupid-simple front end while keeping a strictly structured backend, on one governed copy of the data, in the storage it already ran.