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

Orrstown Bank is a community and commercial bank with $5.5 billion in assets and banking offices across Pennsylvania and Maryland. A 2024 merger of equals made its parent one of the largest independent community banks headquartered in the region, supporting business lending, treasury management, and fraud protection tools for commercial clients.

That operation runs on files. Around five 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. Orrstown sat in the middle of all of it, carrying that traffic on a patchwork of self-hosted infrastructure it could not safely change and through manual steps that depended on specific people being at their desks every day.

Aging Servers and a Person Emailing the Daily File

An on-premises Titan SFTP server sat on a legacy network segment. A second SFTP server ran an obsolete version of Red Hat Enterprise Linux and executed roughly 20 cron jobs that transformed files between process steps. It had been built by an engineer three staff turnovers ago, with no documentation, so nobody could safely change it because nobody knew everything it did. SFTP workloads also ran on AWS EC2, and the bank's security team wanted 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 emailed it the next business day, every business day. The daily encrypted exchange with IntraFi was handled manually, and it was error-prone.

The problem was not any one server. Orrstown was running core banking file movement on infrastructure it could not safely change, through manual steps that depended on specific people being at their desks every day.

Too Critical to Break, Too Entrenched to Rebuild

The estate survived that long because it could not safely be touched. 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. Counterparties like IntraFi would change nothing on their side, so the bank had to absorb every piece of integration work. And before the undocumented Linux server could go anywhere, the team first had to reverse-engineer what its cron jobs actually did.

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

“We don't want to be in the business of hosting SFTP servers. We don't have to.”

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. Orrstown selected Files.com to be that layer.

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

Files.com became Orrstown'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 Windows utility servers inside Orrstown'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.

At publication, Titan SFTP had been decommissioned. The obsolete Red Hat server and AWS SFTP instances remained in the estate while the team prepared their client connections and transformation jobs for migration.

What Runs Without a Person Now

With the first workflows in production, Orrstown replaced a daily routine of manual pulls, re-uploads, and hand-sent emails 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 14 days. The person who used to email it every business day is out of the loop.
• The daily IntraFi exchange is pulled, staged, and decrypted without manual handling, removing an error-prone step from an encrypted daily flow.

A New Default for File Movement

What changed at Orrstown 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. Orrstown 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.