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

POBO (payment on behalf of) and COBO (collection on behalf of) are arrangements in which one entity pays or collects through its own bank account for a different legal entity. POBO moves money out for that other party, and COBO brings money in. The Payments Market Practice Group defines both in its November 2023 guidelines on ultimate parties.

What POBO and COBO mean in a payment message

The reference text is the Payments Market Practice Group's (PMPG) Market Practice Guidelines on ultimate parties in cross-border payment messages, published in November 2023. It defines POBO as third-party payments an entity executes from its own bank account held with the debtor agent, the bank that holds the paying account. It defines COBO as third-party collections received into the entity's own account with the creditor agent, the bank that holds the receiving account. COBO is also called ROBO, for receivables on behalf of.

The party the money really belongs to is the ultimate debtor on a payment and the ultimate creditor on a collection. Two features set these flows apart from an ordinary transfer. The ultimate party has to be a different legal entity from the account holder, and it usually has no account with the bank at all, because the entity's account is the one in use.

The PMPG also draws a boundary. An entity that only has technical control over a client's own account, without owning it, is not an ultimate party. It is an initiating party, and its client is the debtor. Legacy MT messages had no dedicated fields for ultimate parties, and ISO 20022 added them.

On Lumx every account belongs to an onboarded customer. A third party that is not onboarded can appear only as a disclosed destination holder, with its relationship to the customer stated, which is the visibility the PMPG says the account-holding bank needs.

How do POBO and COBO differ?

The difference is direction. POBO sends money out for another party and COBO receives money in for another party, and almost everything else follows from that.

POBO and COBO side by side, with the examples and requirements taken from the PMPG guidelines of November 2023.

On Lumx a collection is an on-ramp and a payment is an off-ramp. Most of them are ordinary transactions by a customer for its own business. They count as on behalf of someone only when the money belongs to another entity, and the section on how POBO and COBO run on Lumx says what Lumx requires then.

Where payments on behalf of someone else show up

The PMPG describes three shapes. A law or notary firm pays from its trust account for clients who are not customers of the bank. A collection agency receives money for the businesses it works for. A payment factory or in-house bank pays and collects from its own accounts for the operating companies of a group, which cuts the number of accounts the group has to run. That is why companies choose these structures over separate accounts, and the cost is visibility: the bank has to understand the relationship and the messages have to carry the ultimate party.

Platforms look similar but are a different case, and the PMPG excludes them. A payment service provider that holds client accounts or wallets is identified as an agent, the debtor agent or creditor agent, with the client as debtor or creditor. The PMPG says ultimate party fields are not permitted there, because the setup does not meet the conditions for an ultimate party. Only a genuine collection agency qualifies, with the merchant as ultimate creditor.

Lumx's docs handle the group case and the platform case with the same rule, and it matches the PMPG's exclusion because the platform is never the ultimate party: every legal entity whose funds move is separately onboarded. In the treasury guide a parent onboards each subsidiary as its own business customer with a dedicated wallet, and internal transfers between them carry no FX cost. In the marketplace and payroll guides, each seller or employer is its own customer, and the platform takes its cut through a partner fee.

Whose name the other side sees

The name that reaches the payee or the payer is set by the account that moved the money and by the fields the banks in the chain fill in. Under ISO 20022 the ultimate debtor and ultimate creditor have their own elements. The PMPG says correct population matters for reconciliation and anti-financial-crime controls, and that concealing ultimate details carries regulatory consequences.

For a payer or a payee, the safest reading is that the name on the account is the name they will see, and anything beyond that depends on the banks in the chain. Ask any provider whose name is on the account that is debited or credited, and which ultimate party fields are filled.

Lumx publishes the first answer. On the rails it runs in USD, EUR and GBP (ACH, FEDWIRE, SWIFT, SEPA and Faster Payments), the sender of record on the recipient's bank statement is the customer, meaning the legal name registered during KYC (know your customer, the verification of an individual) or KYB (know your business, the verification of a company and its owners). On Pix (Brazil's instant payment system, run by the Central Bank) and SPEI (Mexico's) payouts the recipient also sees the customer.

Where on-behalf-of ends and nesting begins

Picture a marketplace that collects buyer payments into its own account and pays out sellers it never onboarded. No ultimate party field repairs that, because the PMPG treats a platform holding client accounts or wallets as an agent, not as a party the money belongs to. The Lumx docs name the pattern: buyer funds pooled in one account and distributed to sellers who are not onboarded.

On-behalf-of is legitimate when the bank can see every party. It turns into nesting when it cannot. The PMPG quotes the Wolfsberg Group's position that the debtor agent must understand an on-behalf-of arrangement, so that it can confirm the relationship is permissible under local regulation, for example where custodial or fiduciary relationships are involved.

The Lumx docs turn that into a one-line test: whose money is it, and whose business does it pay for? If both answers are the onboarded customer, the transaction fits. If either names an entity Lumx has not onboarded, it is nesting. Layered models, such as agency or payout programs, need a written agreement and enhanced due diligence first, with pre-approval at compliance@lumx.io. A transaction that fails the visibility test can be delayed, rejected or reversed.

When a platform asks me whether it can pay or collect for its customers, my recommendation is to start from the list of customers, not from the rail. Write down each business the money would belong to and run the nesting test on that list line by line. A customer that cannot be onboarded cannot be paid for, whatever the rail, and the list shows that before anything is built.

How POBO and COBO run on Lumx in USD, EUR and GBP

The rule on Lumx is short. POBO and COBO run through named virtual accounts, each in the customer's own name, and every party whose funds move is either onboarded as its own customer or covered by a structure Lumx has approved in writing. A layered structure, such as an agency or a payout program, needs that written approval and enhanced due diligence from compliance@lumx.io. An undisclosed third party cannot be the ultimate debtor or creditor on a Lumx account.

Two cases come up often. A parent that pays a subsidiary's supplier from the parent's wallet is allowed once compliance has approved the flow of funds in writing. A third party can fund an on-ramp when the payment is consistent with the flow of funds the customer described, and a payer that looks out of pattern can trigger a compliance hold and, as a result, a return of the funds.

Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.

The sentence groups two things that are easy to run together. POBO and COBO run in USD, EUR and GBP, while SWIFT runs in USD only.

Rails Lumx runs in USD, EUR and GBP, with cut-offs and settlement, plus the sender of record. Lumx docs, read on November 1, 2026.

Lumx picks the SEPA scheme itself, so a request always says SEPA. EUR and GBP accounts are issued by a banking partner in the customer's name and move to active right after the customer is approved, while a USD account can take up to one business day.

The currency pairs have their own pages, USDC to EUR and USDC to GBP. The deadlines are in payout limits and cut-offs by rail, the full rail list is on the coverage page, and global payments shows how the pieces fit in one API. Where a flow touches USD wires, stablecoins and SWIFT compared covers the settlement difference.

How do you set up a payment or collection for each business whose money moves?

The setup is the same steps whichever direction the money goes, and most of the work happens before the first payment. Each business becomes a customer acting for itself.

1. List every business the money would belong to and run the nesting test above. Each one that passes becomes a customer.

2. Onboard each as a business customer. The customer accepts the terms of service and completes KYB, described in what KYB involves. Request USD, EUR or GBP in the accounts array when creating the customer.

3. For a collection, create an on-ramp for each expected deposit with the exact amount, and give the depositor the payment details from the response: an IBAN and BIC for EUR, a sort code and account number for GBP, wire or ACH details for USD. A deposit that lands after the on-ramp has expired is refunded to the sender on the same rail.

4. For a payment, register the payee as a destination under the paying customer with the holder relationship that matches the facts, such as SUPPLIER, and use the TRADE_TRANSACTIONS purpose code for supplier invoices. Then create the off-ramp from the customer's wallet.

5. Check the limits. The default per-transaction limit for a KYB Standard customer is $50,000.

6. Expect questions. A purpose code that does not match the use of the funds can hold a transaction or trigger an RFI (request for information, a compliance hold that asks for a document before a transaction clears). Every transfer carries a per-rail reference and a webhook.

The account behind step 3 is a named virtual account (a local account number issued in the customer's own name). What a named virtual account is, named accounts for B2B collections and the product page cover it further.

Is POBO or COBO legal?

Yes, where the bank can see the arrangement and local rules allow it. Neither the PMPG nor the Wolfsberg Group bans them. The Wolfsberg position quoted by the PMPG says the debtor agent has to understand the arrangement to confirm it is permissible under local regulation. The PMPG adds that concealing ultimate party details has regulatory consequences. Whether a given structure is allowed depends on the jurisdiction and the bank.

In the US, Lumx US OP LLC, a Wyoming company, is registered with FinCEN as an MSB (money services business, the FinCEN registration category). EUR and GBP accounts are issued by a banking partner in the customer's name, and Lumx does not hold an EU licence of its own. On any of them the rule is the one above: an onboarded customer for each party whose funds move, or a structure approved in writing.

When on-behalf-of is the wrong structure

Some flows should not be built as POBO or COBO at all.

• The other party cannot be named. An undisclosed party is nesting, and on Lumx it is not allowed.

• The money belongs to the account holder. Paying your own suppliers from your own account is an ordinary payment with no ultimate party to name. On Lumx it is an off-ramp to a destination whose relationship is SUPPLIER.

• A local rail already reaches the payee. If the payee banks in Brazil, Mexico or Colombia, a local payout in the payee's currency may remove the need for the structure; the local rails are on the operator map.

Methodology and sources

The definitions and examples, and the Wolfsberg position, come from the PMPG's Market Practice Guidelines on ultimate parties in cross-border payment messages (November 2023), read in full as a PDF from GLEIF on November 1, 2026. Everything about what Lumx does comes from docs.lumx.io pages read on November 1, 2026: nested payments, destinations, accounts, sender of record, cut-off times, transaction limits, and the treasury, marketplace and payroll guides.

Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.

Cover photo: Athina Vrikki on Unsplash.