The 12-digit unique identity number issued by UIDAI (Unique Identification Authority of India). In CKYC submissions, Aadhaar is submitted as DocumentType 04. Under CKYCRR 2.0 and DPDP Act requirements, the DocumentNumber field must contain only the last 4 digits of the Aadhaar number. The document image must have the first 8 digits masked before base64 encoding. Submitting an unmasked Aadhaar is both a document validation failure and a compliance violation. See: CKYC Rejection Guide.

A static authentication credential required in the header of every CKYC API call, passed as api_key: your_api_key. Missing or invalid API keys return HTTP 400 with error: API Key required or error: Invalid API Key. The API key is issued by the CKYC service provider and must be kept confidential. See: CKYC API Integration Guide.

The method used to convert binary document files (photographs, Aadhaar scans, Passport copies) into ASCII text strings for transmission in JSON API payloads. In CKYC submissions, all documents in the files.Documents array must be provided as base64-encoded strings in the DocumentBase64 field. The total size of all base64-encoded documents in a single submission must not exceed 1MB.

The collective sector comprising banks, NBFCs, insurance companies, mutual funds, stock brokers, and all other regulated financial entities in India. All BFSI entities registered with CERSAI as Reporting Entities are obligated to upload customer KYC records to CKYCRR and comply with RBI's Master Direction on KYC and PMLA requirements.

The government-mandated body that operates the Central KYC Records Registry (CKYCRR) under the Prevention of Money Laundering Act (PMLA). CERSAI was originally established for maintaining security interests but was designated as the operating entity for India's centralised KYC system. It sets the technical specifications, validation rules, and operational requirements that all Reporting Entities must comply with when uploading and accessing CKYC records. See: CKYCRR 2.0 Guide.

India's centralised KYC framework that allows a customer to complete KYC once and have it recognised across all regulated financial institutions. Introduced under PMLA and operated through CKYCRR managed by CERSAI. Regulated by RBI for banks and NBFCs, SEBI for market intermediaries, IRDAI for insurance, and PFRDA for pension funds. The CKYC process involves Search, Download, Generation, Data Matching, and CKYC Number storage. See: Complete CKYC Lifecycle.

The technology infrastructure operated by CERSAI that stores, processes, and provides access to KYC records for all regulated entities in India. CKYCRR 2.0 is the upgraded version announced in Union Budget 2025 and built by Protean eGov Technologies under a Rs.161 crore government contract. It replaces batch SFTP uploads with real-time JSON API submissions and introduces AI-based biometric deduplication, mandatory Aadhaar masking, and OTP-based consent logging. See: CKYCRR 2.0 Complete Guide.

The address where a customer prefers to receive official communications, statements, and letters from the institution. In the CKYC API, CL fields include CL_Line1, CL_City, CL_Pincode, and CL_State_Code. If the CL address is the same as the CP address, set flag_indicating_if_cpi_address_is_same_as_cl_address to Y and leave CL fields empty — the system auto-copies. Contrast with CP Address.

The residential address where the customer currently lives or their permanent home address. In the CKYC API, CP fields include CP_Line1, CP_City, CP_District, CP_Pincode, and CP_State_Code. CP fields are always mandatory. An address change since the last CKYC registration is the most common cause of a Partial Match during data comparison. See: CKYC Lifecycle Guide.

The stage in the CKYC lifecycle where the record downloaded from CERSAI is compared against the data the customer provided during current onboarding. Produces one of three outcomes: Full Match (all fields align — store KIN immediately), Partial Match (one or more fields differ — trigger Update API), or No Match (no record existed — proceed to Generation). Data matching only applies on the Download path. See: CKYC Lifecycle and our detailed Data Matching guide.

The two-step API pattern used to retrieve an existing CKYC record from CERSAI when the Search API confirms a record exists. Step 1 is Download Initiate (POST /download-initiate) which triggers an OTP to the customer's registered mobile. Step 2 is OTP Validate (POST /validate-otp) which confirms consent and returns the full CKYC record. Under CKYCRR 2.0, the OTP consent step is mandatory and every consent event must be logged. See: API Integration Guide.

India's personal data protection legislation that governs the collection, storage, and processing of personal data of Indian residents. The DPDP Act intersects with CKYC compliance in the context of Aadhaar masking requirements — storing unmasked Aadhaar numbers in any system creates dual exposure under both PMLA/CKYCRR 2.0 and DPDP Act provisions. See: CKYC Compliance and Penalties Guide.

A declaration submitted by individuals who do not have a PAN card when entering into a financial transaction. In CKYC API submissions, when a customer does not have a PAN, the PAN_Card field must contain the exact string Form60 — not blank, not null, not any other value. Any other value in this field when no PAN is available will cause a validation rejection. Common in rural and semi-urban onboarding where PAN penetration is lower.

The data matching outcome where all key identity fields in the downloaded CKYC record — name, date of birth, PAN, address, and other core fields — align with the data collected during the current onboarding. On a Full Match, the CKYC number (KIN) can be stored against the customer record immediately with no further action required. Contrast with Partial Match.

The API pattern used to create a new CKYC record with CERSAI when no existing record is found. Called via POST /upload-data. Accepts a full KYC data package — identity fields, address, KYC verifier details, and base64-encoded documents. Returns HTTP 201 with a transaction_id on successful submission. Generation is asynchronous — CERSAI assigns the KIN after validation, which can take hours to days. The transaction_id must be stored and used to poll the Status API. See: API Integration Guide and Rejection Guide.

A category of NBFC specifically regulated by the National Housing Bank (NHB) that provides loans for home purchase, construction, and renovation. HFCs are Reporting Entities under CERSAI and are subject to the same CKYC obligations as banks and other NBFCs — including the 3-working-day upload deadline and periodic re-KYC requirements. HFCs often have large rural and semi-urban portfolios which present specific CKYC collection challenges around document quality and PAN availability.

The unique 14-digit number assigned by CERSAI to each customer when their CKYC record is first created. Also referred to as the CKYC Number or CKYC ID. The KIN acts as a universal KYC reference across all regulated entities in India — once a customer has a KIN, they should not need to submit KYC documents again at any CERSAI-registered institution. From January 2025, CERSAI migrated to a masked format for KINs. Systems must handle both legacy unmasked and new masked KIN formats. See: CKYC Lifecycle Guide.

The process by which financial institutions verify the identity and address of their customers before establishing a business relationship. KYC requirements in India are governed by RBI's Master Direction on KYC (for banks and NBFCs), SEBI circulars (for capital market intermediaries), IRDAI guidelines (for insurance), and PMLA Rules. CKYC is the centralised, once-for-all version of KYC applicable across all these regulators. Periodic re-KYC must be performed at risk-tiered intervals: 2 years (high risk), 8 years (medium risk), 10 years (low risk). See: RBI Penalty and Compliance Guide.

A financial institution registered under the Companies Act and regulated by RBI that provides financial services similar to banks but does not hold a banking licence. NBFCs include microfinance institutions, gold loan companies, housing finance companies (HFCs), asset finance companies, and others. All NBFCs registered with CERSAI are Reporting Entities with mandatory CKYC obligations including the 3-working-day upload deadline, periodic re-KYC, and CKYCRR 2.0 API integration requirements. See: Complete CKYC Lifecycle for NBFCs.

Under CKYCRR 2.0, before any institution can download a CKYC record from CERSAI, the system must send an OTP to the customer's registered mobile and validate their consent. Every such event must be logged with timestamp, customer identifier, institution code, employee or system identifier, and purpose. This log is mandatory for audit and must be queryable and exportable. Absence of OTP consent logs is one of the most common adverse findings in RBI CKYC audits. See: Compliance and Audit Guide.

The list of identity and address documents officially accepted for KYC purposes under RBI's Master Direction. Current OVDs include: Aadhaar Card (DocumentType 04), Passport (DocumentType 05), Driving Licence (DocumentType 06), Voter ID Card (DocumentType 07), and NREGA Job Card (DocumentType 08). PAN card is accepted as a standalone identity document but is not classified as an OVD. At least one OVD must be submitted as Proof of Address (POA) in every CKYC Generation submission. See: Rejection Guide for document requirements.

The 10-character alphanumeric identifier issued by the Income Tax Department of India. In CKYC submissions, the PAN_Card field accepts either a valid PAN in standard format or the string Form60 for customers without a PAN. The PAN is a primary deduplication key — if CERSAI's database contains an existing record with the same PAN, the Search API will return it. A PAN format error (lowercase, extra spaces, incorrect length) is a common data validation rejection cause.

The data matching outcome where one or more fields in the downloaded CKYC record differ from the current onboarding data. Common causes include address changes, name spelling variations, and updated marital status. On a Partial Match, the institution must trigger the CKYC Update API workflow with corrected data before storing the KIN. Storing a KIN without resolving a Partial Match through the Update API is a compliance violation and a common adverse audit finding. Contrast with Full Match. See: our Data Matching deep-dive guide.

The primary Indian legislation governing anti-money laundering obligations for financial institutions. The CKYC upload obligation flows from Section 12 of PMLA, which requires Reporting Entities to maintain KYC records and furnish information to CERSAI. Section 13 provides the penalty framework — up to Rs.1 lakh per day for continued default in CKYC obligations. All regulated financial entities — banks, NBFCs, insurance companies, mutual funds — are Reporting Entities under PMLA. See: RBI Penalty and Compliance Guide.

A document submitted to verify a customer's residential address in a CKYC submission. Accepted POA documents are OVDs: Aadhaar (Type 04), Passport (Type 05), Driving Licence (Type 06), Voter ID (Type 07), and NREGA Job Card (Type 08). POA is mandatory in every Generation submission. The most common document rejection reason is POA name mismatch — when the name on the POA document differs from the name entered in the form fields. See: Rejection Guide.

The central bank of India and primary regulator of banks and NBFCs. RBI's Master Direction on Know Your Customer (KYC) is the primary compliance framework for CKYC obligations in the banking and NBFC sector. RBI regularly updates this direction to align with PMLA amendments and CKYCRR changes. The January 2026 amendment introduced mandatory 3-notice re-KYC reminder frameworks. RBI's enforcement actions against KYC non-compliance are published publicly and carry both financial and reputational consequences. See: CKYCRR 2.0 Guide and Penalty Guide.

Any financial institution registered with CERSAI that is legally obligated to upload customer KYC records, conduct periodic re-KYC, and comply with the CKYC framework. As of 2024, there are 7,166 Reporting Entities registered with CERSAI across banking, NBFC, insurance, and capital markets sectors. Each RE is assigned a unique entity code by CERSAI used in API authentication and audit logging.

The code in the Residential_Status field classifying the customer's residential category. Allowed values: 01 Resident Individual, 02 Non Resident Indian, 03 Foreign National, 04 Person of Indian Origin. The vast majority of NBFC customers use 01. Any value outside these four codes returns a CERSAI rejection. See the API Code Reference infographic below.

The mandatory first API call in every CKYC flow, used to check whether an existing CKYC record is registered in CERSAI for a given customer. Called via POST /search with the customer's PAN or Aadhaar details. Returns the KIN if a record exists (status: true) or confirms no record (status: false). The Search API must always be called before Generation — submitting a Generation request for a customer who already has a KIN creates a duplicate record rejection. See: API Integration Guide.

The legacy method of submitting CKYC records to CERSAI through scheduled batch file uploads via SFTP. Under CKYCRR 1.0, this was the primary submission mechanism. CKYCRR 2.0 replaces SFTP batch uploads with real-time REST API submissions, with instant validation feedback. Institutions still running SFTP batch workflows must migrate to the real-time API model as CERSAI transitions fully to CKYCRR 2.0 through 2026. See: CKYCRR 2.0 Guide.

The API endpoint (POST /get-status) used to poll the result of a CKYC Generation submission. Since Generation is asynchronous, the institution must repeatedly call the Status API with the transaction_id received from the Generation submission until CERSAI assigns a KIN or returns a rejection. Recommended polling interval: every 30 minutes for the first 4 hours, then hourly for 48 hours, then daily until resolved. See: API Integration Guide.

A unique reference string returned by the Generation API on successful submission (HTTP 201 response). Example format: H_ZvU_896. The transaction_id must be stored persistently — it is the only reference for tracking the submission through CERSAI's processing queue and retrieving the KIN via the Status API. Loss of the transaction_id means the institution cannot track or retrieve the submitted record. Never store transaction IDs only in application memory.

The API pattern used to update an existing CKYC record when data in the downloaded record differs from the current onboarding data (Partial Match). Update submissions follow the same structure as Generation API calls but with the CKYC_ID field populated with the existing KIN. CERSAI guidelines prohibit direct overwriting of CKYC records — all updates must go through the authorised Update API flow. Storing a KIN without completing the Update API on a Partial Match is a compliance violation. See: our Data Matching guide.

The institution employee who physically verified the customer's KYC documents during onboarding. CKYC submissions require verifier details: kyc_verification_name, KYC_Verification_Emp_Code, KYC_Verification_Emp_Designation, and KYC_Verification_Emp_Branch. The KYC Verification Date must be on or after the Applicant Declaration Date. These fields ensure accountability in the KYC process and may be cross-referenced in regulatory audits. All these fields are mandatory — missing or invalid verifier details cause data validation rejections.