Employee Background Verification API for India: What It Covers

Key takeaways

• An identity API covers identity and payment-account checks: PAN, driving licence, voter ID, passport file, vehicle registration for drivers, and the salary bank account. It does not run criminal, court, education or past-employment checks, and it does not offer Aadhaar-based verification.
• Build role-based packages. An office hire, a driver, a contractor and a finance role each need a different set, and each set should be written down once and applied consistently.
• Get consent and give notice before you check anything. Collect only what the package needs, tell candidates why, and keep the purpose narrow.
• Indian names break naive matching: initials, name order, spellings, married names and transliteration. Use score thresholds with a review band and never reject on string inequality.
• Treat a failed check as a question, not a verdict. Give candidates a way to explain or correct, because source records can be wrong and typos are common.
• valid: false and found: false are completed, billable answers; retry only 429 and 502.
• Cost per hire is a few rupees to a few tens of rupees depending on the package; the arithmetic for three hiring volumes is below.

What background verification covers, and what an identity API can do

Start with an honest map. The left column lists the elements you will see on a typical background-check proposal; the right column says what this platform can do about each.

Two cautions follow from the table. A voter ID or licence response may include an address, but that is a registry record, not proof of where someone lives today. And an identity check proves a document exists and matches a name; it does not tell you anything about a person's honesty or skills. Present it internally as "identity and payment-account verification" so that nobody reads more into it than is there.

Who is involved, and who decides what

Three parties touch every check, and being clear about their roles avoids problems later.

The employer, or the staffing firm's client, decides the package for each role and what an adverse result means. The staffing or verification firm, if you are one, runs the checks on the client's behalf, holds the candidate's data while doing so, and reports outcomes. The candidate provides the data, gives consent and has the right to be told, to correct errors and to complain.

Whether your firm is acting as an independent decision-maker or as a processor for each client, and what that means under data-protection law, is a question for your counsel. We mention it because the design should keep each client's data separate and make the chain of responsibility visible in your records.

The candidate journey

A background-check flow that fits a hiring funnel looks like this. The offer is made. The candidate receives a joining link, reads a short notice that says which checks will run and why, and gives consent. The candidate enters identifiers or uploads documents. Your system runs the checks and shows the candidate a status ("in progress", "needs your attention", "done") without exposing registry data. HR sees a package result with per-check outcomes. If something needs the candidate's attention, they get a clear message and a way to respond. When the package is complete, HR clears the candidate for joining, and payroll gets the verified bank account.

The point of running the checks during the joining form instead of afterwards is simple: a mismatch found on day one can be fixed with a corrected entry, while a mismatch found in week three has become an awkward conversation with someone already on the payroll.

The workflow, step by step

1. Define the package for the role. Write down which checks each role needs. Decision: no package, no checks. This stops ad-hoc over-collection.
2. Show the notice and record consent. Store the notice version, the timestamp and the candidate's confirmation. Decision: no consent, no check.
3. Collect identifiers. PAN, bank account and IFSC, and the role-specific document: driving licence number and date of birth, voter ID, or passport file number and date of birth. Validate patterns locally. Decision: fix typos before spending.
4. Verify the PAN with the candidate's name. POST /v1/verify/pan with pan and name. Read valid, type, registeredName, nameMatchScore. Decision: a company or firm type on an individual hire is a data error; a weak score goes to review.
5. Verify the role document. For drivers POST /v1/verify/driving-license with dlNumber and dob; for others voter ID or passport as your package says. Decision: expired or inactive status is a stop for driving roles and a question for others.
6. Verify the vehicle where relevant. POST /v1/verify/rc with vehicleNumber. Decision: owner and status checked against the role's rules (own vehicle, fleet vehicle, lease).
7. Verify the salary account. POST /v1/verify/bank-account with account number, IFSC and the candidate's name. Decision: payroll uses the account only after a valid result and an acceptable name score.
8. Assemble the package result. Combine the per-check outcomes into one status: clear, clear with note, needs attention, or hold. Decision: HR sees the status and the reasons, not raw registry data.
9. Give the candidate a chance to respond. For "needs attention", send a plain message with what to fix. Decision: one correction round before a human reviews.
10. Record and retain according to policy. Store referenceId, time, key fields, decision, reviewer; schedule deletion according to your retention rules.

Sample request and response: the driving-licence check

For driver and delivery roles, the licence is the central document. The request carries the licence number and the candidate's date of birth:

curl -X POST "https://api-b2b.stampmitra.in/v1/verify/driving-license" \
  -H "Authorization: Bearer $STAMPMITRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"dlNumber":"MH1420110012345","dob":"1990-01-01"}'

{
  "referenceId": "SMV-20260927-2Q56T8",
  "valid": true,
  "name": "RAHUL KUMAR",
  "fatherOrHusbandName": "SURESH KUMAR",
  "dob": "1990-01-01",
  "address": "123, MG Road, Bengaluru",
  "validUpto": "2030-12-31",
  "dlStatus": "ACTIVE"
}

The driving-licence and passport endpoints are sensitive scopes, so plan on an IP-allowlisted production key. Show reviewers only the fields they need; the address and relationship name in this response are good examples of data you should minimise.

Indian names and why exact matching fails

The single biggest source of false mismatches in identity verification is names. The same person can legitimately appear as "Rahul Kumar", "Kumar Rahul", "R. Kumar", "Rahul K", "Rahul Kumar Singh" or "Rahul Kumar S" across a PAN, a licence, a bank account and a joining form. Married names change surnames. Transliteration from regional scripts produces different spellings of the same name. Some people have a single name; some systems truncate long names.

Plan for this in three ways. First, use the match score the PAN and bank-account endpoints return, not your own equality test, and set thresholds with a review band. Second, for endpoints that return a name without a score (licence, voter ID, passport and registry lookups), compare names yourself with a tolerant method that handles word order, initials and common spelling variants. Third, never let a name mismatch alone reject a candidate; send it to a human with both names visible and let them apply judgement, perhaps with a short call to the candidate.

import re

def normalise(name: str) -> list[str]:
    cleaned = re.sub(r"[^a-z ]", " ", name.lower())
    return [w for w in cleaned.split() if w]

def tolerant_match(a: str, b: str) -> str:
    wa, wb = normalise(a), normalise(b)
    if not wa or not wb:
        return "review"
    full_b = {w for w in wb if len(w) > 1}
    initials_b = {w[0] for w in wb}
    hits = 0
    for w in wa:
        if len(w) > 1 and w in full_b:
            hits += 1
        elif len(w) == 1 and w in initials_b:
            hits += 1
    ratio = hits / len(wa)
    if ratio >= 0.9:
        return "agree"
    if ratio >= 0.5:
        return "review"
    return "disagree"

The function is a starting point, not a finished matcher. Test it on a few hundred real name pairs from your own history, look at the false positives and negatives and adjust. Keep a record of the thresholds in use at the time of each decision.

Decision table: valid, mismatch, inactive, not found

Note that nothing in the table is an automatic rejection of a person. A stop means the package cannot be cleared until the issue is resolved. The decision to withdraw an offer is a human one and should follow your HR policy and legal advice.

Role-based packages

Write the packages down so that candidates in the same situation get the same checks. These are examples, to adapt.

• Office or back-office hire. PAN with name, then the salary account. Add a voter ID or passport check only if your policy asks for a second identity document.
• Driver or delivery rider. PAN, driving licence, vehicle registration where the rider uses their own vehicle, and the salary or payout account.
• Contractor or freelancer. PAN, the bank account, and if they invoice with a GST registration, a GSTIN check; for a micro or small enterprise a Udyam check; for a company a CIN check.
• Finance, cash-handling or high-trust role. Everything in the office package, plus the checks your policy requires from specialist providers for criminal and past-employment history. The identity API is one input; the rest is outside it.
• Agency-supplied worker. The staffing firm runs the package; the client receives a result and the reasons, not the raw documents, unless the client has a legitimate need.

Consent, notice and fairness

Background checks use personal data about people who are in a weak bargaining position. Handle that with care.

Tell candidates before you check: which checks, why, which provider processes the data, how long you will keep it and how to ask questions or complain. Ask for consent in a way that is distinct from the rest of the joining paperwork and keep a record of what the candidate saw and when. Collect only what the package requires; if you do not need a voter ID, do not ask for it. Do not reuse the data for other purposes without a fresh basis. Give candidates a route to see the outcome of their own checks and to correct errors.

India's Digital Personal Data Protection Act, 2023 sets out principles on notice, consent, purpose limitation, accuracy and retention for personal data. How it applies to employment screening, including any legitimate-use provisions for employers, depends on the text and rules as they stand when you read this. Ask your counsel; do not rely on a summary from a vendor.

Adverse outcomes and candidate disputes

Source data can be wrong. A licence record may carry an old name; a PAN may carry a different spelling; a bank may hold the name in a form the candidate no longer uses. If a check fails, treat it as a reason to talk, not a reason to decide.

Tell the candidate which check needs attention and what they can provide to resolve it, such as a corrected entry or a document. Give a reasonable time to respond. Have a human compare the candidate's explanation and documents with the check result. Record the reasoning and the reviewer. Only after that, and in line with your HR policy and any legal advice, decide what to do with the offer. If the outcome is adverse, keep the evidence record so that you can explain the decision to the candidate or to a regulator or court if asked.

Do not retry a failed check in the hope that it passes. The answer will be the same and the call is billed again. Do not tell a candidate more than they need: the aim is to say what to fix, not to echo the registry.

Running checks in volume for a staffing agency

A staffing firm that onboards hundreds of workers in a day for a client has throughput problems that individual HR teams do not.

Run checks asynchronously with a queue. Workers pick up candidates, call the endpoints, write results and update the candidate's status. Keep concurrency within the rate limit that applies to your plan (the documented error example is 60 requests per 60 seconds; read your own limits from the dashboard and the pricing page). Back off on 429 and 502, alert on 402, and do not retry negative answers. Isolate each client's data and reports so one client never sees another's candidates, and tag each check with the client and package so that invoicing and audit trails line up.

Expect peaks: shift-based hiring creates spikes at the start of a project. Pre-validate patterns in the intake form so that bad data does not consume paid calls, and put a cap on retries per candidate so that a candidate who keeps entering the same wrong number does not run up charges. Give the client a status dashboard that shows counts by outcome and the age of items waiting on candidates, since "waiting for the candidate" is the most common reason for delay and is outside your control.

Verifying the salary account before the first payroll

A failed salary credit is a small crisis for the employee and a large nuisance for payroll. Verify the account before payroll set-up using verify/bank-account with the employee's name, and act on the result: a valid account with a strong name score goes into the payroll master; a middling score goes to a short human check; a not-valid account gets a request for different details. For joint or family accounts, your policy decides whether to accept them and what proof to ask for. Because the check costs the flat bank-account rate on every plan, doing it for every hire is cheap compared with a returned salary.

Treat later account changes like the initial one: re-verify before updating the payroll master, and require confirmation from the employee through a channel you already trust. A salary-diversion scam depends on someone accepting a change request without verification.

Five scenarios from the HR-operations desk

These are hypothetical cases.

The clean joiner

An office hire consents, enters PAN and bank details, and both checks return valid with strong scores. The package is clear within a minute, payroll takes the account, and HR sees one line: cleared.

The married name

A candidate's PAN carries her maiden name while her bank account uses her married name. The bank score lands in the review band. The reviewer sees both names and the candidate's marriage certificate upload, records the reason and clears the check. No call is repeated.

The expired licence

A delivery rider's licence returns a validity date in the past. The package for riders stops. The candidate is told which check needs attention. They upload a renewed licence receipt, the reviewer records the explanation and the joining is delayed until a current licence is verified. The decision remains with the HR lead.

The vehicle owned by a relative

A rider uses their father's motorcycle. The RC check returns a valid registration under a different name. The rider's package allows this with a written authorisation from the owner. The reviewer attaches the authorisation and marks the check as cleared with a note.

The registry outage

During a hiring drive the licence call returns 502. Candidates see "verification in progress" rather than an error. The queue retries with backoff and finishes when the source returns. No candidate is cleared by default, and none is flagged for a platform problem.

Review rules an HR team can copy

These are suggestions for your policy to adapt.

• Clear automatically when every check in the package is valid, name scores are above your high threshold, dates of birth agree and statuses are active.
• Review when a name score falls in the middle band, a date of birth differs, a vehicle owner differs from the candidate, or a document is close to expiry.
• Stop for resolution when a document is expired or inactive for a role that requires it, a PAN type contradicts the role, or the salary account is not valid.
• Never auto-reject. A human decides about offers, using the evidence and the candidate's response.
• One correction round before human review, and a time limit on candidate responses that you tell the candidate about.
• Second reviewer for overrides and for any decision that withdraws an offer on the strength of a check result.
• Least privilege. Reviewers see the fields they need; managers see statuses and reasons.

Operating model

Run two queues. The candidate queue holds items that wait on the candidate; its job is to remind, answer questions and chase, and it is staffed by recruiters or HR coordinators. The review queue holds items that need judgement; it is staffed by HR operations analysts with a named senior reviewer for escalations. A third, platform queue for failed calls and wallet alerts belongs to engineering.

Set turnaround targets that suit your hiring pace, such as same day for review items on joining day, and measure the age of the oldest item in each queue. Give each client or business unit a view of its own metrics so conversations about delays rest on numbers.

Write the escalation path down as well. A reviewer who is unsure whether a mismatch is innocent should know exactly who to ask, how quickly an answer is expected and what to do in the meantime, which is usually to leave the candidate's status as "needs attention" rather than guess. A short weekly meeting between HR operations and the recruiters who talk to candidates also pays off: recruiters hear which messages confuse people, and operations hears which candidates are repeatedly stuck on the same step, and the message templates improve as a result.

What to store and for how long

Store the notice version and consent record, the package definition, referenceId for each check, timestamps, the environment of the key, masked identifiers, the response fields used for the decision, the decision, the reviewer and the reason for overrides. Keep raw document numbers out of application logs. Store candidate documents, if you collect any, in a separate access-controlled store.

Retention differs between candidates who joined and candidates who did not. A common principle is to keep data for a shorter time where there is no ongoing relationship and for longer where employment and statutory record-keeping apply, but the actual periods depend on employment law, tax and payroll rules, contractual needs and data-protection law. Ask your counsel for the periods, write them into a retention schedule, and automate deletion. StampMitra's own handling of data is in its retention and deletion schedule and data processing addendum.

What it costs: three hiring volumes

Pay-as-you-go prices are ₹5 per call for PAN, licence, voter ID and the registry checks, ₹4 for the bank-account check, and ₹9 for the premium band (vehicle RC and passport). Growth and Scale lower the standard and premium rates and add a monthly plan fee; the bank-account rate is the same on all plans. All amounts exclude GST at 18%.

The cost of one hire depends on the package. An office hire (PAN and bank account) and a driver (PAN, licence, vehicle RC and bank account):

For monthly models, assume 70 percent of hires are office roles and 30 percent are drivers. For N hires that is N PAN checks, 0.3N licence checks, 0.3N vehicle checks and N bank checks, which is 1.3N standard calls, 0.3N premium calls and N bank checks. At 200 hires a month: 260 standard calls, 60 premium calls and 200 bank checks.

At 2,000 hires a month: 2,600 standard calls, 600 premium calls and 2,000 bank checks.

At 20,000 hires a month, as a large staffing platform might see: 26,000 standard calls, 6,000 premium calls and 20,000 bank checks.

Reading the three tables: at 200 hires a month pay as you go is the cheapest option because plan fees outweigh the lower rates; at 2,000 Growth is the cheapest; at 20,000 Scale is, and the spend is above the level at which StampMitra suggests an enterprise arrangement, which you can raise on the contact page. The tables assume GST applies to the plan fee as well; confirm on an invoice. Usage is recorded only after a successful response, so calls that fail with an error are not charged, but valid: false is a successful answer and is charged. These figures cover only the StampMitra calls; the cost of other background-check elements from other providers is separate, and so is the staff time spent on review.

Rollout: sandbox, pilot, production

Sandbox. Build the candidate journey, package logic and review queue against sandbox keys. Responses are sample data and the wallet is never debited. The sandbox responder returns a valid result for the PAN SNDBX0000A and an invalid one for SNDBX9999F; any other input gets a stable but arbitrary result, so do not assert on it. Confirm current test values in the dashboard. Test every cell of the decision table, the name matcher, the consent gate, the one-correction-round rule and the 402, 429 and 502 paths.

Pilot. Apply for production access, which needs your organisation's KYC approval and the per-product application. Licence and passport scopes are sensitive and need an IP-allowlisted key. Run one client or business unit's joiners through the flow while HR continues to check manually for a few weeks, and compare outcomes.

Production. Widen by client and role. Review thresholds after the first month with real mismatch data. Alert on wallet balance, and keep the sandbox versus production keys guide at hand for scopes and the allowlist.

Metrics worth watching

• Share of packages cleared without human review, per package type.
• Time from candidate submission to package result, and from result to joining.
• Share of candidates in "needs attention", and median time to respond.
• Review-band rate for names, and how many were cleared after review.
• Hard-stop reasons by role: expired licence, invalid account, PAN type.
• Appeals or corrections that changed an outcome.
• Calls per candidate. A high number points at retry loops or repeated entry of wrong data.
• Rejected-then-reversed decisions, which show where the process is too strict.

Mistakes that harm candidates or weaken the process

• Expecting an identity API to do the whole background check. It does identity and payment-account checks only.
• Over-collecting. Asking for every document for every role.
• Exact name equality. It creates false mismatches for ordinary Indian names.
• Auto-rejecting on a failed check. Source records can be wrong.
• Showing registry data to candidates or managers. It leaks personal data and invites disputes.
• Retrying negative answers. Same answer, billed again.
• Skipping consent and notice. Both are central to fair processing.
• Keeping data forever. Set and automate retention.
• Mixing clients' data in a staffing platform. Isolate by client from day one.
• Treating the check as a character reference. It says nothing about integrity or skills.

Related APIs and guides

The endpoints used on this page are in the verification API reference: PAN, driving licence, voter ID, passport, vehicle RC and bank account. For related reading, see bank account verification before payout, which applies equally to salary accounts, the marketplace seller verification page for gig and delivery partners, the PAN verification guide, the vehicle RC guide and the errors guide. All industry pages are listed on the solutions page, and rates are on the pricing page.

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-2Q56T8",
  "verificationId": "VRF-4H8Z2M6TQ9KW",
  "valid": true,
  "dlNumber": "KA51201900089895",
  "dob": "1994-08-05",
  "status": "VALID",
  "dlStatus": "VALID",
  "name": "JOHN DOE",
  "fatherOrHusbandName": "JOHN DOE",
  "address": "FLAT NO D-901 SUN,BELLANDUR, BANGALORE SOUTH,BANGALORE,KA 560103",
  "validUpto": "09/05/2039",
  "badgeDetails": [
    {
      "badgeIssueDate": null,
      "badgeNo": null,
      "classOfVehicle": [
        "LMV"
      ]
    }
  ],
  "dlValidity": {
    "nonTransport": {
      "to": "09/05/2039",
      "from": "10/05/2019"
    },
    "hazardousValidTill": null,
    "transport": {
      "to": null,
      "from": null
    },
    "hillValidTill": null
  },
  "detailsOfDrivingLicence": {
    "dateOfIssue": "10/05/2019",
    "dateOfLastTransaction": null,
    "status": null,
    "lastTransactedAt": null,
    "name": "JOHN DOE",
    "fatherOrHusbandName": "JOHN DOE",
    "addressList": [
      {
        "completeAddress": "FLAT NO D-901 SUN,BELLANDUR, BANGALORE SOUTH,BANGALORE,KA 560103",
        "type": "permanent",
        "splitAddress": {
          "district": [
            "BANGALORE"
          ],
          "state": [
            "KARNATAKA",
            "KA"
          ],
          "city": [
            "BELLANDUR"
          ],
          "pincode": "560103",
          "country": [
            "IN",
            "IND",
            "INDIA"
          ],
          "addressLine": "FLAT NO D-901 SUN,BELLANDUR, BANGALORE SOUTH,BANGALORE,KA 560103"
        }
      },
      {
        "completeAddress": "FLAT NO D-901 SUN,BELLANDUR, BANGALORE SOUTH,BANGALORE,KA 560103",
        "type": "temporary",
        "splitAddress": {
          "district": [
            "BANGALORE"
          ],
          "state": [
            "KARNATAKA",
            "KA"
          ],
          "city": [
            "BELLANDUR"
          ],
          "pincode": "560103",
          "country": [
            "IN",
            "IND",
            "INDIA"
          ],
          "addressLine": "FLAT NO D-901 SUN,BELLANDUR, BANGALORE SOUTH,BANGALORE,KA 560103"
        }
      }
    ],
    "address": "FLAT NO D-901 SUN,BELLANDUR, BANGALORE SOUTH,BANGALORE,KA 560103",
    "photoUrl": "https://example.com/dl-photos/KA51201900089895.jpeg",
    "splitAddress": {
      "district": [
        "BANGALORE"
      ],
      "state": [
        ""
      ],
      "city": [
        "BELLANDUR"
      ],
      "pincode": "560103",
      "country": [
        "IN",
        "IND",
        "INDIA"
      ],
      "addressLine": "FLAT NO D-901 SUNCITY,BELLANDUR, BANGALORE SOUTH,BANGALORE,KA 560103"
    },
    "covDetails": []
  }
}

{
  "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