Screen 1: Mobile / Email Registration

The client has just opened the application for the first time. They do not have a trading account yet, and they may be unfamiliar with the regulatory machinery that stands between them and their first trade. The very first screen asks for one thing: their mobile number. Mobile verification is required for OTP-based Aadhaar authentication and KRA communication throughout the onboarding process.

1 Mobile / Email Registration

Purpose: Establish the identity anchor and OTP (One-Time Password) communication channel before any KYC data is captured.

Every subsequent step — PAN (Permanent Account Number) verification, KRA (KYC Registration Agency) lookup, DigiLocker (Government of India’s digital document platform) authentication, eSign (electronic signature via Aadhaar OTP) — relies on the ability to send the customer an OTP. Without a verified mobile number, the entire pipeline has no communication channel.

User Input

The customer types a single field.

Field	Validation	Notes
Mobile Number (10 digits)	10 digits starting with 6-9	OTP sent via SMS for verification

Fallback: Email registration if mobile OTP fails 3 times.

On registration, device risk assessment fires asynchronously — risk signals including emulator detection, root detection, and synthetic identity checks.

Why start with mobile?

Mobile number is the universal communication channel for OTPs, KRA verification, CKYC (Central KYC), and all post-onboarding notifications. Establishing it first ensures every subsequent step has a verified contact channel.

While the customer is looking at the OTP input field, the system initiates a background device risk assessment to detect potentially fraudulent devices.

What Fires Async

Service	What It Does
Device Risk Assessment	Detects emulators, rooted devices, synthetic identities, and coordinated fraud patterns. Results feed into AML/fraud evaluation at the Blocking Gate.

This device intelligence layer runs silently in the background. No user interaction required. Results feed into the AML/fraud evaluation at the Blocking Gate (Screen 8).

OTP delivery failures

If the SMS OTP does not arrive within a reasonable window, the customer can request a resend. After 3 failed attempts, the system should offer email-based registration as a fallback. Do not let OTP delivery issues become a dead end — mobile network congestion is common in India, especially during market hours.

At this point, the system has everything it needs to move forward. The customer has proven they control this mobile number, and the device has been assessed for fraud risk.

Data Captured

After this screen, the system has:

• Verified mobile number (OTP-confirmed)
• Device risk assessment results
• Session identifier for all subsequent API calls

For vendor implementation options, see Vendor Integrations.

What happens next

The customer moves to Screen 2, where they will enter their PAN and date of birth. Those two fields unlock four parallel API calls that form the backbone of the entire KYC verification. But none of that would be possible without the verified mobile number established here.