Apply a servicing restriction

Apply or clear a named hold over payments, autopay, funding, collections, or communication—customer- or loan-scoped—without changing the loan lifecycle state.

A restriction is a named hold applied to a customer, optionally scoped to one loan. Each type has fixed semantics enforced at execution time; bankruptcy stay, cease communication, suspected fraud, and legal protection each map to the types they need.

A named hold, not a loan status

CommandPOST /v1/customers/{customerId}/restrictions

Case contextRequired on human calls

ApprovalThe case supplies the basis; source names it on the record

Ledger effectNone — enforcement lands on actions, never on balances

UndoPOST …/restrictions/{restrictionId}/clear

Applied at once, cleared explicitly

Hold appliedno effective-dating in the requesta person
Enforced at executionread immediately before each actionautomatic
Clearedthe server records who and whena person
Re-evaluatedblocked actions are not auto-releaseda person

The applied interval stays in the list with its clearedAt time, so a hold that once held never reads as though it never did.

Restriction types

Type	What it blocks or changes
`PAYMENT_HOLD`	Blocks payment creation against affected loans.
`AUTOPAY_HOLD`	Pauses affected autopay enrollments in the same transaction.
`DISBURSEMENT_HOLD`	Blocks funding creation—disbursements and refunds alike.
`COLLECTIONS_HOLD`	Suspends collections activity and pauses affected autopay enrollments.
`COMMUNICATION_HOLD`	Blocks outbound servicing communications.
`SCRA_MLA_PROTECTED`	Marks verified servicemember protection; affected actions route to manual handling.

Several restrictions can be active at once; every enforcement point honors all of them, and the most protective outcome wins. Compose broader situations from the types—a bankruptcy stay is typically COLLECTIONS_HOLD plus COMMUNICATION_HOLD, with PAYMENT_HOLD only where policy pauses voluntary payments too.

The server derives the effective time

Restrictions are customer-scoped resources; supply loanRef to scope one to a single loan. There is no effective-dating in the request.

curl -X POST "$BASE/v1/customers/412/restrictions" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "LendEasy-Case: case_HBR_BANKRUPTCY_3" \
  -H "Content-Type: application/json" \
  -d '{
    "restrictionType": "PAYMENT_HOLD",
    "loanRef": "7204",
    "source": "bankruptcy-notice-91"
  }'

{
  "resourceId": 41
}

Applying an already-active restriction of the same type and scope is idempotent: the original record is returned rather than a duplicate created. The underlying evidence lives on the case.

A cached badge is never authorization

curl "$BASE/v1/customers/412/restrictions" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender"

{
  "items": [
    {
      "restrictionId": 41,
      "restrictionType": "PAYMENT_HOLD",
      "loanRef": "7204",
      "active": true,
      "source": "case:case_HBR_BANKRUPTCY_3",
      "effectiveAt": "2027-06-03T14:00:00Z"
    }
  ]
}

Active restrictions also appear in the loan summary’s activeRestrictions, but the summary is informative, never authorization.

Clearing does not release blocked actions

curl -X POST "$BASE/v1/customers/412/restrictions/41/clear" \
  -H "Authorization: Bearer $TOKEN" \
  -H "LendEasy-Tenant: demo-lender" \
  -H "LendEasy-Case: case_HBR_BANKRUPTCY_3"

Clearing takes no body. Apply and clear both write to the governance ledger, readable at GET /v1/customers/412/governance-records.

A restriction applied in error is cleared, not deleted

Clearing is the correction: enforcement stops at the next check. A restriction cleared by mistake is applied again as a new record with its own source and case.

Restriction is not loan status

The loan can remain ACTIVE while payments or communications are held. Keeping the models separate preserves accurate balances and prevents clearing a restriction from accidentally activating a closed or terminated loan.