Account Aggregator orchestration for regulated lenders
One API for every
Account Aggregator rail
Lender OS gives NBFCs and fintech lenders a single integration for consented financial data: consent lifecycle, borrower journey, FI acquisition, decryption and delivery — identical across every RBI-licensed Account Aggregator you contract.
curl https://api.sandbox.lenderos.in/v1/consents \
-H "Authorization: Bearer los_sk_test_..." \
-H "Idempotency-Key: 7f9c24e5-..." \
-d '{
"client_reference": "LOAN-APP-88213",
"customer": { "reference": "cust_9f2c1a", "mobile": "+919812345678" },
"template_ref": "tpl_personal_loan_12m",
"journey": { "return_url": "https://lender.example.com/aa/return" }
}'{
"type": "consent.activated",
"livemode": false,
"sequence": 3,
"data": {
"previous_state": "PENDING",
"object": {
"id": "con_01J8Y7QN4M5R",
"state": "ACTIVE",
"custody": { "decryption_performed_by": "LENDEROS" }
}
}
}What payment orchestrators are to payment gateways, Lender OS is to Account Aggregators.
The AA framework is powerful. Integrating it is not.
India’s Account Aggregator ecosystem gives lenders consented, bank-grade financial data. But each AA exposes its own API shapes, consent semantics, journey behaviour, error vocabulary and delivery model. Integrating one rail is weeks of work; every additional rail multiplies the surface — and your team ends up owning consent-state reconciliation, key custody, ReBIT decryption and purge obligations across all of them.
Lender OS absorbs the rails, so you integrate once.
The orchestrator presents one canonical model — consents, journeys, data sessions, events — and maps every rail into it behind per-AA connectors. Upstream quirks and error codes never leak into your code. You are the FIU throughout: your identity, your AA contracts, your keys, operated on your behalf under an auditable custody model.
How it works
Consent → data → delivery, on one state machine
Four calls and two webhooks take a loan file from “we need bank statements” to normalized FI data in your systems — with every step evidenced.
Your systems
one integration
Lender OS orchestrator
TSPone state machine, every rail
AA ecosystem
FIPs: banks holding the data
- 01
Create a consent
One POST with canonical consent parameters — or a saved template. Lender OS validates the terms, selects an AA rail from your contracted pool, and registers the consent. Routing is decided once, transparently, with typed reasons when no rail fits.
POST /consents → PENDING
- 02
Borrower approves
Mint a short-lived journey URL and redirect the borrower to their AA. The redirect back to you is a UX signal; the authoritative outcome arrives as a signed webhook once the rail confirms.
consent.activated → ACTIVE
- 03
Fetch within the terms
Open a data session under the active consent. Data range and fetch frequency are enforced in Lender OS code before any rail sees the request — out-of-bounds fetches fail fast with typed errors.
POST /data-sessions → session.data_ready
- 04
Pull normalized data
One authenticated pull endpoint returns a normalized envelope wrapping raw ReBIT FI JSON per account. Webhooks carry references, never financial data. Custody and purge are recorded and attested.
GET /data-sessions/{id}/data
Capabilities
Infrastructure-grade, from consent to purge
One API across AA rails
Consents, journeys, data sessions and webhooks behave identically on every RBI-licensed AA you contract. No AA-specific concept ever reaches your integration — switching or adding rails is configuration, not code.
Explicit consent state machine
PENDING → ACTIVE → PAUSED / REVOKED / EXPIRED, moved only by verified rail notifications and authoritative polls — never by the borrower’s redirect. Every transition is webhooked with a gapless per-entity sequence.
Signed webhooks
Every event is HMAC-SHA256 signed with a timestamped signature header, replay-protected, retried on a 24-hour backoff schedule, and deduplicable by event id. Financial data never rides in a webhook body.
Per-tenant key isolation
Your FIU identity and keys are yours. Decryption happens inside your tenant’s isolated key boundary, and every payload records who performed it — LENDEROS or RAIL — in an auditable custody trail.
Data-life enforcement
Every consent carries a data-life; every session carries a purge_due_at. Purge is executed and attested — after purge, the API returns the attestation, not a 404. Evidence outlives the data.
Consent-funnel analytics
Journey outcomes are normalized across rails — approved, rejected, abandoned, failed, with machine-readable reasons — so you can see exactly where borrowers drop and which rails convert.
Fail-fast serviceability
Borrowers the AA framework structurally cannot serve (joint-only accounts, NRE/NRO, no live FIP) surface as a typed CANNOT_SERVE outcome, not a mystery error — switch rails immediately instead of retrying.
Sandbox that behaves like production
A fully separate deployment with mock FI data and no AA contract required. Same API, same state machines, same webhooks. Going live is a credential change, never a code change.
Built for lenders
Made for RBI-regulated credit, not generic data plumbing
Every design decision assumes the file ends in a lending decision that must survive an audit: explicit consent terms, enforced data-life, evidence for every byte.
For engineering
- Stripe-grade API conventions: idempotency keys, cursor pagination, typed errors, additive versioning
- Webhook signatures you can verify in ten lines, with rotation that never drops events
- Raw ReBIT payloads — your parsers read the standard, not a proprietary transform
For credit & risk
- Bank-grade cash-flow data under explicit, purpose-bound consent
- Partial results delivered as results — underwrite on what arrived while failures carry typed reasons
- Normalized funnel outcomes to quantify and fix consent drop-off
For compliance & ops
- An evidence pack per consent: who consented, what was fetched, who decrypted, when it was purged
- Consent-term enforcement in code — frequency and range violations never leave your perimeter
- Purge attestation aligned to the consent’s data-life, exportable for audit
Put your AA integration on one rail-proof API
Tell us about your lending stack and AA plans. We’ll walk you through the orchestrator, the sandbox, and what onboarding looks like.