A Global Travel Management Company Meets Every Client Security Regime on One Files.com Site

A global corporate travel management company runs the travel programmes of large enterprises across dozens of countries.

A travel management company runs other enterprises' travel programmes. That meant the company's operation ran on other enterprises' data. The authoritative list of who could book travel for any client was not the company's list. It lived in the client's own HR system, and the client pushed it to the company. Before the company could book a single trip, that client's employee data had to cross the boundary between two companies, on terms the client's security team set.

The company consolidated hundreds of these client-specific security regimes onto one Files.com site, where each client's rules became per-relationship configuration. Today, client folders receive and clear files every day without manual handling. Automated traffic grew many times over, while day-to-day administration remains with one global support analyst.

The File That Decides Whether a Client's Travelers Can Book

The file at the center of the challenge was the HR feed: a client's current list of its travelers, exported from Workday, SuccessFactors, or whatever HR system the client ran, and pushed to the company weekly or more often. People joined and left constantly, so the list had to stay current. The company's systems collected each feed, loaded the traveler profiles into the booking platform, and cleared the file. If a client's feed did not land and process, that client's travelers could not book travel.

This was the standing condition of the business, not an edge case. Client folders across the company's exchange each received at least one file every day. The same pipeline carried client invoices, custom reporting data, project codes, and approver attributes. The dependency was severe enough that the company treated even a couple of hours of disruption as a major outage.

Hundreds of Clients, Each With Its Own Security Regime

The company's counterparties were not typical file-exchange partners. The roster included energy majors, global law firms, national research laboratories, universities, and some of the world's biggest consumer brands, and each one arrived with a security team that dictated the terms on which its employee data could move. One client's governance body refused to sign off on the integration at all unless connections carried certificate-based dual authentication and firewall-level IP filtering, so that no other party could ever connect and drop a file. A large financial-services client required write-only accounts with credentials segregated and tracked on both sides. Others mandated specific ciphers or key types, dedicated IP addresses, or PGP encryption on every file they sent.

The company could not negotiate these requirements away. The data belonged to the client, and the client's regime governed. The company had to satisfy every regime individually, on one shared estate, with no client ever able to see another's data, and with the whole pipeline running unattended every day.

For years the exchange grew the way global operations usually grow: region by region, arrangement by arrangement, with separate SFTP setups serving separate teams and clients. Each new security requirement was answered with another one-off build. The company's teams knew what they actually wanted, and it was the opposite of running more servers: a cloud-hosted endpoint where a client or supplier could drop files into a folder and the back-office application could pick them up, with the patching, uptime, and network underneath handled by somebody else. As the client roster grew into the hundreds, per-client infrastructure stopped being survivable. Every enterprise deal carried a security review, and every new requirement risked another bespoke integration.

The fix had to express every client's regime as configuration on one platform: a single endpoint under the company's own name, a hard boundary per counterparty, authentication and network controls set per account, encryption set per folder, an audit trail strong enough to put in front of a client's reviewers, and storage segmented by region for a global operation.

Files.com gave the company that layer, and the consolidation ran region by region. One regional operation was on the platform first, the meetings-and-events team folded its workloads into the same account, and offshore client processing was cut over from its prior SFTP location.

One Branded Endpoint, Configured Per Relationship

Every client and supplier now gets a dedicated, scoped account and folder on the company's Files.com site, reached through the company's own branded domain over whichever protocol the counterparty already speaks: SFTP, FTPS, HTTPS, or AS2. Each relationship's security regime is applied to that account as settings rather than built as infrastructure. Authentication is a password, an SSH key, or a client certificate where a security team demands dual authentication. Per-user IP whitelisting restricts where a connection may originate. Write-only permissions let an external party drop files without seeing anything else on the site, while the internal folder owner keeps full control. Per-folder GPG handles the clients who will only send encrypted files. And when one client's firewall team needed to filter the company's traffic at the network level, dedicated Files.com IP addresses cut that team's whitelist from dozens of addresses to a fixed few.

Onboarding a new counterparty became a repeatable sequence instead of a bespoke project. The company creates the scoped user and folder, then applies the protocol, authentication, network, and permission settings that relationship requires.

Feeds That Land, Load, and Clear on Their Own

Downstream, the pipeline runs itself. Files.com webhooks or the company's scheduled SFTP and REST API collection prompt its business application to retrieve each feed, load the traveler profiles into the booking platform, and delete or archive the processed file. The same drop-and-process pattern handles client invoices and custom reporting data. Storage is segmented across multiple Files.com regions to serve a client base spread across the world.

Steep Traffic Growth on the Same Site

With the estate consolidated on Files.com, the exchange that decides whether a client's travelers can book at all now runs as one governed operation rather than a set of regional arrangements.

• Enterprise security reviews are answered from standing controls. The company satisfied reviews from law firms, energy companies, and public institutions using Files.com's SOC 2 attestation, AES-256 encryption at rest, TLS in transit, audit logging, and per-folder GPG, instead of building custom infrastructure per client.
• Client folders each receive and clear a file every day with nobody touching them, and automated traffic grew many times over, absorbed without the operation changing shape.
• Day-to-day administration of the whole estate sits with a single global support analyst, who acts as the group's own third-line support for the platform.

Every Client's Rules, One Files.com Site

The company never had to standardize its clients. Their differing controls live as configuration on one Files.com site, with no client able to see another. The question that used to hang over every enterprise deal, whether the company could stand up an integration this client's security team would sign off on, is now answered before it is asked, from controls already running. Files.com did not remove the security regimes the company's clients impose. It made them cheap to meet, and for a business that wins by running the travel programmes of the world's most demanding organizations, that turns the client security review from an obstacle into a step.