Built for banks, NBFCs and fintech lenders in India
The operating system for
regulated lending
Lender OS runs the credit lifecycle end to end — origination, decisioning, servicing and collections — on one platform, built over consented financial data from 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" }
}
}
}Platform
Every stage of the loan, one system of record
Twelve modules that share one borrower record, one policy engine and one audit trail — use the full stack or start with the module that hurts most.
Acquire & originate
-
CRM
Lead capture to sanction — every borrower interaction in one pipeline.
-
Loan Origination
Configurable journeys from application to disbursal, with maker-checker control.
-
KYC
Identity and document verification with audit-ready trails.
Decide
-
Credit Decisioning
Policy-driven decisions your credit team can change without code.
-
Bureau Integrations
Pull and parse bureau reports inside the file, not in another tab.
-
Bank Statement Analysis
Cash-flow features from statements and AA data, normalized for underwriting.
Service & collect
-
Loan Management
Schedules, accruals, restructures and closures on a single ledger.
-
Collections
Bucketed queues, promise-to-pay tracking and field workflows.
-
Workflow Automation
Route files, approvals and exceptions by policy, not by email.
Data & build
-
Consented bank data across every RBI-licensed AA — one API, one consent journey.
-
Analytics & Reporting
Portfolio, funnel and team dashboards, with exports your auditors will accept.
-
APIs
Every module is API-first — build Lender OS into your stack, not around it.
At the platform’s core, the AA Orchestrator: what payment orchestrators are to payment gateways, it 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.
Inside the AA Orchestrator
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
From consent to purge, engineered end to end
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. The audit trail survives 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
- The API conventions you’d expect: 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
One platform from first consent to final collection
Tell us about your lending stack. We’ll walk you through the platform, the AA sandbox, and what onboarding looks like.