Crypto payments interrupted while signing now return clear retry guidance
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. Previously this state returned an unexplained internal error.
Locked accounts no longer hand out crypto deposit addresses
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.
Budgets and agents must name at least one allowed merchant, or allow all
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. Previously, choosing a specific allowlist while selecting no
merchants was accepted and produced a budget that silently blocked every
payment; the same request now returns a clear validation message instead. To
deliberately stop a budget’s spending, pause it — that is what pause is for,
and it is reversible. Existing budgets in this state can still be edited to a
valid merchant scope, paused, or revoked.
Solana payments that can no longer settle decline automatically
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.
Previously such a payment stayed pending until Anchorage resolved it
manually. A payment whose settlement did land on chain is never declined this
way; it completes as usual.
Budget allowlists follow merchant records through catalog consolidation
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 grant keeps admitting the same
real-world merchant, and its cap and spend-to-date stay untouched.
Previously a payment against such a grant was refused until an org admin
re-added the surviving entry to the allowlist. See
Budgets.
Payments refuse a merchant that mislabels what is being sold
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.
Invitations to organizations whose setup is incomplete wait visibly instead of failing
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.)
Sign out directly from the organization chooser
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.
New organizations are ready to use as soon as they are created
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.This replaces the separate activation step organizations used to wait on. An
invitation into a newly created organization is accepted on the spot, and a
payment is no longer refused at approval time for an organization awaiting
activation. Anchorage’s onboarding checks on an organization and its members
still run in full — they now complete as the organization is set up.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.
Browsing the merchant directory works when signed out
The merchant directory at
/merchants now returns results whether or not you
are signed in. Searching it while signed out shows the same live merchants a
signed-in user sees; previously a signed-out search came back empty.Invited members can sign in regardless of email domain
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 now decline an invitation at the moment it is accepted rather than
letting it through: 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.
New organizations are activated by the compliance team before first use
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, and
transferring wait until activation, and approving a queued payment is
rejected until the organization is activated. Existing organizations are
already active and unaffected. Merchant availability is likewise reviewed by Anchorage’s
compliance team.
A starting page at agentic.anchorage.com
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, instead of going straight to the
sign-in form. If you are already signed in, you still go directly to your
account — nothing changes for you.
Try deposits and payments in sandbox mode
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.
Frozen organizations can no longer approve queued payments
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.
Collapse the navigation sidebar on desktop
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.
Easier navigation on phones and clearer section highlighting
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.
List paging rejects invalid page markers
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; previously such a marker could quietly return the wrong page.
Markers issued before this release are invalidated once at rollout, with the
same recovery.
These docs have a new home
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.
One merchant catalog, richer results, for agents and browsers
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 report catalog gaps and broken services
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.
Solana deposit setup warning
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.
Pay and fund with USDC on Solana
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.
Repeat deposits can reuse sender details
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 search the merchant catalog
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.
Stronger linked-card compliance screening
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.
Attribute a held deposit
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.
Blocked agent connections end the session
When an agent connection does not pass compliance screening, its session now
ends, not just the one request it was making. The agent must reconnect to
continue. No action required — a runaway agent is stopped at the connection,
not asked again on the next call.
Deposit screening labels
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.
Larger paid-URL responses
Paid URLs that return large payloads now come back to your agent whole.
Responses up to 10 MB are delivered in full instead of being cut short, so
data-heavy APIs behind a paid URL work as expected.
Linked-card compliance screening
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.
Pilot launch and public docs
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.