Loan Origination Assistant

Unsecured personal-loan origination loses applicants at the form: abandonment is highest at document upload and income entry, and first-line agents spend most of their time chasing incomplete applications. This agent owns the front end of origination - it converses with the applicant, collects and validates the application, verifies documents, runs a soft eligibility pre-check and hands underwriting a complete package. An agent rather than a smarter form because the work is adaptive: which documents are needed, what counts as income, and what to ask next depend on the answers so far.

In scope:

• Application data capture: identity, contact, employment, income, liabilities, loan purpose and amount
• Soft eligibility pre-check against configurable product rules (age, income floor, DTI ceiling, geography)
• Document request, upload handling, classification and field extraction (ID, payslip, bank statement)
• KYC identity verification call-out and result handling
• Applicant-facing explanations of requirements, status and pre-check outcome
• Structured handoff package to underwriting with a completeness score

Out of scope:

• Credit decisioning, pricing and offer generation (underwriting agent, to be specified)
• Hard bureau pulls - triggered by underwriting after consent is recorded
• Disbursement, servicing, collections
• Secured products (mortgage, auto) - own subdomains

Trigger: applicant starts an application from web, app or assisted channel; or a loan officer opens a partially completed application.

1. Open - greet, state what the process involves, confirm consent to collect data and documents (recorded with timestamp and policy version).
2. Intent - loan amount, purpose, preferred tenure. Validate against product bounds; if out of bounds, explain and offer the nearest in-bounds option.
3. Identity & contact - collect; trigger kyc_identity_check. On failure, one retry with clarification, then route to human (gate A).
4. Employment & income - collect; determine required proof by employment type (salaried: payslips; self-employed: bank statements + ITR). Ask only for what the rules need.
5. Documents - request each; on upload call document_extraction; reconcile extracted fields against declared values. Discrepancy > tolerance -> ask once, then flag.
6. Liabilities - collect declared EMIs/cards; compute indicative DTI.
7. Soft pre-check - evaluate product_rules_lookup. Outcomes: likely-eligible, borderline, not-eligible. Explain outcome using only reasons the rules mark as disclosable.
8. Package - assemble application, compute completeness score, write to application_store, hand off (gate B: loan officer review for borderline / flagged).
9. Close - summary to applicant: what was submitted, what happens next, expected timeline.

The agent stops and asks a human at gates A and B, and whenever the applicant asks for a decision, a rate, or legal/tax advice.

• Never: state or imply a credit decision, rate or approval likelihood beyond the three disclosable pre-check outcomes; collect protected attributes not required by the product rules; proceed without recorded consent; accept a document it cannot classify.
• Approval gates: A - KYC failure after retry; B - borderline pre-check or any discrepancy flag before handoff. Both route to a loan officer with the trace attached.
• Data handling: PII handled in-session and written only to application_store; documents stored by reference, never in the agent's logs; extracted-field logs redact account numbers to last four. Compliant with fair-practice disclosure rules; explanation text comes from rule-attached templates, not free generation.

• Success criteria: application completeness at handoff >= 95% (vs form baseline); document-rejection rate at underwriting < 5%; zero disallowed statements (decision, rate, advice) across the eval set; median time-to-complete under 12 minutes.
• Eval set: evals/origination-conversations.jsonl - synthetic applicant personas x product rule variants x document quality tiers; includes adversarial turns asking for decisions and advice. Target 200 conversations before reviewed.
• L1-L5 levels: L1 tool-call correctness (right tool, valid args); L2 extraction and reconciliation accuracy against ground truth; L3 end-to-end task completion and guardrail adherence per conversation. L4/L5 (business outcome, drift) apply once prototyped.
• Failure modes tested: asking for unnecessary documents; accepting mismatched income; leaking a decision; continuing after KYC failure; losing state mid-upload.

• Short-term: full conversation state, extracted fields with provenance (declared vs extracted, confidence), rule-evaluation trace.
• Long-term: the application record only, in application_store, keyed by application id; retained per lender policy (default 7 years post-decision, as regulated records). No conversational memory is kept across applications; a returning applicant resumes from the stored record, not from chat history.
• Retrieval: product rules are fetched per run and pinned by version for the session; help content (document guides, FAQs) retrieved from a small curated corpus, refreshed daily.

• Document extraction quality on low-resolution phone photos is the likeliest demo failure.
• Which disclosure rules apply depends on jurisdiction; the product-rules schema needs a disclosable flag per rule and a jurisdiction field.
• Consent recording format must match the lender's existing audit trail.
• Open: should the assisted (loan-officer) channel share this agent or get a variant?

Not started. Built on registered interest. Planned demo: a single web chat against a synthetic product-rule set with three applicant personas, showing the package and completeness report at the end.