How to automate personal loan product definition
TLDR
Release a new definition after Product approves the legal creditor, eligible jurisdictions, product type, supported channels and term limits for that revision.
What must Product approve before a personal-loan definition can go live?
Product proposes the same installment loan through a new partner. Its jurisdiction row names the partner's brand but leaves the legal creditor blank. Hold the affected scope row and send it to Compliance before the revised definition goes live.
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 product launch or change alters permitted terms, customer scope or channels.
Owner and accepted result. Consumer Lending Product. Release a new definition after Product approves the legal creditor, eligible jurisdictions, product type, supported channels and term limits for that revision.
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 product analyst copies the creditor from the last launch into a new channel row. Assistant pitfall. The agent treats a partner's brand name as the legal creditor.
Release check. Join each proposed product, jurisdiction and channel row to the creditor and product-type entries in the approved scope matrix; save the matching row and revision. A partner-channel row names no authorized creditor. Hold that row and ask Compliance to resolve it before implementation.
Tasks and validation instructions
Define the product scope
Owner and trigger. Product manager. A product launch or change alters permitted terms, customer scope or channels.
Read and preflight. Use the proposed customer, use case and distribution channels. An authorized product-change proposal identifies the intended customer/product/jurisdiction/channel scope. A previously approved product is not required to draft a new one.
Implement and hand off. Produce the product and jurisdiction matrix. 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. The matrix identifies the legal creditor and permitted product type. Refer unresolved regulatory scope to Compliance.
Human pitfall. A product analyst copies the creditor from the last launch into a new channel row.
Assistant pitfall. The agent treats a partner's brand name as the legal creditor.
Independent check. Join each proposed product, jurisdiction and channel row to the creditor and product-type entries in the approved scope matrix; save the matching row and revision.
Failure and recovery. A partner-channel row names no authorized creditor. Hold that row and ask Compliance to resolve it before implementation. Use the original key (control work item + product/campaign/pricing version + actual 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 “Define the product
scope”. Use only the authorized input
manifest for this task. Use the
proposed customer, use case and
distribution channels. Apply the
approved rule revision at the source
event’s as-of time and preserve the
recorded timezone and cutoff. Join
each proposed product, jurisdiction
and channel row to the creditor and
product-type entries in the approved
scope matrix; save the matching row
and revision. 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 (Product manager).
Leave unsupported values unknown.
Apply this recovery rule. A
partner-channel row names no
authorized creditor. Hold that row and
ask Compliance to resolve it before
implementation. 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 · Approve and release the definition · Specify permissible terms
Specify permissible terms
Owner and trigger. Product manager with Credit. A product launch or change alters permitted terms, customer scope or channels.
Read and preflight. Use product requirements and risk appetite. An identifiable proposed product scope and actual risk/legal requirements are available for term specification.
Implement and hand off. Produce approved amount, duration, eligibility and fee boundaries. 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. Terms and credit criteria have named policy owners. Escalate proposed exceptions before approval.
Human pitfall. A reviewer enters a term in years where the product rules expect months.
Assistant pitfall. The model fills an unset maximum fee from a neighboring product.
Independent check. Normalize durations to the unit declared by the product policy and compare min/max amount, term, fee and eligibility fields to its effective revision and owner.
Failure and recovery. A fee ceiling has no approved source. Preserve the null, hold the affected term and route it to the product policy owner. Use the original key (control work item + product/campaign/pricing version + actual 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 “Specify permissible
terms”. Use only the authorized input
manifest for this task. Use product
requirements and risk appetite. Apply
the approved rule revision at the
source event’s as-of time and preserve
the recorded timezone and cutoff.
Normalize durations to the unit
declared by the product policy and
compare min/max amount, term, fee and
eligibility fields to its effective
revision and owner. 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 (Product
manager with Credit). Leave
unsupported values unknown. Apply this
recovery rule. A fee ceiling has no
approved source. Preserve the null,
hold the affected term and route it to
the product policy owner. 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 · Define the product scope · Approve and release the definition
Approve and release the definition
Owner and trigger. Product owner with Compliance. A product launch or change alters permitted terms, customer scope or channels.
Read and preflight. Use the reviewed product package. An identifiable proposed product package and assigned approval authority are available for review. Release occurs only after actual required signoffs.
Implement and hand off. Release a dated product version for implementation. 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. Signoffs and the effective date are retained. Hold unapproved versions.
Human pitfall. Release staff schedule the approved version for the wrong effective date.
Assistant pitfall. The agent treats a review comment as final approval.
Independent check. Compare the saved release package digest and effective timestamp to the approved package and required signoff records for that exact revision.
Failure and recovery. A signoff refers to revision 4 while revision 5 is queued. Block the release; obtain revision 5 approval or use the still-authorized version. Use the original key (control work item + product/campaign/pricing version + actual 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 “Approve and release
the definition”. Use only the
authorized input manifest for this
task. Use the reviewed product
package. Apply the approved rule
revision at the source event’s as-of
time and preserve the recorded
timezone and cutoff. Compare the saved
release package digest and effective
timestamp to the approved package and
required signoff records for that
exact revision. 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 (Product owner
with Compliance). Leave unsupported
values unknown. Apply this recovery
rule. A signoff refers to revision 4
while revision 5 is queued. Block the
release; obtain revision 5 approval or
use the still-authorized version. 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 · Specify permissible terms · Develop the pricing schedule
Scheduling and safe replay
Run when the product package, jurisdiction scope or approval record changes. Evaluate the package digest against the governing approvals at the proposed effective time. Replay the changed rows and retain the previous release and its date.
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-01-lab.sqlite \
--process LO-01
LO-01-current→verified.LO-01-stale-version→hold. Reasonmismatch:product_revision. Sourceproduct_revisionis4. The saved value is3.
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 product definition. 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
-
OCC Installment Lending Handbook · Office of the Comptroller of the Currency
