Full Match vs Partial Match vs No Match: How CKYC Data Comparison Works in Practice
Every CKYC Download produces a data matching decision. Most operations teams know the three outcomes exist. Far fewer have a formalised, documented workflow for each one - and that gap shows up in audit findings, unresolved queues, and CKYC numbers stored incorrectly. This guide covers every decision point in detail.
- What Is Data Matching - And When Does It Happen?
- Which Fields Are Compared?
- Full Match - The Clean Path
- Partial Match - The Workflow Most Teams Get Wrong
- No Match - Not a Match Problem, a Generation Problem
- Decision Matrix and Workflow Diagram
- Common Partial Match Scenarios and How to Handle Them
- Who Owns the Matching Decision?
- Frequently Asked Questions
What Is Data Matching - And When Does It Happen?
Data matching is a specific stage in the CKYC lifecycle that only occurs on the Download path. It happens after a CKYC Search confirms a record exists for the customer and the Download API successfully retrieves the full CKYC record from CERSAI. At that point, the institution must compare the downloaded record against the data the customer provided during the current onboarding - and make a decision based on how well they align.
This step is frequently misunderstood or skipped. Some operations teams treat the Download as the end of the CKYC process - the record exists, we have the KIN, job done. That is incorrect. The downloaded CKYC record reflects what was submitted to CERSAI at some point in the past - often months or years ago. The customer's current data may have changed. The matching decision determines whether the KIN can be stored directly or whether a further step is required.
Which Fields Are Compared?
The comparison covers the core identity and address fields. A mismatch in any one of these qualifies the record as a partial match and triggers the update workflow.
Full Match - The Clean Path
A full match means every key identity field in the downloaded CKYC record aligns with the data collected during the current onboarding. The customer's name, date of birth, PAN, address, and other key fields are consistent between what CERSAI holds and what the institution has collected fresh.
This is the ideal outcome and the fastest path through the CKYC lifecycle. On a confirmed full match, the institution stores the CKYC number (KIN) against the customer record immediately, creates an audit log entry recording the match type and timestamp, and notifies downstream systems. No manual review is required.
Partial Match - The Workflow Most Teams Get Wrong
A partial match is the most operationally complex outcome. It means a CKYC record exists in CERSAI for this customer, but one or more fields in that record differ from the data collected during the current onboarding. The most common causes are address changes since the last KYC registration, name spelling variations between source systems, and customers who have updated marital status or obtained a PAN after a previous Form 60 registration.
A partial match does not mean the CKYC process fails. It means a specific update workflow must be completed before the CKYC number can be stored. The institution must trigger the CKYC Update API with the corrected data, or route the record to an authorised manual review workflow where the discrepancy is documented and resolved.
What the Update API Workflow Requires
When a partial match is identified, the Update API submission must include the existing CKYC ID (the CKYC_ID field which is mandatory for updates), all the corrected field values, and the supporting documents where the data change requires documentary evidence. The submission follows the same structure as a Generation API call but with the CKYC_ID field populated. CERSAI processes the update and returns a new or confirmed KIN once the update is accepted.
No Match - Not a Match Problem, a Generation Problem
Strictly speaking, No Match is not a data matching outcome - it is a Search outcome. When the CKYC Search API returns no record for the customer, there is no CKYC data to download and therefore no matching comparison to perform. The process moves directly to the Generation API path.
It is included here because operations teams frequently conflate it with the matching stage. The key distinction is: data matching only applies when a record has been downloaded. No Match means no download occurred, and the Generation path must be followed to create a new CKYC record with CERSAI. For the full Generation API process, see our CKYC API Integration Guide.
Decision Matrix and Workflow Diagram
The diagram below maps all three outcomes from the matching stage and the workflow path that follows each one.
| Outcome | Condition | Immediate Action | When KIN Is Stored | Audit Evidence Required |
|---|---|---|---|---|
| Full Match | All key fields match | Store KIN directly | Immediately | Match log with timestamp and match type |
| Partial Match | One or more fields differ | Trigger Update API or manual review workflow | After successful update resolution | Mismatch log, Update API submission record, resolution timestamp |
| No Match | No record in CERSAI | Proceed to Generation API | After KIN assigned by CERSAI | Generation API transaction ID, Status API KIN assignment record |
Is your data matching workflow formalised and auditable?
HSS's managed CKYC service includes automated matching logic, Update API submission, and full audit trail generation for every matching decision - removing the manual inconsistency that causes compliance findings.
Common Partial Match Scenarios and How to Handle Them
| Scenario | Field(s) Affected | Typical Cause | Update API Action |
|---|---|---|---|
| Customer has moved | CP_Line1, CP_City, CP_Pincode, CP_State_Code | Address changed since last KYC registration | Submit updated address with current address proof document |
| Name spelling variation | First_Name, Last_Name | Different spelling in source system vs CERSAI record | Submit corrected name with identity document showing correct spelling |
| PAN obtained after Form 60 | PAN_Card | Customer had no PAN at previous KYC, now has one | Submit PAN number with PAN card document in update |
| Marital status change | Marital_Status, Father_or_Spouse_First_Name | Customer married since last KYC registration | Submit updated marital status and spouse name with supporting document |
| Father name variation | Father_or_Spouse_First_Name | Different name format collected across branches | Submit corrected name - standardise collection format going forward |
| Mobile number mismatch | Mobile_Number | Customer has changed mobile since last CKYC | Submit updated mobile with OTP validation on new number |
Who Owns the Matching Decision?
Data matching is one of the most ownership-ambiguous steps in the CKYC lifecycle. Technology teams build the API integration. Operations teams handle the data. Compliance teams set the rules. In practice, matching decisions often fall into gaps between these functions - which is why inconsistent handling is so common.
Frequently Asked Questions
Automate Your CKYC Data Matching - End the Manual Queue
HSS's managed service handles every matching outcome automatically - full match storage, partial match Update API routing, and audit trail generation - with zero manual handoffs and full compliance documentation.
Talk to Our Team Explore Our ServicesThis article is for informational purposes only. For institution-specific compliance guidance, consult your legal and regulatory team.
