Suit Up · Asia's institutional desk on tokenisation

TL;DR

This playbook is for the institutional decision-maker asking the upstream question, before any rail or vendor work, of whether to support AI agents holding tokenised money or transacting with tokenised assets on behalf of customers, and if so, in what shape. The bottom-line guidance for May 2026 is to occupy a defined narrow agent use case under an explicit legal and operational framework rather than open agent access across all customers, with a pilot scoped tightly enough to defend if a regulator asks and broad enough to learn from. The regulatory perimeter is moving but not settled (see Regulatory perimeter for agents), and the gating questions on counterparty identity, transaction limits, dispute resolution, and instrument fit need to be answered before any rail decision. Get those answered first; the rail choice falls out.

Decision frame

The institution is asking whether to support agent-mediated transactions on its tokenised products, whether that product is a tokenised deposit, a regulated stablecoin, or a tokenised fund interest. This is upstream of choosing a rail. The right sequence is to decide whether to support it at all, then what the minimum operational shape that is defensible looks like, then how to know when to expand. If you skip to rail selection, you will ship a working integration sitting on top of an unresolved legal posture, which is the worst possible combination because it makes escalation harder, not easier.

The framing errors that show up most often in early conversations. Treating agentic commerce as just another distribution channel misses that agent counterparties have different identity primitives, different dispute paths, and different anti-money laundering (AML) and know-your-customer (KYC) implications than human or corporate counterparties. Picking x402 because it is the standard ignores that x402 is one rail among several and integrating without the institutional design questions answered creates compliance debt the integration team is not equipped to repay. Waiting for regulators to be clear is the comfortable choice that misreads the moment: regulators across MAS, HKMA, the BIS, and the major US agencies are explicitly in dialogue mode and the institutions that ship first set the reference points others get measured against. Assuming that an existing tokenised-deposit programme is agent-ready is the most common technical misread; current bank tokenised-deposit programmes are designed around named-customer addresses, not agent-controlled addresses, and the address model has to change before the rail can accept genuine agent-initiated flows (see Gating questions and instruments).

The right starting question is not "which rail" but "what is the principal-and-agent structure we are willing to stand behind." Once that structure is defined, the rail follows. Until it is defined, every rail conversation is premature.

The gating questions

Five questions, in order. None of them are technical in the chain-mechanics sense. All of them are load-bearing for whether the programme is operationally and legally defensible.

Who is the legal counterparty. The institution, the human end-user the agent acts for, or the agent's developer. Most operational designs today route agent-mediated transactions through the human end-user as the legal counterparty, with the agent as an instructor and executor under delegated authority. This is the architecture the foundations chapter recommends and the architecture every credible regulator-side commentary points toward. It requires that the institution's customer agreement authorise agent-mediated instruction, and most current customer agreements do not explicitly contemplate this. A customer-agreement amendment is the cheapest single piece of work that unlocks the programme, and it should be drafted before the integration spec, not after. The fallback options run worse. Treating the agent as the principal would require the agent to be a legal person, which it is not in any major financial jurisdiction. Treating the institution as the principal would convert the bank into a discretionary fiduciary on every transfer, which most banks do not have the licence or the appetite for.

What identity primitive does the agent hold. Three patterns are live. An API key wrapped over a custodian-controlled wallet, where the institution holds the keys, the agent has API access, and the on-chain entity is the institution. This is the dominant model in bank-issued tokenised-deposit programmes today and the lowest-friction starting point for a regulated bank. A delegated-authority signature, where the human customer signs a delegation to the agent, the agent's transactions reference the delegation, and the on-chain authority is the customer with the agent executing within scope. This is the model x402 and the W3C Verifiable Credential plus Decentralised Identifier stack lean toward (see Architectural primitives and identity). A directly-held wallet, where the agent has its own private keys, holds tokenised assets, and transacts as itself. Most institutions are not building toward this because it collides with the legal-counterparty question above.

What is the transaction-limit framework. Per-transaction caps, per-day caps, per-counterparty caps, per-merchant-category limits, dollar-velocity ceilings, novel-counterparty thresholds. The framework needs to be enforceable at the point of the agent's instruction, not at post-trade reconciliation. That means smart-contract-level limit enforcement if the rail is on-chain (the MAS Project Orchid purpose-bound money construct is the cleanest existing pattern for this) or API-layer enforcement if the rail is off-chain with on-chain settlement. The limits should be customer-configurable within institution-set caps, with a clear escalation path for a customer who wants to expand limits and a clear audit trail for every limit change.

What is the dispute resolution mechanism. Three roles can carry it: the customer (their agent, their problem), the institution (their customer, their problem), or the agent's developer (their product, their problem). Most current product designs put dispute resolution on the customer with the institution providing investigation support, and that is workable but creates a meaningful customer-experience burden the institution needs to budget for. The first major agentic-commerce dispute will likely set patterns that hold for several years (this is one of the open questions tracked in Production and open questions); a sensible posture is to design for the world where the dispute apparatus is closer to the card-network model than to the wire-transfer model.

Does your jurisdiction recognise agent-driven transactions as binding on the principal. The short version: the underlying legal doctrine (agency law, electronic transactions law, delegated authority) is workable in every major financial jurisdiction we have reviewed, if the construction is careful. The longer version is in Regulatory perimeter for agents. What does not yet exist in May 2026 is specific regulatory guidance saying "yes, this exact construction is approved." Operating in that silence is a deliberate choice, and the institutional posture should reflect that the silence is not permanent.

Decision dimensions for product design

Once the gating questions have answers, three product-design dimensions follow.

Instrument fit. Which tokenised instruments are agent-friendly today, and which are not. Tokenised deposits with named-customer addresses are not agent-friendly in their current architecture; the address is bound to the customer, the customer authorises the agent off-chain, and the on-chain transaction is the customer's executed via API, which is workable but requires the customer-agreement and limit-enforcement work above. Stablecoins with whitelisted-merchant rails are agent-friendly; this is the x402 sweet spot, where the agent transacts directly and the merchant rail enforces eligibility. Tokenised fund interests are not agent-friendly today because transfer-agent registration requires a named investor and agents do not have the legal personality to be that named investor (see BUIDL reference architecture for the canonical transfer-agent stack). Tokenised stable-value e-money under the HK Stablecoins Ordinance, the MAS Single Currency Stablecoin framework, or the Japanese PSA stablecoin routes are probably agent-friendly depending on the issuer's terms of service; the regulatory frame neither expressly contemplates nor prohibits agent-mediated transactions, and the issuer's published terms govern.

Rail choice. Three institutional patterns to think in. x402 for HTTP-native machine-to-machine payments, where the use case is "agent buys from agent" or "agent pays an API or merchant" with stablecoin settlement. Visa Intelligent Commerce or Mastercard Agent Pay for card-rail-mediated agent purchases, where the use case is "agent purchases on behalf of customer using customer's card credentials"; this is closest to existing card infrastructure and lowest in legal novelty, with a mature dispute apparatus the chain-native rails do not yet have. An internal rail (your own tokenised deposit or stablecoin) for closed-loop institutional flows where the institution controls both ends of the transfer. The right rail depends on the use case the gating questions surfaced; the rail does not pick the use case.

Operational posture. Two postures are distinguishable. Support a defined narrow agent use case under an explicit legal framework, with a single named agent provider, a single asset class, defined merchant categories, and conservative velocity caps. Open agent access to all customers, with broader authorisation patterns and lighter institutional gating. The first is what most institutions should be doing in May 2026 and is the posture this playbook recommends. The second is what a small number of fintechs are pursuing as a deliberate edge play, with the corresponding regulatory and dispute risk concentrated in those firms.

Worked example

A regional bank in Singapore or Hong Kong is deciding whether its tokenised deposit programme can accept transactions originated by a customer's AI agent, where the customer instructs Claude or an equivalent system to pay a vendor on their behalf. Walk the gating questions in order.

Legal counterparty. Customer is the principal, agent is the executor via API instruction against the bank's existing tokenised-deposit address for the customer. The customer-agreement amendment authorising agent-mediated instruction is drafted and signed before any technical work begins. The agent provider (in this hypothetical, the customer's chosen assistant vendor) is a third-party tool, not a counterparty to the bank.

Identity primitive. API key over the customer's existing tokenised-deposit address, scoped to specific merchant categories and dollar limits at the bank's API layer. The on-chain identity remains the customer's address; the agent's authority is expressed in the API scope, not on the chain. This sits in the first of the three identity patterns above and is the lowest-novelty starting point for a regulated bank.

Transaction limits. Enforced at the bank's API layer pre-settlement, with per-transaction caps, per-day caps, a defined merchant-category whitelist, and a novel-counterparty pause. Customer can adjust within bank-set ceilings; bank logs every change. The smart-contract-level enforcement (Project Orchid PBM-style) is the next-stage architecture the bank may move to, but is not required for the pilot.

Dispute resolution. Bank handles per its existing customer dispute process, with customer-agent disputes referred back to the customer's agent provider. Investigation support is in scope; making the customer whole on a disputed agent-initiated payment is in scope on the same terms as a disputed human-initiated payment under the customer agreement. The bank budgets for an elevated rate of customer-experience touchpoints in the pilot.

Jurisdictional recognition. Customer-agreement amendment authorises agent-mediated instruction; the underlying agency law in Singapore and Hong Kong supports the construction; no specific regulator approval is sought because none is required for the construction, but the bank notifies its supervisor as a matter of professional courtesy and to surface any concerns early.

Recommended posture for the pilot. A single named agent provider with explicit institutional integration, a single asset class (tokenised SGD or HKD deposit), a defined whitelist of merchant categories, conservative velocity caps, and a 12-month review for expansion. Volume targets are deliberately small; the goal is to learn the operational and dispute patterns, not to capture share.

Red flags

Assuming that current tokenised-deposit programmes are agent-ready. They are not. The address model is named-customer-only and the authorisation pattern was designed around human or corporate signing. Treat agent acceptance as a programme change, not a feature toggle.

Missing the AML and KYC implications of agent-mediated transactions. The agent is not a customer for KYC purposes, the human end-user remains the customer, and transaction-monitoring rules need to flag agent-pattern behaviour distinctly from human-pattern behaviour. Frequency, time-of-day distribution, and counterparty diversity all shift when an agent is the executor. Existing monitoring rules will produce false positives or false negatives if not retuned.

Building agent rails before the legal and identity primitives are settled internally. The rail will work and the legal posture will not, and the institution will ship a programme it cannot escalate or defend if a regulator or dispute counterparty pushes back. Get the customer-agreement amendment, the authority documentation, and the limit framework done before the integration is built, not after.

Conflating the agent-as-user model (agent transacts on behalf of human) with the agent-as-merchant model (agent receives payments for services rendered). These are different products with different counterparty risk profiles and different KYC implications. A bank that accepts agent-initiated transfers from its customers is doing one thing; a bank that accepts agent-received deposits from external agent operators is doing a different thing with materially harder counterparty diligence.

Treating the regulatory perimeter as static. The perimeter is actively forming. What is defensible in May 2026 may be regulated by Q4 2026. Build the programme to be amendable, with explicit checkpoints for re-evaluating the construction against any new published guidance from MAS, HKMA, the BIS, or the major US agencies.

[Suit Up]

Approaching agentic commerce as an institution