What a file-request link is and when to use one instead of email

You're an accountant, a tax pro, or a financial advisor, and you need a client to upload their last two pay stubs, a passport scan, and a brokerage statement before you can finish onboarding them. You can email them and hope the attachment doesn't bounce off the corporate gateway. You can send them a Dropbox file request. Or you can send them a link that captures who uploaded what, when, and from where into a tamper-evident audit row at delivery time — with a signed Proof-of-Deletion Receipt on Enterprise plans when the transit copy is destroyed. The third option is what the rest of this post is about.

The shape of a file-request link

A file-request link is a one-direction inbound channel. The recipient clicks the link, sees an upload prompt (no folder browsing, no peer files visible), drops their documents in, and the bytes flow back to you. They never see your other files. They never see anyone else's uploads to the same request. They get a receipt; you get a notification and a row in your audit log.

That's the simple version. The interesting part is what's wrapped around the upload itself.

For a regulated workflow — KYC, source-of-funds, tax document collection, beneficial-ownership disclosure — the upload alone is the boring part. The boring part is solved by half a dozen tools. What's not solved is the wrapper:

• A per-uploader audit row tying a specific human (verified by email, passphrase, or magic link) to a specific filename, file size, and timestamp.
• A defensible disposal artifact at the back end — on Enterprise plans, a signed Proof-of-Deletion Receipt when the transit copy is destroyed, useful when a regulator or auditor asks "did the client deliver the document, and what happened to your transit copy afterwards?"
• An expiry window so a request you sent to a client in February doesn't sit open forever as a soft phishing surface for whoever next gets their email.
• A passphrase or identity gate so the wrong person — a spouse, an assistant, a forwarded inbox — can't drop a fake document into the slot.
• Optional caps so a single request can't be flooded with 800 files because a script went wrong.

That wrapper is the thing email and consumer file-sharing don't give you. And in regulated workflows, the wrapper is the thing that matters.

Why email is not the answer here

Every accountant and advisor I've talked to has the same workaround: "Just email it to me." It works, until it doesn't. Three failure modes, in rough order of how often they bite:

1. Attachment loss. The client's corporate mail gateway strips the PDF. Or yours does. Or Gmail nukes it as a suspected scam because the filename contains "passport." You don't know it happened until you ask the client where the document is and they say "I sent it two weeks ago."

2. Trail loss. A document ends up in your inbox. Six months later compliance asks who sent it, when, from what IP, and whether the chain of custody is intact. Your answer is a forwarded email header and a shrug. If the client used the wrong account, used a personal Gmail instead of their corporate address, or BCC'd themselves and a friend, you have no clean way to reconstruct what actually happened.

3. PII lying around. A passport scan, an SSN-bearing tax form, or a brokerage statement now lives in your sent folder, the client's sent folder, two corporate mail archives, and the metadata graphs of whatever providers handled the relay. None of that gets deleted on a schedule you control. None of it gets deleted at all, in most cases.

A file-request link with the right wrapper closes all three. The upload either succeeds (and you see it) or it doesn't (and the client sees the failure immediately, not three weeks later). The trail is built in. The bytes go to a destination you control with a retention policy you set.

Why Dropbox-style file requests aren't quite right either

Dropbox file requests, Google Drive folder uploads, and OneDrive request links are real products and millions of small businesses use them. They are not bad tools. They are the wrong tool for KYC and tax-document collection for a specific reason: they're designed as a drop-folder, not as a regulated intake channel.

Here's the difference that matters:

• A Dropbox file request gives you a folder full of files. It doesn't give you an audit row per uploader saying "Maria Chen, verified via passphrase, uploaded 2023-W2.pdf (412 KB) at 14:03 UTC on April 14 from IP 203.0.113.42." You might be able to reconstruct that from logs if you're on an Enterprise tier and the audit export still has it. You won't get it as a first-class artifact.
• It doesn't write a per-uploader row to a tamper-evident log, and it doesn't issue a signed destruction artifact when the transit copy is later deleted. The client sees a thank-you screen and a green check; your audit trail is whatever Dropbox's mutable activity feed reports.
• It doesn't tie a passphrase to the upload slot. Anyone with the URL can upload. If you sent the link to a client and they forwarded it to their assistant who forwarded it to the family lawyer, anyone in that chain can drop a file in the slot and you'll see it land — with no signal about who they were.
• It doesn't expire on a sensible default. You set the request up, you forget about it, the URL lives forever in the client's inbox as a soft credential.

For collaborative file sharing among coworkers, these are non-issues. For a regulated workflow where you need to defend a chain of custody to a compliance auditor or a regulator, they're each a small bleed.

A file-request link for KYC is not a folder. It's an intake channel with an audit trail, a receipt, and an expiry. If the tool you're using doesn't give you all three, you're using the wrong tool.

The audit row is the load-bearing piece

If I had to pick the single most important difference between a regulated file-request and a consumer one, it's the per-uploader audit row.

For an accountant collecting source-of-funds documentation, the audit row needs to answer five questions later:

1. Who. Email verified, or magic-link verified, or passphrase-verified. The identity isn't just a self-declared name in a form field.
2. What. File name, file size, and the share's opaque identifier so the row can later be tied back to the specific upload event.
3. When. Server-side timestamp. Not the client's clock.
4. From where. IP address, optionally a country-level geo (city + country).
5. In what state. Did the upload complete? Did it get truncated? Did the client try three times and one succeed? Was the request still live or had it expired? Was a passphrase verified or skipped?

CIPH4's audit log is hash-chained, which means each row's integrity depends on every previous row's. If someone tampers with row 47, every row after it stops verifying. You don't have to take anyone's word that the trail is intact — there's a math proof you can run. We built the public receipt verifier specifically so a regulator, an auditor, or a courtroom can independently confirm that a specific upload happened, with the contents you claim, at the time you claim, without trusting CIPH4 the company at all.

For workflows that touch financial services compliance, this is the entire point. The defensibility of your KYC program is only as good as the records that back it.

When a file-request link is genuinely the right shape

The shape works well when:

• You're collecting documents from someone, not sharing documents with them.
• You need a defensible record of receipt — for compliance, for an auditor, or for a "who sent what when" question that will come up six months later.
• The number of uploaders is more than one — a single request gathering documents from twelve different LPs in a fund raise, or twenty new clients onboarded in the same week.
• The uploaders aren't sophisticated enough to manage their own secure-sharing tooling. You need a link they can click on their phone in an Uber.
• You want the documents to disappear from your side on a predictable schedule, not accumulate in a "to delete someday" folder forever.

Common buyer scenarios where this lands cleanly:

• Tax pros collecting W-2s, 1099s, K-1s during filing season. Three hundred clients, each uploading four or five documents, each upload needs to be tied to a specific return.
• Wealth advisors running annual KYC refresh. Beneficial-ownership disclosures, source-of-funds attestations, refreshed government ID scans.
• HR onboarding contractors who need to send a W-9, a void check, and a passport scan before payroll can run.
• M&A diligence collecting financials from a seller's CFO, where the request goes to one person and the chain-of-custody question matters because the documents will end up referenced in the closing binder.
• Insurance brokers collecting claim documentation — police report, medical records, repair invoices — with a per-uploader audit row at delivery and (on Enterprise) a signed Proof-of-Deletion Receipt when the transit copy is destroyed.

Cases where it's not the right shape:

• A one-off send of a single document to a specific person. That's a regular encrypted-link share, not a file-request.
• A real collaborative folder where multiple people need to see what each other have uploaded. That's a shared workspace, and you should use Box or SharePoint with proper access controls.
• Anything the recipient needs to edit and send back. File-requests are inbound-only; they don't round-trip.

What "good" looks like in practice

A few concrete behaviors a regulated file-request workflow should give you:

• One link per uploader. Gives each upload a distinct audit row tied to a verified identity. The opposite shape — a single shared link with no per-uploader differentiation — gives you an audit row that says "someone uploaded a passport at 14:03" and forces you to play detective.
• An expiry default measured in days, not "never." Seven days is a good ceiling for most workflows. Long enough that a busy client can find the document on the weekend; short enough that a forgotten link doesn't become a year-long phishing surface.
• A modify-after-send capability. You sent the link, the client said "I'll get to it Monday," Monday turns into Friday, the link expired. You want to extend the expiry by a click, not start over with a new link and lose the trail continuity.
• A defensible record on the receiving side. Every upload is captured in the hash-chained audit log with the per-uploader fields above. On Enterprise plans, when the receiving share is later destroyed (burned, expired, or revoked), CIPH4 generates a signed Ed25519 Proof-of-Deletion Receipt anchored to that chain — a portable artifact you can hand a regulator who later asks "did the client send the document, and did the transit copy get destroyed afterwards?"
• Clear failure semantics. If the upload truncated, you want to know. If the wrong passphrase was tried four times in a row, you want to know. If the link expired before the client got to it, the client should see a useful message and not a generic error.

The compliance buyer's view on this is usually narrower than the workflow itself: "show me the audit trail, show me the retention controls, show me the proof of deletion." The accountant or advisor cares about all three, plus they care that the link doesn't make the client feel like they're filing taxes through a security clearance portal. Friction kills completion rates.

Pricing this against what you're already paying

If you're paying for Dropbox Standard or Google Workspace Business at the firm level, you have file-requests today, and they're the consumer-grade version described above. For a small practice with one accountant and ten clients a year, that's probably fine.

For a tax firm processing two hundred returns in a quarter, a wealth advisor running KYC on a book of three hundred clients, or an insurance brokerage handling several hundred claim packages a year, the math changes. The per-upload audit row, the per-link passphrase, and the retention-policy guarantee aren't extras — they're the difference between a defensible workflow and an indefensible one. Our pricing puts file-requests on the Teams plan because that's where the per-uploader audit row and tamper-evident log kick in. Signed Proof-of-Deletion Receipts at the back end are an Enterprise upgrade for shops that need the portable cryptographic artifact in addition to the audit row. The Free plan is for sender-side encrypted links, not for inbound document collection.

If you're integrating file-requests into a portal your clients already use — a tax-prep workflow, a client onboarding sequence, a claims intake form — the API documentation covers how to mint a request programmatically, embed it in your portal, and stream the delivery webhook back to your case-management system. The wrapper is the same; you're just driving it from your software instead of clicking through the CIPH4 dashboard.

What to do next

If you're collecting KYC, source-of-funds, or client tax documents and you're currently using email or a consumer drop-folder, the upgrade path is straightforward: send your next request through a file-request link that captures a per-uploader audit row at delivery and — on Enterprise — produces a signed Proof-of-Deletion Receipt when the transit copy is destroyed. The first time a compliance question comes up six months later, you'll know whether it was worth it.

Start with one client and one document type. If the audit row, the receipt, and the expiry behavior fit the shape of your workflow, expand from there.