PAN verification for digital lending: what to check and why

Almost every digital lending journey in India asks for a PAN early on. It is quick to add and easy to get subtly wrong: a check that only confirms the number is well formed tells you very little, and a check that treats every mismatch as a failure turns away good applicants. This guide covers what a PAN check can tell you, what it cannot, and where it fits in an onboarding flow.

What a PAN is

A Permanent Account Number is a ten-character identifier issued by the Income Tax Department: five letters, four digits and a final letter. The fourth character shows the type of holder, such as P for an individual or C for a company, and for individuals the fifth character is the first letter of the surname.

That structure is useful for catching typing mistakes before you spend a check on them. It is not verification. A number can be perfectly formed and still not exist, belong to someone else, or no longer be usable.

Businesses, trusts and other entities hold PANs too. The same checks apply to them, with the name on record being the entity's name rather than a person's.

What a PAN check tells you

A verification check asks a source permitted to answer about the PAN itself. Done well, it returns:

• whether the PAN exists;
• its status, for example whether it is active or has been made inoperative;
• the permitted details held against it, such as the name on record;
• which source answered, and when.

Status matters more than many teams expect. Since July 2023, a PAN that should have been linked to Aadhaar but was not has been treated as inoperative, so an applicant can hold a genuine card that no longer works for some purposes. Your policy should say what happens in that case rather than leaving it to whoever reviews the file.

Three checks, not one

What lenders call "PAN verification" is usually three separate questions, and it helps to keep them apart:

• Status: does the PAN exist, and is it active?
• Match: do the name and date of birth the applicant entered agree with the details on record?
• Document: if the applicant uploaded a photo of their PAN card, what does it say, and does it agree with what they typed?

Each answers a different risk. Status catches numbers that are wrong or unusable. The match catches applicants using someone else's PAN with their own details. Reading the card catches typing errors and gives a reviewer something to compare, though reading a card does not show that the card itself is genuine.

Running them as separate checks also makes the reasons clear when something does not pass: a reviewer can see straight away whether the number, the details or the document was the problem.

What a PAN check cannot tell you

An active PAN with a matching name is a good start, not a conclusion. It does not confirm where someone lives today, it says nothing about creditworthiness, and for a business it does not show who ultimately owns it. Nor does a match prove that the person filling in the form is the PAN holder: that needs other evidence, such as comparing a selfie with an identity-document photo, or checking that the disbursement account is in the same name.

Handling the awkward cases

Most of the work in a PAN check is in the cases that are neither clean passes nor clean failures:

• Name variations. Initials, word order, honorifics and transliteration all produce near-matches. A field-level score with a reason lets you send partial matches to a person instead of declining them automatically.
• Inoperative status. Decide in advance whether this blocks the journey, triggers a request to the applicant, or goes to review.
• No answer. If the source is unavailable, record that the check could not be completed. Treating "could not check" as "failed" or as "passed" both cause problems later.
• Evidence. Keep the source and time of every answer, so the credit file shows what was checked and when.

Common mistakes

• Checking the format and calling it verification. A well-formed number has only passed a typing test.
• Running the same check again on every screen. Check once per application, keep the result with its time, and re-check only when your policy says it has gone stale.
• Showing the applicant what the source holds. If the name does not match, ask the applicant to confirm their details rather than displaying the name on record.
• Failing silently. When a check does not pass, tell the applicant what they can fix, such as a mistyped character, and give them a way to try again.

Where it fits in the flow

Because it is cheap and gates everything after it, the PAN check usually comes first, followed by the name and date-of-birth match. A bank account check in the same name and an analysis of bank statements tend to follow. Your policy decides which of these a product needs and what happens at each outcome.

Before any of it runs, record why you are checking and, where the source or your policy requires it, the applicant's consent. Those two records travel with the result, so anyone reviewing the file later can see not only what was checked but on what basis.

Koshio's PAN verification API is designed to return the status and the permitted details on record, each with its source and as-of time, alongside separate APIs for the name and date-of-birth match and for reading PAN cards. Access is by request while the platform is being built.