- Soroco Tops Everest Group’s PEAK Matrix® Assessment - Four Years in a Row
Customer Stories
Ecosystem
Work Graph
Financial Services: Consumer Lending Operations
A Consumer Lender Found 1,890 Hours of Annual Agent Capacity by Observing How Their Funding Team Actually Worked
The Situation
Consumer loan funding is a high-volume, deadline-sensitive operation. When a borrower is approved for a loan, the funding team takes over: verifying that the application is complete, the collateral is valid, the dealer or merchant is eligible, and the documentation is in order before funds are released. Every day, a queue of applications arrives. Every application has to move through a defined sequence of checks before it can fund.
This lender funded auto loans, personal installment products, and secured consumer credit. The funding team worked in a loan origination system that was three years old, widely adopted, and by every dashboard metric, performing adequately. Throughput was steady. The team was experienced. Leadership considered the operation well-run.
They had begun exploring automation. Some pilots had run. Progress was slower than expected. The question the operations director eventually brought to the table was direct: why were agents not moving faster through a process that looked, on paper, straightforward?
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 | Receive and assess the incoming application | Applications arrive with varying levels of completeness. A missing field, an inconsistent data point, or an absent document creates downstream rework if it reaches the queue. Triage quality determines how much friction the rest of the workflow carries. |
| Eligibility check | Confirm the dealer or merchant is active and eligible in the network | Dealer eligibility is maintained in a separate directory. For some loan types, the analyst must verify eligibility via a manual lookup before the application can proceed. This step is undocumented for certain loan categories and handled by experienced staff from memory. |
| Collateral and VIN validation | Verify the vehicle or asset details against bureau data | VIN validation requires querying an external bureau and manually transferring the result into the loan processing system. No integration exists between the bureau and the LOS. Each validation is a manual copy-paste event. |
| Document review | Confirm that required documents are present and consistent | Required documents vary by loan type, dealer, and collateral. A document missing at this stage sends the application back to the queue with a rework flag. The criteria for completeness are embedded in analyst knowledge, not in the system. |
| Decision and funding | Record the funding decision and release the application | Funding decisions, holds, and escalations are recorded as free-text comments in the LOS. The reason for a hold, the nature of a conflict, the action required: all captured in unstructured notes that vary by analyst. Nothing in the system can read or act on them programmatically. |
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 | Identifies which of the four execution paths applies to an incoming application based on loan type, dealer type, and collateral category. The fourth path, the dealer eligibility check that was previously handled manually and invisibly, is now an explicit routing rule. Every application receives the correct execution path before processing begins. |
| Agent readiness scorer | Evaluates each application at intake against the three readiness criteria: data completeness, data consistency, and document presence. Cases above the threshold route to straight-through processing. Cases below route to a human queue with the specific gap identified, rather than a generic incomplete flag. |
| VIN verification agent | Queries the external bureau and transfers the validated vehicle identification data into the loan processing system automatically. Replaces the manual copy-paste step on every applicable auto loan. The bureau query, which previously left no record in the LOS, is now a logged, structured step in the funding workflow. |
| Document completeness checker | Validates that all required documents are present before an application enters the funding queue. Applied at intake, based on the document requirements observed across loan type and dealer combinations. Cases missing required documents are flagged and held before they reach the analyst queue, eliminating the rework loop that occurred when gaps were discovered mid-process. |
| Escalation routing agent | Uses the structured comment taxonomy to detect hold reasons, route escalations, and trigger interventions programmatically. The agent that was previously impossible to build because decisions lived in free text now operates reliably on structured decision signals. Routing errors dropped within six weeks of the comment taxonomy going live. |
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
Routing errors dropped significantly within six weeks of the comment taxonomy going live
The measurement itself was a product of the observation: before Scout, routing errors were undetectable because decisions were recorded in free text. The structured taxonomy made them visible and correctable.
The fourth execution path is now a documented, managed workflow
The dealer eligibility check that every experienced analyst handled manually and invisibly is now an explicit routing rule. New staff encounter it on day one with the same instructions as any other case type.
VIN validation is now a structured agent step
The bureau query is logged, the transfer is automated, and the error risk on each case is removed.
Institutional knowledge has been codified
The charge structure criteria, the document completeness rules, the dealer eligibility logic: all of it now exists in the agent system rather than in the accumulated memory of experienced staff.
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.
See Scout in action.
Schedule your demo now!
