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

OnePay is a consumer fintech backed by Walmart and Ribbit Capital. 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 OnePay, 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.

OnePay had no controlled way to take that paperwork in. Intake was manual. 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. It was never designed to hand an upload point to an outside consumer and then take it away, so it could not provide the thing this workflow actually required: an intake surface scoped to one customer’s case, alive only as long as the case is.

At more than 400 document requests a day, that gap stopped being survivable. Every request needed a person’s handling, so throughput was capped by the team doing the handling. Every certificate passed through a surface that could not be scoped to one customer or revoked afterward, leaving an intake point standing beyond the case. 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 OnePay can then destroy. Files landing in storage OnePay controls, under its own policies. And all of it driven by API, so the workflow lives inside OnePay’s own support tooling rather than in a portal an administrator runs by hand.

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

One Inbox Per Case, Created and Revoked by Code

What OnePay 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, OnePay’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 OnePay’s own domain, so a banking customer uploading a birth certificate sees OnePay, 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 OnePay’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 OnePay governs.

Cleanup is part of the workflow, not a chore after it. Once the paperwork arrives, a Files.com webhook tells OnePay’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, OnePay replaced manual document collection through a SharePoint data room with an intake pipeline embedded in its own app support flow.

• More than 400 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 OnePay’s own S3 bucket under its own IAM policies, so the most sensitive documents its customers own never sit on a collaboration surface built for something else.
• The next case costs the same as the last: a folder and an inbox created by API. The pipeline scales with OnePay’s customer base, not with support headcount.

Sensitive Document Collection as a Product Feature

Today, a OnePay customer who needs a legal name change gets a link, uploads a certificate, and is done. What used to be someone on the identity-operations team receiving a death certificate by hand into a SharePoint site 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 OnePay: not a portal to administer, but a programmable intake layer its banking app is built on.