How German Banks Should Normalise Names and Addresses Before Entity Resolution

TL;DR: German banks should preserve source names and addresses, apply defined Unicode normalisation, and test observed spelling variants on labelled records. Compare German street, house number, postcode and locality as separate address fields where supplied. A comparison variant is a candidate, not proof that two customers are one person.

Book a Demo to review the pipeline on your customer data, or Try Tilores Studio (Free) to test difficult variants locally.

On this page

1. Why should normalisation happen before matching?
2. Which German variants need explicit treatment?
3. How should a bank build the pipeline?
4. How should normalised fields enter matching?
5. Where do sanctions, PEP and adverse-media checks fit?
6. How do you test the result?
7. What do bank teams ask most often?

A bank rarely receives one clean spelling of a customer. A test set might contain “Müller”, “Mueller” and “Muller”, or “Hauptstraße”, “Hauptstr.” and “Hauptstrasse”; a name from another script might be recorded in more than one Latin spelling. These are examples to test against the bank’s own labelled records, not universal equivalence rules. None of those variations proves a match.

The implementation goal is therefore not to force every value into one supposedly perfect spelling. It is to make comparable representations while retaining what each source actually supplied. That distinction protects both recall and explainability. A pipeline should help the bank find plausible links without concealing how it reached them.

Why should normalisation happen before matching?

Computers compare encoded values, not visual impressions. Unicode normalisation gives canonically equivalent strings a unique binary representation. Applying a defined Unicode form early prevents some technically different encodings of the same visible text from creating avoidable mismatches. It does not solve transliteration, nicknames, typing errors or postal variation, so those concerns need separate transformations.

Address work needs the same separation of concerns. The UPU S42 model combines generic address components with country-specific templates. That is a useful architectural pattern for a bank: retain a common internal model, then apply rules and reference data appropriate to the country represented by the record.

The German Federal Network Agency describes an address as street, house number, postcode and locality. The Federal Statistical Office lists delivery postcode, street and house number in its municipal-address inventory, which is updated annually. A customer master is not a mail label; these official fields support a structured comparison while leaving identity to be decided from wider evidence.

Apply defined Unicode normalisation before candidate generation and scoring. Test any additional spelling or address variant as a separate, versioned hypothesis on labelled bank records, retaining the original field throughout.

Which German name and address variants need explicit treatment?

Start with an inventory of observed variation, not a universal replacement list. The bank should profile each source and record which transformations improve known links, which create false candidates and which require human review.

Variant class	Safe comparison treatment	Risk to control
Unicode composition	Apply one versioned Unicode normalisation form to a derived field.	Changing compatibility distinctions that the bank still needs.
Observed German spelling variants	Where the bank actually sees ä/ae, ö/oe or ü/ue, test separate comparison values on labelled cases.	Treating a tested candidate as automatic equality.
Observed ß and ss variants	Test them as separate candidate hypotheses while preserving the supplied spelling.	Collapsing unrelated names or identifiers.
Transliteration	If the input contains another script, compare only documented, versioned forms supported by the bank’s source records.	Combining different conventions without provenance.
Titles and particles	Parse them into explicit fields where the source permits.	Deleting meaningful parts of a family name.
Street fields	Keep street and house number distinct where supplied; test any abbreviated street spelling separately.	Losing house-number detail or assuming an abbreviation proves equality.
Postcodes and localities	Compare the supplied fields with an approved, dated reference where available; retain the recorded value.	Overwriting a historical or source-correct value without evidence.

The output should be several purpose-built fields, not one destructive “clean” value. A record might retain name_original, name_unicode, name_transliterated and name_phonetic. Address components can follow the same pattern. Every derived value should carry the transformation name and version that produced it.

Keep original records intact while testing reversible comparison checks. Distinct matching methods feed human review for uncertain links, with trace-back to the source.

How should a bank build the normalisation pipeline?

1. Preserve the source record. Store the original value, source system, source record ID and ingestion time before applying transformations. Tilores normalises and persists ingested data while retaining originals.
2. Apply safe character normalisation. Choose and version a Unicode normalisation form. Keep compatibility transformations separate where they could remove distinctions that matter to a customer identifier or legal name.
3. Create locale-aware name variants. Test separately versioned comparison values only for variation observed in the bank’s data, including case, spacing, diacritics or transliteration where relevant. Keep the source spelling and measure false links.
4. Parse and standardise addresses. Separate the supplied street, house number, postcode and locality, retaining any other supplied address fields and the raw input so an analyst can reconstruct the decision.
5. Match with distinct methods. Tilores keeps deterministic, fuzzy and probabilistic matching distinct. This prevents a close spelling score from being presented as if it were the same thing as a trusted identifier or a multi-field probability.
6. Validate with labelled bank cases. Measure false merges and missed links by source, variant type and downstream decision. Re-run the labelled set whenever a transformation, reference file or matching rule changes.

The pipeline also needs explicit failure behaviour. If an address cannot be parsed confidently, retain the raw value and mark the structured output as uncertain. If two derived forms disagree, expose both with their provenance. Silence is not a safe default because it makes later match evidence appear cleaner than it was.

How should normalised fields enter entity resolution?

Normalisation produces evidence. Entity resolution decides how much that evidence means. A bank can use a trusted customer number deterministically, compare spelling variation fuzzily, and combine several partial signals probabilistically. The thresholds and negative rules should reflect the consequence of a wrong link.

Method	Appropriate bank example	Required safeguard
Deterministic	The same trusted identifier from an authoritative source.	Confirm that the source guarantees uniqueness and ownership.
Fuzzy	Two close family-name or street-name spellings.	Require supporting fields and inspect common-name behaviour.
Probabilistic	Several partial agreements across name, date of birth and address.	Calibrate on labelled pairs and retain component evidence.

Use negative evidence as deliberately as positive evidence. Conflicting dates of birth, incompatible house numbers or a source-specific identifier assigned to another customer can block a tempting merge. A false merge can expose one customer’s data to another. For that reason, precision thresholds should be tied to the action that follows: search assistance, analyst review and automatic account consolidation should not share one threshold.

Once records are resolved, the live runtime interface is GraphQL, not REST or MCP. Downstream services should request the resolved entity and the evidence their workflow needs, while source records and transformation provenance remain inspectable.

Where do sanctions, PEP and adverse-media checks fit?

Screening is a separate risk-control process from identity resolution. The European Commission describes customer due diligence as identifying and verifying clients, monitoring transactions and reporting suspicious transactions. EU sanctions obligations are binding on EU nationals or people located in the EU or doing business here. Identity resolution can hand a traceable customer profile to the bank’s separate screening process. Those duties do not turn any one spelling variant into a confirmed identity match; the bank must validate the data and rules used in its separate screening process.

PEP and adverse-media checks also remain within the bank’s own risk process. The identity layer should preserve its source values and transformation history for handoff; the bank’s specialist teams set and validate screening inputs, sources and decisions.

Keep source and derived identity values traceable when sending the profile to a separate control. This article does not set sanctions, PEP or adverse-media screening rules.

How do you test whether normalisation is helping?

Build a labelled evaluation set from the bank’s own difficult cases. Include confirmed links, confirmed non-links and unresolved pairs. Cover every important source system and isolate variant families so the team can see whether a gain came from umlaut handling, transliteration, address parsing or another change.

Report precision and recall at the decision level, not only across all candidate pairs. The useful question is whether an onboarding duplicate check, customer-service search or screening handoff became safer. Review errors with data stewards who understand the source systems, then turn recurring findings into versioned transformations or matching rules.

Keep a regression set of near neighbours: customers in one household, common surnames in the same postcode, reused telephone numbers, changed addresses and names that transliterate to similar Latin forms. These cases reveal when a recall improvement has quietly increased false merges.

Finally, make rollback operational. Store the normalisation version, matching configuration and entity history used for each evaluation. A bank should be able to compare two configurations on the same records, explain cluster changes and restore the earlier behaviour if the new release crosses an agreed risk threshold.

What do bank teams ask most often?

Should a bank replace umlauts before matching names?

No. Preserve the supplied spelling. If the bank observes an alternate form, test it as a separate candidate on labelled records; do not treat it as automatic proof of identity.

Should Straße and Strasse always be treated as identical?

No. If both spellings occur in the bank’s records, test them as candidates while comparing the supplied house number, postcode, locality and other customer evidence.

Can a normalised name and address prove that two customers are the same person?

Usually not on their own. They create comparable evidence, but the final decision should combine stronger identifiers, field quality, source reliability and explicit matching rules.

Should sanctions and PEP screening use the normalised value or the original value?

There is no universal choice in this article. Preserve the source and derived identity fields, then let the bank’s sanctions and PEP teams validate their screening inputs and review rules.

Test the difficult records, not just the clean examples. Book a Demo or Try Tilores Studio (Free).

Sources

1. Unicode Normalization Forms, Unicode Consortium.
2. Addressing Solutions and S42, Universal Postal Union.
3. Stationary postal facilities: address fields, German Federal Network Agency.
4. Municipal address inventory 2026, Federal Statistical Office of Germany.
5. Anti-money laundering and countering the financing of terrorism at EU level, European Commission.
6. Overview of sanctions and related resources, European Commission.
7. Run Entity Resolution on Your Own Machine First, Tilores.
8. How to Query a Unified Customer Profile Through an API in Real Time, Tilores.
9. KYC and Compliance, Tilores.