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

# Budgets

> How agents are pre-authorized to spend on the crypto rail.

A **budget** is a pre-authorized USD spend limit for crypto payments. It is
the spend control on the crypto rail; linked-card purchases use per-purchase
passkey approval instead and are covered separately.

A budget exposes a spend limit to the agent. Every budget references one
[account](/agentic-banking/concepts/accounts) — the funding pool the spend draws against —
but the agent only ever sees the limit, not the account's balance.

## What an org admin configures today

The org settings page exposes one budget per network the org runs on
(typically mainnet and/or testnet). Each budget is **org-wide**: it applies
to every member of the org, and each member gets their own independent USD
cap. The fields the admin sets are:

* **Name** — a label (e.g., "Research travel").
* **Cap (USD)** — the per-member limit.
* **Merchant scope** — either **all merchants** (every merchant Anchorage has
  screened and promoted to Active) or a **specific allowlist** picked from
  the merchant catalog. {/* req: policies/merchant-rules.md#1, #2 */}

That's the full set of pilot configuration. The underlying model supports
period rollover, parent/child cascades, and per-agent or shared-pool
variants; those will reach the org-settings UI in later releases.

## Period

Pilot budgets are **fixed**: spend accumulates against the cap until the
admin raises it. Daily, weekly, and monthly calendar-period caps are on the
roadmap.

## States and actions

Each budget is in one of three states; the admin can transition between them
from the org settings page:

| State   | Meaning                              | Available actions   |
| ------- | ------------------------------------ | ------------------- |
| Active  | Budget admits payments under the cap | Edit, Pause, Revoke |
| Paused  | Budget rejects all payments          | Resume, Revoke      |
| Revoked | Budget is permanently disabled       | (none)              |

## Two gates per payment

Every crypto payment runs through two distinct gates:

1. **Compliance gate** — the merchant must be Active and on the budget's
   allowlist. A failure here is a hard reject with no approval path.
   {/* req: policies/merchant-rules.md#3, #20 */}
2. **Spending gate** — the requested amount, plus existing holds, must fit
   inside the cap. See [Approvals](/agentic-banking/concepts/payments#approvals) for what
   happens when a payment crosses the cap.
   {/* req: policies/approval-flows.md#1 */}

## What the agent sees

Through MCP, the agent reads its own allotted cap, its spend-to-date, and the
merchant allowlist that applies to it. The agent's view is scoped to its own
slice.

## What the org member sees

A member's profile page in the web UI shows their own slice of each org
budget — the cap, the merchants admitted, and a progress bar for spend-to-date.
Each member's view stays scoped to their own slice.