A Community Bank Retired Titan SFTP and Automated Core Banking Flows on Files.com

A mid-sized community and commercial bank operates banking offices across a multi-state footprint. A recent merger of equals expanded that footprint, and the bank supports business lending, treasury management, and fraud protection tools for commercial clients.

That operation runs on files. A handful of banking vendors, FIS and Q2 among them, exchange the transactional files that update the bank's core system every business day. Daily account extracts and transaction reports flow back out to commercial clients, who load them into their own accounting systems. The bank sat in the middle of all of it, carrying that traffic on self-hosted SFTP servers and cron-based transformations it wanted off its network, and through manual steps that depended on specific people being at their desks every day.

Self-Hosted Servers and a Person Sending the Daily File

An on-premises Titan SFTP server sat on its own network segment. A second self-hosted SFTP server executed roughly 20 cron jobs that transformed files between process steps. SFTP workloads also ran on AWS EC2, and the bank's security team wanted all of that infrastructure retired.

The cost landed on people. Positive pay files arrived several times a day for commercial customers, and staff pulled each batch and re-uploaded it to Q2 by hand. A daily transaction report for a municipal housing agency was generated and encrypted automatically, and then a person sent it to the client the next business day, every business day. The daily encrypted exchange with IntraFi was pulled and decrypted by hand.

The problem was not any one server. The bank wanted core banking file movement on one hosted layer that runs before anyone sits down at a desk, instead of on servers the bank had to build and keep alive.

Too Critical to Break, Too Entrenched to Rebuild

The migration had hard constraints. The core banking system had to be current every day, so nothing could break mid-migration. Vendors and clients had the bank's hostnames, credentials, and host keys wired into their own systems, and they could not be asked to reconfigure. Counterparty connections, IntraFi's among them, had to keep working unchanged, so the bank absorbed every piece of integration work. And each of the roughly 20 transformation jobs had to be rebuilt as a workflow before its server could go anywhere.

Meanwhile the requests kept coming. Every new vendor or client need for file exchange had the same answer: build another in-house SFTP server for the bank to own and keep alive. After the merger set a cloud-first direction, that answer stopped being acceptable.

The hosted layer taking over those workflows had to support scheduled, encrypted, machine-to-machine transfers while allowing external counterparties to change nothing at all. It needed retry logic and failure alerting, PGP inside the workflow rather than at somebody's desk, and access to file shares inside the bank's own network. The bank selected Files.com to be that layer.

One Hosted Layer Between the Vendors, the Clients, and the Core

Files.com became the bank's hosted file-transfer layer between its banking vendors, commercial clients, and internal systems, running under the bank's own branded domain.

The vendor flows ran machine to machine. Files.com connected to vendor SFTP endpoints as remote servers and distributed daily Q2 BAI account extracts automatically into per-client folders. Commercial clients could retrieve their extracts through the method that fit their operations, including scheduled scripts that pulled files straight into their accounting systems. Failed transfers retried automatically and alerted the team if they still did not complete.

Encryption moved inside the workflow. Each afternoon, a Files.com workflow pulled the day's encrypted file from IntraFi, staged it, and decrypted it with GPG automatically. Nobody handled a key or ran a decryption step by hand.

The platform also reached back into the bank. The Files.com Agent, installed on utility servers inside the bank's network, bridged the on-premises file shares that remained the source of record for several flows over an outbound-only connection. On the cloud side, a sync picked up the housing agency's daily report from Azure Files and delivered it to a client folder, with a notification to the client and automatic file expiration behind it.

Built in a Development Folder, Cut Over One Workflow at a Time

The bank's systems engineering team did nearly all of the configuration itself, and it sequenced the migration so that nothing critical was ever at risk. Each workflow was built and tested inside a development folder on Files.com, verified with the counterparty, and moved into production while the legacy infrastructure continued running in parallel. Production and test folder trees remained separate, so a new vendor connection could be built and verified without touching live data. The Q2 extract distribution went live on a Friday and ran clean end to end the following Monday morning.

For the remaining client-facing SFTP connections, the team designed cutovers that counterparties would not have to notice. Existing usernames, password hashes, and host keys were exported for import into Files.com, and the client-facing hostname would move over by DNS so external clients could keep the settings, credentials, and scripts they already had.

Titan SFTP has been decommissioned. The second SFTP server and the AWS instances follow on the same pattern, as the team moves their client connections and transformation jobs over.

What Runs Without a Person Now

With the first workflows in production, the bank replaced a daily routine of manual pulls, re-uploads, and hand-sent deliveries with scheduled, encrypted, machine-to-machine transfer.

• The Titan SFTP server is decommissioned. Vendor traffic that moved to Files.com no longer round-trips through a box on the bank's own network.
• Positive pay runs end to end with nobody touching a file. The batches staff used to pull and re-upload to Q2 several times a day now move on their own.
• The housing agency's daily report is delivered to a client folder and announced by notification automatically, and every delivered file expires after a set period. The person who used to send it every business day is out of the loop.
• The daily IntraFi exchange is pulled, staged, and decrypted without manual handling, removing a manual step from an encrypted daily flow.

A New Default for File Movement

What changed at the bank is the default answer. When a vendor mandates an encrypted daily exchange, when a commercial client wants extracts it can script against, or when an internal system needs a file moved between process steps, the answer is now a workflow on Files.com rather than another server for the bank to build and keep alive. The file movement behind the core banking system runs before anyone sits down at a desk, and it retries and alerts on its own when something on the far end misbehaves.

The migration also demonstrated that retiring aging FTP infrastructure does not require a single, risky, synchronized cutover. The bank moved one workflow at a time and kept the legacy servers running in parallel until each flow was verified. For its remaining client-facing servers, it designed DNS cutovers around existing credentials and host keys so vendors and clients would not have to change their settings.