Payment reversal is where the difference between a limitation and a decision becomes concrete, so it is worth walking through the three rails an agent might execute on and what each actually permits.

Open banking

A push payment initiated from the customer’s own bank. Once it settles it is gone. There is no reversal primitive; there is a return request, which is a new payment the receiving party has to agree to make. An agent that offered to “undo” one would be describing something that does not exist.

A tenant’s own core

For customers who are themselves banks, the payment executes inside their core. Reversal exists as an operations procedure, performed by their team, subject to their controls. It is not an API call an agent has access to, and we do not ask for one.

First-party balances

This is the interesting one. When both accounts sit on our own rail, a reversal is a database write. We could perform it. Nothing technical stands in the way.

We withhold it anyway, at the platform floor, for every agent at every depth.

Why the difference has to be visible

A capability table that renders all three as “not available” is lying by omission about the third. Anyone reading it forms the impression that reversal is universally impossible, and then encounters an operations team that reverses things routinely, and concludes the governance surface does not reflect reality.

So the third case reads as withheld rather than unheld: it exists, it works, and it is refused on purpose. Granting it would not be a settings change; it would require the reason to stop being true. The three-state model exists largely because of cases like this one.

What the agent says instead

“I cannot reverse a settled payment. What I can do is raise a return request to the receiving institution and flag this to your operations team, who can reverse it internally if both accounts are on our rail.” That answer takes longer to write and is the only version that leaves the person able to act.