What Banks Are Actually Allowed to Require for KYC

When a bank asks for more than feels necessary, most people comply and move on — onboarding friction is the last thing you want when you're trying to open an account. But the question of what banks may require for KYC has a real legal answer, and it sits in the tension between two bodies of law that pull in opposite directions: the Geldwäschegesetz, which obliges banks to identify and assess you, and the DSGVO, which obliges them to collect no more than necessary.

Knowing where one ends and the other begins is what separates being a cooperative customer from being an over-collected one. The bank's compliance duty is real. So is your data-minimisation right. They are not in conflict as often as banks imply.

The two laws and why they're not opposites

The GwG (and its Austrian and EU equivalents under the AML directives) imposes Sorgfaltspflichten — due-diligence duties. The bank must identify you, verify that identity against a reliable document, understand the purpose of the relationship, and in some cases dig deeper. That's a lawful basis to process your data: GDPR Art. 6(1)(c), processing necessary to comply with a legal obligation.

Here's the part banks under-explain: that basis is scoped to the obligation. Art. 6(1)(c) lets them collect what the GwG duty requires — not whatever is convenient, not "everything, to be safe." GDPR Art. 5(1)(c), data minimisation, still applies on top. The AML duty defines the ceiling; minimisation says you stay at or below it.

So the real test for any field a bank requests is a single question: does this specific GwG duty require this specific data point for this risk level? If yes, hand it over. If the bank can't connect the field to a duty, you're looking at over-collection.

What standard due diligence actually covers

For a normal customer relationship at standard risk, the core identification duties are narrow:

• Identity: name, date of birth, place of birth, nationality, residential address.
• Verification: a valid government ID checked against that data.
• Purpose and intended nature of the business relationship.
• Beneficial ownership, where you're acting for or alongside others.
• Ongoing monitoring of the relationship over time.

That's the standard tier. It does not, by default, include your tax returns, your employer's details, a breakdown of every income source, or a notarised explanation of where your savings came from. Those belong to enhanced due diligence.

Standard vs. enhanced: know which tier you're in

Aspect	Standard due diligence	Enhanced due diligence
Trigger	Normal risk relationship	High-risk: PEP, high-risk jurisdiction, complex/unusual structure
Identity data	Core identifiers + valid ID	Same, often with extra verification
Source of funds/wealth	Generally not required	Frequently required
Documentation depth	Light	Heavier, with justification
Your leverage	High — minimisation applies cleanly	Lower — but scope still applies

The leverage point: most retail and SME customers are in the standard tier. If you're being treated as enhanced — asked for source of wealth, employment history, exhaustive documentation — the bank should be able to name the risk factor that triggered it. "Policy" is not a risk factor. A specific, articulable reason is.

What over-collection looks like in practice

You'll recognise it once you know the pattern. Common DACH examples:

• A basic Kontoeröffnung that demands proof of income and source-of-wealth documentation with no stated risk trigger.
• A request for a full, unredacted ID copy when verification of the data fields would suffice — and where retaining a full copy isn't separately justified.
• "Send us a copy of your ID by email" — collecting the maximum through the least secure channel, which is its own red flag. How to handle that one is covered in countering insecure KYC requests.
• Bundling: a single form that collects KYC data and marketing consent and data-sharing permissions, where only the first has a legal basis.

None of these are automatically illegal, but each deserves the question: which duty requires this?

How to push back without derailing onboarding

Pushing back works far better as a clarifying question than an accusation. The framing that gets results:

"Happy to provide what's needed. So I can send the right thing, could you confirm the legal basis and purpose for [specific field] under GDPR Art. 13? And whether a verification of the data fields works instead of a full copy?"

This does three things. It signals cooperation. It invokes a right the bank's compliance team recognises instantly (GDPR Art. 13 transparency, Art. 15 access). And it shifts the burden: now they connect the field to a duty. An obliged entity acting properly answers in a sentence. One that's over-collecting tends to go quiet or escalate to a human — which is exactly where the request gets right-sized.

When you do provide data, provide the minimum cleanly. Share the specific fields the check needs rather than the whole document, keep a record of what you sent to whom, and don't let a copy become a permanent uncontrolled artefact. Working out which fields a given request actually justifies is its own discipline — see data minimisation: which fields to share. And your standing rights to ask, correct, and erase throughout the relationship are laid out in your GDPR rights in KYC.

Tools matter here too. Sharing identity data through a scoped link rather than an email attachment lets you give a bank exactly the fields a check needs, watermarked and revocable, with an audit log of who accessed what. That's the model behind ShareKYC — verify once, share narrowly, retain control.

The bottom line

Banks may require what the GwG genuinely demands for your risk level — no more. The AML duty is real and worth respecting; it is also bounded, and GDPR minimisation polices the boundary. The next time a request feels heavy, don't refuse and don't blindly comply. Ask for the legal basis, the purpose, and whether scoped verification works instead of a full copy. Most of the time the request shrinks the moment someone has to justify it.

If you onboard with banks, brokers, and PSPs often, having your verified identity data ready to share field-by-field — instead of re-uploading a passport scan to every new portal — turns each of these from a friction point into a thirty-second decision. That's what ShareKYC is built for.