Apply a servicing restriction

A restriction is a typed 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.

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.

Apply

Restrictions are customer-scoped resources; supply loanRef to scope one to a single loan. A human call carries LendEasy-Case naming an open case when case management is enabled; without it the call is rejected before execution.

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
}

The server derives the effective time—there is no effective-dating in the request. Applying an already-active restriction of the same type and scope is idempotent: the original record is returned rather than a duplicate created. source names the basis; the underlying evidence lives on the case.

Read

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"
    }
  ]
}

Cleared rows remain in the list with their clearedAt time. Active restrictions also appear in the loan summary’s activeRestrictions, but the summary is informative—enforcement points read current restrictions immediately before execution, so a cached UI badge is never authorization.

Clear

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; the server records who cleared it and when. The applied interval remains in history and governance records—apply and clear both write to the governance ledger, readable at GET /v1/customers/412/governance-records. An action blocked during the interval must be re-evaluated after clearing; it is not automatically released.

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.