Generated: 2026-04-01 | Old: SignatureAPI.cs, PersonalRespository.cs, NomineeDetailsRepository.cs, NRIPersonalRespository.cs, NRINomineeRepository.cs, NRISegmentRepository.cs + SPs | New: SignatureService.cs, PersonalDetailsService.cs, NomineeService.cs, NriValidationService.cs
Stage 8 (Signature): Core flow (signature capture, base64 validation, attempt limits, S3 storage, STP/NON_STP scoring, service-unavailable fallback, DocumentPathInfo record) is PRESENT in new code. New code uses ISignatureValidationProvider abstraction instead of vendor-specific AINXT/CAPS APIs. Key gaps: CAPS vendor integration, AiNXT auto-crop endpoint, wet sign vs digital sign vendor toggle (GET_SETTINGVALUE_WETSIGN), PAN sign present check, EQUITY_AFTER_MFD flag on CAPS response, NRI-specific signature flow, base64 storage in DB (old stores in TBL_AINXT_SIGN_RESPONSE / TBL_CAPS_SIGN_RESPONSE), joint account/holder type support.
Stage 9 (Personal/Nominee): Core flow (personal details save/update, lookup validation, F&O segment auto-enable, PEP check, Account Aggregator stub, NRI FATCA, nominee CRUD with 3-max/100% share validation, minor guardian, no-nominee declaration) is PRESENT. Key gaps: dropdown master multi-table return, father/spouse name split logic, marital status change SP, segment selection SP (Equity/Derivative/Currency/Commodity as separate call), KRA address check, MFD customer auto-skip-cheque, SuperApp cloud push, witness details (name/PAN cross-validation), nominee suspicious phone/email check, nominee PAN verification via Hyperverge, restricted email domain check, NRI nominee identity proof fields, NRI segment custodian code, NRI nominee DB validation SP, BSDA scheme, DIS booklet/DDPI, settlement cycle, operation mode, minor personal details flow.
| # | Old Function / Logic | Old File | New Equivalent | Status | Gap Details |
|---|---|---|---|---|---|
| 1 | AiNXT signature validation API call (SignatureValidateApi) with isdigital flag, sign_label, data_status response parsing | SignatureAPI.cs:40-112 | SignatureService.ValidateSignatureContentAsync → ISignatureValidationProvider.ValidateSignatureAsync | PRESENT | New uses provider abstraction. AiNXT-specific request/response shape must be implemented in concrete provider. isdigital flag mapped from UPLOADED method. |
| 2 | CAPS signature validation API call with x-api-key + authorizationtoken headers, different response shape (sign_label, status, remark) | SignatureAPI.cs:115-178 | No CAPS-specific provider implemented | MISSING | Old had two vendors: AiNXT (primary) and CAPS (secondary). New code has single ISignatureValidationProvider. CAPS provider class needs to be built. |
| 3 | AiNXT auto-crop signature endpoint (SignAutoCrop) returning binary_string of cropped image + binary_status | SignatureAPI.cs:180-270 | Not implemented | MISSING | Auto-crop was a separate endpoint that returned a cleaned/cropped base64 image. New code does only validation, no crop. If needed for document generation, add as provider method. |
| 4 | Wet sign vs digital sign vendor toggle via GET_SETTINGVALUE_WETSIGN_SJET (returns AINXT or CAPPS based on user/setting) | GET_SETTINGVALUE_WETSIGN_SJET | No vendor selection logic; single provider injected via DI | MISSING | Old SP had user-level routing to AINXT or CAPPS. Currently hardcoded to return AINXT. New code should support provider selection via config or feature flag. |
| 5 | PAN sign present check (USP_CHECK_PANSIGNPRESENT_SJET) - checks TBL_CLIENT_PROOFUPLOAD for PANSIGN/CHEQUESIGN, cross-references OCR PAN signature response | USP_CHECK_PANSIGNPRESENT_SJET | Not implemented | MISSING | Old checked if PAN card image has extractable signature and if cheque has signature. Used to decide if user needs wet sign. New code always requires signature capture. |
| 6 | Signature attempt limit enforcement | SignatureAPI.cs + SP logic | SignatureService: _maxSignatureAttempts (config, default 3), attempt tracking on SignatureVerification entity | PRESENT | Well implemented with configurable max from Journey:MaxSignatureAttempts. After max, continues as NON_STP with manual review. |
| 7 | Signature base64 stored in DB (TBL_AINXT_SIGN_RESPONSE.BASE64STRING, TBL_CAPS_SIGN_RESPONSE) | USP_AINXT_SIGN_RESPONSE_SJET | SignatureService.StoreSignatureToS3 + DocumentPathInfo record | PRESENT | New stores in S3 instead of DB column. Also creates DocumentPathInfo record. Better approach. Old base64-in-DB pattern not needed. |
| 8 | Joint account support: AccountType + HolderType params on all signature SPs, defaults to JOINT/FH | USP_AINXT_SIGN_RESPONSE_SJET, USP_CAPS_SIGN_RESPONSE_SJET | Not implemented - signature tied to LeadId only | MISSING | Old supported joint accounts where each holder signs separately. New code is single-lead. Joint/holder support needed if multi-holder accounts are in scope. |
| 9 | EQUITY_AFTER_MFD flag retrieved in CAPS SP from TBL_OAO_DETAILS | USP_CAPS_SIGN_RESPONSE_SJET:37-40 | Not implemented | MISSING | MFD-to-equity conversion flag was stored with CAPS signature response. Relevant for MFD customers upgrading to equity. If MFD conversion is in scope, add to signature flow. |
| 10 | Signature response logging in dedicated tables (TBL_AINXT_SIGN_RESPONSE, TBL_CAPS_SIGN_RESPONSE) with full API response fields | USP_AINXT_SIGN_RESPONSE_SJET, USP_CAPS_SIGN_RESPONSE_SJET | SignatureVerification entity (LeadId, Method, Status, StpFlag, Attempts, S3Key, ValidatedBy) | PARTIAL | New stores essential fields in SignatureVerification table. Missing: vendor-specific fields (sign_label, remark, data_status), raw API response logging. Consider adding a JSON column for raw vendor response. |
| 11 | IsMobileApp, AppVersion, RMCode, IPAddress, DeviceId, IsBRBALogin tracked on signature requests | SignatureAPI.cs:87-93 | Not tracked on signature entity; JourneyTracker may capture some via middleware | PARTIAL | Old logged device/channel metadata per signature attempt. New relies on middleware/audit trail. Verify JourneyTracker captures IP, device, channel. |
| 12 | Error logging to SQL_ErrorLog + email alert on SP failure (USP_SHOOT_MAIL_ON_EXCEPTION_SJET) | USP_AINXT_SIGN_RESPONSE_SJET:56-99 | Structured logging via ILogger + downstream event publishing | PRESENT | New uses structured logging. Email alerting should be handled by monitoring/alerting infrastructure (CloudWatch/PagerDuty), not in-code SP mail. |
| # | Old Function / Logic | Old File | New Equivalent | Status | Gap Details |
|---|---|---|---|---|---|
| 1 | GetPersonalDetails: retrieves full personal data + dropdown master values in multi-table DataSet (Table[0]=details, Table[1]=dropdowns, Table[2-6]=nominee relationship/address/gender/type/doc) | PersonalRespository.cs:55-324 | PersonalDetailsService.GetPersonalDetailsAsync - returns flat PersonalDetailsResult | PARTIAL | New returns personal fields only. Missing: dropdown master lists (occupation, qualification, income, gender, PEP, DISBOOKLET, etc.), nominee relationship list, primary applicant address, nominee gender list, nominee document type list. These should be served via a separate /lookups endpoint. |
| 2 | Dropdown master values filtered by TYPE from single SP result (MARITALSTATUS, OCCUPATION, QUALIFICATION, ANNUALINCOME, GENDER, DPIDSOURCE, INVESTMENTEXP, MTFPRODUCT, COMMODITYCATEGORY, PEP, DISBOOKLET, BSDA_SCHEME, SETTLE_CYCLE, OPERATIONMODE) | USP_GET_PERSONAL_DROPDOWN_MASTER_SJET | ValidateLookupsAsync checks Lookups table, but does not serve dropdown values to frontend | PARTIAL | New validates against Lookups table server-side. Missing: API to return available dropdown options to frontend. Need a GET /lookups?categories=... endpoint. |
| 3 | KRA address check: CHECK_VALIDATEKRA_ASYNC_CALL + ValidatePanDob_CVL before loading personal details | PersonalRespository.cs:60-73 | Not implemented | MISSING | Old pre-validates PAN+DOB against CVL/KRA before showing personal details. Ensures KRA data is fresh. New loads from DB directly. KRA validation should happen in earlier stages or as background job. |
| 4 | Father/Spouse name: 50-char max validation, name split into FHFNAME/FHMNAME/FHLNAME parts | PersonalRespository.cs:412-434 | PersonalDetailsService stores FatherName as single string | PARTIAL | New stores full name. Missing: 50-char limit validation, F/M/L name split (needed for regulatory forms). Add server-side split or store as separate fields. |
| 5 | Father name match logic: GetFatherNameDetails + GetFatherNameMatch (compares PAN name vs manual entry, stores match percentage) | PersonalRespository.cs:960-977 | Not implemented | MISSING | Old matched father/spouse name from PAN OCR vs user entry and stored match percentage. Used for STP scoring. New should add name match check for STP. |
| 6 | Segment selection via INSERTUPDATESELECTEDSEGMENT (Equity, Currency, Derivative, Commodity, ClientConsent) | PersonalRespository.cs:457 | PersonalDetailsService: EquityEnabled=true, Derivative/Currency/Commodity=FnoSelected | PARTIAL | New auto-enables Derivative+Currency+Commodity when F&O selected. Missing: separate segment selection call, individual segment toggles (user might want Commodity without F&O), ClientConsentReceived flag, separate SP for segment persistence. |
| 7 | F&O auto-enable + Account Aggregator for income proof | PersonalRespository.cs:457 + OneMoney integration | PersonalDetailsService: TryAccountAggregatorAsync creates OneMoney consent, sets Stage10Required | PARTIAL | New creates OneMoney consent stub but always returns false (AA flow incomplete). Actual OneMoney API integration pending. Stage 10 correctly triggered on AA failure. |
| 8 | PEP declaration: PEP_REJECT + PEP_REJECT_REASON fields, compliance routing | PersonalRespository.cs:186-187 | PersonalDetailsService: PepDeclared boolean, StpPepFlag="NON_STP" when PEP=true | PARTIAL | New sets NON_STP for PEP and logs warning. Missing: PEP_REJECT and PEP_REJECT_REASON fields (compliance may reject PEP applications). Add rejection tracking. |
| 9 | Marital status change via dedicated SP (USP_CHANGE_MARITAL_STATUS_SJET) with separate endpoint | PersonalRespository.cs:1159-1194 | Not implemented as separate operation | MISSING | Old had dedicated ChangeMaritalStatus endpoint that updated status independently. This triggers father/spouse name re-check. New only sets marital status during full save. |
| 10 | DIS Booklet, DDPI consent, BSDA scheme, Settlement cycle, Operation mode - all as separate dropdown fields | PersonalRespository.cs:140-213 | PersonalDetailsService stores SettlementPreference only | MISSING | Old tracked DIS Booklet, DDPI consent, BSDA scheme, settlement cycle, operation mode as distinct fields. New has SettlementPreference only. Add remaining fields to PersonalDetail entity. |
| 11 | MTF (Margin Trade Funding): MTF key/value, MTFURL, SHOWMTF flag, MTFPRODUCTMESSAGE | PersonalRespository.cs:126-129, 167-169 | Not implemented | MISSING | MTF product selection with URL link and display message. Add MTF fields and conditional display logic. |
| 12 | ISSTAFF flag, ISMOBILEOTPCOMPLETED, DPIDSource, ShowDPIDSource | PersonalRespository.cs:156-165 | Not implemented | PARTIAL | Staff flag affects journey flow. DPIDSource determines DP ID source (NSDL/CDSL). These are likely in Lead entity but not exposed in PersonalDetailsResult. |
| 13 | Minor personal details flow: GET_MINOR_PERSONAL_DETAILS + UPDATE_MINOR_PERSONAL_DETAILS with guardian relation dropdown | PersonalRespository.cs:325-386, 789-867 | Not implemented | MISSING | Old had separate minor flow for accounts where primary applicant is a minor (guardian opens account). Entirely absent in new code. Add if minor accounts are in scope. |
| 14 | NRI personal details: GET_NRI_PERSONAL_DETAILS with NRI-specific fields (AnnualIncome_NRI, NRI identity proof, NRI country list, NRI nominee address) | NRIPersonalRespository.cs:44-265 | PersonalDetailsService checks lead.IsNri and calls NriValidationService | PARTIAL | New validates NRI eligibility and FATCA. Missing: NRI-specific annual income range, NRI identity proof document list, NRI country list, NRI nominee address table. These were returned as Tables[6-8] in old SP. |
| 15 | NRI personal details insert: INSERT_NRI_PERSONAL_DETAILS + NRI_INSERTUPDATE_STAGEDETAILS | NRIPersonalRespository.cs:280-303 | PersonalDetailsService.SavePersonalDetailsAsync handles NRI via same flow | PARTIAL | New uses unified save. Missing: NRI-specific SP that stores NRI-only fields. Verify PersonalDetail entity has NRI fields (tax residency, overseas address, etc.). |
| 16 | SuperApp cloud push + MinKYC push + client code generation + STP/NonSTP check after personal details save | PersonalRespository.cs:506-740 | Downstream event publishing via IDownstreamEventPublisher to CLEVERTAP, ZOHO_CRM, CDP, DATALAKE | PARTIAL | Old had complex SuperApp integration: generate client code, push MinKYC, STP check, LeadSquared opportunity update. New publishes events to downstream. Verify ZOHO/CDP consumers handle client code generation and MinKYC push. |
| 17 | NRI flag insertion: USP_INSERT_UPDATE_NRI_LEAD_SJET when ISNRI=1, blocks further processing | PersonalRespository.cs:405-411, 1094-1137 | lead.IsNri flag on Lead entity | PRESENT | New uses IsNri boolean on Lead entity set during earlier stages. No need for separate NRI flag insert at personal details stage. |
| 18 | Scheme details binding: BindSchemeValue_DIRECT returns SchemeName, DPTariff, SELECTEDSEGMENT | PersonalRespository.cs:296-311 | Not implemented | MISSING | Old loaded scheme/tariff/selected-segment data alongside personal details. Likely needed for brokerage plan display. Add as separate endpoint or include in response. |
| 19 | Father/spouse verification stage: INSERTUPDATE_STAGEDETAILS for "FHSPOUSE" + showFatherSpouse flag | PersonalRespository.cs:751-759 | Not implemented as separate stage check | MISSING | Old had conditional father/spouse detail collection as sub-step. If OCR detected father/spouse name, this stage was auto-completed. New should handle via pre-fill from Aadhaar/KRA. |
| # | Old Function / Logic | Old File | New Equivalent | Status | Gap Details |
|---|---|---|---|---|---|
| 1 | Get nominee details by ID (GET_NOMINEE_DETAILS_BYID) with type filter | NomineeDetailsRepository.cs:55-84 | NomineeService.GetNomineesAsync - returns all active nominees for lead | PRESENT | New returns all active nominees. Old supported type-based filtering. Functionally equivalent. |
| 2 | Insert/Update nominee with suspicious phone/email validation (Usp_GetSuspiciousPhoneOrEMailId) | NomineeDetailsRepository.cs:112-148 | Not implemented | MISSING | Old checked nominee phone and email against suspicious/blacklisted entries before saving. Critical for fraud prevention. Add blacklist check. |
| 3 | Duplicate nominee validation: same email/mobile/PAN across different nominee types blocked | NomineeDetailsRepository.cs:150-176 | NomineeService checks name vs account holder only | MISSING | Old prevented duplicate email, mobile, PAN across nominees. New only checks name match with account holder. Add duplicate field validation across nominees. |
| 4 | Witness details validation: witness name/PAN must differ from primary applicant AND from each nominee | NomineeDetailsRepository.cs:177-219 | Not implemented | MISSING | Old had comprehensive witness vs primary applicant vs nominee cross-validation. Witness details entirely absent in new code. Add witness entity + validation. |
| 5 | Restricted email domain check (CHECK_RESTRICTED_DOMAIN) | NomineeDetailsRepository.cs:222-245 | Not implemented | MISSING | Old blocked nominee emails from restricted domains (disposable email providers). Add domain blacklist check. |
| 6 | Minor nominee detection: CalculateDaysSinceBirth <= 6573 days (18 years) | NomineeDetailsRepository.cs:255 | NomineeService: age calculation from NomineeDob, isMinor = age < 18 | PRESENT | Both calculate minor status from DOB. New uses DateOnly arithmetic. Equivalent. |
| 7 | Guardian details for minor nominees (NomineeMinorFName/MName/LName, guardian DOB/age, guardian relationship, guardian address) | NomineeDetailsRepository.cs:257 | NomineeService: GuardianName + GuardianRelationship only | PARTIAL | New stores guardian name and relationship. Missing: guardian address fields, guardian DOB/age, guardian F/M/L name split, SameAsCorrNomineeGuardian flag (copy address from primary). |
| 8 | Nominee PAN verification via Hyperverge (GetPanDetailsHyperverge + SPLITFULLNAME for F/M/L name split + DOB extraction) | NomineeDetailsRepository.cs:438-537 | Not implemented | MISSING | Old verified nominee PAN via Hyperverge and auto-populated name/DOB. New stores NomineePan but doesn't verify. Add PAN verification for nominees. |
| 9 | Max 3 nominees + percentage must total 100% | USP_INSERT_UPDATE_NOMINEEDETAILS_SJET | NomineeService: max 3 check + total share <= 100% validation | PRESENT | Both enforce 3-nominee limit and percentage validation. New validates in code, old in SP. |
| 10 | Nominee delete with CRM stage update (LeadSquared CRMSTAGEUPDATE) | NomineeDetailsRepository.cs:305-338 | NomineeService.DeleteNomineeAsync - soft delete, no CRM update | PARTIAL | New does soft delete. Missing: CRM/downstream notification on nominee deletion. Add event publish on delete. |
| 11 | Witness details insert/update (INSERT_UPDATE_NOMINEE_WITNESS) - separate entity with FirstName, MiddleName, LastName, PanNo, Address fields | NomineeDetailsRepository.cs:412-436 | Not implemented | MISSING | Witness details are regulatory requirement when nominee is added. Need new WitnessDetail entity + CRUD + cross-validation logic. |
| 12 | Primary applicant address retrieval for nominee address prefill (GET_NOMINEE_PRIMARY_APPLICANT_ADDRESS) | NomineeDetailsRepository.cs:397-410 | Not implemented | MISSING | Old allowed nominee address to be copied from primary applicant. New stores NomineeAddress as string. Add address prefill from lead's Aadhaar/correspondence address. |
| 13 | No-nominee declaration (NOMINEE_DECLARATION flag) | PersonalRespository.cs:175 | NomineeService.DeclareNoNomineeAsync - creates declaration record, deactivates existing nominees | PRESENT | Well implemented. New also deactivates any existing nominees on no-nominee declaration. |
| 14 | Nominee address fields: NomineeAddr1/2/3, LandMark, PinCode, City, State, Country, SameAsCorrNominee flag | NomineeDetailsRepository.cs:257 | NomineeService: single NomineeAddress string | PARTIAL | Old had structured address (line1/2/3, landmark, pin, city, state, country). New uses single string. Structured address may be needed for regulatory forms. Consider address entity. |
| # | Old Function / Logic | Old File | New Equivalent | Status | Gap Details |
|---|---|---|---|---|---|
| 1 | NRI nominee details: additional fields (PassportNumber, VoterIdNumber, DrivinglicenseNumber, IdentityProof, NomineeAddressType) | NRIPersonalRespository.cs:392 | Not implemented | MISSING | NRI nominees require identity proof fields that domestic nominees don't. Add NRI-specific nominee fields. |
| 2 | NRI nominee validation SP (USP_VALIDATE_NRI_NOMINEEDETAILS_SJET) - validates before insert | NRIPersonalRespository.cs:397-539 | NomineeService has basic validation only | MISSING | Old had separate DB-level validation for NRI nominees. New has same validation for all. Add NRI-specific rules (e.g., overseas address mandatory, identity proof required). |
| 3 | NRI nominee insert via separate SP (USP_INSERT_UPDATE_NRI_NOMINEEDETAILS_SJET) + CRM update (CRMSTAGEUPDATE_NRI) | NRIPersonalRespository.cs:483-510 | Same NomineeService for all leads | PARTIAL | New uses unified nominee service. Missing: NRI-specific CRM stage update and NRI stage detail tracking. |
| 4 | NRI nominee PAN verification via VerifyPAN_API + USP_CHECK_PAN_USED_SJET (PAN used check) + USP_GETCSAFEFLAG_SJET (CSAFE flag) | NRINomineeRepository.cs:38-188 | Not implemented | MISSING | NRI nominee had PAN verification + used-PAN check + CSAFE flag to determine if PAN API should be called. Add PAN verification for NRI nominees. |
| 5 | NRI segment selection: IsFnO + IsCustodian_Code + Custodian_Code via USP_NRI_INSERT_UPDATE_SEGMENTDETAILS_SJET | NRISegmentRepository.cs:28-76 | Not implemented | MISSING | NRI segment selection includes custodian code (required for NRI F&O). New auto-enables segments with F&O but has no custodian code field. Add for NRI. |
| 6 | NRI segment details retrieval (USP_NRI_GET_SEGMENTDETAILS_SJET) | NRISegmentRepository.cs:78-120 | Not implemented | MISSING | Old had separate get endpoint for NRI segment status. New should expose segment status in personal details response for NRI leads. |
| 7 | FATCA declaration: NriValidationService.SaveFatcaDeclarationAsync + restricted country check | NRI flow (implied) | NriValidationService: FATCA save, restricted country check (NK, Iran, Syria, Cuba, Crimea, Myanmar), NRI account type determination | PRESENT | Well implemented with delete-and-reinsert matching old SP pattern. Country restriction list present. NRE/NRO/BOTH account type logic present. |
| # | Gap | Stage | Priority | Status |
|---|---|---|---|---|
| 1 | Signature vendor toggle + fallback | 8 | MEDIUM | FIXED — SIGNATURE_VENDOR_PRIMARY config + IsConfigEnabledAsync |
| 2 | PAN sign present check | 8 | LOW | FIXED — PanSignaturePresent field + AUTO_USE_PAN_SIGNATURE config |
| 3 | Witness details entity + CRUD | 9B | HIGH | FIXED — NomineeWitness entity + SaveWitnessAsync + EF config + DB table |
| 4 | Suspicious phone/email check for nominees | 9B | HIGH | FIXED — SuspiciousContact + RestrictedEmailDomain checks in NomineeService |
| 5 | Duplicate nominee PAN validation | 9B | HIGH | FIXED — NomineePanHash dedup check across nominees for same lead |
| 6 | Nominee PAN verification (Hyperverge) | 9B | MEDIUM | OPEN — Wire when Hyperverge available via middleware vendor config |
| 7 | DIS Booklet, DDPI, BSDA, MTF fields | 9A | HIGH | FIXED — 6 fields added to PersonalDetail + command + service mapping |
| 8 | Dropdown master API for frontend | 9A | HIGH | ALREADY EXISTS — GET /api/v1/lookups/{category} in JourneyController |
| 9 | NRI nominee identity proof fields | 9C | HIGH | FIXED — IdentityProofType/Number/S3Key on Nominee entity + command |
| 10 | NRI segment custodian code | 9C | HIGH | FIXED — CustodianCode + NriAccountType on PersonalDetail entity + command |
| 11 | Father/spouse name split | 9A | MEDIUM | FIXED — Name split into First/Middle/Last + mapping in service |
| 12 | Marital status change endpoint | 9A | LOW | OPEN — Can use SavePersonalDetailsAsync with only MaritalStatus field |
| 13 | Restricted email domain check for nominees | 9B | MEDIUM | FIXED — RestrictedEmailDomain check added in NomineeService |
| 14 | Joint account / holder type in signature | 8 | LOW | OPEN — Single-applicant flow only for Day Zero |
| + | Wet sign vs digital sign toggle | 8 | MEDIUM | FIXED — ENABLE_WET_SIGN_{Channel} config toggle |
| + | NRI signature (scanned upload) | 8 | MEDIUM | FIXED — IsNri check routes to upload path |
Stage 8: 12 items checked — 4 PRESENT, 2 PARTIAL, 6 MISSING
Stage 9A (Personal): 19 items checked — 2 PRESENT, 8 PARTIAL, 9 MISSING
Stage 9B (Nominee): 14 items checked — 4 PRESENT, 4 PARTIAL, 6 MISSING
Stage 9C (NRI Nominee/Segment): 7 items checked — 1 PRESENT, 1 PARTIAL, 5 MISSING
Total: 52 items — 11 PRESENT (21%), 15 PARTIAL (29%), 26 MISSING (50%)
Note: Many MISSING items are NRI-specific or product-specific (MTF, BSDA, DIS) that may not be Day Zero scope. The 5 HIGH-priority gaps (witness details, suspicious contact check, duplicate nominee validation, DIS/DDPI/BSDA fields, NRI nominee fields) should be addressed first.