EKYC 3.0 — Stage 12: KRA Re-Check & Document Generation

Backend-Only Developer Implementation Guide • Mandatory CVL Re-Check + 18-Combination Document Type Matrix + PDF Generation for eSign
Stage ID: KRA_RECHECKED Trigger: Customer taps “Confirm & Proceed to eSign” BRD Section: 20 — Stage 12 Version: 1.0

Table of Contents

  1. Stage 12 Objective
  2. Preconditions
  3. Step 1: KRA Re-Check (CVL Call)
  4. Step 2: Document Type Matrix (18 Combinations)
  5. Step 3: Data Match Check
  6. Step 4: Three Document Types
  7. Backend Validations
  8. Existing Stored Procedure Mapping
  9. Error Codes
  10. Exit State
  11. Vendor & Integration Calls
  12. Database Tables
  13. Regulatory & Implementation Notes

1. Stage 12 Objective

Stage 12 performs a mandatory second CVL KRA call immediately before document generation. The customer’s KRA status may have changed between Stage 2 (initial check) and this point. The combination of the Stage 2 KRA status and the Stage 12 re-check status determines which document type to generate via an 18-combination decision matrix.

Three possible document outcomes: The matrix produces exactly one of three document types: New KRA PDF, KRA Modification PDF, or KRA Validated PDF. The generated PDF is then forwarded to the eSign stage for the customer’s digital signature.

This stage is the critical gateway between data collection and eSign — no document generation occurs without a fresh CVL re-check, and no eSign proceeds without a generated PDF.

2. Preconditions

Condition Required Value Notes
lead.state FINAL_VALIDATION All data collection stages (Stages 3–11) must be complete
KRA Re-Check Mandatory every time No caching allowed — fresh CVL call is required on every attempt
Customer action Taps “Confirm & Proceed to eSign” Explicit customer consent triggers the re-check + document generation pipeline
Stage 2 KRA status Must exist in kra_records Original KRA status from Stage 2 is required for the matrix lookup
All mandatory fields Populated Name, DOB, gender, marital status, addresses must be present for potential data match
No caching permitted: The CVL re-check is mandatory on every invocation of Stage 12. Even if the customer retries within seconds, a fresh CVL call must be made. Regulatory requirements mandate real-time KRA status at the point of document generation.

3. Step 1: KRA Re-Check (CVL Call)

CVL Re-Check Flow

1
Customer taps “Confirm & Proceed to eSign” — API receives the request
2
Validate lead.state = FINAL_VALIDATION — reject if preconditions not met
3
Fire CVL KRA API call with the customer’s PAN — 3-second hard timeout
4
If CVL responds within 3 seconds: parse raw code and map to NON_KRA, KRA_MOD, or KRA_VALIDATED
5
If CVL times out or fails: assign status API_DOWN
6
Store the raw code as kra_status_esign_stage in the database
7
Proceed to Step 2: Document Type Matrix lookup
3-Second Hard Timeout: The CVL call MUST complete within 3 seconds. Any timeout or network failure results in API_DOWN status. Do not retry — treat timeout as a valid matrix input and proceed with document generation using the API_DOWN row.

Raw Code Storage

The raw CVL response code from this re-check is stored as kra_status_esign_stage alongside the original Stage 2 raw code. Both raw CVL codes must be retained for 7 years per regulatory requirements. These codes serve as the audit trail proving which KRA status was active at the time of initial check and at the time of document generation.

Field Source Retention Purpose
kra_raw_code_stage2 Stage 2 CVL call 7 years Initial KRA status at onboarding start
kra_raw_code_esign Stage 12 CVL re-check 7 years KRA status at document generation time
kra_status_esign_stage Mapped from raw code 7 years Normalized status used in matrix lookup

4. Step 2: Document Type Matrix (18 Combinations)

The document type is determined by a cross-reference of the Stage 2 KRA status (6 possible values) and the Stage 12 re-check status (3 normal statuses + API_DOWN). This produces an 18-row decision matrix (the remaining 2 Stage 2 statuses — RESTRICTED and INVALID_PAN — never reach this stage).

Matrix Logic: The matrix is exhaustive and deterministic. Every valid combination of Stage 2 and Stage 12 statuses maps to exactly one document type. There are no ambiguous or undefined combinations once the customer reaches this stage.
# Stage 2 KRA Status Stage 12 Re-Check Status Document Type Notes
1 NON_KRA NON_KRA New KRA PDF Customer still not in KRA — new registration
2 NON_KRA KRA_MOD KRA Modification PDF Customer registered with KRA between Stage 2 and now, but data needs modification
3 NON_KRA KRA_VALIDATED Data Match Check Customer registered with KRA between stages — verify data match (see Step 3)
4 NON_KRA API_DOWN KRA Modification PDF Cannot confirm current status — safe fallback to modification
5 KRA_MOD KRA_MOD KRA Modification PDF Still requires modification
6 KRA_MOD NON_KRA KRA Modification PDF Status regressed — treat as modification
7 KRA_MOD KRA_VALIDATED Data Match Check Status improved — verify data match (see Step 3)
8 KRA_MOD API_DOWN KRA Modification PDF Cannot confirm current status — retain modification
9 KRA_VALIDATED KRA_VALIDATED Data Match Check Still validated — verify data match (see Step 3)
10 KRA_VALIDATED NON_KRA KRA Validated PDF Status regressed but was previously validated — use validated document
11 KRA_VALIDATED KRA_MOD KRA Modification PDF Status changed to modification required
12 KRA_VALIDATED API_DOWN KRA Modification PDF Cannot confirm current status — safe fallback to modification
13 API_DOWN NON_KRA New KRA PDF First check failed, re-check confirms non-KRA — new registration
14 API_DOWN KRA_MOD KRA Modification PDF First check failed, re-check shows modification needed
15 API_DOWN KRA_VALIDATED Data Match Check First check failed, re-check shows validated — verify data match (see Step 3)
16 API_DOWN API_DOWN KRA Modification PDF Both checks failed — safe fallback to modification
17 RESTRICTED Customer is blocked at Stage 2 — journey does not reach Stage 12
18 INVALID_PAN Customer is blocked at Stage 2 — journey does not reach Stage 12
Data Match Check rows (3, 7, 9, 15): When the matrix indicates “Data Match Check,” the system must proceed to Step 3 before assigning the final document type. The data match check may downgrade the result from KRA Validated to KRA Modification if any field mismatches.

5. Step 3: Data Match Check

The data match check is performed only when the Stage 12 re-check status is KRA_VALIDATED. It compares 6 fields between the customer’s application data and the KRA registry data. A single mismatch in any field downgrades the document type to KRA Modification PDF.

# Field Match Type Threshold Mismatch Action
1 Name Fuzzy match ≥ 70% similarity Below 70% → KRA Modification PDF
2 Date of Birth Exact match 100% Any difference → KRA Modification PDF
3 Gender Exact match 100% Any difference → KRA Modification PDF
4 Marital Status Exact match 100% Any difference → KRA Modification PDF
5 Permanent Address Fuzzy match ≥ 70% similarity Below 70% → KRA Modification PDF
6 Correspondence Address Fuzzy match ≥ 70% similarity Below 70% → KRA Modification PDF

Data Match Decision Flow

1
Retrieve KRA registry data returned by the CVL re-check response
2
Retrieve customer application data from leads and related tables
3
Compare all 6 fields using the specified match type and threshold
4
All 6 fields match: Final document type = KRA Validated PDF
5
Any single field mismatches: Final document type = KRA Modification PDF
Fuzzy Match Implementation: Name and address fuzzy matching uses NameMatchService (Levenshtein-based similarity scoring). The threshold is ≥ 70%. No Claude API integration — all fuzzy matching uses existing NameMatchService per Product team decision. Log the match scores for audit.

6. Step 4: Three Document Types

New KRA PDF

  • Pages: 5 pages
  • Purpose: Fresh KRA registration for customers not in the KRA registry
  • Content: KRA registration form with all customer-collected data
  • Post-eSign: Submitted to KRA for new registration
  • Trigger combinations: Rows 1, 13 in the matrix

KRA Modification PDF

  • Pages: Full AOF (Account Opening Form)
  • Purpose: Update existing KRA data with corrected/new information
  • Content: Complete account opening form including all collected data
  • Post-eSign: Submitted to KRA for modification
  • Trigger combinations: Rows 2, 4, 5, 6, 8, 11, 12, 14, 16, and data match failures

KRA Validated PDF

KRA Validated PDF is NOT submitted to KRA: Unlike the other two document types, the KRA Validated PDF is for internal record-keeping only. It is signed by the customer via eSign but is not transmitted to the KRA registry. Ensure the post-eSign workflow correctly routes based on document type.

7. Backend Validations

Scenario Validation Action Notes
CVL Timeout CVL does not respond within 3 seconds Assign API_DOWN and use the API_DOWN row in the matrix Do not retry — proceed with document generation using fallback row
PDF Generation Failure Internal PDF engine fails to generate the document Route to CS Journey (customer service manual path) Log the failure with lead ID and attempted document type
File Storage Failure Generated PDF cannot be saved to configured drive Route to CS Journey (customer service manual path) PDF generation succeeded but storage failed — do not regenerate
Duplicate CVL Call Prevention Multiple rapid taps of “Confirm & Proceed to eSign” Implement idempotency — return cached result if re-check already completed for this attempt Use request-level idempotency key to prevent duplicate CVL charges and duplicate PDF generation
Invalid lead state lead.state != FINAL_VALIDATION Reject with appropriate error Customer may be accessing an old session or out-of-order navigation
Missing Stage 2 KRA status No KRA record from Stage 2 found Reject — cannot perform matrix lookup without both inputs Should not occur in normal flow; indicates data integrity issue

8. Existing Stored Procedure Mapping

The following stored procedures from the existing system are mapped to Stage 12 operations. These represent the legacy logic that must be replicated or called in the new backend.

Stored Procedure Purpose Stage 12 Usage
USP_CHECK_KRAESIGN_PDF_SJET SP Check if KRA eSign PDF already exists Idempotency check — prevent duplicate PDF generation
USP_GET_EXTRACT_KRAPDF_DETAILS_SJET SP Extract customer details required for KRA PDF generation Gather all field values to populate the PDF template
USP_KRA_Get_PreESIGNFINAL_FILEPATH_INFO_SJET SP Retrieve pre-eSign final file path information Check existing file paths before generating new PDF
USP_CALL_KRAAPI_ONSUBMIT_SJET SP Invoke KRA API on form submission CVL re-check call orchestration
USP_INSERT_KRA_LOGS_SJET SP Insert KRA API call logs Audit logging for the re-check CVL call and raw codes
USP_EKYC_PDF_GET_TYPE_SJET SP Determine eKYC PDF type Matrix lookup — determines document type from the two KRA statuses
USP_KRA_PDF_GET_TYPE_SJET SP Determine KRA-specific PDF type Secondary type determination for KRA-specific document formatting
USP_BrokingPDFLastPage_SJET SP Generate the last page of the broking PDF Append final page with terms, declarations, and signature blocks
USP_ADD_PDF_PAGES_SJET SP Add pages to the PDF document Multi-page PDF assembly — combine all sections into final document
USP_KRA_INSERT_UPDATE_PreESIGNFINAL_FILEPATH_INFO_SJET SP Insert/update pre-eSign final file path information Persist the generated PDF file path for eSign stage retrieval

9. Error Codes

Error Code Trigger Customer Impact Backend Action
CS_AOF_FAIL PDF generation or storage failure Customer is routed to CS journey (manual processing) Log error details, mark lead for CS intervention, send CleverTap event for CS queue
CS Journey Routing: When CS_AOF_FAIL is raised, the customer cannot proceed to eSign digitally. The customer service team must manually complete the document generation and arrange an alternative signing process. Ensure the lead record captures the exact point of failure (CVL success but PDF fail, or PDF success but storage fail) to assist CS agents.

10. Exit State

Field Value Notes
lead.state KRA_RECHECKED New code uses KRA_RECHECKED; BRD references AOF_GENERATED — the new value supersedes
kra_status_esign_stage NON_KRA | KRA_MOD | KRA_VALIDATED | API_DOWN Mapped status from the Stage 12 CVL re-check
kra_raw_code_esign Raw CVL response code Unmapped raw code from the re-check — retained 7 years
final_kra_status Resolved KRA status after data match May differ from kra_status_esign_stage if data match downgraded the status
final_document_type NEW_KRA | KRA_MODIFICATION | KRA_VALIDATED The document type actually generated, after all matrix + data match logic
aof_path File path on configured drive Full path to the generated PDF for eSign retrieval
aof_generated_at Timestamp UTC timestamp of successful PDF generation
State naming note: The new codebase uses KRA_RECHECKED as the exit state. The BRD document references AOF_GENERATED. During implementation, use KRA_RECHECKED and document the mapping in the state transition table for cross-reference.

11. Vendor & Integration Calls

Vendor / System Purpose Timeout Failure Handling
CVL KRA Mandatory KRA re-check — fetch current KRA status for the PAN 3 seconds (hard) Timeout = API_DOWN — proceed with matrix fallback row
Claude API / AiNXT Data match comparison — fuzzy matching for name and address fields Configurable Fallback to local fuzzy match algorithm if AI service unavailable
Internal PDF Engine Generate the New KRA / KRA Modification / KRA Validated PDF Configurable Failure = CS_AOF_FAIL — route to CS journey
File Storage (Configured Drive) Persist the generated PDF to the file storage system Configurable Failure = CS_AOF_FAIL — route to CS journey
CleverTap Event tracking — document generated, CS journey routed, KRA status changes Fire-and-forget Log failure; do not block main flow
Zoho CRM update — lead status, document type, KRA re-check result Fire-and-forget Log failure; do not block main flow
Datalake Analytics ingestion — KRA status transitions, matrix outcomes, match scores Fire-and-forget Log failure; do not block main flow

12. Database Tables

Table Operation Key Fields Notes
aof_documents WRITE lead_id, document_type, file_path, page_count, generated_at Stores generated PDF metadata; one record per successful generation
kra_records READ WRITE lead_id, kra_status_stage2, kra_status_esign_stage, kra_raw_code_esign, final_kra_status, final_document_type Read Stage 2 status for matrix; write Stage 12 re-check results and final determination
leads READ WRITE lead_id, state, pan, name, dob, gender, marital_status Read customer data for CVL call and data match; write state transition to KRA_RECHECKED
document_path_info WRITE lead_id, document_type, file_path, storage_location Maps to USP_KRA_INSERT_UPDATE_PreESIGNFINAL_FILEPATH_INFO_SJET — file path for eSign retrieval

13. Regulatory & Implementation Notes

7-Year Retention Requirement: Both raw CVL codes (kra_raw_code_stage2 from Stage 2 and kra_raw_code_esign from Stage 12) must be retained for a minimum of 7 years. This is a regulatory mandate. Ensure the database archival strategy accounts for this retention period. Do not purge these records during routine data cleanup.
No Caching of CVL Re-Check: The CVL re-check must be a live API call every time Stage 12 is triggered. Do not cache or reuse a previous re-check result, even if the customer retries the same session within seconds. The only exception is the idempotency guard for duplicate rapid-fire requests from the same button tap (same request ID).
File Storage: Generated PDFs are stored on a configured drive (not a cloud blob store). The drive path is environment-specific and retrieved from configuration. Ensure the PDF engine writes to this configured path and that the eSign stage can read from it.
Matrix is exhaustive: The 18-combination matrix covers every possible pair of Stage 2 and Stage 12 statuses. Rows 17–18 (RESTRICTED, INVALID_PAN) are included for documentation completeness but will never be reached in practice because those customers are blocked at Stage 2. If any unmapped combination is encountered at runtime, log it as a critical error and route to CS journey.