Aadhaar eSign for Banks & NBFCs: Legally Valid Signing
Most lending and account-opening teams in India believe they have solved signatures. The customer taps a checkbox, receives an OTP, enters it, and the loan agreement is marked executed. It feels like a signature. It is captured in an audit log. It has worked for years.
It is also, in a growing number of regulated contexts, not enough.
There is a specific legal definition of what counts as an electronic signature in India, and a specific technical service built to deliver it at population scale. If your onboarding stack does not produce that artefact, you are relying on evidence of intent rather than a signature the law presumes to be valid. This post explains the difference, how Aadhaar eSign actually works underneath, and what a bank or NBFC should check before committing to an implementation.
What "legally valid" actually means here
The Information Technology Act, 2000 recognises two things: digital signatures under Section 3, and electronic signatures under Section 3A. A Section 3A electronic signature is only valid if it uses a technique specified in the Second Schedule of the Act.
In 2015, the Government introduced the Electronic Signature or Electronic Authentication Technique and Procedure Rules, which added a technique described as e-authentication using Aadhaar e-KYC services. That technique is what the market calls eSign. It exists because the older model did not scale: to sign digitally, a person had to apply to a Certifying Authority, prove identity and address in person, and take custody of a hardware cryptographic token. That process cannot be run for a billion people, and it certainly cannot be run inside a two-minute onboarding journey.
So the distinction that matters is not "wet signature versus digital." It is:
- A recognised electronic signature — produced through eSign or a Digital Signature Certificate, backed by a certificate issued under the IT Act, cryptographically bound to the document.
- Everything else — checkbox consent, typed names, drawn squiggles, OTP confirmations. These may still be admissible as evidence of agreement. They are not a signature the statute presumes valid, and the burden of proving the transaction falls on you.
Aadhaar eSign vs DSC vs OTP click-wrap
| Aadhaar eSign | Token-based DSC | OTP click-wrap | |
|---|---|---|---|
| Legal basis | Section 3A, IT Act + Second Schedule technique | Section 3, IT Act | Contract law only; no statutory presumption |
| Identity proof | e-KYC authentication at the moment of signing | One-time verification at certificate issuance, then reused for years | Whatever the app captured |
| Key custody | Generated in an HSM, used once, destroyed immediately | User holds a physical token indefinitely | No keys involved |
| Certificate validity | Very short-lived, issued per transaction | Typically two to three years | None |
| Onboarding friction | Seconds, fully remote | Days, usually in person | Seconds |
| Fits mass retail lending | Yes | No | Fits, but weakly evidenced |
The short certificate lifetime is a design decision worth understanding rather than glossing over. Because the certificate expires almost immediately after signing, verification does not depend on revocation checking. There is no window in which a compromised long-lived key can be abused, and no CRL lookup to fail at verification time. The signature on the document remains verifiable long after the certificate has expired, because what is being verified is that the signature was valid when it was applied.
How the eSign flow actually works
Stripped of vendor language, a single eSign transaction looks like this:
- Your application prepares the document and computes a cryptographic hash of it.
- Only the hash is sent to the eSign Service Provider. The document itself never leaves your environment. This is the privacy property most teams underuse when explaining the service to their own risk committee.
- The signer authenticates through e-KYC, using biometric or OTP options supported by the e-KYC provider.
- A key pair is generated inside a Hardware Security Module operated by the service provider, and a short-validity signature certificate is issued against the authenticated identity.
- The hash is signed and the signature plus certificate are returned to your application.
- The private key is destroyed immediately after that single use. Your application affixes the signature to the document.
The whole exchange, including signer consent, certificate issuance, signature creation and certificate acceptance, is designed to satisfy the IT Act's requirements and to leave a complete audit trail behind it.
What changed for lenders
The Reserve Bank of India's Digital Lending Directions, 2025 tightened documentation obligations considerably. Regulated entities must furnish borrowers with a Key Fact Statement before the loan contract is executed, and digitally signed copies of the loan documentation — the KFS, sanction letter, terms and conditions and related disclosures — must be delivered automatically to the borrower's verified email or mobile number after execution.
Read that carefully against a typical stack. If the document your system emails after disbursal is a PDF generated from a template, with no certificate embedded, then "digitally signed" is doing work your architecture does not support. Two distinct obligations are involved:
- The borrower's signature on the agreement, where eSign is the mechanism built for the job.
- Your own institutional signature on documents issued on your letterhead, which is a separate organisational signing problem and usually solved with a document signer certificate held in an HSM.
Teams routinely build the first and forget the second. Both need to exist before the compliance question is closed.
The ASP and ESP distinction most teams get wrong
This is where implementations go sideways, so it is worth being precise about the roles.
An eSign Service Provider (ESP) is the entity that actually performs key generation, certificate issuance and signing. Under the current framework, only Certifying Authorities licensed under the IT Act can operate as ESPs.
An Application Service Provider (ASP) is the organisation whose application consumes the service — your bank, your NBFC, your government department. There is no registration process for becoming an ASP; you contract directly with an ESP.
Three consequences follow, and each one has derailed a project somewhere:
You cannot sublet the service. An ASP may use eSign only for applications it owns or operates. If you are a platform planning to resell signing capacity to your merchants or partner institutions under your own ASP arrangement, that model does not work as designed. Each entity needs its own arrangement.
Every request must be signed by you. eSign transactions are XML, and each request has to be digitally signed by the ASP before it reaches the ESP, using a valid certificate issued by a licensed CA. That certificate has to be provisioned, configured at the ESP's end, monitored for expiry, and rotated without downtime. It is a small operational detail that becomes a production incident when nobody owns it.
There is more than one API family. The Controller of Certifying Authorities maintains separate specification tracks — a CA e-KYC account-based series, an online Aadhaar and others series, and a remote API specification for remote key storage scenarios. Which one applies depends on your ESP, your authentication model and your use case. An integration built against the wrong specification is not a configuration change to fix.
What to evaluate before you commit
If you are scoping an eSign rollout, these are the questions that separate a two-week integration from a two-quarter one:
- Where does the signing component sit? A server deployed inside your own perimeter, communicating with your core systems over TLS, keeps document content and customer data within your control boundary. This matters for both your data governance posture and your auditors.
- Does it expose clean REST APIs? Your loan origination system, account opening journey and internal workflows all need to call it. XML-over-HTTP plumbing to the ESP should be the platform's problem, not something each application team re-implements.
- Can it handle multi-party workflows? Single-signer flows are the easy case. Guarantor sign-offs, co-applicants, internal approvers and sequenced signing orders are where most real lending documents live. Look for the ability to assign signatories, control signature placement, dispatch notifications, track status and retrieve completed documents.
- Is the audit trail complete and exportable? Consent capture, authentication method, timestamps, certificate details. Assume you will have to produce all of it for a regulator or a court.
- Does it scale with volume, not with headcount? Throughput at peak, and cost behaviour as transaction counts rise, both need to be answered before a pilot becomes production.
- Who owns ESP relationship management? Certificate rotation, specification upgrades and ESP-side changes are ongoing work, not one-time setup.
Where FinaSign fits
FinaSign is Finahub's end-to-end eSign implementation: an eSign server that runs on your premises with the web and mobile client modules needed to actually roll the service out to customers and staff. The server exposes REST APIs so existing origination and onboarding processes can call signing as a service rather than absorbing the ESP integration themselves, and the workflow layer handles document upload, signatory assignment, signature placement, notifications, progress tracking and retrieval of completed documents.
Because the deployment sits inside your infrastructure and only document hashes travel outward, the data-residency and privacy conversation with your risk team starts from a much easier position than a fully hosted alternative.
Frequently asked questions
Is Aadhaar eSign legally valid in India?
Yes. eSign is an electronic signature technique recognised under Section 3A of the Information Technology Act, 2000, read with the Second Schedule and the Electronic Signature or Electronic Authentication Technique and Procedure Rules, 2015. A document signed through eSign carries a valid digital signature backed by a certificate issued by a licensed Certifying Authority.
Does the eSign provider see our documents?
No. Only a cryptographic hash of the document is transmitted for signing. The document content stays within your systems, which is a deliberate privacy property of the eSign design rather than a vendor feature.
How is eSign different from a DSC token?
A DSC involves a long-lived certificate and a physical cryptographic token the user must obtain in advance and keep safe. eSign generates a key pair inside a Hardware Security Module at the moment of signing, uses it once, and destroys it. There is no token to issue, distribute, lose or renew.
Can we become an eSign Service Provider ourselves?
Not under the current framework — only Certifying Authorities licensed under the IT Act can operate as ESPs. Banks and NBFCs participate as Application Service Providers, contracting with an ESP.
Is OTP-based click-wrap acceptance enough for digital lending documentation?
It is weaker than most teams assume. RBI's Digital Lending Directions, 2025 require digitally signed loan documents to be delivered to borrowers, and a checkbox with an OTP does not produce a certificate-backed signature. Institutions relying on click-wrap for regulated lending documentation should review that position against the Directions.
Next step
If you are moving account opening, loan documentation or internal approvals off paper, the signature layer is the piece most likely to be underspecified until an audit forces the conversation. Getting it right early is considerably cheaper than retrofitting it.
Talk to the Finahub team about an eSign implementation →
Sources: Controller of Certifying Authorities, eSign — Online Electronic Signature Service and eSign API Specifications; CCA ASP On-Boarding Guidelines; Information Technology Act, 2000; Electronic Signature or Electronic Authentication Technique and Procedure Rules, 2015; Reserve Bank of India (Digital Lending) Directions, 2025.
This article is general information about regulatory and technical frameworks, not legal advice. Confirm current requirements against the primary source documents before making compliance decisions.
