Skip to main content
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

ControlWhat it doesDefault
Total budgetHard ceiling on lifetime spend, allocated from the team/project budgetSet at agent creation
Per-payment limitMaximum amount for a single transactionNo limit
Daily spend limitMaximum total spend per rolling dayNo limit
Hourly velocityMaximum payments per hourPlatform default cap
Daily velocityMaximum payments per dayPlatform default cap
Approval thresholdAmount above which a human must approveEvery transaction requires approval until configured
Merchant allowlist / denylistRestrict which merchants the agent may pay — card rail onlyAll allowed unless listed
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.

​
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).