An Armored Courier Replaced Citrix ShareFile With File-Triggered Report Delivery to Partner Banks

A US armored courier collects cash from thousands of clients across more than a dozen states, including retailers, ATM operators, and money services businesses. Regional processing sites count that cash, vault it, and prepare it for deposit.

But the thing a client's bank actually receives from the courier each day is not cash. It is a file: a daily deposit, currency-order, or vault-summary report, delivered to a network of financial institutions so that customer accounts are credited or debited by the next business day. Strip away the trucks, and the last mile of cash logistics is a file transfer with a settlement deadline that arrives every single business day, in four US time zones at once.

A Portal Built for People, Doing the Work of a Delivery System

Until 2023, that delivery ran on Citrix ShareFile, fed from SharePoint sources upstream. ShareFile is a platform designed for people sharing documents with people, and the courier was asking it to be something else: a delivery network for systems.

The mismatch showed everywhere. ShareFile could not be made to accept automated uploads at all. Every file movement was therefore either manual or ran on a fixed schedule, and fixed schedules fail structurally against this workload, because daily report files come off processing at different times each day. A schedule set early ran before the files existed. A schedule set late had to be re-run to catch stragglers. There was no schedule that was correct, because the correct trigger was the file itself.

Administration carried the same weight. Hundreds of partner users had to be managed one at a time, and reporting on them was a manual chore.

Replacing the partner-facing platform was not a weekend job. The counterparties on the far side of the delivery are banks, many running their own automated pulls on their own schedules, with any change to a path or a credential coordinated through each institution's IT team.

What made the arrangement untenable was growth. The courier was steadily adding financial institutions, and every new bank meant more folders, more manual movement, and more schedule-guessing on a platform that could not automate. The delivery operation could only scale by adding people.

The replacement had to do four things: move files when they arrive rather than when a clock fires, present a per-institution folder structure that banks could reach over SFTP or plain web download, apply encryption and long-term retention to delivered reports, and cut over without breaking a bank's existing automated connection. The courier selected Files.com to be that delivery layer.

Standing Up the New Network Behind the Old One

The migration began in April 2023 as a parallel bridge. SharePoint synced into Files.com, and a Files.com Automation pushed files onward into a ShareFile FTP mount, so partner banks kept downloading from exactly the place they always had while the new network was proven behind it. Most of the processing sites were configured in a single day.

The following month, the bridge gave way to a direct cutover, and by mid-2023 the partner user base had been moved onto Files.com. Institutions running their own automated SFTP pulls moved at their own pace, with changes coordinated through each bank's IT team, so the courier did not force a bank's automation to change on its timetable.

Delivery Triggered by the File, Not the Clock

What the courier built on Files.com was an event-driven delivery network: the reporting engine produced per-institution files, and the arrival of each file was what moved it.

Create-triggered Files.com Automations watched the staging folders and fanned each report into the correct institution's delivery folder the moment it landed. A file that came off processing at six in the morning and one that came off at two in the afternoon took the same path, with no schedule to guess and no second pass to catch stragglers. Scheduled Automations handled the movements that genuinely were time-based, and a daily sync archived every delivered file, with long-term retention as standard practice.

The delivery structure ran to hundreds of per-institution folders, keeping each institution's reports separated. SFTP was the primary partner protocol, with delivery jobs that once ran over FTP moved to SFTP. PGP encryption was applied at destination directories, and folder-level email notifications were timed for each institution's time zone.

Files.com Remote Server Mounts and the Files.com Agent connected the network to Azure Blob storage, the reporting engine, and on-premise production servers over outbound-only connections that required no inbound firewall openings.

One Repeating Pattern for Every New Bank

With the Files.com network in production, the courier replaced a hand-fed portal and schedule guesswork with a delivery pattern that repeats identically for every institution.

• Nobody moves a daily report by hand. Files.com Automations run the delivery network across every institution's folders.
• Some institutions collect their files fully unattended over their own SFTP pulls, while most self-serve by web download against the same per-institution folders.
• Onboarding a new bank is a folder and the standard automation pattern, not a bespoke project.
• New processing sites use the same delivery pattern, and every delivered report is archived automatically and retained long term.

The immediate result was the disappearance of manual movement and schedule guesswork. That matters because these reports drive the credits and debits due by the next business day: as soon as a report exists, its delivery begins. The compounding result is larger: growth stopped costing process. Each new institution and each new processing site lands on a pattern that already exists, which is what let the delivery network expand for years without the operation expanding underneath it.

A Delivery Network, Not a Better Portal

Today, when reports come off a processing site, whenever they come off, they move. The analysts who run the estate no longer spend their days feeding a portal or guessing at schedules; their job is the network, and Files.com does the moving.

The courier did not swap ShareFile for a better sharing portal. It replaced a platform built for people handing files to people with a Files.com delivery network built for systems delivering to systems, because when files arrive on their own schedule and settlement has a deadline, reliability comes from event-triggered automation, not from tighter scheduling.