Extra request headers on a payment or cost preview — an API key, a content
type — reach the paid URL whether the agent passes them as a JSON object or
as a JSON-encoded string, and a headers value of any other shape is refused
with an error naming what was sent, before anything is fetched or paid.
Previously the object form was silently ignored, so a payment could settle
against the response the URL gives an unauthenticated caller.A request body must be a string: a body sent as an unencoded JSON document
is refused with an error asking for the string form, before anything is
fetched or paid. Previously that shape was silently sent as an empty body.
Registering an MCP client and revoking a token are now rate-limited: repeated
registration or revocation attempts are refused once they arrive faster than
the limit allows. An agent’s first reach of an endpoint URL nobody has
registered yet is rate-limited per agent. Once an endpoint URL is
registered — whether or not a payment on it completes — later calls to that
URL are not limited, and a normal connect — one registration, one consent —
stays well inside the limit.A registration or revocation request that hits its limit comes back as a
standard HTTP 429 with a
Retry-After header and the X-RateLimit-Limit,
X-RateLimit-Remaining, and X-RateLimit-Reset headers, so a client can wait
exactly as long as the response asks and then retry. A payment tool call that
hits its limit returns an error naming the limit; retry shortly.Every request body is also capped at 2 MiB: a request that declares a body
larger than that is refused with a 413 before it reaches the requested
action, unless another protection, such as cross-origin request blocking,
refuses it first. A request sent without a declared size that turns out to
exceed the cap is refused once the cap is hit while reading it. See
Agents for the details.When a payment or cost preview cannot reach the paid URL — the hostname does
not resolve, the connection is refused or unreachable, or the request times
out — the agent now receives an error naming the host and the cause, so it
can report the failing address instead of retrying blindly. These failures
used to return the generic reference-ID error. A URL whose host points at a
private or reserved network address is reported the same way as one that does
not resolve. Failures inside Anchorage Agentic Banking still return the
reference-ID message so support can trace them.
A cost preview for a paid URL now names the payment rail its price applies to,
alongside the amount, asset, chain, and recipient it already reported.A preview still moves no money, and it quotes the merchant’s terms rather than
clearing the payment: an agent that gets a price can still be refused when it
pays, because paying applies budget, screening, and wallet checks a preview has
nothing to run them against. The agent-facing tool text now says so, so an
agent reports a price as a price rather than as an approval.
The Deposit page fetches the details for whichever deposit option you pick, so
picking one is what shows you where to send funds. The page tells you while it
is fetching them.
A payment to a merchant who also banks with Anchorage Agentic Banking now
credits the receiving account from the same on-chain transfer that debits the
payer, so a paid balance reflects the money that arrived and reconciles
against the chain.
Improvement
Your first sign-in lands on the organization picker, where you accept an invitation or join an organization open to your email domain
Signing in identifies you, and you choose which organization to enter. Your
first sign-in lands on the organization picker, which lists your pending
invitations and every organization open to your email domain. Accept an
invitation or click Join, and you are a member; later sign-ins take you
straight to the organization you belong to.An organization is open to your email domain when it admits anyone with an
address at that domain. When one matches an address you have verified and you
are not a member, it appears under Organizations you can join with a Join
button — on the organization picker when you have no organization yet, and on
Settings once you do. You join at the standard member role, so accept the
invitation instead when someone invited you as an admin. An organization you
were removed from stays out of that list; ask an admin there to restore your
access.
A payment record now carries two budget versions: the version read when the
payment started, and the version in effect when the funds were authorized.
When they match, nothing changed mid-payment. When they differ, you can see
which rule applied. Both appear on the payment detail page and in the payment
record the API returns.This records the budget the payment draws on directly. A budget nested under a
parent is still checked against its parents as well, and their versions are
not recorded.
A Solana payment that settles on chain in the brief moment between the
merchant receiving the signed payment and Anchorage recording that delivery
now completes automatically: the settlement is recognized whichever side
finishes first, and the payment reaches its normal completed state with funds
accounted for exactly once. Payments on Base already behave this way.
In the rare case a crypto payment is interrupted at the moment of signing —
before any payment authorization is recorded — the agent now receives a
structured conflict explaining that reserved funds stay held and that
retrying with the same idempotency key re-enters normal payment
processing.
Every org admin now has the Deposit page and its navigation entry, so any
organization can fund its account by deposit. Incoming deposits still go
through the same compliance screening before the funds release to your
available balance.
While an account is locked for review, the Deposit page now withholds its
crypto deposit addresses — generating a new address and viewing the current
one are both refused, and the page explains the lock in place of the
address. The account’s deposit history stays visible throughout,
and deposits already on their way to a previously issued address still
arrive and follow the usual screening steps. A frozen account is unchanged:
it still accepts deposits and still shows its deposit addresses.
Creating or editing a budget — including the budget created with a new agent
— now requires the merchant scope to either allow all merchants or name at
least one; an empty allowlist returns a clear validation message. To
deliberately stop a budget’s spending, pause it — pause is reversible. An
existing budget with an empty allowlist can still be edited to a valid
merchant scope, paused, or revoked.
A Solana payment authorization is signed against recent network state and can
only land on chain for a short window. When that window has provably closed
and the network shows no settlement, the payment now declines automatically
and its reserved funds release — matching what already happens on Base. A
payment whose settlement did land on chain completes as usual.
When Anchorage consolidates duplicate entries for one merchant in the
merchant catalog, budgets whose allowlist names the duplicate now follow
to the surviving entry automatically. The budget keeps admitting the same
real-world merchant, and its cap and spend-to-date stay untouched. See
Budgets.
When a paid URL quotes its price, the quote may also name the resource
being sold. That name must now sit at the same address as the URL actually
reached — the same host and port, so a sibling or CDN subdomain counts as a
different address. A mismatch refuses the payment before anything is
signed, and a cost estimate for the same URL reports the same refusal.
Merchant screening is keyed by the resource’s address, so a mismatched
address could otherwise let one merchant present itself as another. Quotes
that omit the resource name keep working unchanged. See the failure-modes
table in Crypto payments.
A pending invitation to an organization whose setup did not finish now shows
Setup incomplete in its row instead of an Accept button — accepting
becomes available the moment Anchorage completes the organization’s setup.
Declining stays available throughout. Signing in also now requires an
organization that is ready for you: an invitation to an organization with
incomplete setup admits you once that setup completes, or once another of
your invitations or memberships points somewhere active. (Organizations are
active from the moment they are created — see the entry below — so this
state is rare and always something Anchorage resolves, never a step you wait
out.)
The organization chooser — including the pending-invitations view shown
before you belong to an organization — now names the account you are signed
in to and includes a sign-out button. Signing in with the wrong account
recovers in one step: sign out from the page and sign back in with the right
account.
A new organization is active from the moment Anchorage creates it. Anyone it
invites can accept and sign in straight away, and paying, transferring, and
approving a queued payment all work immediately.Anchorage’s onboarding checks on an organization and its members still run in
full — they complete as the organization is set up. This replaces the separate
activation step described in the 2026-07-27 entry below.An organization can still be frozen, which stops payments and transfers and
pauses its agents, and approving a queued payment stays blocked until it is
unfrozen.
The merchant directory at
/merchants now returns results whether or not you
are signed in: a signed-out search shows the same live merchants a signed-in
user sees.An invited member can now sign in for the first time with the email address
the invitation was sent to, whatever its domain — a personal address, or a
contractor’s own company address, for example. Signing in creates their
account and shows them the invitation; accepting it is what adds them to the
organization, with the role the invitation specified. An expired, revoked,
or already-accepted invitation grants nothing.Sign-in for a domain with an identity provider configured still goes through
that provider. Someone invited from outside that domain signs in with an
email code and accepts the invitation the same way.Two cases decline an invitation at the moment it is accepted: an organization
that has since restricted membership to its own email domain, and one still
awaiting activation. Both leave the invitation open — the first needs a fresh
invitation from an address the organization now admits, the second only needs
activation to finish.
A new organization now starts in a review state and must be activated by
Anchorage’s compliance team before it can be used — signing in, paying,
transferring, and approving a queued payment wait until activation. Existing
organizations are already active and unaffected. Merchant availability is
likewise reviewed by Anchorage’s compliance team.
Visiting agentic.anchorage.com without being
signed in now shows a short starting page linking to sign-in, these docs, the
product overview, and a way to reach us. If you are already signed in, you go
directly to your account.
You can now switch to sandbox mode to try deposits and payments on a test
network without moving real funds. Your sandbox balance is kept separate from
your live one, and test-network deposit addresses differ from your live ones —
copy the address shown for the network you are on. Switch back to your live
account at any time.
Approving a payment that is waiting in the approval queue now checks the
organization’s status first: if the organization is frozen, the approval is
rejected with a message naming the reason and the payment stays in the queue.
The same check runs when an approved payment is re-issued. Nothing is lost —
once the organization is unfrozen, the approval and re-issue work as before.
On a computer you can now collapse the navigation sidebar to give the page
more room, and open it again from the menu button in the top bar — the
sidebar stays the way you left it as you move between pages. The bar holding
the logo and the light and dark theme controls now sits at the top of every
screen, on computers as well as phones.
The navigation menu on phones opens from the top bar, the Escape key
closes it, and keyboard focus moves into the menu when it opens and
returns to the menu button when it closes. Switching between light and
dark themes is available directly from the top bar on phones. The
sidebar also keeps the current section highlighted while you view its
subpages — for example, a card’s detail page keeps Cards highlighted —
so it is always clear where you are.
Paging through long lists — purchase requests, budgets — uses an opaque
marker to fetch the next page. A corrupted or outdated marker now returns a
clear invalid-request error, and restarting the listing from the first page
recovers. Markers issued before this release are invalidated once at rollout,
with the same recovery.
This documentation now lives at docs.anchorage.com/agentic-banking. Old
links under agentic.anchorage.com/docs redirect here automatically, so
bookmarked pages keep working. The docs MCP server moved with it: requests
to the old address are redirected with the method preserved, which most
MCP clients follow transparently — if yours does not, update its
configured address to docs.anchorage.com/mcp. Updating saved links is a
good idea either way.
Finding a merchant now happens in one place: the merchant catalog, browsable
by anyone in the web UI — signed in or anonymous — and searchable by agents
over MCP. An agent’s results are limited to what it can actually pay on its
network (mainnet or testnet), and this catalog search is now the only way
an agent discovers where it can pay; the earlier separate list of allowed
merchants has been retired in its favor. Each result now also shows
the merchant a service belongs to, whether that merchant runs the service
itself or resells another provider’s, and the payment methods the service
accepts, so an agent can tell up front what it’s able to pay and who it’s
dealing with. Services from the same merchant are grouped together, and
pulling a single service’s detail lists the payment methods its endpoints
accept. Only merchants that have cleared review appear in results.
Agents can now report problems with the merchant catalog as they browse it. When
an agent cannot find a merchant it expected, finds that no merchant offers what
it needs, hits a service that does not work, or gets search results that miss the
mark, it can send that feedback to Anchorage Agentic Banking — noting the search
it tried or the service in question. The reports help us fill gaps in the catalog
and fix listings that have gone stale.
The Deposit page now warns when a Solana deposit address still needs its token
account created. If you see the warning, complete the setup before sending
funds to that Solana address. Existing ready addresses are unchanged.
Agents can now make crypto payments with USDC on Solana, alongside USDC on
Base — Anchorage Agentic Banking automatically settles on Solana when a
merchant prices a request there. You can also fund your account by depositing
USDC on Solana; it credits your account’s USD balance on that network
(mainnet or testnet — Base and Solana deposits feed the same balance, not
separate ones per chain) and is screened like any other deposit. Existing
Base payments and deposits are unchanged.
After you attribute a self-hosted deposit sender once, later deposits from the
same sender in your org can reuse those details automatically. The deposit still
runs screening before funds become available, so a fresh review can still block
the funds.
Agents can now find merchants and services to pay by describing what they
need — for example, “weather data” or “image generation” — instead of needing
a URL up front. Search returns the matching live merchants, and an agent can
then pull a service’s payable endpoints and documentation links to make the
call. Only merchants that have cleared review appear in results.
Linked-card compliance screening was strengthened. As before, a card that does
not pass is refused at link time and stays in your card list, marked with the
reason.
When a deposit reads Needs attribution, you can now enter the sender’s
name and country directly from your deposit history. Submitting those details
runs the review and releases the funds in the same step if it passes.
When an agent connection does not pass compliance screening, its whole
session now ends and the agent must reconnect to continue. No action
required — a runaway agent is stopped at the connection.
Each deposit now shows where it stands in review: Needs attribution,
Reviewing attribution, Cleared, or Blocked on screening. A deposit
becomes available to spend once it reads Cleared. The label sits next to
each deposit in your deposit history, so you can tell at a glance whether
funds are ready or still in review.
Paid URLs that return large payloads now come back to your agent whole:
responses up to 10 MB are delivered in full, so data-heavy APIs behind a paid
URL work as expected.
Linked-card support now runs compliance screening when a card is linked and on
each purchase. A card or purchase that does not pass is refused; rejected cards
stay visible in your card list for audit, marked with the reason. No action
required — if a link or purchase is refused, the web UI explains why.
The first public release of Anchorage Agentic Banking, alongside the
launch of this docs site.
- Two payment rails. Crypto payments to paid URLs on the open internet, and linked-card purchases via a one-shot credential scoped per merchant. Each agent can use both rails and picks one per spend.
- Agent-scoped budgets. Org admins pre-authorize crypto spend with a USD spend limit and a merchant allowlist; agents see the limit, not the account balance.
- Per-purchase passkey approval for linked cards. Each card purchase an agent requests goes through a fresh passkey approval in the browser.
- Safety cap that no approval can override. $1,000 per UTC day, per agent, across both rails.
- Instant revoke of any agent from the web UI, with no grace window.
- Sign-in via work SSO or a one-time email code.