Part 09 — Data & Integrations

India Stack Lending

The rails that matter in lending

“India Stack” in an SME loan file is not one API. It is a bundle of consent, verification, document execution and registry rails that remove manual evidence from the journey. A practical lending stack normally uses Account Aggregator (AA) for bank-account data, GST and income-tax data through approved or consented channels, DigiLocker for documents, eSign and eStamp for execution, eNACH for repayment mandates, CKYC for KYC reuse, CERSAI for security-interest registration, NeSL for debt evidence, and Udyam for MSME identity.

Do not treat these rails as interchangeable. AA is a consented data-sharing protocol. DigiLocker is a document wallet. eSign signs a document hash. eStamp pays state stamp duty. eNACH creates a debit mandate. CKYC and CERSAI are registries. NeSL is an Information Utility under the Insolvency and Bankruptcy Code. Udyam is an MSME registration system. Each has a different legal owner, consent model, uptime behaviour and audit trail.

Account Aggregator mechanics

The Reserve Bank of India (RBI) introduced the NBFC-Account Aggregator framework through the Master Direction - Non-Banking Financial Company - Account Aggregator (Reserve Bank) Directions, 2016, and the Department of Financial Services page was still describing this as the governing framework in May 2026 (DFS AA framework). As of 31 March 2026, DFS reported 17 RBI-registered AAs, 179 live Financial Information Providers (FIPs), 989 live Financial Information Users (FIUs), more than 2.88 billion enabled financial accounts, and 284.6 million linked accounts (DFS AA progress update). Sahamati’s public dashboard showed the ecosystem continuing to grow through June 2026, with 314.50 million cumulative linked accounts and 493.50 million cumulative fulfilled consents (Sahamati dashboard).

The three regulated roles are simple but easy to mis-implement:

FIP: the institution that holds the data, such as a bank, NBFC, mutual fund, depository, insurer, pension CRA or GSTN where enabled.
FIU: the regulated institution that requests data for a permitted purpose, such as a bank or NBFC underwriting a loan.
AA: the RBI-licensed consent manager and data-transfer intermediary. Sahamati explains that the AA cannot store, process or sell customer financial data; the payload is encrypted and moved only after explicit user consent (Sahamati FAQ).

The technical protocol is maintained by ReBIT. ReBIT lists three API groups: AA APIs, FIP APIs and FIU callback APIs. Its AA API specification says the AA manages consent-artefact lifecycle through consent-flow APIs and mediates secure flow of financial information from FIPs to FIUs through data-flow APIs (ReBIT AA specifications).

The lending flow looks like this:

The lender’s loan origination system (LOS) creates a consent request through its FIU integration.
The borrower is redirected to, or opens, an AA app.
The AA authenticates the borrower and asks the borrower to link accounts at FIPs if not already linked.
The borrower approves or rejects a consent artefact.
The AA sends consent status to the FIU and FIP.
The FIU raises a data request against the approved consent.
The FIP sends encrypted financial information through the AA route; the FIU decrypts and stores only what is allowed by the consent and its own regulatory retention policy.

Account Aggregator flow where the borrower approves a consent artefact, FIPs release encrypted data through the AA, and the FIU lender receives permitted data for underwriting. — AA separates consent management from data holding: the borrower controls the artefact, FIPs hold source data, and the lender FIU receives only the permitted payload.

The consent artefact is the control surface. A good lending consent should state the purpose, data type, consent type such as profile, summary or transactions, one-time or periodic fetch, historical data range, fetch frequency, consent validity and data life. Sahamati’s Fair Use Template FAQ says these attributes map to ReBIT specifications and are intended to set outer bounds, not encourage maximal collection (Sahamati Fair Use FAQ). For SME underwriting, the usual request is six or twelve months of deposit account transactions. For post-disbursement monitoring, periodic pulls may be used, but the FIU should justify why monitoring is needed and avoid collecting broader data than the loan policy needs.

GST, ITR and Udyam surfaces

GST data reaches lenders through several surfaces. For statutory e-invoice and e-way bill operations, GSTN and NIC publish API documentation for taxpayer systems and GST Suvidha Providers (GSPs). GSTN’s e-invoice page says taxpayers, GSPs and accounting or billing providers can integrate with the e-invoice system through APIs and that authentication tokens are used for subsequent API calls (GSTN e-invoice APIs). The e-way bill API developer portal documents authentication, e-way bill generation, consolidated e-way bill generation, vehicle update, cancellation and rejection APIs, intended for technical solution providers and large taxpayers (E-way Bill API docs). NIC also states that e-way bill APIs are available for large taxpayers and GSPs (NIC e-way bill system).

In lending practice, the NBFC rarely connects directly to GSTN as a tax filer. It typically consumes GST return analytics through a GSP/ASP/vendor journey, borrower OTP/login consent, uploaded GSTR PDFs, or an Account Aggregator route where GST data is enabled for the use case. The important underwriting data is not just turnover. It is filing regularity, GSTR-1 versus GSTR-3B variance, cancelled GSTINs, top customers and suppliers, e-way bill movement, input tax credit reversals, nil-return months, and sudden spikes before the loan application.

Income-tax return (ITR) data is even more sensitive. The Income Tax Department publishes ERI API specifications for e-Return Intermediaries, including login, add-client, prefill, validate-and-submit, e-verify and acknowledgement flows; the official page says taxpayer consent is required for adding a client and fetching prefill details (Income Tax API specifications). For a lender, this means there is no generic public “pull anyone’s ITR” API. A lender uses a regulated or contracted channel, borrower-authorised credentials/OTP, ERI-assisted flow, document upload, or a vendor report. If a vendor claims direct ITR access without borrower authorisation, treat that claim as unverified and high-risk.

Udyam is the MSME identity rail. The official Udyam portal says registration is free, paperless and based on self-declaration; it also says the registration process is integrated with Income Tax and GSTIN systems, and that PAN and GST-linked investment and turnover details are taken automatically from government databases (Udyam portal). As of 15 July 2026, the portal’s dashboard showed about 9.00 crore total Udyam plus Udyam Assist registrations, including about 5.11 crore Udyam registrations and 3.89 crore Udyam Assist Platform registrations (Udyam dashboard). The public portal and verification flow are verifiable, but an open official Udyam API for arbitrary lender use could not be verified. In production, lenders generally use a consented vendor/API arrangement or portal verification, and they should store the Udyam Registration Number, certificate date, enterprise type, NIC activities and QR-verification evidence.

Documents, execution and mandates

DigiLocker is the document rail. Its partner page defines Issuers as authorised organisations that issue digital documents into DigiLocker and Requesters as entities such as banks, telecom providers and loan agencies that request access for verification (DigiLocker partner overview). DigiLocker says Requesters access through API Setu, authenticate with OAuth 2.0/OpenID, and that document access follows explicit user consent (DigiLocker security architecture). In lending, common pulls are PAN, Aadhaar XML/offline KYC where permitted, driving licence, GST certificate, Udyam certificate, bank account proof, education documents for promoter profiling, and incorporation documents when available.

eSign is the signing rail. The Controller of Certifying Authorities (CCA) describes eSign as an online electronic signature service that can be integrated via API; the signer is authenticated through e-KYC, the document hash rather than the full document is submitted for signing, and the one-time private key is destroyed after use (CCA eSign). CCA lists eSign API version 2.1, released on 7 February 2023, for online Aadhaar and other flows (CCA eSign API specifications). For loan documents, ensure the signatory authority is correct: proprietor, partner, authorised signatory under board resolution, guarantor and co-borrower are different legal actors.

eStamping is separate from eSign. Stock Holding states that it has been authorised by the Ministry of Finance as the Central Record-Keeping Agency for electronic stamp duty collection and that eStamping is a web-based solution for non-judicial stamp duty (StockHolding eStamping). Stamp duty remains state-specific; a Karnataka hypothecation deed, Maharashtra loan agreement and Delhi guarantee can have different duty logic. Vendor APIs can help procure stamps, but the lender must own the duty matrix and evidence of certificate number, article, first party, second party, amount and state.

eNACH is the repayment mandate rail. NPCI’s NACH circular page lists current NACH/eMandate circulars, including 2026 mandate-form and simplified-mandate updates (NPCI NACH circulars). NPCI’s eMandate eSign FAQ says the Application Service Provider must integrate with eSign APIs and generate the eMandate XML as per NPCI specifications; customer consent is mandatory, the Unique Mandate Reference number is 20 digits, and a mandate initiated using eSign has the fifth digit as “6” (NPCI eMandate eSign FAQ). Lenders should not book a loan as ready for disbursement until mandate registration status, maximum amount, frequency, start date and end date are stored.

Registries: CKYC, CERSAI and NeSL

CKYC reduces repeat KYC collection. RBI’s 8 July 2016 amendment operationalised the Central KYC Records Registry (CKYCR) and stated that the Government of India had authorised CERSAI to perform CKYCR functions; it required regulated entities to capture KYC information for individuals and legal entities in the prescribed templates (RBI CKYCR operationalisation). In SME lending, CKYC works well for individuals and increasingly for legal-entity KYC, but the lender still needs constitution-specific documents, beneficial-owner checks and periodic updation under the KYC Master Direction.

CERSAI is the security-interest registry. SARFAESI section 20 provides for a Central Registry for registration of securitisation, asset reconstruction and creation of security interest (India Code, SARFAESI section 20). The Central Registry Rules fee table includes registration or modification of mortgage by deposit of title deeds, hypothecation of plant and machinery, stock, debt/book debt/receivables, intangible assets, and under-construction property interests, with ₹50 or ₹100 base fees depending on whether the loan is up to or above ₹5 lakh for several categories (Central Registry Rules fee table). The operational point is strict: search before disbursement, file after security creation, update modification, and file satisfaction on closure.

NeSL is the Information Utility rail. PIB announced in 2017 that IBBI registered National E-Governance Services Limited (NeSL) as the first Information Utility, and explained that an IU stores financial information to establish defaults and verify claims under the Insolvency and Bankruptcy Code (PIB on NeSL IU registration). IBBI’s IU list continues to show NeSL as IU registration number IBBI/IU/01 (IBBI IU list). For lenders, NeSL is useful for loan record submission, authentication, evidence of debt and later default records. It does not replace bureau reporting or CERSAI security registration.