Lending & Credit

What this area actually covers

Lending is giving someone money now for a claim on their future income, and the systems split into three phases. Origination takes an applicant from enquiry to funded loan: capture, identity and income verification, a credit decision, an offer, an agreement, disbursement. Servicing runs the loan for its life — schedule, payment allocation, interest accrual, statements, part-payments, changes of terms. Collections handles loans that stop performing, through to recovery, write-off, or sale of the debt.

Two things get wrongly bundled in. Payments is one: a lender needs rails to disburse and collect, but clearing and settlement belong elsewhere. Fraud is the other — it asks whether this person is who they claim to be, where credit asks whether this person, genuinely themselves, will repay. Dressing a fraud decline up as a credit decline is also a regulatory problem, because what you owe the applicant differs.

Where it sits in a real business

Capital arrives from deposits, wholesale funding or securitisation, and it has a cost. The rate charged must also cover expected credit losses, operating cost, capital held against the exposure, and a margin; every system in the stack exists to make one of those five measurable.

The record of truth is a loan account with a principal balance, an accrual basis and a schedule. Each payment hits an allocation waterfall — conventionally fees, then accrued interest, then principal — and the order matters, because the same rupee applied differently moves both the customer's payoff date and the lender's revenue. The loan system is a subsidiary ledger that must reconcile to the general ledger.

Risk and finance then read the same portfolio differently: regulatory capital uses probability of default, loss given default and exposure at default under the Basel framework, while accounting uses expected credit loss provisioning, staged under IFRS 9 by whether credit risk has deteriorated significantly. Both sit downstream of your servicing system's delinquency data, so a bug in computing days past due becomes a misstated balance sheet.

Who does this work

Credit risk analysts build and monitor the scorecards: pulling bureau and application samples, binning variables, checking discrimination and stability, arguing about cut-offs. Many still build logistic-regression scorecards on weight-of-evidence-transformed features precisely because the resulting points table is explainable line by line.

Decisioning engineers build the runtime that takes an application, orchestrates bureau and verification calls inside a latency budget, executes policy rules, invokes models and returns a decision with reasons; the hard parts are timeouts, partial failures and versioning, not throughput. Servicing engineers own schedules, accrual and restructuring, where correctness compounds over years. Model validators sit outside the building team and try to break the model. Underwriters and collections strategists work the referred exceptions, and their feedback is the main signal that a policy is mis-tuned.

Demand, adoption and how that is changing

Demand is high, and the driver is distribution rather than banking growth. Credit is being embedded at the point of need — a checkout page, a seller dashboard, a dealer's tablet — so non-bank companies now need lending capability they never had, usually built against a licensed lender's API. Buy-now-pay-later made this visible at consumer scale on unusual economics: short tenor, often no interest to the shopper, revenue from the merchant, a decision in under a second on thin data. That created real demand for fast small-ticket decisioning and for servicing enormous numbers of tiny loans.

It also invited regulation, the second driver. Supervisors in several jurisdictions have moved to treat deferred-payment credit as credit rather than as a payment feature, pulling affordability assessment, bureau reporting, disclosure and dispute handling into products launched without them. India's digital lending rules show how architectural this gets: funds must move between the borrower and the regulated lender rather than through an intermediary's pool account. Underneath both drivers sits steady replacement work, because much lending still runs on cores written decades ago.

What makes it hard

The conceptual leap is that a credit policy and a scoring model are different objects and must stay different. A policy is deterministic rules encoding eligibility and appetite — minimum age, jurisdiction, no active bankruptcy, a debt-to-income ceiling, exposure limits — human-authored, individually justifiable, and hard declines. A model is a statistical ranking estimating probability of default; it produces a score, not a verdict, and the decision comes from applying a cut-off to that score inside the policy. Teams that collapse the two — training a model to predict "approved" rather than "defaulted", or expressing appetite as model features — lose the ability to change appetite without retraining, and lose the trail that says why this applicant was refused.

That trail constrains the technology directly. In the United States the Equal Credit Opportunity Act, implemented through Regulation B, requires that a refused applicant be given the specific principal reasons, and the Fair Credit Reporting Act adds duties when a credit report drove the decision; comparable obligations exist elsewhere, and the GDPR gives rights around solely automated decisions with significant effects. Three things follow. You cannot ship a model you cannot attribute, because each decline needs a short ordered set of reasons traceable to inputs, and a post-hoc explanation of a model is not automatically a legally adequate reason. You cannot silently retrain, because scheduled retraining or a mutable feature store destroys reproducibility; a decision must be replayable years later with its exact input vector, model version, policy version and bureau payload. And you cannot use features you cannot defend, since fair-lending exposure arises from disparate impact rather than intent, making a proxy for a protected characteristic a liability even when predictive. Independent validation and stability monitoring are release gates, not paperwork.

The third difficulty is time: a loan is a stateful object living for years while its terms change. Take 100,000 over 24 months at 12% nominal annual, compounded monthly at 1%:

Month	Instalment	Interest	Principal	Closing balance
1	4,707.35	1,000.00	3,707.35	96,292.65
2	4,707.35	962.93	3,744.42	92,548.23
3	4,707.35	925.48	3,781.87	88,766.36

Now perturb it. An extra 20,000 in month 7: shorten the tenor or cut the instalment, and does the customer choose? A payment nine days late: is a fee levied, and does it capitalise? A payment of 4,000, where your days-past-due logic must decide whether that is delinquent? Then a restructuring extends the tenor and capitalises arrears, rewriting every remaining row — and all of it must be reversible, because operational errors happen.

Delinquency is bucketed by days past due — current, 1–30, 31–60, 61–90, 90-plus — with the 90-day mark widely used as the definition of default and, in many regimes, the trigger for non-performing classification. Collections strategy is built on how accounts move between buckets, so roll rates and vintage curves rather than point-in-time totals are the real analytics.

Why study it

Learn this if you want systems where correctness has a definable cost and the constraints are interesting rather than arbitrary. Lending is one of the few domains where machine learning has been in high-stakes production for decades with a mature discipline around governing it, so if you care about responsible ML in practice rather than in principle, the practice already exists here. Skip it if you want fast product iteration, because a decisioning engine's release cadence is set by governance, or if you want to build unconstrained state-of-the-art models — the best model here is frequently not the most accurate one.

Your first hour

Build a loan in a spreadsheet or thirty lines of code, then break it. Take 100,000 over 24 months at 12% nominal annual. Compute the level instalment with P * r * (1+r)^n / ((1+r)^n - 1) where r is the monthly rate, generate the schedule, and confirm the closing balance in month 24 is zero to the last unit of currency — deciding where you absorb the rounding difference is your first real design decision. Then handle three cases: an extra 20,000 in month 7 with tenor held constant, a payment of 4,000 in month 9, and a fee of 500 in month 10 allocated ahead of interest. Finally write half a page: your allocation order, what counts as delinquent, and what you must store to reproduce any past statement exactly.

What this is not

It is not credit scoring. A bureau score is one purchased input to a decision that also weighs application data, income verification, existing exposure and policy; the lender's own model and cut-off matter more to the outcome, and the internals of commercial bureau scores are proprietary.

It is not payments and it is not accounting. You need working literacy in both, but the rails and the general ledger are other people's systems. Nor is it a pure machine learning role: most of the code is orchestration, long-horizon state management and evidence production, and if you join expecting to spend the week on model architecture you will spend it on reconciliation.

The duty to explain a refusal is not a compliance wrapper bolted onto a lending system; it is the constraint that decides what the system may be built out of.