Polygon Labs provided a detailed introduction to Open Money Stack, or OMS, on September 9. It puts identity verification, wallets, fiat on/off-ramp, conversion, cross-chain, and settlement into a single set of APIs. The goal is to let businesses avoid having to stitch together multiple vendors separately, so they can build dollar accounts, cross-border remittance, or stablecoin payment flows. The official breaks the capabilities into ten foundational modules: Send, Receive, Convert, Hold, Ramp, Bridge, Swap, Earn, Program, and Identity. Businesses can adopt the full workflow, or use only one layer.
There are few difficulties in paying—it's just sending a token from address A to address B. In reality, funds may enter from cash or a bank account, go through customer identification, exchange-rate locking, stablecoin conversion, inter-chain routing, and then end at another bank or a cash withdrawal point. Using different vendors at each step creates different account systems, error codes, settlement records, and customer-support boundaries. OMS tries to carry the whole process through with the same set of objects and transaction states, reducing repeated translation between the various vendors’ interfaces.
The ten modules cover the full funds journey—not just Polygon on-chain transfers.
Send and Receive handle fund dispatch and receipt; they can connect to on-chain wallets and also cover bank payments and cash entry. Convert locks exchange rates and executes conversions between fiat and stablecoins, as well as between stablecoins. Hold allows enterprises to keep fiat or stablecoin balances in the networks they need. Ramp connects RTP, ACH, same-day ACH, domestic wire transfers, SWIFT, debit cards, and retail cash. Bridge and Swap handle cross-chain movements and token exchanges, respectively. Program provides splitting, custody, approvals, and policy controls. Identity routes KYC and KYB to verification providers suitable for the customer’s region.
The settlement time information provided by the official source makes it clear that a “unified API” doesn’t mean “all payments settle instantly.” RTP is about one minute; ACH typically arrives by the next business morning; same-day ACH is within the same business day; domestic wire transfers are about one hour; SWIFT to an IBAN or a Canadian bank may be the same day or the next business day. On Polygon, on-chain settlement is about one minute; on Ethereum or Base, it’s about five minutes. These are typical timeframes under normal conditions—bank business days, compliance review, network congestion, and partner maintenance can still introduce delays.
OMS uses shared objects such as Customer, Wallet, Quote, Transaction, Counterparty, and External Account to record transactions. Quotes include fee breakdowns and an expiration time; the transaction moves from processing to completion via Webhook updates. A unified transaction ID helps with reconciliation and customer support: when a remittance gets stuck in the middle, the team can more easily identify whether the issue occurred in identity, conversion, the bank, or on-chain settlement—rather than opening tickets with each individual provider.
The compliance portion is selected by Identity: it chooses the region-specific KYC and KYB services, with sanctions and anti–money laundering checks running through every step of each flow. Current coverage includes the U.S. (48 states) and an expanding set of international corridors. Polygon Labs is responsible for the technical layer, while licensed partners handle verification, custody, virtual account issuance, and fund transfers. This responsibility split must be made clear to enterprise customers: a single API reduces the number of integrations, but it doesn’t eliminate payment licensing and compliance obligations.
A unified stack reduces engineering friction, but reliability, rate locking, and responsibility boundaries must be re-evaluated.
The most direct benefit of using a single interface is reducing integration and maintenance. The team doesn’t need to handle authentication, version upgrades, retries, and data models separately for each provider, so products can ship faster. Non-custodial wallets also support smart contract wallets, Gas sponsorship, batch transactions, and Smart Sessions: once a user authorizes a limited scope, the application can execute within that scope, reducing repeated confirmations at each step. OMS also supports x402 and ERC-8004 for proxy payments with quota control and on-chain identity.
Centralization also brings new dependencies. If the OMS interface fails, partner coverage changes, or a route is paused, multiple payment steps could be affected at the same time. Enterprises should confirm service levels, status pages, data exports, failure compensation, and migration plans to ensure that “missing seven providers” doesn’t turn into “no alternate exit.” Even though unified objects make reconciliation easier, the underlying banks, wallets, and chains may use different finality standards; the system must accurately express whether each step is pending, revocable, or already irreversible.
Routes span Ethereum, Polygon, Base, and Solana, but the functionality varies by network, and the official guidance also recommends that developers check the live network directory first. Polygon is recommended as the default settlement layer because of speed and cost; this doesn’t mean every customer, asset, and region fits the default route. Enterprises should choose based on liquidity, bridge risk, target network, and compliance requirements—not by comparing per-transaction Gas fees alone.
Fees also need end-to-end calculation. On-chain settlement may use very little in transaction fees, but fiat on/off ramps, cash-in/point collections, exchange rate spreads, identity verification, and refund processing still incur costs. The official mentions more than 50,000 retail cash locations and emphasizes that settlement costs may decrease as scale increases, but ultimately enterprises should judge based on the true total corridor cost and success rate. A cheap on-chain step can’t hide an expensive last mile.
A suitable launch approach is to first choose a specific corridor and fix the currency, amount range, and customer type. Measure account opening success rate, quote deviation, settlement time, failure rate, manual work tickets, and total cost, then gradually expand to more networks and modules. Each time you broaden scope, validate how the system handles Webhook loss, duplicate requests, expired exchange rates, and irreversible on-chain errors.
What’s publicly available for OMS is a set of composable payment infrastructure and the current coverage, but it doesn’t mean all countries, card types, and networks are fully supported everywhere. Officially, it’s clear that more countries and card options are still being rolled out gradually. It solves the engineering problem of stitching together multiple providers, but concentrates platform governance and partner risk. For enterprises, the real value won’t be determined by the slogan of “one API”; it depends on whether a payment can be consistently tracked, explained, and recovered in case of anomalies—from entry to exit.