DBi Built a Permanent Archive on Files.com for Custodian Files That Vanish in Ten Days

Dynamic Beta Investments (DBi) is a New York alternative investment manager and a pioneer of hedge fund replication. It runs billions of dollars across US ETFs, European UCITS funds, and vehicles for Japanese investors under SEC, CFTC, and NFA regulation—all with a lean bench of senior investment professionals rather than a large operations department.

Running those funds day to day is an exercise in consuming other firms' files. Net asset values, cash balances, positions and risk data arrive from the custodians, administrators and counterparties that service each fund—BBH, State Street, and more than a dozen others. Every one of them delivers to an SFTP server that the counterparty itself owns and hosts. DBi's trading and middle-office work starts wherever those firms choose to put the data.

Fund Data That Lived Only as Long as Each Vendor Kept It

Before Files.com, DBi worked directly off those counterparty servers. Whatever a custodian posted, the team connected to that vendor's SFTP and used the file in place.

“We wanted to synchronize all of our data from all these various third parties into Files.com so we can build a historical repository and keep the original files, because sometimes a vendor can delete a file and then put in a new file.”

The cost landed on the firm's record of its own inputs. Most counterparties hold files for only about ten days before deleting them. Some delete a file and post a replacement in its place. The daily Summary Net Asset Value files from State Street that the team uses to extract fund assets and run risk, the cash and position data behind the middle office: all of it existed only as long as each vendor chose to keep it. When a file was replaced, the original was gone, and with it the history of what a given day's numbers had actually been run on.

None of this could be fixed at the source. The counterparties own the delivery infrastructure, and a boutique manager cannot ask a global custodian to change its retention policy or its hosting for one client. Any fix had to happen on DBi's side. And DBi runs its operations with senior investment staff, not a dedicated infrastructure group, so whatever collected the data would have to be built and operated by the trading desk itself.

As DBi rebuilt its data infrastructure and the roster of counterparty feeds kept growing, working off each vendor's server directly stopped being sustainable. What the firm needed was specific: connect outbound to every counterparty SFTP it dealt with, pull files on a schedule, hold the originals on DBi's side for as long as DBi wanted, keep them exactly as they arrived, and hand working copies to the tools where analysis happens. DBi selected Files.com to be that central ingest layer and system of record.

One Platform Pulling From Every Counterparty

Files.com became the one place all counterparty data lands, and the only place the original of every file is guaranteed to survive.

DBi configured a Files.com Remote Server connection to each counterparty SFTP. DBi and each counterparty whitelisted the dedicated site IPs needed for the connection, but the counterparties kept their existing delivery infrastructure and process: they continued delivering to their own servers, and Files.com reached out and pulled. Solanki configured the connections himself after a single walkthrough, then built the estate counterparty by counterparty over roughly a year until every available vendor was connected, growing from eight or nine servers to fourteen at the peak.

Scheduled syncs pulled each vendor's files into Files.com native storage on DBi's schedule, retaining for a year or more files the source systems deleted after roughly ten days. Files.com Automations created a real-time working copy in SharePoint, where data manipulation happens, while an API key gave DBi's risk provider programmatic retrieval from the archive. The Files.com copy is never touched.

“I'm just creating a SharePoint copy of the Files.com files to keep the Files.com files raw and untouched, original.”

The Original of Every File, Kept on DBi's Side

With the Files.com estate in production, DBi replaced day-to-day work against a dozen separate vendor servers with a single archive the firm owns.

• Files that counterparties delete after roughly ten days are held in Files.com for a year or more, so the inputs behind any NAV extraction or risk run can be produced long after the vendor's copy is gone.
• When a vendor deletes a file and posts a replacement, DBi still holds the original as it first arrived. Silent loss of an original can no longer happen.
• The archive grew from under a gigabyte at onboarding to more than half a terabyte of retained originals.
• Adding a counterparty stopped being a project. It is one more Remote Server connection and an IP whitelist entry, and the new feed lands in the same archive and flows through the same downstream syncs.

All of it—the connections, the syncs, the SharePoint flows—is configured and run by the trading desk itself. A firm managing billions across US and European fund structures operates its entire counterparty data estate without a dedicated infrastructure team.

The History Now Belongs to DBi

Today, the record of the data DBi's funds run on belongs to DBi. Analysis happens on the SharePoint copies, while the originals sit in Files.com exactly as they arrived from each custodian, so the desk can pull the file behind a months-old risk run whenever a question comes up. That used to be impossible ten days after delivery.

And DBi got there without asking a single counterparty to change its delivery infrastructure or process. BBH, State Street and the rest deliver today exactly as they always have. Files.com built the permanence on DBi's side of every connection, operated by the people who use the data.