Bank-issued stablecoins may be moving onto the agenda at major financial institutions, but issuing a token is the comparatively easy part. The harder problem is building a payment system that can determine—quickly, consistently and across jurisdictions—whether a transaction should be allowed.
Cointelegraph’s September 2 market briefing reported that Bank of America and Citi are planning stablecoin initiatives while Singapore and Thailand are considering crypto rules. The available report summary does not establish product specifications, launch schedules or the exact shape of those regulatory discussions. It does, however, put two related developments in the same frame: banks are exploring tokenized money as governments continue defining how crypto activity should operate.
That intersection matters more than another stablecoin announcement.
If regulated banks intend to move money on blockchain-based rails, compliance policies cannot remain buried in PDF manuals, fragmented databases and manual review queues. Payment software—and eventually automated financial agents—will need reliable, machine-readable answers about customer identity, transaction permissions and jurisdictional restrictions.
Without that layer, stablecoins can move faster than the institutions responsible for controlling them.
Token issuance does not create a payment network
A bank can technically issue a digital liability without solving the broader operational requirements of a usable payment system. The token contract may define balances, transfers, minting and redemption, but those functions cover only part of the product.
A functioning bank payment instrument also needs rules governing who can hold it, where it can circulate and what happens when a transfer creates a compliance or operational problem.
Those questions include:
- Which customers and businesses are eligible? - Can approved users transfer tokens to unverified wallets? - What identifying information must accompany a payment? - Which countries or counterparties require enhanced review? - How are sanctions and fraud controls applied? - Can a transfer be frozen, rejected or reversed? - What happens when two jurisdictions impose conflicting obligations? - Which institution handles a customer dispute?
Traditional banking systems already address versions of these problems, although often through a patchwork of messaging standards, account controls, compliance vendors and human escalation. Blockchain settlement changes the timing and architecture. A transaction can reach finality before a manual team has time to interpret an ambiguous alert.
That makes policy execution part of the core payment infrastructure.
Compliance has to become computable
“Machine-readable compliance” does not mean handing every decision to an opaque algorithm. It means expressing enough of a financial institution’s rules in structured, testable formats that software can apply them consistently.
Consider a business attempting to pay an overseas supplier with a bank-issued stablecoin. Before approving the transaction, the system may need to verify the sender, identify the recipient, determine the relevant jurisdictions, screen both parties and assess whether the destination wallet is eligible to receive the token.
The output cannot simply be “risk detected.” The payment system needs an actionable response: approve, reject, hold for review or request additional information.
Each decision also needs an audit trail. The institution should be able to identify which policy version was used, what data supported the result and whether a human overrode the automated decision.
This is particularly important when rules change. A payment allowed today might require additional checks tomorrow. Institutions need to know which policy applied when a transfer occurred rather than silently evaluating old transactions against new standards.
Crypto systems make this issue more visible because the settlement layer may be public or shared, while the compliance logic remains private and institution-specific. The challenge is connecting the two without exposing sensitive customer data or reducing every transaction to a slow manual process.
Identity cannot stop at wallet ownership
Wallet screening is often treated as a substitute for payment identity. It is not.
A blockchain address can show transaction history, but it does not necessarily establish who controls the wallet, who benefits from a payment or what commercial purpose the transfer serves. Addresses can also change, and one organization may operate many of them.
Banks therefore need an identity layer that connects customers and authorized counterparties to permitted payment activity. That does not require putting names, documents or confidential business data directly on a public blockchain. It could involve credentials or attestations that allow a system to verify a relevant claim without publishing the underlying information.
For example, a payment application may need to confirm that a recipient passed required checks through an approved institution. The application may not need unrestricted access to the recipient’s full identity file.
The difficult part is governance. Institutions must decide who can issue a credential, how long it remains valid, when it can be revoked and whether another institution or jurisdiction will recognize it.
An identity credential accepted by one bank is not automatically portable across the financial system. A shared technical format helps, but legal recognition and liability still determine whether another institution can rely on it.
Regional rules can fragment one token into several products
The mention of regulatory activity in Singapore and Thailand highlights another infrastructure problem: a stablecoin may be globally transferable at the protocol level while remaining locally constrained as a financial product.
A bank could respond by limiting circulation to a closed group of verified customers. That approach simplifies some controls but also reduces interoperability. Alternatively, it could allow broader transfers while adding restrictions based on wallet status, customer category or jurisdiction.
Either model can produce fragmentation.
The same token may function differently depending on where a user resides, which bank provides access and what type of transaction is being attempted. A corporate treasury transfer, retail payment and exchange deposit may trigger different controls even when they use the same blockchain.
Developers and businesses should therefore be cautious about treating token compatibility as product compatibility. Two wallets may support the same network and token standard but still be unable to transact because their identity and compliance systems do not recognize each other.
The integration work moves above the blockchain: permissions, credentials, policy engines, reporting and exception handling.
Automated payments raise the standard further
The problem becomes more urgent when software agents are allowed to initiate payments.
An automated purchasing tool could theoretically monitor inventory, choose a supplier and submit a stablecoin transfer without waiting for an employee to approve each step. But that system needs more than access to a wallet. It requires defined spending authority, verified counterparties, transaction limits and a reliable method for handling exceptions.
An AI agent should not be expected to interpret an evolving stack of legal documents every time it pays an invoice. It needs structured permissions and current policy data. Just as importantly, the bank must be able to distinguish an authorized automated action from a compromised credential or malfunctioning workflow.
This creates demand for infrastructure that connects organizational identity, agent identity and transaction authority. A business may authorize an agent to pay one supplier up to a specified amount but prohibit transfers to newly created addresses or unfamiliar jurisdictions.
Programmable money is useful only when its permissions are equally programmable.
What businesses should watch
For retail users and small businesses, the most consequential stablecoin developments may not be token launches. The important signals will be operational.
Does the product support direct redemption? Are eligible users and jurisdictions clearly defined? Can businesses reconcile payments with invoices? What information must recipients provide? How are blocked or mistaken transfers handled? Can the stablecoin move outside the issuer’s application without losing support?
Those details determine whether a bank stablecoin becomes useful working capital or another restricted balance inside a branded platform.
The reported interest from major banks suggests that tokenized payments remain an active area of development. The simultaneous attention from regulators is not a separate storyline. It is part of the same infrastructure challenge.
Stablecoins can make settlement programmable, but they do not automatically make identity, compliance or accountability programmable. Until those systems work together, bank-issued tokens will remain closer to controlled experiments than universal payment rails.