The Savings Group Cuts API Traffic 97% by Replacing Its Cleanup Script With Files.com File Expiration Rules

The Savings Group (TSG) is a consumer marketplace for auto finance and refinance, operating the AUTOPAY and RateGenius brands. It is a broker rather than a lender: when a consumer refinances a car loan through TSG, one of the more than 200 banks and credit unions in its nationwide lender network funds it.

That model makes TSG a data exchange as much as a marketplace. Every application and funding package is a file moving between TSG and a lender, and nearly every one of those files carries consumer financial data. Brokering loans across 200 partners in all 50 states means moving regulated data every day. And a file full of consumer data has a lifespan: once it has been delivered and processed, it has to be deleted, reliably and on schedule.

Retention the Way Everyone Builds It: A Script

TSG runs its partner file exchange on Files.com. Loan files go out to bank and credit union partners over SFTP and FTPS. Two-way partner folders are wrapped in PGP encryption, applied automatically as files land. An on-premise server pushes data into the site over SFTP, where it feeds Domo and other downstream automation. The working files are not small: CSVs run to nearly two million rows of loan data.

Retention on all of it was handled the way nearly every file transfer estate handles it: with a script the team wrote themselves. Every night, in a two-hour window, the script connected over SFTP, walked the directories, checked file ages, and deleted whatever had expired. It did its job. Files never accumulated.

The cost was in what the job took. To delete a file, the script first had to find it, so it read enormously more than it wrote: about 100 read operations for every write on the site. Daily API traffic ran past 100,000 calls, and almost none of it was the business.

For a lending company, that is not a cosmetic problem. TSG uses its activity logs for audit and governance: who sent which file to which partner, and when. With 100 machine reads for every real transfer, the record had stopped answering that question. Pulling a day of activity meant digging a few thousand business events out of a hundred thousand machine-generated ones. And the script itself was a standing obligation: something TSG had to host, schedule, patch, and trust with the deletion of consumer data, indefinitely.

The script could not simply be switched off. Deleting aged consumer data is not optional in this business, and any replacement had to be trusted to remove the right files on the right schedule before the old process could retire.

Four Reads a Second, Found in the Logs

TSG's CIO ran the diagnosis himself, from Files.com's own History and API logs. A day's activity export showed read counts wildly out of proportion to anything the business was doing. Filtering by action and time isolated the source: a single directory-status operation firing more than 30,000 times in the script's two-hour nightly window, roughly four per second.

That finding wrote the requirements for the replacement. It had to enforce the same retention, folder by folder. It had to be dependable enough to retire the script outright rather than run beside it as a backstop. It had to need nothing hosted or maintained on TSG's side. And it had to delete files without enumerating anything first.

Files.com already had that built in. TSG replaced the entire home-grown process with File Expiration rules, the platform's native retention policy.

A One-Day Cutover

A File Expiration rule is a folder setting. Files older than the configured age are deleted by the platform itself, on schedule, and each deletion is logged like any other action. Nothing connects from outside and nothing walks a directory tree, because Files.com already knows what it holds and how old every file is.

TSG built expiration rules to match the script's retention behavior, cut over in a single day in January 2025 on a working call with Files.com Customer Success, and went back to the same logs that had exposed the problem to check the result the next morning.

97% of the Traffic Was the Script

With File Expiration rules in production, TSG replaced a scheduled job it owned with a retention policy the platform enforces. The logs showed how much the estate had been carrying:

• Daily API traffic fell 97% within 24 hours of the cutover, settling from more than 100,000 calls a day to under 10,000.
• Retention on consumer loan files runs as platform policy. Files.com deletes aged files on schedule and logs every deletion, and there is no script for TSG to host or maintain.
• The activity record reads like the business again. An audit export now shows partner sends and BI feeds rather than a machine walking directories, so governance review starts from the traffic that matters.
• Retention travels with the folder structure. An expiration rule is a setting on the folder a partner's files land in, so adding the next lender to the network adds no plumbing.

Retention as a Property of the Platform, Not a Program

The nightly cleanup script is the piece of home-grown plumbing that survives in almost every file transfer estate, because it works just well enough to never reach the top of anyone's list. TSG did not tune its script or reschedule it. It deleted it, in a day, and let the platform that moves the files be the thing that cleans up after them.