A Wealth Management Firm Replaces Manual Bank File Exchange With One Files.com Hub and One PGP Key Pair

A US wealth management firm supports a network of affiliated independent advisors.

Client account information lives at the banks and custodians that hold the assets. Turning it into consolidated reporting means moving it: out of the institutions, on to the processing firm that consolidates it, and back again as finished reports. The firm needed to turn that chain into one repeatable exchange: multiple banks sharing an intake and public key without seeing one another’s files, managed from one console.

Sensitive Data Moved by Hand, on the Institutions’ Terms

Before the build, file transfer with outside parties at the firm was manual, with no centralized orchestration or automation over any of it. The firm had no SFTP service for an institution to connect to, no way to decrypt a PGP payload on arrival, and no governed path from a bank to the processor. Sensitive client financial data changed hands the slow way, one file and one person at a time.

The build was set in motion by a specific relationship: a financial institution the firm needed to transmit files with over secure SFTP. That counterparty, like the ones that followed, moved on its own timeline, and the firm’s side of the work waited on institutions to come ready with keys and connections.

The harder constraint was what the exchange had to become once several institutions fed it. Multiple banks needed to send encrypted files into the same operation while remaining invisible to one another. No sender could ever see another sender’s file names, let alone its files. Coordinating PGP keys, SFTP credentials, and per-sender isolation across banks, a processor, and downstream vendors is exactly the estate that dedicated managed file transfer servers, and the staff to run them, exist for. The firm had neither, and a transfer server per relationship was never going to be the plan.

What the fix had to do was clear before any product was named. It had to provide one intake that speaks SFTP as the institutions require, decrypt PGP automatically as files land, keep every sender’s submissions invisible to the others, route data onward to the consolidating processor, and carry finished reports back. It had to run under the firm’s own name, hold files for the length of its compliance window, and run without a server or a team behind it. The firm selected Files.com to be that hub.

One Intake, One Key, Every Sender Kept Apart

Files.com became the encrypted exchange layer between the institutions that hold the data and the processor that consolidates it. The banks connect over SFTP and deliver PGP-encrypted payloads into a raw-data intake on the firm’s Files.com site. Files.com decrypts inbound files using GPG decryption configured on the folder, routes the data onward to the consolidating processor, and receives the processed reports back through the same hub. Vendors that only deliver files get write-only folder access: they can drop what they owe and see nothing else.

The key design is what keeps the estate small. Rather than negotiating a separate key pair with every counterparty, the firm generated a single GPG key pair in Files.com and standardized on it. Every sending institution encrypts against the same public key, and everything moving downstream is decrypted with one key. Multiple institutions send into the same folder on the same scheme, and folder-level permissions are arranged so that no sender can see another’s file names.

The core was configured in a single working session: the SFTP connections, the remote server integrations, the folder structure, and the retention policy. The first bank was already sending files while distribution to the downstream processor was still being built, and further institutions were layered on as each counterparty came ready. The firm’s director of technology ran essentially all of it.

The rest of the configuration makes the hub the firm’s own. The exchange runs on the firm’s branded domain with managed SSL certificates, so counterparties connect to an endpoint that carries the firm’s name. Two-factor authentication is scoped by group, leaving the institutions’ automated SFTP connections unaffected. Deleted files remain available for the length of the firm’s compliance window.

Several Institutions, One Hub

With the hub in production, the firm replaced manual, uncentralized file exchange with a standing encrypted pattern that every counterparty plugs into.

• The bank-to-processor path is no longer handled by hand, and files remain encrypted in transit and at rest.
• Adding an institution is a repeat of the pattern, not a project. When the firm brought on an additional major custodian, it pointed the new sender at the existing folder and public key while keeping its files invisible to the other institutions.
• Compliance holds by configuration rather than by memory: senders stay blind to one another, deleted files persist for the firm’s compliance window, and due diligence on the exchange is handled through Files.com’s SOC report and security documentation rather than infrastructure the firm would have to document and defend itself.

The Next Custodian Is a Folder and a Key

An institutional security mandate used to be a demand the firm had no infrastructure to answer. Today it is the easy part. When an institution requires encrypted SFTP, the firm’s side of the conversation is about which folder to open and when the counterparty will be ready, because the intake, the key, and the isolation already exist on Files.com.

That is the lesson of the build: the firm never needed a pipeline, a key pair, or a server per bank. One encrypted intake on a single key, with folder permissions keeping every sender apart, carries as many institutions as the business adds.