An Alternative Asset Manager Scales from Three Manual SFTP Flows to Dozens of Connections on Files.com—Without a File Server

A US alternative asset manager was built unlike almost any firm it trades with: entirely cloud-based from inception, with no data center, no server room, and a technology estate made of SaaS products.

The industry it plugged into was built the opposite way. The first operational need of any asset manager is file exchange with its counterparties. End-of-day holdings, trade and position files move every day between the firm and the banks, custodians, fund administrators, trustees and pricing services that sit behind each position.

Over four years, three hand-run external flows became dozens of remote server connections, while the firm’s technology team never stood up a file server.

Ten Files a Day, All Moved by Hand

When the firm came to Files.com, that exchange ran on people. The firm had three external flows moving five to ten files a day, handled manually over desktop SFTP clients, alongside a Box fileshare kept in sync by hand.

The cost was not the ten files. It was what each one carried and what each new relationship added. These are the files that price and settle positions, so a transfer that lands late, half-written, or under the wrong name is a portfolio problem before it is ever an IT problem. Every new counterparty relationship meant another set of transfers for the technology team to carry by hand. A young firm adding banks and custodians as fast as it added strategies could start that way. It could not scale that way.

The Counterparties Set the Terms

What made the problem hard to fix was that the firm controlled neither end of the exchange. A young firm could not ask a global bank to modernize. The counterparties dictated the terms: SFTP-only interfaces, fixed filenames the sender had to produce exactly, folder conventions the firm could not rename, and strict change-management rules before any new connection touched production.

The incumbents the firm competes with answered those terms with the on-premise transfer estates they had accumulated over decades. The firm had deliberately built nothing of the kind, and did not intend to start.

So the fix had to do a specific set of things. Speak SFTP to the outside world as fluently as any bank’s own estate. Connect to the SaaS systems on the inside: SharePoint, Azure Blob, Box and Salesforce. Repeat per counterparty without new infrastructure. Satisfy each counterparty’s change-management process. And retain transferred files against a multi-year requirement. The firm selected Files.com as the transit hub between its SaaS estate and the SFTP endpoints of its counterparty network.

One Repeatable Pattern for Every New Counterparty

On Files.com, each counterparty followed the same construction: a remote server mount pointed at the counterparty’s SFTP server, plus a chain of syncs and Automations that carried files between that mount and the firm’s internal systems.

The firm’s work was configuration, not infrastructure: create the mount and sync chain, run it through the counterparty’s UAT process, then promote it to production. The roughly month-long calendar window came from the counterparty’s change-management requirements, not from building new transfer machinery.

Where a counterparty required the firm to host the endpoint rather than the reverse, Files.com hosted the SFTP endpoint itself. Where an application was reachable only across a private VPN tunnel, a Files.com Agent deployed in the firm’s Azure tenant routed SFTP through the tunnel, so the connection originated inside the firm’s own network with nothing exposed inbound.

The result is that no counterparty’s rules, however particular, require new machinery. They require a mount and a sync chain.

SharePoint Stays the Record, Files.com Does the Moving

On the inside, the firm kept SharePoint as its internal storage of record and positioned Files.com deliberately as the transit layer. Files.com syncs carry counterparty files into and out of the repository where the business actually works.

The data warehouse feeds the same layer. Snowflake produces daily files in Azure Blob; Files.com Automations rename each file in flight to the exact fixed name the receiving counterparty requires and deliver it to that counterparty’s server. Uploads move into place only on completion, so a counterparty’s delete-on-read process never picks up half a file.

Files.com also retains copies against the firm’s multi-year data retention requirement. Every transfer lands in the audit log and forwards into Microsoft Sentinel, the firm’s SIEM.

From Three Flows to a Full Counterparty Network

With the Files.com layer in production, the firm replaced hand-run routine transfers and a hand-synchronized fileshare with a repeatable per-counterparty pattern. The original three external flows became dozens of remote server connections and Agents spanning banks, custodians, fund administrators, trustees, sub-investors, and actuarial, risk and pricing services.

A new counterparty now comes online routinely without additional infrastructure. During that expansion, company headcount multiplied and the file layer absorbed the growth. The platform also meets the multi-year retention obligation with a forwarded log of every transfer instead of a policy someone has to remember.

The immediate result is that routine counterparty flows no longer depend on someone moving each file by hand. The compounding result is larger: counterparty connectivity stopped being a project. The next bank costs the firm a configuration, not an integration, and the business can add relationships at whatever pace the deals demand.

Connecting Systems Instead of Running Them

Today, trade and end-of-day position files cross between the firm’s SaaS estate and its counterparties through Files.com. When the technology team takes on a new bank, the conversation is about that bank’s change window rather than about servers.

That is the difference worth carrying away. Being cloud-first in finance never required the banks to modernize, and it never required the firm to quietly build the on-premise transfer estate it was founded to avoid. The SFTP the industry demands is real and permanent; it just runs on Files.com instead of on anything the firm owns. Four years in, the firm is still what it set out to be: a company that connects systems rather than running them.