Radancy Moved 100 Clients Off In-House SFTP and Automated Per-Client Decryption With Files.com

Radancy is the talent acquisition technology company that operated as TMP Worldwide until 2021. Its platform runs recruitment marketing for more than 1,000 enterprise customers worldwide: personalized career sites, programmatic job advertising, candidate relationship management, and hiring events, delivered from New York across operations in the Americas, Europe, and Asia.

Underneath all of it is a feed. A client's HR systems produce job-posting data as XML. Radancy ingests it, personalizes it, publishes it to the client-branded career site it hosts, and syndicates the postings onward to the major job boards. More than 600 corporate career sites are kept current this way. So before Radancy can do any of the work it actually sells, hundreds of corporate clients have to be able to push files to it reliably, every day, and a growing share of those clients require their feeds encrypted.

Running a Transfer Service Was Never the Business

For years, Radancy answered that requirement by operating its own transfer service. It ran local SFTP and FTP implementations and handed out credentials on those servers as the way clients delivered feeds. When clients began demanding PGP-encrypted delivery, Radancy's engineers wrote and maintained custom scripts to decrypt each feed as it arrived, with each client's own keys. Every account was added and removed by hand, through an internal manual process.

The cost of that arrangement scaled with exactly the thing Radancy wanted to grow: its client count. Every new client meant another hand-provisioned account, and every encrypted client meant more key handling inside scripts somebody had to own. Radancy had outgrown its own estate. The team was spending its time operating servers and encryption plumbing that had nothing to do with publishing jobs.

“We used to have an in-house SFTP server, and we had everything custom scripted with decryption and encryption. After a while, the amount of clients we got was just getting to be more of a headache in admin work.”

An Endpoint Hundreds of Clients Depended On

The estate was hard to walk away from because it was not internal. It was a service hundreds of external companies were configured against, each with their own transfer tooling on their side and, for the encrypted feeds, their own keys. Moving the service off it meant moving those counterparties without interrupting the feeds that keep 600+ career sites publishing.

So the replacement had specific work to do. It had to present the SFTP and FTPS endpoints clients already knew how to use. It had to keep each client's data in its own space and decrypt each client's feeds with that client's keys. It had to let Radancy's own systems create and remove accounts through an API instead of a person. And it had to run alongside the legacy servers while clients moved, because a hard cutover across hundreds of external companies was never realistic.

Radancy selected Files.com to carry that client-facing transfer layer.

Per-Client Folders, Automatic Decryption, and Provisioning by API

Files.com became the intake layer between Radancy's corporate clients and its publishing pipelines. Clients push their XML job feeds into Files.com over SFTP or FTPS, each into their own folder. When a feed arrives encrypted, Files.com decrypts it on landing using the GPG key pair configured on that folder. Keys are set per client, per folder, and the model stretches as far as a client needs: one client runs separate test and production keys against a single Files.com endpoint. Radancy's pipelines then pull the decrypted feeds and reprocess them into the career sites it hosts and out to the job boards.

That per-folder decryption is what retired the scripts. Encryption handling was the part of the old service Radancy had built entirely by hand, and once Files.com performed it automatically on arrival, the custom scripting had nothing left to do.

“We don't have to have a script coming in decrypting all that stuff.”

Provisioning moved to the Files.com REST API. Creating or removing a client account is now a step inside Radancy's own onboarding process rather than a task performed by hand on a server.

One Hundred Clients in Two Months

The migration off the legacy servers ran as a wave, not a cutover. In a two-month window, Radancy moved roughly 100 clients from its in-house SFTP server onto Files.com. The old server stayed online in parallel to avoid interrupting feeds and remains in place for a small number of clients, while every new client is onboarded directly to Files.com. The bulk of the client base has moved over.

Feeds for 600+ Career Sites, and No Scripts to Maintain

With Files.com carrying the client-facing service, Radancy replaced a self-operated server estate and its custom encryption scripting with a repeatable intake pattern:

• The decryption scripting is retired. Encrypted feeds decrypt automatically on arrival with each client's own key, and nobody at Radancy maintains PGP scripts.
• Account lifecycle is an API call. Radancy's internal onboarding process creates and removes client credentials itself, so provisioning no longer grows with the client roster.
• Job feeds for more than 600 corporate career sites now land on Files.com.
• New clients onboard straight to Files.com, and Radancy adds client accounts month after month without adding corresponding administrative work.

The compounding result is the one Radancy was after. Taking on the next client, including one that mandates encrypted delivery, is a folder with the client's key and a credential provisioned over the API. Growth in clients stopped meaning corresponding growth in transfer administration.

More Time for the Platform Radancy Sells

With Files.com carrying the bulk of the client-facing service, the people who used to run servers spend their time on the platform Radancy actually sells.