How to automate personal loan application intake
TLDR
Record when the lender actually received the request under its applicable procedures. Keep later submission, classification and completeness events separately.
Which receipt time belongs in the application record?
An assisted request precedes the completed web form. The form has the same case reference and a later timestamp. Retain the original receipt and record the later submission as its own event.
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 credit request arrives or actual creditor conduct changes its treatment, including oral, written, direct, referral or renewal requests.
Owner and accepted result. Application Operations. Record when the lender actually received the request under its applicable procedures. Keep later submission, classification and completeness events 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. An intake processor uses the web form's later submission time for a request already received by phone. Assistant pitfall. The agent omits an assisted request because it lacks a digital case ID.
Release check. Compare the saved original receipt event, channel, timestamp and request reference to the source phone/assisted/digital record; keep a provisional link when correlation is unresolved. A web resubmission follows an earlier assisted request. Preserve the earlier source receipt and route ambiguous case linkage to Application Operations before creating a duplicate.
Tasks and validation instructions
- Capture request and original receipt event
- Validate intake and source-specific permissions
- Update legal completeness and clock ledger
Capture request and original receipt event
Owner and trigger. Application operations specialist. An actual permitted referral-routing message or its owned receiving context selects intake. LO-07-T01 creates/upserts or links the receiving case once while preserving the original legal receipt. An already-created case/acknowledgment is not required before capture.
Read and preflight. Actual oral/written/assisted/digital request or source payload and available occurrence/receipt metadata. Case ID may be newly assigned or unresolved. An actual incoming request/change/creditor-conduct event or minimally attributed intake exception exists.
Implement and hand off. Canonical/provisional request record preserving actual received_at and original event, or an owned correlation/metadata exception. 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. Capture oral/assisted requests under actual creditor procedures. Do not replace real receipt time with later full web-form submission or owner-queue arrival. Review possible duplicates before creating another case.
Human pitfall. An intake processor uses the web form's later submission time for a request already received by phone.
Assistant pitfall. The agent omits an assisted request because it lacks a digital case ID.
Independent check. Compare the saved original receipt event, channel, timestamp and request reference to the source phone/assisted/digital record; keep a provisional link when correlation is unresolved.
Failure and recovery. A web resubmission follows an earlier assisted request. Preserve the earlier source receipt and route ambiguous case linkage to Application Operations before creating a duplicate. 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 “Capture request and
original receipt event”. Use only the
authorized input manifest for this
task. Actual
oral/written/assisted/digital request
or source payload and available
occurrence/receipt metadata. Case ID
may be newly assigned or unresolved.
Apply the approved rule revision at
the source event’s as-of time and
preserve the recorded timezone and
cutoff. Compare the saved original
receipt event, channel, timestamp and
request reference to the source
phone/assisted/digital record; keep a
provisional link when correlation is
unresolved. 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
operations specialist). Leave
unsupported values unknown. Apply this
recovery rule. A web resubmission
follows an earlier assisted request.
Preserve the earlier source receipt
and route ambiguous case linkage to
Application Operations before creating
a duplicate. Keep the decision and any
write within existing authority. Read
any original destination receipt
before repeating an effect.
Source context · Regulation B §1002.2 Definitions and official interpretations
Connected work · Route the referral and record routing state
Validate intake and source-specific permissions
Owner and trigger. Application operations specialist. The creditor may continue the contemplated evaluation with proper access/use permissions.
Read and preflight. Candidate request, actual known/unknown creditor/product/jurisdiction/channel fields, current requirement rules and any source/delivery/use basis records. An attributable request/field/permission candidate exists, including named missing values or unresolved program context.
Implement and hand off. Validated intake/permission findings, or precise missing/failed/unknown scope and permission states. No unknown permission authorizes a source request. 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. Do not use a generic checkbox as authority for every report/data source. Do not confuse legal completeness, internal readiness and lawful access. Hold unauthorized retrieval or request missing items.
Human pitfall. A processor uses a generic permission checkbox to request a specific report.
Assistant pitfall. The agent treats eligibility for the product as authorization to retrieve every source.
Independent check. Compare the applicant and request context to the effective creditor, product and jurisdiction rules and the distinct authority record for each requested source, purpose and delivery use.
Failure and recovery. Report permission is missing for one source. Hold that retrieval and record the precise authority gap while preserving the original intake. 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 intake and
source-specific permissions”. Use only
the authorized input manifest for this
task. Candidate request, actual
known/unknown
creditor/product/jurisdiction/channel
fields, current requirement rules and
any source/delivery/use basis records.
Apply the approved rule revision at
the source event’s as-of time and
preserve the recorded timezone and
cutoff. Compare the applicant and
request context to the effective
creditor, product and jurisdiction
rules and the distinct authority
record for each requested source,
purpose and delivery use. 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 operations specialist).
Leave unsupported values unknown.
Apply this recovery rule. Report
permission is missing for one source.
Hold that retrieval and record the
precise authority gap while preserving
the original intake. Keep the decision
and any write within existing
authority. Read any original
destination receipt before repeating
an effect.
Source context · Regulation B §1002.2 Definitions and official interpretations
Connected work · Obtain identity evidence
Update legal completeness and clock ledger
Owner and trigger. Application operations specialist with Compliance support. Original receipt, accepted normally required evidence, actual action/notice or relevant timer event.
Read and preflight. Use information normally required for a credit decision and the case state. An actual received/evidence/action/notice/due event and available original clock/requirement history exist. Missing metadata can be identified.
Implement and hand off. Versioned completeness/clock entries or named unresolved event/requirement exception. Original history remains immutable. 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. Completeness includes information normally obtained/considered, including applicable third-party evidence. A queue handoff does not restart clocks. Escalate uncertain prequalification or notice treatment.
Human pitfall. A processor resets the recorded receipt when the file changes queues.
Assistant pitfall. The agent marks the application complete from an internal readiness label while required third-party evidence is unavailable.
Independent check. Recompute completeness from the effective requirements and evidence states at the recorded event time; compare the saved ledger entry and original receipt to immutable history.
Failure and recovery. The required third-party evidence has no supported receipt. Keep completeness unresolved and send the discrepancy to Application Operations without rewriting the clock. 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 “Update legal
completeness and clock ledger”. Use
only the authorized input manifest for
this task. Use information normally
required for a credit decision and the
case state. Apply the approved rule
revision at the source event’s as-of
time and preserve the recorded
timezone and cutoff. Recompute
completeness from the effective
requirements and evidence states at
the recorded event time; compare the
saved ledger entry and original
receipt to immutable history. 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 operations specialist
with Compliance support). Leave
unsupported values unknown. Apply this
recovery rule. The required
third-party evidence has no supported
receipt. Keep completeness unresolved
and send the discrepancy to
Application Operations without
rewriting the clock. Keep the decision
and any write within existing
authority. Read any original
destination receipt before repeating
an effect.
Source context · Regulation B §1002.2 Definitions and official interpretations
Scheduling and safe replay
Run on each actual credit request, qualifying source event or attributed correction. Use the source receipt and the creditor's effective rule at that event time. Recompute affected completeness states and preserve original clock entries.
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-07-lab.sqlite \
--process LO-07
LO-07-current→verified.LO-07-rewritten-receipt→hold. Reasonmismatch:original_receipt_at. Sourceoriginal_receipt_atis"2026-11-05T14:00:00Z". The saved value is"2026-11-05T15:00:00Z".
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 loan application intake. 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
-
Regulation B §1002.2 Definitions and official interpretations · Consumer Financial Protection Bureau
-
Regulation B §1002.9 Notifications · Consumer Financial Protection Bureau
-
Regulation B §1002.12 Record retention · Consumer Financial Protection Bureau
