HSBC Joins Effort to Set Asia-Pacific Rules for Agent Payments: When AI Starts Spending, Who Confirms Identity and Bears Responsibility?

The Emerging Payments Association Asia (EPAA) has recently launched an AI and Agent Payments working group, with HSBC as a founding member.

The working group plans to bring together banks, payment networks, fintech companies, and technology platforms to establish common standards for payments initiated by AI agents. The scope of discussions will cover agent identity, authentication, authorization, liability allocation, fraud risk, business models, and industry practice guidelines.

This is not a short-term technical discussion.

According to the current plan, the working group will establish a committee of 10 to 12 institutions and involve up to 30 participants. Over the next 18 months, the recommendations will be communicated to governments, regulators, and central banks of ASEAN and APEC member economies, with formal policy recommendations expected to be submitted to the 51st ASEAN Summit and APEC Economic Leaders' Week in November 2027.

It should be noted that this working group was initiated by the EPAA. Current public information does not indicate that the Monetary Authority of Singapore (MAS) is a co-sponsor of the project, so it should not be described as 'jointly promoted by MAS and other regulators.'

More accurately, this is an attempt by the industry to first propose rules and then gradually engage in dialogue with regulators in the Asia-Pacific region.

Why HSBC Became a Founding Member

HSBC's participation in the working group is no coincidence.

In May 2026, HSBC completed a B2B Agentic Commerce payment pilot in Singapore with Mastercard. The pilot connected a multinational corporate buyer, Singapore-based procurement platform SourceSage, and e-commerce supplier FortyTwo, with transactions completed via Mastercard Agent Pay.

In this trial, AI agents were involved not only in product discovery and procurement but also in the actual payment process. HSBC emphasized that such transactions require embedded controls, transparency, and risk management from the outset.

This practical experience means HSBC is no longer dealing with abstract technical questions but with the real challenges banks must address when entering agent payments:

• Which individual or business does the AI agent represent?
• What permissions does it have, and where do those permissions end?
• If the agent exceeds its authorization, should the bank execute the payment?
• When errors or fraud occur in a transaction, what are the respective responsibilities of the developer, deploying enterprise, user, and payment institution?
• How can an automatically initiated payment meet audit, dispute resolution, and regulatory inspection requirements?

Nicholas Soo, Head of Payment Products for Asia at HSBC, stated that the previous agent payment pilot has proven that B2B transactions can be executed end-to-end with controls, transparency, and risk management throughout. The next step is to work with other working group members to build the foundation needed for agent commerce to truly take off.

From testing a single transaction to participating in rule-setting, HSBC is moving agent payments from product exploration to institutional building.

After AI Pays, the Hardest Question Is 'Who Is Paying'

The identity chain in traditional payment systems is relatively clear.

Individuals undergo KYC for identity verification, enterprises prove their business entity through KYB, and accounts, bank cards, and payment credentials connect payment actions to responsible parties.

But an AI agent is neither a natural person nor a legally liable business entity. It is simply software deployed, authorized, and run by a person or organization.

Therefore, 'identifying the agent' alone is insufficient. What truly matters is tracing back from the agent to confirm who it represents, under what authorization it acts, and the scope of funds it can control.

This makes KYA (Know Your Agent) a noteworthy industry direction.

While the EPAA's currently disclosed scope uses terms like agent identity, authentication, and authorization without publishing a formal standard called KYA, from OceanAlt's perspective, a future complete agent identity system must address at least four questions:

1. Who created and deployed the agent?
2. Which natural person or legal entity does the agent represent?
3. What explicit authorizations has the agent received?
4. Can each payment be traced back to a specific task, instruction, and responsible party?

KYA should not become another 'identity performance' that merely verifies technical credentials.

Even if the system confirms that a wallet, key, or Agent ID exists, it does not mean the actual controller behind the agent has been proven, nor that the transaction aligns with the user's true intent.

Effective identity attribution must connect the agent, authorizer, funding account, task source, and transaction behavior into a verifiable chain of evidence.

When a Payment Goes Wrong, Responsibility Cannot Disappear into Code

Liability allocation is another core challenge the working group must address.

Suppose a company authorizes an AI agent to purchase office equipment with a single-transaction limit of $10,000, but the agent mistakenly buys $100,000 worth of goods. Liability could involve multiple parties:

• Did the user or company give ambiguous instructions?
• Does the agent developer have design or security flaws?
• Did the deploying party correctly configure permissions and limits?
• Did the merchant identify the anomalous transaction?
• Did the bank or payment institution fulfill necessary risk control obligations?
• Did the payment network provide adequate authorization and dispute resolution mechanisms?

If rules are unclear, each party might claim they were merely executing instructions from the system above.

Thus, a payment completed by an AI agent could leave technical traces everywhere but have no one legally responsible.

This is why agent payments must establish a 'non-repudiation' mechanism. Future payment instructions must not only prove the transaction occurred but also retain the agent identity, original task, authorization credentials, limit rules, decision-making process, digital signature, and execution result.

When a transaction is disputed, the system must be able to reconstruct:

Who initiated the task, who granted the authorization, what information the agent used to make its decision, and why the payment institution released the funds.

Only when the chain of responsibility can be reconstructed can insurance, arbitration, refunds, and regulatory accountability have a solid foundation.

Fraud Risk Amplified by Automation

The efficiency brought by AI agents can also become a lever for fraudsters.

Attackers can alter agent behavior through prompt injection, forge payment pages or payee identities, steal agent credentials, or tamper with transaction parameters to trick agents into bypassing original permissions.

Traditional fraud often requires attackers to operate transaction by transaction; agent fraud, however, can be executed repeatedly in seconds and rapidly spread across multiple accounts, wallets, and jurisdictions.

Therefore, agent payments require not a post-payment risk report but a control layer before funds are transferred.

Currently, the EPAA has not announced specific 'pre-settlement firewall' standards, nor has HSBC declared deployment of a complete KYA or on-chain risk screening product. However, from an industry development perspective, a mature agent payment control system may need to include:

• Identity Attribution Verification: Confirm the agent and its underlying natural person or legal entity.
• Authorization Intent Verification: Determine if the agent is authorized to execute the current transaction.
• Amount and Frequency Controls: Set single-transaction limits, cumulative limits, and abnormal payment frequency.
• Trusted Payee Mechanism: Restrict the agent to paying only verified accounts, wallets, or merchants.
• Counterparty Screening: Conduct sanctions list checks, fraud risk assessments, and necessary on-chain address checks based on business context.
• Abnormal Suspension Mechanism: Immediately halt payments when payee, amount, or behavior patterns are anomalous.
• Human Override Mechanism: Return decision-making to a human when transactions exceed preset risk boundaries.
• Full-Process Audit Trail: Record complete evidence of tasks, authorizations, decisions, payments, and settlements.

These capabilities are not meant to stop AI from spending money but to ensure AI can only spend money within clear, limited, and traceable authorization boundaries.

Banks, Regulators, and Tech Companies Sit at the Same Table

HSBC's participation as a founding member sends a more important signal: traditional financial institutions are no longer just observing agent payments but actively seeking to define the rules.

Tech companies excel at enabling agents to discover products, call services, and issue payment instructions. Payment networks control authorization, authentication, and transaction routing. Banks and other regulated financial institutions must address accounts, funding sources, anti-money laundering, dispute resolution, and legal liability.

No single party can solve all the problems of agent payments independently.

Future agent payment standards will likely not be decided solely by the pure tech community but will emerge from ongoing negotiation among banks, payment networks, tech companies, industry associations, and regulators.

The EPAA working group's choice to first form a common industry position and then communicate with relevant ASEAN and APEC governments, central banks, and regulators also indicates that the Asia-Pacific region aims to establish its policy influence before global agent payment rules are fully set.

However, the working group is still in its startup phase. Whether it ultimately produces standards adopted by banks, payment networks, and regulators across jurisdictions will depend on the scope of participation, technical outcomes, and policy coordination over the next 18 months.

How This Rule Change Will Impact the Market

Enterprises cannot only consider 'how to enable agents to complete payments'; they must also establish agent identity attribution, tiered authorization, limit management, payee verification, and transaction audit mechanisms. Otherwise, even if payments are technically successful, they may fail internal audits or external compliance reviews.

For AI agent developers, identity, permissions, and logs will no longer be just add-on features but may become basic requirements for accessing mainstream payment systems.

MCP, x402, and other agent protocols address interoperability at different levels, but regardless of the technology used, development frameworks must ultimately answer the same set of questions: Who does the agent represent, what can it do, how much can it spend, and when must it stop and wait for human approval?

For payment and compliance professionals, traditional KYC, KYB, and AML systems will not disappear because the payer becomes AI. Instead, they must extend to agent identity, authorization relationships, and behavior monitoring.

Future compliance targets are not just account holders and counterparties but also the AI agents that sit between them, capable of understanding tasks and taking autonomous actions.

From 'Machines Can Pay' to 'Machines Can Be Trusted'

HSBC's participation in the Asia-Pacific Agent Payments working group signals a shift in industry focus.

Previously, the discussion was about whether AI could complete payments. Now, the more important question is: Can this payment be explained, constrained, audited, and traced to a real responsible party when something goes wrong?

Protocols can teach machines to pay, and stablecoins and payment networks can accelerate fund flows. But only when identity, authorization, risk control, and liability mechanisms are jointly established can agent payments truly enter the enterprise and financial system.

When AI agents start spending real money, trust cannot rest solely on a piece of code or a digital signature.

It must come from a complete chain of evidence: knowing who is paying, understanding why the payment is made, confirming the payment should be made, and, after everything goes wrong, still finding someone responsible.