LOS-to-LMS handoff: an accepted API request does not prove a serviceable loan
Define what an LOS-to-LMS handoff must prove: approved terms, account identifiers, usable schedules and clear recovery when requests conflict or responses fail.
The origination team has a success response. The loan management team has an account number. Neither proves that the next repayment will be calculated from the terms the lender approved.
A Loan Origination System (LOS) to Loan Management System (LMS) handoff should establish a business result: the receiving system has accepted the correct version of the loan and can support the next authorised servicing action. The LMS maintains the account and its transactions; servicing is the work that follows across its life. Both depend on accepting the intended terms.
The practical artefact is an acceptance matrix agreed by origination, loan management and servicing, finance and the integration owners. It states what must match, how the result will be demonstrated and who resolves a mismatch.
Agree where the handoff occurs
An approved application and an active loan are different states. Some integrations create a provisional record before later events make it operational. Others receive a funded account with an initial balance. The acceptance conditions must name the intended stage.
Do not use “loan created” as a catch-all label. Specify which further evidence is required before a schedule, statement or collection action may be used. A successful import should not itself authorise a disbursal, a debit or a change to approved terms.
This article concerns the post-approval receiving boundary. It does not propose an underwriting decision or a universal booking sequence. A lender’s actual product, accounting model and system responsibilities determine that sequence.
Compare meaning as well as format
A date can be validly formatted and still be the wrong first due date. A rate can be numeric and still use a different basis from the approved terms. A customer identifier can exist and still identify the wrong role on a joint account.
Use the following matrix as a starting point. Extend it for the product rather than treating the list as a complete data specification.
| Acceptance area | Evidence to compare | Example failure to reject or hold |
|---|---|---|
| Identity and references | Source loan, receiving account, borrower roles and applicable partner references | Valid customer ID attached in the wrong role |
| Approved terms | Approval reference and version, amount, rate basis, tenure, fees and relevant dates | Current product defaults substituted for approved terms |
| Schedule and balances | Expected instalments and opening state under agreed calculation and rounding rules | Dates agree but the first instalment amount does not |
| Operating readiness | Required documents, servicing owner and readiness of the next permitted action | Account created while a required dependency remains unresolved |
| Outcome and recovery | Request identity, accepted version, result reference and exception status | A timeout interpreted as proof that no account exists |
Compare outputs as well as input fields. If two systems receive the same rate and dates but generate different schedules, passing a schema check has not resolved the disagreement. Investigate calculation conventions, rounding and configured rules. Do not choose whichever schedule makes the import pass.
Work through one first-period mismatch
A historical open-source issue report described a first-period calculation using 31 days where the reporter expected five between 27 January and 1 February. The report was later closed as abandoned, not as a verified fix. It supplies a test pattern, not evidence about a current provider.
Use a controlled fixture to test that pattern. Assume ₹1,00,000 principal, a 12% annual rate, Actual/365 interest and an agreed five-day first period. The following is an illustrative acceptance comparison, not exported customer schedules. It isolates the interest component; principal repayment and fees are excluded.
| First-period field | Approved LOS fixture | Faulty LMS output |
|---|---|---|
| Start and first due date | 27 January to 1 February | 27 January to 1 February |
| Days used for interest | 5 | 31 |
| Calculation | ₹1,00,000 × 12% × 5 ÷ 365 | ₹1,00,000 × 12% × 31 ÷ 365 |
| First-period interest | ₹164.38 | ₹1,019.18 |
The displayed dates match, but the separately rounded interest amounts differ by ₹854.80. Reject business acceptance until the calculation basis agrees with the approved fixture. Testing that the due-date field arrived correctly would miss this defect. Repeat the comparison for rounding, a holiday shift and the lender’s actual first-period convention.
Make the receipt say what was accepted
The HTTP standard defines 202 as acceptance for processing rather than completion. The eventual result needs a separate way to become visible. For other response codes, interpret success against the operation the endpoint actually promises.
For the business handoff, require a result that identifies the source request, receiving account, approved version and acceptance status. Link unresolved checks to an exception reference. Agree these result fields in the integration contract.
A receipt for version 4 should never be presented as acceptance of version 5. That becomes especially important when people correct a failed case while an earlier request is still running.
The broader integration planning guide covers dependency planning. This acceptance record adds a specific question: what can the operating team safely conclude from each response?
Test a lost response and a changed request
In a separate recovery test, request H-204 carries approved terms version 4. The LMS creates account L-880 and records its result, but the connection fails before the sender receives it. The sender sees a timeout.
First, query or otherwise resolve H-204 through the agreed recovery mechanism. A timeout describes what the sender observed. It does not establish whether the receiver performed the work.
Next, retry the unchanged request under the supplier’s documented duplicate-handling contract. The expected result is the existing account and recorded outcome, with no second account or repeated financial side effect. Test the scope and retention period of that protection. A request key that expires before the lender’s retry window leaves a gap.
Finally, submit version 5 using H-204. The integration must recognise that the payload is different and follow the defined conflict or correction process. Silently returning the old success would hide the change. Silently applying new terms would bypass the distinction between initial acceptance and an authorised amendment.
A published command-retry hardening task, still in progress when checked, shows why duplicate protection deserves explicit tests. Its proposal does not establish production behaviour.
Repeat the exercise with concurrent, delayed and out-of-order responses. The operator should still be able to identify the accepted version and any unresolved change.
Give rejected handoffs somewhere to go
An exception queue needs enough information to act: the failed condition, affected request, source version, current receiving state and owner. A raw error message without the source record forces the next team to reconstruct the incident.
Keep business-data correction separate from a technical retry. A missing approval reference will not become valid because a scheduler sends it again. An uncertain execution result needs investigation before replay. A corrected request needs a traceable relationship to the original case.
Measure accepted handoffs, unresolved age and recurring rejection reasons. A high API success rate can coexist with a growing queue of accounts that cannot yet be serviced. Report that queue to the people accountable for the book.
After the handoff works, rehearse the first repayment cycle with the operating team. That tests what happens after acceptance, including payment exceptions and borrower support.
Lokta’s Loan Management and AI Loan Servicing are available now for the post-approval book. Loan Origination is on the roadmap. For a lender retaining an external LOS, the useful evaluation is its specific handoff into loan management and servicing. Make the agreed schedule fixture and retry cases requirements of the integration evaluation. Request the observed result, protection scope and retention period for the proposed connection. These are buyer acceptance tests; this article does not establish that Lokta has passed them for a particular integration.
Frequently asked questions
What should an LOS-to-LMS handoff confirm?
It should confirm the receiving account, the approved terms version, the relevant customer and partner references, and the initial state needed for the next servicing action. The exact fields depend on the product and handoff stage. Compare resulting schedules and balances with agreed expectations, rather than checking only that fields were present. Keep a separate exception state when business acceptance has not completed, with a named owner and a recoverable request reference.
Does HTTP 202 mean a loan is ready for servicing?
No. HTTP 202 confirms acceptance for processing, not completion. Obtain the eventual business result through the agreed status resource or event, then verify the accepted terms version, schedule and account state before authorising the next servicing action.
How should an LMS handle a retried loan creation request?
The integration should define a stable request identity and a duplicate-handling contract. If the same request has already succeeded, a retry should resolve to its recorded result rather than create another account. If the same identifier arrives with materially different terms, treat it as a conflict requiring the defined correction process. Verify the supplier’s actual behaviour, scope and retention of duplicate protection rather than assuming that adding a reference field makes retries safe.
Who owns an LOS-to-LMS handoff exception?
The source-data owner resolves missing or inconsistent approved terms. The integration or LMS owner resolves receiving-system failures. Operations needs the same case reference, current account state and unresolved condition so it can explain why the next action is held.
Read next
- LMS integration planning: place the handoff within the wider integration programme
- Rehearse the first repayment cycle: test the operating team after accounts are ready for servicing
Sources
- IETF RFC 9110, section 15.3.3: HTTP 202 distinguishes accepted processing from completed work. The lending acceptance matrix in this article is an original recommendation, not part of the RFC
Lokta editorial analysis by Chandramouli, co-founder and CEO.
