A Real Estate Services Platform Replaced WinSCP and Avoided an AWS SFTP Build With Files.com

A North American real estate services platform runs the business around top-producing real estate teams, regardless of which brokerage they hang their license with: CRM, transaction management, marketing, finance, HR, legal, recruiting, and training.

That business reaches well past brokerage software. The company operates mortgage, title, and insurance lines alongside the agent platform, and the mortgage and capital markets side of the house transacts with Wall Street: loan files, transaction banking, financial reporting. Which meant a company centered on Google Workspace, without a repeatable secure-transfer platform, was going to be handed a file exchange requirement written by a bank. The workflow that met it later became the pattern for exchanging files across a network of capital markets counterparties.

A Bank's File Mandate Lands on a Google Shop

The project came to IT from Finance. One of the world's largest investment banks required the company to build a system that pulls PGP-encrypted financial files from the bank's transaction banking SFTP server into NetSuite, the company's ERP. The requirements were the bank's, and they were not negotiable: SFTP, static IP allow-listing on both ends, industry-standard encryption, PGP-encrypted payloads, and retained records of what was transferred.

The company had nothing repeatable to meet it with. External file movement ran on WinSCP scripts and on-premise SFTP servers that IT maintained end to end. The company's director of information technology, the person accountable for keeping documents secure, wanted one governed platform that enforced that security as policy rather than as a script per counterparty.

The Obvious Answer Was Building It, and Owning It Forever

The conventional path was a build: stand up SFTP servers in AWS, then write and operate everything around them. The pull schedule, the PGP key handling, the decryption step, the hand-off into NetSuite, the monitoring. All of it would land on IT permanently, stacked on top of the WinSCP scripts the team already maintained. The IT director rejected that outright.

So the fix had a clear specification. It had to sit between the bank's SFTP server and NetSuite. It had to speak SFTP with a static IP the bank could allow-list, and present one for the bank to match. It had to decrypt PGP files on arrival, run on a schedule with nobody watching it, hand clean files to the ERP, and retain an encrypted copy as the legal and compliance record. And it had to do all of that as configuration rather than as infrastructure.

The company selected Files.com to be that transfer layer.

A Nightly Pull, Decrypted and Handed to NetSuite

Using Files.com Remote Servers, the company mounted the bank's SFTP server as a folder on its own Files.com site. A scheduled sync now pulls the encrypted financial files in every night. Files.com decrypts each PGP payload using keys managed on the platform, and a NetSuite service account picks up the decrypted files for the company's downstream ERP automation. Every transferred file is retained on Files.com, encrypted at rest, as the record Finance and Legal can point to later.

Nothing in the design is bespoke to this one bank. It is a mount, a schedule, a key, and a hand-off, which is what made it worth more than the project it was built for.

One Feed Became a Counterparty Network

With the workflow in production, the company met the bank's mandate without standing up any infrastructure. What would have been a permanent build, servers and scripts and key handling owned by IT indefinitely, became configured automation.

• The nightly bank feed runs on its own: pull, decrypt, deliver to NetSuite, retain. Nobody runs a script and nobody babysits a server.
• The WinSCP scripts and on-premise SFTP servers were retired for external transfer, and secure external file exchange got one governed home.
• The pattern repeated across the capital markets side of the business. From a single bank feed at launch, the company now exchanges loan files with counterparties including major asset managers, an insurance company, and a loan-trading platform, and sends financial reporting back to the bank.
• When the company acquired a mortgage business, it onboarded onto the same platform as a Files.com Partner, with the acquired company's own IT team administering its counterparty folders.

The Next Counterparty Is Configuration

Before Files.com, a bank-grade transfer requirement meant the company's IT team choosing between a script it had to maintain and a server estate it had to own. Now, when Finance brings IT the next counterparty, the answer is a mount, a schedule, and a key on a platform the IT team already runs, with the security enforced by the platform rather than by a script IT maintains. Secure external file transfer stopped being something the company builds and became something it configures, which is why one mandate from one bank turned into the way an entire capital markets operation moves its files.