Agent refund threshold policy

The control gap

Routine customer remedies can remain fast while larger or unusual transfers retain financial review.

A useful refund policy considers more than amount. Include currency, cumulative refunds for the customer, original charge, refund reason, account risk flags, destination, and whether the request changes a previous decision. The USD 100 value in this template is deliberately illustrative; finance should set thresholds from observed loss and service-recovery patterns.

Approval should display the customer and charge context without exposing unnecessary payment data. After approval, execute only the amount and charge identifier reviewed. Store the payment provider's result beside the Endram decision so duplicate, partial, failed, and reversed refunds can be distinguished during reconciliation.

Normalize monetary values before comparison. Convert minor units deliberately, retain original currency, and avoid floating-point thresholds. If policy uses a reporting currency, bind the exchange-rate source and timestamp; otherwise an amount can move across the approval boundary because different services rounded or converted it differently.

Add velocity and relationship checks where loss patterns justify them. A series of individually small refunds, a refund to a changed destination, or an amount exceeding the captured charge should not evade review. These checks belong in deterministic request context and provider validation, not in an agent's subjective risk explanation.

Exercise partial refund, repeated idempotency key, already-refunded charge, dispute, provider timeout, and webhook reordering. Financial evidence should reconcile requested, authorized, provider-accepted, settled, reversed, and failed states without storing card data or treating an HTTP timeout as proof that no money moved.

What good looks like

A narrow policy that can be tested in shadow mode, reviewed with owners, and promoted to enforcement with measurable impact.

• Match the concrete action "issue_refund" rather than every operation exposed by the tool.
• Scope the target to refunds above USD 100 and the production environment.
• Require a request-bound approval that expires and cannot be reused.
• Record denied attempts as well as approved executions.

A production workflow

1. Copy the template and replace example identities and resource selectors.
2. Run it in shadow mode against representative requests.
3. Review false positives, missing resource attributes, and approver routing.
4. Enable enforcement for one agent and expand only after reviewing the decision log.

A policy you can test

Agent refund threshold policy is a concrete starting point, not a claim that one generic rule fits every environment. Replace example identities and selectors, validate the request shape, and begin in shadow mode.

name: refund-threshold
match:
  action: issue_refund
  request.amount_usd: { greater_than: 100 }
decision: require_approval
approval:
  reviewers: ["finance-on-call"]
  expires_in: 20m

Endram keeps the policy version with every decision. A later change creates new evidence instead of rewriting why an earlier request was permitted.

Evidence to require

• Every attempted issue_refund, including denied requests.
• The exact refunds above USD 100 selector evaluated by policy.
• The requesting agent, delegated user, reviewer, and timestamps.
• Policy version, matched rule, decision reason, and execution result.

Buyer checklist

• Does the selector cover only the intended production resources?
• Who owns the approval queue outside business hours?
• What is the acceptable approval expiry?
• Which emergency identity may bypass the rule, and how is that use audited?