Moving money with agents
When AI agents make financial decisions at machine speed, the underlying infrastructure needs to enforce authority just as quickly. Here’s how Lead is building the agentic control plane.
The promise of agentic finance is simple: software can do more than recommend what should happen with money. It can act.
An agent can pay an invoice when it comes due, fund a supplier, settle a purchase, or move money to complete a task without waiting for a human to click “approve.”
Gartner predicts that 90% of B2B buying will be AI agent intermediated by 2028. The shift is not just about faster payments. It changes who can exercise financial authority and how that authority is controlled.
“Agentic finance is not just a faster way to make a payment. It changes who can exercise financial authority and requires the financial system to make that authority specific, visible, and revocable,” said Jackie Reses, Lead co-founder and CEO. “The opportunity is to support what agents can do without treating autonomy as a blank check.”
For decades, payment systems have been built around a human initiating or approving a transaction. Agentic finance introduces a different model: a human or business grants authority, and software exercises it repeatedly within a defined mandate.
The question is no longer simply who is allowed to move money. It is what the agent can do, for whom, under which conditions, and who enforces those boundaries before the money moves.
Application-layer controls are necessary, but the strongest controls sit as close to the movement of money as possible. Lead operates at that layer, enforcing controls before a payment leaves the banking system rather than simply telling an application what it should or should not do.
“We view agentic finance as an engineering challenge, first and foremost,” said Ronak Vyas, Lead co-founder and CTO. “That’s why we put the solution in the infrastructure, not in the prompt. Each task gets its own account number; controls are defined by rail and enforced on every payment; and access can be revoked when the mandate ends. For agentic finance to scale safely, controls need to be machine-readable, interoperable, and portable across every system an agent touches.”
That makes Lead more than infrastructure that agents can transact through. It makes Lead part of the agentic control plane.
From human authorization to bounded authority
Giving software the ability to act exposes a gap in traditional authorization systems. Know Your Customer (KYC) processes and multifactor authentication were designed around human users who explicitly approve transactions.
Agent-initiated payments change that model altogether. A customer might authorize an agent to pay vendors or purchase inventory without approving every payment it makes along the way.
Builders therefore face a choice: give an agent a payment method backed by the company’s real limits, or put a person in front of every transaction and compromise the efficiency the agent was designed to deliver.
Agentic finance needs something in between: bounded spending authority.
Handing an agent a payment method should not mean handing it a blank check. With Lead, companies can give an agent authority scoped to a specific task, with transaction controls on different payment rails enforced by the bank.
A company can provision an account number for an agent or task, choose which payment rails it can use, control whether money can move in or out, restrict payments to approved counterparties, and shut access down when the task is complete.
Those boundaries do not exist only in the application’s instructions to the agent. They can be enforced at the banking layer.
What bounded authority can do
Here are some examples of controls and guardrails in action. Each of these uses the same building block – a scoped account number – and initiates payments out of it. What differs is the rail, the direction of money movement, and the counterparties the agent can reach. Lead can configure these controls around each client program’s unique mechanics, disclosure requirements, governance, and oversight.
Pay approved vendors
An agent can pay a set of approved vendors as invoices clear, without a person releasing each payment. Its account number sends wires only to counterparties on an allowlist, so any vendor not on that list cannot be paid, whatever the agent is asked to do. With banking controls in action, Lead can prevent that account number from reaching the unapproved counterparty. The agent has autonomy, but not unlimited authority.
Fund an agent for a specific task
An agent can be given a set amount of working capital for a specific task and spend only against approved destinations. Rather than exposing the company's primary operating account, the company can create an account number for the task and fund it internally. Other incoming payment rails can be turned off, and outgoing payments can be restricted to approved destinations. The agent only gets access to the money it needs, not all of the company's money. When the job is over, the account number can be deactivated or cancelled.
Pay recurring bills
An agent can keep recurring bills paid on time with a scoped account number and cancel it after use. Its account number sends ACH credits only to the billers on an allowlist, and accepts ACH debits only from approved originators, so an authorized biller can collect and nobody else can. This is the basic pattern behind agentic money movement: give software enough authority to complete the task, while keeping that authority narrow, observable, and revocable.
*Note: These examples are illustrative only. Existing and prospective Lead customers can contact the Lead team to explore a tailored agentic program.
Building agentic finance workflows with Lead
Lead’s APIs provide many of the primitives developers need to build this model.
Step 1. Create the entity the agent acts for
POST /v0/entities creates an individual or business entity for that customer.
This is an important starting point for agentic finance. The agent's authority traces back to a verified person or business on record with the bank, which means agent activity is always attributable to a known customer.
Step 2. Create an account number scoped to the task
POST /v1/account_number creates an account number on the underlying entity's account for the agent to transact with.
Create one account number per agent task or session. Each carries its own controls and can be cancelled once the work is done, which keeps an agent's authority narrow and specific to the job in front of it.
Step 3. Set the transaction controls
Controls are set per rail, under ach_controls, wire_controls, instant_payment_controls, and internal_transfer_controls. Each one governs two dimensions: which direction money can move, and which counterparties are reachable.
{
"account_id": "acct_...",
"entity_id": "ent_...",
"ach_controls": {
"incoming": {
"accept_credit": true,
"accept_debit": false,
"counterparty_filter": "reject_all"
},
"outgoing": {
"counterparty_filter": "allowlist_only",
"counterparty_account_numbers_allowlist": [
{
"type": "checking",
"account_number": "...",
"routing_number": "..."
}
]
}
}
}
For each rail and direction, you can accept all counterparties, restrict the agent to an approved list, or block them entirely. Set controls at creation, or update them with PATCH before the agent begins transacting.
Step 4. Pick the rail
The agent then transacts. Each payment references the account number it originates from, and the controls on that account number are what the payment is checked against.
Step 5. Turn off access when the task is done
Agent permissions should not outlive the mandate that created them. Once the task is complete, cancel the account number. Cancelling is permanent and the number is never reused. If you expect to use it again, you can deactivate and reactivate it as needed instead. The important point is that revocation is not merely an instruction sent to the model. Access to the financial infrastructure itself can be removed.
Independent controls at the banking layer
Agent programs will build controls into their own products. Lead adds a second, independent layer at the bank. Every payment Lead makes is evaluated against the defined limits, regardless of what the application requests.
An application can tell an agent to pay only approved vendors. Lead can independently enforce which counterparties an account number is capable of paying.
The application may determine that a payment is appropriate. The bank still applies regulatory screening and determines whether the payment can actually move.
Once intent shifts to money movement, Lead evaluates payments against account controls, available balances, and program-level limits, including applicable daily and monthly ceilings. Regulatory screening, including applicable sanctions screening, happens before funds move.
Today's capabilities are the first step. Companies can provide agentic finance offerings by assembling Lead's existing bank products and calling Lead's APIs while the agent transacts within scope. For programs offering agentic cards, Lead can also be the issuing bank with the same capabilities as a traditional card program.
The harder questions are ahead: How do you bind an agent and its activities to a verified human? How do you determine what it is allowed to do, understand its mandate, and revoke its permissions? How do you monitor and audit its actions?
“Know your customer” gave financial institutions a framework for establishing the identity behind financial activity. Agentic finance will increasingly require another layer: know your agent. KYA will not replace KYC. It will extend the chain of trust from a verified customer to the software acting on that customer’s behalf.
The exact standards are still taking shape as regulators, financial institutions, networks, technology companies, and customers work out what autonomous financial activity requires.
A trusted foundation for an agentic world
Agentic finance is not simply a new checkout experience or interface for an existing payment system. It changes who – or what – can exercise financial authority, how quickly that authority can be exercised, and how controls need to work.
The compliance standards that protect the financial system cannot disappear because the actor is software. They need to operate at software speed.
Lead has built its platform around that principle: programmable financial infrastructure paired with the compliance and regulatory foundation of a bank. As agentic finance develops, the controls will become more sophisticated, the forms of money agents interact with will expand, and the regulatory framework around them will mature.
But the basic architecture for agentic finance in financial services is already visible. An agent receives a mandate, exercises only the financial authority that mandate requires, operates within boundaries enforced as close to the money as possible, and has that authority revoked when the work is done. That is how agents move from recommending financial actions to executing them.
The interfaces may change. The need for a trusted money layer does not. Lead is building that layer.
