Nium Replaces Hand-Managed SFTP Accounts With an API-Provisioned Reporting Hierarchy on Files.com

Nium is a global cross-border payments company. It moves more than $60 billion in transaction volume a year, supports payouts to more than 190 countries, and holds regulatory licences and authorisations in more than 40 of them. Its travel business began as Ixaris, the Malta company that introduced Europe's first virtual prepaid card in 2003. Today that 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. Nium 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, Nium 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

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

Nium 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 Nium'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. Nium 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 Nium's platform and its travel clients, and the core of it is a folder tree whose structure is the access model. For each aggregator, Nium 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.

“There's a country folder and in that folder there are different folders for the clients, and then we can give access to the country manager to access the reports of all the clients.”

Everything around the tree is programmatic. Nium's in-house Python ETL generates the reports on its own server and pushes them to Files.com over a WebDAV mount, including month-end files that run above 500 MB. When a new client onboards, Nium'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 Nium's own domain and download. Both paths land on the same folder tree and the same permissions.

Nium 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. Nium 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, Nium 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 Nium requires.

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

A Decade of Daily Reports on One Structure

Nium's client reporting has now run on Files.com for a decade, through a rebrand, an acquisition, 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 Nium's team creates a client account by hand.

That is the portable lesson in Nium'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, Nium expressed the whole hierarchy as one governed folder tree, let the API do the provisioning, and let the structure do the access control.