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

As stablecoins gain traction and AI agents handle more financial activity, payment infrastructure faces new questions about 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 agents make more payments instead of people, stablecoins could help them move money because they settle quickly and operate around the clock. SphereNet is being prepared for that use case.

It is a semi-permissioned network where participants are vetted before they transact. Compliance checks are built into the payment process. The network can check identity, sanctions, counterparties and other requirements before a payment settles, rather than reviewing the transaction only after it goes through.

This also reduces friction in traditional payment systems, where banks and other institutions often repeat the same checks and reconstruct events later. SphereNet keeps a record of those checks for authorized institutions to review.

Post-transaction monitoring will still be needed, especially when suspicious activity becomes clear only over time. The aim is to catch more problems before the money moves instead of fixing them afterward.

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

SphereNet plans to complete identity and compliance checks before finalizing a payment. The relevant parties must be 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 it operates. After verification, the network does not need to store identity documents or other sensitive information. Instead, it can use an attestation or proof that confirms the customer passed the required checks.

Approved issuers can create, update, expire or revoke these attestations. 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. These would let institutions prove that a customer meets a requirement without sharing the underlying information on the network. SphereNet records these checks and changes for auditing, while the institution remains responsible for ensuring that its customers and transactions comply with 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 plan for mistakes and deliberate attacks. An attacker may find a prompt, data source, credential or workflow that exposes a weakness the designers did not anticipate.

Businesses should set strict limits on what agents can access and authorize. Those limits can cover transaction amounts, counterparties, time periods and the people or organizations the agents represent. Companies will also need to prepare for prompt injection, manipulated data, stolen credentials and other attempts to influence an agent’s decisions.

Cross-border transactions add complexity because financial, sanctions, licensing, data and consumer-protection rules differ between countries, even though an 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 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. The system should limit the consequences when that happens.

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 both cases.

An AI agent acts through a wallet controlled or authorized by an onboarded person, business or regulated institution. That creates 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.

The transaction is subject to the same enforcement rules whether it was initiated manually or by software. Wallet actions and credential states are recorded on SphereNet’s shared ledger, creating a traceable, tamper-evident and independently auditable record for authorized parties.

SphereNet provides transparency and auditability through identity, attestations and transaction history. It does not rely on 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 apply identical rules to every authorized wallet.

An issuer could also treat human- and AI-controlled wallets differently. It could 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. SphereNet would not make 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 human or multi-party approval must remain in the process, 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 credibility not only from its claims, but also from who is willing to operate it. The participants at the base layer matter as much as the architecture.

Deutsche Telekom has joined SphereNet as one of our earliest validator partners. It is running node infrastructure across testnet and mainnet through the same subsidiary that already validates for a range of established networks.

That broadens the group of independent, vetted operators securing the base layer. An operator experienced in running regulated infrastructure at that scale is also well suited to a network where the rules are built into the rail.

A partner of that standing choosing to invest early and build alongside us, rather than watch from a distance, is also a meaningful signal to the licensed institutions we are onboarding next. 

Telecoms have carried money and messages across borders for well over a century. There is a clear fit in helping them run this kind of network.

What I care about most at this stage is building with partners who can help us create 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 builds the same checks that another firm has already built. It confirms that the person is who they say they are, that they may hold the product and that they are not on a sanctions list.

Each institution then stores the documents and carries the liability for that data. This is a task every financial company must perform, but it is not an area where they compete. Rebuilding it in-house a thousand times over never made much sense.

On SphereNet, an institution can use a check that already covers the requirement. It works much like a developer using a well-tested library instead of writing encryption from scratch.

Onboarding becomes an integration rather than a build. Everyone in the environment is already a vetted, regulated entity. Someone verified once can meet the same requirement at the next service without handing over their information again.

The business gains access to a larger pool of already-verifiable customers and has less data to protect.

We enable adoption by making blockchain-based payments an institutional integration. Banks and enterprises do not have to build the full stack themselves.

To note, SpherePay already provides APIs, SDKs and dashboards for onboarding, KYC/KYB, fiat and stablecoin movement, and transfer-status management. Institutions can integrate payments without building custody, chain routing and corridor operations from scratch.

SphereNet, currently in testnet, is designed to extend that approach to settlement and asset policy.

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.

For each asset, an issuer can require 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 enforces 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 an AI agent initiates a transaction. The issuer of each asset defines the conditions under which that asset may move.

Those conditions can cover jurisdictions, counterparties, credentials, attestations and approvals. The 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. Where an issuer-recognized credential or authorization identifies the difference, it may 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. 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 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, which produces deterministic outcomes.

People at the asset issuer or relevant regulated institution create and authorize those policies 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 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. I don’t want to wave that away; it’s a genuine constraint.

The response is to move more care before settlement. SphereNet is a semi-permissioned environment where every participant is vetted and regulated, and compliance checks are built into the rail.

Those checks run while the money is moving, and the record is written as it happens. When something needs to be examined, a bank partner or regulator can inspect a canonical, cryptographically verified record on their own.

Accountability therefore does not rest on one 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 and 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. That is happening now, ahead of a public launch in 2027.

Alongside that, there’s a version people can use for basic accounting and testing the nested cryptography. There is also 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. This is a deep and slightly stubborn tree, and each branch tends to open the next one. 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 compliance and record-keeping are already part of the design. The parts that used to take weeks of back and forth could feel closer to real-time.