Skip to content
Independent XRP reference
Our standards
← All XRP news

Ripple

BLOOM Adds Malaysia and Thailand: What It Means for Ripple’s RLUSD Pilot

Two central banks join Singapore’s digital-money initiative. Ripple’s earlier RLUSD pilot shows why trade conditions and cross-border acceptance need separate proof.

By
A pale-gold folding thread-pitch gauge with three cobalt toothed leaves rests beside a separate threaded stud on ivory stone.

What changed in Singapore’s BLOOM initiative?

Malaysia’s and Thailand’s central banks have joined Singapore’s BLOOM digital-money initiative, expanding policy coordination around cross-border settlement. Ripple already participates through a planned RLUSD and XRP Ledger trade-finance pilot with Unloq. The October 23 announcement establishes broader cooperation, but does not announce a live regional RLUSD payment service or XRP purchases.

Confirmed: the Monetary Authority of Singapore’s October 23, 2026 release names Bank Negara Malaysia and the Bank of Thailand as new policymaker members. Its participant list also includes Ripple, Visa, Mastercard and the World Bank Group. FinanceFeeds independently reported the expansion that day. These organisations have different roles; sharing a participant list does not make every pair a commercial partner.

For Ripple followers, the useful change is the addition of policy counterparts from neighbouring markets to the same settlement discussion. The release concerns frameworks and operating arrangements. Its relevance should therefore be judged through the problems those arrangements could resolve, rather than treating the names of central banks as evidence of immediate transaction demand.

Section sources[1][3]

Ripple and Unloq’s RLUSD pilot predates the expansion

Ripple announced its BLOOM participation on March 25, 2026. The company described a pilot with supply-chain technology provider Unloq, combining the SC+ trade-finance platform, RLUSD and the XRP Ledger. CoinDesk and Cointelegraph reported the same design. October’s membership update is therefore a new regional policy development around an existing announced experiment, not Ripple’s first entry into BLOOM.

In that design, a commercial condition such as verification of a shipment can trigger a payment. Unloq’s platform brings the trade obligation and its financing workflow together; the announced settlement arrangement uses RLUSD. That is a specific proposed use of a dollar stablecoin. It does not establish that the invoice must be funded by purchasing XRP or that a receiving business accepts XRP as its payment asset.

The chronology matters for evaluating progress. A March statement about what a pilot will do cannot serve as October evidence of completed trades. Readers should look for a subsequent result identifying which part of the workflow was actually exercised: checking the shipment, authorising payment, transferring the settlement asset, or making usable money available to the seller. Each answers a different operational question.

Section sources[4][5][6]

Shipment verification and successful payment answer different questions

Analysis: the most revealing test of conditional trade settlement is a disputed condition, not a perfect demonstration. Consider a hypothetical exporter whose contract permits payment after delivery verification. One system records that a shipment arrived, but the buyer disputes whether the agreed goods were delivered. Moving money automatically cannot itself decide which evidence the contract recognises or who has authority to resolve the disagreement.

This example is not a reported BLOOM transaction. It illustrates the work hidden inside the phrase “commercial conditions.” A production arrangement would need to define the approved evidence provider, the exact event that authorises release and a response when data arrives late or contradicts another record. Operators should also be able to distinguish a rejected condition from a payment that was authorised but has not completed.

Ripple’s March announcement supplies the condition-based premise, independently corroborated by Cointelegraph. It does not publish the full dispute-handling specification. For a business considering such a service, a useful demonstration would include an exception: missing shipment evidence, an invalid recipient or a duplicate instruction. Showing how a system safely stops and resumes would teach more about readiness than repeating an uncomplicated transfer.

Section sources[4][6]

BLOOM must connect acceptance rules as well as networks

MAS’s October 23 initiative page describes work on acceptance and settlement, interoperability, and programmable controls. The controls include identity checks, sanctions screening and transaction restrictions. FinanceFeeds corroborates those workstreams. The central distinction is between moving a digital asset across infrastructure and having a counterparty accept that asset as satisfaction of an obligation.

Analysis: imagine that the exporter is willing to receive a local-currency bank deposit while the payer holds a dollar stablecoin. A working technical connection is only one part of the transaction. The proposed service still needs an agreed conversion, a party responsible for delivering the receiving asset and a clear point at which the original invoice is considered paid. The example assumes different preferences; it does not describe a disclosed BLOOM corridor.

This is where policy coordination can have practical value. Teams can test a common transaction description against the requirements of each market instead of assuming the sending market’s answer applies everywhere. MAS says the work will allow differences in local requirements. That makes the question of which conditions travel with a payment especially useful: which checks are recognised, which must be repeated and which institution remains accountable for the result?

Section sources[2][1][3]

What this changes for XRP readers and treasury teams

Inference: broader policymaker participation gives Ripple’s proposed trade workflow a more relevant environment for examining cross-border acceptance. It does not select Ripple as the exclusive infrastructure provider. The MAS list includes multiple banks, stablecoin businesses and payment networks. Participation can expose a design to more counterparties, but an eventual customer would still need to evaluate the actual service offered.

For XRP readers, keep three identifiers separate: Ripple is the company participating; RLUSD is the stablecoin named in its trade-payment plan; the XRP Ledger is the network named in that plan. Evidence about one does not establish a commercial outcome for all three. Neither the October MAS release nor Ripple’s March pilot announcement supplies a new XRP purchase commitment. A price snapshot would add no evidence about whether the trade workflow works.

For treasury teams, the next useful comparison is between two complete payment journeys. Record the starting asset, the recipient’s usable ending balance, required prefunding, approval steps and exceptions. Compare those under equivalent conditions. A faster blockchain transfer would be valuable, but the relevant business outcome is an invoice discharged and funds available where they are needed. That is the level at which any claimed improvement should be tested.

Section sources[2][4][5]

The evidence that would turn coordination into a deployable service

Unresolved: the reviewed announcements do not establish a commercial launch timetable for a three-country RLUSD service, completed Ripple-Unloq pilot volume or a bank-by-bank rollout. Those are not minor missing statistics. They determine whether a company is evaluating a research design, a controlled test or a service it can procure. They should remain separate entries in any assessment.

A practical next disclosure would connect a named test to an outcome. It would identify the participating institutions and currencies, explain the settlement condition, report whether the recipient obtained the intended asset and describe any failed attempts. Results should distinguish simulated funds from transactions with actual commercial obligations. The appropriate comparison would include the existing process, not just an isolated transfer time.

For small exporters, the decisive improvement would be less uncertainty about when they can use their proceeds and what happens if a shipment or payment is challenged. For operators, it would be a repeatable process with clear responsibility at each handoff. BLOOM’s expanded policy membership creates an opportunity to work on those questions. The next milestone worth reporting is evidence that a particular arrangement answers them, with its limits made explicit.

Section sources[1][3][4][6]

What to watch next

  • • A published BLOOM implementation framework specifying asset acceptance, settlement responsibilities and treatment of different local requirements.
  • • A dated Ripple-Unloq result distinguishing shipment verification, payment authorisation, ledger settlement and the recipient’s usable balance.
  • • Named currencies, institutions and corridors for a concrete trial, with test transactions separated from completed commercial payments.
  • • Disclosed exception handling for disputed shipment evidence, duplicate instructions and unavailable counterparties.
  • • Any later customer launch or XRP-use claim supported by actual service terms, asset flows and transaction evidence.

Sources and verification

We prioritize primary records and label supporting coverage. Dates reflect each source’s publication record.

  1. [1]MAS: Malaysia and Thailand join BLOOM as policymaker membersprimary
  2. [2]MAS: BLOOM objectives, workstreams and participant listprimary
  3. [3]FinanceFeeds: Rick Steves on BLOOM’s cross-border expansionsupporting
  4. [4]Ripple: BLOOM participation and Unloq trade-finance pilotprimary
  5. [5]CoinDesk: RLUSD shipment-triggered trade-finance pilotsupporting
  6. [6]Cointelegraph: Zoltan Vardai on Ripple and Unloq’s pilot designsupporting