The Situation
Industry
Financial Services: Consumer Lending
Function
Loan Funding Operations
Team Size
Auto loans · Personal installment · Secured products
Deployment
5 agents · 50-day calibration
How Loan Funding Actually Works
A consumer loan application moves through several stages between approval and disbursement. Each stage has a defined purpose, and each carries its own sources of variation and exception.
Stage
What happens
Where complexity enters
Intake triage
Eligibility check
Collateral and VIN validation
Document review
Decision and funding
The Trigger
The internal data had flagged something the team had read as good news: 83% of loan applications were completing in under 10 minutes. The interpretation, at the time, was that the team was efficient.
When Scout observed the actual work, the interpretation shifted. Those 83% were completing quickly because they were structurally simpler cases: complete data, consistent documents, no eligibility exceptions. They were completing in under 10 minutes because experienced analysts recognised them at a glance and moved through them without friction.
The question the operations director asked after seeing those findings was the one that reframed the program:
“If 83% of our cases are structurally simple and take under 10 minutes, why are agents handling them the same way they handle everything else?”
The answer was that the system had no way to identify those cases at intake. They entered the queue as undifferentiated applications. Agents and analysts processed them in the same order as everything else, with the same manual steps, regardless of their complexity.
What the Funding Team Found
Four weeks of Scout observation across the funding team produced a picture of execution that the LOS utilisation reports had consistently missed.
Finding
What it meant for operations
34 application switches per analyst per hour
Analysts were moving between the loan processing system and other tools 34 times every hour. These transitions appeared in no process documentation and were invisible to the LOS utilisation reports leadership reviewed monthly. Each switch represented a data transfer or a decision step that the system was not performing.
Four execution paths, three documented
The LOS defined three workflow states. Scout observed a fourth: applications requiring a dealer network eligibility check via an external directory, using a dealer network ID that existed in no other system. Every analyst who encountered this case type handled it manually, with no documented routing rule. An agent built from the LOS documentation would encounter this case and have no instruction for it.
VIN validation by manual copy-paste
Vehicle identification required querying an external bureau and transferring the result into the LOS by hand. No integration existed. The step consumed time on every auto loan application and created error risk on each transfer. The LOS had no record of the bureau query at all.
Funding decisions in free-text comments
Hold reasons, conflict flags, escalation triggers, and compliance notes were all recorded as unstructured text in a comments field. The instruction in the SOP was: “Update the comments for the decision taken.” An agent cannot parse that field. An agent cannot write to it reliably. Every downstream routing decision depended on a human reading a note someone else had written.
Charge structures varied without a consistent schema
Fee itemisation differed by dealer and by loan type, with no enforced consistency in how charges were recorded. Cases with non-standard charge structures required analyst interpretation before they could proceed. The criteria for what was standard were embedded in team knowledge, not in any system definition.
“Scout gave us a level of visibility into our own operation that we simply didn’t have before. We could finally see which cases needed judgment and which ones didn’t, and route them accordingly from the moment they entered the queue. That’s what made straight-through processing possible at the scale we achieved.”
VP, Loan Operations
What Changed
The team made two structural changes before deploying agents. Both were about giving agents what they needed to act on the workflow reliably, rather than routing around the gaps manually.
Identifying which cases agents could handle, at intake
An agent readiness scorecard was defined based on three signals observed in the workflow data: data completeness (all required fields present), data consistency (no conflicts between bureau data and submission data), and document presence (loan agreement, bank statements, insurance certificate, title documents all confirmed).
Cases scoring above the threshold route directly to straight-through processing. Cases below route to a human queue with a pre-populated gap summary identifying the specific missing or conflicting element, rather than a generic incomplete flag. For the first time, the system could tell agents and analysts apart at intake, by the nature of the work itself.
Turning decision logic into something agents could act on
The free-text comment field was the single biggest barrier to agent execution in the workflow. A comment taxonomy was defined based on the actual hold and escalation patterns observed in the data: MISSING_INSURANCE, COLLATERAL_CONFLICT, NETWORK_ISSUE, VIN_MISMATCH. These structured codes were implemented alongside the existing free-text field.
This change meant that for the first time, the system could detect the reason for a hold programmatically. Escalation routing, intervention triggers, and compliance flags all became agent-executable. The structured comment field was what made the routing agent possible.
The Five Agents
Five agents were deployed across the funding workflow, each grounded in the observed digital work sequences and designed to operate on the actual execution patterns the team used, rather than the documented workflow states.
Agent
What it does in funding operations terms
Loan variant classifier
Agent readiness scorer
VIN verification agent
Document completeness checker
Escalation routing agent
A 50-day calibration phase ran alongside deployment. The confidence threshold for straight-through processing was set from real acceptance and rejection data, not from assumptions about case complexity. The 83% figure that had initially read as an efficiency metric became the operational baseline for the STP routing rule.
The Impact
The funding operation now routes the majority of its volume through straight-through processing before it reaches the analyst queue. Staff focus on the cases that genuinely require judgment: the eligibility edge cases, the collateral conflicts, the applications where documentation is ambiguous.
1,890h
Annual capacity identified across four use cases, representing 62% of total observed operational effort
83%
Of loan applications now route to straight-through processing at intake
51%
Of the total capacity impact comes from straight-through processing alone
Why This Matters
Consumer lending operations carry a particular kind of operational risk: high volume, tight timelines, and a regulatory environment where documentation gaps and routing errors are expensive. The cost of a missed eligibility check, a misfiled document, or a hold reason that failed to reach the right person is measured in compliance exposure and customer experience, not just processing time.
The agents that succeeded here were built from observed execution, from four weeks of watching how experienced analysts actually moved through the workflow, rather than from the three documented workflow states the LOS defined. The fourth execution path, the manual VIN transfers, the free-text decisions: all of it was visible only through observation.
The 83% that looked like efficiency was actually latent capacity. Finding it required looking at the work directly.
