Eight resources. One authorisation model.
Adapter is a Cloudflare Worker in front of New Zealand's open banking rails. Every route declares the privilege it requires in the same table that dispatches it, so what a caller may do is a property of the endpoint rather than of where it sits in a file.
Money is an integer, always.
Amounts cross the wire as { minor, currency }. Minor units are not always hundredths - JPY has none, KWD has three - so Adapter carries the ISO 4217 exponent rather than dividing by a hundred and hoping. A float only ever appears at a provider's own edge.
Payment rails sit behind a provider interface, and the differences between them are capabilities you branch on, not methods that throw. Akahu moves NZD domestically; Airwallex handles cross-border.
Three steps from a hostname to a payment.
An agent should not need a human to read documentation on its behalf. Adapter is being built so that everything an agent needs - where to authenticate, what it may do, what each tool costs it in privilege - is discoverable from the origin itself.
Discover
LiveAdapter publishes OAuth Protected Resource Metadata (RFC 9728) and an API catalog (RFC 9727). An agent that has only the hostname can find the authorisation server and the machine-readable description of the API without being told either.
Authenticate
PreviewA scoped bearer token for an agent whose operator can paste a secret; OAuth 2.1 with resource indicators for one you do not control. Scopes name capabilities, not routes - payments:create is granted separately from everything else, and most agents never need it.
Call
PreviewAn MCP server at /mcp over Streamable HTTP, built against the 2026-07-28 specification: stateless, no session header, no initialize handshake. That is a natural fit for a Worker, which has no long-lived process to hang a session off in the first place.
There is no create_payment tool, and there will not be one. An agent composes a workflow whose destination is a payee the account holder already authorised at their bank, and runs it. It never gets a primitive that takes an account number and an amount.
Autonomy with a fixed blast radius.
The interesting question about an agent that can move money is not what it can do on a good day. It is what it does when the prompt is poisoned, the model is confused, or the token leaks. Adapter's answer is that the set of accounts money can reach was fixed by a human, at a bank, before the agent existed.
A payee is authorised at the bank, not in our database.
Destinations come from an enduring consent the account holder granted inside their own bank. Adapter cannot add one, and neither can anything calling Adapter. The worst a compromised agent achieves is paying someone the account holder already chose to be payable.
A workflow will not arm until every destination is covered.
Enablement walks the destination nodes, resolves each payee against the consent, and refuses on any gap. The failure is explicit and machine-readable, so an agent can tell the difference between "not authorised yet" and "broken".
The payment row is written before the rail is asked.
Adapter inserts PENDING_SUBMIT, then submits. Only a definite rejection may mark a payment failed - a timeout or a 5xx leaves it pending for reconciliation, because guessing "failed" hides a real payment and frees a retry to make a second one.
A human can be required, out of band.
An approval node emails a named person and waits. That approval is durable and lives outside the agent session: it survives the agent going away, and the approver need not be whoever is running it.
Push, encrypted to a key we do not hold.
Polling an API for "did the money move" is the wrong shape for an agent and an expensive one for a bank rail. Adapter posts workflow and payment events to an endpoint you control, envelope-encrypted so the payload is readable only by you.
A per-delivery AES-256-GCM key encrypts the event and is wrapped to your RSA public key. Sealing happens once, at enqueue.
The stored payload is ciphertext, so the delivery history cannot show a body - not to you in the dashboard, and not to us.
An HMAC over the body, with the same primitive used to verify inbound trigger calls. Timestamped, so a replay is detectable.
The delivery id is stable across retries. Retries follow a published backoff rather than whatever the queue default happens to be.
New Zealand's banking infrastructure, addressable.
Adapter is not a ledger with a bank logo on it. It sits directly on the country's open banking infrastructure, which is what makes an agent-issued instruction end as a real credit into a real account at a real bank.
Bank connectivity is Akahu's, accredited under New Zealand's Consumer Data Right and used by PaySauce, Booster and Sharesies. Adapter never sees a bank credential.
Payments run under an enduring consent granted through the bank's own authorisation flow, with per-payment and per-period caps set there rather than here.
NZ account numbers are validated, NZ business days and cut-off times are modelled, and NZD is the domestic currency. Cross-border is a separate rail, not a fudge.
Revoking the connection removes Adapter's ability to act. There is no shadow copy of the mandate that keeps working after you leave.
Shipped, in preview, or not yet.
Deciding whether to build on a platform means knowing which half of its marketing is real. Live means you can call it today. Preview means it is designed and being built, and the shape below is what it will be.
The questions a developer asks first.
Give your agent a bank account.
Adapter is in early access with a small group of teams building payment automation on New Zealand rails. Tell us what you are building and we will get you an account, and a token as soon as tokens ship.