A Regional Bank Replaces WinSCP With Scheduled Files.com Syncs Over Azure Blob

A US regional bank is built on commercial, treasury, and retail banking, with insurance, mortgage, and other affiliates alongside. It has grown largely by acquiring other banks.

A bank of that kind runs on files. Every business day, wire files, ACH batches, image cash letters, loan-servicing batches, and the transaction files that update online-banking balances move between the bank and the vendors that process them. Most of those files carry a deadline set by someone else: a vendor's overnight job, an accounting close, the wire system's daily closeout.

The bank also made an infrastructure choice unusual for a regional bank. It is cloud-first, with Azure Blob storage as the backbone of its application estate, and it ran no traditional managed file transfer platform in front of that estate. Those two facts together are the story: a business made of deadline-driven file exchange, with no dedicated machinery to run it.

Deadline-Driven Files, One Vendor at a Time

Until 2022, those transfers ran from a desktop SFTP client. An engineer opened WinSCP and worked through the day's exchanges vendor by vendor: loan-system exception files staged ahead of a vendor's early-morning job, deliveries to the accounting platform by mid-morning, month-start batches from the loan servicer, and an end-of-day file the wire system needed before closeout.

The bank wanted each of those exchanges to run itself, on a schedule set once. A desktop client moves a file when someone runs it, and the bank's list of vendors was only going to grow.

The routine had grown one vendor at a time, and the bank adds counterparties as a strategy. Its commercial and treasury client base keeps expanding, and every acquired bank arrives with its own set of live vendor flows that must keep running through the transition. A bank whose growth model is more counterparties needs file exchange that scales by configuration, and the bank had outgrown a desktop client.

Cloud-First, With No Place to Put an MFT Appliance

The conventional answer for a regulated bank is an on-premise MFT platform. For this bank that was a poor fit. Its storage and applications live in Azure Blob, so an appliance would have added a box to patch and a hop in every path, and forced internal applications to start delivering files somewhere new.

What the transfer layer actually had to do was specific. It had to speak SFTP to hundreds of external counterparties, each with its own quirks: connection caps, encryption requirements, firewall rules demanding fixed IP addresses. It had to read and write Azure Blob directly, so internal applications could keep dropping files exactly where they already did. It had to run every exchange on a schedule, with no one in the path. And it had to present itself to partners under the bank's own name.

The bank selected Files.com to be that layer, and stood it up in 2022. Vendor SFTP connections moved one by one while WinSCP ran alongside during the cutover.

Azure Blob on One Side, Hundreds of Vendor Endpoints on the Other

Files.com became the hub between the bank's Azure storage and its vendors. The folders that files arrive in and leave from are Files.com folders, each remote-mounted to an Azure Blob container. An internal application that writes a file to Blob has, by that act alone, handed it to the transfer platform. Scheduled Files.com syncs do the rest: pushing outbound files to each vendor's SFTP endpoint, and pulling inbound files back into Blob for downstream processing.

The estate now runs hundreds of remote servers and more than a hundred syncs, most of them on a cadence of minutes. Vendor endpoints do not behave uniformly, and Files.com absorbs those differences in configuration.

To partners, the whole exchange runs under a transfer domain carrying the bank's own name, with dedicated IP addresses that vendors whitelist in their firewalls. Standing up a new third party now follows the same repeatable pattern of connectivity testing, encryption, two remote mounts, and a scheduled sync in Files.com.

A Hub for Bank File Movement

With the hub in production, the bank replaced desktop-client transfers with a scheduled exchange pattern and kept extending it across the bank.

• The morning accounting delivery and the end-of-day closeout file move on syncs that run on their own schedule, every business day.
• Outbound partner connections grew by dozens in a single year, and each addition followed the standard pattern rather than becoming a new project.
• The same pattern absorbs whole acquisitions. File flows for acquired institutions can be stood up and tested on Files.com ahead of the transition and kept delivering afterward.

File Movement the Bank Can Grow On

Today, the end-of-day file the wire system needs before closeout is collected and delivered by a Files.com sync, on schedule, the way every exchange on the list is. Every deadline the bank's vendors set is met by a sync that runs on its own schedule.

The larger difference is what the bank can take on. The bank adds commercial clients, adds treasury counterparties, and acquires entire institutions, and each new relationship's file exchange comes online the same way the last one did. File movement became infrastructure the bank grows on.

And the bank got there without ever buying the appliance. Files.com mounted the Azure Blob storage the bank already ran and put governed, scheduled SFTP exchange in front of it. The transfer layer fit the cloud the bank had built, instead of asking the bank to build around the transfer layer.