Design Principles

This page documents the regulatory and architectural constraints that govern every decision in the KYC (Know Your Customer) onboarding system. These constraints emerge from Indian securities regulation (SEBI circulars, PMLA rules, IT Act 2000), the capabilities of government identity infrastructure (DigiLocker, Aadhaar, CKYC), and the operational requirements of KRA/exchange/depository submissions. When you encounter a design choice elsewhere in the docs, the rationale traces back to one of these constraints.

Regulatory Design Constraints

#	Constraint	Regulatory Basis
1	Mobile verification required for OTP-based authentication	Mobile OTP establishes the identity anchor and communication channel required for KRA verification, eSign authentication, and post-onboarding notifications per SEBI KYC norms.
2	Government identity sources for IPV exemption	Aadhaar eKYC via DigiLocker consent provides IPV exemption per SEBI/HO/MIRSD/DOP/CIR/P/2020/73. Identity fields are sourced from government-issued digital documents.
3	Aadhaar eKYC without Aadhaar number collection	DigiLocker consent flow provides Aadhaar eKYC without requiring the intermediary to collect or store the Aadhaar number, in compliance with Aadhaar Act Section 29 restrictions.
4	Government data sources reduce manual entry errors in regulatory submissions	DigiLocker, KRA, and CKYC data sources pre-populate identity and financial fields, reducing discrepancies in KRA/CKYC/UCC submissions that lead to rejections.
5	Parallel verification against regulatory databases	PAN verification, KRA lookup, CKYC search, and AML screening execute in parallel against respective regulatory databases without blocking customer progression.
6	Data quality: fewer manual entries reduce KRA/exchange rejections	Customer-entered fields are limited to data unavailable from any government or regulatory source (mobile, email, bank account details, segment preferences).
7	Digital signature per IT Act 2000, Section 3A	Single Aadhaar OTP-based electronic signature on the complete application, legally valid under IT Act 2000 Section 3A and SEBI eSign guidelines. No physical signatures required.
8	Regulatory agency submissions after dual-control approval	KRA, CKYC, UCC, and BO account submissions are processed in batch after maker-checker approval, per SEBI dual-control requirements for account opening.
9	IPV exemption via Aadhaar eKYC	Aadhaar eKYC through DigiLocker exempts In-Person Verification (IPV) and Video In-Person Verification (VIPV) per SEBI/HO/MIRSD/DOP/CIR/P/2020/73.
10	Progressive disclosure of conditional fields	Fields are shown only when relevant to customer selections (e.g., income proof for F&O/Commodity segments, FATCA declarations for tax residency, PEP declarations).
11	Pre-submission validation gate	All blocking regulatory checks (PAN status, KRA status, AML screening, bank verification) must pass before the customer proceeds to eSign. Applications failing mandatory checks are stopped early with clear remediation guidance.

Tip

These constraints directly map to the 9-screen user journey. Each screen collects the minimum required input while sourcing remaining data from government and regulatory databases.

Constraints are mandatory, not advisory

When building a new feature or modifying an existing screen, verify compliance against these constraints. If a change requires manual entry of a field available from a government source, it violates Constraint 4. If a change adds a synchronous API call to the customer’s critical path, it violates Constraint 5. Use this table as a checklist during code reviews and design discussions.

The constraints are not independent — they reinforce each other in a specific pattern. Understanding how they connect will help you see the system as a whole rather than a collection of screens.

How Constraints Connect

The constraints work together as a system:

• Constraints 1-3 establish the identity foundation (mobile verification, government identity sources, Aadhaar eKYC)
• Constraints 4-6 ensure data quality and completeness from authoritative sources
• Constraints 7-8 handle completion (digital signature, batch submission to regulatory agencies)
• Constraints 9-11 enforce regulatory compliance (IPV exemption, conditional disclosures, pre-submission validation)

Do not add synchronous calls to the customer path

The most common architectural mistake in KYC systems is making the customer wait for an API response before they can proceed. If you find yourself writing code that blocks screen navigation on an API call, stop and reconsider. Constraint 5 (parallel verification) exists because external API response times are variable, and that variability must not block customer progression through screens where the response is not yet required.