How to automate personal loan booking
TLDR
Publish one accepted opening after reconciling the signed terms, principal, payout, dates and schedule by meaning. Link any correction to the same opening identity.
When is a funded loan ready for an accepted opening record?
The core contains a provisional account reference and the payout is settled. Its opening schedule still disagrees with the approved terms. Hold accepted booking until Loan Operations reconciles the component meanings.
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 selected implementation needs a provisional reference, configured opening evidence becomes available, or an existing opening record needs a source-owned correction.
Owner and accepted result. Loan Operations. Publish one accepted opening after reconciling the signed terms, principal, payout, dates and schedule by meaning. Link any correction to the same opening identity.
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. Reports a provisional account number as a funded loan. Assistant pitfall. Interprets a reserved core ID as servicing activation or recognition.
Release check. Check the core record type and state against the loan reference and actual settlement/opening evidence separately. Core ID exists in provisional state with no payout evidence. Keep provisional and do not advance funded status.
Tasks and validation instructions
- Establish or resolve provisional account reference
- Prepare or confirm the loan opening record
- Reconcile opening principal, schedule and component meanings
- Publish the initial opening or scoped correction event
Establish or resolve provisional account reference
Owner and trigger. Loan Operations. A selected lending/payment implementation needs a persistent account reference before disbursement.
Read and preflight. Current application, creditor/product, approved/current draft reference and existing account search. A stable case/business-intent identity and actual implementation reference requirement are known.
Implement and hand off. One provisional non-activated reference or confirmed existing record. 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 placeholder is explicitly not proof of funded credit, servicing activation or GAAP recognition. Assigned authority retains the stated decision. No universal manual approval is implied.
Human pitfall. Reports a provisional account number as a funded loan.
Assistant pitfall. Interprets a reserved core ID as servicing activation or recognition.
Independent check. Check the core record type and state against the loan reference and actual settlement/opening evidence separately.
Failure and recovery. Core ID exists in provisional state with no payout evidence. Keep provisional and do not advance funded status. Use the original key (original case + creditor/program + provisional reference purpose) 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 “Establish or
resolve provisional account
reference”. Use only the authorized
input manifest for this task. Current
application, creditor/product,
approved/current draft reference and
existing account search. Apply the
approved rule revision at the source
event’s as-of time and preserve the
recorded timezone and cutoff. Check
the core record type and state against
the loan reference and actual
settlement/opening evidence
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 (Loan Operations).
Leave unsupported values unknown.
Apply this recovery rule. Core ID
exists in provisional state with no
payout evidence. Keep provisional and
do not advance funded status. Keep the
decision and any write within existing
authority. Read any original
destination receipt before repeating
an effect.
Source context · Mambu Loan Account Life Cycle and States
Connected work · Capture request and original receipt event · Validate payout destination and selected route
Prepare or confirm the loan opening record
Owner and trigger. Loan operations specialist. The current entry gate permits initial opening preparation.
Read and preflight. Executed terms, authoritative payment state, any previously reserved account reference and configured booking criteria. The stable case/business intent and inspectable executed/source record are attributable.
Implement and hand off. One traceable draft/current opening record, reusing an existing account reference or creating it only when absent under the selected 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. The entry criterion permits preparation/confirmation. Accepted opening publication still waits for the explicit subsequent reconciliation. No universal platform activation timestamp is imposed. Resolve duplicate or inconsistent account references.
Human pitfall. Uses the payout amount as opening principal when fees change the amount delivered.
Assistant pitfall. Assumes any created core record is an accepted opening.
Independent check. Compare the candidate with authorized principal, current terms, execution and qualified payout evidence. Record candidate status until reconciliation.
Failure and recovery. Net proceeds and authorized principal differ. Keep the distinct fields and send the candidate for reconciliation. Use the original key (original economic intent + opening/reference candidate version + actual scoped preparation) 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 “Prepare or confirm
the loan opening record”. Use only the
authorized input manifest for this
task. Executed terms, authoritative
payment state, any previously reserved
account reference and configured
booking criteria. Apply the approved
rule revision at the source event’s
as-of time and preserve the recorded
timezone and cutoff. Compare the
candidate with authorized principal,
current terms, execution and qualified
payout evidence. Record candidate
status until reconciliation. 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
(Loan operations specialist). Leave
unsupported values unknown. Apply this
recovery rule. Net proceeds and
authorized principal differ. Keep the
distinct fields and send the candidate
for reconciliation. Keep the decision
and any write within existing
authority. Read any original
destination receipt before repeating
an effect.
Source context · Regulation Z §1026.18 Content of disclosures
Connected work · Reconcile opening principal, schedule and component meanings
Reconcile opening principal, schedule and component meanings
Owner and trigger. Loan operations specialist. An attributable prepared opening candidate becomes inspectable.
Read and preflight. Executed authorized terms/schedule, actual permitted dates, disbursement allocations and accounting-component context. The original loan/intent and the candidate record or affected component set can be identified.
Implement and hand off. A meaning-aware opening reconciliation with explained authorized differences or itemized defects. 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. Match each amount to its actual meaning. Validate authorized dates, installments and first due date without silent signed-term changes. Return discrepancies to Closing or Accounting.
Human pitfall. Matches opening balance and cash total while misclassifying a withheld fee.
Assistant pitfall. Forces equal totals by silently changing signed terms or first due date.
Independent check. Compare principal, net proceeds, fee components and schedule separately by meaning and currency against signed terms and settlement. Check authorized first due date.
Failure and recovery. The core date differs from the signed schedule. Hold opening acceptance and return the date mismatch to Loan Operations. Use the original key (original loan + opening candidate/component versions + scoped change 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 “Reconcile opening
principal, schedule and component
meanings”. Use only the authorized
input manifest for this task. Executed
authorized terms/schedule, actual
permitted dates, disbursement
allocations and accounting-component
context. Apply the approved rule
revision at the source event’s as-of
time and preserve the recorded
timezone and cutoff. Compare
principal, net proceeds, fee
components and schedule separately by
meaning and currency against signed
terms and settlement. Check authorized
first due date. 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 (Loan operations
specialist). Leave unsupported values
unknown. Apply this recovery rule. The
core date differs from the signed
schedule. Hold opening acceptance and
return the date mismatch to Loan
Operations. Keep the decision and any
write within existing authority. Read
any original destination receipt
before repeating an effect.
Source context · Regulation Z §1026.18 Content of disclosures
Connected work · Prepare or confirm the loan opening record
Publish the initial opening or scoped correction event
Owner and trigger. Loan operations specialist. opening reconciliation check positively accepts the current prepared/reconciled opening or permitted correction version.
Read and preflight. Use the verified loan and funding linkage. The current positive opening reconciliation and original economic intent are identified.
Implement and hand off. Versioned authoritative opening-record event explicitly classified as initial opening or a linked correction. 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. One initial opening identity is retained. A corrected version never becomes a second loan, initial accounting recognition or first boarding. Assign downstream or accounting exceptions to their owner.
Human pitfall. Publishes a new opening identity for a correction.
Assistant pitfall. Treats a correction as permission to repeat first boarding or recognition.
Independent check. Match the outgoing event to the original opening identity, current reconciled version and superseded event reference. Check the destination receipt by key.
Failure and recovery. Opening v2 corrects v1. Publish a linked correction and prevent a second initial opening event. Use the original key (original loan/economic intent + accepted opening version + initial-or-correction event kind) 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 “Publish the initial
opening or scoped correction event”.
Use only the authorized input manifest
for this task. Use the verified loan
and funding linkage. Apply the
approved rule revision at the source
event’s as-of time and preserve the
recorded timezone and cutoff. Match
the outgoing event to the original
opening identity, current reconciled
version and superseded event
reference. Check the destination
receipt by key. 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 (Loan operations
specialist). Leave unsupported values
unknown. Apply this recovery rule.
Opening v2 corrects v1. Publish a
linked correction and prevent a second
initial opening event. Keep the
decision and any write within existing
authority. Read any original
destination receipt before repeating
an effect.
Source context · Regulation Z §1026.18 Content of disclosures
Connected work · Prepare the servicing package
Scheduling and safe replay
Run when required opening evidence is available, a provisional reference must be resolved or a correction arrives. Pin the accepted payout and terms at the opening cutoff. Reuse the initial opening key and track approved corrections separately.
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-24-lab.sqlite \
--process LO-24
LO-24-current→verified.LO-24-one-cent-opening-variance→hold. Reasonmismatch:opening_principal_cents. Sourceopening_principal_centsis800000. The saved value is800001.
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 booking. 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.
