Buckler Securities Replaced Four to Five Hours of Daily FileZilla Transfers With Files.com

Buckler Securities is an institutional broker-dealer based in Greenwich, Connecticut. Registered with the SEC and FINRA, the firm specializes in liquidity: repurchase financing for Treasury, agency, mortgage-backed, and investment-grade corporate securities, along with securities lending and prime brokerage for banks, hedge funds, asset managers, and other institutional clients.

A firm like this runs on counterparty data. Every trading day, files move between Buckler and its market-data and execution vendors: Bloomberg TOMS and MARS, Marex, Trading Technologies, and Instinet. Each vendor has its own SFTP site, its own credentials, and its own way of delivering. And every file has to end up on the trading file server in Greenwich, behind the firm's firewall.

Most of the wider IT function sits at the parent company's headquarters. The Greenwich trading office runs with a single on-site IT resource, and at market open the traders come first. The data the desk ran on moved whenever the one person who could move it got free.

Every Vendor File Moved by Hand, Four to Five Hours a Day

Until late 2024, those files moved by hand. Tom Vaccaro, the office's IT systems administrator, ran the vendor transfers each morning in FileZilla: logging into each vendor's FTP or SFTP site, pulling files down to the local file server, and pushing outbound files back up. The work started around 10 AM and finished by 3 PM. Four to five hours, every trading day, for one person.

The obvious fix was not obvious to build. Each counterparty worked differently. Some pushed files and others had to be pulled. Bloomberg's server exposed locked system folders that a naive sync would trip over. Marex delivered only to whitelisted IP addresses. One Bloomberg report arrived as a CSV attached to an email. A cloud drop point solved nothing on its own, because every file had to land on the on-premise trading file server, behind the firewall, where the business actually used it. The vendors also required Buckler to keep duplicate copies of everything at a site outside the company, where auditors could reach them. There was no second IT person to absorb any of this, and a pile of scheduled scripts would have recreated the same fragility around the same single point of failure.

Meanwhile, the vendor list was growing, and under the manual pattern every new counterparty meant another permanent slice of the morning. Buckler needed a standing hub that could speak SFTP and FTP to every counterparty on that counterparty's terms, run unattended on a schedule, deliver behind the firewall, present fixed IP addresses vendors could whitelist, and hold the off-site copies the vendors required. Buckler selected Files.com to be that hub.

Files.com Between Every Counterparty and the Trading File Server

Files.com became the fixed point every vendor connected to, in whichever direction and over whichever protocol that vendor already used. Files.com normalized these incompatible delivery methods into one unattended workflow.

For SFTP feeds, Buckler configured vendor sites as Files.com Remote Servers, with scheduled syncs pulling new files and Automations pushing outbound files the other way. Files.com also handled the exceptions: exclude patterns stepped around Bloomberg's locked system folders, a Microsoft 365 forwarder routed an emailed Bloomberg CSV into a Files.com Inbox, and dedicated IP addresses gave vendors like Marex a fixed address to whitelist.

On the other side of the firewall, a Files.com Agent ran on the on-premise Windows server. The Agent held only an outbound connection, so nothing had to be opened inbound, and Files.com Automations moved each arriving file down through it to the trading file server. Copies stay on Files.com, and that retention is the point rather than a by-product.

“If the company burned down, auditors can still come in and pull the files from Files.com.”

The rollout ran one vendor at a time, in parallel with the manual process. Marex went first, then Trading Technologies, the two Bloomberg connections, and Instinet. Each vendor's morning FileZilla run was retired only after its scheduled replacement had proven itself, avoiding a single cutover event while the desk continued receiving its data.

Half a Working Day Back, and New Vendors Live Within a Morning

Buckler replaced a morning of hand-run transfers with a schedule that runs whether or not anyone is at a desk.

The four to five hours of daily manual transfer work are gone. Transfers that anchored someone to FileZilla now complete in seconds, on their own schedules. Vendor feeds no longer compete with market open: the traders get the IT resource's morning, and the data arrives anyway.

Five vendor connections run in production, and the Bloomberg and Marex connections were pushing files within a morning of being configured. The off-site duplicate the vendors require also exists by design. Every file that moves through Files.com is retained outside the company, where auditors can retrieve it.

The Next Counterparty Is Configuration, Not Labor

Today, Buckler's vendor transfers run without waiting for someone to start them. The person who used to spend half of every day moving files spends that time on the trading floor's actual problems, while the feeds run on Files.com schedules with a log of every transfer.

The lesson travels. A hand-run counterparty transfer operation does not have to be replaced in a single cutover. Buckler retired its manual process one vendor at a time, switching each feed off the day its Files.com replacement was proven. What remains is a hub where connecting a new counterparty is something one administrator configures in a morning, not labor that recurs every morning after.