Design an instant loan approval pipeline

An application spends most of its time waiting: for vendors (bureau p99 can be several seconds), for the user (OTPs, AA consent, e-sign), and for callbacks. A synchronous request chain would time out and lose progress. Use a durable workflow engine like Temporal: the workflow code describes steps, and the engine persists every step result, so a crash resumes from the last completed step without repeating it. That last part matters because bureau pulls and eKYC calls cost money and some leave a footprint (a hard inquiry on the credit report). Each activity has its own timeout and retry policy: retry network errors with exponential backoff, but never retry a 'no record found' or a business rejection. Wait for user actions with signals plus timers ('if no AA consent in 30 minutes, decide without AA or send a reminder'). Order steps by cost: run free and fast checks (eligibility, device, negative list) before paid ones, and stop early on hard rejects. Put each vendor behind an adapter with a circuit breaker and a fallback vendor where possible (two bureaus, two KYC providers). If you do not want Temporal, a Postgres step table with a worker pool and a scheduler is a valid answer at this scale; the key ideas are persisted progress and idempotent steps.

Use layers. First, policy rules that lenders and regulators require: minimum age, serviceable pin codes, bureau score cut-offs, no recent write-offs, maximum debt-to-income. These are hard rejects and must be readable by risk teams, so keep them in a rules engine with versioned rule sets, not in code. Second, an ML model (often gradient-boosted trees, because they are accurate on tabular data and explainable with SHAP values) predicts probability of default from features. Third, pricing and limit rules map the risk band to an offer: amount, tenure options and interest rate. Every decision writes an immutable record: the feature vector, model version, rule set version, score, reason codes and offer. This gives reproducibility (re-run the same model on the same features and get the same answer), adverse-action reasons for rejected users, and audit support. Roll out new models in shadow mode first (score but do not act), then champion-challenger on a small traffic slice, and watch approval rate and early delinquency. Feature consistency matters: compute features with the same code online and offline, and store point-in-time snapshots so training does not use data that was not available at decision time (leakage).

Instant loans attract organised fraud: stolen identities, synthetic identities, and 'first-party' fraud where the borrower never intends to pay. Most fraud is caught by signals around the application, not the bureau score. Device intelligence: emulator or rooted device, one device used by many applicants, SIM recently changed. Identity: face match between selfie and KYC photo, liveness, name match across PAN, bank account (penny drop) and KYC. Graph signals: shared phone numbers, addresses, devices or bank accounts across applications; a graph store or simple linked-entity tables with counts catch fraud rings. Behaviour: typing patterns, time spent on the form, and applying from a location far from the KYC address. Velocity: many applications in a short time from the same IP range or pin code. Score fraud separately from credit risk, run it before paid bureau pulls where possible, and send borderline cases to manual review with all evidence on one screen. Feed outcomes back: loans that default in the first EMI (first payment default) are the best fraud labels, and they arrive 30-60 days later, so the training pipeline must handle delayed labels.

In India, RBI's digital lending guidelines shape the architecture. Disbursal and repayment must flow directly between the regulated lender's account and the borrower's bank account, not through the app's pool account, so the app calls the lender's LMS to disburse rather than moving money itself. The borrower must get a Key Fact Statement with the all-in annual percentage rate before signing, and a cooling-off period to exit without penalty, so the KFS generator and an 'exit' workflow branch are part of the system. Data collection needs explicit, purpose-specific consent, and apps should not access contacts or media for lending, so consent ids are stored with every data pull and the feature builder must not use unconsented data. Data must be stored in India. The Account Aggregator framework itself is consent-based: the AA never sees decrypted data, and the consent has a purpose, a date range and an expiry. In the interview, keep this short: name these constraints and show where they appear in the design. That shows you can build regulated systems, which fintech interviewers care about a lot.

A synchronous 'apply and wait' API is simple but breaks when any step takes more than a few seconds or needs user action. An async workflow with a status endpoint and push notifications handles minutes-long flows, app restarts and partner delays. The cost is more moving parts and a UI that must show progress states.

Reusing a report pulled in the last few days saves cost and avoids extra hard inquiries. A fresh pull catches new loans taken in between, which is a known fraud pattern (loan stacking). Common policy: reuse within a short window for the same product, pull fresh before disbursal for large amounts.

Bureau scores are a good start but generic. In-house models using platform data (transaction history, repayment behaviour) are much better for your users, but need data science, monitoring and governance. Start with bureau score plus rules, add your own model once you have enough repayment outcomes.

At 10x applications, bureau and KYC vendors throttle first. Queue applications at the vendor's allowed rate with per-vendor token buckets, show 'checking your details' in the app, and spread load across two vendors. Pre-approved users (scored in batch overnight from existing data) can skip parts of the flow.

If rules send too many cases to review, the queue grows and decisions take days. Track referral rate as a metric, tune thresholds, and prioritise the queue by expected value (larger, likely-good loans first).

The circuit breaker opens; the workflow waits and retries with backoff, or uses the fallback bureau. Applications are not rejected for a vendor outage; users are told the decision will come shortly by notification.

The loan stays in DISBURSING. The workflow queries the lender for status with the same idempotency key; it never sends a second disbursal request with a new key. Daily reconciliation against the lender's disbursal file closes the gap.

Monitor approval rate, score distribution and feature drift in real time; a sudden jump triggers an automatic rollback to the previous model version, which is just a config change because models are versioned and the decision service loads by version.