An Alternative Investment Firm Runs One Files.com Connection Layer Between Its Counterparties and Its Data Lake

A global alternative investment firm specializes in credit and credit-related assets, with strategies spanning asset-based finance, real estate, and corporate credit, and is regulated as an investment adviser in several jurisdictions. The firm describes its whole platform as data-driven: an in-house data science team shapes how it underwrites and gives it a real-time view of the assets it holds.

That data comes from outside. A credit and mortgage investing business runs on files from other people's systems: banks, loan servicers, originators, and data providers across the US and Europe. Every deal the business side signs creates a recurring data exchange with a new counterparty. Some send daily raw data. Some send monthly reports. Individual deliveries can run to many gigabytes. The counterparty dictates the protocol, the encryption, and the cadence, and many of them have no technical team at all. For the firm, file exchange is how the raw material of the investment process arrives.

Every New Deal Meant Another Hand-Built Connection

Before Files.com, the firm ran that exchange itself. Inbound files landed on a self-hosted Cerberus FTP Server. Outbound, the firm connected point to point to each counterparty's SFTP endpoint, with no management layer over the connections. Files moved through desktop SFTP clients, manual SSH sessions, and custom scripts written by individual teams, and each connection was its own small project with nothing above it to manage them as a set.

The cost showed up in two places. The first was effort. Every deal the business signed meant another bespoke connection for someone to build and then maintain indefinitely, and the firm's own developers were spending engineering time building an in-house file transfer capability because the connections had to exist and nothing else was there to carry them. The second was access. The firm wanted every person who reached a counterparty endpoint to do so under an individual identity tied to the corporate directory, with access granted and revoked by the firm rather than passed between people. For a regulated investment firm, access to a counterparty feed has to belong to a named person. And the firm wanted a separate environment for testing, so a new counterparty workflow never shared a system with a live data feed.

Each connection, once built, worked. What ended the estate was compounding. The counterparty count climbed with the deal flow, large deliveries had to move reliably over SFTP the counterparties mandated, and the load outgrew what could be managed by hand. The firm decided to stop letting its developers rebuild file transfer and buy it instead.

What the replacement had to do was already written in the shape of the old estate. Connect to every counterparty on the counterparty's terms: pull from their SFTP servers and S3 buckets, accept pushes from those who could send, and decrypt GPG-encrypted deliveries on arrival. Give the counterparties with no technical team a web experience instead of a protocol. Give every internal user individual access tied to the corporate directory, with the platform holding the credentials to vendor endpoints. Keep testing away from production. And log all of it completely enough to stand as the firm's compliance record.

The firm selected Files.com to be that layer.

One Connection Layer Between Counterparties and the Data Lake

Files.com now sits between the firm's external counterparties and its internal systems, as the staging and routing layer for everything that crosses the boundary.

On the inbound side, Files.com Remote Server Syncs pull from counterparty SFTP servers and S3 buckets on schedule, and counterparties that can push deliver files directly into the platform. Where a counterparty mandates GPG encryption, Files.com decrypts on arrival, inside the flow, with no manual step. Automations then fan each file out to where it is consumed: to S3 for the firm's data lake, and to SharePoint, where the business reads its reports. Most of what arrives through Files.com ends up with the data science team, reaching them through those two destinations without anyone touching a file in between.

Counterparties with no technical team get a different front door into the same layer. Each is onboarded with an individual account, a self-set password, an upload-only folder, and an email notification when new files are waiting, all through a consistent web interface on the firm's own domain.

A separate staging site, with its own domain, runs alongside production. Counterparty testing and developer testing happen there, so a new workflow never touches a live feed until it works.

The migration itself ran one connection at a time. As the business made deals, the team rebuilt each counterparty connection on Files.com and converted the old CLI transfer scripts into Syncs, onboarding several counterparties a month at the peak without interrupting the daily and monthly feeds the analytics side depends on.

Individual Access Through the Corporate Directory

Access changed shape entirely. Internal users sign in through the firm's Microsoft Entra SSO, with accounts and groups provisioned automatically from Active Directory over SCIM. A user who logs in sees exactly the folders they are entitled to see. And when someone needs to reach a vendor's SFTP site directly, Files.com brokers it: the platform holds the one stored credential to the vendor endpoint and grants named users ad hoc access through it.

On top of the platform, the firm's infrastructure team built a production control plane. It wrapped the Files.com CLI in a PowerShell layer and provisioned the site with the Files.com Terraform provider. Automated monitoring retries failed operations and alerts the team only when a failure persists. Activity logs export to the firm's SIEM, Sumo Logic. The firm operates the platform the way it operates the rest of its infrastructure: monitored, alerted on, and defined in code.

One Governed Layer Between Counterparties and the Firm

With Files.com in production, the firm replaced a self-hosted server and a hand-built connection per counterparty with one governed layer between the outside and the inside.

• Files.com is the single connection layer to the firm's counterparties. Dozens of outbound connections were consolidated onto it, new ones are added as deals are signed, and terabytes of data a month move through it.
• Access to every counterparty endpoint is individual, tied to the corporate directory, and granted through the platform, which holds the stored vendor credentials itself.
• Onboarding a counterparty is configuration, not engineering. During the buildout the team brought on several a month, and the connection estate now grows with the deal flow rather than with engineering effort.
• The developers moved off file transfer. The in-house capability they had been building and maintaining was retired along with the server.
• The internal support burden for FTP access disappeared. Users sign in through SSO and see what they are entitled to see, so access questions stopped landing on IT.

The layer has run at production scale since: individual automations have accumulated tens of thousands of runs. And the record those runs leave behind is itself an outcome. Files.com's logging is complete enough that the firm's compliance baseline is met from the platform's own records, and when a counterparty disputes whether a file was sent or received, the firm settles it by handing over the log.

The Glue Between the Outside and the Inside

Today, when the firm's business side signs a deal, the data feed that comes with it lands in a pattern that already exists. Someone configures a sync and a set of permissions, and the counterparty's files start flowing to the data lake and the business.