Broad tokens, narrow intent
An OAuth scope or an API key in a prompt grants far more than the one payment the customer had in mind.
Agent-native infrastructure for open finance
Let agents act on money,
within a mandate you can prove.
Every agent action is identified, checked against its mandate and your policy, approved by a person when it must be, and sealed as evidence before it reaches a payment rail.
For banks, payment providers, merchants and agent builders, across payments, data access and commerce.
- Agent registry
- Mandates
- Spend limits
- Policy engine
- Human approval
- Evidence packs
- API
- SDK
- CLI
- MCP server
Safety rule: No agent moves money without an authenticated human approval or a valid mandate recorded in the audit trail.
AgentHousehold bills agent
Sandbox: live
- 1Agent registered and keys publishedDone
- 2Mandate granted: utilities, £300 per paymentDone
- 3Monthly cap set: £900Done
- 4Policy check: new payee → escalateDone
- 5Customer approval on phoneDone
- 6Evidence pack sealedDone
0Terminal views
0Lab missions
0Access channels
Built for the teams that let agents touch money
BanksPayment service providersCard issuers and acquirersMerchantsAgent buildersAI platformsIdentity and credential providersRisk and compliance teamsSupervisors and policy teams
The problem
A login consent is not authority to pay.
Agents already read accounts, fill carts and prepare payments. Most stacks still hand them a broad token and write a log afterwards. When a customer disputes a payment, that log cannot answer the question a bank, a merchant or a supervisor will ask: was this action allowed, by whom, and within which limits?
No limit the rail can see
Per-payment caps, monthly caps, payee lists and expiry live in application code, not in a mandate the next system can check.
Approval without context
When a person must approve, the prompt rarely shows the amount, the payee and the agent that asked.
Logs are not evidence
A log line written after the fact does not show the mandate, the policy verdict and the approval that were in force at the moment of the action.
The approach
Model the authority first;
then connect the rails.
AgenticOpenFinance separates what an agent may do from how the money moves. Agents, mandates, limits, policies, approvals and evidence are built and tested first; each capability then runs in one of three modes:
- 1Simulator
- 2Provider sandbox
- 3Live connection
- Agent registered
- Mandate defined
- Limits and policy
- Approval route
- Simulation
- Failure tests
- Provider sandbox
- Pilot
- Live rails
Outcomes
What changes for your teams
Actions stay inside the mandate
Payments that would cross a cap, reach an unknown payee or run after expiry are stopped before execution, not flagged afterwards.
Evidence before the complaint
Each action carries a sealed record of the mandate, verdict and approval, ready when a dispute or a supervisor's request arrives.
Faster risk sign-off
Risk and compliance review one mandate and one policy set, and watch them hold in failure tests, instead of reading code.
Rail-independent
The same mandate runs over card agent tokens, account-to-account payments or variable recurring payments; connectors are swappable.
Known agents only
Requests are signed and checked against the agent's published keys, its operator and the principal it acts for.
Reusable across products
Mandates, policies and connectors built for one agent are reused by the next one.
Value per audience
Each team gets a concrete result on day one.
Choose your role.
For banks
Accept agent-initiated payments and data access with mandate checks, decoupled customer approval and an evidence pack per action.
For payment service providers
Route agent payments to the right rail and return a verdict, a status and evidence the merchant and the issuer can both read.
For merchants
Tell known agents from unknown bots, accept agentic checkout for a specific amount, and keep the evidence for chargebacks.
For agent builders and AI platforms
Give your agent mandate-checked tools over MCP and an API, with limits and approvals your customers' banks can accept.
For identity and credential providers
Issue and verify credentials that bind an agent to its operator and principal, and plug them into every mandate check.
For engineering teams
API, SDK, CLI, webhooks, MCP server, schemas and sample data, all on one domain model with idempotent writes.
For risk and compliance
Policies, limits, approvals, evidence and audit trail defined in the product, not reconstructed from logs after an incident.
See governanceFor supervisors and policy teams
Explore how mandates, approvals and evidence behave across failure scenarios, with fictional data and no commercial commitment.
One platform, modular
Every module an agent action passes through
Select a module to see its lifecycle and get the path to build it.
How it works
Four steps, one path to production
Register the agent.
Give the agent an identity, an operator and a principal, and publish its keys so every request it sends can be verified.
ExampleHousehold bills agent, operated by Tallyline Ltd (demo), acting for one customer
OutputAgent idAgent cardSigning keys
Define the mandate.
State what the agent may do: action class, payees, per-payment and monthly caps, currency and expiry. The customer grants it once.
ExampleUtilities only · £300 per payment · £900 per month · expires 2027-03-31
OutputMandateLimitsApproval routePolicy set
Simulate the failures.
Run the paths that go wrong before production: over limit, expired mandate, new payee, injected instruction, replayed request.
ExampleA £412.00 bill against a £300 cap
OutputAllowed403 over limitEscalated401 expiredReplayedEvidence
Connect the real rails.
Swap the simulator for a provider sandbox, then a live connection. Mandates, policies and evidence stay exactly as tested.
ExampleUK open banking payment initiation and a card agent token programme
OutputSandbox→Pilot→Live
Do not start from a blank page
Every project starts with five packs.
Defines how an agent pays within a mandate.
Payment initiationCard agent tokensVariable recurring paymentsIdempotency keysReceiptsRefunds
Defines what an agent may read, and for how long.
AccountsBalancesTransactionsPurposeExpiryPermission dashboardRevocation
Defines when a person decides and how the request reaches them.
Escalation rulesDecoupled approvalApprover rolesTimeoutsStep-up authentication
Defines what is recorded for every action.
Agent identityMandate snapshotPolicy verdictApproverRail responseSealJSON export
Defines how a past action is explained when it is challenged.
Unauthorised claimChargebackError resolutionReplayCase notesOutcome
The same mandate looks different in each sector.
Retail banking
Customers let agents read accounts and pay bills; the bank sees each mandate and each approval.
E-commerce
Agentic checkout with a token for one merchant and one amount, and evidence for chargebacks.
SME finance
Accounts-payable agents pay approved invoices under caps; larger ones go to the finance lead.
Corporate treasury
Sweeps and liquidity moves within set parameters, business days and dual approval.
Travel
A buyer agent books with a seller agent and pays under a trip mandate with a fixed budget.
Wealth
Rebalancing proposals that stay proposals until the policy and the client allow execution.
An empty sandbox is not enough
Start with data from day one.
Projects arrive with fictional but realistic agents, mandates, customers, payees and payment histories, so the sandbox is useful from the first hour.
An agent has a lifecycle, not a feature list
Register, scope, mandate, act, escalate, evidence, revoke.
Select a stage to see what happens in it.
Simulation first
See the failures before production does.
Choose a run mode and a failure scenario, and watch how the mandate, the policy and the evidence respond.
Failure scenario
- Choose a scenario and press "Run scenario".
Use cases
Two examples, from mandate to evidence
Household bills
A customer lets an agent pay household bills from a UK current account.
- Agent registered
- Mandate granted
- Bill received
- Policy check
- New payee: escalate
- Customer approves
- Payment initiated
- Evidence sealed
- Payments pack
- Payment initiation
- Data pack
- Balances and transactions
- Human in the loop
- Decoupled approval
- Provider
- Simulator + Fernhill Bank (demo)
- Governance
- £300 per payment, £900 per month
SME accounts payable
A small business lets an agent pay approved supplier invoices.
- Invoice received
- Supplier verified
- Budget check
- Under cap: pay
- Over cap: finance lead approves
- Payment batch
- Reconciliation
- Evidence export
- Payments pack
- Account-to-account
- Data pack
- Invoices and ledger
- Human in the loop
- Finance lead approval
- Provider
- Simulator + Harbourline Bank (demo)
- Governance
- €5,000 per invoice, known suppliers only
From API to app
See what the customer sees
Three demo apps built on the same API. Tap inside the phone or press play; each step shows the API call and the event it produced.
Bank appGrant a bills mandate, then approve a new payee
9:41
Business appAn invoice over the cap waits for the finance lead
9:41
Agentic checkoutAn agent token for one merchant and one amount
9:41
Tap any call in the list under a phone to open the same request in the API console. All data is fictional.
Embeddable components
Mandate, approval and evidence widgets for your own product
Each widget runs on the platform's API and takes your brand. Use it here, then copy the embed code.
Settlement calendar
An agent payment settles on a business day, not on a timestamp
Business days and holidays for the United Kingdom, the United States and the euro area, from the official schedules of GOV.UK, the Federal Reserve Banks and the ECB's T2 calendar. Agents and approvers see the real settlement date before they commit.
One engine, every channel
One calendar engine for the whole platform
The calendar on this page and its published data file come from one engine, so no two parts of the platform disagree about a business day or a settlement date. The API, SDK, CLI, MCP tools and iCal feeds are planned on the same engine.
- Data
/data/calendar.json: holidays and business days, published with the site - APIRead-only settlement endpoint (planned)
- SDKEmbedded engine and typed client (planned)
- MCPRead-only calendar tools for agents (planned)
- iCalHoliday subscription per market (planned)
curl https://agenticopenfinance.com/data/calendar.json
# markets: GB, US, EU (T2) · holidays with their official source
# 2026-12-25 Christmas Day · 2026-12-28 Boxing Day (substitute day) in GB# Trade 2026-12-24, settle T+1
GB → 2026-12-29 (skips 25 Dec and the 28 Dec substitute day)
US → 2026-12-28 (skips 25 Dec)
EU → 2026-12-28 (T2 closed 25 and 26 Dec)// planned: read-only tools for agents
{ "method": "tools/call",
"params": { "name": "calendar_settlement",
"arguments": { "market": "GB", "date": "2026-12-24", "t": 1 } } }Notifications
One event, to the right person on the right channel.
Approval requested, mandate expiring, payment blocked, consent revoked: push, email, in-app and webhook from one rule, with quiet hours, business days and a delivery receipt for each message. Choose an event type and answer it on the phone. Demo data
Agents and protocols
An agent may act,
only within its authority.
No agent moves money without an authenticated human approval or a valid mandate recorded in the audit trail. An agent acts only when:
- its identity is verified,
- a valid mandate covers the action,
- the policy allows it,
- the limits hold,
- and the result can be recorded and proven.
Bills agentPayables agentCheckout agentTravel booking agentTreasury sweep agentCollections agent
Data-access agentRebalancing agentDispute agentReconciliation agentCompliance agentEvidence agent
Request from the payables agentPay €6,480.00 to Alder Joinery GmbH (demo), invoice INV-2026-0918
- Intent
- Identity
- Mandate
- Limits
- Policy
- Approval
- Rail
- Evidence
- Reconcile
When an agent goes past its mandate, a person decides.
DemoAll companies, people, agents and amounts are fictional. Protocol names refer to public specifications; naming one is not a partnership or an endorsement.
Agent workflows
From invoice to reconciliation, with checkpoints.
Each node is a capability, a provider, an agent, a person or a policy. Every run is visible step by step, and waits for a person wherever the policy requires one.
Control and observability
One control surface for every agent.
Demo data
Active agents0▲ 3
Mandates in force0▲ 12
Escalated today0No change
Blocked today0▼ 2
Agent actions, last seven days
MondayTuesdayWednesdayThursdayFridaySaturdaySunday
Recent actions
- Bills agent · £84.20 to Brightwave Energy (demo)Allowed
- Payables agent · €6,480.00 to Alder Joinery (demo)Awaiting approval
- Checkout agent · $129.00 at Cobalt & Fern (demo)Settled
- Travel agent · €2,150.00 to a new payeeEscalated
- Sweep agent · £12,000.00 over monthly capBlocked
The AgenticOpenFinance terminal
Every agent, mandate and verdict, in one environment.
Register, scope, approve, pay and prove, for people and agents, from one place. Demo data
Identify→Mandate→Check→Approve→Execute→Prove
DemoAll companies, people, agents and amounts are fictional. Protocol names refer to public specifications; naming one is not a partnership or an endorsement.
For developers
API, SDK, CLI and MCP on one domain model
A mandate, a limit or an approval is defined once and exposed the same way to your backend, your scripts and your agents. The MCP server offers only mandate-checked tools: an agent cannot call a payment tool its mandate does not cover.
Create a mandate
POST/v1/mandates
Interactive API console
Try the API here
Pick an endpoint, edit the request and send it. You see the path from gateway to mandate check, policy and rail, the response, the headers, the webhook events and ready-made code in four languages. Responses come from the simulator and touch no real account.
POST
Press "Send" to see the response.
This session
- No requests sent yet.
Architecture
Every layer between an agent's intent and a settled payment
Select a layer to see its role.
Channels
Bank appBusiness appMerchant checkoutWidgetsAgent runtimes
Identity
Agent registryAgent cardSigned requestsOperatorPrincipalCredentials
Authority
MandateConsentLimitsPolicyApproval
Rails
Payment initiationCard agent tokenVariable recurring paymentAgent-to-agentSettlement calendar
Evidence
Evidence packSealAudit trailExportDispute replay
Access
APISDKCLIWebhooksMCP
Select a layer.
Ecosystem
Every party to an agent payment, on one model
Customers and businesses, their agents, banks, payment providers, card networks, merchants, identity providers and supervisors meet through one model of identity, mandate and evidence. The directory lists regulators, standards bodies, rails and sandboxes from official sources.
- Customers
- Businesses
- Agents
- Agent platforms
- Banks
- Payment providers
- Card networks
- Merchants
- Identity providers
- Standards bodies
- Supervisors
Agent-to-agent networks
Let known agents transact with each other, under mandates on both sides.
A buyer agent reads the seller agent's card, verifies its identity and pays under its principal's mandate; the seller's receipt returns to both evidence packs. Demo data
DemoAll companies, people, agents and amounts are fictional. Protocol names refer to public specifications; naming one is not a partnership or an endorsement.
Connect once, reuse
Turn each integration into a reusable connector.
Providers differ; your mandate does not.
An adapter maps the platform's payment model onto each provider's own contract. The mandate, the policy and the evidence stay the same; only the connection changes.
Platform payment modelagenticopenfinance.payment.v1
Adapter
Fernhill Bank (demo)POST /pisp/domestic-payments
Every connector in one registry
Providers, capabilities, versions, environments and health, in one view.
| Connector | Capability | Environment | Status |
|---|---|---|---|
| Platform simulator | Mandates, payments, evidence | Simulated | Ready |
| Fernhill Bank (demo) | Payment initiation, balances | Sandbox | Connected |
| Tidewater Payments (demo) | Card agent tokens, refunds | Live | Active |
| Veritrust ID (demo) | Agent credentials | Sandbox | Mapping |
One mandate, several rails
One payment command; the rail the mandate allows.
Card agent token, account-to-account or variable recurring payment, chosen per action by mandate, cost, time and policy. If a rail fails, the next permitted one is tried and every step is timestamped. Demo data
DemoAll companies, people, agents and amounts are fictional. Protocol names refer to public specifications; naming one is not a partnership or an endorsement.
Governance by design
Every action authorised, controlled and provable.
The rule: No agent moves money without an authenticated human approval or a valid mandate recorded in the audit trail.
- Request
- Identity
- Mandate
- Policy
- Approval
- Execution
- Evidence
Agent identityConsentMandateSpend limitsPolicyHuman approvalEvidenceEvent logAuditRetentionRevocationKill switch
Compared with common approaches
Why tokens and logs are not enough
| Approach | Strength | Limit |
|---|---|---|
| API keys in the agent's prompt or config | Quick to start | No per-action limit; one leaked key opens everything |
| Broad OAuth scopes | Standard, well supported | Grants a class of actions, not one payment to one payee |
| Logs written after the action | Cheap to add | Shows what happened, not whether it was allowed |
| AgenticOpenFinance | Identity + mandate + limits + policy + approval + evidence, per action | Needs mandates and policies defined for each use case |
Business value
Letting agents act should not make every change riskier.
Fewer unauthorised-payment disputes
Payments outside the mandate are stopped before they reach the rail.
Less rework
Demo, pilot and production share one model of mandates, policies and evidence.
Less provider lock-in
Rails and providers change without redesigning the authority model.
Less incident reconstruction
Evidence exists at the moment of the action, not after the complaint.
More reuse
Mandates, policies, connectors and workflows carry over from one agent to the next.
Your agents should not wait for a blank cheque.
Continue here
Try it, learn it, build it with us.
LabRun seven missions in your browser.
List agents, read their headroom, pay under a mandate, replay safely, hit the cap and read the events. No sign-up.
Open the lab TerminalFourteen views of governed agent actions.Mandates, human approval, agent payments, treasury sweeps, agent-to-agent purchases, failure scenarios and evidence.
Open the terminal AcademyLearn agentic finance step by step.Six tracks from fundamentals to mandates, protocols, identity, governance and disputes, plus workshops.
Enter the academy PartnersBuild agent-native open finance with us.Banks, payment providers, agent builders, connector maintainers, advisers, universities and standards contributors.
Become a partnerPodcasts
Agentic finance, in one and two minutes
Short shows, from 5 October 2026 at 06:00 UTC: Agent Minute, one glossary term every day; Two Minutes of Agentic Finance on Mondays; On the Wire, one agent protocol from its own specification, on Tuesdays; Rulebook for Agents, regulation from official sources only, on Wednesdays; Sectors in Two Minutes on Thursdays; and Licences, Plainly on Sundays. Each episode comes with a full transcript and an RSS feed.
Glossary
The agentic finance glossary
Terms for agents acting in finance, in plain English: mandates, consent, agent identity, payments, protocols, security, governance, liability, AI regulation, open finance, evidence, commerce and risk. Each term cites its official or specification source and says when a term is industry usage rather than a legal definition. One term a day is explained in a minute.
Events
Webinars, workshops and seminars
Hands-on lab workshops on mandates and approvals, protocol walk-throughs and sessions with bank, payments and risk teams; with registration, reminders and calendar invites.
Hear about new events first
We email you when a new event or an important guide is published.
FAQ
Questions we are often asked
Can an agent move money on this platform?
No agent moves money without an authenticated human approval or a valid mandate recorded in the audit trail. In the simulator and the lab, agents move fictional money only. With a live connection, an agent can initiate a payment only through a licensed bank or payment provider connected to the platform, only within a mandate the customer granted, and only when the policy allows it or a person approves it.
Is AgenticOpenFinance a bank or a payment institution?
No. AgenticOpenFinance is technology infrastructure. It does not hold customer funds or provide regulated payment, banking or investment services. Offering those services to customers requires the authorisations that apply in each jurisdiction.
Is this legal advice?
No. The site explains rules in general terms and links to the official source, such as the European Commission, the EBA, the FCA, the CFPB or MAS. Check the current text with the regulator and take legal advice for your own case.
Which regulations apply to AI agents in finance?
It depends on the jurisdiction and the activity. Examples: the EU AI Act, which lists creditworthiness assessment and some life and health insurance pricing as high-risk uses; PSD2 and its technical standards on strong customer authentication in the EU; the Payment Services Regulations 2017 in the UK; and Regulation E for electronic fund transfers in the US. The Rulebook for Agents series covers each one from official sources.
Do I need a real bank connection to start?
No. Agents, mandates, limits, approvals and evidence can be built and tested in the simulator with sample data. Provider sandboxes and live connections come later, without changing the mandates you tested.
Which agent protocols does it work with?
The MCP server exposes mandate-checked tools, and the platform's model maps onto public specifications such as MCP, A2A, AP2, ACP and x402; each link is the publisher's own specification page, and the directory lists them with their sources. Naming a protocol is not a partnership or an endorsement.
How is the information I enter in forms used?
Only to answer that request. Read the details in the .
Start with one agent
Give your agents a mandate;
keep the proof.
Agent identity, mandates, limits, policy, approval, evidence, connectors, API, SDK, CLI and MCP in one path.
Start with one agent and one mandate; add rails, providers and environments as you go.