Card operations are one of the clearest cases for letting an agent execute. Freezing a card, unfreezing one the customer froze, reissuing a lost card and updating card controls are routine, tightly bounded and mostly reversible. They suit depth 3: the agent acts within bounds and is corrected if wrong. The exceptions are specific, and knowing them is what makes depth 3 safe.
Why do card operations fit depth 3?
Depth measures how far an agent may act, per capability. Depth 3 means executing routine work within bounds, without a person approving each action. The test for depth 3 is whether the work is routine, well bounded, and cheap to correct if wrong.
Most card operations pass that test easily. A freeze can be lifted in seconds. A reissued card replaces one that was lost or damaged anyway. A change to a contactless or online spending control can be reversed by the customer in their app. Customers want these actions done at once, often at times when no person is available, and the cost of delay, such as a lost card used by a thief overnight, is usually larger than the cost of an occasional error.
So the case for depth 3 rests on a balance: low reversal cost on one side, real harm from delay on the other.
Which card operations fit, and which do not?
The detail matters. Several operations that look similar sit at different depths.
| Operation | Depth | Why |
|---|---|---|
| Temporarily freezing a card at the customer's request | 3 | Protective, instantly reversible, and urgent |
| Unfreezing a card the customer froze themselves | 3 | Restores the customer's own choice, after authentication |
| Unfreezing a card blocked by fraud controls | Person | The block exists because something looked wrong; lifting it is a fraud judgement |
| Reissuing a lost, stolen or damaged card | 3 | Routine, bounded by policy, and the old card is no longer usable anyway |
| Reissuing to a new address | Person, or 3 after verification | A classic route for takeover fraud |
| Adjusting card controls within the customer's own settings | 3 | The customer could do it themselves in the app |
| Raising a credit limit | Person, or 4 if earned | A credit decision with lasting effect |
| Deciding a chargeback or dispute outcome | Person | A judgement between the customer and a merchant |
Two rows deserve emphasis. Unfreezing after a fraud block looks like the mirror of freezing, and it is not. Freezing is protective; unfreezing a fraud block removes protection on the strength of the agent's view that the concern is resolved. The guidance on whether an AI agent can freeze a customer's card draws exactly this distinction.
Reissuing to a new address is the other. Ordering a replacement card to an address the bank has not previously verified is one of the most common account takeover patterns. The same capability, reissuing, sits at depth 3 for the address on file and needs a person or a verified change for anywhere else; see whether an AI agent can issue a replacement card.
What bounds keep depth 3 safe?
Depth 3 is not unlimited execution. It is execution inside bounds the platform enforces.
- Authentication. The customer has authenticated to the level the bank requires for that operation. Freezing may need little; reissuing more.
- Recent-change checks. Any recent change of contact details, address, device or phone number routes card reissues to a person.
- Rate limits. A customer reissuing several cards in a short period is unusual and should be held.
- Source checks. The instruction came from an authenticated channel, not an email or an unverified call.
- Card data handling. The agent never sees full card numbers or security codes; it works with tokens and references, in line with PCI DSS.
The fifth bound is often overlooked in early designs. An agent does not need card data to freeze or reissue a card, and giving it access expands PCI DSS scope for no benefit. The guide on connecting an AI agent to a card management system covers how to scope the integration.
Why start bank agents here?
Card operations make a good first case for agent execution in a bank. The volume is high, the rules are clear, customers notice the speed, and errors are cheap to put right. A bank that gets depth 3 working well for card operations builds the platform, controls and evidence it needs before moving to work where errors cost more.
The bank operations depth matrix places card operations alongside other bank work and shows how they compare.
Where does this go wrong?
The common failure is treating "card operations" as one capability and certifying it once. That lets fraud-block release and new-address reissue slip in alongside the routine freeze. Certify each operation separately, and the exceptions stay at their own depth.
The second failure is forgetting that depth 3 is earned, not assumed. Even routine operations should be replayed against the bank's own cases before an agent executes them, and the certificate should lapse and be renewed like any other.
Where Pryme fits
In Pryme, each card operation is its own capability with its own depth. An agent can hold depth 3 for freezes and same-address reissues while fraud-block release stays held for a person. Attest certifies each on your own cases, and the minimum chain checks authentication, recent changes and rate limits at the moment of action. See AI agents in banking: what they may and may not do.
Questions people ask
Can an agent cancel a card permanently?
Permanent cancellation usually goes with a reissue for a lost or stolen card, and suits depth 3 in that case. Cancelling a card the customer wants to close entirely is closer to an account change and may need more checks.
Should an agent tell customers which merchants used their card details?
It can list recent transactions and help identify ones the customer does not recognise. Deciding whether a transaction is fraudulent stays with the fraud team.
What if a customer freezes and unfreezes repeatedly?
It may be legitimate, or a sign of confusion or of someone else controlling the account. A rate limit that routes repeated changes to a person is a sensible bound.