EKYC 3.0 — Stage 15: Activation (Terminal State)

Backend-Only Developer Implementation Guide • Downstream Sync + Customer Notifications + Fund Transfer + Terminal State
Stage ID: ACTIVATED (terminal) Trigger: dp_id confirmed on account_activations All Downstream: Async via Kafka Backend: .NET 8 + PostgreSQL

Table of Contents

  1. Objective
  2. Preconditions
  3. Systems Updated
  4. Customer Notifications
  5. Fund Transfer (Conditional)
  6. Backend Validations
  7. Existing SP Mapping
  8. Error Codes
  9. Exit State
  10. Vendor Calls
  11. Database Tables
  12. Notes

1. Objective

All downstream systems are updated asynchronously. The customer is notified via SMS, WhatsApp, and Email. The account is live as soon as dp_id is confirmed. No downstream failure delays activation.

Key Principle ACTIVATED is the terminal state. Once reached, the customer's account is live regardless of whether individual downstream systems succeed or fail. All downstream failures are P1 non-blocking — they are logged, alerted, and retried but never roll back activation.

2. Preconditions

Condition Required Value
lead.state ACCOUNT_CREATED
client_id Set on account_activations (assigned by CBOS)
dp_id Set on account_activations (assigned by CBOS)

3. Systems Updated

8+ downstream systems are updated via async messaging (Kafka). All updates are non-blocking — failure in any system does not prevent activation.

# System Channel Purpose
1 GCM (Global Client Manager) Kafka Register new client in global client registry
2 RIISE App Kafka Enable customer login on RIISE trading app
3 CDP (Customer Data Platform) Kafka Sync complete customer profile for personalization
4 Zoho CRM Kafka Update deal stage to "Activated" with client_id
5 DION Direct call by EKYC Exchange registration for direct trading access
6 Datalake Kafka Compliance payload for 7-year regulatory retention
7 Netcore (SMS / WhatsApp / Email) Kafka / API Customer notifications (welcome kit, credentials)
8 CBOS Kafka Activation confirmation back to CBOS
Async via Kafka All downstream updates use PublishDownstreamUpdatesAsync which publishes events to Kafka topics. Each system has its own consumer. Failures are tracked per-system in downstream_events with independent retry logic.

4. Customer Notifications

Channel SLA Content
SMS Within 2 minutes Account activation confirmation with dp_id, client_id, and RIISE app download link
WhatsApp Within 2 minutes Rich notification with account details, dp_id, client_id, and RIISE app link
Email Within 5 minutes Welcome kit email with complete account details, dp_id, client_id, and getting-started guide
Template Variables All notification templates include: dp_id, client_id, RIISE app download link, customer name. Templates are managed in Netcore and referenced by template IDs in application_config.

5. Fund Transfer (Conditional)

Fund transfer is optional and controlled by a configuration toggle. When enabled, the system initiates a fund transfer to the newly created account.

Attribute Details
Config Toggle FundTransferService with IsEnabled flag in application_config
Payment Modes NEFT, RTGS, IMPS, UPI
Simulated Mode Available for dev/test environments — generates mock fund transfer confirmations

6. Backend Validations

All failures are non-blocking No downstream failure prevents or reverses activation. All are logged as P1 incidents for ops follow-up.
# Validation / Failure Scenario Priority Action
1 GCM update failure: Client registry update fails P1 (non-blocking) Log failure, retry via downstream event mechanism, alert ops
2 RIISE race condition: RIISE queries before CBOS propagation P1 (non-blocking) RIISE should check CBOS directly. Retry with backoff.
3 DION call fails: Exchange registration does not complete P1 (non-blocking) Retry via downstream events. If persistent, P1 alert for manual registration.
4 Notification failure: SMS/WhatsApp/Email delivery fails P1 (non-blocking) Ops manual resend via notification dashboard. Retry automatically first.

7. Existing SP Mapping

Reference Only These stored procedures are from the old system. The new backend reimplements this logic in .NET 8 services. Listed here for migration reference and validation comparison.
Old Stored Procedure Purpose New Backend Equivalent
USP_UPDATE_SECONDARY_STAGE_SJET Update secondary stage flags after activation ActivationService.ActivateLeadAsync
USP_PUSH_TRADINGDETAILS_SJET Push trading details to downstream systems DownstreamEventService.PublishDownstreamUpdatesAsync
USP_GETFUNDTRANSFERFLAG_SJET Check if fund transfer is enabled for this lead FundTransferService.IsEnabledForLead
USP_FundTransfer_Request_SUPERAPP_SJET + 8 more fund transfer SPs Initiate and track fund transfers across NEFT/RTGS/IMPS/UPI modes FundTransferService.InitiateFundTransferAsync
USP_PUSH_DRISHTI_DATA_SJET Push analytics/compliance data to Drishti/Datalake DownstreamEventService.PublishDownstreamUpdatesAsync (Datalake target)

8. Error Codes

None blocking All failures in Stage 15 are P1 non-blocking. The ACTIVATED state is set regardless of downstream outcomes. There are no error codes that prevent activation.

9. Exit State

Field Value
lead.state ACTIVATED (terminal state)
lead.IsCompleted true
activated_at UTC timestamp of activation
activation_notifications_sent JSON tracking per-channel delivery status (SMS, WhatsApp, Email)
downstream_sync_status JSON tracking per-system sync status (GCM, RIISE, CDP, Zoho, DION, Datalake, Netcore, CBOS)
Terminal State ACTIVATED is the final state in the EKYC journey. Once set, lead.IsCompleted = true and no further state transitions occur. The lead is considered fully onboarded.

10. Vendor Calls

Vendor / System Call Type Purpose
GCM Async (Kafka) Register client in global client manager
RIISE Async (Kafka) Enable login on RIISE trading app
CDP Async (Kafka) Sync customer profile
Zoho CRM Async (Kafka) Update deal to Activated
DION Direct (EKYC calls) Exchange registration
Datalake Async (Kafka) Compliance payload (7-year retention)
Netcore SMS Async (Kafka/API) SMS notification with account details
Netcore WhatsApp Async (Kafka/API) WhatsApp notification with account details
Netcore Email Async (Kafka/API) Welcome kit email
CBOS Async (Kafka) Activation confirmation
Kafka Message broker Backbone for all async downstream events

11. Database Tables

Table / Entity Operation Key Columns
leads WRITE State = ACTIVATED, IsCompleted = true, ActivatedAt
account_activations READ WRITE ClientId, DpId, ActivationConfirmedAt
fund_transfers WRITE LeadId, Mode, Amount, Status, TransactionRef
downstream_events WRITE LeadId, Target, Status, RetryCount, LastAttemptAt
notifications WRITE LeadId, Channel, TemplateId, DeliveryStatus, SentAt

12. Notes

ACTIVATED is Terminal ACTIVATED is the final state. lead.IsCompleted = true. No further state transitions are possible. This is the end of the EKYC onboarding journey.
All Downstream Async Every downstream system update is asynchronous. No downstream failure blocks or delays activation. Each system's sync status is tracked independently in downstream_events and retried independently.
7-Year Retention (Datalake) The Datalake compliance payload includes the full customer profile, all KYC documents, and account details. This data must be retained for 7 years per regulatory requirements. The payload is published via Kafka and stored by the Datalake consumer.