Customer Identification Program, or CIP, is the identity proofing step that confirms a person or business is real and that the submitted details are valid. Customer Due Diligence, or CDD, goes further by assessing expected activity, risk level, and whether the relationship should be monitored more closely. CIP answers who the customer is. CDD answers how risky the relationship is.
How CIP and CDD differ in bank onboarding
CIP is the bank’s identity confirmation step: it verifies that the customer exists and that the submitted identifying details are credible enough to open the relationship. CDD starts after that and asks a different question, namely how the customer should be risk-rated, monitored, and reviewed over time. In practice, CIP is about establishing identity; CDD is about establishing risk appetite and ongoing oversight.
The distinction matters because onboarding is not one control. A file can satisfy CIP and still require enhanced CDD if the customer type, jurisdiction, ownership structure, expected transaction profile, or product use creates higher exposure. Conversely, a straightforward low-risk customer may pass CIP with a lighter CDD posture. The two steps share data, but they do not answer the same operational question.
For banks, CIP is usually the gate that prevents opening an account for a person or entity that cannot be reasonably identified. CDD is the layer that turns identity information into a relationship decision. That means CDD often uses CIP output as an input, then adds due-diligence factors such as beneficial ownership, purpose of the account, expected activity, and whether the customer requires enhanced monitoring.
Where CIP stops and CDD begins in onboarding workflows
CIP is typically front-loaded and deterministic. The institution collects required identifiers, verifies them against reliable sources or documentary evidence, and decides whether the applicant can be accepted as the named customer. That step is focused on identity validity, not business justification or behavioural risk.
CDD begins where identity alone is no longer enough. The bank uses the established customer record to assess whether the relationship fits the institution’s controls, products, and risk tolerance. In a banking onboarding flow, this is the point where screening results, customer type, ownership structure, geographic exposure, and expected account activity start to influence the level of review and the monitoring model.
Seen operationally, CIP reduces the chance of onboarding an impostor. CDD reduces the chance of onboarding a real customer under the wrong risk assumptions. The first protects against false identity; the second protects against misplaced trust.
Why the split matters for AML, KYC, and bank control design
The bank’s control design needs the split because KYC work is not effective if identity verification and risk assessment are blended into a single vague review. FATF Recommendations and AML/KYC guidance treat customer due diligence as a broader obligation than identification alone, and that distinction is what drives risk-based onboarding.
CDD becomes the place to capture whether the customer should be reviewed more deeply, monitored continuously, or assigned enhanced due diligence conditions. That matters because onboarding decisions affect downstream alerts, periodic review cadence, case handling, and whether the relationship can be justified under the institution’s policy. CIP by itself cannot support those decisions because it does not evaluate expected behaviour or relationship risk.
For institutions operating in Europe, EBA AML/CFT guidance reinforces that due diligence is part of a broader AML control framework, not a one-time onboarding check. The practical result is that a bank should be able to show both that the customer was identified and that the relationship was risk-assessed in a way that is consistent with policy and regulatory expectations.
Risk and Threat Considerations
When CIP and CDD are blurred, the main risk is control failure at the onboarding boundary. A bank may accept a customer whose identity is technically verified but whose ownership, purpose, or expected activity was never risk-scored properly, which weakens monitoring and can leave the institution exposed to abuse, evasion, or compliance findings.
Failure mechanism: Weak CIP can admit a false or unverified identity, while weak CDD can misclassify a real customer and leave the relationship under-monitored. In both cases, the bank inherits a customer record that looks complete on paper but does not support the level of control the relationship actually needs.
Impact: The practical impact is higher exposure to fraud, money laundering, sanctions evasion, account misuse, and remediation work later in the relationship. It can also create audit friction because the bank cannot clearly demonstrate why the account was opened or why the monitoring posture matched the customer’s risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-12 — Identity Proofing | CIP requires reliable identity proofing before account opening. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Bank customers are external users whose identity must be established. | |
| AU-6 — Audit Review, Analysis, and Reporting | CDD drives monitoring and review decisions over the life of the relationship. | |
| Recommendation — Apply IA-12 to verify customer identity before onboarding the relationship. Use IA-8 to authenticate external customers and validate their identities. Use AU-6 to review alerts and evidence that monitoring matches customer risk. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | CDD is a risk-based onboarding decision tied to the institution’s appetite. |
| ID.AM-01 — Physical Devices and Systems Are Inventoried | Customer records and onboarding evidence need clear inventory and traceability discipline. | |
| Recommendation — Define a risk strategy that sets when CDD must escalate beyond standard onboarding. Maintain a complete inventory of onboarding records and supporting evidence. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Onboarding decisions determine whether the customer should receive access to services. |
| A.5.16 — Identity management | CIP depends on identity management for establishing a valid customer record. | |
| Recommendation — Use access control rules to align account capabilities with verified customer status. Establish identity management procedures that support verified customer onboarding. | ||
| CIS Controls v8 | CIS-5 — Account Management | Onboarding and ongoing review are core account management activities. |
| Recommendation — Tie account creation, review, and deactivation to documented customer due diligence outcomes. | ||
Practitioner Guidance
What to verify: Treat CIP as a pass-fail identity gate and CDD as a separate risk decision. If a file “passes onboarding” but you cannot explain the expected activity, ownership structure, or trigger for enhanced review, the customer is not really CDD-complete even if CIP is done.
Decision rule: If identity evidence is weak, fix CIP first; if identity evidence is sound but the customer is complex, proceed to enhanced CDD rather than overloading the identity review with risk questions. That separation keeps onboarding decisions auditable and prevents teams from using a simple identity check as a substitute for risk analysis.
Practitioner takeaway: CIP confirms who the customer is, while CDD determines what the bank is willing to do with that relationship, and the most common failure is assuming one can stand in for the other.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?