Loading...
compliance

Customer Identification Program (CIP) Verification Form

A Customer Identification Program (CIP) Verification Form for documenting identity checks, verification results, exceptions, and approval when opening a new financial account.

Trusted by frontline teams 15 years of frontline software AI customization in seconds

Built for: Banking · Credit Unions · Fintech · Brokerage

Overview

This Customer Identification Program (CIP) Verification Form records the identity checks performed when opening a new financial account and creates a clear audit trail for the review. It is designed to capture the submission notice, customer and account details, identity information collected, verification method and result, exceptions, and final compliance attestation in one structured record.

Use this template when your onboarding process needs to show what identity data was collected, which documents or identity elements were reviewed, who performed the verification, and whether any follow-up was required. The form is especially useful when account opening happens across multiple channels, because it keeps the same fields and review steps in place whether the customer applies online, in branch, or through an assisted workflow.

Do not use this form as a catch-all intake sheet. If the account type does not require CIP documentation, or if your process only needs a lightweight contact capture, this template may collect more than necessary. It also should not be used to store unrelated customer profile data, since the goal is data minimization and a focused compliance record. When verification fails or requires escalation, the Exceptions and Follow-Up section preserves the decision path instead of leaving the file incomplete.

Standards & compliance context

  • This template supports CIP documentation by creating a structured record of identity collection, verification, exceptions, and approval for new financial accounts.
  • The form aligns with GDPR Article 5 data minimization by limiting fields to the identity data needed for the stated verification purpose.
  • For any public-facing or customer-submitted version, the submission notice should disclose what data is collected, why it is collected, and what happens after submission.
  • If the workflow is used in a regulated onboarding process, the retention acknowledgement should match your institution’s recordkeeping policy and audit trail requirements.

General regulatory context for orientation only — verify current requirements with counsel or the relevant agency before relying on this template for compliance.

What's inside this template

Submission Notice

This section captures the purpose of the submission, who sent it, and when it was submitted so the record starts with a clear audit trail.

  • I understand this form collects PII for Customer Identification Program verification and compliance recordkeeping. (required)
  • Submission purpose
  • Submitted by (required)
  • Submission date (required)

Customer and Account Details

This section ties the verification record to the specific customer and account being opened, which prevents mismatches later in review.

  • Customer full name (required)
  • Date of birth

    Collect only if required by your institution’s CIP policy and applicable law.

  • Account type (required)
  • Account opening channel (required)
  • Internal customer or application reference (required)

Identity Information Collected

This section shows exactly which identity elements and documents were gathered, helping reviewers confirm the minimum necessary data was collected.

  • Customer type (required)
  • Identity elements collected for an individual
  • Identity elements collected for a business or entity
  • Identity documents reviewed (required)

Verification Method and Results

This section documents how the identity check was performed and what the outcome was, which is the core CIP decision record.

  • Verification method used (required)
  • Verification result (required)
  • Verification date (required)
  • Reviewer name (required)
  • Reviewer title

Exceptions and Follow-Up

This section explains any mismatch, missing information, or manual review path so exceptions are not lost in the file.

  • Reason for exception or unresolved mismatch (required)
  • Additional steps taken
  • Escalation required (required)
  • Escalation owner

Compliance Attestation

This section records the final CIP decision, retention acknowledgement, and approval so the file is complete for audit and oversight.

  • CIP verification completed in accordance with institution policy (required)
  • I understand this record will be retained as part of the compliance audit trail. (required)
  • Approver or compliance reviewer
  • Approval date

How to use this template

  1. Start by confirming the account opening request and capturing the submission notice, including consent acknowledgement, submission purpose, submitted by, and submission date.
  2. Enter the customer and account details exactly as they appear in the onboarding record, using the correct customer type and account opening channel so the rest of the form branches correctly.
  3. Collect only the identity elements and documents needed for the customer type, and use conditional logic to show individual or entity fields instead of exposing unnecessary fields.
  4. Record the verification method, the verification result, the verification date, and the reviewer’s name and title immediately after the identity check is completed.
  5. If anything does not match or cannot be verified, document the exception reason, the additional steps taken, and whether escalation is required, then assign the escalation owner.
  6. Finish with the compliance attestation, including the CIP compliance decision, retention acknowledgement, approver name, and approval date before closing the account-opening file.

Best practices

  • Mark only the fields that are truly required for the account type and verification path, and keep the rest optional.
  • Use date pickers for dates, dropdowns for account type and verification method, and multi-select fields for identity documents reviewed.
  • Apply progressive disclosure so individual and entity identity fields appear only when relevant to the customer type.
  • Record the verification result at the same time the review is completed so the audit trail reflects the actual decision, not a later reconstruction.
  • Include a clear submission confirmation line that tells the submitter what happens after they send the form and who reviews it next.
  • Document exceptions in plain language and avoid vague entries like 'pending' without a follow-up owner or next step.
  • Minimize PII by collecting only the identity elements needed for CIP and not adding unrelated demographic or marketing fields.

What this template typically catches

Issues teams running this template most often surface in practice:

Missing or incomplete identity documents reviewed fields.
Using free-text entries where a structured field or dropdown would make review easier.
Leaving verification result blank when the reviewer had to escalate or reject the submission.
Collecting more identity data than the account type requires.
Failing to name the reviewer, approver, or escalation owner.
Not documenting what additional steps were taken after a mismatch or exception.
Submitting the form after the account is already opened instead of during the onboarding review.

Common use cases

Retail Branch New-Account Representative
A branch employee opens a consumer checking account and uses the form to capture the customer’s identity elements, document review, and final approval. The structured fields help the branch team keep the record consistent across locations.
Business Banking Onboarding Analyst
An analyst reviewing an LLC or corporation account uses the entity identity fields, records the documents reviewed, and notes any escalation when ownership information is incomplete. The form keeps the entity review separate from individual customer intake.
Digital Account Opening Operations Team
An operations team handling online applications uses the template to document identity verification results from uploaded documents or electronic checks. Conditional logic keeps the form short for straightforward cases and expands only when a manual review is needed.
Compliance Reviewer for Exceptions
A compliance reviewer receives a file with a failed identity match and uses the exceptions section to record additional steps, escalation, and the final attestation. The form creates a defensible audit trail for the decision.

Frequently asked questions

When should this CIP Verification Form be used?

Use it when opening a new financial account that requires Customer Identification Program documentation. It is meant to record what identity information was collected, how it was verified, and who reviewed the file. If the account is not subject to CIP review, this form is usually unnecessary.

Who should complete and review this form?

The frontline employee or onboarding specialist typically completes the submission, and a compliance reviewer or designated approver confirms the final attestation. The reviewer should be the person accountable for the verification decision, not the same person who collected the data when separation of duties is required. If your process uses escalation, the escalation owner should be named in the form.

What identity information belongs in the form?

Include only the identity elements needed for the customer type and account opening channel, such as name, date of birth, and the applicable individual or entity identity elements. Record the identity documents reviewed and any reference number used to tie the submission back to the source record. Avoid collecting extra PII that is not needed for the verification decision.

How does this form handle exceptions or failed verification?

The Exceptions and Follow-Up section is where you document why verification could not be completed, what additional steps were taken, and whether escalation is required. This keeps the audit trail clear when documents are missing, information does not match, or a manual review is needed. It also helps prevent informal approvals that are hard to defend later.

What is the difference between this form and an ad-hoc checklist?

An ad-hoc checklist often misses key fields, creates inconsistent records, and makes it harder to prove what happened during onboarding. This template standardizes the submission notice, identity fields, verification method, exceptions, and compliance attestation in one place. That consistency supports cleaner review, easier audits, and fewer follow-up questions.

Can this template be customized for different account types or onboarding channels?

Yes. You can use conditional logic to show different identity fields for individuals versus entities, and different verification methods for branch, online, or assisted onboarding. You can also add channel-specific instructions, but keep the form focused on the minimum necessary data for the account type being opened.

How should this form integrate with other systems?

It works well with account-opening workflows, document management, case management, and audit trail systems. Store the form alongside the supporting identity documents and verification evidence so reviewers can trace the decision without searching multiple tools. If you use automation, map the reviewer, approval date, and exception status into your compliance record.

What are the most common mistakes when using a CIP form?

Common mistakes include marking every field required, collecting more PII than needed, failing to document the verification method, and leaving exceptions blank. Another frequent issue is not recording who approved the final result or what happened after a failed verification. A good rollout should train staff to complete the form at the time of onboarding, not after the account is already open.

Go deeper on the topic

Related concepts
  • Lockout/tagout (LOTO) is the procedure for controlling hazardous energy — electrical, hydraulic, pneumatic, mechanical, thermal, chemical — before...
  • Job hazard analysis (JHA) — also called job safety analysis (JSA) — is the structured exercise of breaking a work task into sequential steps, identifying the...
  • A near-miss is an event that could have caused injury or damage but didn't — a slip that didn't fall, a load that shifted but didn't drop, a machine that...
  • AI governance is the framework a company uses to decide what AI tools are allowed to do, who's accountable for their outputs, what data they're allowed to...
Related guides

Ready to use this template?

Get started with MangoApps and use Customer Identification Program (CIP) Verification Form with your team — pricing built for small business.

Ask AI Product Advisor

Hi! I'm the MangoApps Product Advisor. I can help you with:

  • Understanding our 40+ workplace apps
  • Finding the right solution for your needs
  • Answering questions about pricing and features
  • Pointing you to free tools you can try right now

What would you like to know?