RFC: add payment.cumulative constraint for autonomous agent budgets

[swaroopt14]

Summary

This RFC proposes payment.cumulative as a new constraint type in the Verifiable Intent specification for autonomous mode (L3) execution. It enables users to cap total spending over a time period (e.g., $500/month), providing essential budget controls for delegated agent commerce.

Problem

Mastercard’s vision of agentic commerce empowers AI agents to execute payments on behalf of users. However, current constraints (e.g., payment.amount) validate each transaction in isolation. This creates a critical vulnerability: an agent can make many individually compliant transactions that collectively exceed the user’s intended budget over time.

Consider:

• A parent authorizes a shopping agent with a $300 monthly limit for sports equipment.
• The agent makes two purchases of $280 each – both pass the per‑transaction payment.amount check.
• The combined $560 violates the parent’s explicit monthly budget, leading to unexpected charges and potential disputes.

This is not just a theoretical gap. In family accounts, corporate procurement, and BNPL scenarios, users think in budgets (“don’t spend more than $500 this month”), not just per‑transaction caps. Without cumulative controls, agentic commerce cannot deliver the predictability and trust that Mastercard’s brand promises.

As Pablo Fourez noted: “When AI agents act with real money, consumers aren’t just looking for speed or convenience. They expect clarity about what was authorized, confidence that instructions were followed, and protection if something goes wrong.” Cumulative limits are foundational to that protection.

Proposed Constraint: payment.cumulative

Introduce a new constraint type that enforces a maximum total amount over a specified period.

Schema:

{
  "type": "payment.cumulative",
  "max_total": 50000,          // amount in minor units (e.g., cents)
  "currency": "USD",
  "period": "MONTHLY",          // DAILY, WEEKLY, MONTHLY, YEARLY, or CUSTOM with period_seconds
  "reset_mode": "ROLLING"       // optional, default ROLLING; CALENDAR also supported
}