Skip to main content
POST
/
v1
/
loans
/
external
/
{loan_external_id}
/
adjust-disbursement-date
Adjust disbursement date
curl --request POST \
  --url https://api.dev.bsa.ai/v1/loans/external/{loan_external_id}/adjust-disbursement-date \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "actualDisbursementDate": "<string>",
  "note": "<string>"
}
'
Shifts the effective disbursal date on an Active loan. Use this when the partner’s wallet credit was delayed (e.g. pending → confirmed two days later) and the LMS-recorded disbursement date no longer matches the day the customer actually received the money. Interest re-accrues from the new date, and the repaymentSchedule is recalculated so the next due-date math matches reality.
A loan with recorded repayments is rejected with 409 aborted. The adjustment reverses and re-books the disbursement, which would cascade-reverse any repayments — so erasing them must be an explicit choice. Reverse the repayment(s) first, then adjust.

​
Date constraints

  • The new date must not be in the future — pass today or any past day.
  • The new date must not be before the loan’s approval date. Because POST /v1/loans approves on the same day it disburses, the new date must be on or after the original disbursement date.
For the realistic delayed-wallet flow both constraints are satisfied naturally: the partner calls this endpoint on the day the wallet credit actually confirms, which is between the original approval/disbursement day and today. Two equivalent forms — prefer the externalId form for partner integrations.

​
Path parameters

​
loan_external_id
string
required
The loan’s externalId. On the /v1/loans/{loan_id}/adjust-disbursement-date form, this is the numeric LMS id instead.

​
Request body

​
actualDisbursementDate
string
required
ISO-8601 YYYY-MM-DD. The corrected disbursal date.
​
note
string
Optional. Reason for the adjustment, captured in the LMS audit log.

​
Examples

# By loan externalId (recommended)
curl -sf -X POST "$BASE/v1/loans/external/loan-ext-12345/adjust-disbursement-date" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "actualDisbursementDate": "2026-05-30",
    "note": "Wallet credit confirmed 2 days after original disbursement"
  }'

# Same effect, by LMS id
curl -sf -X POST "$BASE/v1/loans/501/adjust-disbursement-date" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"actualDisbursementDate": "2026-05-30"}'

​
Response

200 OK returns the loan object with the new disbursal date, recomputed schedule, and adjusted next-due fields.

​
How it works

The wrapper performs undo-disbursal then re-disburse against the LMS with the corrected date. These are two separate LMS commands, so the wrapper makes them atomic from the partner’s point of view: it records the current disbursement date first, and if re-disbursing at the new date fails it automatically rolls the loan back to the original date. Either the adjustment succeeds (loan Active, new schedule), or it fails cleanly with the loan left in its original Active state — the loan is never stranded in Approved. The only exception is the rare case where the re-disbursal and the automatic rollback both fail; the response is then a 500 whose message states the loan is in Approved and names the original date to re-disburse manually.

​
Errors

CodeWhen
not_foundNo loan with that id or externalId
failed_preconditionThe loan has no disbursement to adjust (not yet disbursed)
abortedThe loan has recorded repayments — reverse them before adjusting the date
invalid_argumentactualDisbursementDate missing, not ISO YYYY-MM-DD, in the future, or before the loan’s approval date
permission_deniedDate in the future, or date before the loan’s approval date
internalRe-disbursal failed and automatic rollback also failed — loan is in Approved and needs manual re-disbursal (message names the original date)