A Scrap Metal Broker Moved Steel Mill EDI From Its FTP Server to Files.com—Without Rebuilding the Exchange

A North American scrap metal broker is a wholly owned subsidiary of a steelmaker, which it supplies with ferrous scrap. Scrap is the steelmaker's largest single cost, and the broker is how it owns that supply chain directly: a national network of recycling facilities feeding raw material into the parent's steel mills.

Alongside the material flows the paperwork. Contracts, shipment records, and invoices move every day between the broker's systems and the systems at the mills, because every truck of scrap that arrives at a mill has data that has to arrive with it. That exchange runs as files: the broker's software writes them, the mills' systems collect them and send their own files back, machine to machine, on schedule, across multiple mill sites. Whatever carries those files is carrying a piece of a steel supply chain.

The FTP Server That Carried It Was a Headache to Own

For years, what carried them was the broker's own self-hosted FTP server. Running it fell to the broker's software engineering team, whose actual job is the supply-chain systems on either side of the exchange, not file-transfer infrastructure.

The burden mattered because the exchange behind it is not optional. Without an automated channel, moving contracts and shipment data to the mills means doing it by hand: noticing something has stopped, working out what has and has not been sent, recreating the files, and getting them to the mills so trucks and shipments can be processed. That is the manual reality the channel holds at bay every day.

The obvious modern answer, converting everything to direct API integrations, only went so far. The broker did convert some mill exchanges to APIs over the years, but for some exchanges that does not always make sense. The scheduled, bidirectional file pattern had to survive. What the broker needed was a platform that kept that pattern intact: one that spoke the protocols its applications and the mills' systems already used, ran the exchanges automatically, and took the infrastructure itself off the broker's hands.

The broker selected Files.com to be that platform, and decommissioned its internal FTP servers.

A Daily File Dump the Mills Collect

The mill exchange now runs on a Files.com site, in the same shape it always had.

The broker's engineering team built the surrounding machinery in-house on the platform. Files.com Automations and inbound syncs move the files feeding the mills. The broker's .NET applications upload directly to folder paths through the Files.com API, preserving the same application-driven drop-and-pickup work the old FTP server used to host. Mills and outside counterparties connect over SFTP, FTP, and FTPS, while the folder structure keeps brokerage, consumer, and mill flows apart.

No FTP Servers Left, and No Manual Handling

With the exchange in production on Files.com, the broker replaced infrastructure it had to operate with a platform it builds on.

• The broker no longer operates any FTP servers of its own for these flows. That headache is gone entirely, not consolidated or reduced.
• Automation keeps manual file handling out of the mill workflow. Nobody has to reconcile what has and hasn't been sent, recreate files, or deliver them to the mills by hand.
• Adoption spread across the mill side of the exchange: many of the accounts on the broker's site belong to the mills, which means the mills themselves work in it daily.
• The platform outgrew its first job. Mills drop operational data into the same site for the broker's BI reporting, payment and bank files route out through automations the broker's engineers built, and emailed attachments land in site folders that feed the broker's Dynamics 365 lockbox process. Each new flow moved onto the platform that already existed, not onto new infrastructure.

Bringing a new counterparty into the exchange stopped being a project, too.

The Exchange Kept Its Shape

Today the daily file dump still runs, the mills still collect their contracts and return their shipment files, and the broker's applications still write to folder paths, exactly as they did before. What changed is underneath: the infrastructure carrying the file layer of the steelmaker's scrap supply chain is Files.com's to operate, and the broker's software engineers spend their time on the supply-chain systems that are actually their job. The broker never had to force every mill exchange into an API to get there. Retiring a self-hosted FTP server doesn't require converting the work it carried; the file exchange can keep its shape while the server behind it becomes someone else's problem.