COBO and POBO: collections and payments on behalf of

COBO and POBO are treasury-centralisation structures used by marketplaces, payroll platforms, and payment service providers to consolidate incoming and outgoing flows. The appeal is operational: one integration, one reconciliation surface, one liquidity position. The tension is regulatory: the more flows a platform centralises, the harder it must work to prove, at any moment, which funds belong to which client.

What are COBO and POBO?

COBO stands for Collections On Behalf Of. A platform receives incoming payments, customer settlements, subscription revenue, or marketplace proceeds, on behalf of its underlying clients, rather than each client collecting directly. POBO stands for Payments On Behalf Of. The platform disburses outbound payments, supplier settlements, merchant payouts, or salaries, on behalf of those clients from a centralised structure.

Both terms come from transaction banking, where large corporates centralise the collections and payments of their subsidiaries into a single treasury entity. Platforms have adopted the same model. A marketplace collects buyer funds (COBO) and pays out sellers (POBO). A payroll platform collects employer funds and disburses net salaries. A PSP does both continuously.

The structures also split by whose name sits on the transaction. First-party (1st-party) on-behalf-of means the platform transacts as itself. Third-party (3rd-party) on-behalf-of means the platform transacts explicitly for a named client, with that client identifiable on the flow. The difference matters for regulators, for reconciliation, and for what happens if the platform fails.

Why platforms use on-behalf-of structures

Centralisation is the reason. Consolidating flows through one structure removes the need for every client to open, maintain, and reconcile its own banking relationships across currencies and jurisdictions.

• Single integration. The platform connects once and routes all client collections and disbursements through that connection, rather than integrating a bank per client per market.
• Consolidated liquidity. Treasury sees one aggregate position across clients, which simplifies funding, FX, and working-capital management.
• Faster onboarding. A new client transacts through the existing structure immediately, without waiting on its own bank onboarding.
• Multi-currency reach. A platform running multi-currency clearing can offer clients collections and payouts in USD, EUR, GBP, and AED without each client holding local accounts.

The efficiency is real. So is the exposure it creates. Once a platform collects and pays on behalf of many clients, it is holding other people's money, and the regulatory question is no longer *how efficient is this?* but *whose money is this, and how is it kept separate?*

Client-money rules answer that directly. The FCA's client money regime (CASS) and the safeguarding rules for payment firms require funds held on behalf of clients to be segregated and identifiable. On-behalf-of flows sit squarely inside that obligation.

How on-behalf-of accounts work: the role of named accounts

The cleanest way to run COBO and POBO is to give each client a named account in its own name. Collections land in the client's own account. Payments leave from it. The platform orchestrates the flow, but ownership is established by the account structure itself, not by a ledger the platform maintains on top of a shared pool.

This is where architecture decides the outcome. In a pooled or omnibus model, all clients' funds sit in a single account and segregation exists only as internal bookkeeping. If that ledger drifts from the bank balance, or the platform fails, there is no structural mechanism to prove who owns what. It is the failure mode that froze funds in the Synapse collapse.

Named accounts remove the divergence by design. Because each client's funds sit in an account held in that client's name, reconciliation becomes verification rather than ledger-matching, and ownership is visible in the account records. This is the named vs pooled distinction: segregation that is architectural, not contractual.

Named virtual IBANs make this practical at platform scale. A platform can issue named virtual IBANs that support both first- and third-party collections and disbursements, so each merchant collects and pays through an account addressable in its own name. The centralisation benefit stays. The commingling risk does not. That is the model Lorum runs: named custody accounts across USD, EUR, GBP, and AED, provisioned via API, on a non-lending, 100% reserve basis.

COBO and POBO: named accounts vs a pooled account

The same on-behalf-of flows can run through named custody accounts or through a single pooled account. The structural differences determine segregation, reconciliation, and what happens in insolvency. This is not a feature comparison; it is an architecture decision.

The infrastructure decision

COBO and POBO centralise a platform's flows. The question every platform eventually faces is whether that centralisation also commingles its clients' funds. Run through a pooled account, on-behalf-of flows inherit every weakness of the omnibus model: ledger dependency, shared counterparty risk, and an insolvency outcome that rests on recordkeeping under stress. Run through named accounts, the same flows keep their efficiency and gain segregation by design.

Lorum is a globally licensed specialist correspondent institution. It operates a non-lending, 100% reserve model focused on three functions: global multi-currency clearing, named custody accounts, and cash management including wholesale FX.

For marketplaces and other platforms disbursing on behalf of merchants, that means named accounts for first- and third-party COBO and POBO, multi-currency by design, with segregation that is architectural rather than contractual, and the settlement certainty of clearing infrastructure rather than a correspondent nostro chain.

Frequently asked questions