How to automate personal loan income and employment verification
TLDR
Send income values that Verification can trace to the applicant, source period and approved basis. Treat gross earnings and net deposits as separate measures.
Which income figures can be sent to Credit?
A pay statement shows gross earnings, while a bank credit appears to be its net deposit. They may describe the same paycheck. Keep both sources and hold the overlapping component until Verification confirms its ownership, period and basis.
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. The actual policy/product/law selects financial evidence, an approved alternative is needed, or relevant financial facts/source state change.
Owner and accepted result. Verification Operations. Send income values that Verification can trace to the applicant, source period and approved basis. Treat gross earnings and net deposits as separate measures.
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 processor requests another pay document without checking whether an accepted source already covers the requirement. Assistant pitfall. The agent interprets permission to read bank data as permission to set up repayment.
Release check. Match income type and open requirement to the current approved sources, applicant, purpose and permitted read scope; check that the request matches the outstanding evidence item. The provider has no coverage. Record the actual source outcome, keep repayment authority untouched and offer only a permitted alternate.
Tasks and validation instructions
- Collect applicable permitted financial evidence
- Interpret and reconcile financial evidence
- Resolve verification discrepancies
- Record financial status and publish supported facts
Collect applicable permitted financial evidence
Owner and trigger. Verification analyst. Requested correction supplies affected financial evidence. Case is active for this contemplated action, current evidence version applies, and no withdrawal, terminal disposition or superseding material-change hold prohibits it. Active for this scoped action includes an explicit effective LO-08-T06 authorization that lifts only a prior valid-NOI nonresponse closure. It never overrides other terminal reasons.
Read and preflight. Use authorized data connections and applicable documents. The current actual financial requirement and a lawful selected provider/document/source route cover this request.
Implement and hand off. Actual permitted financial request/receipt state and candidate evidence, including no coverage, refusal, unreadable, missing or unknown result. 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. Choose evidence by actual income type and requirements. Do not require employment contact for every source or infer automatic-debit authorization from data access. Offer an approved alternate evidence path when needed.
Human pitfall. A processor requests another pay document without checking whether an accepted source already covers the requirement.
Assistant pitfall. The agent interprets permission to read bank data as permission to set up repayment.
Independent check. Match income type and open requirement to the current approved sources, applicant, purpose and permitted read scope; check that the request matches the outstanding evidence item.
Failure and recovery. The provider has no coverage. Record the actual source outcome, keep repayment authority untouched and offer only a permitted alternate. 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 “Collect applicable
permitted financial evidence”. Use
only the authorized input manifest for
this task. Use authorized data
connections and applicable documents.
Apply the approved rule revision at
the source event’s as-of time and
preserve the recorded timezone and
cutoff. Match income type and open
requirement to the current approved
sources, applicant, purpose and
permitted read scope; check that the
request matches the outstanding
evidence item. 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 (Verification
analyst). Leave unsupported values
unknown. Apply this recovery rule. The
provider has no coverage. Record the
actual source outcome, keep repayment
authority untouched and offer only a
permitted alternate. Keep the decision
and any write within existing
authority. Read any original
destination receipt before repeating
an effect.
Source context · Regulation B §1002.6, evaluation of applications
Interpret and reconcile financial evidence
Owner and trigger. Verification analyst. A lawfully inspectable financial response/document candidate is available, including named missing/conflicting period, ownership or coverage fields for LO-11-T02 assessment. Fully unavailable/unreadable source results retain their existing fallback/owned gap. No accepted financial fact is fabricated.
Read and preflight. Actual candidate financial source values and available ownership/period/gross-net/context fields, including named missing/conflicting components. An attributed source/document interpretation candidate or named incomplete field/source state exists.
Implement and hand off. Supported interpreted components or named missing/defective/unknown ownership, period, amount or treatment status. 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. Preserve ownership, source, period, gross/net basis and permitted income components. Reconcile transfers/duplicates as relevant. No automatic exclusion of protected income or equivalence of deposits/business revenue and supported personal income. Refer irregular or unexplained amounts.
Human pitfall. An analyst adds gross payroll and the matching net deposit as separate income.
Assistant pitfall. The model infers personal earnings from an uncategorized business deposit.
Independent check. Compare borrower ownership, period, gross/net basis, payroll and transaction references against the raw sources; reconcile overlapping transfers using the approved treatment.
Failure and recovery. The bank credit may duplicate the payroll item and its relationship is unresolved. Hold the affected component, preserve both references and send it to Verification. 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 “Interpret and
reconcile financial evidence”. Use
only the authorized input manifest for
this task. Actual candidate financial
source values and available
ownership/period/gross-net/context
fields, including named
missing/conflicting components. Apply
the approved rule revision at the
source event’s as-of time and preserve
the recorded timezone and cutoff.
Compare borrower ownership, period,
gross/net basis, payroll and
transaction references against the raw
sources; reconcile overlapping
transfers using the approved
treatment. 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 (Verification
analyst). Leave unsupported values
unknown. Apply this recovery rule. The
bank credit may duplicate the payroll
item and its relationship is
unresolved. Hold the affected
component, preserve both references
and send it to Verification. Keep the
decision and any write within existing
authority. Read any original
destination receipt before repeating
an effect.
Source context · Regulation B §1002.6, evaluation of applications
Connected work · Resolve verification discrepancies
Resolve verification discrepancies
Owner and trigger. Verification analyst or senior assessor. An actual material financial-evidence discrepancy needs clarification.
Read and preflight. Use conflicting results and applicant clarification. A real named financial discrepancy and available candidate evidence/clarification state exist.
Implement and hand off. Supported correction, exact missing-item request basis or an explicit unresolved/source-owned financial gap. 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. Clean cases bypass this remediation. Do not treat missing provider coverage or connection refusal as proof of fraud. Return affected evidence for correction or hold the case.
Human pitfall. A reviewer overwrites an evidence revision instead of linking the applicant's correction.
Assistant pitfall. The agent treats a refusal to connect a provider as proof of fraud.
Independent check. Compare the actual conflicting values, original source revision and newly attributed correction to the specific open gap and recompute only the affected check.
Failure and recovery. A correction cannot be linked to the reported pay period. Preserve both versions, keep the affected gap open and request precise clarification. 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
verification discrepancies”. Use only
the authorized input manifest for this
task. Use conflicting results and
applicant clarification. Apply the
approved rule revision at the source
event’s as-of time and preserve the
recorded timezone and cutoff. Compare
the actual conflicting values,
original source revision and newly
attributed correction to the specific
open gap and recompute only the
affected check. 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 (Verification
analyst or senior assessor). Leave
unsupported values unknown. Apply this
recovery rule. A correction cannot be
linked to the reported pay period.
Preserve both versions, keep the
affected gap open and request precise
clarification. Keep the decision and
any write within existing authority.
Read any original destination receipt
before repeating an effect.
Source context · Regulation B §1002.6, evaluation of applications
Connected work · Interpret and reconcile financial evidence
Record financial status and publish supported facts
Owner and trigger. Verification Operations. An attributable actual current financial-result/requirement assessment is available or changes: clean/resolved, adequate/not-required, or a named deficient/unsupported/unknown/current-basis-loss state. Accepted facts remain a separately supported output.
Read and preflight. Source, ownership, period, gross/net basis, accepted components, overlaps and uncertainties. An attributable clean/resolved/deficient/not-required financial result candidate and its basis/limits state exist.
Implement and hand off. Versioned supported financial facts/adequate-or-not-required state, or explicit unresolved/unsupported publication hold with no accepted fact fabricated. 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 equate deposits or business revenue with supported personal income. Preserve source basis and allowed treatment, and keep capacity decision with Credit. Assigned authority owns this recorded outcome. A human signoff is required only where the applicable rule or actual policy requires it.
Human pitfall. A processor publishes an annual figure as monthly income.
Assistant pitfall. The agent decides the borrower's capacity from an unresolved deposit.
Independent check. Compare published components, declared period/unit, ownership, source revision and effective treatment to the accepted evidence snapshot, preserving unsupported components as unknown.
Failure and recovery. No authorized evidence supports a deposit as personal income. Withhold that component, publish only supported facts and keep the capacity decision with Credit. 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 “Record financial
status and publish supported facts”.
Use only the authorized input manifest
for this task. Source, ownership,
period, gross/net basis, accepted
components, overlaps and
uncertainties. Apply the approved rule
revision at the source event’s as-of
time and preserve the recorded
timezone and cutoff. Compare published
components, declared period/unit,
ownership, source revision and
effective treatment to the accepted
evidence snapshot, preserving
unsupported components as unknown.
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
(Verification Operations). Leave
unsupported values unknown. Apply this
recovery rule. No authorized evidence
supports a deposit as personal income.
Withhold that component, publish only
supported facts and keep the capacity
decision with Credit. Keep the
decision and any write within existing
authority. Read any original
destination receipt before repeating
an effect.
Source context · Regulation B §1002.6, evaluation of applications
Connected work · Assess repayment capacity
Scheduling and safe replay
Run when applicable financial evidence, a correction or a provider status changes. Pin the approved requirement, source revision and reporting period. Recompute affected components and publish a new version only when their treatment is supported.
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-11-lab.sqlite \
--process LO-11
LO-11-current→verified.LO-11-wrong-income-period→hold. Reasonmismatch:income_period. Sourceincome_periodis"month". The saved value is"pay_period".
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 income & employment verification. 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.
