How to automate personal loan identity verification

What evidence clears an applicant identity discrepancy?

A report carries a different address and the identity service has returned a technical success. Verification still needs the evidence required to establish the report relationship and any separate alert outcome.

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. Applicable identity work is selected, a report discrepancy/alert arises, relevant identifying facts change, or a source-recovery event occurs.

Owner and accepted result. Verification Operations. Verification clears the discrepancy when current permitted evidence links the report to the applicant and separately resolves each applicable identity or alert requirement.

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 attaches a co-applicant's document under the primary applicant's identity. Assistant pitfall. The agent accepts a source response because the display name looks similar.

Release check. Match the request and response to the expected stable applicant and case references, provider request ID and document provenance before binding evidence. The response references another applicant. Hold the evidence, preserve its source reference and send the mismatch to Verification for controlled correction.

Tasks and validation instructions

• Obtain identity evidence
• Own identity-source failure and select permitted recovery
• Compare identifying attributes
• Resolve report/applicant address discrepancy
• Perform alert-type identity verification/contact
• Record the identity outcome

Obtain identity evidence

Owner and trigger. Verification analyst. Requested correction supplies missing identity 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 applicant identifiers and permitted sources. Current sufficient request identifiers and an actual lawful permitted identity-source/document route exist for this scoped request.

Implement and hand off. Actual identity-source/document request/receipt result and provenance, including missing/unavailable/unusable state. 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. Evidence belongs to the applicant or identified co-applicant. Hold source or identity mismatches.

Human pitfall. A processor attaches a co-applicant's document under the primary applicant's identity.

Assistant pitfall. The agent accepts a source response because the display name looks similar.

Independent check. Match the request and response to the expected stable applicant and case references, provider request ID and document provenance before binding evidence.

Failure and recovery. The response references another applicant. Hold the evidence, preserve its source reference and send the mismatch to Verification for controlled correction. 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 “Obtain identity
evidence”. Use only the authorized
input manifest for this task. Use
applicant identifiers and permitted
sources. Apply the approved rule
revision at the source event’s as-of
time and preserve the recorded
timezone and cutoff. Match the request
and response to the expected stable
applicant and case references,
provider request ID and document
provenance before binding evidence.
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 response references
another applicant. Hold the evidence,
preserve its source reference and send
the mismatch to Verification for
controlled correction. Keep the
decision and any write within existing
authority. Read any original
destination receipt before repeating
an effect.

Source context · Fighting Identity Theft with the Red Flags Rule: A How-To Guide for Business

Connected work · Validate intake and source-specific permissions

Own identity-source failure and select permitted recovery

Owner and trigger. Verification Operations. Required identity source/document is missing, unavailable or unusable.

Read and preflight. Original request/state, actual failure cause, available alternatives, applicable legal clock and case state. An attributed actual failed/pending identity-source request or unusable document candidate and known case context exist.

Implement and hand off. Owned classified or unknown identity-source gap, permitted alternative/request/recovery plan, or unresolved specialist 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. Do not blame applicant for inaccessible third-party failure or infer fraud. Retry only after actual relevant recovery/new evidence and source-state reconciliation. Unrelated work/clocks remain owned. Assigned lawful owner retains the scoped decision. No universal human signoff is invented.

Human pitfall. A coordinator retries a provider request while its original outcome remains unknown.

Assistant pitfall. The agent treats a provider outage as applicant noncooperation or suspected fraud.

Independent check. Match the original request ID to provider status and independent incident or recovery evidence; verify an alternate source or retry against the effective procedure and case state.

Failure and recovery. The original request outcome remains unknown during an outage. Record a source-owned gap, preserve unrelated obligations and authorize only the approved recovery path. Use the original key (application + actual affected evidence/decision/notice/condition version + event identity) 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 “Own identity-source
failure and select permitted
recovery”. Use only the authorized
input manifest for this task. Original
request/state, actual failure cause,
available alternatives, applicable
legal clock and case state. Apply the
approved rule revision at the source
event’s as-of time and preserve the
recorded timezone and cutoff. Match
the original request ID to provider
status and independent incident or
recovery evidence; verify an alternate
source or retry against the effective
procedure and case state.  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. The original request
outcome remains unknown during an
outage. Record a source-owned gap,
preserve unrelated obligations and
authorize only the approved recovery
path. Keep the decision and any write
within existing authority. Read any
original destination receipt before
repeating an effect.

Source context · Fighting Identity Theft with the Red Flags Rule: A How-To Guide for Business

Connected work · Specify the missing-information request

Compare identifying attributes

Owner and trigger. Verification analyst. Changed identifying attributes actually affect prior identity comparison. On an attributable loss affecting existing dependent current authority, emit stale/held/negative state immediately even when the change itself created a hold or replacement data are unavailable. This message does not authorize a later rerun or rewrite completed history.

Read and preflight. Use source responses and submitted identity fields. An inspectable attributed identity/application candidate or named source/field gap exists.

Implement and hand off. Supported matched/mismatched attributes or explicit missing/unknown comparison state. 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. An unavailable response cannot be treated as a passed check. Request alternate evidence or refer suspicious conflicts.

Human pitfall. A reviewer marks a blank comparison field as matched.

Assistant pitfall. The model resolves an inconsistent address from a guessed abbreviation without keeping the discrepancy.

Independent check. Compare policy-required raw application attributes with the attributed provider fields using only approved normalization; record missing, mismatched and matched fields separately.

Failure and recovery. The source omits a required identifying field. Preserve unknown and route the missing field to Verification; do not mark the check passed. 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 “Compare identifying
attributes”. Use only the authorized
input manifest for this task. Use
source responses and submitted
identity fields. Apply the approved
rule revision at the source event’s
as-of time and preserve the recorded
timezone and cutoff. Compare
policy-required raw application
attributes with the attributed
provider fields using only approved
normalization; record missing,
mismatched and matched fields
separately.  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
source omits a required identifying
field. Preserve unknown and route the
missing field to Verification; do not
mark the check passed. Keep the
decision and any write within existing
authority. Read any original
destination receipt before repeating
an effect.

Source context · Fighting Identity Theft with the Red Flags Rule: A How-To Guide for Business

Resolve report/applicant address discrepancy

Owner and trigger. Verification Operations. A CRA address-discrepancy notice or material report/application identity mismatch requires resolution.

Read and preflight. Attributed report/application discrepancy and permitted reliable comparisons. An actual CRA address-discrepancy notice/material relationship mismatch and inspectable comparison/source candidates or named gaps exist.

Implement and hand off. Supported reasonable report relationship, unresolved discrepancy/request basis, or owned source defect. No missing result is promoted to identity acceptance. 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 treat report data as relating to the applicant until the required reasonable-belief procedure is satisfied. Request only missing relevant clarification. Assigned authority owns this recorded outcome. A human signoff is required only where the applicable rule or actual policy requires it.

Human pitfall. A reviewer accepts a different report address without applying the required attribution procedure.

Assistant pitfall. The model uses a plausible address match from unrelated source text as authoritative evidence.

Independent check. Compare the attributed application and report identities and addresses to the reliable comparisons required by the approved discrepancy procedure; record the evidence supporting the report relationship.

Failure and recovery. The current comparison cannot link the report to the applicant. Keep the report relationship unresolved and route the specific missing comparison 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 “Resolve
report/applicant address discrepancy”.
Use only the authorized input manifest
for this task. Attributed
report/application discrepancy and
permitted reliable comparisons. Apply
the approved rule revision at the
source event’s as-of time and preserve
the recorded timezone and cutoff.
Compare the attributed application and
report identities and addresses to the
reliable comparisons required by the
approved discrepancy procedure; record
the evidence supporting the report
relationship.  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. The
current comparison cannot link the
report to the applicant. Keep the
report relationship unresolved and
route the specific missing comparison
to Verification. Keep the decision and
any write within existing authority.
Read any original destination receipt
before repeating an effect.

Source context · Regulation V §1022.82 — Duties of users regarding address discrepancies

Connected work · Record the identity outcome

Perform alert-type identity verification/contact

Owner and trigger. Identity / Fraud specialist. An initial, active-duty or extended fraud alert applies to the contemplated extension.

Read and preflight. Alert type, permitted contact details and requested credit action. An actual alert-type/contemplated-credit candidate and current permitted procedure context exist.

Implement and hand off. Recorded applicable contact/verification attempt and supported successful result, or unresolved alert hold/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. Apply the alert-specific identity steps before authorizing covered new credit. Extended-alert contact differs from initial/active-duty reasonable-belief procedures. Selecting a permitted procedure enables this task. Completing the required actual verification/contact is its output acceptance, not a prerequisite to attempting it. Credit/funding holds do not themselves prohibit lawful resolution work. Assigned authority owns this recorded outcome. A human signoff is required only where the applicable rule or actual policy requires it.

Human pitfall. A reviewer uses the contact procedure for the wrong alert type.

Assistant pitfall. The agent marks verification successful when the contact attempt was only initiated.

Independent check. Join the report's actual alert type and requested credit action to the approved procedure, then compare the attempt and outcome to the required evidence for completion.

Failure and recovery. The attempt is logged but no required verification result is available. Preserve the unresolved alert and hold the affected credit action pending owner review. 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 “Perform alert-type
identity verification/contact”. Use
only the authorized input manifest for
this task. Alert type, permitted
contact details and requested credit
action. Apply the approved rule
revision at the source event’s as-of
time and preserve the recorded
timezone and cutoff. Join the report's
actual alert type and requested credit
action to the approved procedure, then
compare the attempt and outcome to the
required evidence for completion.
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
(Identity / Fraud specialist). Leave
unsupported values unknown. Apply this
recovery rule. The attempt is logged
but no required verification result is
available. Preserve the unresolved
alert and hold the affected credit
action pending owner review. Keep the
decision and any write within existing
authority. Read any original
destination receipt before repeating
an effect.

Source context · 15 USC 1681c-1 — Identity theft prevention. Fraud alerts and active duty alerts

Record the identity outcome

Owner and trigger. Verification analyst. Applicable identity evidence is accepted with no unresolved relation/verification condition.

Read and preflight. Actual candidate comparison/discrepancy/alert/referral state and supporting or explicitly missing evidence. Not only resolved evidence. An actual identity/comparison/discrepancy/referral result candidate and available evidence references exist, including unresolved state.

Implement and hand off. Recorded verified, unresolved, pending, held, referred or failed identity state with current source/version and owner. 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. Record supported identity state and unresolved/cleared conditions separately. Fraud clearance alone does not verify all evidence. Statutory alerts and report relationship remain applicable gates. Route possible fraud to the authorized specialist.

Human pitfall. A reviewer clears the entire identity record after a single fraud concern is cleared.

Assistant pitfall. The agent promotes a pending comparison because the provider returned technical success.

Independent check. Compare the saved identity state and source revisions to the actual comparison, alert, discrepancy and referral records; require every applicable decision input for verified status.

Failure and recovery. Fraud is cleared while a required identity comparison remains open. Record the narrow clearance and retain the identity hold with 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 “Record the identity
outcome”. Use only the authorized
input manifest for this task. Actual
candidate
comparison/discrepancy/alert/referral
state and supporting or explicitly
missing evidence. Not only resolved
evidence. Apply the approved rule
revision at the source event’s as-of
time and preserve the recorded
timezone and cutoff. Compare the saved
identity state and source revisions to
the actual comparison, alert,
discrepancy and referral records;
require every applicable decision
input for verified status.  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. Fraud is cleared while
a required identity comparison remains
open. Record the narrow clearance and
retain the identity hold with
Verification. Keep the decision and
any write within existing authority.
Read any original destination receipt
before repeating an effect.

Source context · Fighting Identity Theft with the Red Flags Rule: A How-To Guide for Business

Connected work · Resolve report/applicant address discrepancy

Scheduling and safe replay

Run when identity evidence, a discrepancy, an alert, a material correction or source recovery arrives. Use the current applicable policy and evidence versions at the decision cutoff. Replay the affected identity check when new evidence is attributed.

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-09-lab.sqlite \
  --process LO-09

• LO-09-current → verified.
• LO-09-wrong-consumer → hold. Reason mismatch:consumer_token. Source consumer_token is "consumer-42". The saved value is "consumer-43".

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 identity 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.

Sources and related guides

• Fighting Identity Theft with the Red Flags Rule: A How-To Guide for Business · Federal Trade Commission

• OneMain Help and Support Center — Applying for a Loan · OneMain Financial

• Regulation V §1022.82 — Duties of users regarding address discrepancies · Consumer Financial Protection Bureau

• 15 USC 1681c-1 — Identity theft prevention. Fraud alerts and active duty alerts · Office of the Law Revision Counsel, U.S. House of Representatives

• How to automate loan origination for consumer lenders

• Incomplete Application Resolution

• Credit Report Review