MANTL Productizes SFTP With Files.com to Onboard Banks Without Engineers

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

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 MANTL 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 MANTL does not control, operated by teams whose capabilities vary as widely as the institutions themselves.

The Only Delivery Mechanism Was an API Bank Staff Couldn’t Use

MANTL 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. For an institution with its own engineering team, that worked. For much of MANTL’s market, it did not.

“Our customers vary in their technical capabilities. Sometimes they have fully built-out IT teams and engineering teams, and sometimes they have Billy, the bank manager’s nephew. We try to meet our customers where they are.”

The cost landed in two places. Dozens of banks needed to pull large files, sometimes 30 GB and more, many times a day, and the files included the daily ACH transfers that fund new accounts. And every credential setup required a MANTL engineer, which meant the pace of onboarding new banks was gated on engineering time. As MANTL 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 MANTL had already been down that road. A prior SFTP implementation had proven buggy and problematic enough that the engineering team wrote its own push function rather than keep fighting 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 MANTL 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: MANTL’s customers wanted encryption, but did not want their files resting outside MANTL’s own Google Cloud environment.

MANTL 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.

“We have one cloud storage bucket per customer, actually two: one for the test environment and one for the production environment.”

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 MANTL-owned buckets, while the files stayed in MANTL’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 more than 20,000 API calls a day, with peaks near 50,000.

“We are heavy users of the API. That is how we set everything up, including the auto-encrypt stuff.”

The last piece was built for the bank firewall teams on the other end. MANTL 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.

Ten Banks a Month, Onboarded Without an Engineer

With Files.com in production as the platform’s SFTP layer, MANTL 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: two users and two outbound connections, production and test kept isolated, provisioned by implementation staff with no engineering ticket. MANTL sustains at least ten new bank onboardings a month.
• All MANTL customer data now moves through Files.com—more than a dozen terabytes 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 MANTL’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 MANTL could build on, and the company launched new product lines that run over the same layer: integrations that move applicant documents from MANTL 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 MANTL used to be the exception path: an engineer provisioning access to a cloud API that half the market could not operate. Today, a bank that signs with MANTL 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 Billy with an SFTP client, pulls extracts, documents, and account-funding ACH files the same standard way.

MANTL 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 MANTL can use for each new file-driven product line.