DEV Community

amandeep
amandeep

Posted on • Originally published at finovo.tech

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

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.

Top comments (0)