A Commercial Bank Moved ACH Intake From Axway SecureTransport to Files.com So Clients Reconfigured Once

A US commercial bank runs a treasury operation that gives its business and institutional clients ACH origination, positive pay, and lockbox services.

Treasury banking runs on files. A client originating ACH payments sends the bank a payment file. A client using positive pay sends the file that says which checks are legitimate. Those files move money, and they have to land inside same-day processing windows. For more than fifteen years, the front door they landed at was Axway SecureTransport, running on the bank's own servers in two locations.

A Front Door Clients Configure Once

SecureTransport gave clients no self-service. A client who lost a password called the bank, and client services reset it. The bank wanted clients resetting their own passwords, with key-based SFTP and MFA as the standard for organizations sending it money-movement files.

Underneath that sat the structural requirement. Client and vendor accounts connected directly to the bank's own servers, which made the bank's infrastructure part of every client's configuration. Any change to those servers, or their addresses, reached every external organization connected to them. The bank wanted a client-facing endpoint that stays put while everything behind it can move.

One Chance to Move Every Client

That requirement became urgent when the bank committed to a datacenter co-location build and a physical building move. The servers clients connected to were going to change, and with them the addresses those clients had built into their own systems. IT leadership set the scope plainly: get off SecureTransport. The team running the migration set the bar: each client would be contacted and reconfigured exactly once.

Files.com would become the stable client-facing endpoint. Once a client moved, the bank could change servers, IP addresses, or buildings behind it without asking that client to reconfigure again.

The replacement had a demanding specification. It had to give clients the same two paths in, web portal and SFTP, under the bank's own name. It had to provide self-service password resets, key-based SFTP, and MFA. It had to confine each client to their own directory. It had to deliver every inbound file onto the bank's internal file server exactly the way the old path did, because nothing downstream could change: an in-house application picks ACH files up from that file server and reformats them for the core, and deposit services performs its own out-of-band confirmation of each file before funds are released, a manual control the bank keeps deliberately. And it had to absorb the accounts gradually, because ACH files that miss a same-day window are not an inconvenience. They are a failure of the bank's product.

The bank selected Files.com to be that front door.

Files.com in Front, the Agent Bridging Into the Bank

The bank built a client-facing exchange layer on Files.com that external organizations connect to, with the bank's own infrastructure sitting entirely behind it.

Clients upload ACH and positive-pay files to a branded portal and SFTP endpoint on the bank's own domain, with dedicated IPs and the bank's own look. Each client lands in a per-user folder, and user-root isolation means a client sees only their own directory whether they arrive by browser or by SFTP client.

Using Files.com Automations, each upload is renamed to prepend the client's user ID, the convention downstream processing depends on to match an ACH file to its transmittal. The Files.com Agent, installed on a dedicated VM, moves the file into the landing zone on the internal file server, where the reformatting application and deposit services take over untouched. The client receives an email confirming receipt.

Authentication runs the way the bank specified. SSH key authentication works over SFTP. Password users reset their own passwords. MFA runs on Microsoft Authenticator, Duo, and YubiKey hardware keys, with IP allow-listing available as an alternate control for SFTP users, and internal staff sign in through the bank's Microsoft Entra ID SSO.

A Parallel Run From Five Pilot Clients to the ACH Base

Files.com ran alongside SecureTransport for the entire migration, and customers moved before vendors, on plain reasoning: the bank can coordinate its clients, while vendors migrate on schedules the bank does not control.

After internal and line-of-business testing, the bank moved to a five-client ACH positive-pay pilot and then batch onboarding of the remaining ACH clients. Batching was possible because most of the base runs the same standard ACH workflow. Vendors followed, pulling internally staged files down from Files.com. The site is fully live in production, with most customers migrated off SecureTransport and the remaining client and vendor migrations continuing on their own schedules.

Ten Minutes to Onboard a Client, One Minute to Confirm a File

With the Files.com workflow in production, the bank replaced a front door that generated support calls with one clients use without help.

• Clients reset their own passwords, and client services no longer fields password calls.
• Key-based SFTP is offered at onboarding, and some clients volunteer a preference for it.
• A client's upload is confirmed in about a minute, comfortable margin inside same-day ACH windows.
• Onboarding a new client is a ten-minute template run. New secure-transfer clients go straight onto Files.com.
• Files.com Expectations watch the bank's recurring flows and flag a delivery window that closes empty, so a vendor that stops picking up staged files surfaces as soon as its window closes.
• Client connections terminate at Files.com rather than on hardware in the bank's buildings.

A Datacenter Move No Client Noticed

For the clients already migrated, the payoff the whole design pointed at arrived when the bank completed its datacenter move. The Agent's VM was restored into the new facility with a new internal address and a new outbound public IP. On SecureTransport, that change would have meant contacting every client and reworking every allow list pointed at the bank. Because every client connection now terminates at Files.com, not one client was asked to change anything, and not one noticed. They kept dropping files at the same address.

That is what fundamentally changed at the bank. For fifteen years, external organizations were wired directly to servers in the bank's own buildings, so any change to the bank's plumbing reached every client. Now the address migrated clients use belongs to Files.com, and everything behind it, the Agent, the file server, the deposit-services controls, the buildings themselves, is the bank's to rearrange without a single client call. The bank impacted each migrated client once, moving them onto Files.com. It has not had to impact them since.