What is the difference between POBO and COBO?

POBO, payment on behalf of, is outbound: one entity sends a payment from its own account for an obligation that belongs to someone else. COBO, collection on behalf of, is inbound: one entity receives a payment into its account that economically belongs to someone else. Both come from corporate treasury, where a parent pays and collects for its subsidiaries through one account.

Whose name does the supplier see on a POBO payment?

It depends on how the payment is built. Under ISO 20022 the message can name an ultimate debtor separately from the account holder, but many providers don't populate that field. In practice the payee sees the name on the account that was debited, so the reliable way to show your customer's name is an account titled in your customer's name, plus a clear payment reference.

What is a UETR and why does it matter for POBO?

A UETR, or Unique End-to-end Transaction Reference, is a 36-character identifier carried in every Swift payment instruction. Every bank in the chain refers to the payment by the same UETR, so the sender, the receiver, and each correspondent can trace the same payment. For POBO it is the number you give a supplier who says the money never arrived.

Is MT103 still used after Swift's ISO 20022 migration?

Swift ended the MT and ISO 20022 coexistence period for cross-border payment instructions on November 22, 2025, so banks now exchange those instructions as ISO 20022 messages such as pacs.008. Many banks and customers still call the payment confirmation an MT103, and the familiar fields map across: the MT103 field 70 remittance information becomes the remittance information element in pacs.008.

Is POBO the same as nested payments?

No. POBO is legitimate when the provider can see the party it is paying for: that party is onboarded, verified, and holds an account in its own name. Nesting is when a customer uses its account to move money for its own clients, whom the provider never onboarded or screened. The mechanics look alike. The visibility is what separates them.

Can stablecoins replace SWIFT for POBO and COBO?

Not fully. Stablecoin settlement can replace the expensive middle of the payment, but a supplier who invoices in dollars and banks with a correspondent-connected bank still expects a SWIFT payment. Hybrid setups settle the value in stablecoins and deliver the last leg as a SWIFT payment, so the supplier sees an ordinary wire with a UETR.

POBO vs COBO: SWIFT payments on behalf of, explained

POBO (payment on behalf of) is when one entity sends a SWIFT payment for an obligation that belongs to its customer. COBO (collection on behalf of) is when it receives a payment that belongs to its customer. Both let a platform pay and collect internationally for customers who don't hold their own overseas bank accounts.

Key takeaways

POBO is outbound, COBO is inbound. Both come from corporate treasury, where a head office pays and collects for its subsidiaries.
The name on the account decides what the counterparty sees. ISO 20022 has ultimate debtor and creditor fields, but you can't count on every provider or bank to fill them.
The UETR is the tracking number. Every Swift payment instruction carries one, and every bank in the chain uses it.
POBO is not nesting. It only works when the provider has onboarded the party it pays or collects for.
Stablecoins replace the middle, not the ends. Hybrid setups settle in stablecoins and deliver a normal SWIFT payment to the supplier.

Definition. POBO and COBO are third-party payment arrangements in which one entity pays (POBO) or collects (COBO) through its own account on behalf of another party, the ultimate debtor or ultimate creditor.

What are POBO and COBO?

POBO and COBO are "on behalf of" arrangements in which the account holder and the party that owns the money are different entities.

The terms come from corporate treasury. A multinational runs a payment factory: one entity pays suppliers for every subsidiary and collects from customers into one set of accounts. The Payments Market Practice Group's guidelines on ultimate parties (November 2023) define POBO as third-party payments executed from the entity's own bank account, and COBO, also called ROBO, as third-party collections received into it.

Platforms now do the same thing for their customers instead of their own group companies. A marketplace pays a seller's supplier. A payroll platform collects from a client abroad. The mechanics are the same; the compliance requirements are stricter, because the customers are separate businesses.

How do POBO and COBO compare?

POBO moves money out for a customer and COBO brings money in for a customer; most other differences follow from that direction.

	POBO	COBO
Direction	Outbound	Inbound
Who owns the obligation	Your customer owes the payee	The payer owes your customer
ISO 20022 party	Ultimate debtor	Ultimate creditor
What the counterparty should see	Your customer as the sender	An account that looks like your customer's
Typical setup	An account titled for the customer, plus a payment reference	A per-customer account with its own beneficiary name and SWIFT details
Typical documents	Invoice or purchase order proving the obligation	Sender details captured on arrival for reconciliation
Main failure	Payee can't match the payment to an invoice	Payer sends to the wrong details, or funds can't be attributed

Whose name appears on a POBO payment?

The name that reaches the payee is usually the name on the account that was debited, so an account titled for your customer is the reliable way to show their name.

ISO 20022 does give each party its own field. The PMPG guidelines note that legacy MT messages had no dedicated fields for ultimate parties, which pushed that information into free-text fields like remittance information. ISO 20022 adds structured ultimate debtor and ultimate creditor elements.

The catch: a structured field only helps if every party in the chain populates it and the beneficiary bank shows it. Many don't. So ask any provider two questions before promising a customer that their name will appear:

Is the debited account titled in my customer's name, or in yours?
Do you populate the ultimate debtor field, or only the debtor?

If the answer to the first is "ours," the supplier will see the provider's name and will need the payment reference to match the invoice.

What does a SWIFT payment carry back?

A SWIFT payment carries back a UETR, a 36-character reference the sending bank assigns, and every bank in the chain uses it to report status.

According to Swift's UETR explainer, a UETR works like a courier tracking number: any party in the chain can locate the payment, and the sender is notified when the funds are credited or rejected. Swift made it mandatory on MT103 payment instructions from November 2018.

The message format changed too. Swift ended the MT and ISO 20022 coexistence period for cross-border payment instructions on November 22, 2025. Instructions now travel as ISO 20022 pacs.008 messages. Banks and finance teams still ask for "the MT103" as payment confirmation, and the fields map across.

One field matters most for POBO: remittance information (field 70 on MT103, the remittance information element on pacs.008). It is the only payer-supplied text the beneficiary's bank reliably shows as the payment reference. Put the invoice number first and keep it short, because some routes truncate it. How to track an off-ramp payout covers what to send a recipient who can't find a payment.

Where is the line between POBO and nested payments?

POBO stays compliant only when the provider can see the party the payment is for; when it can't, the arrangement is nesting.

The PMPG guidelines cite the Wolfsberg Group's position that on-behalf-of arrangements must be understood by the sending bank, so it can confirm the relationship is allowed under local rules. For a platform, that translates to one test:

POBO or COBO: your customer is onboarded with the provider, has passed KYC or KYB, and the account is in their name. The provider sees who owns the money and what it is for.
Nesting: your customer uses its account to pay or collect for its own clients, whom the provider has never onboarded or screened.

The payment reference doesn't change the answer. If one of your customers needs to pay for its own client base, those clients need to be onboarded too.

How do stablecoins fit into POBO and COBO?

Stablecoins can carry the value across borders while SWIFT delivers the first or last leg, so the counterparty still sees an ordinary bank payment.

A hybrid POBO payment looks like this:

Your customer funds the payment in USDC or USDT, or from local currency converted into stablecoins.
The provider quotes the payment and locks the rate.
The stablecoin moves on-chain to the provider in seconds or minutes.
The provider sends a SWIFT payment from an account titled for your customer, with the invoice number in the remittance field.
The UETR comes back once the payment is confirmed, and you pass it to the supplier.

COBO runs the other way: the payer sends a SWIFT payment to a per-customer account, the funds convert to stablecoins, and the stablecoins land in your customer's wallet.

The supplier never touches a stablecoin. What changes is the middle: no pre-funded nostro balance and no float sitting in a correspondent account. Stablecoins vs SWIFT for B2B payments compares the two on cost and speed.

How does BlindPay run POBO and COBO?

BlindPay runs SWIFT (POBO/COBO) on top of a virtual account issued to a specific onboarded customer, with UETR tracking and MT103 confirmations, and settles the value in USDC or USDT.

COBO. Inbound international payments need a virtual account, which carries the customer's own beneficiary name, SWIFT BIC, and account number. Incoming funds convert to USDC or USDT and go to the customer's linked wallet, and the payin reports the sender's name, bank, account, and reference.
POBO. The Named Account setting puts the customer's name on the payment instead of BlindPay's. BlindPay doesn't populate the ISO 20022 ultimate debtor field, so the name travels through the account title and the reference.
Rules worth planning around. The minimum SWIFT payout is 100 USD, the cut-off is 10:30 AM ET, and settlement takes up to 5 business days. Every SWIFT payout starts on hold, and payments to a third party need a document such as an invoice before they release. Only the first 30 characters of the description reach the beneficiary.

The full setup is in the POBO and COBO guide, and the product overview is on POBO and COBO over SWIFT.

When should you not use stablecoins for an on-behalf-of payment?

Skip the stablecoin leg when it adds a step without removing a cost.

Domestic payments. A US company paying a US supplier is better served by ACH or a domestic wire.
Countries that restrict third-party payments. Some beneficiary banks decline a payment that isn't in the invoice party's name, whatever rail funds it.
Suppliers who require a specific bank. If the contract names the paying bank, a provider-issued account won't satisfy it.
Very small payments. Below a SWIFT minimum, use a local rail or batch the invoices.
No one owns the documents. If nobody on your side can produce invoices on request, third-party SWIFT payments will sit on hold.

When not to use blockchain payments covers the broader cases.

How do you choose a rail for a payment on behalf of a customer?

Pick by the corridor, the amount, and how the counterparty wants to be paid.

Does the recipient's country have an instant local rail the provider pays out to? If yes, a local payout usually beats SWIFT on speed and cost.
Does the supplier insist on a wire? Then SWIFT delivers the last leg, with stablecoins or a bank balance funding it.
Is the amount above the provider's SWIFT minimum? If not, batch or use a local rail.
Can you produce the invoice? Third-party SWIFT payments need one.
Does your customer's name need to show? Confirm the account is titled for them before you promise it.
How urgent is it? SWIFT can take several business days; budget for cut-offs and weekends. Why cross-border payments are slow explains where the days go.

For how payout APIs, wallet APIs, and issuer APIs divide these jobs, see types of stablecoin APIs.

What should you do next?

List the customers you pay or collect for today and check each one against the nesting test. Then confirm with your provider whose name appears on the payment and where the invoice reference lands. Fix those two before the first supplier calls asking who sent the money.

POBO vs COBO: SWIFT payments and collections on behalf of, explained