Your supplier wants to be paid in Singapore. Payroll is tomorrow. Some of your cash is in the wrong currency.
Now imagine giving your business account one instruction:
“Pay the supplier. Protect payroll. Keep the rest working within my limits.”
An agent could work through the steps: check obligations, choose an authorised payment route, track settlement and update the books. Eligible surplus could move into a tokenised investment, subject to a separate mandate and its redemption terms.
That is the banking experience I would like to explore.
I narrowed our research to five integrations I would try first: an account that acts, smarter payment routing, tokenised treasury, portable permissions and reconciliation.
Each comes with a working browser prototype: change the inputs, trigger a failure and inspect the result. The five demos use fictional data and deterministic rules. They show proposed integration behaviour, with no live bank, AI model or blockchain connected.
Start with the product experience: give a business account one instruction and follow it through payment, treasury and the books → Then change the situation: make the provider go silent or revoke the agent’s authority. The walkthrough connects the five capabilities; the individual labs below let you inspect each one.
The shortlist reflects editorial judgement; the integrations are hypotheses to validate. Pick the problem closest to your product and try its experiment.
1.Give a bank account a job to do
The scene: a business owner approves a supplier payment while keeping tomorrow’s payroll protected.
The agent reads upcoming obligations from the banking platform. It reserves the money, checks the recipient and prepares an allowed route. A connected stablecoin provider could handle an eligible cross-border leg; the bank account remains the place where the customer sees what happened.
The exciting part is the continuity. The customer gives a financial instruction and can follow it all the way to a recorded outcome.
First experiment: one fictional business, one approved supplier and one payment route. Test success, a revoked mandate and a provider timeout.
The hard part: permission to prepare a payment, permission to execute it and confirmation of final settlement need distinct states.
Coinbase’s Agentic Wallets provide a component to investigate. A real bank-connected product still requires the relevant institutions, providers and approvals.
Try the prototype: Agent-operated account controls →
Run the default instruction, then choose “Provider times out after submission.” The $12,025 stays reserved. Deliver the completion receipt and watch the account update. Deliver it again: the debit stays single.
Developer takeaway: separate planning, policy checks, reservations and settlement. A model-generated instruction should pass deterministic controls before it touches an execution adapter.
2.Let a payment find its best available route
Illustrative routes. Costs and times are fictional demo assumptions, not provider quotes.
The scene: the supplier needs local currency, and the sender wants to know the total cost before approving.
An agent compares the routes actually available to that customer: a bank transfer, a stablecoin settlement service or another supported provider. It checks fees, FX, delivery conditions and recipient payout before presenting a choice.
Web3 contributes an additional settlement path. Its value depends on the full journey, including conversion and the final payout.
First experiment: compare one bank route and one supported stablecoin corridor using timestamped quotes. Let the user set a maximum cost and a delivery deadline.
The hard part: a confirmed blockchain transaction can still leave a fiat payout pending. The product should show both.
Circle’s CPN Managed Payments is one provider proposition to evaluate. Corridor access and onboarding determine what a pilot can actually use.
Try the prototype: Payment Route Lab →
For a fictional $10,000 payout, compare a $65 bank-route fee with $40 for a stablecoin route including conversion and payout. Set a four-hour deadline, then make the stablecoin corridor unavailable. The result becomes “No eligible route” instead of recommending a transfer that misses the deadline.
Developer takeaway: route selection needs all-in quotes, expiry, corridor eligibility and payout timing. The demo ranks eligible routes by cost; actual provider quotes and execution are separate integrations.
3.Put eligible surplus to work while protecting payroll
The scene: a business has surplus cash today and a large obligation next week.
A treasury agent forecasts the cash needed for approved obligations. Within an explicit investment mandate, it could prepare an allocation to an eligible tokenised fund, then monitor when that position can be redeemed.
The useful question is concrete: can the business get its money back in time?
First experiment: simulate a cash reserve and one fictional fund with explicit redemption windows. Move an invoice forward and see whether the proposed allocation still makes sense.
The hard part: investment eligibility, losses, fees, market hours and redemption delays all belong in the decision. A token does not make the underlying asset instantly liquid.
Franklin Templeton and MoonPay’s institutional integration announcement provides a distribution example to investigate. Actual access and product terms require verification.
Try the prototype: Treasury Liquidity Lab →
Start with $100,000, protect $40,000 for payroll and request a $30,000 allocation. An additional $40,000 bill is coming. Move its deadline from 96 to 48 hours while assumed redemption takes 72 hours: the permitted allocation drops to $20,000 so the bill stays covered in cash.
Developer takeaway: model available cash against obligations and redemption constraints. The demo treats redemption timing as an assumption; a real product must account for uncertainty, holidays, losses and provider limits.
4.Make the agent’s permissions follow the money
The scene: an agent can pay an approved supplier up to a daily limit. Halfway through the workflow, the owner revokes that authority.
Every execution point needs to know.
A bank-to-wallet integration could carry the customer’s mandate into enforceable controls: permitted recipients, assets, amounts and expiry. Before an external action, the system checks whether the authority still holds.
This is where a convenient assistant becomes a financial tool a team can reason about.
First experiment: run the same payment with valid, expired and revoked permission. Add a second agent and check the shared budget.
The hard part: a signed instruction needs enforcement at the actual execution boundary. The design must explain what happens to transactions already submitted when permission changes.
Google’s AP2 announcement offers a useful mandate vocabulary. Extending it across bank and onchain execution remains an integration design to test.
Try the prototype: Agent Permission Lab →
The default $12,000 request fits a $20,000 daily limit after $5,000 of prior spending and a $25 fee. Revoke the mandate, change the recipient or increase shared spend. Each condition can block a new submission. Mark the payment as already submitted to see the recovery boundary: revocation cannot reverse a settled transfer.
Developer takeaway: enforce permissions at execution time and reserve shared budgets atomically. A signed mandate alone cannot prevent two agents from racing to spend the same allowance.
5.Follow every payment all the way into the books
The scene: the payment provider times out. Someone clicks again. Later, two identical completion receipts arrive.
Did the business pay once or twice? Which amount is still reserved? What should the account display?
A reconciliation layer connects the bank instruction, provider request, onchain transaction and payout receipt. An agent can help investigate discrepancies while deterministic rules control posting and duplicate handling.
The customer gets a readable answer. Operations gets the evidence behind it.
First experiment: send a simulated payment, delay its receipt and deliver that receipt twice. The ledger should record one completed payment.
The hard part: defining which evidence is authoritative at each stage and routing unresolved exceptions to a person.
An API-first, event-sourced core such as SaaScada’s platform is a useful starting point to evaluate. This proposal describes a possible integration; our demo has no connection to SaaScada.
Try the prototype: Receipt Reconciliation Lab →
Deliver a timeout, a receipt with the wrong amount, a valid completion and another completion with a different receipt ID. The reservation survives uncertainty, the mismatch goes to the exception trail, and the same payment produces one debit.
Developer takeaway: match payment identity and amount before posting. Deduplicate by the settled payment as well as receipt identity; two webhook IDs can describe one economic event. Production needs authenticated events, durable storage and atomic posting.
Try the complete account journey
We built Agentic Bank Lab to make that last scenario tangible.
Start with a fictional $100,000 business account. Protect $40,000 for payroll, pay an approved $12,000 invoice plus a simulated $25 fee, then consider allocating $30,000 to a fictional eligible fund.
Make the payment provider time out.
The money stays reserved while the outcome is uncertain.
Deliver the completion receipt. Then deliver it again. Watch how the account handles the duplicate.
You can also revoke the mandate or make the fund reference stale. Each change shows a different boundary the integration has to handle.
All balances, providers, receipts and fund values are fictional. The browser demo uses deterministic logic, with no live AI model, bank, custody service or blockchain connected. It calculates no investment return and has not been audited.
Pick one workflow to try first
The agent-operated account is the bigger vision. A scoped payment-and-reconciliation workflow gives a team a concrete first slice to build and evaluate.
Choose one customer job, one route and clear failure cases. Measure whether the records reconcile, whether permission checks hold and how many exceptions need manual intervention.
The research snapshot behind this shortlist is dated 17 September 2026. Linked sources describe building blocks and provider propositions; the five combinations are our hypotheses.
Which of these would make the biggest difference to your customers?
Tell us which workflow you would try first and where your team gets stuck. We can explore the architecture, dependencies and a focused first experiment together.