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:
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:
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:
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:
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 for how the synchronous request and response with your endpoint work, including the one-second default timeout and the required fallback_result.
Use the Spend Controls guide for rule configuration, business-wide rules, and worked examples of attaching controls.