Promise-to-pay · LendEasy Docs

Capture a specific borrower commitment, approve out-of-policy terms, suppress redundant outreach, and evaluate the promise against posted payment facts.

A promise-to-pay is a structured commitment with covered debt, amounts, dates, guardrail decision, and evaluation state. It is never just a case note, and creating it does not move money.

Lifecycle

LifecyclePromise-to-pay

PROPOSEDterms captured

ACTIVEapproved and in force

KEPTposted payments satisfy terms

PROPOSED→APPROVAL_REQUIREDterms exceed a configured guardrail

APPROVAL_REQUIRED→ACTIVEauthorized checker approves

APPROVAL_REQUIRED→REJECTEDchecker declines with reason

ACTIVE→PARTIALLY_KEPTsome but not all covered amount posts

ACTIVE→BROKENevaluation time passes unsatisfied

ACTIVE→CANCELLEDborrower withdraws or terms are superseded

A revised promise supersedes the prior version. It does not edit the original terms or their approval history.

Harbor commitment

On May 1, Harbor is 22 days past due for $517.14. Maya commits to pay $260 on May 8 and $257.14 on May 22.

POST /v1/servicing/cases/case_HBR_COL_51/promises
Idempotency-Key: harbor-promise-2027-05-01-v1

{
  "loanId": "7204",
  "commitments": [
    { "amount": "260.00", "dueDate": "2027-05-08" },
    { "amount": "257.14", "dueDate": "2027-05-22" }
  ],
  "sourceInteractionId": "int_HBR_CALL_91",
  "borrowerConfirmedAt": "2027-05-01T10:18:42-07:00"
}

The response explains each guardrail tested: maximum horizon, minimum covered percentage, installment count, first-payment timing, and any product-specific rule. It returns ACTIVE only if terms are inside policy or already approved.

Money movement is separate

A promise can optionally reference future payment instructions, but it does not authorize a debit. Each later payment must have its own valid authorization and follow the payment lifecycle. This separation allows a borrower to keep a promise through the portal, ACH, card, lockbox, or another posted source.

Evaluation rules

Evaluation uses posted, value-dated payment facts from the authoritative system. The policy defines:

which loan and transaction types count;
whether early payments count and how they map to installments;
grace time and the evaluation timezone;
how reversals and returns reopen a result; and
whether one payment can satisfy more than one promise.

For Harbor, if $260 posts effective May 8 and $257.14 posts effective May 22, the promise becomes KEPT. If the second ACH is processing on May 22, evaluation remains pending under the covering-payment policy; it does not prematurely mark kept. If that debit later returns, the prior evaluation is reversed with a linked event and follow-up work opens.

Outreach suppression

An active promise can suppress redundant collection outreach for the covered debt and interval. Required notices, borrower-initiated responses, unrelated obligations, and legally permitted exceptions remain separately evaluated. Suppression exposes its source promise and expiry so a worker knows why a channel is unavailable.

Revision and cancellation

Revision creates a new promise version and re-runs guardrails. The prior version becomes SUPERSEDED; payments already credited to it remain visible. Cancellation requires actor, reason, borrower request or policy basis, and effective time. A broken promise is not cancelled merely to improve performance reporting.

Reporting measures

Track created, approved, kept, partially kept, broken, cancelled, and superseded promises by terms and segment. Keep “kept at first evaluation” distinct from “later reversed after payment return,” and measure outreach suppressed without conflating it with successful payment.

Guardrail defaults shown in a tenant configuration are product policy, not universal legal rules. The API returns the exact policy version and rule results applied to every promise.