A Cross-Border Payments Company Replaces Hand-Managed SFTP Accounts With an API-Provisioned Reporting Hierarchy on Files.com

A global cross-border payments company moves billions in transaction volume a year and holds regulatory licences in dozens of countries. Its travel business issues single-use virtual cards that online travel agencies use to pay airlines and hotels behind the scenes of every booking.

A virtual card is only half the product. The other half is accounting for it. The company generates daily activity and funds-flow reports for every travel client, with heavier files at month end, and its clients depend on those files to reconcile the money moving through their bookings. The audience for those reports is not flat. Some clients are global distribution systems: providers whose software online travel agencies book through, and who organize those agencies by country, with a country manager responsible for all of them. A single reporting relationship can mean one travel agency, or a whole country's worth of clients under one manager.

To replace hand-managed, flat SFTP accounts, the company built one API-provisioned Files.com folder hierarchy that mirrors those relationships and controls who can see each report.

Every New Client Meant Another Hand-Managed Account

The company delivered those reports through a hosted SFTP service, and that service made every relationship a manual one. Onboarding a client meant creating a user account by hand and managing its authentication by hand, so the team's administrative work grew with every client signed.

Flat SFTP accounts also could not express how the client base was actually organized. Reports are generated per client, but an aggregator's country manager needs the reports of every client beneath them. On a flat account model, that roll-up view meant bespoke access work for every aggregator relationship.

The company could not solve this by giving each client its own deployment, either. Its own service is multi-tenant: systems and data storage are shared between tenants, so any model that required a contract or an instance per tenant was unworkable. And as a payments business, whatever hosted the reports had to be PCI compliant.

So the replacement had a clear specification. It had to express tiered access in its structure rather than in per-client work. It had to be provisioned by code as clients onboard, run under the company's own domain and branding, serve both machines ingesting files and people downloading them, and sit inside PCI-compliant hosting, all from one multi-tenant site. The company selected Files.com to be that client-facing reporting layer.

One Folder Tree That Matches How the Travel Industry Is Organized

Files.com became the governed reporting portal between the company's platform and its travel clients, and the core of it is a folder tree whose structure is the access model. For each aggregator, the company built a country folder containing a folder per client. Granting a country manager permission at the country folder reaches every client folder beneath it, so the roll-up view that used to mean bespoke work is now a property of the tree.

Everything around the tree is programmatic. The company's in-house Python ETL generates the reports on its own server and pushes them to Files.com over a WebDAV mount. When a new client onboards, the company's code calls the Files.com API to create the folder and the users. No one builds an account by hand.

Clients collect their reports in whichever of two ways fits them. Systems integrate directly against Files.com over SFTP or the API and ingest reports into their own databases. People sign in to the branded web portal on the company's own domain and download. Both paths land on the same folder tree and the same permissions.

The company governs internal users through Okta single sign-on, while external client users stay on local Files.com accounts governed by platform policy, including two-factor authentication, IP restrictions, and enforced password expiration. The company also pulls Files.com usage analytics to verify how often each report type is collected. Whether a client ever picked up a file is a lookup, not a guess.

Onboarding a Client Is an API Call

With Files.com as the reporting layer, the company replaced per-client account administration with a structure that applies itself. New agencies and aggregators enter the same access model without hand-built accounts or bespoke authentication work, while Files.com enforces the password, two-factor, and IP policies the company requires.

The arrangement also holds up under a regulated payments company's formal governance. Files.com has passed the company's annual Vendor Risk Assessment and the associated data protection impact assessment, was carried through its global critical-vendor assessment, and satisfied the DORA ICT third-party requirements.

A Decade of Daily Reports on One Structure

The company's client reporting has now run on Files.com for a decade, through corporate change, an internal identity migration, and the annual vendor scrutiny of a regulated payments company. Through all of it, the daily and month-end reports keep landing in the same tree, and nobody on the company's team creates a client account by hand.

That is the portable lesson in the company's setup. A tiered partner network of aggregators, regional managers, and end clients does not have to be administered as a pile of individually managed SFTP accounts. On Files.com, the company expressed the whole hierarchy as one governed folder tree, let the API do the provisioning, and let the structure do the access control.