Common KYC Data Quality Problems and How to Fix Them

Most KYC data quality problems fall into six groups: broken name formats, transliteration variance, missing or partial dates of birth, unstructured addresses, duplicate customer records, and stale data nobody refreshed. Each one causes a specific screening failure. A missed sanctions match, a flood of false positives, or a customer who exists twice in your system under two different risk ratings.

The failure happens before a compliance officer sees anything. If the name submitted to the screening engine is wrong, no threshold setting will save you.

Below is each problem, the screening failure it causes, and the fix that holds.

Name format problems

Name handling is the biggest source of screening error, and almost all of it comes from how the field was designed.

One field or several

A single free-text name field lets staff enter anything. “Smith, John A.” in one record and “John Smith” in the next. The matching engine sees two different strings. Split the field into given name, middle names and family name, and store the full name as a derived value rather than the source of truth.

This breaks in cultures where name order or structure differs. Many people have a single mononym. Spanish naming conventions use two family names. Some East Asian records place family name first. Forcing everyone into a Western template creates errors that look like customer mistakes but are yours. Keep a “full legal name as written” field alongside the parsed components and screen both.

Noise inside the name field

Titles, suffixes and corporate designators wreck match scores. “Dr”, “Mr”, “Jr”, “Ltd”, “Pte Ltd”, “GmbH”, “SARL”. A name field holding “PARAGON TRADING PTE LTD” scores poorly against a list entry reading “Paragon Trading”. Strip designators before matching, but keep the original stored. Truncation is worse still. A field capped at thirty characters silently cuts long company names in half, and nobody notices until the audit.

Extra characters count too. Double spaces, trailing whitespace, non-breaking spaces pasted from a PDF, and apostrophes that arrive as curly quotes in one record and straight quotes in another.

Transliteration and script variance

A name written in Arabic, Cyrillic, Chinese or Thai has no single correct Latin spelling. Romanisation depends on the standard used, the passport issuing authority, and sometimes the clerk. The same person can legitimately appear as Mohammed, Mohamed, Muhammad or Mohammad. Chinese names may arrive in Pinyin, in Wade-Giles, or in a Cantonese romanisation from a Hong Kong document.

Major sanctions lists handle this by publishing alternate spellings. An entry commonly carries a primary name plus several aliases and low-quality aliases. That helps only if your engine screens against all of them, and only if your own record is close enough to one of them to score above your threshold.

Three practical fixes. Store the name in its original script where the document provides it, in a Unicode field, not converted to question marks. Record which romanisation standard your capture process uses so the variation is at least consistent. Then test: take ten list entries with known alias spellings, load them as test customers with a different romanisation, and see whether your system flags them. That test tells you more than any vendor specification. If you are weighing tooling, the trade-offs between automated and manual screening come down largely to how well the engine handles this.

Dates of birth and identifiers

Date of birth is the field that turns a possible match into a resolved one. Without it, you cannot discount a common name, so the alert sits in the queue and the analyst has nothing to write.

Two failure modes dominate. The first is format ambiguity. A record showing 03/04/1978 means March in one country and April in another. Store dates in ISO 8601 format, as year-month-day, and validate on entry. The second is the partial date. Documents from some jurisdictions give only a year, or a year and month. Storing that as 01 January of the year creates a false precision that leads an analyst to discount a real match.

Build the field to hold a partial date explicitly and flag it. Sanctions list entries often carry ranges or multiple listed dates of birth for the same person, so your matching logic needs to treat a year-only value as overlapping rather than as a mismatch.

Identifiers have their own trouble. Passport numbers get typed with the issuing country omitted. Company registration numbers arrive with and without leading zeros, or with the registry prefix stripped. Store the identifier, the type, and the issuing jurisdiction as three separate fields. An identifier without a jurisdiction is close to useless for disambiguation.

Address data

Address is where country risk is decided, and it is usually the worst-structured field in the record.

The core fault is a free-text blob with the country buried inside it. Risk scoring then reads a country field that somebody filled in separately, and the two disagree. Separate country into its own field using ISO 3166 two-letter codes, not free text where “UAE”, “U.A.E.” and “United Arab Emirates” become three values.

Distinguish address types as well. Registered office, trading address, mailing address and beneficial owner residence are different facts with different risk meanings. A company registered in a low-risk jurisdiction that trades from a high-risk one is exactly the pattern your risk model should catch, and it cannot if you store one address.

Watch for the registered agent address shared by hundreds of entities. That is a signal, and it only surfaces if addresses are structured enough to group. It sits close to several of the red flags of sanctions evasion worth watching for.

Duplicates and fragmented records

The same customer exists three times. One record came from the web form, another from a legacy migration. The third was created by an operations user who could not find the first two.

Clutter is the smallest part of the damage. Each copy can carry a different risk rating, and a periodic review closed against one copy leaves the other two stale. Worse, a screening hit resolved on one record does not attach to the others, so the same alert reappears and gets cleared again by someone who never sees the earlier work.

Fixing this needs a master record with a stable internal identifier that never changes, and links from every source system to it. Deduplication rules should be conservative. Merging two genuinely different people because they share a name and a city is a worse outcome than leaving a duplicate in place. Require a human decision above a defined similarity score, and keep the merge history so the action is reversible.

Stale records and how fast data decays

Corporate data goes off quickly. Directors resign, shareholders sell, registered offices move, companies dissolve or get acquired, and trading names change without a registration change. A file verified two years ago describes a company that may no longer exist in that form.

Refresh cycles are set by risk tier rather than by convenience. What matters more is event-driven refresh. A change in ownership, a new director, adverse media, a change of address, or a transaction pattern that does not match the stated business should all trigger a review outside the cycle. Ownership changes deserve particular care, because a shift in shareholding can pull an entity into scope under ownership rules even when the entity itself is not listed.

Stale data also creates a screening obligation people forget. Lists change constantly. Screening a customer once at onboarding proves nothing about today, which is why rescreening frequency for suppliers and customers is a policy decision, not an operational detail.

Problem, failure and fix at a glance

Data problem	How it looks in the record	Screening failure it causes	Fix
Single name field	“Smith, John A.” beside “John Smith”	Missed match on name order	Split fields plus stored full legal name
Designators and titles	“PARAGON TRADING PTE LTD”	Score falls below threshold	Strip designators at match time only
Field truncation	Long company name cut mid-word	Entity never matches its listing	Raise field length, alert on truncation
Transliteration variance	Mohamed against Muhammad	Missed match or alert storm	Screen all aliases, store original script
Ambiguous date format	03/04/1978	Wrong discount of a true match	ISO 8601 storage, validate on entry
Partial date stored as full	Year only saved as 1 January	False precision clears a real hit	Explicit partial-date flag
Country as free text	“UAE”, “U.A.E.”, spelled out	Country risk scored wrongly	ISO 3166 codes in a fixed field
Duplicate customers	Three records, three ratings	Review closed on the wrong copy	Master record with stable identifier
Stale ownership	Shareholder register two years old	Owner listed since, never screened	Event-driven refresh and rescreening

Fix it at the point of capture

Cleaning data downstream is a treadmill. The durable fix is a written data standard applied where the record is created, plus validation that refuses bad input.

A workable standard specifies, for each field, the name, the type, whether it is mandatory, the permitted values, and the validation rule. Keep it to one page per entity type so people read it.

• Names stored as Unicode, no character stripping, no truncation, split components plus full legal name.
• Dates in ISO 8601, with a separate flag for year-only or year-and-month values.
• Country as an ISO 3166 code, selected from a list, never typed.
• Identifiers stored with type and issuing jurisdiction as separate fields.
• Address split into lines, city, region, postcode and country, with an address type attached.
• Every record carries a source field and a last-verified date.

Validation at entry does the heavy lifting. Reject a date of birth in the future. Reject a country code that is not on the list. Flag a name that is a single character or that contains a digit. Warn when a company name ends at the exact field limit, because that usually means it was cut. Getting them right during sanctions screening at customer onboarding is far cheaper than remediating later.

Measure data quality with a scorecard

“The data is messy” is not a management report. Run five measures monthly across the customer population and report them by risk tier.

1. Completeness. Percentage of records with every mandatory field populated. Count blanks, “N/A” and “unknown” as missing.
2. Validity. Percentage of values that pass their format rule, such as a real country code or a parseable date.
3. Uniqueness. Estimated duplicate rate from a similarity pass across name, date of birth and identifier.
4. Timeliness. Percentage of records verified within their risk-tier refresh window.
5. Consistency. Percentage of records where the same fact agrees across systems, for example country in the CRM and country in the screening file.

Add one control test that measures the outcome rather than the input. Seed a small set of test records built from known list entries, using alternate spellings, and confirm the system flags every one. Run it after any change to thresholds, list feeds or the matching engine. Keep the results, because they are evidence that the control worked on a given date. If you need a baseline, you can run a denied party screening check against current lists and compare the output to what your own system produced.

Remediation without stopping the business

A remediation project that tries to fix every record at once stalls. Sequence it.

1. Profile the population first and quantify the gaps before promising a completion date.
2. Fix the standard and the validation rules, so new records stop adding to the problem.
3. Remediate high-risk customers and any record with a screening alert history.
4. Work through medium risk, then low risk, in date order with the oldest first.
5. Rescreen every remediated record. A corrected name is a new name as far as the engine is concerned.
6. Record what changed, when and on what source, so the work is auditable afterwards.

Step five gets skipped constantly. Teams clean thousands of names and never put the corrected values back through denied party screening. The whole point of the exercise was to make those names matchable.

Keep the before and after values. If a regulator asks why a customer’s name changed in your system, the answer needs to be a documented remediation with a source, not an unexplained edit. Sound record keeping for screening makes that answer easy. For teams starting from scratch, Globalior’s free screening tool gives you a clean reference point to test your data against.

Key takeaways

• Screening failures start in the data layer, so tuning match thresholds cannot fix a name field truncated at capture.
• Keep the full legal name as written alongside parsed components, because parsing rules break on mononyms and on two-family-name conventions.
• Transliteration has no single correct answer, so store the original script and screen against every alias a list publishes.
• Store dates in ISO 8601 and flag partial dates, since a year-only value saved as 1 January clears real matches.
• Use ISO 3166 country codes in a dedicated field, and store registered and trading addresses separately.
• Duplicate records split risk ratings and review history, so build a master record and require human approval before merging.
• Rescreen every record you remediate, and keep before and after values with their source.

Frequently asked questions

What counts as poor KYC data quality?

Data that is incomplete, invalid, duplicated, inconsistent across systems, or out of date against its refresh cycle. In practice the common cases are blank mandatory fields, names entered in inconsistent formats, free-text country values, dates in mixed formats, and customer records that exist more than once with different risk ratings attached.

How does bad data cause false positives?

Missing discriminating fields are the main driver. If a record has a name and nothing else, every list entry with a similar name becomes a possible match that an analyst must review by hand. Populating date of birth, nationality and a jurisdiction-tagged identifier lets the engine and the analyst discount most of them quickly.

How do I handle names that do not fit first name and last name?

Store the full legal name exactly as it appears on the document, and treat parsed components as derived values rather than the record of truth. Allow a single-name entry without forcing a placeholder. Screen both the full string and the components, since list entries themselves vary in how they are structured.

How often should KYC data be refreshed?

Set the cycle by risk tier, with high-risk customers reviewed most frequently, and define event triggers that override the cycle. Ownership change, a new director, a change of address, adverse media and unusual activity should all prompt a review regardless of when the last one happened. Write the cycle into policy so it is testable.

Do I need to rescreen after fixing data?

Yes. A corrected name, a newly populated date of birth or a changed country all alter what the matching engine sees. Treat every remediated record as a new submission and put it through screening. Keep the result with its date and list version so you can show the check was performed after the correction.

Who owns KYC data quality?

It works best with a named owner per field rather than a single owner for everything. Operations owns capture accuracy, compliance owns the standard and the risk fields, and technology owns validation and storage. Without named ownership, data quality becomes everyone’s concern and nobody’s task, and the scorecard goes unread.

If you want help scoping a remediation or checking whether your current screening setup handles alias spellings properly, contact the Globalior team.