Data Minimization: Which Fields a Bank Actually Needs

The form asks for fifteen fields. The law requires six. That gap is where data minimization lives, and most people fill the whole form anyway because pushing back feels confrontational and slow. It is neither, once you know which fields are load-bearing and which are decorative. This is a field-by-field walkthrough of what a bank or obliged entity actually needs under AML rules, what it merely prefers, and the legal basis you can cite when you decline the rest.

The principle is not abstract. Art. 5(1)(c) DSGVO makes data minimization a binding rule: personal data must be "adequate, relevant and limited to what is necessary." A KYC form is a collection exercise, and every field on it needs a justification. AML law (in the DACH region, the GwG and its national equivalents) sets a mandatory core. Everything past that core is the institution's choice, and a choice has to be defensible.

The mandatory core

For a standard natural-person onboarding, the AML floor is narrow. These are the fields you will not win an argument over, because the law names them:

• Full legal name — first and last name as on the identity document.
• Date of birth — the primary disambiguator for identity matching.
• Residential address — for the customer profile and risk assessment.
• Nationality — relevant to sanctions and PEP screening.
• Identity document type and number — the evidence that the identity was verified.

That is the spine of customer due diligence. If you are opening an account, expect to provide all five and have them verified against a document. Withholding them is not data minimization; it is refusing the transaction.

The negotiable fields

The interesting territory is everything else the form requests. Here the institution has to show necessity, and frequently cannot.

Field	Mandatory?	Legal basis to withhold
Place of birth	Usually not	Disambiguation only; ask for the specific obligation
Photo on ID copy	Situational	Art. 5(1)(c); not needed if identity already verified another way
Tax ID / SSN	Only if tax-reporting applies	Necessity tied to a different law, not AML
Marital status	Almost never	No AML or tax basis for standard accounts
Employer / occupation	Risk-based	Required only where source-of-funds review is triggered
Mother's maiden name	No	Legacy security-question artefact, not a KYC field

The pattern: a field is defensible when a named obligation requires it for this product and this customer. "We always ask" is not a legal basis. Neither is "the system has a field for it."

Walking the document itself

The single biggest over-collection happens with the ID copy. A passport or national ID card carries far more than the five core fields — machine-readable zone, signature, sometimes biometric markers. When you upload a flat scan, you hand over all of it.

Data minimization applies to the copy, not just the form. You are entitled to redact what is not necessary for the stated purpose. Address-proof checks rarely need the document number; document-number checks rarely need the photo. The practitioner move is to redact before sending, which I cover in detail in redacting ID copies safely. The institution can still object and ask for the unredacted field — but now they carry the burden of justifying it, which is exactly where minimization should put the conversation.

Knowing what a bank can lawfully demand

The flip side of minimization is calibration: you cannot push back credibly if you do not know the actual baseline. A bank running enhanced due diligence on a high-risk profile legitimately needs more than one running simplified due diligence on a low-risk one. The fields that are negotiable for a basic current account become mandatory once a transaction crosses a threshold or a PEP flag fires.

So before you redact or refuse, calibrate against the real requirement set. I keep a working reference of what banks may actually require under KYC for exactly this — it is the difference between principled minimization and obstructive nitpicking. The goal is to give the necessary fields cleanly and contest only the genuinely unnecessary ones.

The withholding script

When you decline a field, do it in a way the compliance team can process. A vague "I'd rather not" gets escalated and stalls onboarding. A precise objection moves faster:

1. Name the field you are withholding.
2. State the principle — Art. 5(1)(c) DSGVO, data minimization.
3. Ask for the obligation — "Which specific requirement makes this field necessary for this product?"
4. Offer the core — confirm you are providing all mandatory fields, so the refusal reads as scoped, not obstructive.

In practice, half the over-collected fields disappear the moment someone has to find the legal basis and cannot. The other half come back with a real justification, and then you provide them. Either outcome is correct. Data minimization is not about giving less; it is about giving exactly what is necessary and no more.

Purpose limitation is the field you forget to check

There is a second principle stacked behind minimization, and it changes which fields are defensible at all: purpose limitation, Art. 5(1)(b) DSGVO. Data collected for KYC may be processed for KYC. It may not be quietly repurposed for marketing segmentation, credit scoring, or "service improvement" unless a separate lawful basis covers that.

This matters at the field level because a field that is necessary for the stated purpose can still be over-collection if the institution is really gathering it for a second, unstated one. Occupation is the classic example: legitimately required for a source-of-funds review, but frequently captured to profile customers commercially. When you see a field that the AML floor does not require, the right question is not only "is this necessary for KYC" but "what else are you going to do with it."

The practitioner test for any borderline field:

• Is it on the AML floor? If yes, provide it.
• Is there a named obligation for this product? If yes, provide it.
• Is the stated purpose KYC, and only KYC? If the answer is fuzzy, that fuzziness is the over-collection.

Two fields can look identical on the form and be completely different in legitimacy depending on the answer to the third question. Minimization without purpose limitation is half the analysis.

Storing the calibration so you only do it once

The exhausting part is that this negotiation resets with every new institution. You re-derive which fields are core, re-redact the document, re-run the script. A verify-once model removes the repetition: you verify your identity a single time, hold the data in an encrypted EU vault, and share it field-by-field with scope controls. With ShareKYC you can share only the fields a given counterparty actually needs — name and date of birth to one, full document to another — with expiry, an access limit, download toggled off, and an audit log of who opened what. The minimization decision gets made once and then enforced by the share itself, instead of re-argued on every form.

That also changes the leverage. When you control the scope of the share, declining an unnecessary field is a setting, not a confrontation. The counterparty receives precisely the attributes you decided are necessary, and you keep a record proving what you disclosed.

There is a documentation benefit too. If a counterparty later over-retains or misuses what you sent, an audit log of exactly which fields you disclosed, when, and to whom is the evidence that turns a vague complaint into a concrete one. Minimization decided in your head leaves no trace; minimization enforced by a scoped share with a log is provable. When you exercise the rights covered in GDPR rights in KYC — access, erasure, objection — that record is what lets you state precisely what the institution holds rather than asking them to tell you.

Conclusion

Data minimization in KYC is a field-by-field discipline, not a slogan. Know the mandatory core — name, date of birth, address, nationality, document — provide it cleanly, and treat everything else as a request that needs a legal basis. Redact the document to match the purpose, calibrate against the real requirement set, and use a precise withholding script so refusals read as scoped rather than obstructive. If you would rather make the decision once and enforce it automatically, ShareKYC lets you share exactly the fields each counterparty needs and nothing more.