| # | Old Function / Logic | Old File | New Equivalent | Status | Gap Details |
|---|
| 1 | No explicit "arrival" stage. Session starts at SIGNUP or GENERATEOTP. |
RegistrationController.cs |
ArrivalService.InitJourneyAsync() |
NEW |
New code adds a dedicated Stage 0 with session creation, IP velocity check, device fingerprint check, geo-location resolution, and downstream events (CLEVERTAP, DATALAKE, CDP). This is entirely new and an improvement. |
| 2 | Geo/Location: Lat/Long captured at SIGNUP via RequestJson but no server-side city/state resolution |
RegistrationController.cs (line 251-252: Latitude, Longitude params) |
ArrivalService.ResolveLocation() + DeriveLocationTag() |
NEW |
New code resolves city/state from lat/lng using a hardcoded bounding-box lookup and derives SOUTH vs OTHERS tag. Old code passed Lat/Lng but did NOT resolve them server-side - it relied on client-side values or SP logic. |
| 3 | IsSouthCitySelected flag passed from frontend |
RegistrationController.cs (line 193) |
ArrivalService.DeriveLocationTag() |
PRESENT |
Old code accepted IsSouthCitySelected from client. New code derives it server-side (more secure). Equivalent business logic. |
| 4 | SuperApp detection via ISSUPERAPP flag in JWT token |
LoginController.cs (line 327: ISSUPERAPP from JWT) |
ArrivalService.cs (line 106-109: AppName check) |
PRESENT |
Old code relied on JWT param ISSUPERAPP. New code detects via AppName in (SUPERAPP, MORISE, RISE). Both achieve same goal. |
| 5 | IP velocity / fraud check - not present at arrival |
N/A |
ArrivalService.CheckIpVelocityAsync() |
NEW |
New code checks if >3 sessions from same IP in 1 hour. Old code had no IP velocity check at arrival. |
| 6 | Device fingerprint / bot detection - not present |
N/A |
ArrivalService.EvaluateDeviceFingerprint() |
NEW |
New code detects HEADLESS/PHANTOM/SELENIUM/PUPPETEER browsers and BOT/CRAWLER device types. Old code had none. |
| 7 | Referral code validation at session level |
N/A (validated later at signup) |
ArrivalService.cs (line 161-178) |
NEW |
New code validates referral code against referral_codes table at session init. Old code only passed it through to SP at signup. |
| 8 | UTM parameters captured |
RegistrationController.cs (lines 200-212: utm_Source, utm_Medium etc.) |
ArrivalService.cs (LeadSession entity stores all UTM fields) |
PRESENT |
Both capture full UTM set. New code stores them in a normalized LeadSession entity. |
| # | Old Function / Logic | Old File | New Equivalent | Status | Gap Details |
|---|
| 9 | SIGNUP_OLD: Synchronous signup with 60+ parameters |
RegistrationController.cs (line 86-377) |
RegistrationService.SignupAsync() |
PRESENT |
New code has equivalent logic in CreateLeadCommand. Parameter mapping is cleaner but covers the same fields. |
| 10 | NRI + MOMEAST branch forces ApplicationType=DIRECT |
RegistrationController.cs (lines 99-105, 390-395) |
RegistrationService.cs (lines 92-96) |
PRESENT |
Both handle NRI + MOMEAST -> DIRECT routing identically. |
| 11 | IFAFINCARE AppLoginId forces ApplicationType=CRM, FlowType=DIY |
RegistrationController.cs (lines 107-112) |
N/A |
MISSING |
Old code checks if AppLoginId=="IFAFINCARE" and overrides to CRM/DIY. New code does NOT have this special-case routing. |
| 12 | FSFB3IN1 campaign forces FlowType=APP |
RegistrationController.cs (lines 113-116) |
CampaignRoutingService.cs |
MISSING |
Old code sets FlowType=APP for CampaignName=="FSFB3IN1". New CampaignRoutingService only handles INDUSIND, IIBL, AUFSB, CBI. FSFB3IN1 is missing. |
| 13 | BA Prospect (PP + BACODE) sets AppLoginId=BACODE |
RegistrationController.cs (lines 118-125) |
RegistrationService.cs (lines 104-107) |
PRESENT |
Both map BaCode to AppLoginId for PP application type. |
| 14 | Input validation: CheckDangerousString (SQL injection check) |
RegistrationController.cs (line 142,412) |
RegistrationService.ValidateInput() (regex-based) |
PARTIAL |
Old code used CheckDangerousString for SQL injection patterns on all fields. New code validates mobile (regex ^[6-9]\d{9}$) and name (alpha+spaces). No explicit SQL injection check - but parameterized EF Core queries mitigate this. No dangerous-string check for other fields like email, city, etc. |
| 15 | Phone validation: chk_PhoneNo() and chk_PhoneNo_NRI() with separate NRI regex |
RegistrationController.cs (lines 142-153) |
RegistrationService.ValidateInput() MobileRegex |
PARTIAL |
Old code had separate validation for NRI phone numbers (international format). New code only validates Indian 10-digit mobile (^[6-9]\d{9}$). NRI phone number validation is missing. |
| 16 | Suspicious phone/email check (Usp_GetSuspiciousPhoneOrEMailId) |
LoginController.cs (lines 536-548: GENERATEOTP, lines 335-336: GENERATEEMAILOTP) |
RegistrationService.cs (lines 152-161: suspicious_contacts check) |
PARTIAL |
Old code BLOCKS registration if phone is suspicious (Status==0 returns error). New code only LOGS a warning but does NOT block. This is a significant behavioral difference. |
| 17 | Offline client check (Check_Direct_Offline_Client_EXP) |
LoginRepository.cs (line 163: dtOffline check) |
RegistrationService.cs (line 164: backOfficeCheck.CheckOfflineClientAsync) |
PRESENT |
Both block online journey for branch offline clients with branch-name message. |
| 18 | CBOS dedupe: existing client detection |
LoginRepository.cs (RESUME_AUTHENTICATE_USER_OTP_PASS SP) |
RegistrationService.CheckCbosDedupeAsync() |
PRESENT |
Both check for existing active accounts. New code uses client_master table directly instead of SP. |
| 19 | Bypass logic: USP_BYPASS_MOBILE_EMAIL_PAN_SJET (INACTIVE, PMS, OWNER_BRANCH, WHITELIST) |
LoginRepository.cs (line 1008-1016: getExistingCutomerDT for email bypass) |
BackOfficeCheckService.CheckBypassEligibilityAsync() |
PRESENT |
New code implements INACTIVE, PMS, OWNER_BRANCH, OWNER_SUBBROKER, WHITELIST bypass rules. Equivalent to old SP logic. |
| 20 | Lead Dedupe: 90-day inactive lead deletion + LSQ dormant + SuperApp cloud delete |
CommonRepository.cs (GetLeadDedupe, GetLeadDedupeForAllVerticals, lines 144-602) |
RegistrationService.ArchiveOlderDuplicateLeadsAsync() |
PARTIAL |
Old code does: (1) Check eligible for lead transfer, (2) Make LSQ lead dormant, (3) Delete cloud details via SuperApp API, (4) Delete existing lead from DB, (5) Zoho dormant for Zoho leads. New code only archives leads (sets state=ARCHIVED). Missing: LSQ dormant call, SuperApp cloud delete, Zoho dormant call. |
| 21 | Negative list check |
LoginController.cs (Usp_GetSuspiciousPhoneOrEMailId) |
RegistrationService.CheckNegativeListAsync() |
IMPROVED |
New code checks both mobile hash AND IP address against negative_list table with expiry support. Old code only checked phone/email via SP. New approach is more comprehensive. |
| 22 | Restricted mobile check (block specific numbers) |
N/A (done inside SP) |
RegistrationService.cs (lines 136-148: restricted_mobiles table) |
NEW |
New code has a dedicated restricted_mobiles table check before dedupe. Old code handled this inside stored procedures. |
| 23 | CRM/MFD Product switch checking on resume |
RegistrationController.cs (lines 311-343: CRMMFDProductUpdation) |
N/A |
MISSING |
Old code checks if existing lead has different product (MFD/EQUITY/EQUITY_MFD) and allows product switch. New code has no MFD product switching logic. |
| 24 | Return URL construction: SJET/JET/EXPRESS/DIY URLs with encrypted params |
RegistrationController.cs (lines 293-303), LoginRepository.cs (lines 767-788) |
N/A |
MISSING |
Old code builds encrypted return URLs (RESUME_URL_SJET, RESUME_URL_EXPRESS, TRADING_URL, FranchiseeDiyUrl) based on journey type. New code does not generate return URLs - new frontend likely uses SPA routing. |
| 25 | Privilege client detection (IsPrivilege) with redirect to TRADING_URL |
RegistrationController.cs (lines 301-303) |
N/A |
MISSING |
Old code detects privileged/existing trading clients and redirects them to the trading platform URL. New code does not have this concept. |
| 26 | Multiple user check (CHECK_MULTIPLE_USER_EXISTS) |
LoginRepository.cs (lines 402-414) |
BackOfficeCheckService.CountActiveLeadsAsync() |
PARTIAL |
Old code detects multiple users with same mobile and shows selection UI (MultipleUser="1"). New code detects multiple leads and archives older ones. Different approach: old=user picks, new=auto-archives. |
| 27 | Consent handling (3 explicit consents validated) |
Not explicit in old code (SP-level) |
RegistrationService.ValidateInput() + SaveConsentsAsync() |
IMPROVED |
New code explicitly validates ConsentAccountOpening, ConsentTerms, ConsentCommunication and stores them in consents table. Old code had consent as implicit SP parameters. |
| # | Old Function / Logic | Old File | New Equivalent | Status | Gap Details |
|---|
| 28 | AUTHENTICATELOGIN: OTP verification with password decrypt, max attempts |
LoginController.cs (lines 468-517), LoginRepository.cs (lines 118-509) |
RegistrationService handles OTP via OtpVerificationService (separate) |
PARTIAL |
Old AuthenticateLogin does: decrypt OTP, call RESUME_AUTHENTICATE_USER_OTP_PASS SP, validate, then call PerformLogin. New code has SignupAsync with OTP send + separate OTP verify flow. The actual OTP validation logic is in a different service (OtpVerificationService, not in Stage1 file). |
| 29 | TrueCaller login: IsTrueCaller flag + TRUECALLER_EKYC_LOG |
LoginRepository.cs (lines 190-202) |
ArrivalService stores IsTrueCaller on LeadSession |
PARTIAL |
Old code logs TrueCaller events and skips OTP for TrueCaller-verified users. New code captures IsTrueCaller flag but does NOT implement TrueCaller OTP skip or dedicated logging. |
| 30 | Zoho lead creation post-OTP (createLeadId_Zoho) |
LoginRepository.cs (lines 226-319) |
RegistrationService.PublishDownstreamEventsAsync (ZOHO_CRM target) |
PARTIAL |
Old code calls Zoho API directly to create/update lead after OTP validation. New code creates a PENDING downstream event for ZOHO_CRM. Actual Zoho API call implementation is not in this service - needs a downstream event processor. |
| 31 | LSQ (LeadSquared) lead creation + opportunity |
LoginRepository.cs (lines 228-318: full LSQ field mapping) |
RegistrationService.PublishDownstreamEventsAsync |
PARTIAL |
Old code directly calls LeadSquare API with 50+ mapped fields. New code creates downstream events. The detailed LSQ field mapping (PSource, UTM params, Referee details, DAD advisor) is NOT in the new code event payload. |
| 32 | PerformLogin: GET_CLIENT_BOSTATUS, segment determination (EQ/COMM/EQCOMM) |
LoginRepository.cs (lines 582-604) |
N/A |
MISSING |
Old code calls GET_CLIENT_BOSTATUS to determine segment status (Equity, Commodity) and sends email notification to assigned agent on login. New code does not have segment-based email notification. |
| 33 | PerformLogin: Email notification to agent on login (SEND_EMAIL_ONLOGIN) |
LoginRepository.cs (lines 606-631) |
N/A |
MISSING |
Old code sends HTML email to AgentEmailId/TeamLeaderEmail when lead logs in. New code has no agent notification on login. |
| 34 | PerformLogin: UPDATEOTPEMAILSTAGE (stage progression) |
LoginRepository.cs (line 641) |
JourneyTracker.RecordStateTransitionAsync() |
PRESENT |
Both track stage progression. New code uses explicit state machine transitions. |
| 35 | PerformLogin: GetRedirectionPageName (determine resume page) |
LoginRepository.cs (lines 646-686) |
N/A |
MISSING |
Old code calls SP to determine which page to redirect resuming user to (ESIGN, KRAESIGN, PERSONALDETAIL etc). New code does not have page-level resume redirection - relies on frontend state. |
| 36 | PerformLogin: GET_ISOCRFLAG (OCR user, MFD, ISJET flags) |
LoginRepository.cs (lines 696-732) |
N/A |
MISSING |
Old code checks OCR status, MFD flag, ISNEWREVAMP, ISSUPERJET_OpenMobileApp to determine user journey type. New code stores JourneyVariantId but does not have equivalent OCR/MFD/revamp flag checks. |
| 37 | PerformLogin: JWToken generation with full claim set |
LoginRepository.cs (lines 747-757) |
N/A (handled by auth middleware) |
PARTIAL |
Old code generates JWT with 20+ custom claims (UserId, IsBRBA, BranchEmpCode, TokenKey, DeviceType, etc.). New code presumably uses a separate auth service. Not visible in Stage1 code. |
| 38 | PerformLogin: KRA/Esign pending check (Check_KRA_Esign_Pending) |
LoginRepository.cs (lines 791-806) |
OtpVerificationService.CheckKraEsignPendingAsync() |
FIXED |
Checks if AOF generated but eSign not completed. Returns KraEsignPending=true + ResumePage="ESIGN" in VerifyOtpResult. Runs on both normal OTP verify and RM-bypass paths. |
| 39 | Background PAN validation via Zintler API (CallPanValidateAPIInBackground) |
LoginRepository.cs (lines 511-543) |
N/A |
MISSING |
Old code calls PAN validation API in background thread after successful login. New code does PAN at a later stage but not at login completion. |
| 40 | CRMSTAGEUPDATE / CRMSTAGEUPDATE_NRI - LeadSquared stage sync |
LoginRepository.cs (lines 462-469) |
N/A (downstream event) |
PARTIAL |
Old code calls LeadSquared API to update stage to OTPMOBILE (different for NRI). New code creates downstream event but doesn't explicitly map OTPMOBILE stage to LSQ. |
| # | Old Function / Logic | Old File | New Equivalent | Status | Gap Details |
|---|
| 41 | GENERATEEMAILOTP: Email OTP with suspicious email check + domain validation + real-time email validation |
LoginController.cs (lines 314-362), LoginRepository.cs (lines 840-1122) |
Stage 3: EmailVerificationService.InitiateEmailVerificationAsync() |
IMPLEMENTED IN STAGE 3 |
All checks present in Stage 3: (1) suspicious email BLOCK, (2) regex + custom format validation, (3) restricted domain check, (4) allowed domain whitelist bypass, (5) email dedupe + bypass check, (6) IIBL auto-skip. Cybridge/Karza excluded per product decision. Not in Stage 1 by design — email is a separate stage in the new architecture. |
| 42 | GENERATEEMAILOTP_NRI: Separate NRI email OTP flow |
LoginController.cs (lines 367-379) |
Stage 3: EmailVerificationService (NRI branch) |
IMPLEMENTED IN STAGE 3 |
NRI email flow implemented: CheckNriEmailDedupeAsync (email+InterestedIn dedupe against leads + client_master), forced MANUAL_OTP path (no KRA/Google shortcuts), suspicious email block. No separate endpoint needed — same endpoint with IsNri flag on Lead. |
| 43 | VALIDATEOTPEMAIL / VALIDATEOTPEMAIL_NRI |
LoginController.cs (lines 382-445) |
Stage 3: EmailVerificationService.VerifyEmailOtpAsync() |
IMPLEMENTED IN STAGE 3 |
Email OTP verification with max attempts, lockout, resend cooldown all present. Suspicious email blocking already applied at initiation. NRI uses same verify endpoint. |
| 44 | GETJWTTOKENID: Standalone JWT generation endpoint |
LoginController.cs (lines 264-310) |
Program.cs: AddAuthentication + JwtBearer middleware |
N/A — ARCHITECTURE CHANGE |
Old code had a custom GETJWTTOKENID endpoint generating JWTs with 20+ claims. New code uses standard ASP.NET Core JwtBearer middleware configured in Program.cs. JWT generation is handled by the auth infrastructure, not a custom endpoint. No gap — different architecture. |
| 45 | INIT (Login): GetClientDetails - returns page name, client details for resume |
LoginController.cs (lines 101-138), LoginRepository.cs (lines 1718-1788) |
Stage 1: RegistrationService.GetResumeStateAsync() + GET /api/v1/registration/resume/{leadId} |
FIXED |
Resume endpoint implemented with MapStateToResumePage (20+ state mappings), journey flags (IsNri, IsSuperApp, EsignPending, JourneyVariantId), and KRA esign pending check. |
| 46 | RESUMEFORM: Build resume URL with encrypted params |
LoginController.cs (lines 688-720) |
HandoffLinkService + SaathiShortUrlProvider |
N/A — ARCHITECTURE CHANGE |
Old code built encrypted resume URLs for multi-page MPA. New code is SPA — frontend reads ResumePage from GetResumeStateAsync and routes client-side. HandoffLinkService exists for RM-to-lead handoff links (different use case). No gap. |
| 47 | REDIRECTTOPAGE: Page redirect logic |
LoginController.cs (lines 666-683) |
N/A |
N/A — ARCHITECTURE CHANGE |
Server-side page redirects are not needed in the new SPA architecture. Frontend uses ResumePage from the resume endpoint to route. No gap. |
| 48 | SENDSMS: Generic SMS send endpoint |
LoginController.cs (lines 561-576), LoginRepository.SendSMS() |
NetcoreSmsProvider + SmsTemplateService |
PARTIAL — NO GENERIC ENDPOINT |
SMS sending capability exists (NetcoreSmsProvider.SendSmsAsync + SmsTemplateService) and is used for OTP delivery. However, there is no standalone generic “send any SMS” API endpoint. Old endpoint was used for ad-hoc SMS by ops. Low priority — can be added to Admin controller if needed. |
| 49 | PUSHDATAINDRISHTI: Push data to Drishti system |
LoginController.cs (lines 627-660) |
N/A |
N/A — DEPRECATED |
Drishti analytics platform integration is not carried forward. New code uses downstream events to CLEVERTAP + DATALAKE + CDP for analytics. Drishti was an internal calling system — replaced by CRM downstream events. |
| 50 | LEADDELETECLOUD: External lead deletion API |
LoginController.cs (lines 71-96), LoginRepository.LEADDELETECLOUD() |
LeadDeletionService.AnonymizeLeadAsync() |
PARTIAL |
New code anonymizes PII (nullifies name, mobile, email, IP) and sets state=DELETED. Old code also called a SuperApp cloud deletion API. Cloud deletion not implemented — only relevant if SuperApp stores a separate copy. Low priority if SuperApp reads from the same DB. |
| # | Old Function / Logic | Old File | New Equivalent | Status | Gap Details |
|---|
| 56 | VALIDATEREFERALCODE: Dedicated referral code validation endpoint |
RegistrationController.cs (lines 633-648) |
RegistrationService.cs (lines 385-403: inline referral validation) |
PARTIAL |
Old code has separate endpoint returning referral details. New code validates inline during signup + client_master fallback. No separate endpoint for pre-signup validation. |
| 57 | BINDSTATE / BINDCITY: State and city dropdowns |
RegistrationController.cs (lines 651-680) |
N/A |
MISSING |
Old code has endpoints to get state/city lists. New code resolves from GPS. If user cannot share location, no city/state dropdown fallback exists. |
| 58 | GETUSERDATA_TRUECALLER: TrueCaller user data fetch |
RegistrationController.cs (lines 579-596), Services/RegistrationRepository.cs (lines 98-200+) |
N/A |
MISSING |
Old code fetches user data from TrueCaller API (name, phone, email). New code captures IsTrueCaller flag but does NOT fetch TrueCaller user data. |
| 59 | TRUECALLERCALLBACK: TrueCaller callback handler |
RegistrationController.cs (lines 619-629) |
N/A |
MISSING |
Old code handles TrueCaller SDK callback. Not present in new code. |
| 60 | GETBADIYDETAIL: BA/DIY detail lookup by GUID |
RegistrationController.cs (lines 554-576) |
N/A |
MISSING |
Old code looks up BA/DIY details by GUID for pre-fill. Not in new code. |
| 61 | NRIGETPINCODEDETAILS: NRI pincode validation |
RegistrationController.cs (lines 599-614) |
NriValidationService.cs (exists in Common) |
PARTIAL |
Old code validates NRI pincode against state/city. New code has NriValidationService but specific pincode validation needs verification. |
| 62 | JOINTACCOUNTHOLDEROPTION: Joint account holder option |
RegistrationController.cs (lines 531-549) |
N/A |
MISSING |
Old code had joint account holder option endpoint at registration stage. New code handles joint/minor at later stages only. |
| 63 | DIY_HelpRequest: Predictive help request + LSQ activity log |
CommonRepository.cs (lines 42-142) |
N/A |
MISSING |
Old code tracks DIY help requests, logs to DB, calls LSQ activity API with business-hours message logic. Not in new code. |
| 64 | CheckNameandDOBMismatch: PAN re-verification via NSDL |
CommonRepository.cs (lines 243-334) |
N/A (later stage) |
MISSING |
Old code re-verifies PAN name/DOB via NSDL if days post verification threshold exceeded. Not visible in Stage 0/1 new code. |
| 65 | Zoho lead deletion (DeleteLead_Zoho) with token refresh |
CommonRepository.cs (lines 417-532) |
N/A |
MISSING |
Old code has Zoho lead deletion with OAuth token management, retry on INVALID_TOKEN. New code has no Zoho delete implementation. |
| 66 | ISALLOWREDIRECT: Check if redirect is allowed |
LoginController.cs (lines 594-609) |
N/A |
MISSING |
Old code always returns "1" (allowed). Likely deprecated. Not needed in new code. |
| 67 | GetShortURL: URL shortener endpoint |
LoginController.cs (lines 578-591) |
N/A |
MISSING |
Old code has URL shortening endpoint. Not in new code. |
| 68 | GETONEMONEYFIPLIST: One Money FIP list |
LoginController.cs (lines 613-622) |
N/A |
MISSING |
Old code fetches One Money FIP list. Likely out of scope for new eKYC. |
| 69 | GENERATEPDFMANUALLY: Manual PDF generation |
LoginController.cs (lines 724-737) |
N/A |
MISSING |
Old code triggers manual PDF generation for client. Not in new Stage 0/1 code. |
| 70 | GetHolderMobileDetails: Joint holder mobile details |
LoginController.cs (lines 227-259) |
N/A |
MISSING |
Old code fetches mobile details for joint account first/second holder. Not in Stage 1 new code. |
| # | Gap | Risk | Status |
|---|
| 1 | Suspicious phone check blocks vs logs-only (#16) | HIGH | FIXED - now blocks with MOBILE_SUSPICIOUS error |
| 2 | NRI phone validation missing (#15) | HIGH | FIXED - NriMobileRegex added (7-15 digits, optional +) |
| 3 | Lead dedupe missing LSQ/Zoho/SuperApp cleanup (#20) | HIGH | N/A - LSQ is out of scope. Zoho handled by downstream events. |
| 4 | TrueCaller OTP skip not implemented (#29) | MEDIUM | N/A - TrueCaller not required per product decision |
| 5 | IFAFINCARE/FSFB3IN1 campaign routing missing (#11,#12) | MEDIUM | FIXED - Added to CampaignRoutingService (CRM/DIY + APP) |
| 6 | Agent email notification on login missing (#33) | MEDIUM | FIXED - NotifyAgentOnLoginAsync in OtpVerificationService (fire-and-forget) |
| 7 | No INIT/resume endpoint equivalent (#45) | HIGH | FIXED - GetResumeStateAsync + GET /api/v1/registration/resume/{leadId} |
| 8 | State/City dropdown fallback missing (#57) | MEDIUM | FIXED - GET /api/v1/master/states + /cities/{stateCode} |
| 9 | MFD cross-vertical dedupe blocking (#23) | HIGH | FIXED - CheckMfdCrossVerticalDedupeAsync blocks if MFD/EQUITY_MFD exists |
| 10 | Resume page determination / OCR-MFD-revamp flags (#35,#36) | HIGH | FIXED - MapStateToResumePage + journey flags in ResumeStateResult |