Watch it

4:58 walkthrough · AI voice and music: ElevenLabs · youtu.be/mp9fmOYfBWc · test money only

How it works in 3 steps

Not signed is never paid.

• Face ID or a passkey signs the exact terms. The approval is a signature over the SHA-256 of the terms; change one cent and it no longer verifies. The owner's real approval of 7 November is checked offline by npm run verify-approval (record).
• Limits are enforced in 3 layers: Purser's code, Airwallex's card controls and Metal's on-chain mandate. Airwallex itself declined an agent's card over the CFO's limit (record); Metal refused a purchase over the mandate on chain (record). The mandates: /api/metal/mandates, a live read from Metal testnet, or the recorded 12 Nov snapshot when the chain does not answer (the answer says which).
• The audit chain is anchored on chain. Every event goes into a hash-chained log; its head is in a value-0 Metal testnet transaction, and npm run verify-anchor prints MATCH (record).

Test money only: Metal testnet, Airwallex sandbox, Visa via Airwallex Airi (sandbox), Claude. Check it yourself, offline, no keys: npm ci · npm run judge -- --check · npm run verify-approval (what each does)

Built with

Text names only; no endorsement implied.

Gallery

/try on a phone: the approval with the exact terms (recorded from the live page; test money, a virtual test passkey)	/proof: what Purser guarantees, who enforces it, the evidence
Purser Cloud as a guest: the demo company, made-up data, test money	/security: the layers a payment must pass

Home, light or dark as your GitHub is: one sample invoice from Read to Paid.

Verify it yourself in 3 commands

The quick start: under 2 minutes, no keys. Needs Node.js 22.13 or later and git. npm ci downloads packages from npm; after that, no network and no keys.

npm ci                       # under a minute: the exact versions in the lockfile
npm run judge -- --check     # about 5 s: every page in CHECK_PATHS built from the main run's record, offline
npm run verify-approval      # under 1 s: the owner's real passkey approval of 7 November, checked with Node's crypto

What you should see (abridged):

ok    /  200  63106 bytes
ok    /proof  200  138535 bytes
…
ok    signature          the ES256 signature verifies with the receipt's public key

VALID: docs/runs/2026-11-07-awx-1/receipt-P-0002.json
Proves: the holder of this public key signed exactly these terms, with the authenticator reporting user verification, on this site.
Does not prove: who holds the key, or that it was Face ID (no attestation is checked). A test world's terms: nothing real moved.

npm run verify-approval reads that receipt; change one cent in it and it says NOT VALID. npm run verify-receipt -- receipt.json checks any receipt of the same format.

The full suite, npm test (about 8 to 9 min on a laptop): 6592 tests passing, 4 skipped, in 590 files (the last full run, on commit 717dd1bf: summary), on stand-ins for Airwallex, Metal and Claude. The skipped ones run only on local D1 (npm run test:d1). Two kinds of line in its output are expected noise, not failures: Node's "ExperimentalWarning: SQLite is an experimental feature" and "try-sign: a live agent call failed" (a test that checks the fallback when the model is down).

CI runs these checks on every push; the CI badge at the top shows the result of the latest run on main.

Enterprise

What a finance team gets beyond the demo; test money today, each with where to check it.

• Purser Cloud: a console per company with Overview, Agents, Invoices & books, Transactions, Tokenisation and Settings; a public test preview where Try as guest opens a demo company read-only (purser-try.max-31b.workers.dev, docs/cloud.md).
• Approval alerts: WhatsApp, e-mail, Slack and Teams tell the CFO a payment waits; an alert never carries anything that approves. Built and tested with stand-ins, not sent live yet; WhatsApp goes live once Twilio keys are set (docs/cloud.md).
• Zero trust and step-up: agents act only through a fixed set of tools that code checks; sensitive console settings ask for a fresh passkey check (docs/security.md, cloud/src/stepUp.ts).
• Security contact: security.txt and SECURITY.md; the layers a payment must pass on /security.
• MCP connector: 14 read tools, and proposing an invoice's payment, never approving it; in the MCP Registry as io.github.agamemnon-coder/purser (Connect any AI).
• Tests: the suite's count is written from its last full run by npm run test-count (summary, the line below); CI runs it on every push.

How it works

Airwallex's AgentOS says its "components do not initiate money-out actions (transfers, FX conversions, or payouts) on your behalf" (docs, read 13 November 2026). Purser is the control layer for when agents do move money on Airwallex: within limits the CFO signs, and above them only with the CFO's passkey on the exact terms.

flowchart LR
  A["Claude agent<br/>proposes a payment"] --> P["CFO policy<br/>Purser's code"]
  P -- "within the limit" --> R["Airwallex · Metal · Visa via Airi<br/>each with its own limit"]
  P -- "above it" --> F["CFO's passkey<br/>Face ID on iPhone<br/>signs the exact terms"]
  F --> R
  R --> B["Books<br/>posted to T:0 and Moneybird (sandboxes)"]
  B --> L["Hash-chained audit log"] --> N["Its head anchored on Metal testnet<br/>npm run verify-anchor"]

For judges: 3 minutes

What it is: the control layer between a company's AI agents and its money on Airwallex and Metal, built for Starter Kit 11 (x402 Business Agents) and entered for the Metal Award and the Visa Award. The Kit 11 scenario, run live on 3 November.
1. Try it: a test company of your own; approve the exact terms with your passkey, then change them: refused.
2. Proof: one id per rail in docs/in-depth.md, every run in docs/runs/.
Offline: the quick start, under 2 minutes, no keys.
Simulated: the customer, the supplier, the merchants' charges, the settlement and the second approver; test money only.

What's live, what's simulated

Visa Award

Visa Intelligent Commerce through Airwallex's Airi: an agent pays with a Visa credential Purser binds to one purchase; in the sandbox Airi/Airwallex did not refuse a reuse or a higher amount (vic-3), Purser did (vic-4); within the CFO's limit on its own and above it only after the CFO's passkey. Live in the Airwallex sandbox with a test card on 7 November (a scripted run, no Claude call; first run) and 13 November: 2 paid in the 13 Nov run (5 paid across 3 Visa runs); 1 after Face ID, 5 refused by Purser incl. reused credentials, 1 not confirmed in Airi: nothing charged (latest run). Visa TAP is an extra, not part of the entry. /visa

Metal Award

Each agent pays x402 under its own mandate on Metal testnet, and Metal refuses what is over it: in the main run of 3 November, 86 Metal payments and purchase #24 refused on chain (tx, run). On 12 November a passkey account with two owners (the CFO's passkey and a labelled test passkey) changed the mandate only when both signed, and Metal refused a payment over its cap (record, diagram). /metal · docs/metal-award.md

The business hypothesis

Not validated with customers yet: 2 finance conversations (a CFO and a bank finance professional, quoted, anonymous); more in progress; no pilots, no revenue. Every line below is a hypothesis except the cited source.

• The problem: when an AI agent pays today, its limit lives in a prompt it can be talked out of, or in a month-end review that finds the money after it has left. (problem.md)
• Who buys: the finance team of a small company or scale-up that already banks with Airwallex and lets AI agents pay; the CFO uses it and decides. (model.md)
• Pilot pricing: Starter €49 a month (100 invoices, then €0.25 each); Business from €249 a month; a small fee per payout. A hypothesis. (model.md)
• Why now: Airwallex wrote on 5 October 2026 that agents moving money need limits enforced "through underlying infrastructure rather than prompts" ("Agentic banking starts with governance", source S1). (problem.md)
• Why Purser: it builds on Airwallex's own card controls and Metal's mandates, and adds what sits on top: one CFO policy for card and chain, approvals signed over the exact terms, a hash-chained audit log. (model.md)

Why not Airwallex's own approvals? Purser signs the exact terms with the CFO's passkey before the API call, enforces per-agent limits across Airwallex and Metal, and can additionally require Airwallex's approval workflow (IN_APPROVAL handled, src/airwallex/approvals.ts). Live in the sandbox, 10 and 12 Nov: Airwallex held a payout signed by a labelled test passkey IN_APPROVAL until the owner approved it in Airwallex's web app; then PAID, settlement simulated (run).

Try it in 2 minutes

1. Pay an invoice yourself: kit11.max-31b.workers.dev/try. A test company of your own; Claude reads a sample invoice, you approve the exact terms with your own passkey, it is paid on a simulated bank and booked. Change what you signed: refused.
2. Look around a company: Purser Cloud as a guest, then Try as guest: the demo company's dashboard and books, read-only, made-up data, test money.
3. Ask your own AI: add the remote MCP server https://purser-try.max-31b.workers.dev/mcp and choose the demo company (public token purser-demo-read-only): ask "what's waiting for the CFO?". It reads; it cannot approve or pay (Connect any AI).

See it

▶ MP4, 13 s	▶ MP4, 14 s
Purser Cloud as a guest: the demo company's dashboard (made-up data from a simulated month, test money), then its books.	kit11 /books: a test company's month, read and booked by Claude live; balance sheet, charts and the invoices sorted by Claude. Test money.	kit11 /proof: every claim with its run record.

/airwallex	/metal
/visa	/claude
/books

The pages and the console as the live site showed them on 13 November (npm run readme:shots -- --live; without --live the same shots from a local build): Purser Cloud as a guest with its demo company, light theme. Test money throughout.

How it works in 5 files

sequenceDiagram
  autonumber
  participant Ag as Agent (Claude)
  participant Po as Purser policy (code)
  participant CFO as CFO's phone (Face ID)
  participant Ex as Executor
  participant Rail as Airwallex or Metal
  participant Bk as Books and audit log
  Ag->>Po: propose: pay this invoice
  Po->>Po: check payee allowlist, caps, floors
  Po-->>CFO: over the limit: the exact terms and their SHA-256
  CFO->>Po: passkey signs the hash (Face ID unlocks it)
  Po->>Ex: approved proposal
  Ex->>Ex: re-hash the stored terms, refuse if one cent changed
  Ex->>Rail: pay (an Airwallex payout carries the signed hash in its metadata)
  Rail-->>Ex: accepted (sandbox or testnet)
  Ex->>Bk: book it, append to the hash-chained log

Architecture

flowchart LR
  U["Browser or phone"] --> K
  F["CFO's phone<br/>passkey"] <--> RO
  subgraph K["Worker kit11 · worker/"]
    S["Site: Home, Try, Proof, /security<br/>the hands-on demo"]
    RO["Durable Object RelayObject<br/>the relay: proposals, approvals"]
  end
  RN["Runner · Node, src/cli<br/>the live runs"] <--> RO
  K -- "service binding TRY_ENGINE" --> API
  subgraph C["Worker purser-try · cloud/"]
    API["Console and API"]
    MCP["/mcp · MCP server<br/>read, propose only"]
    E["Durable Object CompanyEngine<br/>one per company"]
    D[("D1 database")]
  end
  AI["Your AI · any MCP client"] --> MCP
  API & MCP --> E --> D
  RN --> AW["Airwallex sandbox"] & M["Metal testnet"] & V["Airi · Visa Intelligent Commerce"]
  S -- "FX quote, read-only" --> AW
  S & E --> CL["Claude · Anthropic API"]

Proof in numbers

Drawn from the run records and git history by npm run charts (scripts/repo-charts.ts); test/repo-charts.test.ts redraws them. Every id behind them is on /proof and in docs/runs/.

Connect any AI

Use your own AI assistant with a Purser company: Claude (claude.ai, the Claude apps, Claude Code), ChatGPT, Cursor, VS Code's agent mode, Gemini CLI, Windsurf, or any client that speaks MCP to a remote server. It reads the books and can propose an invoice's payment; it can never approve or pay: every payment still needs the CFO's passkey over the exact terms.

1. In Purser Cloud, Settings, Connect your AI: make a connector token (only an owner signed in with a passkey can).
2. In your AI, add the remote MCP server https://purser-try.max-31b.workers.dev/mcp (in Claude Code: /plugin marketplace add agamemnon-coder/x402-business-agents and /plugin install purser@purser).
3. Sign in with your token, or choose the demo company: its public, read-only token is purser-demo-read-only (made-up data from a simulated month, test money; it can propose nothing).

Purser shows with its own icon and offers three ready-made prompts: CFO weekly brief, What needs my Face ID? and Explain this invoice. Checked on 13 November 2026, 06:57 UTC: tools/list on that address with the demo token answers 7 read tools; the same morning the owner added it in the Claude iOS app (as the owner states it). The other clients are listed from their own documentation and have not been tried live against a deployed cloud. Every client's steps and every tool: docs/connect-claude.md.

Since then, in this repository (live once the cloud is redeployed): the server speaks MCP 2026-07-28 as well as the older revisions, with 14 read tools (cash and its projection, what waits for approval, the CFO's policy in plain words, spend by agent or supplier, VAT, a payment's audit trail, one payment explained), the books as resources, sign-in by Client ID Metadata Document for ChatGPT and Claude, and a page per client at /connect-ai with one-click links for Cursor and VS Code. Checked with the MCP Inspector against a local cloud; ChatGPT, Cursor, VS Code, Gemini CLI and Windsurf are described from their own documentation. Connections to other systems, read or export only (signed webhooks, Slack and Teams message formats, Xero, QuickBooks and Exact CSV, the read API's OpenAPI), each labelled live or format export: docs/connections.md.

Built after the kit (test environment, test money)

Who does what

Built with Airwallex, Metal, Claude, Visa and Cloudflare (no endorsement implied).

• Built by Max Geurtsen (Claude by Anthropic as the developer, directed and reviewed by Max): Purser itself: the CFO's policy and limits, the approval flow (Face ID on the exact terms, four eyes), the agents' tools and prompts, the relay and the site, the hash-chained audit log, the books, the tests.
• Airwallex (sandbox): the agents' cards and card limits, FX, the SWIFT euro payout, webhooks; its own approval workflow as a second lock. /airwallex
• Metal (testnet): the on-chain mandates and the agents' payments; it refuses what is over a mandate, and a passkey account changes a limit only when two owners sign. /metal
• Claude by Anthropic: two sets of agents. The Kit 11 agents pay for the company's own running costs (cards, x402 on Metal), the three agents' decisions: Sourcing on Claude Haiku, Support on Claude Sonnet, Treasury on Claude Opus. The payables agents handle supplier invoices (Home, /try, Purser Cloud): the Reader reads an invoice, the Checker checks it, the Coder books account and VAT, the Payer proposes the payment; code enforces the limits and the CFO signs with a passkey (Face ID on iPhone). /claude
• Face ID and passkeys (WebAuthn on the CFO's phone): the CFO's passkey (unlocked with Face ID on an iPhone; Purser asks for no attestation, so it cannot tell which authenticator was used) signs the hash of the exact terms.
• Visa Intelligent Commerce via Airwallex's Airi (sandbox, test card): an agent pays with a Visa credential Purser binds to one purchase (the sandbox did not refuse a reuse or a higher amount, Purser did: vic-3, vic-4). This is the work entered for the Visa Award (Visa confirmed on 7 Nov that the VIC run counts). The Visa TAP work is an extra: Visa said on 5 Nov that TAP is not eligible tooling for this hackathon (rules). /visa
• T:0 (shared sandbox entity): a general ledger outside Purser. On 10 Nov the main run's books went in as 95 journal entries, debits equal to credits, matched line by line (record). /t0
• Cloudflare: Workers and Durable Objects run the relay, the site and Purser Cloud's engine (one object per company).

Links

• Read: docs/in-depth.md (each judging criterion, the live runs with every id, what is real and what is mock) · docs/README.md (every doc, by reader) · docs/diagrams.md · docs/claims.md (every claim and its source) · docs/runs/ (every run log, dated) · docs/controls.md · docs/security.md
• Partners: docs/metal-award.md and docs/airwallex.md (what Purser uses from each) · The Visa TAP note: built and verified against Visa's public reference verifier; not eligible Visa tooling for this hackathon (Visa, 5 Nov)
• Run and build: docs/run-it.md (live, with sandbox keys and a Metal RPC) · docs/payables.md (the invoice inbox, built after the submission; code in src/ap) · skills/purser-spend/SKILL.md (for outside agents) · CONTRIBUTING.md · SECURITY.md
• Site: Hands-on demo (a test company of your own, test money) · The replay of the main run of 3 November (under Proof, not in the menu) · /security
• Releases: v1.0-submission (8 November, the hackathon submission) · CHANGELOG.md (every pull request since, generated from git) · docs/releases/v1.1-final.md
• Submission: docs/submission/README.md (the submission text, with the short Description) · docs/submission/long-description.md (the long form text it replaced, in full)

All money here is test money: the Airwallex sandbox and Metal testnet. Licence: MIT.