How Stablecoins Move Money Across Borders
Stablecoins can make the cross-border settlement leg faster and more programmable, while USD funding, FX conversion, PHP liquidity, compliance, local payout, and beneficiary-account credit remain essential parts of delivering money across borders.
1. Why Cross-Border Payments Take So Long
2. How Stablecoins Move Money Across Borders
3. How Cross-Border Payments Trap Working Capital
4. What You Must See Before You Move Money Through a Provider
5. What Licenses You Need to Move Stablecoins Into Philippine Pesos
5. When to Build Your Own Payout Infrastructure
Accept payments from Filipino customers without a Philippine entity.
Most global companies stall in the Philippines for one reason: local acceptance requires local infrastructure. An entity, a resident agent, a bank account you cannot open remotely, and months of setup before the first peso clears.
PayMongo is the licensed local endpoint. One integration, one contract, settlement and compliance handled under our Philippine licence.
PayMongo is regulated by the Bangko Sentral ng Pilipinas.
Stablecoins compress the cross-border settlement leg. They do not eliminate FX, endpoint liquidity, compliance, payout operations, customer support, or reconciliation across the full payment lifecycle.
A USD-to-PHP stablecoin payout remains a fiat-to-fiat payment. The recipient receives PHP only after a regulated off-ramp converts stablecoin value, sources pesos, validates the payout, and obtains a successful beneficiary-account credit.
The stablecoin sandwich
The operating model contains six distinct functions:
A stablecoin transaction transfers a token between blockchain addresses. A PHP payout creates a peso-credit outcome in an identifiable beneficiary account. These are related events. They are not the same event.
The settlement leg can become continuous and near-real-time. The endpoint legs remain governed by banking hours, regulatory controls, available PHP liquidity, local payout-rail availability, beneficiary-account status, and exception handling.
Worked example
The payment begins with a $10,000 USD instruction and ends with PHP delivered to a Philippine beneficiary. The example preserves the same nominal value from Essay 1. The applicable FX rate, spread, conversion fees, and payout fees remain commercial variables.
| Stage | Conventional fiat route | Stablecoin settlement route | Record created | Primary owner |
|---|---|---|---|---|
| 1USD funding | Funds collected The sender’s USD account is debited or the platform collects USD through its funding method. | Funds collected The sender’s USD account is debited or the platform collects USD through the same funding method. | Funding instruction, USD ledger debit, customer receipt, funding-status event. | Owner: Sender-side bank, payment service provider, or platform. |
| 2Compliance review | Customer and payment screening The sender, beneficiary, transaction purpose, and payment pattern undergo KYC, AML, sanctions, and fraud checks. | Adds wallet screening The same customer and transaction controls apply. Wallet and blockchain-address screening adds a distinct control layer. | Screening result, risk score, compliance case, approval or hold decision, audit log. | Owner: Platform, sender-side PSP, and regulated counterparties. |
| 3Value conversion | FX or internal netting USD value is held, netted, or converted using correspondent-bank and FX-provider arrangements. | USD becomes USDC An eligible entity purchases USDC or tokenizes USD into USDC through an issuer account, exchange, or liquidity provider. | FX trade or tokenization record, conversion quote, fee record, wallet or account credit. | Owner: Issuer, exchange, treasury desk, liquidity provider, and platform. |
| 4Cross-border settlement The changed leg | Bank-to-bank movement Correspondent banks exchange messages and settle through bank accounts and established payment infrastructure. | Wallet-to-wallet movement USDC moves from an approved sender wallet to an approved receiving wallet on a supported blockchain network. | Payment message or SWIFT reference; blockchain transaction hash; custody record; confirmation record. |
Fiat: Correspondent banks. USDC: Custodian, wallet provider, and blockchain network. |
| 5PHP liquidity and conversion | PHP made available The destination partner receives, nets, or converts value and makes PHP available from its local liquidity position. | USDC becomes PHP The off-ramp accepts USDC, performs required screening and confirmation, then sells or redeems USDC and makes PHP available. | PHP liquidity allocation, FX execution, redemption or sale confirmation, local ledger credit. | Owner: Philippine liquidity provider, bank, regulated off-ramp, or local PSP. |
| 6PHP payout | Local disbursement The destination partner submits a PHP disbursement through a bank, e-wallet provider, or domestic transfer rail. | Same local disbursement The same local PHP disbursement occurs after USDC has become usable PHP liquidity. | Payout instruction, rail reference, acceptance or rejection event, beneficiary-credit confirmation. | Owner: Local payout provider, beneficiary bank, e-wallet operator, or Philippine payment rail. |
| 7Customer support and reconciliation | Fiat lifecycle matched Operations reconciles funding, FX, intermediary settlement, payout, returns, and customer ledger entries. | Full lifecycle still matched Operations reconciles funding, conversion, wallet movement, on-chain confirmation, redemption, PHP payout, and customer ledger entries. | Reconciliation event, support case, exception code, return or recovery workflow, final payment status. | Owner: The platform owns the customer promise and coordinates all vendor exceptions. |
The stablecoin version changes stage four. It partially changes stage three and stage five. It does not eliminate stages one, two, six, or seven.
What moves and what does not
The stablecoin leg transfers USDC between controlled wallet addresses. It replaces some correspondent-bank movement with a blockchain settlement event.
The sender still funds in USD. The receiver still expects PHP. The off-ramp still needs PHP liquidity. The payout partner still needs correct beneficiary details. The local bank or e-wallet still needs to credit the account.
Circle’s USDC terms formalize the conversion boundary. Direct USD tokenization and USDC redemption require a Circle Mint account in good standing. Direct redemption occurs at one USD per USDC less applicable fees, subject to eligibility, account status, contractual terms, and legal or regulatory restrictions.[1]
Circle publishes USDC reserve holdings weekly and publishes third-party monthly assurance over reserve sufficiency. These disclosures support counterparty diligence. They do not remove the platform’s exposure to redemption access, issuer operations, banking arrangements, market liquidity, or off-ramp execution.[2]
A platform should define payment states that distinguish actual operational reality:
- USD funded: The platform has received cleared or usable sender funds.
- Compliance approved: The payment has passed or exited required risk review.
- USDC converted: USD has been converted or tokenized into USDC.
- USDC broadcast: A valid transaction has been sent to the blockchain network.
- USDC confirmed: The transaction has met the required confirmation threshold.
- Off-ramp accepted: The destination counterparty recognizes the USDC receipt and accepts the conversion obligation.
- PHP available: The off-ramp has secured PHP liquidity.
- PHP submitted: A payout instruction has entered the local payout rail.
- Beneficiary credited: The recipient bank or wallet has credited the account.
- Reconciled: All participant and internal-ledger records match.
“USDC confirmed” is not “beneficiary credited.”
What Stablecoin Settlement Changes — and What It Does Not.
| Measure | Fiat baseline | Stablecoin route | What improves | What remains |
|---|---|---|---|---|
|
01
Settlement speed
Time required to move value between liquidity providers.
|
Bank operating model Settlement depends on intermediary-bank processing, payment cut-offs, time zones, correspondent routing, and destination-bank operations. | Always-on settlement USDC can move 24/7 between approved wallets, subject to network availability and the receiving operator’s confirmation policy. | Gain The cross-border transfer between liquidity providers can compress from bank operating windows to minutes. High impact | Still owned Funding availability, compliance review, USDC redemption, PHP liquidity, payout cut-offs, and beneficiary-bank posting still determine end-to-end delivery time. |
|
02
FX cost
Spread, conversion cost, and the cost of moving value across the corridor.
|
Layered corridor pricing FX can absorb pricing from banks, correspondent relationships, destination providers, and embedded liquidity costs. | More direct treasury movement The stablecoin leg can reduce some intermediary movement costs and enable more direct treasury rebalancing. | Gain Fewer cross-border banking hops can reduce settlement friction and improve pricing transparency. Medium impact | Still owned USD-to-USDC and USDC-to-PHP conversion still require FX execution, spreads, fees, and local liquidity pricing. |
|
03
Liquidity burden
Capital held across accounts, currencies, markets, and operating hours.
|
Pre-funded balances Providers hold or pre-fund balances across bank accounts, currencies, and destinations. | Faster value rebalancing Providers can move dollar-denominated settlement value on-chain and rebalance more frequently. | Gain The model can reduce trapped-balance pressure in corridors where USD stablecoin liquidity is deep and off-ramps are reliable. Medium impact | Still owned The receiving side still needs sufficient PHP liquidity to complete a local payout at the promised rate and time. |
|
04
Reconciliation load
The effort required to prove every leg of the payment completed correctly.
|
Fragmented payment evidence Operations matches payment messages, bank statements, correspondent records, FX execution, local disbursement, returns, and internal ledgers. | On-chain settlement reference Operations gains an immutable transaction reference for the on-chain leg but adds conversion, custody, wallet, and confirmation records. | Gain A transaction hash creates a shared, time-stamped reference for the stablecoin transfer. Mixed impact | Still owned The operator must reconcile USD funding, conversion, USDC movement, redemption, PHP payout, fees, returns, and beneficiary credit. |
|
05
Exception rate
The frequency and operational severity of payment failures and holds.
|
Correspondent and payout exceptions Failures arise from intermediary routing, cut-offs, compliance holds, liquidity gaps, bank-data errors, and local payout rejection. | Different exception set Correspondent-routing exceptions can decline. Address errors, chain congestion, wallet-control failures, blockchain screening alerts, and unsupported-token events enter the failure set. | Gain The stablecoin leg removes some intermediary-bank handoffs and can make settlement-state visibility stronger. Mixed impact | Still owned Off-ramp failure, beneficiary-data errors, local rail downtime, compliance holds, and recipient-bank rejection remain decisive. |
Stablecoins perform best where the core bottleneck is moving value between regulated liquidity nodes. They underperform the marketing claim when the core bottleneck sits at the endpoints.
A PHP payout remains constrained by local payout capacity. A beneficiary account can remain unavailable. A compliance hold can remain active. An invalid account number can still reject. A bank can still post a credit later than the blockchain confirms the USDC transfer.
Stripe’s documentation shows this separation. Stripe states that stablecoin payment settlement timing varies by network. Its global payout documentation separately identifies payout arrival windows that depend on location and payout method. Its stablecoin-payout documentation also identifies account eligibility, supported locations, wallet verification, first-payout holds, and operational review as separate conditions from the blockchain transaction itself.[3][4][5][6]
Where a Stablecoin Payout Can Fail and Who Owns the Recovery
Every participant can cause a failure. The platform remains accountable for resolving the customer outcome.
| Payment domain | Accountable party | Failure mode | Customer impact | Required control |
|---|---|---|---|---|
|
01
On-ramp
Funding
|
Sender-side bank, payment service provider, or platform. | Funding decline, duplicate collection, insufficient funds, fraud hold, KYC failure, or source-of-funds review. | The payment never becomes available for conversion or settlement. | Funding-state verification, idempotency controls, KYC, transaction monitoring, and explicit release criteria. |
|
02
Stablecoin issuer
Conversion
|
Stablecoin issuer. | Tokenization or redemption restriction, account limitation, reserve concern, legal action, operational disruption, or smart-contract control event. | USDC cannot be created, redeemed, transferred as expected, or accepted at par by counterparties. | Issuer due diligence, reserve review, redemption-access testing, concentration limits, escalation paths, and contingency routing. |
|
03
Wallet or custody provider
Settlement
|
Custodian, wallet provider, or platform treasury team. | Lost signing authority, compromised keys, misconfigured policy, incorrect address, custody outage, or failed transaction broadcast. | Funds cannot move, move incorrectly, or become exposed to irreversible loss. | Multi-party approval, address allowlisting, role separation, transaction limits, hardened key management, and incident response. |
|
04
Liquidity provider
Conversion
|
Market maker, exchange, treasury desk, or off-ramp. | Insufficient USDC or PHP inventory, widened spreads, market disruption, unavailable quote, or failed hedge. | Conversion becomes more expensive, delayed, partially filled, or unavailable. | Real-time inventory monitoring, PHP buffers by corridor, pricing limits, multiple liquidity sources, and fallback routes. |
|
05
Off-ramp
PHP conversion
|
Regulated exchange, bank, payment service provider, or local conversion partner. | USDC receipt fails policy checks, the transaction enters review, redemption fails, local operations go offline, or PHP availability falls short. | The receiving wallet can hold confirmed USDC while the beneficiary receives no PHP. | Counterparty service levels, accepted-asset policy, address screening, confirmation rules, PHP capacity, and multi-off-ramp resilience. |
|
06
Bank
Account credit
|
Sender, settlement, or beneficiary bank. | Compliance hold, account restriction, cut-off, posting delay, rejected transfer, or returned funds. | The payment remains pending, returns, or reaches the recipient later than expected. | Account-status checks, cut-off logic, rejection-code handling, return workflows, and accurate payment-status updates. |
|
07
Local payout rail
Local payout
|
Domestic bank-transfer network, e-wallet rail, or disbursement provider. | Rail downtime, timeout, invalid beneficiary data, duplicate instruction, service restriction, or unavailable receiving institution. | The PHP transfer rejects, delays, retries, or requires manual intervention. | Pre-payout account validation, rail-status monitoring, idempotency keys, retry rules, and alternate-rail routing. |
|
08
Merchant or platform
Customer promise
|
The platform that made the customer promise. | Incorrect payout construction, stale recipient data, incomplete vendor integration, weak exception management, inaccurate status messaging, or unreconciled ledger state. | The customer experiences a failed, delayed, opaque, or disputed payment regardless of the underlying vendor event. | End-to-end payment state machine, vendor orchestration, reconciliation, observability, support tooling, and clear liability design. |
A blockchain transaction can confirm successfully while the payout still fails at conversion, compliance, bank posting, or local disbursement.
The platform owns the customer outcome. Vendor fragmentation does not transfer that responsibility.
The technical layer
Wallet control determines who can authorize the stablecoin transfer. A wallet contains the addresses and cryptographic authority used to hold and move digital assets. OFAC describes a digital-currency wallet as a mechanism that holds addresses and private keys, tracks balances, and enables transfers.[7]
Payment operators need a controlled wallet model.
- Use approved wallets only.
- Allowlist recipient addresses before value movement.
- Separate customer ledger balances from treasury balances.
- Require multi-party approval for high-value transfers.
- Apply transaction limits by corridor, counterparty, wallet, and time period.
- Maintain a complete signing, access, and transaction audit trail.
- Treat blockchain address entry as a high-risk instruction field.
Transaction finality requires an explicit policy. A blockchain transaction can appear in a block before the platform deems it irreversible enough to credit the receiving party. Operators define the required confirmation count, monitor network incidents, handle chain reorganizations, and specify whether the off-ramp accepts risk before or after that threshold.
BIS and CPMI state that settlement finality must be clear. Their work on stablecoin arrangements emphasizes the need for certainty around final settlement and the credit and liquidity risks associated with the settlement asset.[8][9]
Network fees and congestion shape actual operating speed. USDC transfers require network resources. The sending wallet needs native gas tokens or a sponsored-fee system. Fees can rise. Transactions can remain pending. Networks can degrade. A platform needs a narrow list of supported chains, fee-policy controls, network-health monitoring, confirmation thresholds, and a fallback path for urgent or high-value payouts.
Compliance remains everywhere
Stablecoins add compliance controls. They do not replace existing controls.
FATF states that virtual-asset service providers and financial institutions conducting virtual-asset transfers must obtain, hold, and transmit required originator and beneficiary information immediately and securely under Recommendation 16, commonly called the Travel Rule.[10][11]
FATF also identifies stablecoin exposure to money laundering and terrorist financing because stablecoins can combine global reach, potential anonymity, and the ability to layer illicit funds. OFAC requires virtual-currency businesses to use risk-based sanctions controls and specifically identifies transaction and wallet-address screening as relevant measures.[7][12][13]
The stablecoin payout requires controls at three points.
At conversion: Verify the customer, transaction purpose, source of funds, counterparty eligibility, and sanctions exposure before USD becomes USDC.
At transfer: Screen the sending and receiving wallet addresses, apply Travel Rule data exchange where required, monitor transaction exposure, and prevent transfers to prohibited counterparties or high-risk clusters.
At payout: Confirm the off-ramp’s compliance acceptance, validate the beneficiary account, screen the beneficiary and transaction, document the PHP conversion, and submit the local payout only after all required controls pass.
The compliance architecture needs one joined case record. Separate checks by separate vendors create gaps when no system owns the final decision.
Risk does not disappear
Stablecoin settlement introduces issuer, market, custody, smart-contract, network, and wallet risks. It also leaves the fiat endpoint exposed to liquidity, compliance, bank, and local-payout failures.
| Risk | Operational mechanism | Failure outcome | Control response |
|---|---|---|---|
|
01
Issuer exposure
Issuer
|
The token depends on issuer operations, reserve composition, banking partners, legal terms, and redemption capability. | The operator cannot convert, redeem, or confidently price USDC when needed. | Use issuers with credible disclosures, tested redemption access, independent assurance, defined legal terms, and concentration limits. |
|
02
Depegging
Market
|
Secondary-market USDC pricing diverges from one USD because of market stress, liquidity fragmentation, or redemption uncertainty. | The platform faces losses, repricing, payout delays, or a gap between quoted and executable PHP value. | Monitor market price, redemption capacity, liquidity depth, off-ramp pricing, and issuer concentration. Set pause and repricing thresholds. |
|
03
Smart-contract risk
Technology
|
A token contract can contain vulnerabilities, pause features, upgrade authority, blacklisting controls, or implementation error. | Transfers can be halted, assets can be frozen, or a contract-level incident can impair access. | Approve specific token contracts and chain deployments, monitor issuer governance, prohibit unreviewed bridges, and maintain incident playbooks. |
|
04
Network risk
Technology
|
Congestion, outages, fee spikes, chain reorganizations, infrastructure failure, or bridging errors delay settlement. | A time-sensitive payout misses its delivery commitment even when USD and USDC remain intact. | Define confirmation policies, monitor network health, maintain gas management, avoid unnecessary bridge exposure, and retain fallback settlement routes. |
|
05
Wallet compromise
Custody
|
Private-key theft, phishing, access-control failure, or signer error authorizes an unintended transaction. | Assets can move irreversibly outside the intended payout flow. | Use hardened custody, MPC or multi-signature controls, address allowlists, maker-checker approvals, velocity limits, and continuous monitoring. |
|
06
Sanctions exposure
Compliance
|
Funds interact with prohibited persons, entities, jurisdictions, or wallet clusters. | The platform can face blocked funds, regulatory reporting duties, legal exposure, and counterparty termination. | Screen customers, entities, counterparties, blockchain addresses, and transaction paths. Maintain escalation, blocking, reporting, and record-retention procedures. |
|
07
Off-ramp failure
Fiat endpoint
|
The receiving partner lacks PHP liquidity, rejects the asset, pauses redemption, enters review, loses access to banking rails, or suffers operational downtime. | Confirmed USDC remains at the off-ramp while the beneficiary does not receive PHP. | Maintain multiple regulated off-ramps, service-level commitments, PHP liquidity buffers, corridor-specific capacity planning, and customer communication states. |
|
08
Local payout failure
Fiat endpoint
|
Invalid recipient data, account closure, payout-rail outage, bank restriction, or failed account credit prevents delivery. | PHP payout fails after successful USDC settlement. | Validate beneficiary data before disbursement, monitor rail health, maintain rejection-code workflows, and support retries, returns, and alternate payout methods. |
The stablecoin leg changes the risk surface. The off-ramp and local payout rail still determine whether the recipient receives PHP.
The important operational fact remains simple. Stablecoins can make the middle of a cross-border payment faster and more programmable. The recipient still depends on the last mile.
Conclusion
Stablecoins can compress a settlement leg. They do not remove FX, endpoint liquidity, compliance, payout operations, or the need to reconcile the full payment lifecycle.
The value proposition is strongest when a platform needs to move value rapidly between approved, regulated liquidity providers across time zones. The platform still needs reliable fiat collection, issuer and custody controls, compliant conversion, PHP liquidity, domestic disbursement capability, beneficiary-account validation, and full-lifecycle reconciliation.
A stablecoin transfer proves that a token reached an address. A successful cross-border payout proves that the intended beneficiary received PHP in the intended account.
Accept payments from Filipino customers without a Philippine entity.
Most global companies stall in the Philippines for one reason: local acceptance requires local infrastructure. An entity, a resident agent, a bank account you cannot open remotely, and months of setup before the first peso clears.
PayMongo is the licensed local endpoint. One integration, one contract, settlement and compliance handled under our Philippine licence.
PayMongo is regulated by the Bangko Sentral ng Pilipinas.
