It can apply them and lower them, but not raise them on its own. An AI agent can set a merchant's starting limits from the payments company's policy table, and lower limits when a defined risk trigger fires, at depth 3. Raising limits, temporary increases and any change for a merchant under investigation stay with a named person.
Why are limits asymmetric?
A merchant's limits cap the payments company's exposure. The higher the limit, the more card payments the merchant can take before anyone looks, and the larger the loss if the merchant fails, commits fraud or cannot cover its chargebacks. Raising a limit is therefore a decision to take on more risk, much like extending credit. It needs someone who answers for that risk.
Lowering a limit reduces exposure, which is why the agent can do it under rules. But it is not free. A merchant whose limit drops in the middle of a busy week loses sales, and may lose customers. So lowering is allowed only on triggers the policy defines, with notice to the merchant and a person reviewing soon after, the same discipline as any protective action that harms someone if it is wrong.
What conditions decide it?
Starting limits are set at activation from the policy table, by category, business size and onboarding risk rating. The agent applies the table; it does not choose numbers.
Lowering is allowed when a trigger in the risk policy fires: chargebacks above a set level, a sudden change in average transaction size, a surge in card-not-present sales from a business that normally sells in person, or a refund rate far above normal. Each trigger names the limit it affects and by how much.
Raising always needs a person, who looks at the merchant's history, financial strength, chargeback record and the reason for the request.
What may the agent do, and where must it stop?
| Change | The agent | Where it stops |
|---|---|---|
| Starting limits at activation | Applies the policy table, depth 3 | Merchants outside the table |
| Lowering on a defined trigger | Lowers as the policy specifies, depth 3 | Triggers the policy does not define |
| Notifying the merchant | Sends the approved notice | Wording where fraud is suspected |
| Restoring a lowered limit | Prepares the review | A person decides |
| Raising a limit | Prepares the case with history and exposure | A person decides |
| Temporary increase for a planned event | Prepares the request | A person approves the amount and dates |
| Refund limits | Applies them like other limits | Changes to the refund policy |
Refund limits deserve particular care, because large refunds can be used to move money out; see how to set refund limits for an AI agent. Starting limits are first set during merchant onboarding for card acquiring.
An example: a sale event and a sudden surge
Take an online clothing retailer with a monthly processing limit of 50,000 and an average order of about 60. It asks for a temporary increase to 120,000 for a two-week sale it has promoted widely.
The agent prepares the request for the risk team: two years of history, a low chargeback rate, refunds within normal range, payouts to the same verified account throughout, and the merchant's marketing for the sale. It does not approve anything. A person approves a temporary limit of 100,000 for the two weeks, and the agent applies it on the dates set.
A month later, a different merchant on the same platform, a café that usually takes in-person payments of around 10, suddenly processes dozens of online payments of 400 each. That pattern is a trigger in the policy. The agent lowers the café's card-not-present limit to the policy's floor, sends the approved notice, and opens a case. A person on the risk team calls the café the same day.
What controls make it safe?
- Limits from the policy table. Starting values and trigger-based reductions are read from sealed policy, versioned.
- No raise capability. The agent prepares increases; a person applies them.
- Notice and review on every reduction. Each lowered limit has a named reviewer and a review deadline.
- Monitoring linked to triggers. The triggers draw on the same signals as transaction monitoring, so the merchant sees one consistent set of rules.
- Every change filed. The old limit, the new limit, the trigger and the deciding bound are recorded together.
Limits also shape payouts: a merchant processing above its limits should not see payouts released as normal, as covered in whether an AI agent can issue a payout to a merchant. The general limits are in AI agents in banking: what they may and may not do.
Questions people ask
Can the agent raise limits automatically for merchants with good history?
Only if the payments company has written a rule that does exactly that, approved by the people who own the risk, with a ceiling. Without such a rule, every increase needs a person.
What happens to payments above the limit?
They are usually declined or held, depending on the setup. The agent can explain this to the merchant and help them request a review.
Can a merchant appeal a lowered limit?
Yes. The agent records the merchant's explanation and attaches it to the case for the reviewer.