--- title: "AgenticOpenFinance™ | Agent-native infrastructure for open finance" description: "Agent-native infrastructure for open finance: agent identity, mandates, spend limits, policy verdicts, human approval and sealed evidence for every action an AI agent takes with money or financial data." url: https://agenticopenfinance.com/ lang: en source: "AgenticOpenFinance" --- > Agent-native infrastructure for open finance: agent identity, mandates, spend limits, policy verdicts, human approval and sealed evidence for every action an AI agent takes with money or financial data. 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 Request a demo See it in the terminal **Safety rule:** No agent moves money without an authenticated human approval or a valid mandate recorded in the audit trail. _Agent workspace · demo data_ Agent **Household bills agent** Sandbox: live 1. 1 Agent registered and keys published **Done** 2. 2 Mandate granted: utilities, £300 per payment **Done** 3. 3 Monthly cap set: £900 **Done** 4. 4 Policy check: new payee → escalate **Done** 5. 5 Customer approval on phone **Done** 6. 6 Evidence pack sealed **Done** **0** Terminal views **0** Lab missions **0** Access channels Built for the teams that let agents touch money Banks Payment service providers Card issuers and acquirers Merchants Agent builders AI platforms Identity and credential providers Risk and compliance teams Supervisors 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? 1 ### 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. 2 ### 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. 3 ### Approval without context When a person must approve, the prompt rarely shows the amount, the payee and the agent that asked. 4 ### 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: - **1** Simulator - **2** Provider sandbox - **3** Live connection Pick a starting product See the architecture 1. Agent registered 2. Mandate defined 3. Limits and policy 4. Approval route 5. Simulation 6. Failure tests 7. Provider sandbox 8. Pilot 9. 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. Banks Payment providers Merchants Agent builders Identity providers Engineering Risk and compliance Supervisors For banks Accept agent-initiated payments and data access with mandate checks, decoupled customer approval and an evidence pack per action. Request a demo 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. Add a connector For merchants Tell known agents from unknown bots, accept agentic checkout for a specific amount, and keep the evidence for chargebacks. Build a prototype 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. Get sandbox access 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. Add a connector For engineering teams API, SDK, CLI, webhooks, MCP server, schemas and sample data, all on one domain model with idempotent writes. Get sandbox access For risk and compliance Policies, limits, approvals, evidence and audit trail defined in the product, not reconstructed from logs after an incident. See governance For supervisors and policy teams Explore how mandates, approvals and evidence behave across failure scenarios, with fictional data and no commercial commitment. Contact us One platform, modular ## Every module an agent action passes through Select a module to see its lifecycle and get the path to build it. ### Agent registry Agent identity, operator, principal, published keys, agent card and status. See lifecycle ### Mandates Action class, payees, per-payment and monthly caps, currency, expiry and revocation. See lifecycle ### Spend limits Running totals per agent and mandate, checked before each payment, with headroom on every response. See lifecycle ### Consent and data access Which agent may read which accounts, for what purpose, until when; revocable from a permission dashboard. See lifecycle ### Policy engine Allow, deny or escalate per request: new payee, jurisdiction, vulnerable-customer flag, amount, time. See lifecycle ### Human approval Decoupled approval on the customer's or approver's device, with amount, payee and agent shown. See lifecycle ### Agent payments Card agent tokens, account-to-account and variable recurring payments, with idempotency keys. See lifecycle ### Agent-to-agent payments A buyer agent reads a seller agent's card, verifies it and pays under mandate; a receipt returns. See lifecycle ### Agentic checkout Cart, agent token scoped to one merchant and amount, confirmation and order. See lifecycle ### Evidence packs Agent id, mandate snapshot, verdict, approver and rail response, sealed per action and exportable as JSON. See lifecycle ### Dispute replay Replay the sealed evidence of a past payment when a customer disputes it months later. See lifecycle ### Sweeps and treasury Variable recurring payment sweeps between accounts, within set parameters and business days. See lifecycle How it works ## Four steps, one path to production 1 Register the agent 2 Define the mandate 3 Simulate 4 Connect ### 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. Example Household bills agent, operated by Tallyline Ltd (demo), acting for one customer Output Agent id Agent card Signing 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. Example Utilities only · £300 per payment · £900 per month · expires 2027-03-31 Output Mandate Limits Approval route Policy set ### Simulate the failures. Run the paths that go wrong before production: over limit, expired mandate, new payee, injected instruction, replayed request. Example A £412.00 bill against a £300 cap Output Allowed 403 over limit Escalated 401 expired Replayed Evidence ### Connect the real rails. Swap the simulator for a provider sandbox, then a live connection. Mandates, policies and evidence stay exactly as tested. Example UK open banking payment initiation and a card agent token programme Output Sandbox _→_ Pilot _→_ Live Do not start from a blank page ## Every project starts with five packs. Agent payments Data access Human in the loop Evidence Disputes Defines **how an agent pays** within a mandate. Payment initiation Card agent tokens Variable recurring payments Idempotency keys Receipts Refunds Defines **what an agent may read**, and for how long. Accounts Balances Transactions Purpose Expiry Permission dashboard Revocation Defines **when a person decides** and how the request reaches them. Escalation rules Decoupled approval Approver roles Timeouts Step-up authentication Defines **what is recorded** for every action. Agent identity Mandate snapshot Policy verdict Approver Rail response Seal JSON export Defines **how a past action is explained** when it is challenged. Unauthorised claim Chargeback Error resolution Replay Case notes Outcome ### 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. Starter Multi-agent Commerce Stress test 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. Email me this path Request a demo for this module 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. **Mock** Test contracts and basic responses. **Simulated** Run stateful mandates and limits over time. **Sandbox** Connect to a provider's test environment. **Live** Promote to a live connection. Failure scenario Over the per-payment cap Over the monthly cap Expired mandate Unknown payee Injected instruction Replayed request Revoked consent Unverified agent signature Approval timeout Rail timeout Settlement on a holiday Disputed payment Run scenario _Run log_ 1. 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. 1. Agent registered 2. Mandate granted 3. Bill received 4. Policy check 5. New payee: escalate 6. Customer approves 7. Payment initiated 8. 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 Run the household bills example SME accounts payable ### A small business lets an agent pay approved supplier invoices. 1. Invoice received 2. Supplier verified 3. Budget check 4. Under cap: pay 5. Over cap: finance lead approves 6. Payment batch 7. Reconciliation 8. 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 Run the accounts-payable example 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 app** Grant a bills mandate, then approve a new payee 9:41 Play Reset **Business app** An invoice over the cap waits for the finance lead 9:41 Play Reset **Agentic checkout** An agent token for one merchant and one amount 9:41 Play Reset 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, the euro area and the high AI velocity markets India, China, Singapore and Australia, from official schedules: GOV.UK, the Federal Reserve Banks, the ECB's T2 calendar, the Reserve Bank of India, China's State Council, Singapore's Ministry of Manpower and the NSW Government. Dates not yet published are marked expected. 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 holiday feeds for calendar apps come from the same engine; the API, SDK and MCP tools are planned on it. - **Data** `/data/calendar.json`: holidays and business days, published with the site - **API** Read-only settlement endpoint (planned) - **SDK** Embedded engine and typed client (planned) - **MCP** Read-only calendar tools for agents (planned) - **iCal** Holiday feed per market: UK, US, euro area, India, China, Singapore, Australia Data T+1 MCP iCal ``` curl https://agenticopenfinance.com/data/calendar.json # markets: GB, US, EU (T2), IN, CN, SG, AU · 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 } } } ``` ``` webcal://agenticopenfinance.com/calendar/uk.ics # One feed per market (uk, us, eu, in, cn, sg, au) # Holidays from official schedules; computed dates marked (expected) ``` [Open the full calendar](https://agenticopenfinance.com/calendar/) [Calendar data (JSON)](https://agenticopenfinance.com/data/calendar.json) [Subscribe to holiday feeds](https://agenticopenfinance.com/calendar/#subscribe) 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. The agent holds a payment mandate Run the agent request Bills agent Payables agent Checkout agent Travel booking agent Treasury sweep agent Collections agent Data-access agent Rebalancing agent Dispute agent Reconciliation agent Compliance agent Evidence agent Request from the payables agent **Pay €6,480.00 to Alder Joinery GmbH (demo), invoice INV-2026-0918** 1. Intent 2. Identity 3. Mandate 4. Limits 5. Policy 6. Approval 7. Rail 8. Evidence 9. Reconcile ### When an agent goes past its mandate, a person decides. **Demo** All 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 agents **0** _▲ 3_ Mandates in force **0** _▲ 12_ Escalated today **0** _No change_ Blocked today **0** _▼ 2_ **Agent actions, last seven days** Actions Blocked Monday Tuesday Wednesday Thursday Friday Saturday Sunday **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 payee _Escalated_ - Sweep agent · £12,000.00 over monthly cap _Blocked_ **Verdicts** Allow: 86% Escalate: 10% Deny: 4% **Approvals answered** 92% Requested: 118 Answered: 92% Timed out: 8% **Rails used** Account-to-account: 52% Card agent token: 31% Recurring (VRP): 17% **Evidence sealed** 100% Actions: 2,406 Sealed: 100% Exported: 37 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** **Demo** All companies, people, agents and amounts are fictional. Protocol names refer to public specifications; naming one is not a partnership or an endorsement. [Open the full terminal](https://agenticopenfinance.com/terminal/) API console 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. API SDK CLI Webhooks MCP Copy **Developer portal** Overview Modules API Webhooks SDK CLI MCP Schemas Samples Sandbox Logs #### Create a mandate POST /v1/mandates Auth: **Bearer + DPoP** Version: **v1** Environment: **Sandbox** Rate limit: **600 / min** Connector: **Simulator** Status: **Healthy** Sample request Response schema Event history Try it Open the API console Get sandbox access 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. Environment Connector POST Send Params Body Headers Schema Simulator scenario Press "Send" to see the response. Response Headers Events Code **This session** 1. No requests sent yet. Get a sandbox key Architecture ## Every layer between an agent's intent and a settled payment Select a layer to see its role. **Channels** Bank app Business app Merchant checkout Widgets Agent runtimes **Identity** Agent registry Agent card Signed requests Operator Principal Credentials **Authority** Mandate Consent Limits Policy Approval **Rails** Payment initiation Card agent token Variable recurring payment Agent-to-agent Settlement calendar **Evidence** Evidence pack Seal Audit trail Export Dispute replay **Access** API SDK CLI Webhooks MCP 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](https://agenticopenfinance.com/directory/) lists regulators, standards bodies, rails and sandboxes from official sources. ![AgenticOpenFinance™](https://agenticopenfinance.com/brand/app-icon-512.png) - 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 **Demo** All 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. All Open banking APIs Payment providers Card agent programmes Agent protocols Accounting and ERP Identity and credentials Messaging Reporting ### 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. Fernhill Bank (demo) Tidewater Payments (demo) Platform payment model agof.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 **Demo** All 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. 1. **Request** 2. **Identity** 3. **Mandate** 4. **Policy** 5. **Approval** 6. **Execution** 7. **Evidence** Agent identity Consent Mandate Spend limits Policy Human approval Evidence Event log Audit Retention Revocation Kill 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. Build a prototype See the architecture Brand guide ## The AgenticOpenFinance™ identity Logo, colours, typography, notification samples and usage rules, for teams, partners and media. [See the brand guide](https://agenticopenfinance.com/brand/) Continue here ## Try it, learn it, build it with us. [Lab **Run 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_](https://agenticopenfinance.com/lab/) [Terminal **Fourteen views of governed agent actions.** Mandates, human approval, agent payments, treasury sweeps, agent-to-agent purchases, failure scenarios and evidence. _Open the terminal_](https://agenticopenfinance.com/terminal/) [Academy **Learn agentic finance step by step.** Six tracks from fundamentals to mandates, protocols, identity, governance and disputes, plus workshops. _Enter the academy_](https://agenticopenfinance.com/academy/) [Partners **Build agent-native open finance with us.** Banks, payment providers, agent builders, connector maintainers, advisers, universities and standards contributors. _Become a partner_](https://agenticopenfinance.com/partners/) Blog ## Guides, analysis and the weekly business-day view Practical guides for product, engineering and risk teams, notes on agent protocols and regulation from official sources, and business-day tables for the markets where agent payments settle. [All posts](https://agenticopenfinance.com/blog/) [RSS feed](https://agenticopenfinance.com/blog/feed.xml) Podcasts ## 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. ![AgenticOpenFinance™ podcast cover](https://agenticopenfinance.com/brand/podcast-cover-600.png) [All episodes](https://agenticopenfinance.com/podcasts/) [Podcast feed (RSS)](https://agenticopenfinance.com/podcasts/feed.xml) 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. [Agents and autonomy 14](https://agenticopenfinance.com/glossary/#agents) [Mandates and authorisation 10](https://agenticopenfinance.com/glossary/#mandates) [Consent and data rights 11](https://agenticopenfinance.com/glossary/#consent) [Agent identity (KYA) 12](https://agenticopenfinance.com/glossary/#identity) [Agent payments 15](https://agenticopenfinance.com/glossary/#payments) [Agent protocols 12](https://agenticopenfinance.com/glossary/#protocols) [Authentication and security 11](https://agenticopenfinance.com/glossary/#security) [Governance and model risk 11](https://agenticopenfinance.com/glossary/#governance) [Liability and disputes 11](https://agenticopenfinance.com/glossary/#liability) [AI regulation 11](https://agenticopenfinance.com/glossary/#ai-regulation) [Open banking and open finance 11](https://agenticopenfinance.com/glossary/#open-finance) [Evidence and audit 11](https://agenticopenfinance.com/glossary/#evidence) [Commerce and checkout 13](https://agenticopenfinance.com/glossary/#commerce) [AI risks and safety 11](https://agenticopenfinance.com/glossary/#risk) [All terms](https://agenticopenfinance.com/glossary/) [Agent Minute](https://agenticopenfinance.com/podcasts/#daily) 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. Full name Email I agree to the privacy policy. Subscribe [Academy and events](https://agenticopenfinance.com/academy/#workshop) 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](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai), which lists creditworthiness assessment and some life and health insurance pricing as high-risk uses; [PSD2](https://web.archive.org/web/20260814022027/https://eur-lex.europa.eu/eli/dir/2015/2366/oj) and its [technical standards on strong customer authentication](https://web.archive.org/web/20260419105535/https://eur-lex.europa.eu/eli/reg_del/2018/389/oj) in the EU; the [Payment Services Regulations 2017](https://www.legislation.gov.uk/uksi/2017/752/regulation/77) in the UK; and [Regulation E](https://www.consumerfinance.gov/rules-policy/regulations/1005/6/) for electronic fund transfers in the US. The [Rulebook for Agents](https://agenticopenfinance.com/podcasts/) 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](https://modelcontextprotocol.io/specification/2026-07-28), [A2A](https://a2a-protocol.org/latest/specification/), [AP2](https://ap2-protocol.org/), [ACP](https://www.agenticcommerce.dev/) and [x402](https://x402.org/); each link is the publisher's own specification page, and the [directory](https://agenticopenfinance.com/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 privacy policy. 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. Request a demo Join the sandbox waitlist Start with one agent and one mandate; add rails, providers and environments as you go.