ABOC Shifted ACH Intake From Axway SecureTransport Before a Datacenter Move—So Clients Reconfigured Once

Amalgamated Bank of Chicago, now branded ABOC, was founded in 1922 by the Amalgamated Clothing Workers Union, and a century later it remains one of only a handful of U.S. banks dedicated to the labor community. More than 200 labor unions bank there, alongside benefit funds, governmental units, and commercial clients. Its treasury operation gives those clients ACH origination, positive pay, and lockbox services, and its trust team manages over $2 billion in institutional investments.

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.

Fifteen Years on a Platform Clients Had to Call for Passwords

Jared Lauer, the business technical support analyst who ran the platform, needed three words for it: "Secure Transport stinks." The verdict was earned in specifics.

SecureTransport gave clients no self-service. A client who lost a password called the bank. Client services reset it and emailed the new password back in plain text, every time, to organizations sending the bank money-movement files. The line of business named it as its worst pain point.

Stronger authentication existed on paper and not in practice. Certificate-based authentication was configured but hard to manage, and the bank could never get key-based SFTP working at all:

“We couldn't get SSH keys to work on Secure Transport.”

The bank's network infrastructure team raised a third problem: a mission-critical money-movement intake with no disaster-recovery story. And underneath all of it sat the structural one. 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.

One Chance to Move Roughly 170 Clients

That structural problem stopped being theoretical 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 fix authentication: self-service password resets, key-based SFTP that actually works, 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.

ABOC 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 Windows 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 finally matches what a bank owes its clients. 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.

“Secure Transport was very granular, but very confusing. Yours tends to be the easiest one to handle.”

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, ABOC replaced a front door that generated support calls with one clients use without help.

• Plain-text password emails are gone. Clients reset their own passwords, and client services no longer fields the calls.
• Key-based SFTP works for the first time in the platform's history, and when the bank offers keys at onboarding, some clients volunteer a preference for them.
• A client's upload is confirmed in about a minute. The bank verified a file uploaded at 1:02 producing a client notification at 1:03, 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.
• Silent failures surface. Under the old setup, a vendor once went eighteen days without picking up files the bank had staged, and nobody knew. Files.com Expectations now watch the bank's recurring flows and flag a delivery window that closes empty.
• Client connections no longer terminate on hardware in the bank's buildings, which was the disaster-recovery exposure the network team raised at the outset.

“You just log in, you drop a file, it goes.”

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 ABOC. For fifteen years, external organizations were wired directly to servers in the bank's own buildings, so the bank's plumbing was every client's problem. 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.