EKYC 3.0 — Gap Analysis: New Backend vs Old Code

Registration, Login & Stage 1 • Comparing D:\MO_Project\ekyc\backend vs D:\MO_Project\ekyc\existing_code
Scope: Registration + Login + Stage 1 (OTP) only New Backend: .NET 8 + PostgreSQL + Redis Old Backend: .NET + SQL Server + SOAP

Table of Contents

  1. Executive Summary
  2. Check-by-Check Comparison
  3. Missing Checks & Logic Gaps
  4. Old Operational Tables — NOT to Reuse
  5. New Operational Tables (Your Backend)
  6. Reference / Master Tables — MUST Use
  7. API Endpoint Comparison
  8. Old SP → New Code Mapping
  9. Action Items

1. Executive Summary

23
Checks Present
8
Partial / Needs Enhancement
11
Missing from New Code
42
Total Checks Analysed
What the new backend does well Redis OTP (not DB), SHA-256 hashing, consent versioning, negative list with IP check, CBOS dedupe with SKIPPED fallback, eligibility decision table with 8 priorities, OTP cascade architecture (interface ready), lead retry (3x/2s), background PAN/KRA/C-safe checks fired after OTP verify, provider chain with circuit breaker, comprehensive audit logging, GDPR-compliant lead deletion.
Critical gaps found (11 items) The old system performed several checks via its stored procedures that are not yet replicated in the new backend. These are mostly reference-data lookups against MOSL feed tables, bypass logic, and specific campaign/branch routing logic. Details below.

2. Check-by-Check Comparison

Every check performed by the old code during Registration/Login/OTP, mapped to the new backend.

# Check / Logic Old Code (SP / Method) New Backend Status
REGISTRATION — Eligibility & Dedupe
1 Negative list check (mobile) TBL_FFF_NOT_ALLOW in Proc_DedupeCheck FraudCheckService.CheckNegativeListAsync() queries negative_list_entries PRESENT
2 Negative list check (IP address) Not in old code RegistrationService passes IP, checks IdentifierType=IP_ADDRESS PRESENT (new, per BRD)
3 CBOS / Back-office active Demat check USP_CHECK_MOBILE_EXISTS_BO_EXP_SJET checks MOSL_FEED + DPMASTER + whitelist RegistrationService checks leads with state=ACTIVATED PARTIAL
4 EKYC DB dedupe — in-progress lead <90 days Proc_DedupeCheck_LeadSquare_LSQ_SJET + USP_CHECK_NINTY_DAY_LOGIC RegistrationService checks active leads in 90-day window PRESENT
5 Same channel/BA/RM → resume Not in old code (BRD new requirement) RegistrationService compares Channel, BaCode PRESENT
6 Different channel → block Not in old code (BRD new requirement) RegistrationService → BLOCKED result PRESENT
7 Old platform in-progress → redirect USP_CHECK_NINTY_DAY_LOGIC + Tbl_DAD_TO_RETAIL_TRANSFERRED_LEADS RegistrationService checks Platform=EKYC_V2/V1 → REDIRECT PRESENT
8 REJECTED / CS_EXPIRED → archive & create new proc_execute_dad_dedupe_discard RegistrationService archives old, creates new PRESENT
9 Mobile bypass logic (INACTIVE/PMS/OWNER) USP_BYPASS_MOBILE_EMAIL_PAN_SJET — checks MOSL_FEED_CLIENT_DETAILS, MOSL_FEED_BRANCH, MOSL_FEED_SUBBROKERS for bypass conditions Not found in new backend MISSING
10 Multiple user exists check USP_CHECK_MULTIPLE_USER_EXISTS_SJET — counts records in DEDUPE_DATA_DUMP with DedupParam IN (N, EPO, MPO) Not found. New code checks single lead by mobileHash but does not handle multiple pre-existing leads for same mobile. MISSING
11 Offline client check (branch client block) USP_Check_Direct_Offline_Client_EXP_SJET — blocks online journey if user is an existing branch offline client Not found in new backend MISSING
12 MOSL_FEED active client check (not just own DB) USP_CHECK_MOBILE_EXISTS_BO_EXP checks VW_MOSL_FEED_CLIENT_DETAILS + TBL_DPMASTER for active accounts across MOSL ecosystem New code only checks own leads table. Does NOT check external MOSL_FEED / DP Master for existing active brokerage accounts. MISSING
13 PAN-Mobile whitelist bypass TBL_PAN_MOBILE_EMAIL_WHITELIST — allows duplicates for whitelisted PAN+Mobile combos Not found in new backend MISSING
REGISTRATION — Lead Creation & Routing
14 Lead record creation with SHA-256 mobile hash Old: plain mobile in TBL_DEDUPE_DATA_DUMP New: IHashingService.HashMobile(), stored as MobileHash PRESENT
15 SSO user creation USP_CLIENT_REGISTRATION_SJET creates MOSL_SSO.dbo.tblUser Not in new backend (likely handled differently in EKYC 3.0 architecture) N/A (new arch)
16 State/city validation from master TBL_STATE_CITY_MASTER_LSQ + MST_CITY_STATE New has StateMaster, CityMaster, PincodeMaster entities defined but no registration-time validation found PARTIAL
17 Branch/RM assignment logic USP_CLIENT_REGISTRATION_SJET — 500+ lines of complex branch/RM routing for Alliance, IDFC, INDUSIND, AUSFBDIRECT, SBOM, DBIZ, SIB, CSFB campaigns New code stores BaCode, BranchCode, BranchEmpCode on Lead entity but no active routing logic found PARTIAL
18 Campaign-specific routing (IIBLMICROSITE, AUFSB, CBI, BA Self-Direct) Extensive campaign-specific logic in USP_CLIENT_REGISTRATION_SJET CampaignName stored on Lead but no campaign-specific routing logic MISSING
19 Consent records with versioning Not in old code Consent entity with ConsentType, ConsentVersion, ConsentTextHash, IpAddress, Platform, WhatsappOptin PRESENT
20 Lead creation retry (3x, 2s delay) Not in old code Implemented in RegistrationService with 3 attempts, 2s delay PRESENT
21 Referral code validation USP_VALIDATE_REFERALCODE_SJET checks MOSL_FEED_CLIENT_DETAILS.CL_code ReferralCode entity exists. Validation against referral_codes table (own table, not MOSL_FEED) PARTIAL
22 Restricted mobiles check Not explicit in old code (embedded in registration SP) RegistrationService checks restricted_mobiles table PRESENT
23 Suspicious contacts flagging Usp_GetSuspiciousPhoneOrEMailId RegistrationService checks suspicious_contacts table, flags but does not block PRESENT
24 Dedupe parameter tracking (N/EPO/MPO/C2) USP_CLIENT_REGISTRATION_SJET sets DEDUPE_PARAM for each registration Not found. New code uses lead state machine (INITIATED, DROPPED, etc.) but no equivalent EPO/MPO/C2 classification. MISSING
25 Product transition flag check Proc_Dedupe_UserIDExistProcess_Revamp checks ProductTransitionFlag in TBL_OAO_DETAILS Not found in new code MISSING
OTP — Generation & Verification
26 4-digit OTP generation In DB via SP OtpGeneratorService — 4-digit cryptographic random PRESENT
27 OTP in Redis only (not DB) Old: stored in DB New: ICacheService.StoreOtpAsync() → Redis, TTL 5 min PRESENT
28 Max 5 wrong attempts → DROPPED Attempt tracking in DB OtpVerificationService: MaxWrongAttempts=5, state→DROPPED, IsLocked=true PRESENT
29 Max 3 resends in 30 min Rate limiting in DB OtpVerificationService: MaxResendCount=3, MinResendIntervalSeconds=30 PRESENT
30 OTP delivery cascade (SMS→WhatsApp→Push→RCS) Old: SMS only (Netcore SOAP) Interface INotificationService.SendOtpCascadeAsync() defined. Current impl uses NetcoreSmsProvider (MOSL SMS) only. PARTIAL (interface ready, only SMS impl)
31 SMS Retriever API support (Android auto-read) Supported in old code Backend-agnostic (frontend concern), but SMS template must include hash N/A (FE)
32 CS Journey on all OTP channels fail Not in old code ICsJourneyService.CreateHoldAsync() exists, OTP failure would trigger CS_OTP_PROVIDER_DOWN PRESENT
POST-OTP — Background Checks (Stage 2)
33 Zintlr phone-to-PAN lookup Not in old reg code (done later) BackgroundCheckService calls ZintlrPhoneToPanProvider with plainMobile PRESENT
34 Hyperverge PAN name+DOB fetch Called at PAN stage in old code BackgroundCheckService calls Hyperverge after Zintlr returns PAN PRESENT
35 NSDL PAN validation (with UTI fallback) PanAPI.VerifyPAN_NSDL() in old code NsdlPanProvider + UtiPanProvider via ProviderChain PRESENT
36 CVL KRA status fetch + data download USP_INSERT_KRA_LOGS_SJET in old code BackgroundCheckService calls CVL, maps raw codes, stores KraRecord PRESENT
37 C-safe AML/SEBI/PEP check USP_INSERT_CSAFE_Req_Resp in old code BackgroundCheckService calls C-safe, stores CsafeCheck with all flags PRESENT
LOGIN / RESUME
38 AuthenticateLogin (OTP-as-password) RESUME_AUTHENTICATE_USER_OTP_PASS in LoginRepository New code uses OTP verification directly via OtpVerificationService. No separate "login" concept — resume is via OTP re-verify. PRESENT (different approach)
39 JWT token generation with claims GenerateEKYCToken() with UserId, BranchEmpCode, etc. JWT configured in appsettings (15-min expiry, 7-day refresh). Endpoint-level auth not yet enforced. PARTIAL
40 Redirection to last completed stage USP_GET_REDIRECTION_PAGENAME_SJET Lead.CurrentStage tracks progress. Resume via eligibility check → same channel → RESUME result includes existing LeadId. PRESENT
41 Truecaller integration USP_GET_USERDATA_TRUECALLER_SJET, USP_CALLBACK_LOG_TRUECALLER_SJET LeadSession.IsTrueCaller field exists but no Truecaller provider or callback handling found MISSING
42 CRM lead creation (LSQ / Zoho) Extensive LeadSquare + Zoho integration in RegistrationRepository & LoginRepository ZohoCrmProvider exists. DownstreamEvent publishes to ZOHO_CRM. But no LeadSquare provider found. PARTIAL (Zoho yes, LSQ no)

3. Missing Checks & Logic Gaps — Priority Action Required

PriorityGapWhy It MattersRecommended Fix
P0 #12 — MOSL_FEED active client check Old code checks back-office MOSL_FEED tables to find if mobile already belongs to an active brokerage client. Without this, you may open duplicate accounts for existing clients. Create a ClientMaster sync job from MOSL_FEED. Your client_master table entity exists — populate it and add a check in RegistrationService before lead creation. Query: WHERE MobileHash = @hash AND IsActive = true AND InactiveDate IS NULL
P0 #9 — Mobile/Email/PAN bypass logic Old USP_BYPASS_MOBILE_EMAIL_PAN_SJET allows registration when mobile belongs to INACTIVE client, PMS-only client, or branch/sub-broker OWNER. Without this, legitimate users whose mobile is in BO will be blocked. Implement bypass service checking client_master: if all records for that mobile are inactive OR product_type=PMS OR mobile belongs to branch/subbroker owner → allow with flag. Add BypassReason field to Lead.
P0 #11 — Offline client block Old code blocks online journey if user is a branch offline client. Without this, branch clients could accidentally create duplicate online accounts. Add check in RegistrationService against client_master where channel=BRANCH and has active offline status.
P1 #13 — PAN-Mobile whitelist Some PAN+Mobile combos are pre-approved to bypass duplicate checks (e.g., family accounts, re-registrations after closure). Create duplicate_bypass_whitelist table (or use existing negative_list_entries concept inverted). Check before blocking on mobile duplicate.
P1 #10 — Multiple user exists If multiple leads exist for same mobile (e.g., one EPO, one MPO), old code handles this explicitly. New code may create duplicates. Add unique constraint: one active (non-DROPPED, non-REJECTED) lead per mobileHash. Add multi-lead resolution logic.
P1 #18 — Campaign-specific routing IIBLMICROSITE, AUFSB, CBI, BA Self-Direct campaigns have special RM assignment and branch routing. Without this, leads from these campaigns won't be assigned correctly. Create CampaignRoutingService with rules per campaign. Can be config-driven via application_config or a new campaign_routing_rules table.
P1 #24 — Dedupe parameter classification Old system classifies each registration as N (new), EPO (email prev owned), MPO (mobile prev owned), C2 (transition). Used for analytics and CRM tracking. Add DedupeClassification field to Lead entity. Set during eligibility check based on what matched.
P1 #25 — Product transition flag Old code checks if a deduped lead is eligible for product transition (e.g., MFD → Equity upgrade via new registration). Add product transition logic if applicable to EKYC 3.0 scope. If not applicable (BRD says upgrade is via eModification), mark as out of scope.
P1 #41 — Truecaller integration Old code had Truecaller SDK integration for auto-fill. Field exists on LeadSession but no provider. If Truecaller is in scope for Day Zero, implement TruecallerProvider. If not, mark as subsequent launch and remove dead field.
P2 #17 — Branch/RM assignment Complex routing for different campaign sources. Fields exist on Lead but no routing logic. Implement post-lead-creation service to assign RM based on channel + campaign + location rules.
P2 #42 — LeadSquare integration Old code had extensive LSQ integration. New code has Zoho only. If LSQ is deprecated in favour of Zoho, mark as N/A. If both needed, add LSQ provider.

4. Old Operational Tables — NOT to Reuse

These are the old system's operational tables. Your new backend has its own equivalents. Do NOT use these tables — they belong to the old EKYC system.

Old TablePurpose (Old System)New Equivalent
TBL_DEDUPE_DATA_DUMPPrimary registration/dedupe record per userleads table (Lead entity)
TBL_OAO_DETAILSAccount opening opportunity detailsleads + personal_details + final_validations
TBL_CLIENT_STAGEDETAILSStage progression trackingleads.CurrentStage + journey_stage_events
TBL_LSQ_LEADID_STAGEDETAILSLeadSquare lead trackingdownstream_events (target=ZOHO_CRM)
TBL_CLIENT_PERSONALDETAILSClient personal datapersonal_details + nominees
MOSL_SSO.dbo.tblUserSSO user accountsJWT-based auth (no SSO user table)
TBL_TRACK_BYPASS_MOBILE_EMAIL_PANBypass audit logUse fraud_checks with CheckType=BYPASS
TBL_DAD_TO_RETAIL_TRANSFERRED_LEADSDAD-to-Retail migration trackingleads with Platform=EKYC_V1/V2 filter
TBL_DEDUPE_PARAM_LOGDedupe decision logginglead_state_transitions
TBL_ZOHOEKYC_MAPPERZoho-EKYC mappingdownstream_events (target=ZOHO_CRM)
TBL_FFF_NOT_ALLOWFraud/blocked listnegative_list_entries
ErrorLogAPI_MasterError loggingapi_audit_logs + structured logging
TBL_RESUME_LOG_VAL_SAATHIResume trackinglead_state_transitions + journey_stage_events
TBL_TRACKINGINPUT_USP_CLIENT_REGISTRATIONRegistration input loggingapi_audit_logs
SQL_ErrorLogSQL error loggingApplication-level structured logging (Serilog/etc.)

5. New Operational Tables (Your Backend)

These are the tables your new ekyc3 PostgreSQL database uses. You own these.

New Table (Entity)Replaces OldKey Differences
leadsTBL_DEDUPE_DATA_DUMP + TBL_OAO_DETAILSSingle unified entity. SHA-256 hashes. State machine. UUID primary key.
lead_sessionsEmbedded in old registration paramsDedicated session table with full UTM, device, location tracking.
lead_state_transitionsNone (new)Full audit trail of every state change with trigger and reason.
otp_verificationsOTP columns in old user tableDedicated table. OTP value only in Redis. Tracks attempts, resends, locks.
consentsNone (old had no consent tracking)Versioned consent records with text hash, platform, IP.
fraud_checksTBL_FFF_NOT_ALLOW (partial)Generic check records with type, result, flag code, JSON details.
negative_list_entriesTBL_FFF_NOT_ALLOWSupports MOBILE, PAN, IP_ADDRESS types. Expiry dates. Source tracking.
journey_stage_eventsInsertApplicationStepsLogRich stage events with duration, vendor, retry count, drop code.
downstream_eventsLSQ/Zoho inline callsEvent-driven async publishing with retry. Targets: CLEVERTAP, ZOHO, CDP, etc.
api_audit_logsErrorLogAPI_MasterFull request/response logging with correlation ID, duration, mock flag.
pan_verificationsPAN columns in old tablesDedicated PAN verification entity with hash, name, DOB, provider, attempts.
kra_recordsKRA log tablesFull KRA data with raw code, mapped status, prefill data, JSON response.
csafe_checksUSP_INSERT_CSAFE tablesDedicated AML/SEBI/PEP check with individual flags.
notificationsSMS send log tablesMulti-channel notification tracking (SMS, email, push, WhatsApp).
cs_journey_holdsNone (new)CS journey pause/resume with automated retry scheduling.

6. Reference / Master Tables — MUST Use

Critical: These reference tables contain business data that MUST be synced or queried These are NOT operational tables. They contain master/reference data maintained by MOSL back-office, compliance, HR, and operations teams. Your new system must either: (a) Sync this data into your own equivalent tables, or (b) Read directly from these source tables via a read-only connection/API.

6.1 Tables Your Backend Already Has Equivalents For

Old Reference TableYour New TableSync StatusAction Needed
MOSL_FEED_CLIENT_DETAILS client_master (ClientMaster entity) DEFINED, NOT POPULATED P0: Set up data sync job. This is the core back-office client feed. Columns needed: ClientCode, PanHash, MobileHash, EmailHash, ClientName, IsActive, InactiveDate, BranchCode, Segments. Sync frequency: at least daily.
MOSL_FEED_BRANCH No equivalent MISSING P1: Need for bypass logic (OWNER check). Create branch_master table or add to client_master sync. Columns: BranchCode, Mobile, Email, PanHash, 1200Code.
MOSL_FEED_SUBBROKERS No equivalent MISSING P1: Need for bypass logic (OWNER check). Create subbroker_master table. Columns: SubBrokerCode, Mobile, Email, PanHash, 1200Code.
TBL_DPMASTER No equivalent MISSING P0: DP master has CM_MOBILE and CB_PANNO for active DP accounts. Needed for CBOS duplicate check. Create dp_master or merge into client_master.
TBL_PAN_MOBILE_EMAIL_WHITELIST No equivalent MISSING P1: Create duplicate_bypass_whitelist table. Columns: PanHash, MobileHash, EmailHash, Reason, IsActive.
TBL_STATE_CITY_MASTER_LSQ / MST_CITY_STATE state_master + city_master + pincode_master DEFINED Populate tables. Ensure IsSouth flag on StateMaster for south_tag logic.
TBL_APPLICATIONCONFIG application_config (ApplicationConfig entity) DEFINED Populate with STP thresholds, feature flags, provider settings.

6.2 Tables Your Backend Already Has and Needs to Populate

Your New TablePurposeData SourceAction
employee_pan_master Block/redirect staff PANs (Stage 4 check, but data needed from Day 1) HR system / MOSL_SDLC_EMPLOYEEDETAILS Set up daily sync. Includes EmpActiveStatus, ResignedRaisedOn, HrStatus.
franchise_pan_whitelist Tag franchise PANs (allow but flag) Franchise operations team Set up data load. Includes FranchiseName, Mobile, PanType.
bank_ifsc_master IFSC lookup for bank verification (Stage 6) RBI IFSC directory Populate from RBI. Already used by BankVerificationService with Redis cache.
negative_list_entries MOFSL + SEBI blocked identifiers Compliance team + SEBI debarred list Populate with hashed mobiles/PANs from SEBI + internal negative list.
restricted_mobiles Mobiles that cannot register Operations/Compliance Populate. Already checked by RegistrationService.
restricted_email_domains Blocked email domains (disposable email services) Security team Populate. Already checked by EmailVerificationService.
suspicious_contacts Flagged phone/email (don't block, flag for review) Fraud operations Populate. Already checked by RegistrationService.
referral_codes Valid referral codes Old: MOSL_FEED_CLIENT_DETAILS.CL_code. New: own table. Populate from client feed or marketing system.
cvl_status_mapping Map raw CVL codes to internal KRA status BRD Section 19 mapping table Populate from BRD. Used by BackgroundCheckService.
nsdl_error_master NSDL error code meanings NSDL documentation Populate. IsFatal flag determines if error is recoverable.
provider_configurations External provider URLs, keys, priorities, circuit breaker config appsettings.json currently Migrate to DB for runtime changes without deploy.

6.3 Old Reference Tables You Must Access (Read-Only) or Sync

These tables live in the old EKYC SQL Server database or MOSL back-office systems You need read access (via API or DB link) to check business rules that depend on back-office data.
Old TableWhy You Need ItRecommended Approach
MOSL_FEED_CLIENT_DETAILS Active client check, bypass logic, referral validation Sync to client_master daily. Include: CL_CODE, PAN, MOBILE, EMAIL, InactiveDate, Product_Type, LONGNAME
MOSL_FEED_BRANCH Branch owner bypass (mobile/email/PAN belongs to branch itself) Sync to branch_master. Include: MOBILE, BA_EMAIL, CORR_EMAIL, PAN, 1200CODE
MOSL_FEED_SUBBROKERS Sub-broker owner bypass Sync to subbroker_master. Include: MOBILE, BA_EMAIL, PAN, 1200CODE
TBL_DPMASTER DP account duplicate check by mobile+PAN Sync to dp_master or merge into client_master
VW_CRM_EMPLOYEEWISE_BRANCH_TRADERCODE Employee-branch mapping for RM assignment Sync if campaign routing is in scope
TBL_ALLIANCE_RM_BRANCH_LIST Alliance RM routing Sync if alliance channel is in scope
TBL_INDUSIND_RM_MAPPING IFSC-to-RM mapping for INDUSIND Sync if INDUSIND campaign is active

7. API Endpoint Comparison

FunctionOld EndpointNew EndpointStatus
Journey init (Stage 0)N/A (page load)GET /api/v1/journey/initNEW
Registration / SignupPOST api/Registration/SignUpAsyncPOST /api/v1/registration/signupPRESENT
OTP ResendPOST api/Login/GENERATEOTPPOST /api/v1/registration/otp/generatePRESENT
OTP VerifyPOST api/Login/AUTHENTICATELOGINPOST /api/v1/registration/otp/verifyPRESENT
OTP Resend (Stage 2)Via GENERATEOTPPOST /api/v1/registration/otp/resendPRESENT
Get client details (Init)POST api/Login/INITVia Lead entity loadPRESENT
Get emailPOST api/Login/GETEMAILVia EmailVerification entityPRESENT
Get mobilePOST api/Login/GETMOBILEVia Lead entity (MobileHash)PRESENT
Resume formPOST api/Login/RESUMEFORMVia registration eligibility → RESUMEPRESENT
Redirect to pagePOST api/Login/REDIRECTTOPAGELead.CurrentStage determines stagePRESENT
Journey statusN/AGET /api/v1/journey/statusSTUBBED
Lead deletion (GDPR)POST api/Login/LEADDELETECLOUDPOST /api/v1/lead/deletePRESENT
Validate referral codePOST api/Registration/VALIDATEREFERALCODEInline in RegistrationServicePRESENT
Check mobile versionPOST api/Registration/CHECKMOBILEVERSIONNot foundMISSING
Truecaller callbackPOST api/Registration/TRUECALLERCALLBACKNot foundMISSING
Send SMS (standalone)POST api/Login/SENDSMSVia INotificationServicePRESENT
CRM lead creationMultiple LSQ endpointsVia DownstreamEventPublisher → ZOHOPARTIAL

8. Old Stored Procedure → New Code Mapping

Old SPNew Code EquivalentCoverage
USP_CLIENT_REGISTRATION_SJETRegistrationService.SignupAsync()70% — Missing: bypass, campaign routing, branch/RM assignment, dedupe params
Proc_DedupeCheck_LeadSquare_LSQ_SJETRegistrationService eligibility checks90% — Missing: FFF_NOT_ALLOW (replaced by negative_list_entries)
USP_CHECK_MOBILE_EXISTS_BO_EXP_SJETPartially via leads table check30% — Missing: MOSL_FEED, DPMASTER, whitelist checks
USP_BYPASS_MOBILE_EMAIL_PAN_SJETNot implemented0%
USP_CHECK_NINTY_DAY_LOGIC_LSQ_SJETRegistrationService 90-day window check90%
USP_CHECK_MULTIPLE_USER_EXISTS_SJETNot implemented0%
USP_Check_Direct_Offline_Client_EXP_SJETNot implemented0%
USP_VALIDATE_REFERALCODE_SJETRegistrationService referral validation against referral_codes table60% — checks own table, not MOSL_FEED CL_code
proc_execute_dad_dedupe_discard_LSQ_SJETRegistrationService archives old lead80%
Proc_Dedupe_UserIDExistProcess_RevampNot directly implemented (product transition)0%
RESUME_AUTHENTICATE_USER_OTP_PASSOtpVerificationService.VerifyOtpAsync()95%
USP_GET_REDIRECTION_PAGENAME_SJETLead.CurrentStage + StageDefinitions100%
USP_VALIDATE_UPDATE_OTP_MOBILE_SJETOtpVerificationService + Redis100%
USP_INSERT_SMS_SEND_API_LOG_SJETapi_audit_logs + notifications100%
Usp_GetSuspiciousPhoneOrEMailIdsuspicious_contacts table check100%
USP_REDIRECT_EKYC_REVAMP_EXP_SJETLead entity with all stage data90%

9. Action Items

#PriorityActionEffort
1P0Set up client_master data sync from MOSL_FEED_CLIENT_DETAILS. Daily batch. Hash mobile/email/PAN. Include: ClientCode, IsActive, InactiveDate, Product_Type, BranchCode, Segments.2-3 days
2P0Add MOSL_FEED active client check in RegistrationService.SignupAsync(). Before creating lead, query client_master for active accounts matching mobileHash. Block if found (and not bypassed).1 day
3P0Implement mobile/email/PAN bypass service. Check client_master for bypass conditions: all-inactive, PMS-only, branch-owner, subbroker-owner. Add BypassReason field to Lead.2 days
4P0Add offline client block. Query client_master where channel=BRANCH and has active record. Block with message: "existing client of {branch} branch."0.5 day
5P0Sync dp_master from TBL_DPMASTER. Include CM_MOBILE (hashed) and CB_PANNO (hashed). Check in CBOS dedupe logic for active DP accounts.1 day
6P1Create branch_master and subbroker_master tables. Sync from MOSL_FEED_BRANCH / MOSL_FEED_SUBBROKERS. Needed for OWNER bypass.1 day
7P1Create duplicate_bypass_whitelist table. Populate with pre-approved PAN+Mobile combos from old TBL_PAN_MOBILE_EMAIL_WHITELIST.0.5 day
8P1Add DedupeClassification field to Lead entity (N/EPO/MPO/C2). Set during eligibility check.0.5 day
9P1Implement campaign-specific routing service. At minimum handle IIBLMICROSITE, AUFSB, CBI, BA Self-Direct for Day Zero.2-3 days
10P1Add multiple-lead resolution logic. Ensure max one active lead per mobileHash. Handle EPO/MPO scenarios.1 day
11P1Decide on Truecaller: if Day Zero scope, implement provider + callback. If not, remove IsTrueCaller field.1-2 days
12P2Implement Branch/RM assignment post-lead-creation service.2-3 days
13P2Decide on LeadSquare: if needed alongside Zoho, add LSQ provider. If Zoho-only, mark LSQ as deprecated.1-2 days
14P2Implement JourneyController endpoints (currently stubbed).1 day
15P2Add mobile version check endpoint if mobile app is in Day Zero scope.0.5 day
16P2Product transition logic: decide if applicable to EKYC 3.0 or out-of-scope (BRD says upgrade via eModification).Decision only
17P2Populate all reference tables: state_master, city_master, pincode_master, cvl_status_mapping, nsdl_error_master, provider_configurations.1-2 days
Summary: The new backend architecture is solid The core flows (registration, OTP, background checks, provider chain, audit logging) are well-implemented. The main gaps are around back-office integration — the old system's stored procedures did extensive lookups against MOSL_FEED tables to check if a mobile/email/PAN already belongs to an existing brokerage client. Your new system needs equivalent checks via synced reference data in client_master, dp_master, branch_master, and subbroker_master tables.