DEV Community: amandeep

Authorised Person onboarding automation for SEBI-registered brokers

amandeep — Tue, 14 Jul 2026 05:00:22 +0000

Originally published at finovo.tech/blog/ap-onboarding-automation — the canonical version has the latest updates.

Authorised Persons (APs) — formerly called sub-brokers — are the field force of most Indian brokers. SEBI mandates a specific onboarding process before an AP can transact on a broker's behalf:

Individual KYC of the AP
NISM-VIII (Equity Derivatives) certification (where required)
NSE and / or BSE registration as that broker's AP
AP code allocation
Indemnity bond
Customer-handling permissions config

Each step used to be paper. Each one took 1-2 weeks. The full chain often took 4-6 weeks per AP — which is why brokers tend to onboard APs in batches and why APs sit idle for the first month or two.

AP onboarding compresses this to under 5 working days.

The KYC step

Same individual KYC flow as a customer, but on the AP onboarding flow. Aadhaar OTP + PAN + video PD. APs are typically professionals (CFP, MBA, etc.) so they tend to complete this in under 2 minutes.

NISM certification check

For APs handling derivatives, NISM-VIII certification is mandatory. The flow asks for the AP's NISM certificate ID and validates against the NISM database (NSE has a published API). If the AP doesn't have it, the flow blocks onboarding for derivatives but allows equity-only onboarding.

NSE / BSE registration

This is where the digital flow really helps. Each exchange has an AP registration system:

NSE: NEAT-ID-based AP registration
BSE: BTN-based AP registration

Both require the broker to file Form-A (or its modern digital equivalent) on the exchange portal, naming the AP. The exchanges return an AP code within 1-3 days.

The AP onboarding flow handles the form filing automatically. The broker's ops team sees the AP code arrive in their inbox; they don't have to type it into anything.

AP code allocation

Once the exchange returns the AP code, it's allocated in the broker's system to:

A region (so geography-based commissions work)
A team / RM (so reporting hierarchies work)
A product permission set (equity-only / derivatives / both)

This is broker-policy work, not regulator work — but the flow has the config UI to do it.

Indemnity bond

The AP signs an indemnity bond protecting the broker from AP-side mistakes. Standard SEBI-approved bond template; we host it as a PDF, the AP signs via Aadhaar e-sign.

Customer-handling permissions

Once active, the AP gets:

A unique customer-onboarding referral code (so customers brought in by this AP are automatically tagged to them)
A login to the broker's RM dashboard (read-only by default; full access on broker policy)
A commission-tracking page showing their revenue share in real-time

Bulk onboarding

Most brokers add APs in waves — 50-200 APs after a hiring round. The flow supports CSV upload of basic AP details; each AP then gets an SMS / email link to complete their own onboarding flow. This way the broker's ops team doesn't have 200 KYC sessions to chaperone.

Compliance reporting

SEBI requires brokers to report AP activity periodically. The AP onboarding flow captures the data points needed for the report — number of APs onboarded per quarter, geographic distribution, NISM certification rate — and outputs the SEBI-format CSV on demand.

For a deeper dive, see our trading automation api nse.

What it replaces

The typical AP onboarding workflow before:

HR shortlists the AP
HR hands a 30-page packet to the AP
AP fills + signs + couriers back
HR forwards to compliance
Compliance forwards to NSE / BSE
1-3 weeks later, AP code arrives
Compliance allocates the code to a region / team
AP starts working

After:

HR enters AP details into the dashboard
AP receives a link, completes online flow in 30-45 minutes
Exchange-side filing automatic
AP code arrives in the dashboard (1-3 days, regulator latency)
Allocation happens at AP-code arrival
AP starts working

5-day vs 21-30-day onboarding. The customer-facing impact is that APs reach productive headcount faster.

PMS individual eKYC: SEBI-aligned account opening

amandeep — Tue, 14 Jul 2026 05:00:17 +0000

Originally published at finovo.tech/blog/pms-individual-ekyc — the canonical version has the latest updates.

Portfolio Management Services (PMS) is one of SEBI's regulated investment categories — your customer is investing 50 lakh+ minimum and the portfolio manager is making active decisions on their behalf. The regulatory bar is correspondingly higher than retail KYC.

PMS individual eKYC handles the regulatory delta.

What's different from retail KYC

A standard individual KYC packet doesn't cut it for PMS. SEBI requires:

The full retail KYC (Aadhaar / PAN / video PD)
A SEBI-specified suitability questionnaire that the customer fills out themselves (not by the RM)
A fee structure disclosure document signed by the customer
A risk profiling questionnaire
Aadhaar e-sign on the PMS agreement (not just digital signature — actual e-sign with UIDAI)
Disclosure of any related-party transactions
The customer's investment objective in their own words

Each is a SEBI checklist item. Missing any gets the account opened but red-flagged on the next inspection.

The suitability questionnaire

This is the most-watched part of PMS onboarding. SEBI is explicit that the questionnaire must be:

Filled by the customer, not the RM (you can't auto-pre-fill)
Time-stamped with each answer
Reviewed by the portfolio manager (logged review event)
Re-administered on any material change in the customer's financial position

The PMS eKYC flow renders the SEBI-spec questionnaire (we maintain the latest version) with each answer's timestamp logged. The portfolio manager reviews via a desktop tool; review action is logged. If the customer skips a question, the flow rejects the submission.

Fee structure disclosure

The fee structure has to be disclosed before the customer signs the PMS agreement — not as an annex, not in the agreement, but as a separately signed document. The customer ticks "I have read and understood the fee structure" with timestamp. The fee schedule is generated dynamically from the portfolio manager's product config, so we don't show wrong fees.

Aadhaar e-sign on the agreement

A digital signature pad isn't sufficient for the PMS agreement — SEBI requires Aadhaar-based e-sign (UIDAI eSign API). This adds an extra step in the flow:

Customer enters Aadhaar
UIDAI sends OTP
Customer enters OTP
UIDAI returns a signed XML
The signed XML is embedded in the PMS agreement PDF
The signed PDF is the master copy stored

The customer never has to print or scan anything. Total e-sign step: 30-45 seconds.

Related-party transactions

If the customer is in any way related to the portfolio manager or its directors, that has to be disclosed. The flow asks:

Are you related to any portfolio manager / director / employee of [PMS firm]?
If yes, describe the relation

A "yes" doesn't block the account; it triggers a compliance-officer review event before the account goes live.

Customer's investment objective

In their own words. This is a free-form text field that the portfolio manager reviews. SEBI's principle is that the customer's stated objective must align with the portfolio manager's strategy — and a one-line "I want returns" doesn't satisfy that. We show example phrasings as placeholders, but force the customer to type their own.

What the broker / PMS firm avoids

Without an integrated PMS eKYC, PMS firms handle this with:

A 30-page paper packet emailed to the customer
A compliance officer reviewing each step manually
A 2-3 week turnaround per account
An ops team that re-types data into the back-office system

After integration:

Single self-serve flow (still requires real customer attention — this isn't 90 seconds; PMS suitability is meant to be deliberate)
Compliance officer review queue, not full manual handling
2-3 day median turnaround
Direct write-through to back-office

Compliance checklist verifier

We bundle a SEBI-checklist-aware verifier that runs on every PMS account before it can go live. It enumerates the SEBI-required items, checks each is captured + signed + timestamped, and refuses to mark the account active if any are missing. This is a hard gate, not a warning.

NRE / NRO eKYC: NRI onboarding under FEMA compliance

amandeep — Mon, 13 Jul 2026 05:00:23 +0000

Originally published at finovo.tech/blog/nre-nro-ekyc-fema-compliance — the canonical version has the latest updates.

NRI account opening is the highest-stakes KYC in Indian finance. The customer is high-net-worth, the ticket size is large, and the compliance surface is massive: SEBI + RBI's FEMA + the customer's country-of-residence regulator + FATCA + tax-residence implications.

Most brokers' NRI onboarding is still manual — a relationship manager and a compliance officer working together over email for 2-3 weeks per customer.

Digital NRI onboarding (NRE/NRO eKYC) compresses this to a single end-to-end flow.

The account types

There are three flavours of NRI account a broker typically opens:

NRE (Non-Resident External): USD-rupee account, repatriable. Used for fresh foreign earnings the NRI wants to invest in India.
NRO (Non-Resident Ordinary): Rupee account, restricted repatriation (currently $1M / year). Used for income earned in India (rent, dividends, etc.).
NRO-PIS (Portfolio Investment Scheme): A specific NRO sub-type for stock-market investments, mandatory designation per RBI.

Each has different documentation requirements and per-country restrictions.

Passport-OCR + OCI / PIO capture

NRIs are identified by passport (not Aadhaar — many don't have one any more, and FEMA doesn't recognise Aadhaar for NRI status). Passport OCR is harder than PAN OCR because:

Passports vary by country (different layouts, MRZ encoding, photo position)
Date formats differ
Some countries' passports have non-Latin name fields

Our OCR runs an MRZ-first parser (the machine-readable zone at the bottom is standardised by ICAO) and falls back to layout-based extraction. Coverage: 50+ countries with > 95% extraction accuracy.

OCI (Overseas Citizen of India) and PIO (Person of Indian Origin) cards are uploaded separately when the customer has them — they're not technically required for NRI status but help establish Indian-origin claims.

FATCA / CRS declaration

US persons (or US-tax-residents anywhere) are subject to FATCA. The flow asks:

Are you a US citizen? (yes / no)
Are you a US tax resident? (yes / no, with criteria explained)
Do you have a US TIN? (entered if yes)

Non-US NRIs are subject to CRS (Common Reporting Standard) — declaration of all tax-residence jurisdictions, with TIN per jurisdiction. The flow auto-detects countries with CRS reporting agreements with India and drives the right declarations.

Misreported FATCA / CRS is one of the most common reasons for SEBI observation letters on NRI accounts. Worth getting right.

FEMA declaration

The actual FEMA-mandated declarations are about source of funds + repatriation intent + portfolio investment cap. We ask:

Source of funds (employment / business / investment / inheritance / other)
Whether they intend to repatriate proceeds
Their NRI status start date (so we can determine FEMA category)
Whether they hold any restricted securities under their country's law (e.g. some US tax-residents can't hold certain Indian instruments)

These are presented as quick-reply forms with explanations, not as a free-form box.

Country-of-residence investment restrictions

Some NRI investment products are restricted by the customer's country-of-residence regulator:

US persons cannot invest in most Indian mutual fund schemes (SEC reasons)
Canadian residents can but with extra disclosure
Some EU countries require MIFID-II suitability tests
UAE is generally open

The flow checks the customer's country at sign-up and shows / hides eligible products on the broker's catalogue. This avoids the broker having to manually intervene later.

Bank account proof

NRE / NRO accounts at the broker reference an existing NRE / NRO bank account. The flow validates the provided IFSC + account number against the bank's NRE / NRO designation. Customer-provided "savings account" that's not actually NRE-flagged gets caught here.

Video PD considerations

NRIs are generally outside the broker's geo-fence. Video PD with a real operator works (we have queues across IST + EST + GMT business hours). For high-net-worth customers, we offer scheduled video PD slots so the customer can pick a convenient time.

What's hard about NRI onboarding

The compliance stack is layered. Each step alone is solvable; the integration is what gets you. We've shipped NRI eKYC for several large brokers; total launch time is typically 4-6 weeks because every broker's NRI customer mix is different and the country-of-residence config has to be tuned.

Corporate eKYC: PVT Ltd / LLP / Partnership digital onboarding

amandeep — Mon, 13 Jul 2026 05:00:17 +0000

Originally published at finovo.tech/blog/corporate-ekyc-coming-soon — the canonical version has the latest updates.

Corporate trading accounts are the most valuable customers a broker has — average ticket size 100x retail, repeat trading volume in lakhs per month — and traditionally the slowest to onboard. A typical PVT Ltd account opening at a Tier-1 broker takes 3-5 weeks of paperwork shuffling.

Corporate eKYC is a Finovo upcoming product that compresses that to under a day.

What corporate accounts need

The regulator's required corporate KYC inputs:

The entity's PAN
The entity's CIN (Corporate Identification Number from MCA)
A verified ROC filing snapshot
KYC of every director (individual KYC, complete)
KYC of every beneficial owner with > 25% stake
The board resolution authorising the account opening
An AOA / MOA (or equivalent for LLP / partnership)
Bank account proof in the entity's name
Signature of the authorised signatory

The directors' individual KYC is the same flow as our retail eKYC — proven path. The novel parts are:

ROC integration so we don't re-collect data the MCA already has
Beneficial-owner capture (a non-trivial UX problem when ownership goes through holding companies)
Board resolution upload + parsing

ROC integration

Every PVT Ltd has a public profile on the MCA portal — directors, registered address, share-capital structure, last filing date. The corporate eKYC flow asks the customer for the CIN, then auto-pulls:

Registered name (as filed)
Registered address
Date of incorporation
Authorized + paid-up capital
Director list (with DINs + appointment dates)

The customer reviews + confirms. They don't re-type any of this.

Beneficial owner capture

This is where corporate KYC traditionally drags. SEBI requires you to identify every individual with > 25% beneficial ownership — including indirect ownership through holding companies. So if Acme Pvt Ltd is owned by Beta Holdings Pvt Ltd which is owned by an individual, you need to know about the individual.

The flow handles this iteratively: customer enters the immediate shareholders. If any are companies, the flow asks for those companies' shareholders. Recurses until it lands on individuals or stops at the 25% beneficial-ownership threshold.

For the typical 5-shareholder closely-held PVT Ltd, this is 90 seconds. For a 4-layer holding-company structure, it can take 10-15 minutes — but you're not redoing the whole KYC on a phone call when you discover the structure.

Board resolution

The board resolution authorising account-opening + appointing a signatory is uploaded as PDF. We OCR + parse to extract:

The resolution date
The directors present
The named signatory's name and DIN
The trading limits (if specified)

Customer reviews the parsed output. We attach the original PDF to the audit trail.

Why "coming soon"

The product is functional and in pilot with three brokers. We're holding general availability until two things land:

Multi-language support for AOA / MOA parsing (currently English-only; next is Hindi)
A migration path from the legacy paper-corporate-KYC database that most brokers carry

Both should land in the next quarter. If you're a high-volume corporate-account broker, book a demo and we'll add you to the early-access list.

What it replaces

Today, the typical corporate account workflow is:

RM emails the customer a 40-page PDF
Customer prints, signs, scans, emails back
Broker ops physically files the original at HQ
RM emails the customer 4 follow-up requests for missing documents
ROC verification is manual (someone literally types the CIN into the MCA portal)
After 18-21 days, the account is opened — and the customer has half-forgotten why they were opening it

Corporate eKYC moves all of step 1-5 into a 30-minute self-serve flow. RM still does the customer relationship; they just stop doing the paperwork.

MFD platforms: vanilla vs enterprise (which one fits)

amandeep — Sun, 12 Jul 2026 05:00:22 +0000

Originally published at finovo.tech/blog/mfd-vanilla-vs-enterprise — the canonical version has the latest updates.

India has 250,000+ registered MFDs (Mutual Fund Distributors). They range from a single CFP working from home to large national distributors with hundreds of sub-ARNs. The platform a 1-ARN MFD needs is fundamentally different from what a 200-ARN distributor needs — and trying to use one for the other ends in tears.

When to pick MFD vanilla

MFD vanilla fits if:

You're a single ARN (one license, one MFD)
< 2,000 customers
You're fine with a Finovo-branded customer app (or your customers don't notice / care)
You don't have sub-distributors under you
Pricing pressure is on per-AUM cost, not feature surface

The vanilla product gives you BSE StAR Connect (transactions), customer self-signup for SIPs / SWPs / switches, an iOS + Android app the customer downloads, statement-on-demand, and the full KYC + re-KYC pipe.

It onboards in about a week. You log in, configure your name and ARN, customers can sign up the next day.

When to pick MFD enterprise

MFD enterprise fits if:

You have multiple ARNs (or sub-distributors)
You want a custom-branded app on your domain (App Store + Play Store under your developer account)
You have a hierarchy: master distributor → regional → individual ARN
You need per-distributor commission splits
You have your own RM team that needs a desktop dashboard
> 5,000 customers, or you'll be there within 6 months

Enterprise gives you the full vanilla feature set plus:

White-label: your logo, your domain, your design tokens, your push-notification certs
Sub-ARN hierarchy: every customer is tagged to the ARN that brought them in; commissions split automatically
Per-region commission overrides (when sub-ARNs negotiate slightly different splits)
Desktop RM dashboard (separate from the customer app)
Custom domain mobile-app deep linking
HRMS for your RMs (attendance, sales targets, pipeline)
A dedicated migration engineer for the first 90 days

The hidden cost of starting on the wrong tier

Most MFDs we work with started on a vanilla product (often a competitor's), grew past 3,000 customers, and then realized they needed sub-ARN logic — at which point they had to migrate every customer. The migration is doable but takes 6-8 weeks of disruption.

Rule of thumb: if you'll be at 5K customers within 6 months, start on enterprise. The marginal cost vs. vanilla pays for itself in the migration you didn't have to do.

What "white-label app" really means

The most-requested feature for enterprise is the white-label mobile app. People often underestimate what's involved:

App Store + Play Store accounts in the distributor's name (not Finovo's)
App-store screenshots, copy, age-rating per their listing
Apple Developer enterprise certs for code-signing
Android upload key + Play Console permissions
Push-notification credentials (APNs + FCM) per app
App-tracking-transparency consent (iOS)

We handle the build pipeline, the cert management, the per-version review submission. The distributor's marketing team owns the listing copy. First app release is typically 3 weeks; subsequent updates are 2-4 days.

What stays the same

The actual transaction engine (BSE StAR), the AMC integrations, the KYC pipe, the SEBI reporting — all the same code. You're not losing engineering quality going to vanilla; you're just choosing how much of the surrounding infrastructure to take.

Pricing shape

Vanilla: flat per-customer monthly + per-transaction. Cheap until you grow.
Enterprise: platform fee + per-transaction (no per-customer). Cheaper at scale.

The breakeven for most distributors lands somewhere between 8K and 12K customers.

For a deeper dive, see our how to become mutual fund distributor india.

For a deeper dive, see our best app for mutual fund distributor.

For a deeper dive, see our how to start mutual fund distribution.

Migration path

Vanilla → enterprise is a no-code migration: same backend, new app shell + admin tools provisioned. Customer accounts persist, transaction history persists, ARN tagging gets re-applied. Typical downtime: zero (the new app ships alongside the old one for 30 days; old app is force-updated to the new one).

Vanilla eKYC: 90-second retail onboarding

amandeep — Sun, 12 Jul 2026 05:00:17 +0000

Originally published at finovo.tech/blog/vanilla-ekyc-90-second-onboarding — the canonical version has the latest updates.

Every retail-broker pitch deck shows a "fastest KYC in India" stat. Most are 4-minute flows that the team rounded down. Real medians, taken across 1M+ customers, sit between 110 and 180 seconds.

90 seconds is achievable, but only if you make a small number of unintuitive choices early.

What the regulator actually requires

For a normal individual with an Aadhaar + PAN, SEBI requires:

Identity (Aadhaar or other OVD)
Address (Aadhaar or other OVD)
PAN
A risk-categorisation question set (politically-exposed, source of funds, occupation)
Either video PD or in-person verification

Note: video PD is not always required for all customers. Aadhaar OTP + PAN + risk-cat is sufficient for many low-risk individual customers. The default-on video-PD is a self-imposed compliance choice by many brokers, not a SEBI rule. We turn it on or off per risk-category.

Where the seconds go

Profiled across many brokers, the long-tail in a typical "4-minute" flow:

Step	Median time	What's actually happening
App / page load	8s	First-paint + KYC form bundle
OTP entry	22s	Wait for SMS, switch to SMS app, copy OTP, paste back
PAN photo	31s	Find PAN, take photo, retry once
Video PD setup	28s	Permission grant for camera, lighting, "say your name" prompt
Video PD recording	45s	Live operator queue + 30s recording
Form fields	24s	Address, occupation, FATCA, source-of-funds
Final review + submit	14s	Long Ts and Cs, signature
Total	172s

The 90-second flow doesn't skip anything; it removes wait + switching costs.

How we get to 90 seconds

The five biggest wins:

Aadhaar OTP, no SMS round-trip: capture OTP in the same screen via <input> autocomplete attribute (autocomplete="one-time-code"). On iOS this auto-pastes from SMS; on Android we use the SMS Retriever API. Saves ~12 seconds.
PAN photo with on-device OCR: don't ship the photo to a server for OCR. Run a small model in-browser (or in-app) that auto-captures the PAN when sharpness + glare are acceptable. The customer doesn't tap a shutter button; the page just notices the PAN is in frame and captures. Saves ~18 seconds.
No video PD by default for low-risk: as above, this isn't required for many customers. Skip it unless the risk-cat triggers it. Saves ~73 seconds for ~70% of customers.
Pre-filled form fields from PAN + Aadhaar: address from Aadhaar, name from PAN, DOB from PAN. Customer reviews + confirms instead of typing. Saves ~16 seconds.
One-screen review-and-submit: the legal copy is shown in a collapsed scroll-area (not a separate Ts and Cs page). Saves ~6 seconds + reduces drop-off.

Pass rate, not just speed

Speed is meaningless if customers drop off. The vanilla flow (eKYC vanilla) tracks at 94% pass rate measured across 200K+ recent flows. Failures are mostly:

3.2% PAN-mismatch (typo on form vs OCR)
1.4% Aadhaar OTP timeout
0.9% video PD anomaly (when triggered)
0.4% network error mid-flow
0.1% other

The PAN-mismatch failures usually convert on retry; total customer-side recovery is ~97%.

Where vanilla isn't enough

Vanilla works for individuals. If you need:

Custom branded flow on your domain
Per-state regulatory variations (a few SEBI master circulars require state-specific clauses)
Integration with your in-house RM workflow

…you want eKYC enterprise, which is the same engine wrapped in white-label + per-broker config.

Try it

The 90-second number is verifiable — book a demo and we'll walk you through one customer's full flow with the timestamps visible. No staged demo accounts; we use the actual production logs.

Enterprise eKYC: white-label KYC for large brokers and NBFCs

amandeep — Sat, 11 Jul 2026 14:42:48 +0000

Originally published at finovo.tech/blog/enterprise-ekyc-white-label — the canonical version has the latest updates.

If you're a 100K+ customer broker, you don't ship a third-party-branded KYC flow. Your customers click "open account" on yourbroker.com and stay on yourbroker.com — even though the verification engine, document parser, and audit trail are running on Finovo.

That's what "enterprise" means: same engine, swapped surface.

The white-label layer

The customer-facing flow is yours, end to end:

Custom domain: kyc.yourbroker.com (we provide CNAME instructions; HTTPS via your CDN or via our managed cert)
Custom design tokens: logo, primary color, typography, button radii — set per-broker via a JSON config
Custom copy: every screen's microcopy is editable so it matches your brand voice
Custom support footer: phone, email, hours
Custom OG metadata for share previews

We don't show the Finovo logo or domain anywhere on the customer-facing flow. The "Powered by" footer is opt-in.

Per-org compliance config

The biggest reason enterprises don't use vanilla: they each have their own internal compliance interpretation.

For example, SEBI Master Direction allows several OVDs (Aadhaar, voter ID, passport, driving license). Some brokers' compliance teams accept all five; others restrict to Aadhaar + passport. Vanilla has a single config; enterprise lets each broker set their own:

Allowed OVDs (per customer category)
Required risk-cat questions
Video PD trigger thresholds
Address-mismatch tolerance
The set of "high-risk" customer flags
The PAN re-validation cadence

These are admin-editable from a config UI; no redeploy.

Multi-tenant isolation

Enterprise is genuinely multi-tenant: each org's data is in a separate logical partition. We don't co-mingle audit trails. Per-org S3 prefixes for documents, per-org Cognito user pools for support staff, per-org rate limits.

Cross-tenant queries are impossible by API design — there's no "list all customers" endpoint that crosses tenant boundaries. This matters when SEBI auditors ask for evidence that broker A can't see broker B's customers.

CRM integration

Vanilla writes the KYC packet to a JSON blob you fetch via webhook. Enterprise integrates with whatever CRM you already use:

Salesforce: KYC creates a Lead → Customer record with the verified fields populated
HubSpot: same shape, with custom-property mapping
In-house CRM: per-org webhook spec; we ship the spec, you implement the receiver
Finovo CRM (here): native integration, no webhook needed

Where it gets useful: the broker's RM gets a desktop notification when a high-net-worth lead lands, with the KYC verified status already populated. They don't have to wait for ops to forward the lead.

Bulk migration

Most enterprise customers come with a legacy KYC database — 50K to several million records, in various states of completeness. Migration is a project:

We import the existing snapshot via S3
For each record, we determine the regulator-acceptable status (CKYC-clean / re-KYC due / never-KYC'd)
Customers due for re-KYC get queued into our calendar engine
Records that look corrupted go into a manual-review queue
We provide a reconciliation report — typically the broker's CMO is surprised by 5-10% of records being in worse compliance state than they thought

Pricing

Vanilla is per-KYC pricing. Enterprise is a flat platform fee + per-KYC marginal cost — typically works out cheaper for any broker doing 50K+ KYCs/year.

For a deeper dive, see our best video kyc bank.

Where enterprise is too much

If you have:

< 5K KYCs/year
No internal compliance team for per-org config
No CRM (or just a Google Sheet)

…you probably want eKYC vanilla. Same engine, simpler.

If you're past those thresholds, enterprise pays for itself in the first quarter on operations cost alone.

Re-KYC at scale: SEBI 6-month compliance, automated

amandeep — Sat, 11 Jul 2026 14:42:43 +0000

Originally published at finovo.tech/blog/re-kyc-at-scale — the canonical version has the latest updates.

If you run more than 100,000 customers, the SEBI re-KYC mandate isn't a project — it's a constant grind. High-risk customers need re-verification every 6 months; everyone else, every 2 years. Manual ops teams burn out. Customer experience suffers (a customer-favorite question to support: "why are you asking me for KYC again?"). And the regulator audits your audit trail.

The fix is to treat re-KYC as a calendar-driven automated pipeline, with manual review only for the cases that fail.

The architecture

A re-KYC pipeline has three layers:

Calendar engine — for every customer, computes the next-due date based on risk category, last-completed date, and product. Fires a Lambda when due.
Re-KYC orchestrator — the actual customer-facing flow. Tries the cheapest verification first (OTP + recent transaction confirmation), escalates to OVD upload + video PD only when needed.
Reconciliation — once daily, reads the regulator's CKYC database and compares against our snapshot. Surfaces any drifts (address change, PAN deactivation, etc.) for manual review.

Why "OTP-first"

The cheapest valid re-KYC for a low-risk customer is just an Aadhaar OTP — 12 seconds, no friction. SEBI accepts this for routine refresh as long as the customer's category hasn't changed. Most re-KYC fails get triggered because the broker over-engineered the flow and asked for full document re-upload, even though the rules don't require it.

Smart escalation:

Tier 1: OTP + recent transaction confirmation (90% of cases)
Tier 2: PAN re-OCR if the PAN looks aged or low-confidence (8% of cases)
Tier 3: Full video PD if any field has changed materially (2% of cases)

Most pipelines we've audited do Tier 3 for everyone, which is why their completion rates are at 30%.

The "address change" trap

A common surprise: a customer who moved to a different city since their last KYC might pass OTP fine, but their address proof is now stale. SEBI doesn't auto-detect this; you have to ask. Best UX is a single-question pre-check: "Is your communication address still 4 / Park Street, Kolkata?" Yes → continue. No → trigger Tier 3.

We see ~3% of customers report address change at re-KYC. That sounds small until you realize at 1M customers you're looking at 30,000 forced Tier-3 flows that someone has to handle.

Audit trail

The regulator audits not the customer's data but how you got it. Every re-KYC step needs:

Timestamp
IP + device fingerprint
The actual question asked (so you can prove you didn't lead the customer)
The customer's literal answer
The system's classification (auto-pass / auto-fail / review-required)
The reviewer (if manual)

A typical re-KYC packet has 40-60 logged events. Storage is cheap; failing the audit isn't.

What you avoid by automating

A 500K-customer broker doing manual re-KYC typically spends:

12-20 ops people full-time on the queue
6-8 weeks each cycle to clear the high-risk list
8-15% of customers in inactive-pending-rekyc status at any time (lost trading volume)
2-4 SEBI observation letters per year about specific customers

After automation:

2-3 ops people for review-only queue
The full high-risk list closes within 3 days of the due-date
<1% of customers in pending-rekyc status
No observation letters about systematic delay (specific-case ones still happen, but those are unrelated to volume)

For a deeper dive, see our what is sebi re kyc.

The integration

This is the re-KYC product. It integrates with whatever broker / NBFC / insurer system you already have via standard webhooks — calendar engine queries your CRM, results write back to it. We don't replace your CRM; we add the automation layer between it and the regulator-facing KYC pipes.

If you're spending more than 4 ops-FTE-equivalents on re-KYC right now, the math probably already works.

HUF eKYC: digital onboarding for Hindu Undivided Family accounts

amandeep — Sat, 11 Jul 2026 14:31:14 +0000

Originally published at finovo.tech/blog/huf-enterprise-ekyc — the canonical version has the latest updates.

HUFs (Hindu Undivided Families) are a long-standing tax structure that brokers and NBFCs frequently see — and traditionally one of the most paperwork-intensive account types to open. A typical HUF onboarding requires:

KYC of the Karta (head of family) as an individual
A separate PAN for the HUF
The original HUF deed
Capture of all coparceners (other family members with a share)
A bank statement in the HUF's name
Specimen signatures of the Karta on the HUF letterhead

In a paper world this routinely takes 2-3 weeks. Digitally, it's the same 6 documents — but they all flow through one screen.

The Karta-KYC step

The Karta is treated as a regular individual KYC subject for this part — Aadhaar OTP, PAN-OCR, video PD where required by SEBI, address proof. Most brokers already have an individual KYC pipeline; HUF reuses it for the Karta.

The trick is the Karta's KYC and the HUF's KYC are two distinct records. You can't open an HUF account by just having the Karta's KYC; you need a separate HUF-PAN-anchored KYC packet. Plenty of in-house onboarding tools fail here because they assumed "1 customer = 1 KYC".

The HUF PAN

Every HUF needs its own PAN — separate from the Karta's. It's issued by the Income Tax Department on Form 49A with the HUF deed attached. Most HUFs already have one; if not, the customer has to apply (we don't issue PANs).

Validation step: PAN-OCR + an Income Tax Department lookup to confirm the PAN belongs to an entity of type "HUF" (not individual). Without this check, you can accidentally open an HUF-flagged account against an individual PAN — a SEBI violation.

The HUF deed

The HUF deed is the legal document that establishes the family. It names:

The Karta
The list of coparceners at the time of formation
The HUF's name (usually "[surname] HUF" or similar)
The date of partition / formation

In the digital flow, the deed is uploaded once and parsed (OCR + light NLP to extract the names + dates). The customer reviews the parsed list of coparceners on screen and confirms or edits — usually a 30-second step. The original deed PDF is signed by the Karta with Aadhaar e-sign at the end of the flow.

Coparcener capture

Coparceners are family members with an inherent share in the HUF. SEBI doesn't require their KYC, but they do need to be listed for audit purposes. The flow captures each coparcener's name, relation to Karta, and date of birth — typically pre-filled from the deed parser.

Bank account proof

The HUF needs a bank account in its own name (not the Karta's personal account). A canceled cheque, passbook front-page, or bank statement establishes this.

What enterprise adds

Vanilla HUF eKYC works for one ARN with a standard form. Enterprise HUF eKYC (the enterprise version) adds:

White-label flow on the broker's domain
Custom fields per the broker's compliance team (e.g. specific HUF sub-types)
Integration with the broker's CRM so HUF accounts route to the right RM
Bulk import for legacy HUF customers being migrated from a paper system

Common edge cases

A few things that look obvious until you ship them:

Karta change: when an HUF Karta dies, the next-eldest male coparcener becomes Karta. The flow has to re-issue KYC under the new Karta without re-creating the HUF entity.
Partition: if an HUF partitions, the entity dissolves. We mark the account as closed-by-partition (SEBI category 'partitioned') rather than just inactive.
Single-coparcener HUFs: legally still HUFs but with quirks around bank-account holding patterns. Most KYC tools mis-classify these as individuals.

Live in production for 15+ Indian brokers. Median Karta-to-account-active time: 8 minutes.

WhatsApp eKYC: zero-install onboarding for India's 500M users

amandeep — Sat, 11 Jul 2026 14:31:07 +0000

Originally published at finovo.tech/blog/whatsapp-ekyc-zero-install-onboarding — the canonical version has the latest updates.

India already lives on WhatsApp. 500 million users, 80%+ daily-active, used by everyone from a Mumbai broker to a Tier-3 NBFC borrower. So when you ask a customer to "click this link, install our app, complete KYC there" — you've already lost a third of them by step three.

WhatsApp eKYC keeps the customer on the app they already have open.

The completion-rate gap

Track any standard web KYC funnel and you'll see the same drop-off shape:

100 customers click the SMS link
76 land on the page (mobile-network drops, browser blocks, etc.)
58 reach the OCR step
43 finish PAN + Aadhaar capture
31 complete the video-PD or selfie step
27 are KYC-cleared

That's a 27% end-to-end completion rate on a flow with no friction beyond the medium itself. Switching the same flow to WhatsApp typically lands at 70-85% completion — not because the regulatory steps got easier, but because the customer never left the app, never dealt with a "this site can't be reached" error, and never had to type their Aadhaar into a tiny mobile keyboard.

What "WhatsApp-native" actually means

"WhatsApp eKYC" gets used loosely. Some flows just send a WhatsApp link that opens a hosted KYC page — that's still a web flow with extra steps. A fully native flow looks like this:

PAN capture via WhatsApp document upload — the user takes a photo of their PAN card or sends an existing PAN PDF.
Aadhaar verification via OTP — the user types their Aadhaar number into a WhatsApp message; we POST to UIDAI eKYC API; the OTP comes back to the user's registered mobile and is entered as a WhatsApp reply.
Video PD via WhatsApp video call — initiated from a Business API agent, recorded, time-stamped, geo-fenced.
Form fields (signature, nominee, FATCA, occupation) via WhatsApp interactive list and quick-reply buttons.
Final consent via WhatsApp's official confirmation message + audit trail.

The customer types nothing into a browser. The KYC packet — including all required SEBI / RBI fields — is built server-side from the WhatsApp conversation log.

Compliance posture

WhatsApp's Business API isn't a regulator-blessed channel by itself; it's a transport. The regulator cares about:

Identity proof capture under their respective KYC Master Direction (UIDAI eKYC, OVD, video-PD where required) — same standards as web.
Audit trail with timestamps, IP, geo, device-fingerprint — captured per-message via the Business API webhook.
Consent: each step has an explicit yes/no quick-reply that's logged.
Re-KYC (the periodic 6-month / 2-year refresh that SEBI Master Circular requires) — same evidence requirements as initial KYC.

Done right, the WhatsApp flow is easier to audit than web because the entire conversation is a single log. No browser-session ambiguity.

Where most teams get stuck

The hard parts of WhatsApp eKYC aren't the regulatory steps — those are the same as any compliant KYC. They're:

Building the conversation orchestrator that handles every user-error case: "what if they send a blurry PAN photo? what if the Aadhaar OTP times out? what if they reply with a sticker?"
The Business API templates for every transactional message, pre-approved by Meta — easy to overlook how strict Meta is about marketing-vs-utility template categories.
The fallback path for the 3-5% of customers who can't complete on WhatsApp — usually old phones, blocked accounts, or regulator-mandated face-to-face cases. You still need the web flow for them.

We've shipped this for 50+ Indian brokers. Customer-side completion is consistently in the 80%+ range; ops teams typically see a 60-70% reduction in support tickets vs. their previous web flow.

Try it

If you want to see the WhatsApp KYC flow end-to-end, we have a privacy-mode demo on the homepage that walks through 21 steps with auto-redacted PII so it's safe to share. Or jump straight to WhatsApp eKYC and book a 30-min walkthrough.

Built specifically for Indian financial regulation. Works for brokers (SEBI), NBFCs (RBI), and insurers (IRDAI) with the right configuration per vertical.