How to automate personal loan servicing handoff
TLDR
Close the initial handoff after the current Servicing owner substantively accepts the current package for the reconciled loan. Record any technical receipt separately.
When can Origination close the servicing handoff?
Servicing confirms file delivery for OPEN-42 but supplies no substantive acceptance for the current package. Record the delivery response and keep the handoff open until Loan Operations receives the required acceptance.
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. An initial authoritative loan package or later source correction is ready, a matched recipient response arrives, or acknowledgment investigation is required.
Owner and accepted result. Loan Operations. Servicing Operations accepts the handoff. Close the initial handoff after the current Servicing owner substantively accepts the current package for the reconciled loan. Record any technical receipt 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. Packages an old schedule or omits the accepted opening reference. Assistant pitfall. Treats successful assembly as current evidence agreement.
Release check. Compare package terms, opening identity, schedule, payout evidence, versions and recipient access with the current release checklist. The schedule revision is stale. Withhold package release and rebuild using the reconciled current schedule.
Tasks and validation instructions
- Prepare the servicing package
- Deliver the initial or corrected servicing package
- Record the initial or current servicing response
Prepare the servicing package
Owner and trigger. Loan operations specialist. An accepted opening version or scoped authoritative source correction selects package preparation.
Read and preflight. Attributable current opening/source records, authoritative term/document references, intended receiving owner and any itemized source correction. Missing or inconsistent candidate items remain inspectable. The original loan, intended receiving interface and candidate source records/references are attributable.
Implement and hand off. A prepared source-linked package satisfying its actual release checks, or itemized missing/inconsistent/access/custody defects owned for 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. Only the positive prepared-package result qualifies for servicing package release. Assembly/inspection can run to discover a defect without assuming source agreement beforehand. Return missing source fields to their owning process.
Human pitfall. Packages an old schedule or omits the accepted opening reference.
Assistant pitfall. Treats successful assembly as current evidence agreement.
Independent check. Compare package terms, opening identity, schedule, payout evidence, versions and recipient access with the current release checklist.
Failure and recovery. The schedule revision is stale. Withhold package release and rebuild using the reconciled current schedule. Use the original key (original loan + source/package candidate version + initial-or-correction scope) 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 the
servicing package”. Use only the
authorized input manifest for this
task. Attributable current
opening/source records, authoritative
term/document references, intended
receiving owner and any itemized
source correction. Missing or
inconsistent candidate items remain
inspectable. Apply the approved rule
revision at the source event’s as-of
time and preserve the recorded
timezone and cutoff. Compare package
terms, opening identity, schedule,
payout evidence, versions and
recipient access with the current
release checklist. 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 schedule revision
is stale. Withhold package release and
rebuild using the reconciled current
schedule. 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 · Publish the initial opening or scoped correction event · Deliver the initial or corrected servicing package
Deliver the initial or corrected servicing package
Owner and trigger. Loan operations specialist. The producer package-release checks permit its first current delivery.
Read and preflight. Current package that met the producer release checks, intended initial/current servicing interface, lawful access, stable loan/package/handoff identity and actual prior delivery state. The current producer-released package, intended recipient, lawful interface access and stable original loan/handoff identity are identified.
Implement and hand off. A scoped initial/correction delivery attempt with local submission evidence, or a pending/failed/unknown send result. Receiving acceptance remains separate. 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. Actual delivery scope and reference are traceable. Neither receiving acknowledgment nor successful boarding is required to attempt the first authorized delivery. Check receiving status before a controlled transfer retry.
Human pitfall. Resends the package before checking an uncertain original attempt.
Assistant pitfall. Claims successful boarding from sender submission.
Independent check. Compare the intended receiver, loan ID, handoff key and package digest with the actual original attempt. Check receiving state separately before replay.
Failure and recovery. Network response is lost. Keep transmission unknown and query the original handoff rather than reboarding. Use the original key (original loan/handoff + producer package version + initial-or-correction delivery attempt) 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 “Deliver the initial
or corrected servicing package”. Use
only the authorized input manifest for
this task. Current package that met
the producer release checks, intended
initial/current servicing interface,
lawful access, stable
loan/package/handoff identity and
actual prior delivery state. Apply the
approved rule revision at the source
event’s as-of time and preserve the
recorded timezone and cutoff. Compare
the intended receiver, loan ID,
handoff key and package digest with
the actual original attempt. Check
receiving state separately before
replay. 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.
Network response is lost. Keep
transmission unknown and query the
original handoff rather than
reboarding. 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 · Prepare the servicing package
Record the initial or current servicing response
Owner and trigger. Loan operations specialist. An actual initial/current servicing-owner response or correlated status-query result arrives.
Read and preflight. A matched initial/current owner response or correlated receiving-state inquiry result, original loan/package/handoff reference and receiving event identity. The response/query result can be attributed to the original loan, exact package/handoff and receiving event.
Implement and hand off. Recorded technical receipt, substantive acceptance, itemized rejection or pending/unknown result for the identified initial/correction interface. 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 the attributed actual response before the receipt gate determines positive completion. Technical receipt, substantive acceptance and current servicing state remain distinct. A negative result is recordable. Route rejected fields for correction and confirm LS-01 acceptance on the updated package.
Human pitfall. Closes Origination after a technical receipt arrives.
Assistant pitfall. Infers substantive acceptance from a successful upload or an old version’s reply.
Independent check. Match the receiver’s current owner, opening ID, package digest and substantive disposition with the current handoff. Confirm the terminal event has not already been emitted.
Failure and recovery. A technical receipt or v2 acceptance arrives for current v3. Record the actual response and keep completion pending. Use the original key (original loan/handoff + package version + receiver event/query 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 “Record the initial
or current servicing response”. Use
only the authorized input manifest for
this task. A matched initial/current
owner response or correlated
receiving-state inquiry result,
original loan/package/handoff
reference and receiving event
identity. Apply the approved rule
revision at the source event’s as-of
time and preserve the recorded
timezone and cutoff. Match the
receiver’s current owner, opening ID,
package digest and substantive
disposition with the current handoff.
Confirm the terminal event has not
already been emitted. 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. A technical receipt or
v2 acceptance arrives for current v3.
Record the actual response and keep
completion pending. 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
Scheduling and safe replay
Run on authoritative package readiness, the actual linked Servicing response or a handoff investigation event. Match the response to the original delivery key and package revision. Replay inquiries without creating another initial handoff.
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-25-lab.sqlite \
--process LO-25
LO-25-current→verified.LO-25-technical-receipt-only→hold. Reasonunconfirmed:receipt_kind. Both records showreceipt_kind="technical_receipt". That state holds even when the records agree.
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 servicing handoff. 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.
