An Auto Finance Marketplace Cuts API Traffic by Replacing Its Cleanup Script With Files.com File Expiration Rules

A consumer auto finance and refinance marketplace is a broker rather than a lender: when a consumer refinances a car loan through it, one of the hundreds of banks and credit unions in its nationwide lender network funds it.

That model makes the company a data exchange as much as a marketplace. Every application and funding package is a file moving between the company and a lender, and nearly every one of those files carries consumer financial data. Brokering loans across hundreds of partners nationwide 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

The company 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 over a 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, 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. Daily API traffic ran into six figures, and almost none of it was the business.

The company uses its activity logs for audit and governance: who sent which file to which partner, and when. With machine reads outnumbering real transfers many times over, pulling a day of activity meant filtering the business events out of the machine-generated ones. And the script itself was a standing obligation: something the company had to host, schedule, and maintain 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.

The Script's Footprint, Found in the Logs

The company'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 tens of thousands of times in the script's nightly window.

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 the company's side. And it had to delete files without enumerating anything first.

Files.com already had that built in. The company 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.

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

Nearly All of the Traffic Was the Script

With File Expiration rules in production, the company 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 to a small fraction of its former level within 24 hours of the cutover.
• 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 the company to host or maintain.
• The activity record is the business traffic. An audit export shows partner sends and BI feeds rather than a machine walking directories, so governance review starts from the events that matter.
• 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. The company 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.