Buckler Securities Replaced GRM Visual Vault With a Seven-Year FINRA Archive on Files.com and Azure

Buckler Securities is an SEC- and FINRA-registered broker-dealer in Greenwich, Connecticut, operating in the plumbing of the institutional fixed-income market. It is also a Netting Member of the Fixed Income Clearing Corporation, which places its repo clearing under some of the strictest risk-management standards in the market.

A firm like that is regulated in everything it does, and its files are no exception. Broker-dealer record-keeping rules require Buckler to keep a copy of its records off-site, in storage that cannot be altered by anyone, including the firm itself, and to produce those records years later when a regulator asks. The archive is not IT hygiene. It is a condition of holding the license.

The system Buckler relied on for that obligation broke.

Buckler replaced GRM’s Visual Vault and the lossy nightly script feeding it with Files.com syncs into immutable Azure storage. The new archive captured file states every four to six hours, retained each captured version for seven years, and carried Buckler’s historical records out of Visual Vault before the firm retired it.

The Vendor Archive Broke, and the Script Feeding It Was Never Complete

For years, the archive ran through Visual Vault, an off-site document archiving service from a vendor called GRM. Feeding it was a home-grown job: every night, a Windows scheduled task checked the archive bit on every file on Buckler's servers, copied anything that had changed into a staging folder, and pushed the batch up to Visual Vault.

That design has a flaw no amount of tuning fixes. A once-a-day copy captures only the last state each file was in when the task ran. A spreadsheet edited a dozen times during the trading day left one version in the archive. A file created and deleted between two runs left nothing at all. The obligation is to retain every record, and the archive was structurally blind to everything that happened inside a business day. If a regulator asked for all the files a particular employee saved on a particular date, the honest answer was that the archive might not hold them.

Then the vendor side failed outright.

“When it broke and we were trying to get it fixed, it became obvious that they're not sure what they're doing with it.”

The arrangement had lasted as long as it did because it looked like it was working. Files went up every night, and the gap never showed until someone went looking. Benda, who joined as CTO in late 2024, went looking. He found the broken vendor system, the lossy script underneath it, and one more problem: there was nothing on the shelf to swap in. He searched for a product purpose-built for this exact obligation and came back empty.

What a Replacement Had to Do

Since there was no compliance-archive product to buy, the replacement had to be assembled, and the requirements were unforgiving. It had to capture file versions throughout the day, not just a nightly snapshot. It had to land each captured version in off-site storage that nobody at the firm can modify, shorten, or delete, and hold it for the seven years the rules require. It had to make retrieval defensible, so files could be found by who saved them and when. And it had to rescue years of historical records out of Visual Vault before the vendor relationship ended, because the old archive was still the only copy of the firm's past.

Files.com became that layer: the platform that moved files from Buckler’s servers into immutable cloud storage and the path the legacy archive traveled on its way out of Visual Vault.

Scheduled Sync Into a Container Nobody Can Alter

A Files.com Agent ran on Buckler's on-premise Windows server and connected outbound to Files.com, so nothing on the firm's network had to be exposed to replace the old system. Scheduled Files.com Syncs pulled changed files through the Agent every four hours.

On the far side sat an Azure Blob storage container, connected to Files.com as a Remote Server with versioning enabled. Every change captured by a sync landed there as a new version. The container carried a time-based retention policy of 2,555 days, seven years, enforced at the version level: once a version was written, no one at Buckler could change or remove it until the clock ran out.

That permanence is exactly why the policy was not locked on day one. An immutability mistake cannot be undone, so Benda deliberately left the retention policy unlocked while the sync behavior was validated end to end, with the old nightly push still running alongside. Only after the archive was proven did the policy get locked, in early 2025, and the legacy job get switched off.

The last task was the rescue. Buckler pulled its historical records out of Visual Vault through Files.com into a dedicated directory in the new archive, preserving the original structure, and then ended the vendor relationship.

Version Capture Throughout the Day

With the syncs in production and the retention policy locked, Buckler replaced a once-a-day snapshot pushed to a vendor it could no longer trust with a more frequent, immutable record the firm controls.

• Version capture runs every four to six hours instead of once a day, so far more intraday edits and deletions reach the archive instead of vanishing between daily snapshots.
• A regulator's request for every file a given user saved on a given date is now answerable from storage no one at the firm can alter.
• The syncs run at the scale of a trading operation: the trading directory alone measured 1.1 million files on a single run, synced on a four-hour cycle.
• Visual Vault is retired, and the firm's historical records reached the new archive first, so ending the vendor cost none of the past.

A Regulator-Grade Archive Without a Specialist Vendor

Today, one of a broker-dealer's most unforgiving obligations runs on two commodity parts: Azure storage the firm already trusted, and Files.com keeping it fed. What Buckler assembled is stricter than the specialist system it replaced, because the immutability is enforced by the storage itself rather than promised by a vendor, and it was validated end to end before the lock was made permanent.

The difference lands where it matters. An examiner's request used to arrive at an archive that only ever saw one version of each file per day, held by a vendor who, when it broke, turned out not to understand it. Now the same request comes back out of a record that captures far more of the working day, from storage nobody can touch.