> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reinx.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Spending Policies

> How Reinx enforces spending rules on every transaction

Every agent has a spending policy — a set of rules evaluated on every payment attempt, enforced by Reinx's infrastructure rather than by the agent's code. An agent can read its own policy (via the `get_spending_rules` MCP tool) but can never modify or bypass it.

## The policy engine

Each payment request passes through a staged evaluation pipeline before any money moves:

1. **Identity** — Is the API key valid, unrevoked, and scoped to this agent?
2. **Budget** — Do the agent, its team, and its project all have sufficient remaining budget? Budgets are checked and reserved atomically, so concurrent requests can't overspend.
3. **Velocity** — Has the agent exceeded its hourly or daily transaction-count limits?
4. **Merchant rules** — On the card rail, is the merchant allowed by the agent's MCC and merchant allow/deny lists? On the wallet rail, the recipient address is validated per chain (checksum, format, supported network) instead — there is no per-recipient allowlist for wallets today.
5. **Approval threshold** — Is the amount above the auto-approval threshold? If so, the request routes to a human instead of executing.
6. **Anomaly checks** — Suspicious acceleration (e.g. hitting a daily velocity limit within a fraction of the day) flags the transaction for review.

A denial at any stage stops the payment and returns a structured denial reason to the agent.

## Policy controls

| Control                       | What it does                                                           | Default                                              |
| ----------------------------- | ---------------------------------------------------------------------- | ---------------------------------------------------- |
| Total budget                  | Hard ceiling on lifetime spend, allocated from the team/project budget | Set at agent creation                                |
| Per-payment limit             | Maximum amount for a single transaction                                | No limit                                             |
| Daily spend limit             | Maximum total spend per rolling day                                    | No limit                                             |
| Hourly velocity               | Maximum payments per hour                                              | Platform default cap                                 |
| Daily velocity                | Maximum payments per day                                               | Platform default cap                                 |
| Approval threshold            | Amount above which a human must approve                                | Every transaction requires approval until configured |
| Merchant allowlist / denylist | Restrict which merchants the agent may pay — **card rail only**        | All allowed unless listed                            |

<Note>
  The approval threshold has three modes: **every transaction** requires approval (threshold 0),
  **above a set amount** requires approval, or **never** — payments auto-approve within budget. Even
  in "never" mode, the total budget remains a hard ceiling and anomaly flags still route to human
  review.
</Note>

## Budget hierarchy

Budgets cascade: **project → team → agent**. An agent's allocation is reserved from its team's budget, which is reserved from its project's. A payment must fit within all three levels simultaneously — increasing one agent's budget never lets the project overspend. The organization's treasury is the funding source those project budgets draw from, not a fourth enforcement tier.

## Changing a policy

Policies are managed by humans in the dashboard (or via the API with an authenticated user session). Changes take effect immediately — there is no propagation delay on the payment path. Budget and threshold changes require step-up authentication (a fresh passkey or TOTP verification).