A customer record can look complete and still leave the risk team with the wrong question. A verified email address does not establish who controls an account. A company registration does not explain beneficial ownership. A clean sanctions screen does not mean the customer profile deserves no further review.
This guide to customer due diligence is for teams building those checks into KYC, AML, fraud, and investigation workflows. The goal is not to collect every available data point. It is to gather enough reliable evidence to understand who the customer is, what risk they present, and when a human needs to look closer.
For software teams, the work begins with a practical constraint: the signals available at onboarding are usually incomplete. A name, email address, phone number, company identifier, device signal, or government document may each add context. None should be treated as proof in isolation.
What customer due diligence needs to establish
Customer due diligence is the process of identifying a customer, verifying relevant claims, assessing risk, and maintaining an appropriate level of oversight over time. The exact standard depends on the jurisdiction, the product, and the regulated activity. A marketplace, a payments provider, and a corporate banking platform will not ask the same questions.
Still, most programs need to answer a small set of connected questions. Is this person or organization real? Does the information supplied by the customer align with independent sources? Is the customer acting for themselves or on behalf of another party? Are there sanctions, politically exposed person, adverse media, fraud, or other risk indicators that require action? And does the relationship continue to make sense after onboarding?
The distinction between identity verification and due diligence matters. Verification tests a claim, such as whether a document is authentic or whether a phone number can receive a code. Due diligence puts that result in context. It considers ownership, geography, transaction purpose, linked entities, and observed behavior.
A good workflow makes that distinction visible. It stores the evidence used, the result returned, the time of the check, and the decision rule applied. That record is useful when a case is reviewed later by compliance, an auditor, or another investigator.
Start with the data you actually have
Design the workflow around the identifiers customers can provide and the identifiers your product can observe lawfully. For an individual, that may include full name, date of birth, residential address, email address, phone number, and document data. For a business, it may include legal name, registration number, jurisdiction, address, directors, shareholders, and declared activity.
Each identifier has different strengths. An email address may help reveal account history or associations in sources that support email based searches. A phone number can sometimes provide useful identity or location context. A company number can connect a submitted business to official registry details. Names are broadly available but prone to ambiguity, especially across common names, transliteration variants, and incomplete records.
This is why matching logic needs care. An exact match on a rare email address may be highly useful. A match on a common name and city is weaker. If your system presents both with the same confidence, it will push reviewers toward bad decisions.
Data availability also varies by source and geography. A result that is useful for one country may not exist for another, and privacy rules may affect which fields can be used for a given purpose. Treat coverage as a property of a specific dataset and use case, not as a global promise.
Match confidence is not risk confidence
Teams often combine these two concepts by accident. Match confidence asks whether a returned record likely belongs to the customer under review. Risk confidence asks whether the evidence supports a risk finding. They are separate.
For example, a possible match to a politically exposed person list might have low match confidence because the name is common and the date of birth is missing. The underlying source can still be credible. The correct outcome is not an automatic rejection or a silent pass. It is a case that requests stronger identifiers or routes to review.
Your interface and API response handling should preserve this uncertainty. Keep source details, matching fields, timestamps, and any provider confidence indicators available to the decisioning layer. Do not reduce every result to a single yes or no too early.
Build a workflow that escalates evidence
Most teams should not apply the most expensive or intrusive checks to every customer. A proportionate model is usually more effective. Low risk customers can move through standard due diligence, while cases with higher risk factors receive enhanced due diligence.
At onboarding, validate basic fields and collect only what the product and regulatory obligation require. Next, check identity evidence against appropriate sources, screen relevant risk lists, and assess the customer profile against your risk rules. If those results conflict, request more information or hold the account for review.
Enhanced due diligence is appropriate when the risk justifies it. Common triggers include high risk jurisdictions, complex ownership structures, unusual business activity, potential sanctions matches, exposure to public office, or material inconsistencies between submitted and external information. The response should be specific to the trigger. Asking for an explanation of source of funds may make sense in one case and be irrelevant in another.
A rules engine can handle clear outcomes, but it should not pretend to replace judgment. Define what causes an automatic pass, an automatic block where policy permits, and a manual review. Then give reviewers the underlying evidence rather than a label generated by a model they cannot inspect.
Use enrichment to resolve gaps, not manufacture certainty
External data enrichment is valuable when it gives your workflow more context around an identifier or entity. It can help connect a phone number, email address, name, social identifier, image, or company record to information that supports investigation and risk assessment.
The value comes from corroboration. Suppose a business applicant provides a company name, a director name, and a contact email. Registry information may confirm that the business exists and identify listed officers. An enrichment result tied to the email may reveal useful associations that warrant further review. A mismatch between the claimed director and available company information may justify an escalation.
That does not mean an enrichment result proves beneficial ownership, criminal conduct, or account control. It may be stale, incomplete, associated with another person, or drawn from a source that needs independent validation. Build policy around what a result can reasonably support.
For teams evaluating data sources, test real but appropriately authorized sample cases. Check the fields returned, geographic coverage, response consistency, latency, documentation quality, and how results can be retained or displayed. The IRBIS portal lets teams explore available endpoints, submit test requests, and inspect responses before deciding how a source fits their product workflow.
Keep source provenance in the case record
A reviewer needs to know more than that a score changed. They need to know which signal drove the change, when it was collected, and what it means. Record the query input, response reference where permitted, source date, matching rationale, and the action taken.
This discipline improves more than audit readiness. It helps product and data teams identify weak rules. If reviewers repeatedly dismiss a certain type of match, that is evidence the threshold, source selection, or presentation logic needs adjustment.
Make ongoing due diligence operational
Customer due diligence does not end after account creation. Customer information changes. Company officers resign. Sanctions lists update. Transaction patterns reveal risks that were not visible at onboarding.
The practical approach is event based and risk based. Refresh information when a customer changes key profile details, when new risk signals appear, when an account reaches a review date, or when activity triggers a monitoring rule. Higher risk relationships should generally receive more frequent scrutiny than low risk ones.
Avoid refreshing data simply because a calendar says so if the result will not affect a decision. Equally, do not wait for a scheduled review when a significant event occurs. The point is to maintain a current risk view that fits the service you provide.
For investigation teams, visual case work can help when the question involves relationships rather than a single record. IRBIS PRO provides a workspace for connecting search results, exploring relationships, and organizing findings. It supports analysis, not automatic conclusions.
Measure decisions, not just checks
A due diligence program can report impressive volumes while still creating unnecessary friction or missing meaningful risk. Measure how often automated outcomes are overridden, which sources lead to useful escalations, how long reviews take, and where customers abandon onboarding. Segment those results by market, customer type, and risk tier.
False positives deserve special attention. They consume reviewer time, delay legitimate customers, and can train teams to ignore alerts. But aggressively reducing them can create false negatives. The right balance depends on the harm your product is trying to prevent and the evidence available for each decision.
The most useful customer due diligence workflow is not the one with the most data. It is the one where every signal has a defined purpose, uncertain matches remain uncertain, and reviewers can explain why a customer moved forward, paused, or required more evidence.