Verification Workflows for Legal and Compliance Teams

Key takeaways

• A legal workflow cares about the record. For each check, keep what you asked, what the source returned, the time, the transaction id, who reviewed it and what you decided.
• Verification helps with "who is the counterparty and is it in good standing". It does not tell you whether a signatory has authority, whether a contract is enforceable, or whether a person is sanctioned or politically exposed.
• For companies, the CIN response lists directors with DIN, name and designation. Comparing the signatory with that list is a useful first test of authority, and a document such as a board resolution or authority letter remains the proper evidence.
• Treat e-stamping as part of the execution step. Duty comes from the calculation endpoint, orders carry your matter reference, and the issued certificate belongs in the matter file as a stored copy.
• Design for confidentiality. Use the minimum identifiers, keep them out of general logs, and decide with your client what they are told about the tools you use.
• Build evidence integrity into the pack: timestamps, hashes of stored files, reviewer sign-off and a clear rule for what a later reader may rely on.
• valid: false and found: false are completed, billable answers. Do not loop them. Retry only 429 and 502.
• A typical matter's checks cost a few rupees at the published rates; the arithmetic for three volumes is below.

Where verification fits in a legal matter

Legal work follows a lifecycle, and verification belongs at specific points in it. The table maps the stages to checks and shows who normally owns each.

The earlier a check happens, the cheaper a mistake is. A wrong legal name found at intake costs a correction. The same error found after execution can cost a re-stamped, re-signed instrument.

What a verification result can and cannot support

An honest list prevents misuse. A verification result can support statements such as: "On this date, the PAN supplied returned a valid record whose name matched the counterparty's declared legal name with the following score." Or: "On this date, the GSTIN supplied was active and its legal name was X." Or: "On this date, the company's registry status was active and its directors included the person who signed."

It cannot support statements such as: "The signatory was authorised." That requires a document and a legal judgement. Or: "The counterparty is solvent." Nothing here measures solvency. Or: "The counterparty is not sanctioned or politically exposed." These endpoints do not screen against sanctions or exposure lists. Or: "The person in front of us is the person on the document." The endpoints do not perform face matching or live identification, and they do not offer Aadhaar-based verification. Write your evidence-pack template so that it states what was checked and nothing more.

The matter file and the evidence pack

Define the evidence pack once, as a template, and make every matter use it. A good pack has seven parts.

1. Matter header. Matter reference, client, counterparty, date opened, responsible lawyer, reviewer.
2. Declaration. What the client or counterparty told you: names, identifiers, entity type, address, signatory.
3. Checks run. For each check: the endpoint, the time (UTC), the transaction id (referenceId), the environment of the key, and the identifiers you sent in masked form.
4. Results. The response fields you relied on, copied as received, and a stored copy of the raw response in an access-controlled store.
5. Findings. What agreed, what did not, and the rule or reasoning you applied to each difference.
6. Decision and sign-off. Who decided, on what basis, when, and who reviewed.
7. Attachments. Authority documents, resolutions, correspondence that resolved a finding, and the stored e-Stamp certificate where relevant.

The test of a good pack is whether a lawyer who was not involved can read it a year later and see what was done and why. Keep the template short enough that people complete it.

The workflow, step by step

1. Open the matter and capture the declaration. Record names exactly as given, identifiers, entity type, registered address and signatory. Decision: no declaration, no checks.
2. Run local format checks. Patterns for PAN, GSTIN, CIN and Udyam; for a GSTIN, that the PAN inside it equals the PAN declared. Decision: correct the declaration or continue.
3. Verify the individual or entity PAN. POST /v1/verify/pan with pan and the declared legal name. Read valid, type, registeredName, nameMatchScore. Decision: invalid stops; a type that contradicts the declared entity type goes to review.
4. Verify the registration. POST /v1/verify/gstin for a GST-registered counterparty, POST /v1/verify/cin for a company, POST /v1/verify/udyam if an MSME claim matters to the contract. Read the status fields. Decision: inactive stops the matter until resolved or documented.
5. Check the signatory. For a company, compare the signatory's name with the directors list from the CIN response, and verify the signatory's own PAN with their name. Decision: a signatory who is not a listed director needs an authority document before execution.
6. Review and sign off. A second person reviews findings above a severity you set. Decision: proceed, request documents or decline.
7. Execute and stamp. Calculate duty, create the order with the matter reference, attach parties, pay, and fetch the certificate. Decision: stamp only when the text is final.
8. Store and close. Save the evidence pack and the certificate bytes, and set the retention class.

Sample request and response: checking a signatory's PAN

The signatory check is the one most often skipped and most often regretted. The request carries the PAN and the name as it appears on the draft:

curl -X POST "https://api-b2b.stampmitra.in/v1/verify/pan" \
  -H "Authorization: Bearer $STAMPMITRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"pan":"ABCDE1234F","name":"Rahul Kumar"}'

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

The response includes fields that this workflow does not use. Store what you need for the decision and nothing else, because every extra personal field in a matter file is a field you must protect and later delete.

The Python function below builds an evidence-pack entry from a response, with masking and a hash of the raw response so that later tampering is detectable.

import hashlib
import json
from datetime import datetime, timezone

def mask(value: str, keep: int = 2) -> str:
    return value[:keep] + "*" * max(0, len(value) - keep - 1) + value[-1:]

def evidence_entry(matter_ref: str, endpoint: str, sent: dict, response: dict, decided_by: str, decision: str) -> dict:
    raw = json.dumps(response, sort_keys=True, separators=(",", ":"))
    return {
        "matter": matter_ref,
        "endpoint": endpoint,
        "checkedAtUtc": datetime.now(timezone.utc).isoformat(),
        "referenceId": response.get("referenceId"),
        "sent": {k: (mask(str(v)) if k in ("pan", "gstin", "cin", "accountNumber") else v) for k, v in sent.items()},
        "relied_on": {k: response.get(k) for k in ("valid", "type", "registeredName", "nameMatchScore", "panStatus")},
        "rawResponseSha256": hashlib.sha256(raw.encode()).hexdigest(),
        "decision": decision,
        "decidedBy": decided_by,
    }

Checking authority: from directors to documents

For a company, the CIN call returns a list of directors, each with a DIN, a name and a designation. Comparing the signatory's name with that list answers one narrow question: is this person on the company's director list as the registry shows it? It is a good first filter, because a signatory who is not a listed director needs an explanation.

It does not answer whether the person is authorised for this transaction. Authority can come from the articles, a board resolution, a power of attorney or a delegation, and it can be limited by amount or type of transaction. Your practice should treat a director match as a prompt to check the document, not a replacement for it. If the signatory is not a director, require the instrument that gives them authority, and attach it to the pack. Where the counterparty is not a company, such as a partnership firm, an LLP or a proprietorship, there is no CIN-style endpoint for authority on this platform, so the evidence is documentary: the partnership deed, the LLP agreement, the proprietor's declaration.

The Node function below shows the first-filter comparison and returns a finding for the pack.

export function signatoryFinding(signatoryName, cinResponse) {
  if (!cinResponse?.valid) return { result: "no_company_record", action: "request_documents" };
  const wanted = signatoryName.toLowerCase().split(/\s+/).filter(Boolean);
  const match = (cinResponse.directors ?? []).find((d) => {
    const name = d.name.toLowerCase();
    return wanted.every((w) => name.includes(w));
  });
  if (!match) return { result: "not_a_listed_director", action: "request_authority_document" };
  return { result: "listed_director", designation: match.designation, din: match.din, action: "check_authority_scope" };
}

The stamping step

Many instruments need to be stamped, and some of the most common legal documents are the ones that pass through your practice every day: rental and leave-and-licence agreements, affidavits, indemnity bonds, sale agreements and similar. The e-Stamp endpoints let you do this inside your matter workflow. List the services you are entitled to, resolve the state and article through the lookups, calculate duty with POST /v1/estamp/duty/calculate, create an order with POST /v1/orders using your matter reference as the externalOrderId, attach parties, pay through a payment intent, and fetch the certificate once the order completes.

Three points suit a legal practice. First, the duty and the article are matters of law that vary by state and change; the API calculates, and a lawyer decides the article. Second, stamp when the text is final and the parties are verified, since a stamped instrument cannot be quietly edited. Third, treat the certificate as part of the matter file: download it, store the bytes, record the document id and a checksum, and never rely on a temporary link. The e-stamp order flow guide walks through each endpoint, and the rental agreement e-stamping page covers the operating model for high volumes. Registration, where a state or the nature of the instrument requires it, is a separate legal step this API does not perform.

Decision table: valid, mismatch, inactive, not found

Confidentiality, privilege and minimisation

Legal work is confidential, and sending identifiers to a third-party service raises questions your profession already has rules about. Settle them before you deploy.

Decide with your client, in the engagement terms or in a notice, that you use verification tools and what data goes to them. Send the minimum: a PAN and a name, not a whole file. Do not include privileged content in any request, and none of these endpoints needs it. Keep verification data out of general-purpose logs and chat channels, and confine access to the people working on the matter. Understand the data-processing position of the provider: StampMitra publishes a data processing addendum and a retention and deletion schedule that your counsel should read before you rely on the service for client matters.

Where your professional rules or your client's contract impose stricter confidentiality duties, those win over convenience. If a client forbids third-party processing of a particular category of data, honour that and do the check manually.

Due diligence at volume

Some matters involve checking many counterparties at once: an acquisition with hundreds of customer contracts, a vendor consolidation, a portfolio review. The approach is the same as for a single matter, with batch mechanics added.

Build a register of counterparties with their identifiers, deduplicate by PAN, and group by entity type. Run the free local checks first. Run the paid checks in a batch within your plan's rate limit (the documented error example is 60 requests per 60 seconds; read your own limit from the dashboard and the pricing page), save each result keyed by counterparty and check so that a restart skips completed work, and stop on a 402 wallet error. Produce a summary by finding code, with counts, and a list of counterparties needing review. Keep the raw responses in the evidence store, and keep the summary in the matter file. Remember that the results are a snapshot at the time of the checks; if the transaction closes weeks later, decide whether to refresh the critical ones before closing.

A worked matter, from intake to closing

Take a hypothetical services agreement between your client, a mid-sized company, and a supplier that is a private limited company. The matter opens on Monday with the supplier's name, PAN, GSTIN and CIN, and the name of the manager who will sign for it.

On intake the paralegal records the declaration and runs the local checks. The PAN inside the GSTIN equals the declared PAN, and the CIN has the expected shape. Three paid checks follow: the PAN with the supplier's legal name, the GSTIN, and the CIN. The PAN returns a valid record of company type with a strong name score. The GSTIN is active and its legal name agrees. The CIN shows an active company whose directors include two people. The signing manager is not one of them.

The finding is straightforward: the signatory is not a listed director. The associate does not treat it as a problem with the supplier; she treats it as a missing document. The supplier is asked for the board resolution or authority letter that empowers the manager for this agreement. It arrives on Wednesday. The associate reads it, notes the scope and any limit on value, files it in the pack and records that authority was established by document.

The partner reviews the pack on Thursday. The review takes minutes, because the pack shows what was checked, when, with which transaction ids, and what each finding led to. On Friday the draft is finalised using the verified legal name, the instrument is stamped through the e-Stamp flow with the matter reference as the order reference, and the certificate is downloaded and stored with its checksum. The pack closes with the retention class set.

Six months later the client asks whether the supplier was in good standing when the contract was signed. The associate opens the pack and answers from it. The answer is precise because the record is: on that date, the registry status was active and the directors were those listed. The associate does not say more than the record shows, and does not claim the supplier remained in good standing afterwards, which the pack cannot show.

What else compliance needs beyond identity checks

Compliance officers are often asked to attest to checks that this kind of API does not cover, and it helps to be clear about the gaps so that nobody assumes coverage that is not there.

Sanctions and watch-list screening, adverse-media checks and politically exposed person screening need dedicated sources and processes. The verification endpoints here return registry facts about identifiers. Beneficial ownership analysis needs documents and judgement. Source-of-funds and source-of-wealth reviews are inquiries into a person's affairs, not registry lookups. Transaction monitoring is an ongoing analysis of behaviour. Regulatory reporting duties, for entities that have them, come from the relevant regulator's rules.

None of that makes identity and registry checks less useful. It means they are one layer in a set of controls, and your policy should say which layer covers which risk. A simple table in your compliance manual, listing each risk, the control that addresses it and the owner, will show where verification sits and where something else must stand in.

If you are a regulated entity, remember that your regulator, not a vendor, decides what is sufficient for your customer due diligence. Treat an API result as evidence that your policy may use, and have your compliance officer record how it is used.

Five scenarios from a legal-operations desk

These are hypothetical cases.

The struck-off counterparty

An associate checks a company before a services agreement. The CIN response shows the company status as not active. The matter pauses, the associate reports to the partner, and the client is told that the counterparty is not in good standing on the registry. Nothing is signed.

The signatory who is not a director

A manager signs on behalf of a private company. The directors list does not include their name. The associate asks for the authority letter, attaches it to the pack, and records that authority was established by document, not by registry.

The changed name

A party's PAN shows a name different from the draft because of a change after marriage. The name score is middling. The associate collects the document, records the reason in the pack and corrects the draft to use the verified name with the former name noted as an alias.

The duplicate matter

Two associates open matters for the same counterparty in one week. Deduplication by a keyed hash of the PAN flags it, the second associate reuses the first matter's evidence within the freshness window set by policy, and a note records the reuse.

The outage on closing day

The registry call returns 502 on the morning of execution. The matter stays pending, the paralegal retries with backoff, and the partner decides whether to proceed on the earlier check, with a recorded note, or to wait. The decision is the partner's and is written down.

Review rules a legal team can copy

These are suggestions for your practice to adapt.

• No execution without a recorded counterparty check for matters above a value or risk level you set.
• Signatory authority by document. The directors list is a prompt, never the authority itself.
• Second-person review for any finding above a severity, and for any decision to proceed despite an inactive status.
• Partner sign-off for exceptions to the pack, and for matters involving entities with a history of status problems.
• Evidence pack is mandatory. No matter closes without the template completed.
• Fresh enough. A check older than your freshness window is repeated before execution.
• No privileged content in requests. Identifiers only.
• No reliance beyond the check. Do not describe a result as showing more than it does.

Operating model

Give each role a clear part. Paralegals and intake staff run the standard checks and complete the pack. Associates review findings, judge authority and prepare drafts. Partners or responsible lawyers sign off exceptions and decide when to proceed. Operations staff handle stamping and payments. Compliance or records staff own retention and the audit of the packs. Engineering, if you have it, owns the keys, the wallet alerts and the platform queue.

Run a weekly review of findings by code and of exceptions, to improve the template and the rules. Run a sample audit of closed matters each quarter, checking that packs are complete and that referenced transaction ids resolve to the stored results.

What to store and for how long

Keep the evidence pack, the raw responses in an access-controlled store, the hashes, the authority documents and the stamped certificate. Keep personal identifiers masked in anything that circulates, and keep unmasked values only in the store that needs them. Delete according to the retention class.

Retention for legal records depends on your professional record-keeping obligations, your engagement terms, limitation periods, tax rules, the client's requirements and data-protection law. We cannot give you the periods. Take the question to your counsel or the responsible partner, write the answer into a schedule, and automate it. StampMitra's own handling is in its retention and deletion schedule. You can also use GET /v1/logs to review your account's request logs and GET /v1/usage/summary for usage totals; log retention depends on your plan and is described on the pricing page.

What it costs: three matter volumes

Pay-as-you-go prices are ₹5 per call for PAN, GSTIN, CIN, Udyam and the cross-lookups, and ₹5 per order as the e-Stamp API fee. Growth and Scale lower these rates and add a monthly plan fee. All figures exclude GST at 18 percent. The e-Stamp figures exclude the statutory stamp duty and the state procurement fee, which are the same on every plan and are quoted before an order, and duty-calculation calls are metered against your wallet, so confirm their pricing with support before you model quote volume; the tables do not include them.

The cost of one matter's counterparty checks (two PAN checks and one registry check), and the same with one e-Stamp order:

For the monthly models, assume every matter gets three standard checks and 60 percent of matters need an e-Stamp order. At 100 matters a month: 300 standard calls and 60 orders.

At 1,000 matters a month: 3,000 standard calls and 600 orders.

At 10,000 matters a month, as a very large legal-services operation might see: 30,000 standard calls and 6,000 orders.

Reading the tables: at 100 matters a month pay as you go is cheapest because the plan fees outweigh the lower rates; at 1,000 Growth is cheapest; at 10,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 after a successful response, so calls that fail with an error are not charged, although valid: false is a successful, charged answer. Compare the figures with the cost of one re-stamped or re-signed instrument, and with associate time spent on manual checks, using your own numbers; we do not quote an industry figure.

Rollout: sandbox, pilot, production

Sandbox. Build the pack template, the finding rules and the stamping step on sandbox keys, where responses are sample data and the wallet is not debited. The sandbox responder returns a valid result for the PAN SNDBX0000A and an invalid one for SNDBX9999F; for GSTIN 09SNDBX0000A1Z5 is valid and active and 09SNDBX9999F1Z5 is not valid and cancelled. Other inputs give stable but arbitrary outcomes, so do not assert on them. Confirm the current test values in the dashboard. Test every row of the decision table, the evidence-entry builder, the batch restart and the 402, 429 and 502 paths.

Pilot. Request production access, which needs your organisation's KYC approval and the per-product application. Run one practice group's new matters through the workflow while the old process continues in parallel for a few weeks. Compare the packs, and let partners review a sample.

Production. Widen by practice group. Run the quarterly pack audit from the first quarter. Alert on wallet balance, and keep the sandbox versus production keys guide for scopes and the IP allowlist.

Metrics worth watching

• Share of matters with a complete evidence pack at closing, which should be all of them.
• Findings by code, and the share that led to a document request.
• Time from matter opening to cleared counterparty review.
• Exceptions: matters executed despite an unresolved finding, with the sign-off recorded. This should be rare and fully documented.
• Packs that failed the quarterly audit, and why.
• Refresh rate: matters where a check was repeated because it had aged.
• Calls per matter, which exposes duplicates and retry loops.
• Stamped instruments with a stored certificate, against the number of orders placed.

Mistakes that weaken a legal verification process

• Treating a registry result as proof of authority. It is a first filter.
• Keeping screenshots instead of records. Capture transaction ids and stored responses.
• Copying whole responses into matter files. Keep only the fields you rely on.
• Skipping the freshness rule. A check from months ago is not today's position.
• Sending more than identifiers. Never include privileged content.
• Stamping before the text is final. Duty is paid up front.
• Saving a temporary download link as the record. Save the bytes.
• Describing results as showing more than they do. State what was checked and nothing more.
• No audit of the packs. A template nobody checks decays.

Related APIs and guides

The endpoints used on this page are in the verification API reference and the e-Stamp API documentation: PAN, GSTIN, CIN, Udyam, bank account, duty calculation, orders and documents. For related reading, see the KYB for B2B platforms page for entity checks, the rental agreement e-stamping page, the e-stamp order flow guide, the business verification guide and the errors guide. All industry pages are on the solutions page, and current 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-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"
    }
  ]
}

{
  "externalOrderId": "ord_ext_123",
  "createdAt": "2026-10-15T09:41:07.000Z",
  "serviceCode": "estamp.instrument.rent_agreement"
}

Frequently asked questions