> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.thepennyinc.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.thepennyinc.com/_mcp/server.

# Spend Controls

Spend Controls define rules that Penny can evaluate when deciding whether activity is permitted.

## Spend Controls

A **Spend Control** is a reusable set of authorization rules and configuration.

Depending on the supported resource type, a Spend Control can be associated with resources such as:

* [Cards](/get-started/platform-concepts/issuing-cards);
* [Cardholders](/get-started/platform-concepts/issuing-cards);
* [Capital and Control Accounts](/get-started/platform-concepts/banking-accounts);
* [Programs](/get-started/platform-concepts/programs);
* [Business Entities](/get-started/platform-concepts/business-access);
* [Businesses](/get-started/platform-concepts/business-access);

This allows controls to be applied at different points in the spending model, from the narrowest control surface (a single Card) up to the broadest (the whole Business).

**What it's for:** a single named rule set you can share across many objects — assign the same `spend_control_id` to ten cards, and updating the control updates the limit for all ten at once, instead of editing each card individually.

**How it behaves:** each Spend Control is made of one or more rules, and each rule is a `rule_type` plus a typed `configuration` whose shape depends on that type:

| Rule type            | Controls                                                                                                                                                          |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `transaction_amount` | Minimum and/or maximum amount per transaction                                                                                                                     |
| `velocity`           | Count or amount limits per calendar hour, day, week, month, quarter, or year (UTC), or over the rule's lifetime                                                   |
| `merchant`           | Allowed or blocked merchant IDs, categories, and names                                                                                                            |
| `geographic`         | Allowed or blocked merchant countries, subdivisions, and postal codes                                                                                             |
| `currency`           | Allowed or blocked transaction currencies                                                                                                                         |
| `processing`         | Allowed or blocked PAN entry modes                                                                                                                                |
| `live_decisioning`   | A real-time approve or decline decision from your own endpoint; see [Live Decisioning](/platform/webhooks-live-decisioning) for the request and response contract |

Fetch the configuration schema and an example for any rule type with `GET /spend_controls/rule_types` before building against it. Each rule must explicitly list its `applicable_transaction_authorizations` and `applicable_card_issuance_modes` (`managed`). Spend control responses return the configured rules in a `rules` array, with each rule's fields on the rule object.

A Spend Control Association attaches a control to a resource. Each attachment point takes a body of `{ "spend_control_id": "..." }` on `PUT`, and is removed with the matching `DELETE`:

| Attach to       | Endpoint                                           | API           |
| --------------- | -------------------------------------------------- | ------------- |
| Card            | `PUT /cards/{card_id}/spend_control`               | Penny Issuing |
| Cardholder      | `PUT /cardholders/{cardholder_id}/spend_control`   | Penny Issuing |
| Capital Account | `PUT /accounts/capital/{account_id}/spend_control` | Penny Banking |
| Control Account | `PUT /accounts/control/{account_id}/spend_control` | Penny Banking |
| Business        | `PUT /businesses/spend_control`                    | Penny Banking |

A resource has at most one Spend Control attached; attaching another replaces it. Use `GET /spend_controls/{spend_control_id}/associations` on Penny Banking to list the objects a control is attached to.

## Multiple applicable controls

More than one Spend Control may apply to the same authorization.

For example, a card may be subject to its own control and to controls attached to its cardholder, its funding account, its Program, its Business Entity, and the Business.

When multiple Spend Controls apply, Penny checks every one of them, from the smallest control surface to the largest:

```
Card → Cardholder → Control Account (if present) → Capital Account → Program → Business Entity → Business
```

When a card uses a Control Account, its attached control is checked at the narrower Control Account level, and the funding Capital Account's control is checked at the broader level. Both apply when both are attached. Without a Control Account, the Capital Account level still applies.

Every rule in every attached control must pass for the transaction to be approved. A control at any level can decline the authorization on its own, and no level overrides another, so when two controls set the same kind of limit, the most restrictive one determines the outcome. For example, a \$500 per-transaction limit on a card and a \$200 per-transaction limit on its cardholder together decline anything over \$200.

**Exception: live decisioning.** A `live_decisioning` rule runs once per authorization, at the most specific level where one is attached. A matching rule at a broader level is skipped, not evaluated in addition to it. For example, if both a Cardholder and its Business have a `live_decisioning` rule, only the Cardholder's rule is followed. See [Live Decisioning](/platform/webhooks-live-decisioning) for how the synchronous request and response with your endpoint work, including the one-second default timeout and the required `fallback_result`.

> **Info**
>
> Use the Spend Controls guide for rule configuration, business-wide rules, and worked examples of attaching controls.

## Related concepts

* [Spend Controls](/spend-controls)
* [Setting Spend Controls](/spend-controls/setting-spend-controls)
* [Banking & Accounts](/get-started/platform-concepts/banking-accounts)
* [Issuing & Cards](/get-started/platform-concepts/issuing-cards)
* [Programs](/get-started/platform-concepts/programs)