KYC vs KYB: What Is the Difference and When You Need Each

Key takeaways

• KYC is about a natural person: who they are, whether they are who they say, and where they can be reached. KYB is about a legal entity: that it exists, what its status is, who owns and controls it, and who may sign for it.
• Business customers need both. The entity gets KYB, and the human applicant gets KYC plus proof of authority to act for the entity.
• Indian regulation speaks of KYC and customer due diligence for individuals and legal entities alike. There is no separate statutory thing called KYB, so your obligations follow your regulator and your partner contracts, not the label.
• Which checks you run depends on entity type: a proprietorship is verified through its owner, a company through its registry record and tax registrations, a trust through its deed and trustees.
• StampMitra covers identity and registry lookups through PAN, GSTIN, CIN, Udyam and bank account endpoints. It does not offer Aadhaar-based verification, and it does not replace documents such as board resolutions, partnership deeds or beneficial ownership declarations.
• Beneficial ownership is the hardest KYB element. Registry lookups show directors, not the people who ultimately own or control the entity, so you collect a declaration and evidence.
• Model both flows as one pipeline over a "party" that is either a person or an entity, with checks selected by type. Do not fork the code.
• Re-verification matters more for entities than for people, because entities change status, directors and registrations.

KYC and KYB compared

Where the terms come from, and why that matters to your design

Indian KYC obligations come from several places. The Prevention of Money-laundering Act, 2002 and its rules set the framework for record keeping and customer identification. The Reserve Bank of India's Master Direction on KYC applies to the entities it regulates, such as banks and non-banking financial companies. SEBI, IRDAI and other sector regulators have their own instructions for the entities they supervise, and payment partners and banks add contractual requirements on top.

Two practical conclusions follow. First, the checks you must perform are a property of your licence and your contracts, so the safest starting point is the instruction you were given by your regulator or partner bank, not a blog post, including this one. Second, those instructions already describe different identification steps for individuals, companies, partnership firms and trusts. That is the substance of KYB, whether or not the document uses the word.

If you are not a regulated entity (say you run a marketplace, a SaaS product or a payroll tool), the same checks are risk management rather than compliance. You choose them to keep fraud and bad counterparties out, and you can tune them to the risk. That freedom is also why it pays to document your policy: you want to be able to explain later why a given vendor got a light check and another got a heavy one.

None of this is legal advice. Where a rule or threshold matters to a decision, check the current text and ask counsel.

What a KYC check consists of

For an individual, a typical sequence has four parts.

Identity. Establish that the identifier is real and belongs to a person with the name the customer gave. In India the practical anchor for most commercial flows is PAN: a lookup returns the name on record and, when you pass a name, a match result. Other documents (voter ID, driving licence, passport) serve the same purpose where PAN is absent or insufficient, and each has its own StampMitra endpoint.

Ownership of the identifier. The harder question: is the person in front of you the holder? A PAN lookup cannot answer this on its own, because the number is not secret. Policies fill the gap with additional steps such as a document photo, a liveness check or a transaction from an account in the customer's name. StampMitra does not offer Aadhaar-based verification or facial matching through the verification endpoints, so if your policy requires them you source them elsewhere.

Address and contact. Address proof comes from documents the customer provides. Contact details are verified by sending a code or a link, which is outside the verification API.

Payout or funding account. If money will flow to the customer, confirm that the bank account exists and that the account holder name matches. This is the job of the bank account verification endpoint, covered in depth in penny drop vs name match.

A KYC check on a person is rarely a single call. It is a short chain, ordered so that cheap and decisive checks run first. The use-case page on KYC for fintech and NBFC onboarding walks that chain for lending.

What a KYB check consists of

For an entity the chain is longer, and every link answers a different question.

1. Existence. Does the entity exist in a registry? For a company, the CIN lookup returns the company record. For an LLP, the registry number is the LLPIN. A sole proprietorship has no company-registry record, so existence rests on the owner's identity plus supporting registrations. Partnerships and trusts are evidenced by their deed and, where applicable, state registration.
2. Standing. Is it active? The CIN response carries cinStatus and companyStatus. A GSTIN response carries registrationStatus. A struck-off company, a cancelled GST registration or a suspended registration are all reasons to stop or review.
3. Tax identity. What are the entity's PAN and GST registrations, and do they belong to the same entity? The PAN to GSTIN lookup answers the second half of that question.
4. People. Who are the directors, partners or trustees? The CIN response lists directors with their DIN, name and designation. Partnerships and trusts depend on documents.
5. Authority. May the person applying bind the entity? This needs a document: a board resolution, an authorisation letter, a partnership deed clause. No lookup returns it.
6. Ownership and control. Who ultimately owns or controls the entity? Covered in its own section below.
7. Funding account. Does the entity have a bank account in its own name? A current account proof or a bank account verification where the holder name matches the entity name.
8. Purpose and risk. What does the business do, and is it in a category your policy treats as higher risk? This is a judgement, informed by industry codes where you have them.

The guide on GSTIN, CIN and Udyam business verification covers the lookups themselves, and PAN vs GSTIN vs CIN explains what each identifier can and cannot prove.

KYB by entity type

The checklist changes with the legal form. This table is a starting template, not a rule: your regulator or partner may require more.

This is not hypothetical. It is close to what StampMitra asks of its own customers. The production access form takes an applicant type (individual, sole proprietorship, partnership firm, LLP, private limited, public limited, trust or society), expects the PAN's fourth letter to agree with that type (P, F, C, T or A), requires a CIN for LLPs and companies and a GSTIN for companies, and asks for the documents in the right-hand column. The board resolution requirement is waived when the applicant is a director of the company. That detail is the template for your own flow: a rule that skips the heavy proof when a lookup already gave you the same assurance.

The sole proprietor: where KYC and KYB blur

A sole proprietorship is not a separate legal person. The business is the individual, trading under a name. That makes it a KYC case with business evidence attached.

• Identity and tax: the proprietor's PAN, verified as for any individual.
• Business existence: whichever of GSTIN, Udyam registration, shop and establishment licence or a current account in the business name the proprietor can show. None is mandatory for every proprietor, and which you should demand depends on your risk policy and what the business does.
• Name handling: the PAN carries the proprietor's name, while the GSTIN shows that name as legalName and the shop's brand as tradeName. Compare the name to legalName, never to the trade name.
• Funding account: a bank account in the proprietor's name or in the business name. Both occur. Decide in advance which you accept and how you treat a mismatch.

Products tend to go wrong here by building two forms (a consumer one and a company one) and having no home for the proprietor. Model the proprietor as an individual with an optional business section, and let the optional fields trigger additional lookups when filled.

Beneficial ownership and control

Beneficial ownership asks a different question from "who are the directors". Directors run the company. Beneficial owners are the natural persons who ultimately own it or exercise control over it, possibly through layers of other entities. The regulatory definitions use ownership thresholds that depend on the entity type and have been revised over time, so check the current rule for the one that applies to you.

A registry lookup cannot settle this. The CIN response lists directors; it is not a shareholder register. In practice a KYB flow obtains a beneficial ownership declaration from the entity, supported by documents such as a shareholding pattern, and applies KYC to the natural persons the declaration names above the relevant threshold. Where an owner is itself a company, you repeat KYB on that company until you reach people.

Two design points. Store the declaration as structured data (name, identifier, percentage or basis of control, date declared), not only as an attachment, so it can be refreshed and queried. And treat the director list from the CIN lookup as a cross-check: a declaration that names nobody who appears among the directors or the documents deserves a human look.

Who gets which check: a scenario table

Modelling both flows as one pipeline

The mistake that costs the most engineering time is building KYC and KYB as separate applications. The checks are the same primitives in different combinations, so model a party and let its type choose the checks.

// party-checks.mjs
const base = "https://api-b2b.stampmitra.in/v1/verify";
const headers = { Authorization: `Bearer ${process.env.STAMPMITRA_API_KEY}`, "Content-Type": "application/json" };

async function verify(path, body) {
  const res = await fetch(`${base}/${path}`, { method: "POST", headers, body: JSON.stringify(body), signal: AbortSignal.timeout(10_000) });
  const json = await res.json();
  if (!res.ok) return { ok: false, status: res.status, code: json.error?.code, requestId: json.error?.requestId };
  return { ok: true, data: json };
}

const PLAN = {
  INDIVIDUAL: (p) => [["pan", { pan: p.pan, name: p.name }], ["bank-account", p.bank]],
  PROPRIETORSHIP: (p) => [["pan", { pan: p.pan, name: p.name }], ...(p.gstin ? [["gstin", { gstin: p.gstin, businessName: p.tradeName }]] : [])],
  PRIVATE_LTD: (p) => [["pan", { pan: p.pan, name: p.name }], ["gstin", { gstin: p.gstin, businessName: p.name }], ["cin", { cin: p.cin }]],
};

export async function runChecks(party) {
  const steps = (PLAN[party.type] ?? PLAN.INDIVIDUAL)(party);
  const results = [];
  for (const [path, body] of steps) {
    const r = await verify(path, body);
    results.push({ path, ...r });
    if (!r.ok || r.data.valid === false) break; // stop at the first hard failure; later checks would only cost money
  }
  return results;
}

The same shape in Python, with a signatory check added for entities:

import os, requests

BASE = "https://api-b2b.stampmitra.in/v1/verify"
HEADERS = {"Authorization": f"Bearer {os.environ['STAMPMITRA_API_KEY']}", "Content-Type": "application/json"}

def verify(path: str, body: dict) -> dict:
    r = requests.post(f"{BASE}/{path}", json=body, headers=HEADERS, timeout=10)
    data = r.json()
    if not r.ok:
        return {"ok": False, "status": r.status_code, "code": data["error"]["code"], "request_id": data["error"]["requestId"]}
    return {"ok": True, "data": data}

def run_company_checks(company: dict, signatory: dict) -> dict:
    out = {"entity": [], "person": []}
    out["entity"].append(("pan", verify("pan", {"pan": company["pan"], "name": company["name"]})))
    out["entity"].append(("gstin", verify("gstin", {"gstin": company["gstin"], "businessName": company["name"]})))
    cin = verify("cin", {"cin": company["cin"]})
    out["entity"].append(("cin", cin))
    out["person"].append(("pan", verify("pan", {"pan": signatory["pan"], "name": signatory["name"]})))
    directors = {d["din"]: d["name"] for d in cin["data"].get("directors", [])} if cin["ok"] else {}
    out["signatory_is_director"] = any(signatory["name"].upper() == n.upper() for n in directors.values())
    return out

The raw request behind the entity lookup, if you want to try it by hand before writing any code:

curl -X POST "https://api-b2b.stampmitra.in/v1/verify/cin" \
  -H "Authorization: Bearer $STAMPMITRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"cin":"U74999DL2015PTC284009"}'

Notice the last line of the Python version: whether the signatory is a director is derived data, and it is what lets you waive a heavier document, as the StampMitra form does with the board resolution. The comparison there is intentionally crude (exact match after upper-casing). In production normalise names first and keep the director DINs in the audit record.

A worked example: a company borrower and its signatory

A fictional lender receives an application from Jane Doe Enterprises Private Limited, signed by Rahul Kumar.

1. The applicant type is a private limited company, so the plan is entity PAN, GSTIN and CIN, then the signatory PAN.
2. The entity PAN's fourth letter is C, consistent. The PAN lookup returns valid: true, the registered name matches.
3. The GSTIN lookup returns registrationStatus: Active. The embedded PAN equals the entity PAN. The principal place of business is the same city as the application address.
4. The CIN lookup returns an active company incorporated in 2015, with a director named Rahul Kumar.
5. The signatory's personal PAN lookup returns a match for Rahul Kumar. The signatory is also a listed director, so the policy waives the board resolution and asks only for the authorisation letter.
6. The beneficial ownership declaration names two shareholders above the policy's threshold. Both go through individual KYC. One has a name that differs slightly from the PAN record: the score is borderline and the case goes to a reviewer, who accepts it after seeing the PAN card image.
7. The funding account is a current account in the company's name. The bank account verification returns a name that matches the company name.

Seven checks, two of them manual. Everything is stored against the application with the referenceId of each call. If the same borrower came back in six months, only the status lookups would be repeated.

Risk-based depth: not every customer needs every check

A single heavy checklist for everyone loses good customers and burns money. A risk-based approach assigns a tier at the start from a few inputs (entity type, product, expected amount, geography, industry) and attaches a check set to each tier.

Write the tier rules down and version them. When a regulator or auditor asks why a customer got a certain depth, the answer should be a rule and a version, not a person's memory. The production access form on StampMitra does something similar: bank account verification and e-Sign are flagged as higher-risk products there, while PAN, GSTIN, CIN, Udyam and e-Stamp are treated as lower risk.

How often to re-verify

People change slowly. Entities do not. A GST registration can be cancelled, a company can be struck off or change directors, and a PAN's status can change. Set a refresh interval per tier and per identifier: registrations and company status more often, PAN less often. Re-run on events as well as on a clock: a payout to a new bank account, a change of signatory, a large transaction, a customer complaint.

Each re-verification is a new billable call at the production rate and produces a new referenceId, so budget for it. The cost of repeating status lookups on your active entity base is usually small next to the cost of paying an entity that no longer exists.

Questions to settle with your regulator or partner bank before you build

Engineering time goes to waste when the checklist arrives after the code. Ask these first and write the answers into your policy.

1. Which identification documents and registry checks are mandatory for each customer type, and which are optional?
2. Is a lookup against a data provider acceptable evidence, or must you hold a copy of the document itself? Many policies need both, with the lookup as the first gate.
3. What is the beneficial ownership threshold for companies, partnership firms and trusts, and how must you evidence it?
4. How long must KYC records be kept, counted from when, and in what form?
5. How often must records be refreshed, and does the interval depend on risk category?
6. What must happen when a check fails: reject, hold for review, or report?
7. Who is allowed to see the underlying personal data, and does access need to be logged?

The answers decide your data model more than any API does. A policy that requires the document copy needs object storage and retention rules. A policy that accepts a lookup as evidence needs the referenceId, the date and the fields you relied on, nothing more. Do not guess at these from a general guide.

Designing the data model: parties and relationships

Keep one table of parties and one of relationships. A party is a person or an entity. A relationship connects two parties with a role: signatory of, director of, owner of, proprietor of. This looks heavier than a flat customer row, but it is the only shape that lets one person appear as the signatory of two companies without being duplicated, and lets one company be owned by another company.

{
  "parties": [
    { "id": "p1", "kind": "ENTITY", "type": "PRIVATE_LTD", "name": "Jane Doe Enterprises Private Limited", "pan": "ABCDE1234F", "cin": "U74999DL2015PTC284009" },
    { "id": "p2", "kind": "PERSON", "name": "Rahul Kumar", "pan": "PQRSX1234L" }
  ],
  "relationships": [
    { "from": "p2", "to": "p1", "role": "DIRECTOR", "evidence": "SMV-20260927-6R38Y3" },
    { "from": "p2", "to": "p1", "role": "AUTHORISED_SIGNATORY", "evidence": "doc_authorisation_letter_0142" }
  ],
  "checks": [
    { "party": "p1", "kind": "cin", "referenceId": "SMV-20260927-6R38Y3", "checkedAt": "2026-10-29", "outcome": "valid" }
  ]
}

Two observations. The evidence field points either at an API referenceId or at a document id, which means a reviewer sees one list of evidence regardless of source. And the director relationship was derived from a lookup while the signatory relationship rests on a document, a distinction your tooling should keep visible.

Asking for the right things in the right words

The way you word the first screen decides how many applicants finish. Three practices help.

Ask the entity question in plain terms. "Are you applying as an individual or on behalf of a business?" is understood by everybody. "Select constitution" is not. After the answer, show only the fields that type needs, the way the StampMitra onboarding form changes its required fields with the applicant type.

Say why you are asking. A line under the PAN field saying you check the name against official records, and a line under the document upload saying what it is used for, reduce abandonment and also serve as the purpose statement your privacy notice needs.

Let a lookup replace a document where your policy allows. If the CIN lookup shows the applicant as a director, asking for a board resolution adds friction without adding assurance. Encode that as a rule and tell the applicant what they no longer need to upload.

Handle mismatches as questions, not errors. "The name on this PAN is slightly different from the name you entered. Is this your full legal name?" recovers more applicants than "Verification failed". Reserve hard failures for invalid identifiers and inactive entities.

What a reviewer should see when a case lands in the queue

A manual review queue is part of the design, because both flows produce borderline cases. Give the reviewer one screen per case with: the claimed party and type; each lookup result with its referenceId and timestamp; the specific reason the case was routed (which check, which threshold); the documents uploaded; the relationships derived from lookups and from documents; and the actions available (approve, reject, request a document, escalate). Log who decided and why. The screen is also what you will export when a partner or auditor asks to see how a decision was made.

Where checks multiply the cost

A company with three directors, two beneficial owners and a signatory has six people and one entity in scope, and every one of them can trigger a lookup. Costs scale with the number of parties, not the number of customers. Plan it in advance. Verify the entity first and stop if it fails, so you do not pay to check people attached to a dead company. Verify only the people your policy requires: the signatory and the owners above the threshold, not every director by default. At production rates a PAN lookup is ₹5 and a bank account check is ₹4 per call on standard pay-as-you-go, with plan pricing lower; see the pricing page for the current numbers. Sandbox calls cost nothing and never debit your wallet, so build and test the whole pipeline there first.

What the API does not cover

Be explicit about the edges, because gaps are where audits find problems.

• Aadhaar-based verification is not offered.
• There are no sanctions, politically exposed person or adverse media screens in the verification endpoints.
• There is no beneficial ownership lookup; the CIN response lists directors, not shareholders.
• Documents (board resolutions, deeds, address proof) are collected and reviewed by you. StampMitra's own production access flow reviews documents for its customers, but that is an internal onboarding process, not an API you can call for yours.
• Results reflect the data source at its last refresh, so a very recent change may not appear yet. See why results differ from the government portal.

Handling personal data across both flows

KYC and KYB both collect personal data: names, PANs, bank account numbers, directors' names and DINs, email addresses. Collect what the check needs, say why in a notice, keep it only as long as your policy or the law requires, and restrict who can see it. The Digital Personal Data Protection Act, 2023 is the general framework for personal data, and sector rules may add longer retention for KYC records, so settle the retention period with your compliance owner rather than defaulting to "forever" or "delete immediately". Mask identifiers in logs. The guide on what to log and keep goes through this field by field.

Common mistakes

• Treating a company's GSTIN as proof the signatory has authority. It shows nothing about who may sign.
• Running only the entity checks for a business customer and never verifying the person who applied.
• Running a consumer-style PAN check on a company PAN and calling that KYB.
• Comparing the signatory's name to the company's name instead of to the director list.
• Letting the proprietor slip through with no business evidence because the form only has a consumer path.
• Storing only the pass or fail outcome, so that a later refresh cannot show what changed.
• Using sandbox results in a demo as if they were real checks. Sandbox returns sample data.

Glossary

What to do next

Pick your entity types, copy the table above into your policy and mark which checks are lookups and which are documents. Get a sandbox key through the quickstart, then try the PAN, GSTIN and CIN calls from the verification docs. For the order of checks on a vendor, read Building a vendor onboarding flow. Before you go live, read sandbox vs production: what you can test. Questions about an input not covered here go to support.

API reference at a glance

{
  "referenceId": "SMV-20260927-8F42K7",
  "pan": "ABCDE1234F",
  "type": "Individual",
  "valid": true,
  "registeredName": "RAHUL KUMAR",
  "fatherName": "SURESH KUMAR",
  "panStatus": "VALID",
  "panStatusCode": "E",
  "panStatusDescription": "Existing and valid PAN",
  "nameMatchResult": "MATCH",
  "nameMatchScore": "100",
  "aadhaarSeedingStatus": "y",
  "aadhaarSeedingStatusDescription": "Aadhaar linked",
  "lastUpdatedAt": "2023-04-01",
  "message": "PAN is Valid"
}

{
  "referenceId": "SMV-20260927-6R38Y3",
  "verificationId": "VRF-6C2N9V4HQ7ZE",
  "valid": true,
  "status": "VALID",
  "cin": "U72900KA2015PTC082988",
  "companyName": "COMPANY NAME",
  "registrationNumber": 82987,
  "incorporationDate": "2015-09-23",
  "cinStatus": "ACTIVE",
  "email": "[email protected]",
  "incorporationCountry": "INDIA",
  "directorDetails": [
    {
      "din": "07168822",
      "name": "Frank Kelvin",
      "dob": "1997-07-21",
      "designation": "DIRECTOR",
      "address": "ST BED KORAMANGALA, BANGALORE, KARNATAKA, INDIA, 566634"
    },
    {
      "din": "07168826",
      "name": "John Doe",
      "dob": "1997-02-07",
      "designation": "DIRECTOR",
      "address": "GAUTAM NAGAR, NOIDA, UTTAR PRADESH, INDIA, 211361"
    }
  ],
  "companyStatus": "ACTIVE",
  "directors": [
    {
      "din": "07168822",
      "name": "Frank Kelvin",
      "designation": "DIRECTOR"
    },
    {
      "din": "07168826",
      "name": "John Doe",
      "designation": "DIRECTOR"
    }
  ]
}

{
  "referenceId": "SMV-20260927-3B71A0",
  "valid": true,
  "nameAtBank": "RAVI KUMAR",
  "bankName": "ICICI Bank",
  "utr": "017952100012345",
  "city": "Mumbai",
  "branch": "Andheri West",
  "micr": "400229002",
  "nameMatchScore": "100",
  "nameMatchResult": "GOOD_MATCH",
  "accountStatus": "ACCOUNT_IS_VALID",
  "accountStatusCode": "1",
  "ifscDetails": {
    "bank": "ICICI Bank",
    "ifsc": "ICIC0001234",
    "micr": "400229002",
    "address": "Andheri West, Mumbai",
    "city": "Mumbai",
    "state": "Maharashtra",
    "branch": "Andheri West"
  }
}

Frequently asked questions