Your AI Agent Can Move Money. Can You Actually Control It?

Emily Jones · 2026-11-10

AI agents used to just suggest financial actions. Now they execute them. They reconcile invoices, kick off procurement workflows, talk to APIs, and increasingly send payments under conditions you've predefined. So the instruction to move money might not come from a person at a screen anymore. It comes from software acting on delegated authority. For the payments world, that's not just a speed boost. It changes how we think about accountability. Compliance has always leaned hard on identity. Who's the customer? Who's the business? Who ultimately owns or controls it? Those questions still matter. But with agentic payments, identity alone doesn't cut it. An agent can be perfectly identified and still trigger the wrong transaction, in the wrong context, at the wrong time. That's why the industry needs to move past "Know Your Agent" and start asking something bigger: can you govern your agent? Knowing who an agent belongs to solves an identity problem. What actually drives risk is authority. What's the agent allowed to do? Under what conditions? For how long? When does that authority stop, and who stays accountable when it acts? The next version of KYA shouldn't be a machine copy of KYC. It should be a control framework built around delegated authority, continuously tying business intent, agent authority, and financial execution together. ### Bind the Agent to an Accountable Principal The first step is still identity, but the goal isn't to give AI its own financial identity. It's the opposite. Any agent that can initiate financial actions should be tied to a real business principal that's already cleared the right KYB, risk assessment, and due diligence. The infrastructure should be able to show which business account the agent represents, who created and authorized it, which credentials it's using, and whether that authorization is still valid. That relationship has to be both technically verifiable and auditable. Financial institutions don't need to decide whether an AI is inherently trustworthy. They need a clear chain of accountability: Verified Business → Authorized Agent → Permitted Action → Transaction. Only when every link traces back to a real business principal and a valid authorization can machine behavior be governed inside a regulated financial environment. ### Define the Mandate, Not Just the Limit Real risk control starts with authority. Traditional payment systems lean on per-transaction limits, daily limits, account limits, and API permissions. Those static controls aren't enough for agentic payments. An agent shouldn't just get a spending ceiling. It should operate inside a clearly defined business mandate. Take a procurement agent. It might be authorized to pay suppliers, but only verified counterparties, against valid purchase orders or invoices, from designated accounts, using approved settlement assets and payment routes, and within set amount and time thresholds. A treasury agent might rebalance liquidity across predefined accounts but shouldn't be able to create new beneficiaries on its own. A payroll agent can pay registered employee accounts but shouldn't redirect funds to unrelated third-party addresses. So the key question isn't only "How much can this agent move?" It's also "Under what business context is this agent allowed to act?" Static limits restrict amounts. Context-bound authorization restricts behavior. For agentic payments, that second layer matters more. > "Limits tell you how much. Mandates tell you whether the agent should be acting at all." ### Every Transaction Must Prove Why It Was Allowed The third control layer is provability. Traditional payment logs usually tell you who paid, who received the funds, how much moved, when it happened, and what the final status was. That's fine for a world where a human clicked "send." But when software acts on delegated authority, a log of what happened isn't enough. You also need to show why it was permitted in the first place. That means capturing the mandate the agent was operating under, the business context that triggered the action, and the authorization that made it valid at that moment. Put simply, the record should answer not just "what happened" but "what allowed this to happen." Here's what a working control layer looks like in practice: - A verified business principal behind every agent - A mandate that defines context, counterparties, and thresholds, not just amounts - A verifiable authorization trail for every transaction - Continuous checks that authority is still valid when the agent acts - Clear accountability when something goes wrong None of this is about distrusting AI. It's about giving it a leash you can actually see and pull. Identity tells you who's acting. Governance tells you whether they should be. For B2B agentic payments, that's the layer the industry can't afford to skip.