A Global Nonprofit Automates Daily Bank File Delivery on Files.com Without Running an SFTP Server

A global human-rights nonprofit protects vulnerable people from violence, working alongside local justice systems through field offices worldwide.

That fieldwork runs on a back office. The money behind the nonprofit’s work moves through ordinary financial rails: banks, card networks, and finance systems spanning its headquarters and field offices on several continents. The institutions on the other end of those rails deliver their records as files, and they deliver them on their own terms.

When the Counterparty Dictates the Connection

A financial institution does not adapt to its recipient. When the nonprofit needed to receive finance and payment files from a major card network and a daily bank feed, each counterparty arrived with its own requirements. The card network required specific host key and fingerprint exchange and specific RSA key lengths; the bank delivered its feed every business day. Until the organization could present an endpoint that satisfied those terms, the feeds could not start, and the finance work that depended on them could not be automated.

The nonprofit had no managed file transfer platform, and its operations-technology team was small. The gap was structural: enterprise financial counterparties on one side, a lean nonprofit IT team on the other, and no infrastructure between them built for the job.

The Alternative Was Operating a Server Indefinitely

The nonprofit’s cyber security leadership set the bar for any exchange with an outside party: SFTP only, no FTP; payloads encrypted or masked; authentication by SSH keypair or username and password; and a unique account for every counterparty, so that each one’s activity logged separately and access reviews stayed clean.

The obvious way to meet that bar was to build. The team knew it could stand up its own SFTP server in the cloud and run it. But a payment feed does not tolerate gaps, so that server would need patching, key management, monitoring, and uptime every business day, indefinitely, with the security bar maintained by hand the whole time. For a team whose job was integration, not infrastructure, the ongoing operation was the real cost.

The nonprofit chose Files.com as that endpoint instead: a managed SFTP platform that met the security requirements as configuration, with nothing for the team to host.

One Account per Counterparty, One Pipeline Behind Them

Each outside party got its own Files.com SFTP account, credentialed by keypair or password as the counterparty required, so every connection carried its own identity in the logs. The team also confirmed connectivity with the card network.

Behind the exchange point, the nonprofit’s integration platform, Dell Boomi, did the internal work. On a schedule each morning, Boomi retrieved inbound files from dedicated finance folders on Files.com and moved each file into an archive folder after collection. The same pipeline carried QuickBooks transaction files and P&L statements across the organization, including finance data from an overseas field office. Files.com folder permissions scoped Boomi’s credentials to the finance directories and nothing else, while the small set of human accounts signed in through the organization’s Azure AD using SAML single sign-on.

Years of a File Arriving Every Business Day

With Files.com as the exchange point, meeting a financial counterparty’s requirements stopped being an infrastructure project and became an onboarding exercise.

• A bank file arrived every business day for years, collected and archived by the pipeline with no one touching it.
• Onboarding the next counterparty is an account, a credential, and a folder, with the security bar enforced by configuration rather than by a checklist someone has to remember.
• Administrator accounts run file exchange for an organization of more than a thousand people, with no server of their own to patch, monitor, or keep alive.

The per-counterparty accounts also delivered the audit posture the security team asked for from the start: every external party’s activity logged under its own identity, so reviewing who delivered what, and when, is a matter of reading the log.

Finance Infrastructure Nobody Has to Run

Today, the nonprofit can meet banks’ and card networks’ connection requirements without owning any transfer infrastructure. The team that would have spent its time keeping an SFTP server patched and reachable spends it on integrations instead, and the feed supporting its finance work arrives every business day into a pipeline that files it away.

That is the lesson a team in the same position can take away: an IT team met financial-counterparty file exchange requirements without ever becoming server operators. Files.com holds the endpoint to the security bar; the nonprofit’s people only have to decide what happens to the files once they land.