RBI Account Aggregator Explained for Fintech Developers

Account Aggregators (AAs) are the backbone of India's open banking ecosystem. Since the RBI officially launched the AA framework in 2021, billions of account links have been activated, enabling consented financial data sharing across banks, mutual fund houses, insurance companies, and tax systems. Yet for many developers building fintech products, the AA framework remains a black box.

This guide breaks down the AA ecosystem from a technical perspective: who the participants are, how consent flows work, what data formats you receive, and how to parse that data reliably in your AI agent using Lekha.

The Three Pillars: AA, FIP, and FIU

Every Account Aggregator transaction involves exactly three participants:

| Role | Full Name | Who They Are | | ------- | ------------------------------ | --------------------------------------------------------------- | | AA | Account Aggregator | The licensed consent manager (e.g., Setu, FinVu, PhonePe AA) | | FIP | Financial Information Provider | The institution holding the data (e.g., SBI, HDFC Bank, UTI MF) | | FIU | Financial Information User | Your application — the entity requesting data with user consent |

As a developer building a lending app, credit scoring tool, or wealth management product, your application is the FIU. You never touch the data directly from the bank — the AA manages all data movement under the user's explicit consent.

This separation is deliberate. It means your app cannot fetch financial data without the user's active approval, and users can revoke access at any time through their AA app.

How the Consent Flow Works Step by Step

Understanding consent mechanics is the most important technical concept in the AA ecosystem. Here is the end-to-end sequence:

1. FIU sends consent request → AA
AA notifies user via push notification
User approves/rejects in their AA app
AA sends signed consent artefact → FIU
FIU sends data fetch request (with consent artefact) → AA
AA fetches encrypted data → FIP
FIP returns encrypted Financial Information → AA
AA returns encrypted data → FIU
FIU decrypts data using session keys → processes document

From the user's perspective, this takes 30–90 seconds. From your code's perspective, you initiate an async workflow and poll or use webhooks for the consent status update.

// Pseudocode — actual implementation depends on your AA operator SDK
const consent = await aaClient.createConsent({
  purpose: {
    code: "101", // 101 = Loan underwriting
    text: "Verify income and bank balance for loan application",
  },
  fiTypes: ["DEPOSIT"],
  dateTimeRange: {
    from: "2026-04-01T00:00:00+05:30",
    to: "2026-09-30T23:59:59+05:30",
  },
  frequency: { unit: "MONTH", value: 1 },
  dataLife: { unit: "MONTH", value: 6 },
});
// Send consentHandle to user's registered mobile for approval
console.log("Consent handle:", consent.consentHandle);
// After user approves, fetch data
const fiData = await aaClient.fetchData({
  consentId: consent.consentId,
  sessionId: generateSessionId(),
  keyMaterial: generateDHKeyPair().publicKey,
});

Consent Parameters: The Regulatory Configuration

When your FIU creates a consent request, these parameters govern what data you can access and for how long:

purpose.code — RBI-mandated purpose codes. Common values:

101 — Loan underwriting

102 — Wealth management

103 — Financial planning

104 — Account aggregation / PFM

fiTypes — Types of Financial Information you're requesting:

DEPOSIT — Bank savings/current accounts

MUTUAL_FUNDS — CAS data from RTAs

TAX — ITR data from income tax portal

INSURANCE_POLICIES — Life and general insurance

EQUITIES — Demat account holdings

dateTimeRange — The historical period to fetch. Most lenders request 6–12 months for underwriting. dataLife — How long you are permitted to store the fetched data. RBI expects this to be the minimum necessary. frequency — How often you can re-fetch data under this consent (for recurring use cases like EMI monitoring).

What the Decrypted Data Looks Like

After decrypting the FI payload, you receive data in one of two formats depending on the FIP:

Format 1: Structured JSON (AA Standard)

Most major banks return structured transaction data conforming to the Account Aggregator Technical Standards Specification (ATSS):

{
  "account": {
    "maskedAccNumber": "XXXXXXXX1234",
    "linkedAccRef": "ref_abc123",
    "type": "SAVINGS",
    "ifscCode": "SBIN0001234"
  },
  "summary": {
    "currentBalance": 84320.5,
    "currency": "INR",
    "openingDate": "2019-03-15",
    "currentODLimit": 0,
    "balanceDateTime": "2026-09-30T23:59:59+05:30"
  },
  "transactions": [
    {
      "txnId": "TXN20260901001",
      "type": "CREDIT",
      "mode": "NEFT",
      "amount": 75000.0,
      "currentBalance": 84320.5,
      "transactionTimestamp": "2026-09-01T10:30:00+05:30",
      "valueDate": "2026-09-01",
      "narration": "NEFT/SALARY CREDIT/INFOSYS LTD",
      "reference": "NEFTREF001234"
    }
  ]
}

Format 2: PDF Attachment

Some FIPs — particularly regional cooperative banks, rural banks, and older PSBs — embed a PDF bank statement as a base64-encoded attachment inside the FI payload. Your code needs to handle this case explicitly.

function isPDFPayload(fiData: FIData): boolean {
  return fiData.format === "PDF" || fiData.mimeType === "application/pdf";
}

This is where Lekha becomes essential: it gives you the same structured JSON output whether your data came as a clean AA JSON or as a PDF attachment.

Building a Unified AA + PDF Pipeline with Lekha

The practical challenge for any production system is that users arrive with mixed data sources:

Some have banks fully enrolled in AA → you get clean structured JSON

Some have banks only partially enrolled → you get PDF attachments within AA payload

Some have accounts at non-AA banks (regional, cooperative) → they upload PDFs manually

Lekha lets you handle all three paths with a single normalized output:

import Lekha from "@lekha/sdk";
const lekha = new Lekha({ apiKey: process.env.LEKHA_API_KEY });
interface NormalizedStatement {
  source: "aa_structured" | "aa_pdf" | "uploaded_pdf";
  accountNumber: string;
  period: { from: string; to: string };
  balance: { opening: number; closing: number; currency: string };
  transactions: NormalizedTransaction[];
  salaryCredits: SalaryEntry[];
  monthlyAverageBalance: number;
}
async function processAAPayload(
  fiPayload: FIData,
): Promise {
  if (isPDFPayload(fiPayload)) {
    // Handle PDF embedded in AA response
    const pdfBuffer = Buffer.from(fiPayload.data, "base64");
    const result = await lekha.extract({
      document: pdfBuffer,
      documentType: "bank_statement",
    });
    return { source: "aa_pdf", ...result.data };
  }
// Handle structured JSON from AA
  return normalizeAAStructuredData(fiPayload);
}
async function processUploadedStatement(
  file: File,
): Promise {
  const result = await lekha.extract({
    document: file,
    documentType: "bank_statement",
  });
  return { source: "uploaded_pdf", ...result.data };
}
// Your loan underwriting agent uses the same interface regardless of source
async function runUnderwritingAgent(
  aaSources: FIData[],
  uploadedFiles: File[],
): Promise {
  const statements = await Promise.all([
    ...aaSources.map(processAAPayload),
    ...uploadedFiles.map(processUploadedStatement),
  ]);
// All statements normalized — merge and analyze
  const merged = mergeStatements(statements);
  return computeCreditScore(merged);
}

Try building this pipeline interactively at lekhadev.com/playground.

Choosing an Account Aggregator Operator

As an FIU, you integrate with one AA operator. Your choice affects developer experience and FIP coverage, but not the regulatory flow (all AAs follow the same AATSS standard):

| AA Operator | Strengths | Best For | | -------------------- | --------------------------------------------- | --------------------- | | Setu (Pine Labs) | Best developer docs, sandbox, fast onboarding | Startups, fintechs | | FinVu | Broadest FIP coverage, enterprise grade | NBFCs, larger lenders | | PhonePe AA | Consumer distribution, large user base | B2C apps | | CAMS Finserv | Deep MF/insurance FIP integrations | Wealth management | | Perfios AA | Embedded analytics layer | B2B underwriting | | OneMoney | Public sector bank integrations | PSB-heavy use cases |

Your FIU integration code stays largely the same regardless of operator since ATSS compliance is mandatory across all.

AA vs Direct PDF Upload: When to Use Which

| Scenario | Use AA | Use PDF Upload + Lekha | | ----------------------------------- | ------- | ---------------------- | | User's bank is on the AA network | ✓ | — | | Need real-time balance verification | ✓ | — | | Bank not yet on AA network | — | ✓ | | User needs > 12 months of history | Limited | ✓ | | Audit trail with original documents | — | ✓ | | Non-consenting user prefers upload | — | ✓ | | Rural cooperative bank accounts | — | ✓ |

The best production architecture supports both. AA is the happy path for speed and user experience; Lekha-powered PDF parsing is the fallback that covers the remaining 40% of Indian accounts not yet in the AA network.

Regulatory Compliance Checklist for FIUs

If you're building an AA-integrated product, ensure you've covered these RBI requirements:

[ ] Register as an FIU with your chosen AA operator

[ ] Implement consent artefact storage (minimum 5 years)

[ ] Enforce dataLife — purge data after the consent period expires

[ ] Use purpose codes approved for your use case (don't use 101 for PFM)

[ ] Implement data localisation (store financial data in India)

[ ] Provide a user-facing consent dashboard to view/revoke consents

[ ] Use encrypted storage for all fetched FI data at rest

[ ] Log all data access events for audit purposes

For document storage and DPDP compliance details, see our post on DPDP-compliant document extraction.

FAQ

What is an Account Aggregator in India? An Account Aggregator (AA) is an RBI-licensed NBFC that acts as a consent manager. It enables users to securely share their financial data from banks and financial institutions with third-party apps. Users retain full control — they can approve, limit, or revoke access at any time without needing to share passwords or credentials. Do I need an NBFC license to integrate with AA as an FIU? No. As an FIU, you only need to sign an API agreement with an AA operator and comply with their technical and regulatory onboarding requirements. This is significantly less burdensome than obtaining an NBFC license. The AA operator manages the RBI licensing on their side. Which banks are on the AA network in India? As of 2026, all major PSBs (SBI, Bank of Baroda, PNB, Canara Bank) and large private banks (HDFC, ICICI, Axis, Kotak, IDFC First) are FIP-enabled. However, many regional banks, urban cooperative banks, and newer small finance banks still have limited or no AA connectivity — making PDF fallback essential. How is AA different from screen scraping or net banking credential sharing? AA is fundamentally different: no credentials are ever shared with your app. The user authenticates directly with their bank through the AA's secure channel. AA data is cryptographically signed and encrypted end-to-end, making it tamper-proof and legally valid — unlike scraped data which has no audit trail and violates most banks' terms of service.

---

Start Building

Whether you're fetching data via AA or parsing uploaded PDFs, Lekha normalizes all Indian financial documents into consistent, agent-ready JSON — bank statements, CAS statements, ITRs, salary slips, balance sheets, and more.

Sign up free at lekhadev.com — no credit card required. Explore the full API reference at lekhadev.com/docs or test a live parse at lekhadev.com/playground.