A Multi-Manager Hedge Fund Replaced Fortra’s JAMS and Custom Scripts With Files.com for Dozens of Counterparty Relationships

A global multi-manager hedge fund adviser does not simply pick managers. It engineers the terms of the allocation itself, directing its portfolio in collaboration with a large roster of established hedge funds and individual portfolio managers, with a risk operation running on a near-24-hour basis across time zones.

A business built that way runs on other institutions' data. The prime brokers, fund administrators, market-data vendors, and client banks in the firm's network all hold files the firm needs every day: position data, risk analytics, NAV reports, performance files. The firm controls none of the systems those files sit on. Its operation depends on pulling a handful of files a day from each of dozens of counterparty endpoints, on time, every day.

Dozens of Counterparty Feeds, Held Together by Hand-Built Scripts

The machinery doing that work had grown up one feed at a time. Custom PowerShell and Python scripts synced files from each partner's SFTP or storage endpoint. A JAMS scheduler, running active/active across two nodes, orchestrated the scripts. An SFTP server that the firm maintained itself handled inbound delivery. Every counterparty connection was bespoke code, and the whole estate had to be kept alive by hand.

The cost fell on the operations team, which oversaw the estate alongside everything else it does. Every new prime broker or vendor feed meant writing and testing more code. And the firm was in the infrastructure business whether it wanted to be or not, operating its own SFTP server, work that has nothing to do with allocating capital.

The stakes were sharpest on market data. Investment decisions depend on Bloomberg AIM, Axioma, and NAV data being in hand within a minute of availability. Bloomberg AIM reports land roughly every half hour, and each one feeds the PowerBI dashboards the firm tracks P&L on. A feed that runs late is not an IT ticket. It is stale data sitting underneath a live investment decision.

The firm had outgrown connectivity built by hand. Its operations team needed to run the growing counterparty network as configuration rather than code, honor the different constraints imposed by every institution, and keep critical feeds on a one-minute cadence. As volumes climbed, the firm needed a repeatable way to add and run feeds that did not mean more scripts, more scheduler jobs, and another server to keep running.

The Counterparties Dictate the Terms

The estate had lasted as long as it did because no generic replacement fit it. In this business, the counterparties set the rules of every connection, and each one sets different rules.

Large banks will not restructure their directories for one client. At some of the firm's partner sites, the firm had to sync an entire remote directory tree while excluding subfolders it was forbidden to read. Encryption varied by institution: some counterparties GPG-encrypt every file they deliver and others do not, and both kinds had to land in the same workflow. The destination was fixed too. Processed data had to end up decrypted on the firm's own servers in Azure, where the firm's processing runs, not sitting in a cloud silo.

And any migration had to happen underneath live feeds. The data could not stop arriving while the plumbing changed, so each connection had to move individually, on its own schedule, with the legacy scripts still running until each replacement was proven.

What the new layer had to do was therefore specific: connect to any counterparty's endpoint on that counterparty's terms, down to the subfolders the firm was allowed to touch; decrypt inbound files as they arrived; deliver the results onto the firm's own servers; hold a one-minute cadence on the market-data feeds; and leave the firm nothing to host or maintain. The firm selected Files.com to be that ingestion and delivery layer.

One Ingestion and Delivery Layer on Files.com

Files.com became the single layer between the counterparty systems and the servers where the firm processes data. Everything the scripts and the scheduler used to do ran as configuration on one platform.

Files.com Remote Server Syncs pulled from each partner's SFTP endpoint using that partner's own authentication and schedule. Where a bank exposed a directory tree containing folders the firm was forbidden to read, root-level syncs with exclude patterns skipped those paths, so the bank changed nothing and the firm stayed inside its permissions.

Automations routed every inbound file, encrypted or not, into one consolidated pickup point, while GPG decryption and Files.com Agents placed the results on the firm’s Azure-hosted servers for processing.

The business-critical feeds ran on the shortest leash the platform offered: the Bloomberg AIM, Axioma, and NAV syncs executed every minute, because the firm required that data within a minute of it becoming available. The firm also presented a fixed identity to its counterparties, running a custom domain with dedicated IP addresses, so partners that restricted inbound connections had stable addresses to whitelist.

Market Data Within a Minute, Without Code to Maintain

With the Files.com pipeline in production, the firm replaced a hand-built connectivity estate with configuration. The PowerShell and Python partner-sync scripts and the two-node JAMS scheduler are gone.

• Business-critical market data is in hand within a minute of availability. The Bloomberg AIM, Axioma, and NAV feeds sync every minute, and each half-hourly AIM report flows straight into the PowerBI dashboards the firm tracks P&L on.
• The entire estate of counterparty relationships is operated as configuration. The operations team administers the whole platform as configuration, with no code to maintain and no scheduler jobs to watch.
• Adding a counterparty is configuration, not development. A new feed is a sync pointed at the partner's endpoint, carrying whatever exclusions, credentials, and keys that partner requires. There is no script to write.
• Growing volume is absorbed without new machinery. A single vendor feed already delivers thousands of files a day through the same pipeline, and it is expected to keep growing.

The platform also answered a question the old stack never could. When one of the world's largest banks put the firm through its third-party risk process, it required attestation of exactly who owns and provides the IP addresses connecting to its systems. The firm answered with Files.com's owned IP range and its dedicated addresses, and passed the bank's connectivity vetting. On the homegrown SFTP setup, that attestation would have been the firm's alone to produce.

Connectivity Without Code

Today, counterparty connectivity at the firm is not an engineering practice. When the firm needs a new prime broker or vendor feed, the operations team points a Files.com sync at the counterparty's endpoint and the data starts flowing through the same decrypt-and-deliver pipeline as everything else. Files that used to arrive because somebody wrote, scheduled, and watched a script now arrive because the platform is doing the watching.

The migration itself is the part any firm running a similar estate can borrow. The firm never asked its counterparties for anything: the banks kept their directory structures, the encryption requirements stayed exactly as they were, and the legacy scripts kept running while each feed moved individually, until there was nothing left for the scripts to do. A connectivity estate built by hand over years did not have to be replaced in one move. It was replaced one feed at a time, on Files.com, without a single counterparty noticing.