Sphere Labs CEO Arnold Lee on Building Compliance-Ready Stablecoin Payments for the AI Era

As stablecoins gain traction and AI agents take on more financial activity, payment infrastructure faces new questions around compliance, security and accountability. In this interview, Arnold Lee, co-founder and CEO of Sphere Labs, explains how SphereNet is building regulation-ready rails for institutional stablecoin payments.

Q1. What is Sphere’s strategy to combine a regulated stablecoin framework and agentic AI to develop a regulation-ready and secure payment network amid growing stablecoin traction?

As more payments start to be made by agents instead of people, stablecoins could become a useful way for them to move money because they can settle quickly and run around the clock. That is the direction SphereNet is preparing for. It is a semi-permissioned network where participants are vetted before they transact, and compliance checks are built into the payment process. Instead of checking a transaction after it has already gone through, the network can check identity, sanctions, counterparties, and other requirements before the payment settles. This also avoids some of the friction in traditional payment systems, where different banks and institutions often run the same checks separately and have to piece together what happened later. SphereNet keeps a record of these checks so authorized institutions have something they can refer back to. Post-transaction monitoring will still be needed, especially when suspicious activity only becomes clear over time, but the idea is to catch more problems before the money moves rather than trying to fix them retroactively.

Q2. What is SphereNet’s plan to verify identities, regulatory requirements, and sanctions in real time ahead of finalizing stablecoin payments?

SphereNet plans to handle identity and compliance checks before a payment is finalized by having the relevant parties verified before they can transact. Because the network is semi-permissioned, each institution is responsible for checking its customers against AML, CFT, sanctions, and other rules that apply in the countries where they operate. After a customer has been verified, the network does not need to store their identity documents or other sensitive information. Instead, it can use an attestation or proof that confirms the customer has passed the required checks. These attestations can be created, updated, expired, or revoked by approved issuers, and a payment can be stopped if the required proof is missing or no longer valid. SphereNet is also working on privacy-preserving credentials and zero-knowledge checks so institutions can prove that a customer meets a requirement without sharing the underlying information on the network. The network keeps a record of these checks and changes for auditing, while the institution remains responsible for making sure its customers and transactions meet the applicable laws.

Q3. As AI agents can now carry out financial decisions autonomously, what are the key security and compliance challenges for which businesses should get ready for the years ahead?

As financial AI agents become more autonomous, businesses will need to think seriously about what happens when those systems make mistakes or are deliberately exploited. A determined attacker may eventually find a prompt, data source, credential, or workflow that exposes a weakness the designers never considered. Businesses should therefore put strict boundaries around what agents can access and authorize, including transaction amounts, counterparties, time limits, and the people or organizations they represent. They will also need to prepare for prompt injection, manipulated data, stolen credentials, and other attempts to influence an agent’s decisions. Cross-border transactions make this harder because financial, sanctions, licensing, data, and consumer-protection rules differ between countries, even though the agent may act almost instantly. Strong access controls, transaction limits, secure key management, detailed records, independent monitoring, and human approval for significant or irreversible actions will become increasingly important. Companies should also regularly test how quickly they can shut down an agent and respond when something goes wrong. The safest approach is to assume that an agent will eventually encounter a situation its designers did not anticipate and build the system so that the consequences remain limited.

Q4. In line with concerns posed to AI systems, what are Sphere’s safeguards to guarantee the transparency, compliance, and auditability of AI-driven payment infrastructure?

From the network’s perspective, it is not necessary to classify every action as human- or AI-initiated. The same onboarding, verification, authorization and compliance requirements apply in either case. An AI agent acts through a wallet controlled or authorized by an onboarded person, business or regulated institution, so there is an accountable party behind the system.

Before a transaction executes, the wallet must present the credentials or attestations required by the relevant institution, asset and jurisdictional policy; just like passing in this information via an api the normal way. Those credentials can be verified, expired or revoked, and the transaction is subject to the same enforcement rules whether it was initiated manually or by software. Wallet actions and credential state are recorded on SphereNet’s shared ledger, creating a traceable, tamper-evident and independently auditable record for authorized parties. SphereNet therefore provides transparency and auditability through identity, attestations and transaction history—not by trusting an AI system to describe what it did.

Q5. How does Sphere create a balance between AI-led automation and human oversight in the case of cross-border or high-value stablecoin transfers?

The issuer of each asset determines the rules under which that asset may move. An issuer may choose to apply identical rules to every authorized wallet. An issuer could also choose to recognize human- and AI-controlled wallets differently and apply different transaction limits, counterparty restrictions, credential requirements or approval thresholds to each. In that case, the distinction would come from an issuer-recognized credential, attestation or authorization, as opposed to SphereNet making its own judgment about whether an actor is human or AI. SphereNet’s role is to enforce the asset’s declared policy consistently. A transfer executes only when the wallet, signatures, credentials and other required conditions satisfy the issuer’s rules. This lets issuers decide where automation is acceptable and where a human or multi-party approval must remain in the loop, including for high-value or cross-border transfers. There is no universal network-wide threshold because the appropriate controls depend on the asset, issuer, institution, corridor, and applicable regulation.

Q6. What is the role of Sphere’s recent partnership with Deutsche to fortify SphereNet’s enterprise model in enhancing compliance, resilience, and trust?

A compliance-native network for regulated finance earns its credibility less from what it claims about itself than from who is willing to operate it, so the participants at the base layer matter as much as the architecture. Deutsche Telekom has joined SphereNet as one of our earliest validator partners, running node infrastructure across testnet and mainnet through the same subsidiary that already validates for a range of established networks. That does a few things at once, it broadens the set of independent, vetted operators securing the base layer, and an operator accustomed to running regulated infrastructure at that scale is the right kind of participant for a network where the rules are meant to live inside the rail. A partner of that standing choosing to invest early, and to build alongside us rather than watch from a distance, is also a meaningful signal to the licensed institutions we are onboarding next. 

Telecoms have quietly carried money and messages across borders for well over a century, so there is a certain fitness to them helping run this kind of network, and what I care about most at this stage is building with partners who can help us build what the institutions moving the world’s money actually need.

Q7. How does Sphere enable banks, enterprises, and financial institutions to seamlessly adopt regulated blockchain-based payments?

When an institution onboards a customer, it ends up building the very same checks that the firm down the street has just built, confirming the person is who they say, that they may hold the product, and that they are not on a sanctions list, and each one then stores the documents and carries the liability for that data. It is the one job every financial company must do and the one none of them competes on, so rebuilding it in-house a thousand times over never made much sense. On SphereNet, an institution reaches for a check that already covers the requirement, much as a developer reaches for a well-tested library instead of writing the encryption from scratch, and onboarding turns from a build into an integration. Everyone in the environment is already a vetted, regulated entity, and someone verified once can meet the same requirement at the next service without handing over their information again, so the business inherits a larger pool of already-verifiable customers and a smaller store of data to guard.

We enable adoption by turning blockchain-based payments into an institutional integration rather than asking every bank or enterprise to build the full stack itself. To note, SpherePay already provides APIs, SDKs and dashboards for onboarding, KYC/KYB, fiat and stablecoin movement, and transfer-status management. This lets institutions integrate payments without building custody, chain routing and corridor operations from scratch. SphereNet, currently in testnet, is designed to extend that approach to the settlement and asset-policy layer. Tokens, transaction fees, signing and other chain interactions can be abstracted from the institution and its end users. 

SphereNet does not impose one compliance model on every asset. The issuer of each asset defines the rules under which that asset can be transferred. On a per-asset basis, an issuer can opt in to requiring credentials, attestations or other verification from senders and recipients. An issuer could, for example, accept an attestation showing that another trusted institution has already KYB’d a party, where the issuer is legally comfortable relying on that verification. The issuer decides which credential or attestation providers it trusts, what evidence is required, when it expires, and when it may be revoked. Those choices apply only to that asset; another issuer can adopt a different policy or choose not to use the same attestations. 

SphereNet’s role is to enforce the selected requirements consistently when the asset moves. This opt-in model reduces bespoke integration and duplicated verification where appropriate without forcing institutions to surrender control of their own compliance standards.

Q8. As payments across borders often include different regulatory models, how does Sphere guarantee compliance of AI agents in performing international stablecoin transfers?

SphereNet does not apply a separate universal compliance regime simply because a transaction is initiated by an AI agent. The issuer of each asset defines the conditions under which that asset may move, including the jurisdictions, counterparties, credentials, attestations and approvals it will accept. Those rules apply at the asset level and can vary between issuers based on their regulatory obligations and risk tolerance. An issuer may apply the same rules to human- and AI-controlled wallets or, where an issuer-recognized credential or authorization identifies the distinction, impose different limits or approval thresholds. In either case, the wallet must be tied to an onboarded and accountable person, business, or regulated institution; an AI agent cannot bypass the verification requirements that apply to the party behind it.

SphereNet’s current testnet controls can enforce revocable eligibility or set-membership attestations, while more expressive jurisdictional and policy tooling remains under development. Our role is to enforce the issuer’s declared conditions consistently and record the executed transaction and relevant credential state for authorized audit. The issuer and participating regulated institutions remain responsible for interpreting local law, selecting the checks they rely on and carrying out any continuing monitoring obligations.

Q9. What is Sphere’s governance framework to ensure the accuracy, adaptability, and transparency of its AI systems amid growing focus of regulators and governments on AI governance?

SphereNet does not use AI to decide whether a transaction is compliant or may proceed. The policies that allow or deny a transaction are on-chain state, resulting in deterministic outcomes. Those policies are created and authorized by people at the asset issuer or relevant regulated institution in accordance with the laws and regulations that apply to them.

When a transaction is submitted, SphereNet checks the wallet, signatures, credentials, attestations, and other required conditions against the issuer’s declared policy. The result does not depend on a model’s confidence score, interpretation or changing behavior; the same inputs are evaluated against the same policy rules. If regulations or institutional requirements change, authorized humans update the applicable policy or credential state through the network’s governed processes. Those updates and the resulting executed actions are recorded on the shared ledger, providing a transparent and auditable history for authorized parties. Whether the transaction was initiated by a person or an AI agent does not change that enforcement model.

Q10. While conventional financial systems can reverse or freeze suspicious transfers following settlement, how does SphereNet address the irreversibility challenge?

It’s true that once something clears on these rails, you can’t reach back and undo it the way a card network can claw back a chargeback, and I don’t want to wave that away, it’s a genuine constraint. The way we’ve thought about it is that if you can’t fix a mistake after the fact, the care has to move to before the fact, which is part of why SphereNet is a semi-permissioned environment where every participant is already vetted and regulated, and why the compliance checks live inside the rail, so they run while the money is moving and the record gets written down as it happens. When something does need to be examined, there’s a canonical, cryptographically verified record that a bank partner or a regulator can inspect on their own, so accountability doesn’t rest on any single party’s account of events. I’d say irreversibility becomes a lot less frightening once the group of people who can transact at all is small, known, and answerable. SphereNet separates ledger finality from asset-level remediation. A finalized transaction is not deleted or rewritten, preserving a canonical audit trail. The first line of defense is preventative: permissioned participation, badge-based eligibility and transaction-level rules are designed to stop a non-compliant transfer before settlement.

Regulated finance also needs exception controls. SphereNet’s regulated-token architecture supports separate freeze, thaw and reconciliation authorities. Where the asset’s legal and governance framework permits it, an authorized issuer or compliance function can halt an account or execute a corrective reconciliation transfer. The corrective action is itself recorded on-chain. The goal is to combine final records with narrowly governed, transparent remediation powers.

Q11. What is SphereNet’s approach to upcoming milestones and their impact on the next-gen regulated stablecoin payments?

The near-term milestone is onboarding a select group of initial validator partners, which is happening now, ahead of a public launch in 2027. Alongside that there’s a version people can get their hands on for basic accounting and for testing the nested cryptography, and a mainnet for regulated entities, pending the licenses we need, which are their own gating item. I try not to oversell what any single milestone means, because the honest picture is that this is a deep and slightly stubborn tree, each branch tends to open up the next one, and I’d be suspicious of any story where a single launch changes everything overnight. What I hope it adds up to is regulated institutions being able to move money across borders on rails where the compliance and the record-keeping are already part of the design, so the parts that used to take weeks of back and forth feel closer to real-time.