A University Bypasses Its Reporting System’s SFTP Cap with a Files.com Fan-Out Hub

A private nonprofit university offers graduate and undergraduate programs across several schools, and behind that work sits the administrative stack of a much larger institution. The university runs a financial system, a reporting utility, payroll, a library, a campus bookstore, a learning platform, and expense tools, and nearly every one of them has an outside counterparty: a bank expecting daily positive-pay files, a payroll processor, a library services cooperative, and SaaS platforms that need student lists on time. Each counterparty expects its files delivered on its own schedule, over its own protocol. But the reporting application that generated most of those files capped how many outbound SFTP endpoints it could define. The university needed to land every file once in Files.com and fan it out from there, bypassing the cap without replacing the reporting system.

Positive-Pay by Hand and a Copy Job Every 15 Minutes

Before Files.com, each of those exchanges was its own piece of manual work. Positive-pay files went to the bank by hand. Data moved out of the reporting utility to an archive location and to a remote partner by hand. One vendor feed depended on a copy job that a person repeated every 15 minutes, or whenever a file was created. Sensitive payroll data was handled manually on its way into an on-premise budget forecasting system.

The university wanted every one of those exchanges on a single encrypted, logged path. Some deliveries also carried an ordering requirement. The bank consolidates a sequence of reports into a single report, and the second cannot be processed until the first has been sent. The university wanted the workflow itself to enforce that order.

The Reporting System Could Never Hold a Connection for Every Partner

The manual work persisted because the university controlled neither end of the exchange. The counterparties dictate the protocols: the bank sets the terms for how its daily transaction files arrive, and each vendor runs its own SFTP or FTPS endpoint. On the sending side, the reporting application that generates most of these files caps how many outbound SFTP endpoints it can define. However the integrations were arranged, the source system could never hold a connection for every partner the university needed to serve. No configuration inside the existing tools could change that, and replacing a campus reporting system to fix file delivery was never a realistic option.

Meanwhile the roster kept growing. A bank, a payroll processor, library services, a bookstore platform, a training platform, and expense vendors each needed timely, secure delivery, and every addition meant more hand-carried files stacked on a process that already had someone copying files every 15 minutes.

The university selected Files.com to be the hub. The new layer had to speak whatever protocol each counterparty demanded, enforce delivery order on its own, keep a dated archive copy of files that arrive under the same name every day, and retain every transfer for the required period.

Everything Lands Once, and Files.com Automations Fan It Out

Files.com became the integration layer between the university’s campus systems and every outside party. The reporting and finance systems push their files to Files.com over a single connection, and everything after that happens on the platform.

Each external partner has its own remote server connection on the Files.com side, configured for that vendor’s SFTP or FTPS endpoint. When a file lands, a Files.com Automation triggers on the upload and copies it out in one run: to the partner, and to the archive. Because the source files carry the same name every day, the Automation renames each archived copy with a date, so the archive holds a usable history instead of one endlessly overwritten file. Scheduled Automations replaced the manual copy cycle outright, so reports now run on a schedule and deliver themselves. The ordering the bank requires is enforced by the workflow itself: the second report is held until the first has been sent.

The same hub accommodated destinations a plain endpoint could not. The university provisioned its site on a custom domain with dedicated IP addresses, giving vendors a fixed address to whitelist, while SFTP, FTPS, and AS2 covered different protocol requirements. Payroll data arriving from Paychex was forwarded by the Files.com Agent to Axiom, the budget forecasting system on an on-premise server behind the campus firewall, over an outbound-only connection. Every transfer also copies to a local archive and to Amazon S3, meeting the retention requirement as a built-in step of the workflow.

The university built all of it in-house. The application support engineer behind the deployment configured the connections and Automations from the documentation, staged the rollout through parallel test and production environments, and had the on-premise Agent installed and its automations running the same day.

Deliveries Now Run Themselves, in the Required Order

With the hub in production, the university replaced an estate of hand-run, per-counterparty transfers with a fan-out that runs itself. FileZilla, the internal FTP server, and the manual copy process are retired.

• The 15-minute copy cycle is automation now. Reports run on a schedule and deliver themselves in the required order, with the second bank report held until the first has gone out. The order is a property of the workflow.
• Every workload travels encrypted and on the record. Payroll, positive-pay, and student-record files move over SFTP, FTPS, and the Agent, and every transfer is logged.
• Retention enforces itself. Every transfer copies to a local archive and to S3, so the retention requirement is met as a step of the workflow.
• Adding a partner is a destination, not a project. Several external partners and platforms already run through the hub, and the next one is a new fan-out target on Files.com, not another outbound definition wrung from a capped reporting system.

The Cap That Stopped Mattering

Today the reporting application still limits how many outbound connections it can define, and that limit no longer describes anything about the university’s integration estate. The campus systems speak to one place, and Files.com speaks to everyone else. The staff who once repeated a copy job every 15 minutes and carried positive-pay files to the bank by hand now point a new feed at the hub and let the Automations carry it.

The university never had to replace the capped system to get past its cap. It landed every file on Files.com once, and let the hub do the fanning out.