Skip to main content

Overview

Registry Verification confirms a financial intermediary’s regulatory registration against the official public registers. Two endpoints, one job — a yes/no answer you can gate onboarding on:
  • POST /v1/verify/sebi — any SEBI-registered intermediary (Investment Adviser, Research Analyst, Portfolio Manager, Stock Broker, Merchant Banker, RTA, Mutual Fund, AIF, and more).
  • POST /v1/verify/mfd — an AMFI Mutual Fund Distributor by ARN, screened against AMFI’s suspended, terminated, and terminated-EUIN lists.
What you get:
  • A single verified boolean to gate on
  • A normalized registration_status (ACTIVE, EXPIRED, SUSPENDED, TERMINATED, NOT_FOUND)
  • The registrant’s name, validity, and category — straight from the regulator’s register
What you need:
  • A registration number (SEBI) or an ARN (AMFI). That’s it — the category is auto-detected.
A “not found” result is a successful verification: you get HTTP 200 with verified: false and registration_status: NOT_FOUND. It’s billed like any other lookup. Only genuine service errors return 5xx (and those are free).

Verify a SEBI intermediary

Send the registration number — the category is detected from its sequence. No need to tell us whether it’s an adviser, broker, or portfolio manager.

Categories & auto-detection

/v1/verify/sebi covers every SEBI intermediary register. When you send a registration_number, the character after IN selects the category automatically — no type needed: The remaining registers don’t encode a category in the number (funds, FPIs, trusts, etc.), so pass type explicitly. These are all supported: Short aliases are accepted anywhere a type is expected: ria, ia, ra, pms, broker, rta, mf, aif, cra, vcf, fvci, fpi, kra, invit, reit. type is also how you search by name (there’s no number to detect from), or override detection:
The registration number is authoritative. If you send both registration_number and name, the name is ignored — we never let a mismatched name turn a real registration into a false “not found”.

SEBI response

Every key is always present on a 200 response — null when it doesn’t apply (e.g. a NOT_FOUND result carries the same keys with nulls). Use verified as your gate.

Verify an AMFI distributor (ARN)

The ARN — and the EUIN attached to it — is screened against AMFI’s adverse lists. A distributor who has been suspended or terminated for cause is reported as such, not merely “not found”:
Only an exact ARN matches. A partial or non-existent ARN returns NOT_FOUND — we never resolve a fuzzy search to some other distributor’s record.
An active distributor returns verified: true, kyd_compliant, and the ARN’s valid_from/valid_till. negative_list_hit is false and negative_list is null.

Adverse-list screening

Every ARN is checked against three AMFI lists. A hit populates negative_list and overrides registration_status: negative_list.since carries the effective date AMFI published (e.g. "May 26, 2006"). On an active record, three AMFI-specific fields matter:
  • kyd_compliant — the distributor’s Know Your Distributor (KYD) status. true when compliant.
  • euin — the Employee Unique Identification Number of the individual under the ARN.
  • valid_from / valid_till — the ARN’s current validity window (ARNs are renewed, never perpetual).

registration_status values

SUSPENDED and TERMINATED are MFD-only. SEBI’s register lists current registrations, so a lapsed or cancelled SEBI registration simply reads NOT_FOUND.

Credit usage

Both endpoints bill under a single verify feature. The register the lookup hit (SEBI vs AMFI) is recorded on the usage event, so you can still break usage down by source.

Error handling

Next steps

KYC PAN Status

Check an investor’s KYC status across all five KRAs

CAS Parsing

Parse portfolio statements once the intermediary is verified