KYC and customer master data

Identity is a relationship, not one row

A bank can identify a customer, verify evidence about that customer and maintain a record of the relationship. These are related jobs with different owners and timestamps. The customer master is the structured record used to connect products, accounts, cases and interactions. Know Your Customer (KYC) is the broader operational practice around understanding and maintaining the relationship. Customer due diligence (CDD) includes identifying and verifying relevant persons, understanding the nature and purpose of a relationship, and applying risk-based ongoing monitoring under the applicable jurisdiction's rules. A populated customer row does not, by itself, establish completed due diligence.

Consider a fictional bank, Willow. An individual opens a current account, later becomes a director of a small company that opens a business account, and signs for a family member's account. The same person has three relationships with different rights. A customer master may link these records, but it cannot treat ownership, control and authorized signing as the same role. A fraud model may legitimately compare the individual's own accounts. A business-account monitoring use may need the company's beneficial ownership and authorized persons. A credit model should not treat every linked account as the individual's assets.

The source of truth can be federated. An onboarding service may hold submitted identity evidence, a customer master may own an internal person identifier, a company registry feed may supply legal-entity facts, a compliance case system may own verification status, and a product platform may own account roles. A curated view should state which source owns each attribute, when it was verified, what was merely declared, and which changes are pending. A model should never equate "present in a data lake" with "verified."

The FATF Recommendations establish international standards that countries implement through their own frameworks. A banking course should distinguish those standards from local law and the bank's policy. For example, the FFIEC U.S. CDD examination material describes risk-based ongoing monitoring and updating customer information in its U.S. context. It does not make an identical workflow or threshold mandatory for every country.

The central AI question is what the customer record means at the model's decision time. A model can rank an alert only if it uses the correct person, entity, relationship and due-diligence state. A convenient, current composite profile can misdescribe an older decision after names, ownership or risk ratings have changed. The bank must preserve the decision-time view and later correction trail.

Customer master fields need status and provenance

A person record may include a legal name, other names, date of birth, address, residency, nationality, contact methods and bank identifier. A legal-entity record may include registered name, registration number, jurisdiction, legal form, registered address and status. The collection and lawful use of each field depend on local rules and purpose. An application form, identity document and authoritative register may disagree. The master should not choose one value without retaining source, verification state and effective date.

A field needs more than a value. For a customer address, record whether it is residential, registered, correspondence or business; whether it is declared or verified; the evidence and date; a valid period; and a pending-change state. A corrected address should not silently rewrite where the bank believed the customer lived at a prior screening event. For a name, transliteration and alternative-script representations may be necessary. Normalizing names for matching is a derived operation, not permission to erase the source spelling.

Contact details have a different status from identity evidence. A mobile number can be an authentication channel, a service contact and a fraud signal, but possession of the number is not proof of legal identity. A recent phone change might alter how a bank confirms a payment; it should not automatically change the customer's established identity. The model or workflow needs the change event and verified status, not simply the latest string.

A master record should distinguish an active customer relationship from an active account. A person may remain a customer after a product closes, and a legal entity may have several products with different lifecycles. A profile can be incomplete while an application is pending. A duplicate candidate is not a confirmed merge. Explicit states prevent downstream systems from treating a missing verification flag as "verified." If the bank has several customer IDs because of a merger, it should keep the crosswalk and its confidence rather than silently overwrite all history with one key.

Willow's analyst defines a "verified business address" feature for an alert triage model. The acceptance criteria say which legal entity it describes, the verification source, age limit under bank policy, effective period and action when evidence is stale. The feature value must be missing or explicitly stale when the source is no longer within that policy, not filled with a newly submitted but unverified address. A reviewer can then see exactly what the model knew.

Matching two records is a controlled decision

Entity resolution asks whether two records describe the same person or organization. Similar names, addresses, dates and identifiers are evidence; none is automatically conclusive across all contexts. Two relatives may share an address and surname. A corporate group may use similar trade names for distinct legal entities. One individual may have a corrected date of birth, a changed name or several scripts. The matching process should retain candidates, confidence, evidence, decision maker and reversal path.

A deterministic exact match can be useful for a validated unique identifier. It still needs source-quality checks and exception handling for transcription errors, reused identifiers, country-specific formats and migration keys. A probabilistic or machine-learning match can rank possible pairs for review, but a high score is not a legal finding that the records are one person. The harm of a false merge can be substantial: another person's transactions, credit history or compliance alerts may attach to the wrong profile. A false split can hide aggregate activity or give a customer inconsistent service.

Create a controlled merge record. It identifies the two source records, evidence used, affected products and downstream consumers, reviewer authority, effective time and retained alias keys. It should allow a correction or split without destroying the earlier association. When a merge changes a model feature, assess decisions made under both identities. Merely rerunning the feature today does not explain a previous payment intervention.

A test pack includes a near-match that should not merge, a legitimate name change that should link, a corporate parent and subsidiary that remain separate, a duplicate created by a channel retry, and a split after a mistaken merge. Test the behavior of fraud, AML and customer service consumers, not only the master-data interface. Does the alert queue gain or lose activity? Can the support agent see the correct case? Are decisions that used the old linkage discoverable?

An identity graph can represent persons, companies, accounts and relationships. Its edges need types and valid periods. "Controls company" differs from "director of" and "authorized signatory for." An inferred shared-address edge may help an investigator, but it should be labeled as inference and never silently promoted to verified beneficial ownership. A graph is useful only when its node identity and edge provenance can be challenged.

Due diligence is a lifecycle

Onboarding obtains and verifies information appropriate to the product, customer and applicable rules. It may establish expected activity and a customer risk profile. The relationship then changes: a new product, new ownership, altered business activity, changed address or unusual transaction pattern can call for review. The ongoing process should distinguish a scheduled policy review, an event-driven update, a customer-provided correction and an investigation. The FFIEC CDD manual describes event-driven updates from normal monitoring for U.S. banks; local requirements and bank policy determine the particular review cycle elsewhere.

A useful case status model separates requested, received, verified, rejected, expired, under review and approved. If a document upload succeeds, "received" is not "verified." If a reviewer resolves a discrepancy, the reason and evidence should be recorded. A model may help prioritize cases or flag inconsistent fields, but the compliance workflow owns the actual verification and risk-profile decision. The product system needs a reliable status feed and a clear fallback when that feed is unavailable.

Risk ratings also need their own definition and owner. A customer risk rating for money-laundering controls is not a probability of fraud or a credit score. It can incorporate jurisdiction, product, expected activity and other factors under a bank's approved method. A model may recommend reassessment, but it should not silently change a governed rating without the required authority. Store old and new ratings, evidence, effective time, approver and reason. A downstream consumer should know whether it is using the current approved rating or a candidate value.

Consider Willow's business customer whose ownership changes. The customer master receives a notification, but verification is still pending. A monitoring system may flag the change for compliance review. It must not claim the new owner is verified because a registry feed populated a name. Nor should it continue indefinitely with the old ownership as if no change occurred. The case status, risk decision and permitted account activity follow Willow's approved process and local obligations, not a generic AI prediction.

Beneficial ownership is a relationship with evidence

A legal entity has a registered existence, owners, controllers and authorized representatives. These can be different people. A director may manage the company without owning it. A shareholder may hold an interest through another entity. A person who signs payment instructions may not be a beneficial owner. A bank needs a dated ownership and control view with the source and verification state for each relationship.

The FATF guidance on beneficial ownership of legal persons discusses adequate, accurate and up-to-date information under Recommendation 24 and a multi-pronged approach for countries. It should not be misread as one global numeric ownership threshold for every bank's CDD. The U.S. FFIEC beneficial-ownership examination section describes a specific rule and exemptions. A bank must map the current local regime and customer type before implementing its collection workflow. This lesson deliberately uses no universal percentage.

For Willow, a company is 70% owned by Holding A and 30% by an individual. Holding A is itself owned by two people. A flattened list of direct shareholders is not enough to understand the people behind the structure. The bank records each ownership edge, percentage as reported, effective date, evidence and unresolved gaps. It also records control roles where the applicable method requires them. A derived ownership view should identify the calculation method and confidence; it must not label an unresolved natural person as verified.

Ownership changes can be reported late. If a new filing becomes available on 10 May but states an effective change on 1 May, a decision on 5 May may have used the prior verified view. The later update can affect current due diligence and trigger a retrospective review if policy calls for it. The original decision record should remain intact. Both valid time and time known to the bank matter. A model back-test that uses the later ownership as a 5 May feature is leaking future knowledge.

An AI tool may extract names and percentages from corporate documents, highlight inconsistent chains and propose questions for a reviewer. Optical character recognition and language models can misread tables, page references or indirect ownership. The tool should cite exact source pages, preserve original text, mark uncertainty and never convert an extracted line into a verified owner without the bank's review process. It can speed investigation, but the decision log must show what a human or approved system established.

Digital onboarding separates proofing from prediction

A digital channel can capture documents, compare identity attributes, validate a digital credential and evaluate fraud signals. These are different controls. A selfie or device score is not the customer's legal identity. A pass from a document-reading service does not necessarily establish that the applicant is the document holder. An applicant may be genuine yet fail a technology check because of camera quality or accessibility barriers. The workflow must distinguish capture quality, authenticity, binding to the person and any later account-use authentication.

The FATF Guidance on Digital ID asks users to understand assurance levels and assess whether a digital identity system is appropriately reliable and independent for its risks. The guidance is technology-neutral. The bank still applies its jurisdiction's identification and verification requirements. In the U.S., the FFIEC Customer Identification Program section describes risk-based procedures, including non-documentary methods for specified situations. These sources do not justify treating every biometric or digital-ID product as interchangeable.

An onboarding funnel needs more statuses than approved and rejected. An applicant can be invited, submitted, awaiting verification, referred, paused for an external service, withdrawn or finally declined under applicable policy. Each transition should carry a reason code and timestamp. A timeout should not be logged as "identity failed." A genuine duplicate application can be a customer retry after an uncertain screen, not attempted fraud. Product and compliance owners define what activities, if any, are permitted while a check remains pending.

A model that ranks applications for manual review should be measured against the correct denominator. Of 10,000 fictional applications, suppose 8,000 pass the approved verification process, 1,500 require review, 300 withdraw and 200 fail for stated reasons. The model sees all applications but is trained only on the 1,500 reviewed cases. It cannot claim an overall fraud rate by treating the other 8,500 as verified negatives. The bank needs mature outcomes, sampling and uncertainty about what was never investigated. These classroom figures are not a recommended threshold.

Watch for feedback loops. If a model sends one channel's applications to more review, that channel produces more confirmed anomalies simply because staff look harder. A later model may learn to distrust the channel. Validation should compare observed labels with investigation coverage, investigate missing outcomes and test impact by relevant customer groups where lawful. A device change, disability-related interaction pattern or low-quality camera should not silently become a proxy for bad intent. Use a human route and correctable evidence when the technology is uncertain.

Monitoring needs dated expectations

CDD often establishes an understanding of a relationship's nature and purpose. That may include the customer's business, product, expected activity or source of funds information when relevant under applicable policy. Transaction monitoring compares observed activity with risks and context; it does not prove that activity is illicit because it differs from an expectation. A profile may be stale, overly broad or wrongly linked. Alerts require investigation and documented disposition under the bank's process.

The FFIEC CDD material addresses ongoing monitoring for suspicious transactions and risk-based maintenance of customer information in the U.S. context. A customer-master design should expose the expected-activity version, approved risk rating, last review, material-change flags and any open update case. It should not let a pending, unverified statement overwrite the approved view. An analyst needs both the old and candidate values to understand the alert.

Suppose Willow's company was expected to receive domestic wholesale payments, then starts receiving many cross-border transfers. That change may reflect legitimate expansion, a source classification problem or activity needing investigation. A model can rank the cases for staff, but its score cannot settle the question. The reviewer checks the actual transactions, current business evidence, ownership and policy. If the business profile changes legitimately, the bank updates it through the authorized process. It preserves why previous alerts were generated under the earlier profile.

The timing of updates matters. A case opened in June may examine May transactions using a business profile that was approved in April. If a July review changes the profile, a replay of the May alert must still show April's approved state, while the investigator can see the later fact. A model that uses today's profile for historical training might appear to predict the past with information not known then. The feature store needs the accepted effective date and the date the bank learned it.

A risk profile should not become a black-box "suspicious customer" badge on a service screen. Staff need to know which information they are authorized to use and what an open investigation does or does not establish. Customer communication must avoid disclosing restricted investigative details, while ordinary service and correction channels remain workable. Access controls and purpose limitation are part of the data product, not a later interface decoration.

Privacy, purpose and access constrain reuse

Identity files can contain high-sensitivity personal information. A bank may need them for identification and due diligence, but that does not authorize their unrestricted use in credit, marketing or a general-purpose assistant. Each new model use should identify its lawful basis or other applicable permission, allowed purpose, data minimization, retention, transfer and access rules for the relevant jurisdiction. These are legal and policy determinations, not properties inferred from a database schema.

Feature engineers can often work with a derived, approved status rather than raw document images or identity numbers. A fraud feature might need "contact detail changed in the last seven days" rather than the phone number itself. An AML reviewer may need controlled access to a beneficial-ownership document that a servicing assistant must not see. A model developer may need pseudonymized histories; pseudonymization does not make the data public or remove re-identification risk when records can still be linked.

Document provenance also protects against prompt injection and unsupported claims. A retrieved company filing or customer email may contain statements that instruct an AI assistant to ignore its rules. It is source data, not operational authority. A generative assistant should cite retrieved evidence, separate extracted facts from inference and operate behind tool permissions. It should not create or merge customer profiles, change a risk rating or send a customer message solely because a document says to do so.

Retention needs a usable evidence trail. The bank may retain an identifying record or a description of how it verified identity for the legally required period, subject to jurisdiction and product. It may also need to preserve the version of a customer fact used in a decision while correcting the current profile. These duties can coexist with rights to correction and data minimization; the precise balance requires the bank's privacy and legal review. Avoid copying documents into every feature pipeline as an easy way to preserve evidence.

A customer correction should produce a controlled chain. The customer reports an incorrect address. The bank authenticates the request, assesses the evidence, updates the authoritative field, publishes a dated event and identifies affected consumers. A prior screening result is not silently recalculated as if the new address had been known. If the error materially affected a customer outcome, the owner investigates remediation under applicable rules. The service team should be able to explain the current state without revealing confidential monitoring or third-party information.

Cross-border groups need extra care. A global customer ID may connect relationships in several jurisdictions, but data transfer and local retention rules can differ. A branch's "resident" field can have a different basis from another branch's tax residence field. A global risk feature that copies a locally collected field without its purpose, source and meaning can create a false equivalence. The bank can share permitted derived indicators with provenance while keeping restricted source evidence under appropriate controls.

Quality measures should reflect identity harm

Customer-master quality is not one completeness percentage. Measure duplicate candidates, false merges, unresolved splits, missing verified identifiers, stale or conflicting attributes, unlinked accounts, expired evidence and late updates. Break measures down by product, channel, entity type and source. A 99% match rate may still be unacceptable if the 1% contains high-impact false merges. Sample records against independent evidence and inspect customer complaints, not only automated validation outcomes.

Some defects are visible at onboarding; others appear months later. A customer's name may be transliterated differently across a card and deposit system. A legal entity may change control and only one product feed receives the update. A customer-service agent may see the new address while a screening service still sees the old one. Cross-system reconciliation should compare identifiers, relationship roles, effective dates and status, then assign mismatches to an owner. Counting discrepancies without a repair path leaves models exposed.

Define a source contract for each material attribute: canonical business meaning, source, possible states, quality rule, freshness, permitted uses and correction process. A generic "KYC status" flag may compress too much. Is it identity verification, CDD review, beneficial-ownership verification, sanctions-screening result or an overall onboarding gate? A model consuming the flag should receive the specific status it needs and distinguish pending, failed, expired and not applicable. Unknown should never quietly become passed.

A quality issue needs a consequence tier. An outdated correspondence address may affect a marketing message but not an established account identity. A conflicting legal-entity identifier can be a stop condition for a new high-impact relationship. An unavailable risk-rating feed may require an approved fallback for transaction monitoring. The bank's policy defines the tier; a data team should not invent the decision during an outage. Document which consumers are paused, degraded or notified when a source fails.

The customer should have a practicable route to correct information. A wrong merge can expose another person's account details and create incorrect interventions. A correction process must authenticate the requester without compounding the error, separate the profiles, reconcile affected systems and review decisions made while merged. Operational metrics should track time to resolution, repeat contact and cases reopened after a supposedly complete fix. Privacy and accuracy meet in the same customer journey.

Model uses need separate labels and owners

Identity resolution, document extraction, customer risk scoring and suspicious-activity alert ranking are different AI uses. An identity matcher proposes that two records refer to one person. A document extractor converts text or an image into candidate fields. A CDD risk model may rank relationships for review. A monitoring model prioritizes alerts. Their targets, test data and acceptable errors differ. A single "KYC AI accuracy" metric hides the consequences of each component.

For document extraction, compare candidate fields with independently reviewed source evidence. Measure omissions and wrong values by document type, language, layout and scan quality. A high average extraction rate may hide poor performance on documents used by a small but important customer group. The system should show the exact page or region supporting a field and route uncertainty to review. A fluent summary of a filing does not verify a beneficial owner.

For identity matching, measure false merges and false splits on a labeled sample that includes hard negatives, name changes, multiple scripts and related companies. A threshold is an operational policy choice. If the model automatically merges above a score, the bank needs stronger evidence and a reversal path than if it merely queues suggestions. Training labels derived from old manual decisions may contain earlier mistakes. An independent reviewer should examine disagreements and the possible harm of a false link.

For customer risk review, a model score is a recommendation until the authorized process changes the official rating. Validation should test whether the training labels are stable and what they represent. An earlier high rating may reflect a jurisdiction or product rule, not an observed crime. A model trained to imitate those ratings should not be described as predicting money laundering. The bank should document the target, limitations, fairness considerations and how staff challenge a suggestion.

For alert ranking, the observed outcome depends on which cases were investigated. A low-ranked case that nobody examined cannot be assumed benign. Preserve mandatory monitoring and reporting processes. Evaluate capture and workload on dated cohorts, including missed high-harm cases and investigator capacity. An alert score should not appear in a service screen as a finding against the customer. The model's job is to allocate review attention under controlled coverage, not to declare guilt.

These components can share identifiers and evidence services without sharing one approval. A new extraction model should not silently change the verified master. A changed matching threshold can alter every downstream feature. A new alert ranker should not rewrite the customer risk profile. Each release needs a clear owner, independent challenge proportionate to use, monitoring, fallback and an impact query for customers whose data or action changed.

Keep screening and identity outcomes distinct

A bank may screen names and related parties against sanctions lists or other watchlists as part of its applicable controls. A potential name match is a screening alert, not proof that the customer is the listed person. The matching data can include names, aliases, dates and jurisdictions, but a false association may still be harmful. Investigators need source-list version, customer identity evidence, matching fields, alert time and disposition. The official list, local legal obligations and bank process determine the required action. A generic customer-master "sanctions status" should not hide the difference between no alert, possible match, confirmed match and a technical screening failure.

A customer can also pass identity verification yet require more due diligence about a business relationship. Conversely, a CDD review can be overdue while a prior identity record remains valid. A service screen should not convert one control's status into an overall "safe customer" label. If a model uses screening results, it needs dated, appropriately authorized outcomes and should avoid treating unreviewed alerts as confirmed positives. An alert created because a common name resembles a list entry is a poor ground-truth label for supervised learning.

A screening system and customer master should reconcile identifiers and updates. If a customer changes name, the screening workflow may need to process the new and prior names under policy. If a company adds a beneficial owner, that person's status may affect relevant screening or monitoring. A delayed master-data event can leave the control using an outdated relationship. The integration test should measure propagation, detect unprocessed changes and expose exceptions. A data-quality check should not claim the customer is cleared when the screening service is unavailable.

The same separation applies to politically exposed person (PEP) indicators and adverse information. Their definitions, review consequences and retention are jurisdiction- and policy-specific. An unverified third-party hit is not an established customer fact. A model may prioritize a review, but staff must be able to inspect sources and correct false links. Do not let a generated summary promote a possible match into a definitive risk rating.

A worked relationship change

Willow's fictional business customer, Cedar Tools, has two approved representatives. A third person submits a request to change the registered address and add a new payment signatory. A document-extraction service reads a board resolution, while a registry feed still shows the previous address. The bank cannot treat the extraction as an approved mandate. It records the request, source document, submitted facts, identity and authority checks, conflicting registry value, reviewer decision and effective time.

Before approval, the payment service continues to apply the currently authorized signatory list under Willow's policy. A case tool may display the proposed person with a pending label to reviewers but must not expose that person as an authorized initiator. If a payment request arrives in the person's name, the system applies its normal authority check. A model's confidence that the document "looks genuine" cannot replace a controlled mandate update. If the bank permits some provisional activity under its actual rules, those conditions must be specified; this example assumes none.

The change can affect several consumers. Customer service needs the accurate request status. The account platform needs the approved signatory update when effective. Screening or monitoring may need the new relationship under its own controls. The data warehouse needs both the old and new views for historical analysis. A model feature counting "authorized persons" should move from two to three only when the approved relationship is effective and available to the feature service. Any earlier score retains the old count.

Suppose the registry address is updated three days later. The bank can reconcile the discrepancy and record that the later source supports the approved change, or it can investigate if the information conflicts. It should not backfill an earlier model input as if the registry had already agreed. The evidence log states the source, receipt time, verification and approval. A later investigator can separate a temporary source lag from a wrong authorization.

Now add a difficult branch: the resolution names the proposed signatory with a name similar to an existing customer but a different birth date. Entity resolution produces a candidate match. The reviewer rejects the match after checking the evidence, creates or links the correct person under Willow's process and records why. The rejected candidate should not leave a hidden edge in the customer graph. A downstream case or feature must not blend the two people's activity.

Acceptance cases for a BA and tester

A business analyst can turn Cedar Tools into testable requirements. The submitted change has a unique request ID and version. Each person-entity link has a role, source, verification state, effective date and approval. The current customer view clearly separates approved from pending values. An extracted field is labeled candidate until checked. A conflicting external source creates an exception with an owner and resolution, not a silent overwrite. The account authority service consumes only the approved signatory record.

Test a valid name change for an individual, a legal entity with layered ownership, a signatory who is not an owner, a duplicate application after a timeout and an incomplete document. Test the same identity appearing in two scripts. Test an ownership filing received after its effective date. For each case, assert the master identity, relationship edges, case status, downstream decision and replay at the prior date. Expected outcomes must come from bank policy and local rules, not from the model output.

Test an unavailable registry, a stale document, a failed extraction, an unreviewed candidate match and a quality feed that claims success but omits records. A safe failure is an explicit pending or exception state with the approved fallback. A test should fail if a blank verification flag becomes approved, if a model silently merges customers, or if a newly submitted signatory can act before authorization. Check that retries do not create duplicate relationships and that a reversal or correction retains history.

Operations needs a queue and escalation plan. If onboarding volumes rise, a model can prioritize review but cannot make mandatory checks disappear. Measure aged pending cases, time to customer resolution, false interventions, corrected merges, case quality and staff capacity by channel. A dashboard should distinguish a failed verification from an uncompleted verification. A complaint about an inaccurate profile should reach a correction owner with the authority to investigate across systems.

The release record should pin the customer-master mapping, model or extraction version, rule and threshold, eligible population, approved uses and fallback. A reviewer should start from one customer-facing event and recover the sources, relationship version, verification outcome, model suggestion, human approval and actual account action. If that chain breaks, the bank has a data and control problem even when its model metrics look strong. Accurate customer identity is the condition under which a model's other signals can be interpreted safely.