The situation
The client is a Series C consumer lender doing installment loans in the $1,000–$15,000 range, underwritten against a mix of credit bureau data, bank transaction history, and a proprietary risk model their data science team had built in-house. By the time they called us, their underwriting team was reviewing roughly 340 applications a day by hand, and application volume had grown 40% year over year while the underwriting headcount plan had grown 12%. The gap was being absorbed as overtime and, increasingly, as slower decision times, which mattered commercially, because in this segment, a borrower who doesn't get a decision within about ten minutes frequently goes and applies somewhere else.
Roughly 70% of applications, by the client's own estimate, were "clean": inside every normal risk parameter, no red flags, no manual judgment really required. The other 30% needed a human because something about the application sat outside the model's confident range: thin credit history, a recent address change, inconsistent income documentation, or a risk score close enough to the approval threshold that a reviewer wanted to look at the supporting detail.
Why off-the-shelf didn't fit
The client had already evaluated two underwriting-automation vendors before talking to us. Both were built around replacing the underwriting decision itself, using a black-box model that would approve or deny in place of a human, with the lender's own risk team relegated to occasional model audits. Legal and compliance killed both evaluations for the same reason: under the applicable state lending regulations, an adverse action (a denial) requires a specific, documentable reason a human can stand behind, and neither vendor's model produced anything more explainable than a score. Replacing the decision wasn't something the client's counsel was going to sign off on, no matter how good the model's accuracy numbers looked in a sales deck.
That reframed the actual problem for us: this was never really a "replace the underwriter" project. It was a "get the clean 70% off a human's desk, and hand the other 30% to a reviewer with better information than they currently have" project. That's a meaningfully smaller and more tractable scope, and it's the one we quoted against.
Scoping the real workflow
The scope call ran long, closer to two hours, because we needed the underwriting team's actual decision logic, not the policy manual's version of it. We sat with two senior underwriters and asked them to narrate their reasoning on a batch of twenty real (anonymized) applications, including several they'd approved that technically had a flag, and a few they'd denied that technically scored fine. That exercise surfaced the real decision boundary: underwriters were weighting income stability and the reason behind a thin file (student vs. recent immigrant vs. genuinely high-risk) more heavily than the internal risk score alone suggested, and the existing risk model wasn't capturing that nuance.
We came out of scoping with three concrete deliverables to build against: an automated approval path for applications meeting a specific, written confidence threshold; a structured triage summary for every application that didn't qualify for auto-approval, written in the same shorthand underwriters already used in their notes; and a full audit log tying every automated decision to the specific policy criteria it satisfied, so compliance could reconstruct the reasoning behind any individual approval on demand.
What we built
The agent sits between the loan application intake system and the existing loan origination system (LOS), reading each application alongside the pulled credit and bank transaction data. For applications that clear a conservative, client-approved confidence threshold, deliberately set tighter than the underwriting team's own comfort zone at launch, it auto-approves and pushes the decision straight into the LOS with the full documentation trail attached. Everything else gets a structured triage note: a one-paragraph summary of the application in underwriter shorthand, the specific factors that kept it out of auto-approval, and a suggested priority ranking, so reviewers see the trickiest or most time-sensitive files first instead of working the queue in the order it arrived.
Every automated approval is logged with the specific underwriting policy clauses it satisfied, the input data considered, and a plain-language rationale, built specifically so the compliance team could hand it to a state examiner without translation. This was, honestly, the part of the build that took the most iteration, because "explainable enough to satisfy underwriters" and "explainable enough to satisfy a compliance examiner" turned out to be two different bars, and we had to clear both.
Where it got hard
The threshold-setting exercise was harder than expected. Set the auto-approval confidence bar too loose, and the agent would have approved applications the underwriting team's own manual review would have flagged, which is unacceptable. Set it too tight, and the automation barely moved the needle on review volume. We ended up running the agent in shadow mode for eight business days before go-live: it made a determination on every incoming application, but a human still reviewed all of them, and we compared the agent's recommendation against the underwriter's actual decision on each one. That shadow period is what let the client's risk team sign off on a threshold with real data behind it rather than a guess, and it added about a week to the original timeline, the one adjustment we made to the initial schedule, flagged to the client the day we proposed it.
The bank transaction data was the other hard part. The client used a data aggregator whose transaction categorization was inconsistent enough (a recurring paycheck sometimes tagged as "transfer," sometimes as "payroll," depending on the originating bank) that our first pass at income-stability logic mis-flagged a noticeable share of otherwise-clean gig-economy applicants. We ended up building a normalization layer specific to that aggregator's quirks, informed directly by the underwriters pointing out the pattern during shadow-mode review.
Rollout & results
The agent went live in week five, immediately handling roughly 55% of incoming volume via auto-approval, below the client's internal estimate of 70%, deliberately, because the confidence threshold was set conservatively at launch with a plan to loosen it gradually as real-world accuracy data accumulated. Three months post-launch, auto-approval rate had climbed to 63% as the threshold was adjusted twice, each time backed by a fresh accuracy review the client's own risk team ran independently of us. Manual review queue volume dropped 61% from its pre-launch baseline, and average decision time on auto-approved applications fell from roughly six minutes to under ninety seconds.
"The compliance sign-off was the thing I was most nervous about walking in, and it ended up being the smoothest part of the rollout, because the audit trail was built to answer the examiner's question before they asked it." VP of Risk & Compliance, client engagement
What we'd do differently
We'd build the shadow-mode comparison tooling earlier in the process next time. We built it reactively once we realized threshold-setting needed real data, rather than planning for it from day one. On a fixed-scope engagement, that kind of tooling is easy to underestimate because it doesn't feel like "the agent", being scaffolding around the agent, but for any workflow with a real regulatory or risk threshold to calibrate, we now build the shadow-mode harness as a first-week deliverable by default.