Allied Credit Used Files.com to Decrypt and Verify Hundreds of Thousands of Loan Files for SharePoint

Allied Credit is an Australian non-bank lender in auto and equipment finance. The company operates between banks and downstream lenders and dealers, with files moving among financial institutions as part of the business.

That operating model has a consequence that shows up in the file system. Behind every loan sits an application file, and when a product launches or a book of loans changes hands, the paperwork has to move between institutions with it. That paperwork is sensitive consumer credit data, and it can run to hundreds of thousands of files at a time.

In 2025, that pattern arrived with a hard deadline attached. A new finance product was set to go live in October, and before it did, Allied Credit’s customer support team needed the historical loan-application archive behind it.

The Archive Behind an October Launch

The first archive comprised hundreds of gigabytes of PDF loan documents, every one of them PGP-encrypted. The support team needed those documents decrypted, organized and usable in SharePoint before launch. Without them, an agent taking a call about an existing loan on day one would have had no file to open.

The encryption was not a preference.

Nothing in Allied Credit’s estate was built for this class of transfer. File movement at the lender had grown up around small daily batch files under a gigabyte, pushed around by PowerShell scripts and a basic SFTP server. A bulk encrypted archive exchange between two organizations was not something the company could support at all.

The destination imposed its own limit. SharePoint document libraries degrade once a folder holds too many files, so the archive could not simply be dumped into the support team’s library. And the transfer itself carried a restart risk: moved as one job, a failure hundreds of gigabytes in would mean starting the whole thing over.

That was the real shape of the problem. Two endpoints Allied Credit did not control, the partner’s platform on one side and SharePoint’s behavior on the other, with a contractual encryption obligation covering everything in between and a launch date that would not move.

What the Transfer Had to Do

Allied Credit ran the migration through Files.com, placing the platform between the partner’s transfer platform and its SharePoint estate as the layer that automatically decrypted the archive, organized it for SharePoint, kept the data in Australia and produced per-file proof of delivery. The immediate job was a migration, but the design would leave Allied Credit with a repeatable way to handle the next bulk exchange.

A Small Rehearsal Before the Archive Moved

Before anything scaled, the team moved a small test batch end to end and validated the result. Only after that rehearsal confirmed the whole path did the real volume start flowing.

Allied Credit and the partner exchanged 4,096-bit PGP keys, and the partner split the archive into pieces so that a failed transfer meant re-sending a piece rather than restarting the job. Files arrived over SFTP into a Files.com folder with a GPG decryption rule set at the parent-folder level, so every encrypted file was decrypted on arrival. The encrypted original stayed on Files.com until the batch was validated. The decrypted copy moved into a secured SharePoint site for the support team, and a Files.com Automation deleted it from the platform once the move completed, so no plaintext copies accumulated. The site itself ran in Files.com’s Australian region, so the archive never left the country.

Batches Sized to What SharePoint Can Take

For a subsequent batch of hundreds of thousands of files, a Files.com move automation organized the source into subfolders, one per day of the transfer, each holding a capped number of files. The sizing was deliberate, and it came from the destination, not the source.

Files.com Syncs then moved the batches into the SharePoint document library sequentially, deleting from the source as each batch landed so nothing synced twice, at a sustained rate of tens of thousands of files a day. When the run finished, the team reconciled the migration against Files.com API log exports rather than counting folders by hand.

From Launch Deadline to File-by-File Proof

Across the initial launch migration and the subsequent bulk batch, Allied Credit completed a class of transfer it had never been able to run at all, with a full record behind it.

• The first wave was decrypted and delivered into the secured SharePoint site in time for the October 2025 go-live, so the support team had the document history behind the product from day one.
• A subsequent batch of hundreds of thousands of files was received, decrypted and delivered in daily batches, with no one handling a single file by hand.
• The contractual obligation held end to end: the data stayed encrypted in transit and at rest until it reached its secured destination.
• Files.com API log exports let the team reconcile the completed migration file by file, so completeness was proven rather than assumed.

The larger result is that the pattern now exists. The next bulk exchange with a partner starts from machinery that is already built: a folder with a decryption rule, a key exchange, batches sized to wherever the files are going, and a log that proves delivery. What was not a capability at all a few months earlier is now configuration.

A One-Off Migration That Left a Standing Capability

Today, a support agent who takes a call about a loan opens the customer’s original application in SharePoint. Nothing about PGP keys, batch sizing or the partner’s transfer platform is visible from that seat, and that is the point. The machinery that put those files there ran on Files.com, and it ran with a record to show for it.

The hard part of moving a bulk encrypted archive was never bandwidth. It was decryption at scale, and it was proof: that SharePoint could sustain what landed in it, and that every file actually arrived. Files.com carried both, which is why a product launch could depend on the transfer.