Re-age a loan · LendEasy Docs

Replace the remaining repayment schedule with an explicit start date, cadence, and installment count.

Re-aging takes the eligible outstanding obligation and constructs a new remaining schedule. Unlike re-amortization, it can choose new due dates and a new maturity.

Worked example: Cedar

On August 20, 2027, Cedar has $2,640.00 outstanding after four of twelve $330 payments. Three installments are overdue. The approved arrangement begins September 15 and uses eight monthly installments.

New principal-only schedule

outstanding principal      $2,640.00
new installment count              8
$2,640.00 ÷ 8                $330.00

first new due date       Sep 15, 2027
new maturity             Apr 15, 2028

Result8 × $330.00

Before	After
Due dates remain on the 8th	New due dates fall on the 15th
Original maturity Jan 8, 2028	New maturity Apr 15, 2028
Three installments past due	New remaining schedule begins Sep 15
Five future installments	Eight new remaining installments

Posted payments remain attached to their original periods. Re-aging moves only eligible outstanding components; it does not rewrite the four payments already made.

Eligibility

The loan must be active, use a progressive schedule with advanced payment allocation, have a positive outstanding balance, and not be charged off or contract-terminated. Only one re-age may post per business date.

For this loan family the new start date cannot be before disbursement. Product policy can impose stronger rules—such as not before the next processing day, a maximum extension, or a maker-checker requirement. Re-aging can be used before or after original maturity when those rules and loan state allow it.

Required terms

Field	Meaning
`transactionDate`	Business date the re-age posts.
`startDate`	Due date of the first new installment.
`frequencyType`	Cadence unit—days, weeks, or months—under the product’s allowed cadences.
`frequencyNumber`	Number of frequency units between installments.
`numberOfInstallments`	Positive count of new installments.

Interest enters the replacement schedule under the loan’s configured progressive-schedule rules; there is no interest-strategy field. Forgiveness is never a re-age side effect—it is the separate interest waiver with its own approval and accounting.

Execute

Re-age is a governed native command. Human calls carry LendEasy-Case naming the open case when case management is enabled.

curl -X POST "$BASE/v1/loans/7204/transactions?command=reAge" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "LendEasy-Case: case_CEDAR_HARDSHIP_4" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: cedar-reage-2027-08-20" \
  -d '{
    "transactionDate": "2027-08-20",
    "startDate": "2027-09-15",
    "frequencyType": "months",
    "frequencyNumber": 1,
    "numberOfInstallments": 8,
    "note": "Affordable repayment arrangement per case plan.",
    "dateFormat": "yyyy-MM-dd",
    "locale": "en"
  }'

{
  "officeId": 1,
  "clientId": 412,
  "loanId": 7204,
  "resourceId": 30518,
  "changes": {
    "transactionDate": "2027-08-20",
    "startDate": "2027-09-15",
    "numberOfInstallments": 8
  }
}

There is no preview endpoint. Build the borrower-facing comparison from GET /v1/loans/7204?associations=repaymentSchedule,transactions and the loan summary before executing, and record it in the case. A lower installment can still increase total cost or extend the obligation materially—compare total payments, interest, maturity extension, and delinquency treatment, not just the new installment amount.

The second-person control

Re-age relies on maker-checker. A flagged command parks; a different user holding the checker permission reviews GET /v1/makercheckers and decides with POST /v1/makercheckers/{auditId}?command=approve|reject. Every execution writes a governance record at GET /v1/loans/7204/governance-records with the case context, actor, and route.

After execution

Re-read the schedule for the authoritative new period list, then invalidate stale payoff projections, regenerate future autopay targets, and preserve already-completed statements. The re-age transaction and the new schedule are the record; consumers should never reconstruct the schedule from the request they sent.

Undo and repeated re-aging

POST /v1/loans/7204/transactions?command=undoReAge is the compensating command. It restores the prior schedule and replays later transactions when deterministic; if later reschedules, disbursements, or other schedule-dependent activity prevents safe replay, the command is rejected with the blocking condition named.

Repeated re-aging replaces the prior remaining schedule; it must not accumulate duplicate stub periods. The schedule read always shows the complete resulting period list, making this invariant externally testable.

Use re-amortization when the original remaining dates and maturity should stay fixed.