Every wrong payout tells the same story afterwards: the account number had a typo, the beneficiary name was never checked, or the account belonged to someone other than the claimed recipient. Money sent to the wrong account in India is recoverable only through goodwill and paperwork. Money sent to a fraudulent account is usually gone.

A bank account verification API prevents the story from starting. Called before the first rupee moves, it confirms that an account exists, is active, and belongs to the person or business you intend to pay. This guide compares the four verification methods behind these APIs, maps them to use cases from lending disbursals to vendor onboarding, and lays out the architecture of a verification layer that holds up at scale.

What Is a Bank Account Verification API?

A bank account verification API is a programmatic service that validates bank account details account number, IFSC, and holder name against live banking rails before a business transacts with that account. A single call returns the account’s status and the holder name as registered with the bank, which the caller matches against expected details.

The API abstracts several underlying rails: IMPS-based penny drops, bank name-lookup services, and UPI-based flows. Good providers expose them behind one interface with intelligent routing, so the integrating team chooses an assurance level rather than a rail.

The business case is asymmetric. A verification call costs a few rupees. A failed payout costs reversal effort, settlement delay, and support load. A fraudulent payout costs the full amount plus investigation. Verification is one of the few controls in fintech where the ROI argument is arithmetic rather than persuasive.

The Four Verification Methods Compared

Four methods dominate, each trading assurance against friction differently.

Penny Drop (Forward)

The provider sends ₹1 via IMPS to the account. The transaction response confirms the account is active and returns the beneficiary name. It requires no customer participation, which makes it ideal for verifying details the business already holds in vendor masters and bulk payout files. Its limits: per-transaction cost, occasional bank-side latency, and no proof of who controls the account. Our [penny drop verification guide] covers it in depth.

Pennyless Verification

The provider queries name-validation services on banking rails without moving money. Results are faster and cheaper than penny drops, with no transaction to reconcile. Coverage varies by bank, so production systems use pennyless as the first attempt and fall through to penny drop where unsupported.

UPI VPA Validation

Given a UPI ID, the API returns the registered holder’s name instantly. It is the lightest check available and fits marketplaces and P2P contexts, though it verifies the VPA rather than a specific underlying account.

Reverse Penny Drop

The customer pays ₹1 via UPI from the account under verification, proving existence, name, and live control in one authenticated act. It is the strongest method for onboarding and disbursal account verification, and we analysed it fully in our [ penny drop guide].

The selection logic: verifying your own records → pennyless with penny drop fallback; verifying a customer’s claimed account at onboarding → reverse penny drop; lightweight marketplace checks → VPA validation.

Use Cases: Where Account Verification Prevents Losses

Lending disbursals. The RBI’s digital lending framework expects funds to flow directly to the borrower’s account. A bank account verification API confirms the account is real and name-matched to the borrower before disbursal the control point that blocks mule-routed loans.

Vendor and payout onboarding. B2B payment fraud frequently arrives as a “changed bank details” email. Verifying every new or modified beneficiary account against the registered name defeats the most common invoice-redirection plays.

Insurance and refunds. Claim payouts and merchant refunds to unverified accounts are a quiet leakage channel; verification closes it at negligible marginal cost.

Salary and gig payouts. Platforms paying thousands of workers verify accounts at onboarding to prevent both fraud and the operational drag of failed credits.

Mandate setup. Verifying the account before registering an eNACH mandate prevents downstream mandate failures.

Name Matching: The Hard Part Nobody Budgets For

Every method above returns a name, and every integration eventually discovers that names do not match themselves. “Priyanka Sharma” arrives as “PRIYANKA S”, “Sharma Priyanka”, or “Priyanka Sharma HUF”. Bank records carry truncations, initials, honorifics, and transliteration variants.

Naive exact matching fails legitimate customers at scale; naive lenient matching lets fraud through. The working answer is a scoring engine combining token-level comparison, phonetic matching, initial expansion, and ordering tolerance, with thresholds tuned per use case: stricter for disbursals, looser for refunds and a manual-review band between pass and fail.

Treat the thresholds as risk policy, not engineering constants. They deserve the same governance as underwriting rules, with periodic backtesting against confirmed-fraud and false-reject data. We expand the techniques in our dedicated [ API guide].

Architecture of a Production Verification Layer

Five components separate a robust verification layer from a single API call.

Method routing. A policy engine selects the method per context: penny-less first for cost, penny-drop fallback for coverage, and reverse penny-drop where control proof is required, without embedding rail logic in product code.

Retry and failover. Bank rails have bad hours. The layer retries transient failures, fails over across provider routes, and distinguishes “account invalid” from “rail unavailable,” because the two demand opposite user experiences.

Caching with expiry. A recently verified account need not be re-verified for every transaction, but for account status changes. Cache verification results with policy-driven TTLs, and always re-verify after beneficiary detail changes.

Audit logging. Every verification request, method, response, name score, and decision is stored immutably. When a payout dispute or regulator asks why money moved, this log is the answer.

Monitoring. Track success rates by bank and method. A single bank’s name-lookup degradation can silently push your traffic to costlier rails or inflate false rejections; dashboards catch it before finance does.

Compliance Context: RBI Expectations and Data Handling

Account verification sits inside several regulatory frames. RBI’s digital lending guidelines make borrower-account integrity a supervised expectation. KYC norms require that payout beneficiaries in regulated flows tie back to verified customers. And the DPDP Act treats account details and holder names as personal data: collect them for verification purposes, retain them under policy, and secure the logs under the fiduciary duties we outlined in our [DPDP Act analysis].

One practical note: verification responses contain bank-registered names of real people. They belong in the same protection class as KYC data, not in analytics stores with open access.

Key Takeaways

• A bank account verification API validates account existence, status, and holder name against live banking rails before money moves.
• Four methods: penny drop, pennyless, UPI VPA validation, and reverse penny drop trade assurance against friction; route by use case, not habit.
• Name matching is the operational hard part: fuzzy scoring with governed thresholds and a review band beats both strict and lenient matching.
• Production architecture needs method routing, retry/failover, TTL-based caching, immutable audit logs, and per-bank monitoring.
• Verification data is personal data under the DPDP Act; protect responses and logs like KYC records.

Frequently Asked Questions

Conclusion

Account verification is infrastructure in the truest sense: invisible when it works, expensive when it is absent. The teams that handle it well stop thinking in terms of a single API call and start operating a verification layer routed, monitored, logged, and governed like the risk control it is.

The next few years will push in one direction: more real-time payouts, more regulatory attention on where disbursed money lands, and more fraud pressure on the beneficiary edge. Institutions that invest in the verification layer now are buying optionality for every payment product they will launch later.

Reverse penny drop solves a critical gap in traditional bank account verification. A standard penny drop confirms that an account exists and returns the registered holder’s name, but it does not prove that the applicant currently controls that account. A fraudster could submit a relative’s, victim’s, or mule account details and still pass the check.

Reverse penny drop closes this gap by reversing the transaction direction. Instead of the business sending ₹1 to the customer, the customer pays ₹1 through UPI from the account being verified. This confirms account existence, retrieves the registered holder’s name, and demonstrates live control of the account.

This guide explains how reverse penny drop works, why lenders are standardising on it, and where it fits against other verification methods.

What Is Reverse Penny Drop?

Reverse penny drop is a bank account verification method in which the customer initiates a small UPI payment, typically ₹1, to the verifying business from the account under verification. The transaction’s response data reveals the account holder’s registered name and confirms the account is active, while the act of payment itself proves the customer controls the account right now.

The method rides on UPI’s architecture. When the customer approves the collect request or scans the QR code and pays, the transaction settles from a specific underlying bank account. The verifier receives the payer’s name as registered with the bank and the account reference, and immediately refunds the rupee.

Three verification outcomes arrive in one step: the account exists and is operational, the registered holder name is captured for matching, and control of the account is demonstrated through the successful, authenticated payment. Traditional methods deliver the first two; only reverse penny drop delivers the third natively.

How Reverse Penny Drop Works, Step by Step

A production reverse penny drop flow has five stages.

Step 1: Initiation

During onboarding or payout setup, the flow presents a UPI intent link, QR code, or collect request for ₹1, addressed to the business’s verification VPA.

Step 2: Customer Payment

The customer completes the payment in their UPI app, authenticating with their UPI PIN. This authentication is the control proof: it requires the registered device, the linked account, and the PIN.

Step 3: Data Capture

The verifier’s system receives the transaction confirmation containing the payer’s bank-registered name and account reference details, sourced from the banking rails rather than from anything the customer typed.

Step 4: Name Match

The captured name is matched against the application name using fuzzy logic that tolerates spelling variants, initials, and ordering differences. The discipline we cover in depth in our [name match API guide] matches scores route to pass, review, or fail.

Step 5: Instant Refund

The ₹1 returns to the customer automatically. The refund is more than courtesy: it keeps the flow’s economics honest and removes any consumer-protection ambiguity about collecting money during verification.

End to end, the journey takes seconds, and every element, payment, name, and refund is logged for audit.

Reverse Penny Drop vs Penny Drop: The Control Problem

The two methods answer different questions, and the difference is exactly where modern fraud lives.

Penny drop (forward): the business pushes ₹1 via IMPS to the account number and IFSC provided, and reads the beneficiary name from the response. It verifies existence and name. It cannot verify control because the customer never has to touch the account. We covered its mechanics in our [penny drop verification guide].

Reverse penny drop: the customer pulls money out of the account under their own authentication. Existence, name, and control are verified in a single authenticated act.

The control gap matters because account-detail fraud is cheap. Mule networks circulate valid account credentials precisely so that fraudsters can pass name-agnostic or detail-only check patterns we documented in our work on [money mule detection]. A lender that disburses to an account verified only by forward penny drop may be paying a mule; one that requires reverse penny drop knows the applicant, at minimum, controlled that account at verification time.

Cost and coverage also differ. Forward penny drop needs payout rails and carries per-transaction costs even for failed verifications. Reverse penny drop leverages UPI’s ubiquity, and failed attempts cost nothing because no money moves.

Why Digital Lenders Are Adopting Reverse Penny Drop

Four forces are pushing the reverse penny drop toward default status in lending.

Disbursal integrity. The RBI’s digital lending guidelines require funds to flow directly between the regulated entity and the borrower’s account. Verifying that the borrower controls the disbursal account, not merely that it exists, is the operational substance behind that rule. Our breakdown of the [RBI digital lending guidelines] covers the broader framework.

Mule and APP fraud pressure. With mule account activity under regulatory scrutiny, demonstrating account control at onboarding is becoming an expected line of defence rather than an advanced feature.

Conversion. Counterintuitively, paying ₹1 often converts better than typing an account number and IFSC without error on a phone keyboard. The UPI gesture is familiar; the sixteen-digit account number is not.

Data quality. The name arrives from the bank’s records via the transaction, eliminating the typo-driven mismatches that plague manually entered details.

Limitations and Fraud Scenarios That Remain

Reverse penny drop is strong but not sufficient. Three residual risks deserve attention.

Willing mules. If the account holder is a knowing participant, they can complete the payment themselves. Control is proven; intent is not. Behavioural and network analytics remain necessary.

Coerced or manipulated payments. Social-engineering scripts can walk a victim through “verification payments.” The ₹1 amount limits direct loss, but the pattern underlines why verification context and customer communication matter.

UPI coverage edges. Accounts without UPI linkage some corporate accounts and certain NRE/NRO setups cannot complete the flow. A forward penny drop fallback keeps these journeys alive.

The mature posture treats reverse penny drop as the control-proof layer inside a stack that still includes identity verification, device intelligence, and screening, not as a standalone gate.

Implementation: UX, Refunds, and Fallbacks

Four implementation choices drive results.

Explain the rupee. One line: “Pay ₹1 from the account you want verified; we refund it instantly” prevents the suspicion that otherwise kills conversion.

Automate refunds with monitoring. Refund latency is your most visible quality signal. Track it as an SLA; a delayed rupee generates support tickets far out of proportion to its value.

Route by outcome, not binary. Name-match scores should feed a threshold policy with a manual-review band, since bank-registered names legitimately differ from application names in ordering and transliteration.

Build the fallback waterfall. Reverse penny drop first; forward penny drop for UPI-uncovered accounts; document-based proof as the last resort. Configuration-driven routing keeps journeys alive without engineering changes.

Key Takeaways

• Reverse penny drop verifies a bank account by having the customer pay ₹1 via UPI from that account, proving existence, name, and, critically, live control.
• Forward penny drop verifies details; reverse penny drop verifies the person’s relationship to the account, which is where mule-driven fraud operates.
• The method aligns with RBI digital lending expectations on direct, borrower-controlled disbursal accounts.
• Residual risks, willing mules and coached payments mean it complements, not replaces, identity verification and behavioural analytics.
• Execution quality lives in refund SLAs, fuzzy name-match thresholds, and a fallback waterfall for non-UPI accounts.
  
  

Frequently Asked Questions

Conclusion

Verification methods earn adoption when they answer the question fraud is actually asking. For a decade, the question was “is this account real?” and penny drop answered it. Today the question is “does this person control this account?” and reverse penny drop answers that one, natively, in a single authenticated gesture.

Expect the direction to continue: verification is migrating from checking submitted data to observing authenticated actions. Institutions that rebuild their payout and disbursal flows around action-based proof now will find both their fraud teams and their regulators easier conversations in the years ahead.

A used-car loan against a vehicle the borrower does not own. A logistics fleet onboarding a truck whose registration lapsed two years ago. An insurance policy issued on a car already hypothecated to another lender. Each of these failures begins the same way: someone accepted a photocopy of a registration certificate at face value.

The registration certificate (RC) is the anchor document of vehicle ownership in India, and it is also one of the most casually forged. A vehicle RC verification API replaces document trust with source truth, pulling the vehicle’s live record from the national VAHAN registry in real time. This guide explains what the API returns, who depends on it, the fraud patterns it defeats, and how to build it into underwriting and onboarding flows.

What Is a Vehicle RC Verification API?

A vehicle RC verification API validates a vehicle’s registration details against government transport records in the VAHAN database maintained under the Ministry of Road Transport and Highways, aggregating registrations from RTOs nationwide. The caller submits a registration number (and, in some variants, a chassis number), and the API returns the vehicle’s official record.

The shift is from inspecting a document to querying the source. A photocopied RC proves only that a document exists; the API response proves what the government’s record says today: current owner, registration validity, hypothecation status, and the vehicle’s technical identity.

Timeliness is part of the value. Ownership transfers, loan closures, and fitness renewals update the registry; a document photographed last year says nothing about any of them. For any decision where the vehicle is collateral, cargo carrier, or insured asset, the live record is the only defensible basis.

What the API Returns: Fields That Matter

A typical vehicle RC verification API response carries four clusters of fields.

Ownership and registration. Registered owner name, registration number, registration date and validity, RTO of registration, and the owner’s serial number, which reveals how many hands the vehicle has passed through.

Vehicle identity. Chassis number and engine number, the immutable identifiers that bind the record to a physical machine. Maker, model, vehicle class, fuel type, and manufacturing year complete the profile.

Encumbrance. Hypothecation or lease status and the financier’s name, where the vehicle secures a loan the single most consequential field for lenders, addressed in its own section below.

Compliance status. Fitness certificate validity, insurance validity as recorded, tax status, and permit details for commercial vehicles.

Two verification moves multiply the response’s power. First, name-match the registered owner against the applicant using fuzzy logic, the discipline from our API guide. Second, for high-stakes cases, physically match the chassis number on the vehicle against the record, closing the loop between the database and the machine.

Who Uses RC Verification: Five Use Cases

Vehicle and used-car lenders. Before financing a vehicle purchase or a loan against a vehicle, the lender confirms ownership, checks existing hypothecation, and validates the asset’s identity and age inputs that flow straight into loan-to-value and title decisions.

Insurers. At policy issuance and claims, RC verification confirms the insured vehicle exists as described, is registered to the proposer, and matches the claimed specifications, cutting both mispriced policies and staged-claim exposure.

Used-vehicle marketplaces. Platforms listing vehicles verify RC details at listing time, filtering stolen, misdescribed, or encumbered inventory before buyers ever see it the same trust-at-source posture we advocate for merchant onboarding fraud .

Logistics and mobility platforms. Fleet onboarding pairs the driver with RC verification for the vehicle: valid registration, commercial permit where required, and fitness.

Corporate fleet and leasing operations. Lessors and fleet managers verify assets at intake and audit encumbrance status across portfolios periodically.

The Fraud Patterns RC Verification Defeats

Four patterns account for most vehicle-linked fraud, and the API addresses each structurally.

Forged or doctored RCs. Templates for RC smart cards circulate freely; a forged card supporting a loan application is a commodity attack. Source verification makes the forgery irrelevant; the record either matches or it does not.

Ownership misrepresentation. The applicant presents a genuine RC for a vehicle they do not own. Matching the owner’s name against the applicant’s verified identity closes this, subject to legitimate transfer-lag windows discussed below.

Double financing. A vehicle already hypothecated is offered as fresh collateral to a second lender. The hypothecation field exposes the existing charge instantly.

Identity swapping. A record for one vehicle supports a transaction involving another the classic cloned-plate or salvage-rebirth pattern. Chassis and engine numbers in the response, checked against the physical asset, break the swap.

None of this replaces behavioural fraud controls; a legitimate vehicle can still anchor a first-party fraud application. The API removes the asset-identity layer of the attack surface, so investigation effort concentrates on intent consistent with the layered posture in our digital lending fraud analysis.

Hypothecation: The Field Lenders Cannot Skip

Hypothecation deserves separate treatment because it is where the most expensive mistakes concentrate.

When a vehicle secures a loan, the financier’s charge is endorsed on the registration record. A vehicle RC verification API surfaces that endorsement and the financier’s name. Three operational rules follow.

Check at origination, always. An existing hypothecation on a vehicle offered as collateral means the equity backing your loan may not exist. Every vehicle-secured credit decision needs this field in its policy, not in an analyst’s habit.

Verify termination, not promises. Borrowers refinancing will assert that the prior loan is closed. The record’s hypothecation status after the prior lender’s termination filing is the fact; the assertion is not.

Re-check at portfolio events. Top-ups, restructures, and repossession actions warrant a fresh pull because the record can change over a loan’s life.

The registry reflects filings, and filings lag reality. A closed loan may show hypothecated until the termination is processed. Build a review path for these windows rather than hard-declining, and document the evidence you accepted.

Integration Patterns and Edge Cases

Four practices make RC verification production-grade.

Verify at the decision point. Call the API where the result changes the outcome: underwriting, listing approval, claim admission, and store the full response with a timestamp as decision evidence.

Handle registry lag gracefully. Recent ownership transfers and loan closures take time to reflect. Define documented exception paths (transfer application receipts, lender NOCs) with expiry windows, so lag neither blocks legitimate business nor becomes a permanent bypass.

Combine with OCR for document-first flows. Where the journey starts with an RC image, [OCR extraction] reads the registration number, and the API verifies it; the document becomes an input, never the evidence.

Respect the data’s purpose. Vehicle records contain personal data (owner names, linkage to addresses via RTO records). Pull them for the stated verification purpose and retain them under policy, in line with DPDP obligations.

Key Takeaways

• A vehicle RC verification API validates ownership, registration, identity, and encumbrance against live VAHAN records instead of trusting documents.
• The response’s power multiplies when paired with owner name matching and, for high-stakes cases, physical chassis verification.
• Lenders, insurers, marketplaces, and fleet platforms use it to defeat forged RCs, ownership misrepresentation, double financing, and identity swaps.
• Hypothecation status is the non-negotiable field for any vehicle secured lending decision checked at origination, closure, and portfolio events.
• Build for registry lag with documented exception paths, and store timestamped responses as decision evidence.

Frequently Asked Questions

Conclusion

Vehicle verification illustrates a principle that now runs through all of Indian regtech: wherever a government registry exists, the registry, not the document, is the evidence. The RC card in an applicant’s hand is a claim; the VAHAN record is the fact, and the API is simply the shortest path between a decision and that fact.

As transport records deepen challan histories, fitness telemetry, and transfer digitisation, the same API surface will carry AML Compliance Software India. Lenders and platforms that wire RC verification into their decision points today are also laying the pipe for whatever the registry learns to say next.

The customers with the most money to move are often the hardest to onboard. An NRI opening an NRE account, a returning professional applying for credit, a foreign national investing through Indian rails none of them fit the Aadhaar-first onboarding flows that domestic stacks optimise for. What they all carry is a passport.

The passport is simultaneously the world’s most standardised identity document and, in many Indian KYC stacks, the least automated. A passport verification API changes that: combining machine-readable zone (MRZ) validation, document authenticity checks, and, for Indian passports, verification against Passport Seva issuance records. This guide covers how passport verification works technically, where it anchors NRI and cross-border journeys, and the design choices that separate real verification from image inspection.

What Is a Passport Verification API?

A passport verification API validates a passport’s authenticity and its holder’s details for identity verification. Depending on the passport’s origin and the integration depth, it operates across three layers: structural validation of the machine-readable zone, forensic analysis of the document image, and, where available, as with Indian passports verification against the issuing authority’s records, as with Indian passport verification.

The passport’s special property among identity documents is standardisation. Under ICAO Doc 9303, every passport carries an MRZ: the two lines of characters at the bottom of the data page encoding name, nationality, passport number, date of birth, sex, and expiry, each protected by check digits. That structure gives automated verification a foothold no purely domestic document offers.

For Indian KYC purposes, the passport is also an officially valid document under the PMLA/RBI framework, which makes the API a compliance instrument, not merely a fraud control.

The Three Layers: MRZ, Document Forensics, Source Records

Robust passport verification stacks three checks, each catching what the previous cannot.

Layer 1: MRZ Validation

OCR reads the MRZ; the API validates its check digits and internal consistency, then cross-checks MRZ data against the visually printed fields. Amateur forgeries fail here: editing the printed name without recomputing MRZ check digits is the most common forgery error. MRZ validation is fast, deterministic, and catches a surprising share of fraud on its own.

Layer 2: Document Forensics

For the image itself: template conformity for the claimed issuing country and series, font and layout analysis, photo-tampering detection, and screenshot/re-capture detection. This is the same forensic discipline we detailed in our [document forgery detection guide], applied to a document family with unusually well-defined templates.

Layer 3: Source Verification

Where issuance records are accessible, the Indian passport’s file number check is the key case; covered next, the API validates details against the authority’s records, converting document trust into registry truth. For foreign passports, source access is generally unavailable, so layers one and two, plus biometric binding, provide assurance.

The layering logic mirrors the rest of the verification stack: structure catches the careless, forensics catches the skilled, and source catches the document that never existed.

Indian Passport Verification: The File Number Check

For Indian passports, verification can go beyond the document. The Passport Seva ecosystem allows validation of a passport’s details against issuance records using the file number and holder details, confirming that the passport number, name, and issuance particulars correspond to a genuinely issued document.

This closes the gap that pure document analysis leaves: a physically perfect counterfeit of a passport that was never issued, or a genuine-looking document whose details were never in the registry. Registry-anchored verification defeats both structurally.

The operational notes: capture the file number where flows allow (it appears on the passport), treat registry mismatches as review events rather than auto-fraud (data-entry variance exists in older issuances), and log the registry response in the evidence bundle alongside MRZ and forensic results. The composite MRZ valid, forensics clean, registry matched, face bound is as strong as Indian document verification gets outside Aadhaar’s cryptographic rails.

NRI and Cross-Border Use Cases

Five journeys lean on passport verification as their identity anchor.

NRI banking. NRE/NRO account opening runs on passport-plus-visa/status evidence. A passport verification API moves these journeys from days of document review toward the same-session onboarding domestic customers get, within the RBI’s KYC framework for non-residents.

Investments and securities. NRI participation in mutual funds, PIS accounts, and demat onboarding requires passport-anchored KYC; automating this process directly shortens funding timelines.

Cross-border fintech. Remittance platforms, international payroll, and multi-currency accounts verify passports from many issuing countries, which is where MRZ standardisation and template libraries earn their keep.

Foreign nationals in India. Employment, banking, and rental/utility flows for expatriates are anchored on passports, where no Indian registry document exists yet.

High-value domestic KYC. Even for residents, the passport serves as a premium OVD in wealth, private banking, and [enhanced due diligence] contexts, where multi-document corroboration is policy.

Across all five, the passport pairs with a live selfie and [face match with liveness] against the data-page photo, the binding without which any document verification, however deep, verifies paper rather than people.

Passport Verification in the OVD and FATF Context

Two regulatory frames shape passport verification design.

Domestically, the passport’s OVD status under PMLA rules and the RBI KYC Master Directions makes it complete identity-and-address evidence for KYC (address per the passport, with policy handling where the current address differs). Institutions running OVD waterfalls as discussed in our [voter ID verification] should treat the passport rail with the same automation dignity as the Aadhaar rail.

Internationally, FATF’s risk-based standards drive the cross-border angle: non-resident customers are commonly higher-risk classifications, which means stronger identification, sanctions and PEP screening against travel-document names, with all the fuzzy-matching complexity covering and often enhanced due diligence. The passport verification API is the identification backbone of that stack, not the whole of it; screening and EDD layers complete the picture, as our [PEP screening guide] details.

Implementation: Capture Quality, Expiry, and Binding

Four implementation realities decide field performance.

Capture quality dominates. Glare on the laminate, cropped MRZ lines, and low-light captures cause most failures. Invest in guided capture UX frame overlays, glare detection, and automatic recapture before tuning anything downstream.

Expiry is policy, not just data. The API returns expiry; your policy decides validity windows (some products require months of remaining validity). Feed expiry into re-verification calendars for long-lived relationships, the same lifecycle logic we prescribed.

Handle name structure generously. Passports split names into surname and given names; applications often do not. Matching logic must handle the structural difference plus diacritics and transliteration in foreign passports.

Data handling is high-stakes. Passport data is sensitive personal data with cross-border transfer implications for international platforms. Minimise retention, control access, and align storage with DPDP obligations and fiduciary duties in our [DPDP analysis].

Key Takeaways

• A passport verification API layers MRZ validation, document forensics, and, for Indian passports, Passport Seva registry checks into one identity verification rail.
• MRZ check digits under ICAO 9303 catch the common forgeries; forensics catch skilled ones; registry checks catch never-issued documents.
• The passport anchors NRI banking, cross-border fintech, foreign-national onboarding, and premium/EDD domestic KYC as a full OVD.
• Cross-border use pulls FATF-driven screening and EDD around the verification core; the API is the backbone, not the whole stack.
• Field performance turns on capture UX, expiry policy, name-structure-aware matching, and DPDP-grade data handling.

Frequently Asked Questions

Conclusion

Passport verification is where Indian KYC meets the global identity system and where stacks built exclusively around domestic rails show their edges. The customers arriving through this rail are disproportionately valuable: NRIs, cross-border businesses, global professionals. Serving them at domestic-onboarding speed is a competitive statement, not a compliance chore.

The technical future is already visible: chip-based (eMRTD) reading, where the passport’s embedded chip yields cryptographically signed data and a photo, will do for passports what signed XML did for Aadhaar: replace forensics with mathematics. Institutions building layered passport verification now will find that an upgrade, not a rebuild.

“I work at a large IT company, ₹85,000 a month.” Every lender hears versions of this claim thousands of times a day, and the traditional evidence for it salary slips and HR letters can be produced by any laptop with a template. Payroll document fraud is not sophisticated; it does not need to be, because most verification of it is visual.

There is a harder record to fake: the trail of provident fund contributions that formal employment leaves at the EPFO, indexed by the employee’s Universal Account Number (UAN). Contributions arrive monthly from the employer’s compliance systems, establishment by establishment, month by month. A UAN verification API turns that trail into an underwriting and screening input. This guide explains what the UAN reveals, how verification flows work, and where EPFO data fits and does not fit in income assessment.

What Is a UAN Verification API?

A UAN verification API validates a person’s employment claims against EPFO records anchored to their Universal Account Number, the portable, lifelong account number that links an employee’s provident fund memberships across employers.

Depending on the integration mode and consent, the API family covers several operations: resolving a UAN from identifiers such as mobile or PAN, validating that a UAN exists and matches the claimed holder’s name, and fetching employment history for the establishments (employers) attached to the UAN, with joining/exit dates and contribution activity.

The evidentiary logic is what makes this rail valuable. Provident fund contributions are statutory filings made by employers, not documents supplied by applicants. A twelve-month contribution streak from a named establishment is third-party, regulatorily anchored evidence of employment, the same “source over document” principle that runs through this entire verification series, applied to the claim that fraud targets most: income.

What EPFO Data Reveals: Employment, Tenure, Stability

Read properly, UAN-linked data answers four underwriting questions.

Is the person formally employed now? Active, recent contributions from a current establishment confirm formal employment; the binary claim of salary slips cannot prove it.

By whom, and since when? Establishment names and joining dates verify the stated employer and tenure. An applicant claiming five years at a company whose EPFO linkage began four months ago has some explaining to do.

How stable is the employment history? The sequence of establishments and gaps between exits and joinings sketches job stability; frequent short stints and long unexplained gaps are a warning signal, not a disqualification.

Is the claimed salary plausible? Contribution amounts derive from PF wages, which relate to (though do not equal) actual salary. Contributions consistent with a ₹25,000 wage base sit awkwardly under an ₹85,000 income claim, flagging the file for the deeper income verification that our [bank statement analysis] and rails provide.

The composite is a fraud filter and a stability profile in one pull, which is why the UAN check increasingly runs early in salaried-lending funnels, before costlier verification spends.

How UAN Verification Flows Work

Production flows follow a consent-first pattern in four steps.

Step 1: Identifier Capture and Consent

The applicant provides their UAN, or the flow resolves it from mobile/PAN where supported, alongside explicit consent for employment verification. Consent capture here is not ceremonial: employment data is personal data, and the DPDP-grade audit trail starts at this step.

Step 2: UAN Validation and Name Match

The API confirms the UAN exists and returns the registered holder details, which are fuzzy-matched against the applicant’s verified identity. A UAN belonging to someone else borrowed employment identity fails here.

Step 3: Employment History Fetch

With consent, the flow retrieves establishment history and contribution activity. OTP-based flows to the UAN-linked mobile provide the strongest consent binding, at some conversion cost; design the fallback path deliberately.

Step 4: Signal Extraction and Decision

Raw history converts to decision features: current-employment flag, current-employer name match against the application, tenure, contribution recency and continuity, and wage-base plausibility versus claimed income. Features feed the credit policy; the raw response is archived as evidence.

Lending Use Cases: The Salaried-Borrower Stack

Personal loans and credit cards. The UAN check verifies the employment premise of the application in seconds. Employer name mismatches, dead contribution trails, and tenure inflation surface before bureau pulls and statement analysis incur their cost.

Salary-advance and earned-wage products. Products whose entire premise is active employment use contribution recency as a live eligibility signal.

Income corroboration. UAN wage-base signals triangulate with bank-credit patterns and ITR data into an income confidence score three independent sources that fraud must defeat simultaneously, a materially harder problem than forging one document. This triangulation is the practical answer to the payroll-forgery patterns we documented in [first-party fraud in India].

Employer-risk overlays. Lenders maintaining employer-level risk views (delinquency by employer, establishment health) key those overlays to verified EPFO establishment identities rather than free-text employer names, cleaning a notoriously dirty data field.

Beyond Lending: BGV and Platform Onboarding

Background verification. Employment-history checks are the slowest, most expensive leg of traditional BGV calls to HR departments, with weeks of waiting. UAN-anchored history compresses the formal-sector portion to an API call inside the stack our [background verification API guide] describes, with human verification reserved for gaps and informal-sector claims.

Gig and platform onboarding. Platforms verifying that a would-be borrower or partner holds (or recently held) formal employment use the same rail for eligibility and risk tiering.

Insurance and underwriting adjacent. Employment stability features feed persistency and risk models where occupation and income claims matter.

Tenant and high-trust screening. Where lawful basis and consent exist, employment verification supports high-commitment relationship checks, always purpose-bound and always consented to.

Limits of EPFO Data and How to Design Around Them

Four limits define the rail’s honest boundaries.

Formal-sector coverage only. EPFO coverage applies to establishments within the EPF Act’s ambit; informal workers, many gig workers, most self-employed, and some exempt establishments sit outside it. Absence of EPFO history is not an absence of income; route these applicants to the [bank statement and ITR rails] rather than declining on a null.

Wage base is not salary. PF contributions are calculated on PF wages, frequently capped or structured below gross salary. Use contribution signals for plausibility bands, never as an income figure.

Filing lag. Employer filings run on statutory cycles; the most recent month or two may legitimately show as pending. Recency thresholds must absorb normal lag.

Exempt trusts and edge structures. Some large employers run exempted PF trusts with different data visibility. Establishment-level nulls need review routing, not auto-decisions.

Designed around these limits as one triangulation source among three, with null-handling and lag tolerance, the UAN rail adds a layer of employment truth that document-based verification never offered.

Key Takeaways

• A UAN verification API validates employment claims against EPFO contribution records, statutory, and employer-filed evidence that salary-slip forgery cannot touch.
• One pull answers four questions: employed now, by whom and since when, how stable, and whether claimed income is plausible.
• Consent-first flows with name matching against verified identity to defeat borrowed-UAN fraud and satisfy DPDP discipline.
• In lending, UAN signals run early, cheap fraud filtering before bureau and statement spends, and triangulate with bank and ITR data for income confidence.
• EPFO’s limits (formal-sector scope, wage-base ≠ salary, filing lag) define routing rules, not disqualification: nulls go to alternate income rails.

Frequently Asked Questions

Conclusion

Income fraud persists because income evidence was always the applicant’s to manufacture. The UAN rail inverts that: the evidence is filed by employers, held by a statutory body, and accumulated month by month over years a record that a template cannot counterfeit and a desperate applicant cannot backfill.

The larger pattern is triangulation. EPFO, bank statements via account aggregators, and tax records are converging into a three-source income truth layer for Indian lending. Each source alone has gaps; together, they leave fraud very little room. Lenders assembling that layer are now building the underwriting advantage of the next credit cycle.

A customer completes full KYC at a bank. Three months later, the same customer applies for a loan at an NBFC. The process restarts from zero: same documents, same verification, same friction. The CKYC registry was built to end this cycle. Yet, a decade after launch, thousands of regulated entities still treat it as a batch-upload formality rather than live compliance infrastructure.

That approach just became expensive. CKYC 2.0, rolling out from July 2026, replaces batch files with real-time APIs, mandates OTP-based customer consent, integrates DigiLocker, and enforces Aadhaar masking on every submission. This guide explains how the CKYC registry works, what changes under CKYC 2.0, where institutions fail their upload obligations, and how to build a compliant integration.

What Is the CKYC Registry?

The CKYC registry, formerly known as the Central KYC Records Registry (CKYCRR), is India’s centralised repository of verified customer KYC records. CERSAI (Central Registry of Securitisation Asset Reconstruction and Security Interest of India) operates it under the Prevention of Money Laundering (Maintenance of Records) Rules, 2005.

The premise is simple. A customer completes KYC once with any regulated entity. That entity uploads the verified record to the registry. The customer receives a 14-digit KYC Identification Number (KIN). From that point, every other regulated entity across banking, securities, insurance, and pension can retrieve the same verified record instead of collecting documents again.

The registry serves four regulatory domains at once. RBI-regulated banks and NBFCs, SEBI-regulated brokers and mutual funds, IRDAI-regulated insurers, and PFRDA-regulated pension entities all report into the same system. This cross-sector design is what separates the CKYC registry from any single regulator’s KYC database.

For customers, the value is a one-time KYC. For institutions, the value is faster onboarding, lower verification costs, and duplication of registry flags when the same identity already exists, which supports fraud control. For a deeper view of the fraud angle, see our guide on [mule account detection in India] (internal link).

How the CKYC Registry Works: KIN, Search, and Download

The operational flow of the CKYC registry has three legs: search, download, and upload. Understanding each leg matters because compliance obligations attach to all three.

Step 1: CKYC Search

Before running fresh KYC, an institution searches the registry using the customer’s PAN, Aadhaar (in permitted form), or other identifiers. CKYC 2.0 adds mobile-number search, which materially improves hit rates. A successful search returns the customer’s KIN.

Step 2: CKYC Download

With the KIN and the customer’s consent, the institution downloads the full KYC record: identity details, address, photograph, and document references. Under CKYC 2.0, this download requires OTP-based consent from the customer. No consent means no access, regardless of purpose.

Step 3: CKYC Upload

When an institution completes fresh KYC for a customer not yet in the registry, it must upload the record. The upload window is 10 days from account opening. The record must follow CERSAI’s prescribed format, and under CKYC 2.0, that format shifts toward JSON-based API submission with automated validation.

The KIN Lifecycle

The KIN stays constant for the customer’s lifetime. However, records require maintenance. When a customer updates an address or document, the institution that captured the change must update the central record. Periodic re-KYC obligations under the RBI KYC Master Directions also flow into the registry, a topic we cover in detail in our [RBI KYC Master Directions 2025 guide] (internal link).

CKYC 2.0: What Changes in 2026

CKYC 2.0 is the most significant upgrade since the registry launched in 2016. Five changes matter operationally.

Real-Time APIs Replace Batch Files

The legacy registry ran on batch uploads: institutions compiled records, submitted files, and waited for acceptance or rejection reports. CKYC 2.0 moves to real-time API interaction. Search, download, upload, and record updates all happen through live endpoints. Consequently, institutions running legacy core banking systems need a middleware layer to convert existing data into the new JSON-compliant structure.

Mandatory OTP-Based Consent

Every record retrieval now requires the customer’s explicit OTP consent. This aligns the registry with the consent architecture of the DPDP Act, which already governs how fintechs handle KYC data.

Mandatory Aadhaar Masking

All submissions must carry masked Aadhaar numbers, with only the last four digits visible. Manual masking is no longer acceptable; the masking must be automated and verifiable. Institutions still storing full Aadhaar images in their KYC archives carry direct regulatory exposure.

DigiLocker Integration

CKYC 2.0 connects the registry to DigiLocker. Customers can view and manage their KYC records and consent through their DigiLocker account, and institutions can verify documents against government-issued digital originals. This closes a long-standing gap: customers previously had almost no visibility into their own central KYC record.

Stricter Validation and Deduplication

The upgraded registry applies stronger validation at the point of submission. Records with mismatched fields, poor-quality images, or unmasked Aadhaar data face rejection in real time rather than in a delayed error report. In addition, tighter deduplication logic makes it harder for synthetic and duplicate identities to enter the system.

Compliance Deadlines Most Institutions Miss

Three timelines govern CKYC registry compliance, and audit findings repeatedly show institutions missing all three.

First, the 10-day upload window. Once digital KYC is completed and an account is opened, the record must reach the registry within 10 days. Institutions relying on monthly batch cycles structurally violate this window.

Second, update obligations. When a customer’s KYC details change, the institution capturing the change must update the central record promptly. Stale central records defeat the registry’s purpose and create downstream liability for every institution that later relies on them.

Third, video KYC integration. The RBI now requires regulated entities to push KYC data captured through V-CIP (video KYC) to the registry. If your video KYC pipeline does not terminate in a CKYC upload, the process is incomplete. Our breakdown of [RBI-compliant video KYC] covers the V-CIP workflow itself.

Penalties for KYC record-keeping failures arise under the PMLA framework, and enforcement has been tightening across banks and NBFCs. The cost of a compliant pipeline is small compared to the cost of a regulatory finding.

CKYC vs eKYC vs Video KYC: Where Each Fits

Teams often conflate these three terms, yet they solve different problems.

eKYC is a verification method. It authenticates a customer’s identity against the Aadhaar database using an OTP or biometrics, and it returns demographic data. It answers the question: Is this person who they claim to be?

Video KYC (V-CIP) is a full KYC process. An authorised official verifies the customer over a live video call, checks documents, performs liveness checks, and completes customer identification per RBI norms.

The CKYC registry is neither a method nor a process. It is the system of record. eKYC and video KYC produce verified data; the registry stores, standardises, and redistributes that data across the financial system.

A well-designed onboarding flow therefore uses all three. Search the CKYC registry first. If a record exists, download it with consent and apply risk-based checks. If no record exists, run eKYC or video KYC, then upload the fresh record within 10 days. This sequencing cuts onboarding cost because a registry hit is cheaper than a full KYC run.

How Fintechs Integrate the CKYC Registry via API

Direct CERSAI integration suits large banks with dedicated compliance engineering. Most fintechs and NBFCs instead integrate through a verification infrastructure provider that wraps CKYC search, download, and upload into managed APIs. The architecture has four components.

Search-First Orchestration

The onboarding flow calls a CKYC search API at the start of every journey. A hit routes the customer into a consent-and-download path. A miss routes them into fresh KYC. Done well, this single decision point reduces both drop-off and per-onboarding cost a dynamic we quantified in the [India Digital Onboarding Benchmark Report 2026].

Consent Capture

The flow must capture OTP consent before any download and log it in an audit-ready trail. Consent records need to survive regulatory inspection years later, so store the timestamp, the OTP transaction reference, and the scope of consent.

Data Normalisation

Registry records and freshly captured KYC data rarely share a schema. A normalisation layer maps both into your internal customer model and flags conflicts, for example, a registry address that differs from a freshly submitted one. Conflicts should route to review, not silently overwrite.

Upload Pipeline with Validation

Build validation to CERSAI’s specification before submission: field formats, image quality, and automated Aadhaar masking. Rejected uploads that sit unresolved are the most common audit finding, so treat rejection handling as a monitored queue with an SLA, not a log file.

Common Failure Modes and How to Avoid Them

Four patterns account for most CKYC registry failures in production.

Skipping the search step. Institutions run full KYC on every customer and only touch the registry at upload time. This doubles the cost and misses the deduplication benefit. Fix: make CKYC the first call in every onboarding journey.

Batch mentality. Records accumulate for weeks before upload, breaching the 10-day rule. Fix: trigger uploads from the account-opening event, not from a calendar.

Unmasked Aadhaar in archives. Legacy records captured before masking mandates still hold full Aadhaar numbers. Fix: run a remediation programme that re-masks stored artefacts, an exercise closely related to the [KYC remediation playbook] we published earlier.

No ownership of rejections. Upload rejections land in a report nobody reads. Fix: assign rejection queues to a named owner with resolution SLAs, and track rejection rate as a compliance KPI.

Key Takeaways

• The CKYC registry, operated by CERSAI, is India’s cross-sector KYC system of record; every regulated entity must search it, use it, and feed it.
• CKYC 2.0 (from July 2026) introduces real-time APIs, mobile-number search, OTP-based consent, DigiLocker integration, and mandatory automated Aadhaar masking.
• The 10-day upload window after account opening is a firm requirement; batch-cycle uploads violate it.
• Search-first orchestration cuts onboarding cost: a registry hit is cheaper and faster than a fresh eKYC or video KYC run.
• Treat upload rejections, consent logs, and record updates as monitored compliance processes with owners and SLAs, not background jobs.

Frequently Asked Questions

Conclusion

The CKYC registry is moving from a compliance afterthought to live infrastructure. Under CKYC 2.0, the institutions that win are those that treat the registry as the first call in onboarding rather than the last step in record-keeping. Real-time search, consent-led downloads, and automated, validated uploads will separate low-cost, low-friction onboarding operations from those absorbing rejection backlogs and audit findings.

The strategic view is larger than compliance. As the registry, DigiLocker, and the Account Aggregator framework converge, India is assembling a consent-driven identity layer for finance. Institutions that build clean CKYC pipelines are now also building the rails they will need for whatever that layer standardises next.

Salaried borrowers leave income trails everywhere: payslips, EPFO contributions, salary credits. Self-employed borrowers leave one that matters most: the income tax return. For business owners, professionals, and freelancers, the ITR is frequently the only structured, government-filed statement of income that exists. It is also the document most often submitted as a doctored PDF.

An ITR verification API resolves the contradiction. Instead of trusting an uploaded acknowledgement, the lender validates the return’s existence and key figures against Income Tax Department records through consent-based data fetches or acknowledgement-number verification. This guide explains what ITR verification actually confirms, how the flows work, how ITR data feeds underwriting for the self-employed, and the misreadings that trip up credit teams.

What Is an ITR Verification API?

An ITR verification KYC API Integration Guide against Income Tax Department records rather than accepting borrower-supplied documents at face value. Depending on the integration mode, it confirms that a return was actually filed for a given PAN and assessment year, retrieves the return’s key financial figures with the taxpayer’s consent, and cross-references related records such as Form 26AS (tax credits) and the Annual Information Statement (AIS).

The distinction the API enforces runs through all modern verification: a PDF of an ITR acknowledgement is a claim; the department’s record is the fact. ITR forms are structured, well-understood documents, which makes them easy to forge convincingly. Template kits for ITR-V acknowledgements circulate exactly as bank statement templates do, a supply chain we documented in our [document forgery detection guide].

For lenders, the API converts the most important self-employed income document from a forensic problem into a data problem, verified figures, machine-readable, ready for underwriting logic.

What Gets Verified: Returns, Acknowledgements, and Linked Records

ITR verification operates at three depths, and choosing the right one is a policy decision.

Filing verification. The lightest check: confirming that a return exists for the PAN and assessment year, matching the acknowledgement number the borrower provided. This defeats wholesale fabrication of the “return” that was never filed with minimal friction.

Return data retrieval. With the borrower’s consent, the flow retrieves the filed return’s substantive figures: gross total income, income heads (business/profession, salary, capital gains, house property), deductions, and tax paid. This is the underwriting-grade depth, because it verifies the numbers, not just the filing.

Corroboration via 26AS and AIS. Form 26AS shows tax deducted and collected against the PAN; TDS entries from clients and employers are third-party evidence of real revenue. The AIS aggregates reported financial transactions. Together, they let underwriters test whether the return’s claimed income is consistent with what payers independently reported triangulation of the same kind we advocate with [bank statement analysis].

The PAN Verification API verifies everything, so ITR verification presumes a verified PAN and identity. The ITR rail extends an identity-verified journey; it does not begin one.

How ITR Verification Flows Work

A production ITR verification journey runs in four steps.

Step 1: Consent and Credential-Free Access

The borrower consents to income verification, and the flow initiates a consent-bound fetch. Modern implementations avoid collecting the borrower’s income tax portal credentials; credential-sharing patterns are a security anti-pattern and increasingly a regulatory one. Data Fiduciary under the DPDP Act to the taxpayer’s registered mobile is the clean design.

Step 2: Return Retrieval or Acknowledgement Check

Per policy depth, the flow either verifies the acknowledgement number and filing status or retrieves the return’s key figures for the required assessment years, typically the latest two or three for underwriting.

Step 3: Cross-Verification

Retrieved figures reconcile against the borrower’s stated income, uploaded financials, 26AS/AIS entries, and bank-statement cash flows. Discrepancies are routed by size and pattern: rounding gaps pass; structural contradictions go to review.

Step 4: Feature Extraction and Decision

Verified figures become underwriting features: income levels, growth trends, income mix, and tax-payment behaviour feed the credit policy, with the raw evidence archived. The journey adds seconds to onboarding, not days, which is what makes verified-ITR underwriting viable at digital-lending speed.

Underwriting the Self-Employed: From ITR Data to Credit Decisions

Verified ITR data changes self-employed underwriting in four concrete ways.

Multi-year income with trend. Two to three years of verified returns establish income level and trajectory. A profession showing steady field income across years is a different risk from one whose income doubled in the year before the loan application the classic pre-application inflation pattern.

Income quality decomposition. The return separates business income from capital gains, rent, and other heads. FOIR and serviceability calculations should weight recurring operating income differently from one-off gains, a distinction a single “annual income” number hides.

Consistency scoring. ITR versus 26AS versus bank credits: three independent views of the same economic reality. High-coherence borrowers earn faster approvals and better pricing; incoherent files earn scrutiny. This is the practical machinery behind the risk signals we mapped in [credit risk assessment: hidden signals lenders miss].

Segment expansion. Verified tax data lets lenders serve professionals and MSME owners who fail pay-slip-based policies, entirely widening the addressable market without widening the risk appetite, in line with the cash-flow-lending direction the [account aggregator framework] is driving.

ITR Fraud Patterns and How Verification Defeats Them

Four patterns dominate ITR-linked fraud.

Fabricated acknowledgements. A return that was never filed, presented as a polished ITR-V PDF. Filing verification kills it in one call.

Altered figures. A genuine filing whose PDF is edited to inflate income before upload. Return data retrieval makes the PDF irrelevant; the department’s figures are the figures.

Belated strategic filing. Returns filed just before the loan application, sometimes for multiple back years simultaneously, showing convenient income. Verification cannot make this income false; the return is real, but filing dates in the verified record expose the pattern, and policy should treat freshly filed multi-year backlogs as a review trigger.

Revised return games. Filing high, applying for the loan, then revising downward. Checking the latest return status and revision history for the relevant years closes the window.

The residual risk is honest-looking dishonesty: real filings on inflated declared income (paying some extra tax as the cost of fraud). This is where 26AS/AIS corroboration and bank-flow reconciliation earn their place: third parties did not report the income, and the accounts do not show it, however genuine the filing is. The layering logic matches our broader [first-party fraud] doctrine: no single artefact, however verified, decides alone.

Reading ITR Data Correctly: Common Misinterpretations

Credit teams new to verified ITR data make four recurring errors.

Confusing gross with taxable income. Deductions and exemptions make taxable income a poor proxy for cash income capacity. Serviceability should build from gross income and cash-flow reality, not the tax-optimised bottom line.

Penalising legitimate tax planning. Presumptive taxation schemes (such as those used by small businesses and professionals) report income on a deemed basis. Low declared margins under a presumptive scheme are a regime feature, not automatically an income-hiding signal; policy must read the scheme context.

Ignoring seasonality and lumpiness. Business income is uneven. A single weak year inside a healthy multi-year pattern is noise; underwriting on the worst year alone systematically misprices seasonal businesses.

Treating filing gaps as disqualification. Genuine reasons for missing years exist (income below thresholds, new businesses). Gaps warrant routing to an alternate income evidence bank that flows via AA and GST data rather than reflexive decline.

The discipline is the same one that governs every rail in this series: verified data deserves informed interpretation, and thresholds deserve governance.

Key Takeaways

• An ITR verification API validates tax return existence and figures against Income Tax Department records, replacing forgeable PDFs with source truth.
• Three depths filing verification, consented return retrieval, and 26AS/AIS corroboration map to escalating assurance needs.
• For self-employed underwriting, verified multi-year returns enable trend analysis, income-quality decomposition, and consistency scoring against bank flows.
• Verification defeats fabricated and altered returns; filing-date and revision-history checks expose strategic filing; corroboration catches inflated-but-real filings.
• Interpretation discipline matters: gross versus taxable, presumptive-scheme context, seasonality, and gap-routing keep verified data from being misread.

Frequently Asked Questions

Conclusion

The ITR sat for years in an awkward position: the most authoritative income document for the self-employed, handled through the least reliable channel: borrower-uploaded PDFs. Verification at source resolves the awkwardness, and with it, one of the structural reasons self-employed credit stayed expensive and slow.

The direction from here is convergence: tax records, GST data, RBI Governor: ULI and Account Aggregators to Boost Credit Access, and EPFO signals fusing into a composite income layer that underwrites people by what their economic footprint shows rather than what their documents claim. Lenders wiring the ITR rail in now are building toward that layer, not just closing a fraud gap.

For decades, proving income in India meant emailing bank statement PDFs documents that are slow to collect, painful to parse, and easy to forge. The account aggregator framework replaces that entire pattern with a consent-driven data pipe: the customer approves a request, and verified financial data flows from their bank to the lender through an RBI-licensed intermediary, digitally signed at the source.

Adoption has crossed the tipping point. Hundreds of banks, NBFCs, and financial institutions are live on the network, and cumulative consents have run into the hundreds of millions. Yet many lending teams still understand the account aggregator framework only as a buzzword. This guide explains the architecture, the consent mechanics, the practical lending use cases, and the failure modes that determine whether an AA integration actually performs.

What Is the Account Aggregator Framework?

The account aggregator framework is India’s regulated system for consent-based sharing of financial data. It was created by the RBI through the NBFC-Account Aggregator Master Directions (2016) and operationalised in 2021, built on the DEPA (Data Empowerment and Protection Architecture) model and technical standards published by ReBIT.

At its core sits a new class of RBI-licensed entity: the Account Aggregator (NBFC-AA). An AA does one job: it moves encrypted financial data from institutions that hold it to institutions that need it, strictly on the customer’s digital consent. The AA cannot read, store, or sell the data it transports. It is a consent manager and a pipe, deliberately “data-blind.”

The framework’s scope started with bank deposit accounts and has been expanding across the financial system securities, insurance, pensions, and GST data under a cross-regulator design involving the RBI, SEBI, IRDAI, and PFRDA. Sahamati, the industry alliance, coordinates ecosystem standards and onboarding.

The Three Roles: FIP, AA, and FIU

Every transaction in the account aggregator framework involves three parties, and the vocabulary matters because contracts, certifications, and integrations are organised around it.

The FIP (Financial Information Provider) holds the customer’s data typically a bank, but also insurers, depositories, and mutual fund RTAs. When valid consent arrives, the FIP packages the requested data, signs it, encrypts it, and ships it.

The AA (Account Aggregator) manages the customer’s consent and relays the encrypted payload. The customer holds an AA handle (similar in spirit to a UPI ID) through an AA app of their choice, where they can view, approve, pause, and revoke consents.

The FIU (Financial Information User) consumes the data: a lender underwriting a loan, a PFM app building a dashboard, a wealth platform assessing suitability. FIUs must be regulated entities and must handle received data per the consent’s terms.

The separation is the framework’s trust design. The FIP never learns the FIU’s underwriting logic. The FIU never touches bank credentials. And the AA, which sees everything, reads nothing.

How the Consent Artefact Works

The consent artefact is the legal and technical heart of the account aggregator framework. It is a machine-readable, digitally signed object specifying exactly what the customer agreed to.

A consent artefact defines, among other fields: the data types requested (for example, deposit account statements), the accounts covered, the date range of data, the purpose code, whether access is one-time or recurring, the frequency of recurring fetches, and the consent’s expiry.

Three properties make it more than a checkbox.

It is granular. A lender can request twelve months of statements from one account for the stated purpose of loan underwriting and nothing more travels.

It is revocable. The customer can revoke consent from their AA app at any time, and recurring fetches stop.

It is auditable. Every consent, fetch, and delivery is logged with signatures across the chain. When the DPDP Act asks a lender to prove a lawful basis for the financial data it holds, an AA consent artefact is close to the strongest evidence available a synergy we explored in our analysis of [DPDP obligations for fintechs]

For lenders, the operational implication is that consent design is product design. Over-broad requests depress approval rates; well-scoped requests convert.

What the Account Aggregator Framework Means for Lending

Lending is the framework’s flagship use case, and the impact lands in four places.

Income and cash-flow verification. Instead of collecting PDFs, the lender fetches source-signed statement data and runs it through analysis directly through the workflow our [bank statement analysis API guide]describes, now fed by a tamper-proof channel.

Cash-flow-based underwriting. Reliable transaction data at scale enables lending decisions built on cash-flow patterns rather than collateral or bureau history alone. For thin-file and self-employed borrowers, this is often the difference between a decision and a rejection a gap we examined in [credit risk assessment signals lenders miss]

Monitoring through recurring consent. A lender with recurring-fetch consent can monitor a borrower’s account health across the loan tenure, spotting stress early instead of at default.

Cost and speed. AA fetches completely in seconds and costs a fraction of manual statement operations, compressing loan turnaround times from days to minutes for data-ready customers.

The RBI’s digital lending framework reinforces the direction: regulated, consent-based data flows are the compliant path, while scraping and credential-sharing patterns face increasing hostility.

AA Data vs Uploaded Bank Statements: The Fraud Difference

The account aggregator framework changes the fraud equation in a way that underwriting teams should internalise.

An uploaded bank statement is an image of a claim. It can be edited, fabricated from templates, or assembled from screenshots the risk class we dissected in [why screenshot PDFs are a compliance nightmare] and our work on first-party fraud. Detection depends on forensic analysis and is probabilistic.

AA-delivered data is signed at source by the FIP and encrypted end-to-end. The borrower never touches the payload, so there is nothing to edit. Statement fraud does not become harder; it becomes structurally impossible on that channel.

The honest caveat: AA data authenticates the account’s contents, not the borrower’s intent. Mule-fed accounts, circular transactions staged to inflate income, and coordinated first-party fraud remain live threats that need behavioural analysis on top of authentic data. Authenticity moves the battle; it does not end it.

Implementation Realities: Coverage, Drop-offs, and Data Quality

Four realities separate AA integrations that perform from those that stall.

FIP coverage and reliability. Not every bank is live, and among live FIPs, response reliability varies. Production systems track FIP-level success rates and route around weak providers, with a statement-upload fallback for uncovered accounts.

Consent-journey drop-off. The customer must discover their AA handle (or create one), locate their accounts, and approve the request. Each step leaks conversion. In-flow education, sensible defaults, and requesting the minimum viable scope measurably improve completion.

Data quality variance. FIPs differ in how they populate transaction narrations and balances. Your analysis layer needs normalisation logic per FIP quirk, or downstream models will misread perfectly authentic data.

Consent lifecycle operations. Recurring consents expire, get revoked, and need renewal journeys. Treat the consent state as a monitored operational domain because a fetch against an expired consent is not a bug; it is a compliance incident.

Key Takeaways

• The account aggregator framework is RBI-regulated, consent-based financial data sharing built on DEPA with data-blind NBFC-AAs as the transport layer.
• FIPs hold data, FIUs consume it, AAs manage consent, and the consent artefact defines scope, purpose, duration, and revocability in signed, auditable form.
• For lenders, the framework enables tamper-proof statement fetches, cash-flow underwriting, and tenure-long monitoring at a fraction of manual cost.
• AA data eliminates statement forgery on its channel, but behavioural fraud, staged transactions, mule funding, and intentional default still require dedicated detection.
• Performance depends on operations: FIP-level routing, consent-journey UX, per-FIP data normalisation, and disciplined consent-lifecycle management.

Frequently Asked Questions

Conclusion

The account aggregator framework is best understood not as a data product but as a change in who controls financial information. Data now moves because the customer says so signed, scoped, and revocable and institutions compete on what they do with it rather than on how they extract it.

For lenders, the strategic question has moved past “should we integrate?” to “how good is our consent UX, our FIP routing, and our cash-flow analytics?” As the framework absorbs more data types and the DPDP Act raises the price of unconsented data, AA-native institutions will underwrite faster, monitor deeper, and defend their data practices more easily than anyone still asking for PDFs.

Every credit decision in India starts with the same question: how has this person handled debt before? And the answer lives with four RBI-licensed credit information companies: TransUnion CIBIL, Experian, Equifax, and CRIF High Mark. The difference between lenders is not whether they use bureau data; it is how intelligently their systems consume it.

A credit score API is the consumption layer: a programmatic interface that pulls scores and full credit reports into onboarding, underwriting, and monitoring flows in real time. Done well, it powers instant pre-qualification, sharper risk pricing, and portfolio early-warning. Done carelessly, it burns money on unnecessary pulls, damages applicants’ scores with avoidable hard inquiries, and violates the consent framework around credit data. This guide covers the mechanics, the soft-versus-hard distinction, the regulatory frame, and the architecture that gets it right.

What Is a Credit Score API?

A credit score API connects a lender’s systems to one or more credit information companies (CICs), returning an applicant’s credit score and, where requested, the full credit information report in seconds, inside the digital journey.

The scores themselves are bureau-computed summaries of repayment history, typically on a 300–900 scale, where higher indicates lower observed default risk. Each bureau computes its own score from its own data, so the same borrower legitimately carries different numbers across CIBIL, Experian, Equifax, and CRIF High Mark a fact that matters for multi-bureau strategy later in this guide.

The API’s value is workflow position. A score consumed in real time can gate a journey (knock-out rules), price it (risk-based interest), or shape it (offer sizing) decisions that a next-day batch file cannot make. For digital lenders operating with approval-in-minutes expectations, the credit score API is as foundational as the disbursal side.

Scores, Reports, and What Bureaus Actually Return

Integrations consume bureau data at two levels, and conflating them causes both overspending and underwriting blindness.

The score is a single number plus score factors: compact, cheap, and fast to decide on. It suits pre-qualification, knock-out screening, and top-of-funnel filtering.

The credit information report (CIR) is the substance: every reported tradeline (loans, cards, their sanctioned amounts, balances, and month-by-month payment history), current and historical delinquencies, written-off and settled accounts, recent inquiry history, and identity/address variations reported by other lenders.

Serious underwriting reads the report, not the number. Two applicants with identical 750 scores can carry entirely different risk: one with a long, clean, seasoned history; another recently recovered from settlement with thin active credit. Report-level features utilisation trends, delinquency recency, inquiry velocity, unsecured-to-secured mix are where model lift lives. Inquiry velocity in particular doubles as a fraud signal: a burst of applications across lenders in days is the classic pattern preceding [bust-out and first-party fraud], and it is visible only in the report.

Soft Pull vs Hard Pull: The Distinction That Shapes Product Design

The most consequential design choice in credit score API usage is when a pull counts as an inquiry.

A hard pull is a lender-initiated inquiry attached to a credit application. It is recorded on the applicant’s report, visible to other lenders, and, in volume, depresses the applicant’s score. Hard pulls belong at the point of genuine application, once.

A soft pull is an inquiry that does not enter the applicant’s lender-visible inquiry history, typically consumer-initiated score checks and certain pre-qualification and monitoring accesses. Soft-pull mechanisms power “check your eligibility without affecting your score” experiences.

The product implications are direct. Pre-qualification funnels built on hard pulls damage the very applicants they hope to convert and inflate declined-applicant harm; building them on soft-pull or consumer-consented mechanisms is both kinder and commercially smarter. Marketplace and multi-offer platforms must be especially careful: shopping one applicant across many lenders as separate hard inquiries manufactures score damage at scale. And monitoring existing borrowers belongs on review-purpose access, not fresh application-coded inquiries.

Whatever the mechanism, the constant is consent and purpose: every access must map to a permissible purpose under the credit information framework, honestly coded.

The Regulatory Frame: CICRA, Consent, and RBI Rules

Credit data is among the most regulated personal data in India, and integrations inherit the obligations.

The Credit Information Companies (Regulation) Act, 2005 (CICRA) governs the ecosystem: CICs must be RBI-licensed, access is restricted to specified users for permissible purposes, and accuracy and grievance obligations attach to both bureaus and reporting institutions. An API integration is a specified-user relationship with rules, not a data faucet.

Consent and purpose discipline. Pulling credit data requires the applicant’s consent for a defined purpose; repurposing pulls (marketing analytics on underwriting data, for instance) breaches the frame. The DPDP Act layers general fiduciary duties on top of the combination we analysed in our [DPDP compliance guide].

Accuracy and dispute duty. Lenders are data furnishers as well as consumers: what you report shapes the borrower’s record everywhere. Reporting hygiene and timely dispute resolution are supervisory expectations, and the RBI has progressively tightened timelines and compensation norms for delayed corrections.

Free report awareness. Consumers are entitled to access their own credit report from each bureau annually at no cost, worth reflecting in customer education, since informed borrowers dispute stale negatives that would otherwise distort their own underwriting inputs.

Where Credit Score APIs Power Lending Journeys

Pre-qualification. Instant eligibility indications at the top of the funnel, built on soft mechanisms, filter applicants before KYC and income verification spends sequencing that our [onboarding benchmark analysis] shows materially improves funnel economics.

Underwriting. The hard pull plus full-report feature extraction at genuine application, fused with verified income and bank-flow rails into the composite decision.

Risk-based pricing. Score bands and report features map to rate grids, letting lower-risk borrowers see better prices, competitive necessity as much as risk management.

Portfolio monitoring. Periodic review-purpose refreshes across the book surface deteriorating borrowers (rising utilisation, new delinquencies elsewhere) before your own EMIs bounce early-warning that pairs with the mandate-failure telemetry.

Thin-file routing. A “no-hit” or thin-file response is a routing instruction, not a decline: send these applicants to cash-flow underwriting on [account aggregator data] rather than punishing the absence of history.

Integration Architecture: Multi-Bureau, Caching, and Cost Discipline

Five architectural practices separate mature integrations.

Multi-bureau strategy. Bureaus differ in coverage by segment and geography. A waterfall (primary bureau, fallback on no-hit) recovers decisions on applicants a single bureau misses; parallel pulls suit high-value decisions where report discrepancies themselves are a signal. Route by economics: fallback pulls only where the primary genuinely fails.

Pull-once discipline. Cache bureau responses per applicant per application with policy-defined validity, so retries, resumed journeys, and internal re-checks reuse the stored report instead of re-pulling, protecting both cost lines and applicants’ inquiry histories.

Consent-and-purpose logging. Every pull stores its consent artefact, purpose code, and response immutably. When a borrower disputes an inquiry or a regulator audits access patterns, this log is the defence.

Score-version awareness. Bureaus revise scoring models. Decision policies and cutoffs must version alongside, or a bureau-side model update silently shifts your approval rates.

Resilience. Bureau endpoints have outages and latency spikes. Timeouts, failover to alternate bureaus, and a defined degraded-mode policy (queue or decision on non-bureau signals for pre-approved segments) keep journeys alive.

Key Takeaways

• A credit score API delivers bureau scores and full credit reports from India’s four CICs into real-time lending journeys.
• Scores gate and filter; reports underwrite tradeline, delinquency, utilisation, and inquiry-velocity features carry the real signal.
• Soft-versus-hard pull design shapes both applicant welfare and funnel economics; pre-qualification belongs on soft mechanisms, hard pulls at genuine application only.
• CICRA, RBI norms, and the DPDP Act make consent, purpose coding, reporting accuracy, and dispute handling supervisory obligations, not hygiene.
• Architecture maturity = multi-bureau waterfalls, pull-once caching, immutable consent logs, score-version management, and outage resilience.

Frequently Asked Questions

Conclusion

Bureau data is the oldest risk infrastructure in consumer lending, and the credit score API is what keeps it relevant at digital speed. But the winning integrations treat the bureau as one voice in a chorus fused with verified income, cash flows, and behavioural signals rather than the verdict.

The near future sharpens this: bureau reporting cadences are tightening, score models keep revising, and composite underwriting keeps absorbing new data rails. Lenders whose credit-data layer is consent-clean, multi-bureau, cached, and versioned will absorb each change as configuration. The rest will keep paying for it in pull costs, in mispriced risk, and eventually in supervisory letters.

Ask most fintech teams what KYC requires, and they will describe a product flow: capture a document, run a face match, screen a name. Ask a regulator the same question, and they will describe customer due diligence, the legal framework from which every one of those product steps derives. The difference in framing is not academic. Institutions that understand CDD as the source obligation design controls that survive audits; institutions that understand only the product steps discover their gaps during inspections.

Customer due diligence is the process of knowing who your customer is, confirming that knowledge with reliable evidence, understanding who ultimately benefits from the relationship, and understanding what the relationship is for, calibrated to risk, and maintained for as long as the relationship lasts. This guide unpacks the framework under Indian law, its four components, its risk tiers, and what operationalising it actually looks like.

What Is Customer Due Diligence?

Customer due diligence (CDD) is the set of measures a regulated entity must take to identify its customer, verify that identity using reliable and independent sources, identify any beneficial owner, and understand the nature and purpose of the business relationship with the depth of those measures scaled to the money-laundering and terror-financing risk the customer presents.

Two clarifications position CDD correctly. First, KYC and CDD are often used interchangeably, but the cleaner mental model is that KYC is the operational programme and CDD is its legal substance: the RBI’s KYC Master Directions are, in essence, an instruction manual for performing CDD. Second, CDD is not an onboarding event. The obligation explicitly continues through the relationship; transactions must remain consistent with the institution’s understanding of the customer, and that understanding must stay current.

Globally, the framework descends from the FATF Recommendations (Recommendation 10 in particular); domestically, it is hard law under the Prevention of Money Laundering Act and its rules.

The Legal Basis: PMLA, Rule 9, and RBI KYC Directions

Three instruments anchor customer due diligence in India.

The AML Compliance Software India 2026 of “reporting entities” banks, NBFCs, payment providers, securities intermediaries, insurers, and designated businesses, including client verification, record maintenance, and reporting to FIU-IND.

Rule 9 of the PML (Maintenance of Records) Rules, 2005 is the operative CDD provision: it mandates identification and verification of every client at the commencement of an account-based relationship, identification of the beneficial owner, and understanding of the ownership and control structure for legal-entity clients. The 2023 amendments materially tightened this frame lowering beneficial-ownership thresholds and expanding covered entities; changes with ownership implications.

Sector regulators translate the rules into supervision. For RBI-regulated entities, the KYC Master Directions specify the acceptable documents (OVDs), the permitted verification modes Aadhaar, [video KYC]), the risk-categorisation duty, and periodic update cadences. SEBI and IRDAI mirror the structure for their sectors. Our [RBI KYC Master Directions guide] walks through the banking version in detail.

The layering matters practically: PMLA defines the offence-adjacent duties, Rule 9 defines the CDD substance, and the sectoral directions define the audit checklist your inspector carries.

The Four Components of Customer Due Diligence

Every CDD programme decomposes into four questions, each with its own evidence discipline.

1. Identification: Who Claims to Be Here?

Collecting the identity claim: name, date of birth, address, identifiers (PAN, Aadhaar reference, registration numbers for entities) through the application journey.

2. Verification: Is the Claim True?

Confirming the claim against reliable, independent sources: Aadhaar-anchored rails, OVDs verified at their issuing registries, and biometric binding of the person to the credential via [face match and liveness]. The verification rails this series has covered are all instruments of this component.

3. Beneficial Ownership: Who Is Actually Behind This?

For legal-entity customers, identifying the natural persons who ultimately own or control the entity, through the ownership thresholds and control tests, is required under the 2023 amendments. A company’s KYC is legally incomplete until its beneficial owners are identified and verified as individuals.

4. Purpose and Nature: What Is This Relationship For?

Understanding the intended use, expected transaction types, volumes, geographies, and counterparties. This component gets the least product attention and does the most monitoring work: “consistent with the declared purpose” is the baseline against which suspicious activity is defined.

The four components are conjunctive. A stack that verifies identity brilliantly but skips beneficial ownership, or never captures purpose, is performing partial CDD, which, in an inspection, is non-compliant CDD.

Risk Tiers: Simplified, Standard, and Enhanced Due Diligence

CDD is explicitly risk-based: the same depth for every customer is both wasteful and non-compliant, since the framework requires calibration.

Simplified due diligence applies to demonstrably low-risk customers and products small-value accounts, regulated-entity customers, and government bodies permitting lighter evidence within defined limits. Simplification is a documented risk decision, not an operational shortcut.

Standard CDD is the default: full identification, verification, beneficial ownership, and purpose measures.

Enhanced due diligence (EDD) applies where risk is elevated: politically exposed persons, high-risk jurisdictions, complex or opaque ownership structures, unusual purpose profiles, and non-face-to-face relationships as policy defines them. EDD means more source-of-funds and source-of-wealth inquiry, senior-management approval, tighter monitoring, and shorter review cycles. Our dedicated [EDD in banking analysis] cover the deep end.

The connective tissue is the institution’s risk-categorisation model: every customer carries a risk grade, the grade selects the CDD tier, and the tier drives evidence depth, approval level, and review frequency. The tiered architecture we outlined in [risk-based KYC] is this principle turned into system design.

Ongoing Due Diligence: CDD as a Lifecycle

The least-implemented word in the CDD framework is “ongoing.” Three duties continue after onboarding.

Transaction consistency monitoring. Activity must be checked against the understood profile of the purpose component earning its keep. A declared salary account moving trade-scale volumes is a monitoring alert precisely because CDD recorded what the account was for. This is the doctrinal basis of the [ongoing AML monitoring] programme.

Periodic KYC updates. Re-KYC at risk-scaled intervals: the RBI framework’s periodic-update regime refreshes identity evidence, contact data, and risk categorisation. Institutions running [KYC remediation programmes] are usually paying down debt accumulated by treating this duty as optional.

Event-driven refresh. Trigger events: ownership changes in entity customers, adverse media, unusual activity, dormancy reactivation warrant CDD refresh outside the calendar. Beneficial-ownership changes are the classic silent drift: the entity you onboarded is not the entity you are banking on three years later.

Operationalising CDD in Digital Journeys

Translating the framework into product reality turns on four design commitments.

Map controls to components. Every journey step should trace to a CDD component in your policy documentation: identification, verification, BO, or purpose. The mapping is what converts a slick onboarding flow into an auditable compliance programme.

Make purpose capture real. Replace the ignored dropdown with structured, product-appropriate purpose profiling that actually parameterises monitoring rules. If monitoring never reads it, purpose capture is theatre.

Automate the evidence bundle. Every verification rail in this series produces machine-readable evidence registry responses, match scores, liveness results, and consent artefacts. CDD-grade record-keeping (PMLA requires five-year retention beyond relationship end) should assemble these automatically per customer, uniformly across rails.

Grade risk with governed models. Risk categorisation deserves the same governance as credit policy: documented factors, periodic validation, and change control. It is the switchboard the entire tiered framework runs through and the first thing a thematic inspection tests.

Key Takeaways

• Customer due diligence is the legal substance of KYC: identification, verification, beneficial ownership, and purpose calibrated to risk and maintained through the relationship.
• The Indian frame is PMLA + Rule 9 + sectoral KYC directions, with the 2023 amendments tightening beneficial-ownership duties.
• The four components are conjunctive; skipping BO or purpose makes the whole CDD defective, however strong the identity verification.
• Simplified, standard, and enhanced tiers must flow from a governed risk-categorisation model calibration is itself a compliance duty.
• “Ongoing” is enforceable: transaction-consistency monitoring, periodic re-KYC, and event-driven refresh complete the lifecycle.

Frequently Asked Questions

Conclusion

Customer due diligence is where compliance stops being a checklist and becomes epistemology: what does the institution actually know about this customer, on what evidence, and is that knowledge still true? Every verification API, screening engine, and monitoring rule in the modern stack is, ultimately, machinery for answering those three questions defensibly.

The regulatory trajectory of tighter beneficial-ownership rules, richer verification rails, and DPDP-era evidence discipline keeps raising the standard for what “knowing your customer” means. Institutions that build CDD as an evidence-producing lifecycle, rather than an onboarding gate, will find that trajectory an advantage: their answer to the regulator’s three questions is already sitting in the audit bundle.