A Consumer Fintech Replaced a SharePoint Data Room With One-Time Files.com Links in Its Banking App

A consumer fintech runs its banking business entirely through a mobile app. There are no branches. Every part of the banking relationship happens on a phone, from opening the account to getting help with it.

That includes the moments banking has always handled across a counter. When a customer marries, or settles an estate, the legal name on the account has to change, and the bank has to collect certified paperwork to make that change: a marriage certificate, a birth certificate, a death certificate. A branch bank handles this with a visit and a photocopier. For a mobile-only bank, it is a file transfer problem, and it arrives hundreds of times a day.

The Paperwork Behind a Name Change

The documents behind a legal name change are among the most sensitive a person owns. And the person sending them is not a trading partner with an SFTP client. It is a retail banking customer on a phone, who needs to receive one link, upload once, and never hold access to anything again.

The company wanted intake built for that customer. The identity-operations team collected certificates by hand, using SharePoint as a data room. SharePoint is built for standing collaborators, people who join a site and keep working in it, not for handing an upload point to an outside consumer once and then taking it away. What this workflow required was an intake surface scoped to one customer’s case, alive only as long as the case is.

At hundreds of document requests a day, the manual model could not keep up. Every request needed a person’s handling, so throughput was capped by the team doing the handling. The fintech wanted each case to have its own upload point, scoped to that one customer and revoked when the case closed. And the volume only moves in one direction as the customer base grows.

The replacement had to work backward from the customer. One link per case, delivered inside the support conversation the customer is already having. An upload point that someone with no account and no software can use once, and that the company can then destroy. Files landing in storage the company controls, under its own policies. And all of it driven by API, so the workflow lives inside the company’s own support tooling rather than in a portal an administrator runs by hand.

The fintech’s corporate security engineering team selected Files.com to be that intake layer.

One Inbox Per Case, Created and Revoked by Code

What the company built on Files.com is a programmable intake layer between its support tooling and its own AWS storage, where every upload point is created, scoped, and destroyed by code.

When a name-change case opens, the company’s support tooling calls the Files.com API to create a folder and a one-time Files.com Inbox for that case, scoped to its case ID. The customer gets an emailed upload link. The page it opens runs on the company’s own domain, so a banking customer uploading a birth certificate sees their bank, not a third-party tool. An Inbox visitor can only upload, and each session stands alone: no customer ever sees another customer’s files, or even their own from an earlier session.

The files never rest on a sharing surface. The case folders sit on a Files.com remote server mount pointed at the company’s own AWS S3 bucket, governed by the restrictive IAM and bucket policies its security team wrote. Files.com is the front door; the documents land in storage the company governs.

Cleanup is part of the workflow, not a chore after it. Once the paperwork arrives, a Files.com webhook tells the company’s tooling the files are in and the case can move forward. The upload link is revoked, and each case folder and inbox is set to expire and delete after a few days. No upload point outlives its case.

From Hand-Collected Paperwork to a Daily Pipeline

With the workflow in production, the fintech replaced manual document collection through a SharePoint data room with an intake pipeline embedded in its own app support flow.

• Hundreds of document requests a day run through the pipeline with nobody collecting or filing certificates by hand. Intake that used to cost a person’s attention per request now costs an API call.
• Each customer’s access is exactly one case wide: one link, one upload, revoked after use, with the inbox gone within days. There is no standing portal to police and no upload point left open by accident.
• Certificates land directly in the company’s own S3 bucket under its own IAM policies, so the most sensitive documents its customers own rest only in storage the company governs.
• The next case costs the same as the last: a folder and an inbox created by API. The pipeline scales with the company’s customer base, not with support headcount.

Sensitive Document Collection as a Product Feature

Today, a customer who needs a legal name change gets a link, uploads a certificate, and is done. What used to be a person’s handling per request is now machinery: Files.com creates the door, takes the file, closes the door, and cleans up behind itself.

The lesson travels well beyond one fintech. Collecting sensitive documents from consumers at banking scale does not require a standing portal or human handling. It can run as ephemeral, per-case upload links created and revoked entirely by API, inside the company’s own product, with the files landing in storage the company already governs. That is what Files.com gave the fintech: not a portal to administer, but a programmable intake layer its banking app is built on.