LendEasy/DocsLMS + Servicing·v1
Start integrating
Guides›Servicing Workspace›Guardrails & approvals

Guardrails & approvals

Bounded discretion is written as policy the platform enforces, so an out-of-policy proposal reaches an approver with its evidence frozen — and a hard stop stays unapprovable.

Guardrails are what let the workforce agree terms with a borrower on the call without asking anybody, and send anything outside the lender’s written policy to a named approver with the evidence frozen. Without bounds there is no line an agent can be trusted up to; with an approval on every deviation the workforce stops at the first non-standard borrower. A guardrail is the line between them: written policy saying how far an otherwise permitted actor may go alone, and where the approval path begins. It never substitutes for permission, consent, compliance, fresh facts, or action eligibility.

The six layers an action must pass

        authenticated actor and permission
      + action capability
      + fresh subject facts
      + compliance eligibility
      + guardrail bounds
      + approval / separation of duties
      -----------------------------------
      = executable action

Each line is an independent test, and the action needs all of them. A permission proves who somebody is, not that the borrower may be contacted; a compliance pass proves the contact is allowed, not that these terms are within a supervisor’s discretion. Collapsing the stack into one answer is how a well-permissioned worker — agent or person — ends up agreeing a settlement nobody authorized.

Maya’s two installments, inside the bounds

Suppose the lender configures this illustrative early-collections policy. Each bound stops one specific thing: an unsupported long-horizon promise, an immaterial arrangement that suppresses work, a plan with too many parts to follow, and an arrangement that asks nothing of the borrower this week.

Out of bounds, the path is supervisor review, which preserves discretion with the evidence attached. Creating the promise does not move money either way: its outcome later derives from posted payment facts.

The approver accepts that exact request

An approval-bound request preserves normalized payload, financial/schedule preview, request hash, facts and versions, policy/guardrail result, evidence, creator, and expiry. Any material edit creates a new hash and requires a new decision — otherwise the terms an approver read and the terms that executed could differ by one date, and the approval record would still look clean.

Nobody approves their own request

The creator cannot approve their own request where separation applies. Eligibility also depends on role, amount/action threshold, legal entity, case type, and current delegation. Approver comments supplement a structured reason code rather than replacing it: a reason code can be counted, sampled, and compared across a quarter, and a paragraph cannot.

Which results an approval can change

Result Can ordinary approval change it?
Within guardrail No approval required unless another policy requires it.
Outside guardrail Yes, through the declared approval path.
Missing facts No; obtain or resolve facts first.
Non-overridable block No ordinary servicing override.
Exceptional policy route Only if the rule explicitly defines scope, authority, and evidence.

A screen can present a non-overridable block however it likes; the result is resolved by policy, and the button stays refused. What the interface calls a control is a design choice, and what the engine does with it is not.

Money still moves through its owning endpoint

Guardrails can bound refunds, fee adjustments, contact intensity, hardship offers, AI actions, and data exports. Contract changes and money movement still travel through the servicing or Lending Core endpoint that owns them. An allowed result executes there; only a genuine approval, deferred, manual, external, or unavailable result opens an action request.

Example bounds illustrate the policy model; they are not legal requirements or platform defaults. Configure product-, jurisdiction-, case-, and risk-specific values with approved governance.
Unified search across guides, recipes & the API referenceEsc