How to Push Back on Insecure KYC Requests
"Just send a copy of your ID to this address." You've read that line a hundred times, and most people sigh and attach the scan. But emailing your passport is one of the worst things you can do with it: email is unencrypted in transit by default, and the attachment becomes a permanent copy sitting in the sender's mailbox, your sent folder, and both providers' backups indefinitely. Learning to push back on insecure KYC requests — quickly, professionally, without torching the relationship — is a skill worth having if you share ID data more than occasionally.
The good news: most insecure requests aren't malicious. They're a default. The person on the other end is following a process nobody designed with security in mind, and they'll usually accept a better channel the moment you offer one. The trick is to make declining frictionless for them, not a fight.
Why "email me your ID" is the wrong default
Worth naming the specific problems, because you'll sometimes need to explain them:
- In transit, email is often unencrypted. SMTP between servers may or may not use TLS, and you don't control whether it does. Treat the contents as a postcard.
- It creates permanent, uncontrolled copies. Your sent folder, their inbox, both sets of backups, possibly a shared support mailbox. You cannot expire, revoke, or even count those copies.
- It scatters the data. Forwarded internally, downloaded to a laptop, attached to a ticket — each hop is a new place your ID lives.
- It's the least accountable channel. No audit log, no watermark, no scope. If it leaks, you'll never know from where.
A secure link inverts every one of these. The full technical comparison is in email encryption vs. secure link; for the pushback itself, you mostly need the scripts.
The core move: offer a better channel, don't just refuse
Refusing alone creates friction and makes you the problem. Offering an alternative makes you the easy path. The structure that works every time:
- Decline the insecure channel plainly, without apology or lecture.
- Offer a specific, concrete alternative they can act on immediately.
- State the benefit to them, not just to you (less liability, cleaner audit trail).
That third point matters. Frame the secure link as making their compliance life easier — auditable, scoped, no sensitive attachment sitting in their inbox — and you've turned a refusal into a favour.
Ready-to-use scripts
Copy, adapt, send.
The standard offer (covers most cases):
Thanks — I'm not able to send ID documents by email, but I can share them through a secure link instead. It expires after a set time, limits the number of views, and gives you exactly the fields you need to verify. Shall I send that over?
When they insist email is "fine" or "how we always do it":
I understand it's the usual process. For ID documents I keep to a secure channel — email leaves permanent copies in both our mailboxes, which is a liability for both of us. The secure link does the same verification with an audit trail on your side. Happy to send it now.
When they need a specific document on file (retention):
Of course. So I send only what's required, could you confirm which fields your check needs recorded, and whether a viewable secure copy works rather than a download? If retention is mandatory I'll enable that — I'd just like to scope it to what's actually needed.
When there's no secure portal and they have nothing to offer:
No problem — I'll provide a secure link from my side. You'll get a URL that opens the document in your browser; nothing to install. It expires automatically once your check is done.
Escalation, when the front line won't budge:
I've offered a secure alternative and I'd prefer not to send identity documents over email. Could you point me to your data protection officer or compliance contact so we can confirm the right channel? I want to complete this — just through a method that protects both of us.
That last one resolves things more often than not. Front-line staff follow scripts; a DPO or compliance lead knows exactly why emailing passports is a problem and tends to fix it fast.
A decision matrix for the moment
When a request lands, run it through this:
| Situation | Your move |
|---|---|
| Casual request, no legal duty | Offer secure link; redact hard; consider declining |
| Legitimate check, insecure channel | Offer secure link doing the same verification |
| Bank/notary, hard GwG duty | Provide via secure link, scoped to required fields |
| They insist on email after you offered | Escalate to DPO / compliance |
| They refuse any secure channel | Treat as a red flag; weigh whether to proceed |
The pattern: almost never is "email it" the right answer, and almost always there's a proportionate alternative. Knowing which requests carry a real legal duty — and which don't — makes the conversation easier; that's covered in what banks are actually allowed to require for KYC.
Make the secure alternative real
Scripts only land if you can actually produce the secure link you're offering. This is where having the capability ready changes the dynamic: instead of "I'd prefer something more secure" (vague, easy to brush off), you say "here's a link, it expires Friday, view-only" (concrete, done).
ShareKYC is built precisely for this exchange. Your identity data is verified once and held AES-256 encrypted in an EU-hosted vault; when a request comes in, you generate a link scoped to the fields they need, with expiry, an access limit, downloads off, an invisible forensic watermark, and full audit log — and you can revoke it the moment the check is done. The pushback stops being a negotiation about your discomfort and becomes you handing over a cleaner solution. The wider framework of access levers behind that link is in share your ID without losing control.
The bottom line
"Send your ID by email" is a default, not a requirement, and you're entitled to redirect it. Decline the insecure channel plainly, offer a concrete secure alternative in the same breath, frame it as easier for them too, and escalate to a DPO or compliance contact if the front line won't move. Most requests get fixed at step one; the rest get fixed at escalation.
The difference between getting brushed off and getting compliance is being able to offer the better channel on the spot. Have a scoped, revocable, watermarked link ready to send, and "I can't email that, but here's a secure link" becomes the easiest thing you say all week — which is exactly what ShareKYC puts in your hands.
Frequently asked questions
What do I say when asked to email a copy of my ID?
Offer a secure alternative: I can't send ID by email, but I'll share a secure link that expires and gives you exactly the fields you need. Most teams accept this immediately.
Is it unreasonable to refuse to email my passport?
No. Email is unencrypted in transit by default and leaves permanent copies in multiple mailboxes. Declining and offering a secure channel is a proportionate, professional response.
When should I escalate an insecure request?
Escalate when the front line insists on email after you've offered an alternative. Ask for their data protection officer or compliance contact — the request usually gets fixed at that level.
What if the company has no secure upload option?
Offer your own secure link. If they refuse any secure channel and insist on email, that is a signal about their data handling worth weighing before you proceed.