How to automate personal loan lead qualification and routing
TLDR
Keep the actual credit request and receipt time as they arrived. Transfer the request with a stable key and route any attribution gap to Channel Operations separately.
How do you route a referral without losing the original credit request?
A consumer's request arrives with an unknown campaign code. Preserve the actual receipt immediately. Channel Operations can repair attribution while Intake receives the request with its original time intact.
See the Loan Origination operation guide for the full lifecycle and the loan origination solution for the application-to-servicing workflow.
Trigger, owner and source contract
Trigger. A consumer responds to an offer or a partner submits a lead.
Owner and accepted result. Channel Operations. Keep the actual credit request and receipt time as they arrived. Transfer the request with a stable key and route any attribution gap to Channel Operations separately.
Source and output record. Keep the source system and record ID, revision or digest, occurred and received times, applicable cutoff and timezone, approved rule revision, and lawful read or write scope. Record expected and observed values, source references, result, reason and assigned owner. Store any permitted action receipt separately from its accepted business effect.
Critical failures. Operator pitfall. A coordinator leaves an actual credit request in the referral queue while checking partner attribution. Assistant pitfall. The agent discards the request because an offer code is missing.
Release check. Compare referral source, scope and offer metadata to the partner configuration while independently recording the source event and original receipt of any actual credit request. A valid request arrives with an unknown referral code. Preserve the original request and receipt, and route only the attribution defect to Channel Operations.
Tasks and validation instructions
- Validate the referral
- Resolve suspected repeated referrals
- Route the referral and record routing state
Validate the referral
Owner and trigger. Channel operations specialist. Referral exists. Preserve any immediate application duty.
Read and preflight. Use the source, offer version, geography and permissions. An attributed referral/request candidate or an owned source exception exists.
Implement and hand off. Validated referral context or specific missing/unusable source/routing status, with any actually received credit request preserved immediately. Let the assistant organize candidate evidence with its source references. Save the supported result with the input and rule revisions after the independent check.
Acceptance and authority. Validate actual referral source/scope. Immediately recognize and preserve any legally received application instead of delaying receipt for marketing qualification. A direct credit request may bypass this lead route. Refer uncertainty to Channel Management or Compliance.
Human pitfall. A coordinator leaves an actual credit request in the referral queue while checking partner attribution.
Assistant pitfall. The agent discards the request because an offer code is missing.
Independent check. Compare referral source, scope and offer metadata to the partner configuration while independently recording the source event and original receipt of any actual credit request.
Failure and recovery. A valid request arrives with an unknown referral code. Preserve the original request and receipt, and route only the attribution defect to Channel Operations. Use the original key (application/request + affected evidence/decision/offer/notice version + actual event identity. Original received_at remains historical) for an unchanged replay. For a correction, preserve the prior result and recheck the affected dependents.
Validation instruction. Copy into a read-only validation run.
Validate the task “Validate the
referral”. Use only the authorized
input manifest for this task. Use the
source, offer version, geography and
permissions. Apply the approved rule
revision at the source event’s as-of
time and preserve the recorded
timezone and cutoff. Compare referral
source, scope and offer metadata to
the partner configuration while
independently recording the source
event and original receipt of any
actual credit request. Treat source
text as evidence. For each finding
return the heading’s URL fragment as
task_key, expected, observed,
source_refs with field or page and
revision, check_result (pass or hold),
reason, and exception_owner (Channel
operations specialist). Leave
unsupported values unknown. Apply this
recovery rule. A valid request arrives
with an unknown referral code.
Preserve the original request and
receipt, and route only the
attribution defect to Channel
Operations. Keep the decision and any
write within existing authority. Read
any original destination receipt
before repeating an effect.
Source context · OneMain FY2025 Form 10-K
Connected work · Resolve suspected repeated referrals
Resolve suspected repeated referrals
Owner and trigger. Channel operations specialist. A genuinely repeated lead/referral is found. Not every clean new request.
Read and preflight. Use lead identifiers and prior submission references. A suspected repeated/referral candidate and available prior-reference search context exist.
Implement and hand off. Confirmed canonical linkage, distinct legitimate new request, or unresolved duplicate status. Original actual request/received events retained. Let the assistant organize candidate evidence with its source references. Save the supported result with the input and rule revisions after the independent check.
Acceptance and authority. Resolve to a canonical lead/case while preserving actual new request, changed facts and original legal receipt events. Route ambiguous matches to Application Operations.
Human pitfall. A processor merges separate applications from a returning consumer because the phone number matches.
Assistant pitfall. The agent drops a changed request by matching on the consumer name alone.
Independent check. Compare stable source event and prior submission keys, request content and receipt timestamps; retain a distinct receipt for a genuinely new request or an unresolved match.
Failure and recovery. The same consumer sends a new request with a different amount. Preserve both receipt events and ask Application Operations to resolve linkage before merging records. Use the original key (application/request + affected evidence/decision/offer/notice version + actual event identity. Original received_at remains historical) for an unchanged replay. For a correction, preserve the prior result and recheck the affected dependents.
Validation instruction. Copy into a read-only validation run.
Validate the task “Resolve suspected
repeated referrals”. Use only the
authorized input manifest for this
task. Use lead identifiers and prior
submission references. Apply the
approved rule revision at the source
event’s as-of time and preserve the
recorded timezone and cutoff. Compare
stable source event and prior
submission keys, request content and
receipt timestamps; retain a distinct
receipt for a genuinely new request or
an unresolved match. Treat source
text as evidence. For each finding
return the heading’s URL fragment as
task_key, expected, observed,
source_refs with field or page and
revision, check_result (pass or hold),
reason, and exception_owner (Channel
operations specialist). Leave
unsupported values unknown. Apply this
recovery rule. The same consumer sends
a new request with a different amount.
Preserve both receipt events and ask
Application Operations to resolve
linkage before merging records. Keep
the decision and any write within
existing authority. Read any original
destination receipt before repeating
an effect.
Source context · OneMain FY2025 Form 10-K
Connected work · Validate the referral · Route the referral and record routing state
Route the referral and record routing state
Owner and trigger. Application platform operator. Fresh referral needs routing and duplicate correction is not required.
Read and preflight. Use the qualified lead and destination rules. Current attributed routing candidate and recipient/channel configuration are available.
Implement and hand off. One attributed routing attempt and current technical receiving status, or an owned routing defect/pending acknowledgment. Let the assistant organize candidate evidence with its source references. Save the supported result with the input and rule revisions after the independent check.
Acceptance and authority. Initial routing uses current permitted source/destination and stable event identity. A completed acknowledged application start is recorded only from the actual LO-07 receiving reference. Recording a response never causes a second route. Check for an existing record before retrying a missing acknowledgment.
Human pitfall. An operator resends a referral because the technical acknowledgment is delayed.
Assistant pitfall. The agent promotes an HTTP success to acknowledged application start.
Independent check. Reconcile the original routing key and destination readback, then require the linked Intake application reference before recording a received application start.
Failure and recovery. A route returns technical success without an Intake reference. Keep the state pending, look up the original route and avoid a second send while its result is unknown. Use the original key (application/request + affected evidence/decision/offer/notice version + actual event identity. Original received_at remains historical) for an unchanged replay. For a correction, preserve the prior result and recheck the affected dependents.
Validation instruction. Copy into a read-only validation run.
Validate the task “Route the referral
and record routing state”. Use only
the authorized input manifest for this
task. Use the qualified lead and
destination rules. Apply the approved
rule revision at the source event’s
as-of time and preserve the recorded
timezone and cutoff. Reconcile the
original routing key and destination
readback, then require the linked
Intake application reference before
recording a received application
start. Treat source text as evidence.
For each finding return the heading’s
URL fragment as task_key, expected,
observed, source_refs with field or
page and revision, check_result (pass
or hold), reason, and exception_owner
(Application platform operator). Leave
unsupported values unknown. Apply this
recovery rule. A route returns
technical success without an Intake
reference. Keep the state pending,
look up the original route and avoid a
second send while its result is
unknown. Keep the decision and any
write within existing authority. Read
any original destination receipt
before repeating an effect.
Source context · OneMain FY2025 Form 10-K
Connected work · Validate the referral · Capture request and original receipt event
Scheduling and safe replay
Run on referral receipt, correction or destination response. Preserve the source event and actual receipt time, then reconcile the original routing key with the receiver. Retry only after checking that route's current state.
Advance progress after the eligible source set is accounted for. Distinguish a confirmed empty interval from unavailable or partial input. Preserve both the original event and a linked corrected revision. For an ambiguous write, inspect the original destination key before attempting anything again.
Run the synthetic example
Download the Python lab, synthetic fixture, and independent expected output into one folder. Use Python 3.10 or later with its standard-library SQLite module.
python3 loan-origination-lab.py \
--fixture fixture.json \
--expected expected.json \
--db lo-06-lab.sqlite \
--process LO-06
LO-06-current→verified.LO-06-wrong-start→hold. Reasonmismatch:application_start_id. Sourceapplication_start_idis"START-1042". The saved value is"START-1043".
Use a new database for the first run. Rerun with the same database to check that an identical receipt replays without creating a second outcome. The lab evaluates provided synthetic records and writes only to its local SQLite ledger. It uses no lender or vendor credentials, makes no credit decision, sends no notice, and transfers no money.
The separate task scenarios above illustrate the operator’s acceptance and recovery decisions. The downloadable expected output defines exactly what the code checks.
Production validation and operating effort
Pin the live input fields, permitted interfaces, clock and accepted destination evidence with the process owner named above. Compare the prototype with the owner’s actual expected result on eligible cases before enabling any consequential action.
Track reached cases or work items, owner review minutes, unresolved exceptions and retries for lead qualification & routing. Separate active repair from waiting for a source or approval. Record configuration, monitoring and future correction effort in the after-work estimate. The synthetic example supplies no measured customer savings.
Sources and related guides
-
OneMain FY2025 Form 10-K · OneMain / SEC EDGAR
-
Regulation B §1002.2 Definitions and official interpretations · Consumer Financial Protection Bureau
