Lending decision infrastructure, and the engineers who own it

The four layers

A digital lending stack reads cleanly as four layers, and briefs that do not distinguish them produce the wrong shortlist.

Data acquisition. Credit bureau pulls from CIBIL, Experian, Equifax and CRIF High Mark; bank statement data via the account aggregator framework or statement parsing; GST and ITR data for business lending; device, telemetry and behavioural signals; employment and payroll verification. Each source has a different latency, a different failure mode and a different consent basis.

Decision. A policy engine evaluating hard rules (eligibility, exclusions, regulatory caps) and soft scores (a model output, a bureau score, a bespoke scorecard) to produce an approve, decline or refer outcome, plus the terms: amount, tenure, rate.

Disbursal and servicing. Loan account creation on a loan management system, disbursal through a payment rail, the repayment schedule, EMI presentation through NACH or UPI AutoPay, foreclosure, part-payment and restructuring.

Collections. Delinquency bucketing, allocation to channels, field and tele-collections tooling, settlement and write-off, plus the conduct obligations that now sit over all of it.

The engineering skill sets in these four layers overlap less than hiring managers expect. An engineer who has built a high-throughput bureau integration layer has probably never built a collections allocation engine, and the two roles interview very differently.

What the 2025 Directions changed for engineering

The RBI (Digital Lending) Directions, 2025, notified on 8 May 2025, consolidated the June 2020 circular on loans sourced over digital platforms, the September 2022 digital lending guidelines and the June 2023 default loss guarantee guidelines. Most of it reads as compliance, but several provisions land directly on architecture.

The point to carry into a brief is that compliance here is implemented in code, not in policy documents. An engineering leader who treats the Directions as somebody else's problem will build a stack that cannot evidence what it did.

The account aggregator rail

The account aggregator framework has become the default consented route to bank data for Indian lenders, and it has changed the shape of the data acquisition layer.

The architecture is deliberately intermediated. A Financial Information User requests data; the account aggregator, a licensed NBFC-AA, manages consent; the Financial Information Provider releases the data; the AA never sees the payload, because it is encrypted end to end. Consent is granular, time-bound and revocable, and the consent artefact itself has to be stored and producible.

The scale is now meaningful rather than pilot-stage. Following the RBI's recognition of Sahamati as the self-regulatory organisation for the ecosystem on 5 June 2026, the published figures were over 450 million consent requests fulfilled, more than 294 million linked accounts, 176 Financial Information Providers, 1,020 Financial Information Users, 17 operational account aggregators and over 290 million monthly data shares.

What that means for engineering:

Consent is state, with a lifecycle. Requested, granted, active, paused, revoked, expired. A lending system that treats consent as a boolean captured at onboarding will eventually process data it no longer has the right to process.

Data arrives asynchronously and sometimes not at all. FIP availability varies. A decision flow that blocks on an AA fetch will have a visibly worse conversion rate than one that degrades to an alternative path, and designing that fallback without weakening the credit decision is a real design problem.

The purpose limitation is enforceable. Data fetched for an underwriting purpose cannot quietly be reused for marketing or for a different product. Enforcing that in the data platform, rather than in a policy, is what separates a defensible architecture.

Statement parsing has not gone away. Most lenders run both paths. Maintaining a parser estate across dozens of bank formats while migrating volume to AA is a common and underestimated workload.

Policy versioning and decision reproducibility

This is the part of the stack that separates engineers who have done it from engineers who have read about it.

A credit decision is a function of several independently changing inputs: the policy rules in force at that moment, the model version and its weights, the data snapshot as it stood when read, the configuration of thresholds and cut-offs, and the identity of whoever approved any override. Each of these changes on its own schedule. Policy changes weekly in a fast-moving lender; models are retrained quarterly; cut-offs move with portfolio performance.

Six months later, a regulator or an internal auditor asks why a specific application was declined. The only acceptable answer is a full replay: these rules, this model, this data, this outcome. Systems that cannot do this end up reconstructing decisions by inference, which is both unconvincing and sometimes wrong.

The patterns that work:

Immutable policy versions with explicit activation windows. Policies are published, not edited. Every decision record carries the policy version identifier.

Snapshot the inputs, not just the references. Storing "bureau score 712" is not enough if the question is what the full bureau report said. Storing a pointer to a bureau record that has since been refreshed is worse than useless.

Model registry with lineage. Which model, which training data, which features, which validation results, who approved deployment and when. This is the evidence base when the Chief Risk Officer is asked how they satisfied themselves a model was fit for use.

Deterministic replay as a tested capability. A replay harness that can be run on demand, and is run, rather than a theoretical ability nobody has exercised.

Shadow and champion-challenger evaluation. Running a candidate policy alongside production without acting on it, and comparing. Lenders that cannot do this change policy on intuition.

The failure mode is specific and recognisable: a lender six months into rapid growth discovers that policy lives partly in a rules engine, partly in application code, partly in a configuration table edited by hand, and partly in a notebook a data scientist runs weekly. At that point nobody can state what the credit policy actually is, which is a governance problem before it is an engineering one.

Where lending stacks break

Bureau integration under load. Bureau APIs are slower and less reliable than application engineers expect, and pulls cost money per hit. Caching strategy, retry behaviour, and what to do when the bureau is down are decisions with direct revenue and risk consequences. A naive implementation either declines good applicants during a bureau outage or spends heavily on duplicate pulls.

Idempotency on disbursal. The single most expensive class of bug in lending. A retried disbursal that double-pays is money gone, and the recovery is manual. This is the same discipline described in ledger architecture, applied to the most consequential write in the system.

The loan management system boundary. Most Indian lenders run a third-party LMS. The integration boundary between the decision stack and the LMS is where state diverges: the decision system believes a loan is disbursed, the LMS has it pending, and the customer sees something else again. This is a reconciliation problem that nobody owns until it becomes one.

Co-lending arithmetic. Under a co-lending arrangement the book is split between partners, usually 80:20, with separate accounting, separate reporting and separately computed collections allocation. Getting the split right at origination is simple. Keeping it right through part-payments, foreclosures, restructures and write-offs is where systems fail, and the errors surface as partner disputes rather than as alerts.

Collections data quality. Allocation engines are only as good as the delinquency data beneath them, and the delinquency data is derived from repayment posting, which is derived from reconciliation. A collections team chasing customers who have already paid is a reconciliation failure presenting as a conduct problem, and the conduct problem is the one the regulator sees.

NACH and mandate lifecycle. Mandate registration, amendment, cancellation and presentation failures each have their own codes and their own remediation path. This is unglamorous work that tends to be assigned to a junior engineer and then becomes load-bearing.

Who owns this, and who to hire

Two hiring notes that matter more than the table.

Regulated lending experience is not interchangeable with fintech experience. An engineer from a payments company is closer to a lending company than one from e-commerce, but the credit-specific obligations are genuinely new to them. Budget for the learning curve or hire against it explicitly.

The strongest candidates are usually inside the eight or ten companies that have done this at scale. They are employed, they are not applying, and they are approached rather than advertised to. This is the market reality behind every lending platform search we run, and it is why these mandates are built from a named map rather than a pipeline. Our approach is described in how we search.

How to assess

Ask for a decision replay. "An auditor asks why application X was declined in March. Walk me through exactly how you answer." Candidates who have lived it describe policy versions and snapshots. Candidates who have not describe looking in the logs.

Ask about a disbursal incident. Double disbursal, failed disbursal with a debited customer, disbursal to a stale account. What happened, how it was detected, how long it took, what changed. This question is diagnostic because everyone who has run a lending stack at volume has one.

Probe the policy boundary. "Where does credit policy live in your system, and who can change it without an engineer?" The answer reveals the architecture and the governance in one go.

Test the partner failure case. "Your bureau provider is down for four hours during business hours. What happens?" Strong answers weigh conversion against risk explicitly and mention who makes the call. Weak answers say the system retries.