AI System Design Case Study: AI-Assisted Loan Origination

When every loan file is read by hand, most of an underwriter's day goes on typing numbers out of PDFs, and judgement gets the scraps. An underwriter is the person who studies a loan application and decides whether to lend, how much and on what terms. This AI system design case study fixes that split without letting the AI decide.

Picture a common setup. A non-bank lender in Pune lends Rs 3 lakh (300,000) to Rs 25 lakh to small businesses such as workshops, shops and small factories. It is an NBFC, a non-banking financial company, regulated by the Reserve Bank of India (RBI). The setup is made up, but the problem is real.

The lender gets about 1,500 applications a month, and six underwriters check them (made-up numbers). Take one file. The owner of an auto-parts shop asks for Rs 8 lakh to buy stock before the festival season and uploads 23 files.

The files include 12 monthly bank statements, a tax return and GST returns. GST returns are Goods and Services Tax filings, which show the shop's sales. There are also KYC (Know Your Customer) documents, which prove who the owner is.

An underwriter spends about 2 hours typing numbers into a spreadsheet: money in each month, bounced payments and existing EMIs. An EMI (equated monthly instalment) is the fixed amount a borrower repays each month. Next comes the 60-page credit policy, to see which rules apply. Only the last 30 minutes go on real judgement: is this business healthy, and can it repay?

The credit head, who leads the underwriters, has 400 files waiting and a festival rush coming. The request to the team's architect is simple: let software do the reading and typing. One condition comes with it: the AI does not decide who gets a loan; the underwriters do. This guide walks through that design in the order you would present it in an interview.

You need seven words for the rest of this guide. Each gets a plain meaning and an example from the running case.

Loan origination. Loan origination is everything from the moment someone applies for a loan until the money is paid out or the application is closed. Example: the shop's file moving from upload, to checks, to the underwriter's decision, to the loan agreement.

Model. In this guide the model is a large language model, or LLM: a program that reads text and writes text back. It is good with messy layouts and plain wording, and it can still get numbers wrong.

Extraction. Extraction means pulling exact facts out of a document into a fixed format your code can use. Example: reading the shop's March bank statement and producing a record that says March credits were Rs 6,20,000, as a number, not as text in a PDF.

Retrieval. Retrieval means searching a library of text and returning the few passages that matter for a question. Example: finding section 6.1 of the credit policy, the rule about bounced payments. When retrieved text is handed to the model to help it answer, engineers call it RAG, short for retrieval-augmented generation.

Risk summary. A risk summary is a short report for the underwriter: the key facts, which policy rules pass or fail, and what looks unusual. Lenders also call it a credit note or credit appraisal memo, and call the underwriter a credit officer.

Guardrail. A guardrail is a check in your code that stops the AI from doing something it should not, whatever the prompt says. Example: the loan system refuses any decision that does not come from a person with credit authority.

Audit trail. An audit trail is a record of every step, input and decision, kept so nobody can quietly change it later. Example: a year from now, a reviewer can see exactly which documents, policy version and summary the underwriter had in front of them.

You start an AI system design case study by writing down the requirements and the decisions the AI must never make. Only then do you draw boxes, because a neat diagram for the wrong problem is worth nothing.

The architect's first meeting with the credit head and an underwriter turns the request into requirements. Functional requirements say what the system must do:

• Accept the documents a small business uploads, such as bank statements, GST returns and tax returns.
• Extract key numbers into a fixed format and check them for mistakes.
• Test the numbers against the credit policy and flag any rule that fails.
• Draft a risk summary for the underwriter, with a source for every claim.
• Let the underwriter approve, reject or ask for more documents, with a written reason.
• Keep an audit trail of every step.

Non-functional requirements say how well it must work. Using made-up numbers, the team writes these down. The system handles 1,500 files a month, and up to 3,000 in the festival season. A summary is ready within 15 minutes of the last upload. Model costs stay under Rs 50 per file.

Two more come from outside the team. Applicant data must be stored in India, because the RBI's rules for digital lending say so; the engineer section covers the exact rule. And if the model service is down, the system keeps working, just with less help.

Then comes the most important line: the AI never makes the credit decision. It reads, checks and explains. A person decides, because a wrong decision can hurt a family business, and someone must explain and own it. This rule shapes everything after it: the model gets no action that changes a loan, and the summary carries no verdict.

An AI loan origination system is a pipeline of small, separate steps. It stores documents, extracts facts, checks rules, finds policy, drafts a summary and hands it to a person who decides. Every step writes to an audit log.

The team picks a workflow, not an agent. In a workflow, your code fixes the order of the steps. In an agent, the model chooses its own next step. Underwriters can list their steps in advance, and a wrong step is costly, so a fixed workflow is easier to test and explain.

Follow the shop's documents from the portal to the loan system in the diagram below. Notice two things: the AI works inside only two boxes, and the only arrow into the loan system comes from a person.

The job queue, a waiting line of jobs, is there for the festival rush: files wait their turn instead of overloading the workers. The policy library keeps every version of every policy section, so you can always tell which rules applied to which file.

The table below is the heart of the design: code does anything that must be exact, the model reads and writes, and people judge.

Each box has its own deeper guide, such as RAG Chunking Strategies for splitting the policy into searchable pieces. Here you only need what each box does and why.

The system reads documents in two stages. The model turns each statement into a fixed set of fields, then plain code checks those fields before anyone trusts them.

First, the system sorts the 23 files by type. KYC proofs go to the lender's existing identity checks, and the credit bureau report arrives as structured data, so the model reads neither. Scanned pages first go through OCR (optical character recognition), software that turns a page image into text, or to a model that can read page images. Next, the model reads each bank statement and fills in a record for every month: opening balance, credits (money in), debits (money out), EMIs paid, closing balance and bounced payments.

A fixed list of fields like this is called a schema. Some model services can be told to reply only in JSON, a plain-text format for structured data, that matches a schema. That fixes the shape of the reply, not the truth of the numbers. Models can misread digits, so code checks every record.

Here is that check, with made-up data and a deliberate misread so you can run it. Amounts are whole paise (100 paise make one rupee), so every sum is exact. Python lets you put underscores between digits, so 6_20_000_00 is 62,000,000 paise, or Rs 6,20,000.

from operator import lt  # lt(a, b) means "a is less than b"


def check_statement(months, gst_turnover):
    # All amounts are whole paise, so every sum is exact.
    problems = []
    for m in months:
        if m["opening"] + m["credits"] - m["debits"] != m["closing"]:
            problems.append(f"{m['month']}: balances do not add up")
    for prev, cur in zip(months, months[1:]):
        if cur["opening"] != prev["closing"]:
            problems.append(f"{cur['month']}: opening is not last closing")
    if len({m["month"] for m in months}) != 12:
        problems.append("need 12 different months")
    credits = sum(m["credits"] for m in months)
    if lt(credits * 10, gst_turnover * 6):  # credits below 60% of GST turnover
        problems.append("bank credits far below GST turnover")
    return problems


def make_months():
    # 12 made-up months: Rs 6,20,000 in and Rs 6,10,000 out each month
    names = ["2025-04", "2025-05", "2025-06", "2025-07", "2025-08", "2025-09",
             "2025-10", "2025-11", "2025-12", "2026-01", "2026-02", "2026-03"]
    months, balance = [], 2_00_000_00
    for name in names:
        m = {"month": name, "opening": balance,
             "credits": 6_20_000_00, "debits": 6_10_000_00}
        m["closing"] = balance + m["credits"] - m["debits"]
        balance = m["closing"]
        months.append(m)
    return months


gst = 82_00_000_00  # Rs 82 lakh of GST turnover, in paise
months = make_months()
print(check_statement(months, gst))
months[5]["closing"] += 9_000_00  # the model misreads one digit
print(check_statement(months, gst))

Run it with Python 3.6 or later and it prints two lines. The first is an empty list, [], because all 12 months add up. The second is ['2025-09: balances do not add up', '2025-10: opening is not last closing'].

What just happened? One misread digit made September's closing balance Rs 9,000 too high. September's own sum broke, and October's opening no longer matched. That is no accident: changing any one amount breaks its own month's sum. In 20,000 random single-digit misreads of the opening, credits, debits or closing, the check caught every one (our test).

Know its limits. If the model gets credits and debits wrong by the same amount in one month, the errors cancel and nothing is flagged. The check also never looks at the bounce count or EMIs, or confirms that the 12 month labels are the latest ones. Those fields need their own test, such as making the model quote the transaction lines so code can count them.

The last check compares two documents. If GST returns show far more sales than the money that reached the bank, someone should ask why. Cash sales or a second bank account can explain it, so the 60% line (made up) only raises a question. Here the shop passes: Rs 74.4 lakh of credits against Rs 82 lakh of turnover, about 91%.

Any problem sends the file to a person, who fixes the numbers from the page. The fixes go into the audit trail.

The AI drafts the risk summary from checked facts and the exact policy sections that apply, and every sentence must point to its source. Numbers and rule results come from code. The model only explains them in plain words.

The credit policy has rules like these two, both made up for this guide. Rule 4.2: all monthly EMIs, including the new loan, must stay below 40% of average monthly bank credits. Rule 6.1: more than 3 bounced payments in any 6 months needs a written explanation from the owner.

The rule engine, plain code that tests each rule, does the maths. Average monthly credits are Rs 6.2 lakh, and existing EMIs are Rs 45,000. At a made-up 18% a year over 3 years, the new Rs 8 lakh loan adds an EMI of Rs 28,922. The usual EMI formula gives that: P times r times (1 + r) to the power n, divided by (1 + r) to the power n, minus 1.

In that formula, P is the loan, r is the monthly rate (0.015) and n is the number of months (36). Total EMIs come to about Rs 73,900, or 11.9% of credits, so Rule 4.2 passes. But March shows 4 bounced payments, so Rule 6.1 is flagged.

Then retrieval finds the policy sections behind each flag, here section 6.1. Only these few sections go to the model, not all 60 pages, so it has less chance to quote a rule that does not apply. In the diagram, look at the two checks after the model writes: they decide what the underwriter sees.

Pause and predict: the draft says "3 bounced payments in March", but the checked record says 4. Which check catches it, and what does the underwriter see?

The citation check, which is plain code. Each line must name a source, such as an extracted field or a policy section. The code confirms the source exists and that every number in the line matches it. This line names the March record, 3 does not match 4, so the line is removed.

If many lines fail, the draft is redone. After two bad drafts, if the model service is down, or if the credit head turns the AI off with one setting, the underwriter gets the facts-only view. It shows the checked numbers and rule results, with a note that the summary is missing. The system gets slower, not wrong.

The wording check looks for a verdict like "approve" or "low-risk borrower" and sends the draft back. The reason is automation bias: the habit of accepting a computer's suggestion without checking it. NIST, the US standards agency, lists the related automation complacency among human biases in its report SP 1270. The RBI's 2026 draft on model risk names automation bias too. A summary that already says "approve" makes it too easy for a busy underwriter to click yes.

Here is part of the summary that reached the underwriter: "Four bounced payments in March 2026 (bank statement, March, page 3), above the limit in policy section 6.1. Section 6.1 allows the file to continue with a written explanation from the owner." A suggested question follows: what caused the March bounces?

You keep a human in charge by making the decision a step only a person can perform. The loan system's code enforces this, not a prompt. The AI holds no tool or permission that can change a loan.

A prompt that says "never approve loans" is only guidance, and hidden text in a document can work against it. A permission check in code cannot be talked out of its job. This is least privilege: each part gets only the access its job needs. OWASP's prompt injection guidance recommends the same, plus human approval for privileged actions.

Here is the function the loan system runs to record a decision, with made-up people and files so you can run it. The worker account stands for the AI workers; a service account is a login used by software rather than a person.

from operator import gt  # gt(a, b) means "a is greater than b"
from types import SimpleNamespace as Obj

audit_log = []
LIMIT = 15_00_000  # Rs 15 lakh

def record_decision(app, user, decision, reason):
    if user.role not in ("underwriter", "credit_head"):
        raise PermissionError("only a person with credit authority can decide")
    if decision not in ("approve", "reject", "ask_for_more"):
        raise ValueError("unknown decision")
    if not reason.strip():
        raise ValueError("write the reason in your own words")
    if decision == "approve" and gt(app.amount_rupees, LIMIT):
        if user.role != "credit_head" or app.recommended_by in (None, user.id):
            raise PermissionError("above Rs 15 lakh: needs a recommendation and a different credit head")
    audit_log.append({"app": app.id, "actor": user.id, "decision": decision,
                      "reason": reason, "summary": app.summary_id,
                      "policy": app.policy_version})
    app.status = decision


worker = Obj(id="svc-summary", role="service")
uw = Obj(id="UW-07", role="underwriter")
head = Obj(id="CH-01", role="credit_head")
small = Obj(id="APP-0001", amount_rupees=8_00_000, recommended_by=None,
            summary_id="SUM-0001", policy_version="P-12", status="open")
big = Obj(id="APP-0002", amount_rupees=20_00_000, recommended_by="UW-07",
          summary_id="SUM-0002", policy_version="P-12", status="open")

for app, user in [(small, worker), (small, uw), (big, uw), (big, head)]:
    try:
        record_decision(app, user, "approve", "Bounces explained by a late payer")
        print(app.id, user.id, "status:", app.status)
    except PermissionError as e:
        print(app.id, user.id, "refused:", e)
print("audit entries:", len(audit_log))

Run it and you get five lines. APP-0001 svc-summary is refused, because a service account has no credit role. APP-0001 UW-07 is approved, because an underwriter may approve Rs 8 lakh. APP-0002 UW-07 is refused, because Rs 20 lakh needs the credit head.

APP-0002 CH-01 is approved, because an underwriter recommended it and a different person approved it. The last line reads audit entries: 2, one for each decision that went through. A recommendation step, not shown, fills in recommended_by.

Notice the scope. The second-person rule covers approvals above Rs 15 lakh only: an underwriter can still reject a large loan, and exactly Rs 15 lakh needs one person (our edge-case test). A blank reason is refused, because that reason later becomes the explanation for the applicant.

One more detail matters in production. Write the audit entry and the status change in one database transaction, a group of writes that succeed or fail together. Then one cannot happen without the other. In the flow below, notice that the size check lives in code, so nobody forgets it on a busy day.

Back to the shop. The underwriter phones the owner about the March bounces. A large customer paid late, so 4 supplier payments bounced, and the owner shares the receipts. The underwriter approves Rs 8 lakh with the reason "March bounces explained by a late customer payment."

Look back at the checks so far: untrusted document text, number checks, citation and wording checks, and this permission check. Each layer catches what another might miss, the idea in LLM Guardrails as Layered Defense. Approval screens and escalation get their own guide: Human-in-the-Loop AI.

Tie every decision to written reasons and sources, keep sensitive details away from the model and test outcomes across groups, and log every step where nobody can edit it. Those three habits make lending explainable, fair and auditable.

What goes into the audit trail

The audit log is append-only: new entries can be added, but old ones cannot be changed or deleted. Each file gets these entries.

• A fingerprint (a hash) of every uploaded document, to prove later that no file was swapped.
• The extraction record, the checks that ran, and any corrections a person made.
• The model version, prompt version and policy version that were used.
• The policy sections the search returned, and the full summary the underwriter saw.
• Who decided, what they decided, when, and the reason they wrote.

With this, the credit head can answer the hardest question a reviewer can ask: what exactly did the underwriter know when they made this decision?

Think of it as a kirana shop's account book. Each page entry is a log entry, writing only on the next blank line is append-only, and turning back the pages is replaying a file's history. Where the picture breaks: a shopkeeper can tear out a page.

A log needs a technical lock instead. Common choices are database permissions that allow inserts but not updates, write-once storage, or a hash chain, where each entry stores the hash of the one before. A chain alone is not enough: someone who edits an entry can recompute every later hash.

So copy the latest hash somewhere the database admins cannot write, such as a separate account or a daily signed report. Now an edit no longer matches the outside copy (our test).

How the system explains decisions

Explainability means a person can understand why a decision was made. The design has two layers. The summary explains the facts, since every line points to a page or policy section. The decision is explained by the underwriter's own reason and a reason code, such as "income too low for the amount asked".

If an applicant is turned down, they get those reasons in plain language and a way to ask for a review. Because a person decided, a person can explain.

How to check for unfair bias

Bias here means the system treats similar applicants differently because of who they are, not how their business is doing. NIST's 2022 report on AI bias says biases are endemic across technology processes and can cause harm regardless of intent. The lender uses three checks:

• Keep sensitive details out. The model never sees gender, religion, caste or photos, and the owner's name becomes "the owner" in prompts, because names can hint at gender or community.
• Run swap tests. Before each release, the team reruns test files with only the owner's name, area or similar details changed, and checks that the flags and summary stay the same.
• Review outcomes. Each month, the credit team compares flag rates and approval rates across groups, such as women-owned businesses and different districts. The credit team holds these details separately, only for this review. A big gap is investigated, even if no rule was broken.

Researchers have catalogued many definitions of fairness, so there is no single test to pass. The team picks the measures it will track, writes them down and reviews them with the compliance team.

As of 19 October 2026, the RBI has no final rulebook just for AI in lending. The guidance comes from a 2025 committee report, a 2026 draft on model risk and the RBI's existing lending directions. This section is a design summary, not legal or financial advice.

What the FREE-AI committee recommends

On 13 August 2025, the RBI released the report of its FREE-AI committee, short for Framework for Responsible and Ethical Enablement of Artificial Intelligence. It makes 26 recommendations, many of them for regulated entities: the banks, NBFCs and other firms the RBI oversees. Its principles say final authority should rest with humans, who should be able to override AI.

The parts that touch this design are specific. Lenders should have a board-approved AI policy that sorts AI uses into low, medium or high risk. The report gives credit underwriting as an example of a high-risk use.

Decisions should be explainable enough to show that no discrimination, direct or indirect, occurs. Customers should be told when they deal with AI, and be able to challenge and seek clarification on AI decisions.

On credit, the report notes that the RBI's digital lending guidelines already require creditworthiness assessments to be auditable. It says this can apply to AI credit assessments, so they do not work as a black box and stay under human oversight. It also calls for AI incident reporting.

What the 2026 draft on model risk adds

On 24 June 2026, the RBI released a draft called Guidance on Regulatory Principles for Model Risk Management, with comments due by 24 July 2026. It covers all models that regulated entities use, including third-party models and AI and machine learning models. NBFCs are on its list.

Model risk is the risk of harm from a model that was built wrongly, is misused or misread, or has drifted out of date. For AI models, the draft asks for human-in-command arrangements, where a person stays in charge. It also wants ways to override, suspend or switch off a model, including a kill switch, a quick way to stop it.

It also asks humans to review model outputs from time to time, and says oversight should consider automation bias and over-reliance on outputs. As of 19 October 2026, the RBI still lists it among draft guidelines, so treat it as a direction, not a rule.

This design already covers the draft's human-oversight asks in paragraphs 60 and 61. A person decides every file, the credit head's switch to the facts-only view is the kill switch, and the monthly outcome review is the periodic human check. The rest of the draft still needs its own plan, such as independent validation, the lender's own check of every model, even when a supplier has tested it.

The data rule that changes your architecture

The RBI's Credit Facilities Directions for NBFCs, dated 28 November 2025 and updated on 15 July 2026, include the digital lending rules in Chapter III. For digital lending, paragraph 14(4) says all data must be stored only on servers located in India. This team assumes its online portal is in scope and confirms that with compliance.

The same paragraph adds a twist. If data is processed outside India, it must be deleted from the foreign servers and brought back within 24 hours of processing. So before a single statement page goes to a model service, find out where that service runs and what it keeps.

The design handles this in three places. The document store and audit log sit in India. The model service runs in India, or the team gets written confirmation that it deletes every copy held abroad, logs included, within 24 hours of processing. The audit log records which model endpoint, the address the request went to, processed each file.

Outside India, the NIST AI Risk Management Framework, released on 26 January 2023 for voluntary use, groups similar work into four functions: govern, map, measure and manage. As of 19 October 2026, NIST's page says version 1.0 is being revised.

Test it on past files with known correct answers, and watch quality and cost signals in production. Keep the cost per file well below the underwriter time it saves.

The team builds a golden set: a fixed collection of test cases with checked answers. Here it is 300 past files (a made-up number), with the right figures and flags recorded by underwriters. Every change to a prompt, model or policy runs against it first.

Each run measures how many extracted fields are exactly right, how many summary lines have a correct source, and how many real flags were caught. Missing the shop's March bounces would be a serious miss. The swap tests must still pass. In the release gate below, notice the arrow back to the golden set: every hard case from production becomes a new test.

In production, the team practises observability: being able to see from outside what the system is doing and why. These are the signals it watches:

• Time from last upload to summary ready, against the 15-minute target.
• Model cost per file, against the Rs 50 limit.
• How often underwriters correct an extracted number.
• How often underwriters disagree with a flag, or find a risk the summary missed.
• How often underwriters approve without opening a single source page, an early sign of automation bias.

Now the cost, using made-up numbers. Model calls for one file cost about Rs 35. A small, cheap model sorts pages, a mid-sized model extracts, and a larger model writes only the short summary. If your provider supports prompt caching (reusing the processed start of a prompt), put the fixed instructions and output format first, and each file's facts and policy sections after them.

Underwriters used to spend 2 hours reading and typing per file. If the system saves 90 of those minutes, 1,500 files a month free up 2,250 underwriter hours (1,500 times 90 minutes, divided by 60). Against that, Rs 35 a file is small. Deeper methods are in LLM Evaluation Metrics and Test Frameworks and LLM Observability.

Tell it as one story in a clear order: requirements, scale, high-level design, two deep dives, the human decision, trust and compliance, then testing and cost. Spend most of your time where the risk is, not on drawing boxes.

1. 1

   Clarify the problem

   Ask who uses it and what a wrong decision costs. State that the AI prepares and a person decides.

2. 2

   Put numbers on it

   1,500 files a month, 15 minutes to a summary, under Rs 50 per file, data stored in India. Call them assumptions to confirm.

3. 3

   Draw the pipeline

   Portal, store, queue, extraction, rules and policy search, summary, underwriter desk, loan system, audit log.

4. 4

   Go deep on two parts

   Extraction with a schema and code checks; a summary where every line cites a source and there is no verdict.

5. 5

   Lock the decision in code

   Permission check, a different second approver for large loans, a written reason every time.

6. 6

   Cover trust

   Audit trail, explainable reasons, bias checks, where data is stored and processed, and current regulator directions with compliance.

7. 7

   Close with testing and cost

   Golden set, release gate, live signals, and cost per file against time saved.