On October 23, 2026, the Monetary Authority of Singapore (MAS) announced that Bank Negara Malaysia (BNM) and the Bank of Thailand (BOT) have joined BLOOM as policymaker members. The three central banks will work with financial institutions, payment networks and technology service providers to study how digital currencies can be accepted, exchanged and settled across institutions, networks and jurisdictions.
BLOOM has previously discussed tokenized bank deposits, regulated stablecoins and wholesale digital settlement. The change this time is not that a few more trial participants have been added, but that the project has begun to address common rules across multiple jurisdictions: local regulatory requirements are not entirely the same, yet digital currencies must still enter real contractual, bank account, foreign exchange management, anti-money laundering and dispute resolution systems.
The official announcement sets out three work streams: cross-jurisdictional acceptance and settlement, interoperability between different digital currency arrangements, and programmable controls such as identity verification, sanctions screening and transaction controls. The project covers payments, corporate treasury and trade finance, and brings in participants including banks, card organizations, payment institutions, stablecoin-related enterprises and the World Bank Group.
These arrangements remain collaborative projects and policy exploration; they do not mean that the three countries have already adopted a unified set of digital currency laws, nor do they mean that products participating in the project have obtained cross-border operating licenses. For Chinese enterprises, the focus should shift from "which currency is faster" to "how multiple sets of rules work together to complete a payment."
Moving from single-network trials to cross-jurisdictional allocation of responsibility
Where tokenized deposits are used within a single bank, the issuer, customer relationship, ledger operation and redemption channel are usually concentrated in the same system. Once funds enter a cross-border scenario, the structure quickly unfolds: the payer may hold tokenized deposits issued by a Singapore bank, the payee uses a Malaysian account, foreign exchange conversion is completed by another institution, and the Thai supplier wishes to receive local currency or a locally acceptable digital currency.
Technology can enable multiple steps to be executed simultaneously, but it cannot eliminate the legal identity of each participant. What obligations the issuing bank bears in respect of deposits, whether a stablecoin issuer opens direct redemption to overseas enterprises, whether a payment institution may provide exchange or transfer services to cross-border customers, and at which bank or under which market infrastructure final settlement is completed, all need to be answered separately.
BLOOM's separation of "acceptance, exchange and settlement" for discussion precisely shows that on-chain transfer is not a single-point action.
Acceptance concerns whether the payee and its service providers are willing, and also whether they are qualified, to accept a certain digital currency; exchange concerns how conversion and transfer occur between different currencies, different issuer liabilities or different networks; settlement concerns when a transaction becomes irrevocable, when the payment obligation is extinguished, and how final funds are delivered between financial institutions. The three may occur at different times and be controlled by different entities.
If an enterprise merely writes "payment in digital dollars" in a contract, it still does not specify which issuer's product is used, on which network the transfer occurs, who bears the conversion cost, and whether payment is completed when the payee receives tokens or when local currency is credited to the account.
Interoperability is not about merging three sets of regulatory rules into one
The Bank of Thailand's publicly described tokenization work shows that its Project SAN focuses on connections between different distributed ledgers and traditional centralized infrastructure, and tests cross-border payments for payment, delivery versus payment and payment versus payment in foreign exchange. BLOOM further incorporates different types of settlement assets and market participants.
Interoperability can reduce duplicate integrations and manual reconciliation, but what it addresses first is how networks communicate; it does not automatically harmonize the licensing, foreign exchange, client money protection, insolvency, data and tax rules of the three countries.
A single digital payment among Singapore dollars, ringgit and Thai baht may involve at least four layers of constraints:
- Product layer: whether the token represents a bank deposit, a stablecoin redemption right, or another contractual claim;
- Institutional layer: who separately provides issuance, custody, exchange, wallet and payment services, and which activities and clients the licenses cover;
- Transaction layer: whether the trade background, use of funds, invoices, logistics, foreign exchange declarations and tax materials can corroborate one another;
- Network layer: which system records instructions, which node completes final settlement, and how recovery is effected after errors, freezes or system outages.
The project proposes to develop an implementation framework and coordinate commercial and operational arrangements, with the aim of reducing the cost to financial institutions of building separate connections for each counterparty or market. This helps with scaling, but it does not mean participants can rely on a single master agreement to handle all issues. Regulatory requirements that cannot be waived through project arrangements in each jurisdiction still need to be implemented under local rules and specific licenses.
Programmable controls embed compliance into payments, but responsibility for judgment remains with people and institutions
BLOOM identifies identity verification, sanctions screening and transaction controls as the focus of programmable controls. For trade finance and corporate treasury, this may place some compliance conditions in the same process as payment instructions: the system executes payment only after the identities of the buyer and seller have passed verification, the documents are complete, the limit has not been exceeded, or delivery conditions have been met.
This design can reduce omissions, but it also creates new boundaries of responsibility.
First, who provides identity and beneficial ownership information. Enterprises, account-opening banks, payment institutions and wallet service providers hold different information. If upstream data is incomplete, a smart contract that accurately executes the wrong conditions may still produce a non-compliant outcome.
Second, who is responsible for updating lists and rules. Sanctions lists, high-risk countries, transaction thresholds and license scope may change, and the code needs continuous maintenance. Project participants should agree on update frequency, data sources, emergency shutdown and human review authority.
Third, who preserves the decision-making process. A system showing "screening passed" is insufficient to respond to subsequent investigations. Enterprises need to know which list version was used, when screening occurred, which names and control relationships were compared, who handled suspected hits, and whether information changed before or after payment.
Programmable payments can automatically execute conditions, but cannot replace judgment regarding transaction purpose, actual control, nature of goods, and anomalous conduct. The more automated cross-border payments become, the more necessary it is to retain clear manual escalation and evidence preservation mechanisms for exceptional transactions.
Realistic scenarios for Chinese enterprises: regional treasury and trade finance
A Chinese enterprise establishing a regional headquarters in Singapore, operating a manufacturing base in Malaysia, and procuring raw materials from Thailand is a typical structure that the multi-currency, multi-network environment discussed by BLOOM may reach.
A group treasury center may wish to use tokenized deposits to pool liquidity and reduce settlement waiting times between different banks; a trade platform may wish to make automatic payments when electronic documents satisfy conditions; and suppliers are concerned with whether the digital currency received can be immediately converted into local currency and enter a disposable account. These three needs are not the same.
Intra-group fund transfers must also be distinguished from external trade payments. The former involves capital account matters, related-party transactions, transfer pricing, and cash pooling arrangements, while the latter requires contracts, invoices, logistics, and customs declarations to correspond with one another. Even if the same technology platform supports both types of transactions, an enterprise cannot process them using the same business labels and approval paths.
The Mainland China regulatory connection also cannot be ignored. An overseas subsidiary participating in a locally regulated tokenized deposit project is not the same issue as providing stablecoin trading, exchange, or promotional services to customers within the mainland. Groups should review the locations of decision-makers and operations personnel, sources of funds, customer targets, system access, data return, and whether domestic entities participate in fee collection or marketing, so as to avoid mistakenly treating an overseas compliant product as a service that can be extended unconditionally into the mainland.
Trade finance scenarios also require examination of financing rights. If payments, bills of lading, or receivables are represented in tokenized form, whether the bank obtains control over digital records, an assignment of receivables, or a traditional security interest must be confirmed under the contract and applicable law. A technical "lock" does not automatically equate to priority effect against third parties.
Six documents enterprises should review during the pilot phase
When a participating bank or technology institution proposes a BLOOM-related solution, the enterprise may require the formation of six reviewable documents.
The first is a participant and licensing map. It should list the issuer, account bank, wallet, exchange institution, network operator, settlement institution, and data service provider, and explain the activities each is permitted to conduct in Singapore, Malaysia, and Thailand.
The second is a funds and liabilities map. It should identify what rights the enterprise holds at each step, when funds convert from bank deposits into tokenized deposits or stablecoins, when foreign exchange conversion occurs, and who ultimately bears redemption liability.
The third is a contract matrix. It maps customer agreements, issuance terms, network rules, exchange arrangements and underlying trade contracts to one another, and addresses the timing of payment completion, fees, exchange rates, erroneous addresses, suspension, freezing, redemption and insolvency.
The fourth is a compliance responsibility matrix. It confirms who performs KYC, KYB, beneficial ownership identification, source-of-funds checks, sanctions and anti-money laundering screening, transaction monitoring and suspicious activity reporting, and how duplicative reviews and information conflicts are resolved.
The fifth is a data and evidence inventory. It preserves authorizations, wallet attribution, payment conditions, rule versions, screening logs, on-chain records, bank credits, exchange records and underlying transaction documents, and specifies cross-border data access, retention periods and regulatory access.
The sixth is a failure and exit plan. It tests whether, in the event of network interruption, tokens that cannot be redeemed, counterparty refusal, erroneous payment, list matches or changes in local rules, the parties can switch back to traditional banking channels, and how incomplete transactions are cancelled or redone.
These six documents bring the risks closer to something an enterprise can manage than a technical architecture diagram does. They convert network commitments into entities, rights, funds and evidence, and preserve verifiable materials for bank credit, audits and dispute resolution.
Differences from existing articles
An article on this website dated October 10 discusses whose liabilities tokenized deposits, regulated stablecoins and wholesale central bank digital currencies respectively are, and when on-chain records constitute final settlement. The new question raised by the BLOOM progress is how three central banks and multiple market participants can make different digital currencies accepted, exchanged and settled across jurisdictions.
The earlier article focused on the legal identity of settlement assets and exit paths; this article focuses on contracts, licences, foreign exchange, compliance controls and the division of evidentiary responsibilities in multi-jurisdictional interoperability. As BLOOM expands from a Singapore project into policy collaboration among Singapore, Malaysia and Thailand, enterprises need to review not "which digital currency to choose" but "how multiple regimes jointly handle a single transaction".
Conclusion
BLOOM has not yet provided a cross-border channel that can immediately replace the traditional correspondent banking network, nor has it created a cross-border operating passport for participants. It offers an observation window closer to commercial implementation: once digital currencies enter regional payments, the difficulty lies not only in connecting ledgers, but in whether different institutions and different jurisdictions can form common practices on acceptance, exchange, settlement and risk management.
For Chinese enterprises, the value of the pilot should not be measured only by settlement speed and fees. Whether each step's debtor and regulatory authority can be identified, whether the trade and funding background can be proven, whether compliance information remains continuous across different networks, and whether, when a transaction fails, the parties can return to enforceable contracts and traditional accounts — these are what determine whether cross-border digital currencies can become reliable treasury infrastructure.
Main references
- Monetary Authority of Singapore, MAS, Bank Negara Malaysia and Bank of Thailand Partner with Industry to Advance Cross-Border Settlement in Digital Money through BLOOM, 23 October 2026：Official announcement。
- Monetary Authority of Singapore, BLOOM, updated 23 October 2026：Project page。
- Bank of Thailand, Tokenization — Interoperability Initiatives and Cross-Border Collaboration：Official project description。
- Monetary Authority of Singapore, Building Trusted Foundations for Digital Finance, 9 October 2026：Policy speech。
The information in this article was verified as of October 24, 2026. BLOOM is a policy and industry collaboration project and does not constitute a uniformly effective cross-border digital currency law or licensing arrangement. This article is provided for general information sharing only and does not constitute Singapore law, Malaysian law, Thai law, PRC law, foreign exchange, payment, tax, digital asset or investment advice specific to any particular project.
