An Australian Lender Runs Bank and Vendor Transfers Through One Files.com Gateway Instead of 60-Plus Scripts

An Australian non-bank lender writes auto and equipment finance and runs the lending behind it: origination at the dealership, credit, servicing, and collections.

That position puts the lender between the banks that fund it and everyone else, and a business in the middle runs on files crossing its boundary. Payment and acknowledgement files pass between it and its banking partners. Credit files go to a bureau. Reports flow to the payroll and finance vendors its operations depend on. Every one of those transfers carries financial records or customer data, and every one is expected to be encrypted, on time, and on the record.

In 2025, the lender set a requirement for all of them: every transfer crossing the boundary goes through one governed gateway, with one activity record.

Files.com gave the lender one governed gateway and let it build a major bank programme as automations instead of more than 60 planned scripts.

File Transfer Had Grown One Tool at a Time

The lender's file transfer had grown with the business, one tool at a time. An SFTP server running VanDyke still carried work it had been given when the company was small. A second SFTP server sat in the Azure DMZ, and different teams used Azure's built-in SFTP as they needed it. PowerShell scripts pulled data out of databases, PGP-encrypted them, and pushed the files to partner endpoints. Business users moved files with FileZilla. For a lender aligning to NIST and Australia's Essential Eight, each of those was another path to govern, and the team wanted one.

Company policy keeps Azure storage accounts off the public internet, so every transfer that needed an externally reachable endpoint meant a separate approval and its own paperwork. The team wanted one boundary to maintain instead. It also wanted the next bank or vendor connection to be configuration rather than bespoke work: a script, a credential, a key exchange, and a schedule, all built by hand, every time.

Too Complex to Script, and No Appetite for Another On-Prem Platform

Any replacement had to go in without interrupting anything: the servers and scripts carried live bank and partner traffic on schedules the counterparties controlled. And the programme directly ahead made the old approach impossible to extend: dozens of encrypted workflows with one of its major banking partners, spread across more than a dozen SFTP credentials and moving dozens of payment, acknowledgement, and report files a day.

The company's senior cloud engineer tested the scripting route and estimated more than 60 PowerShell scripts just to manage that one bank exchange. The idea was rejected as unmanageable.

So the replacement had a clear specification. It had to be one controlled point through which everything crossing the boundary passes. It had to handle per-partner PGP encryption and key exchange without scripts. It had to keep data in Australia, fit a policy that keeps storage on private endpoints, and give business users a way to send files that never involves an SFTP client. And it had to be SaaS.

The lender selected Files.com to be that gateway.

A Folder Tree per Vendor, Keys on the Platform, and No Scripts

The rollout ran in parallel: the legacy scripts kept carrying traffic while their replacements were built on Files.com alongside them, so no bank schedule was ever interrupted. The lender put the platform on its own branded domain, connected single sign-on through Microsoft Entra ID, set Australian data residency, and separated production from non-production paths for every vendor.

On top of that sat a folder tree per vendor and service. Banks and vendors could push and pull over SFTP on their own schedules, while GPG encryption and decryption was applied at the parent-folder level. A file dropped into a bank's outbound folder was encrypted with that bank's key automatically, and inbound encrypted files were decrypted on arrival. The bank programme assessed at 60-plus scripts ran instead as Files.com Automations, defined as rules rather than code.

Files.com also gave business users a route that did not require an SFTP client. For one finance workflow, Files.com connected the company's SharePoint libraries and Azure Blob Storage so a file dropped into SharePoint flowed into Blob storage for the downstream application, and the return file appeared back in SharePoint with no user interaction.

The same design resolved the storage-exception problem. Because Files.com held the one externally reachable connection, every Azure storage account behind it stayed on private endpoints. There was one boundary to maintain instead of a risk acceptance per account. The lender then made the boundary a rule.

Every Transfer Through the Gateway on the Record

With Files.com in production, the lender has a single, visible boundary for the workflows it has moved.

• Every transfer through the gateway has a full activity record, so an auditor's question about any file has an answer on the platform.
• The banking programme runs without the 60-plus scripts it was assessed to need. Dozens of encrypted workflows run as automations the team maintains as configuration.
• Storage stays private. One maintained external connection replaced per-account public-access exceptions that each cost one to two hours of paperwork.
• Onboarding a partner stopped being a deterrent. More than a dozen vendors are mapped across production and non-production, and adding one means a folder tree, a permission set, and a key exchange rather than a new script.

External Data Movement Is Now Policy

File movement at the lender used to run on whichever tool a team had: a script, a desktop SFTP client, a server of its own. Now, Files.com is the mandated boundary and gives the team a repeatable pattern for bringing partner workflows onto the gateway.

For a business built on adding finance partners, the next bank or vendor is no longer a scripting project. It is a folder on the gateway.