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
- Pages: Full AOF (Account Opening Form)
- Purpose: Account opening for customers whose data matches KRA registry
- Content: Complete account opening form — data already validated against KRA
- Post-eSign: NOT sent to KRA — retained internally for records only
- Trigger combinations: Row 10, and rows 3, 7, 9, 15 when data match passes
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.