An Account-Opening Software Provider Productizes SFTP With Files.com to Onboard Banks Without Engineers

An account-opening software provider builds software for community banks and credit unions. A bank’s customers apply through the provider’s white-labeled software, submit identity and corporate documents, and fund their new accounts, while the platform automates the KYC decisioning behind it all. The provider’s distinguishing move was to sit on top of the legacy core systems those institutions already ran rather than replace them.

That proposition, embedding into whatever infrastructure a bank already has, is what put a file-delivery problem at the center of the business. Every account the platform opens produces data the bank needs back: extracts and reports, applicant documents like driver’s licenses and articles of incorporation, and the ACH files that put money into newly opened accounts. All of it has to land in systems the provider does not control, operated by teams whose tooling varies as widely as the institutions themselves.

Delivery Over a Cloud API Gated Every Onboarding on an Engineer

The provider staged all of its customer data in Google Cloud Storage, and the delivery mechanism it offered banks was direct access to the Google Cloud Storage API. That suited banks with their own engineering teams. The company wanted a delivery path that every institution’s existing tooling already speaks, which meant standard SFTP.

The cost landed in two places. Dozens of banks needed to pull large files many times a day, and the files included the daily ACH transfers that fund new accounts. And every credential setup required one of the provider’s own engineers, which meant the pace of onboarding new banks was gated on engineering time. As the company added banks, an engineer-in-the-loop delivery path could not scale with the business.

Building the fix in-house was the obvious answer, and the provider weighed it. Standing up and operating a multi-tenant SFTP service for what would become hundreds of bank counterparties, with per-tenant keys and per-tenant isolation, was infrastructure the product team did not want to own.

SFTP as a Product Feature, With the Data Staying Put

What the company wanted was an SFTP server as a service: a feature of its own product it could switch on for every bank. The requirements described the gap precisely. Standard SFTP that any bank-side client can use. Multi-tenancy across dozens, eventually hundreds, of institutions. Strict isolation between each bank’s production and test environments. GPG encryption with a separate key per customer. Provisioning simple enough that implementation staff, not engineers, hand a new bank working credentials. And a hard residency constraint: the provider’s customers wanted encryption, but did not want their files resting outside the provider’s own Google Cloud environment.

The provider selected Files.com to be that layer, running in front of the Google Cloud Storage buckets it already operated.

One Bucket per Bank, Mounted Into Files.com

The architecture was multi-tenant from day one. Each bank received two Google Cloud Storage buckets, one for production and one for a test environment, kept strictly separate.

Files.com presented those buckets over ordinary SFTP, with a separate GPG key for each bank. Files.com held only encrypted customer data sourced from the provider’s own buckets, while the files stayed in the provider’s cloud.

Provisioning was scripted against the Files.com API from the beginning: creating remote servers, adding mounts, creating users, distributing SFTP credentials, and scheduling daily transfers, all without touching a GUI, explicitly to avoid human error at dozens-of-clients scale. That pipeline now drives tens of thousands of API calls a day.

The last piece was built for the bank firewall teams on the other end. The company configured the SFTP endpoint on its own branded domain with two dedicated IP addresses, so a bank’s network team could whitelist two addresses instead of a list of 70 and more.

New Banks Every Month, Onboarded Without an Engineer

With Files.com in production as the platform’s SFTP layer, the provider replaced an engineer-gated delivery mechanism with a product feature its implementation team switches on for every new bank.

• Onboarding a new institution is a scripted run: users and outbound connections for production and test, kept isolated, provisioned by implementation staff with no engineering ticket. The company sustains a steady stream of new bank onboardings every month.
• All of the provider’s customer data now moves through Files.com—terabytes of data a month—including large recurring pulls and the daily ACH files that fund newly opened accounts.
• Every bank gets GPG-encrypted delivery while its files never rest outside the provider’s Google Cloud environment.

The File Layer Became Reusable Product Infrastructure

The compounding result is larger than any of those. Once per-tenant SFTP existed as a feature, it became a pattern the provider could build on, and the company launched new product lines that run over the same layer: integrations that move applicant documents from the platform into the document-management and anti-money-laundering systems its banks operate, Hyland OnBase and Jack Henry Synergy among them. That work had previously been manual and handled one integration at a time. Now it is the same repeatable path every other file takes.

File delivery at the company used to be the exception path: an engineer provisioning access to a cloud API, one bank at a time. Today, a bank that signs with the provider gets a working SFTP endpoint when an implementation manager runs the provisioning script, and whoever handles files at that institution, whether a full IT department or one employee with an SFTP client, pulls extracts, documents, and account-funding ACH files the same standard way.

The provider ships enterprise file transfer as a native feature of its own product, built on Files.com, without operating an SFTP server and without its customers’ data ever resting outside its own cloud. The result is not only a delivery mechanism but a repeatable foundation the company can use for each new file-driven product line.