Bienrock helps fintechs, marketplaces and payment companies find payment rails and account structures that support payments and collections on behalf of their clients. We prepare the case and the flow documentation; approval remains the financial institution’s decision.
Key takeaways
- POBO (payments on behalf of) means a fintech or payment company sends money from its own account for a client. COBO (collections on behalf of) means it receives money into its own account for a client.
- The question is not POBO or COBO in the abstract, but which direction your client money moves in. Marketplaces, payroll providers and cross-border trade businesses usually need both.
- In ISO 20022 payment messages, the client on whose behalf the company pays or collects is shown as the ultimate debtor or ultimate creditor. Getting these fields wrong causes payment delays and compliance questions.
- Named virtual IBANs are the usual way to make COBO work: each client gets an account number in its name, while funds sit in an account held by the company.
- Banks and EMIs approve on-behalf-of models only when they understand the company’s underlying clients, its regulatory status and how it screens every flow.
- Bienrock is not a bank. It prepares the company’s case and introduces it to banking and payment partners whose risk appetite covers on-behalf-of flows.
Introduction
A fintech or payment company starts with a simple promise to its business clients: “You do not need your own bank account in every market. We will pay your suppliers and collect from your customers for you.” The product team builds it, the first clients sign up, and then the account provider asks a question nobody prepared for: on whose behalf is each of these payments actually made?
This is the core of POBO and COBO. The terms come from corporate treasury, where a group’s payment factory pays and collects for its subsidiaries. Today they describe how most fintechs, marketplaces, payroll providers and cross-border payment companies move client money. The model is common. What separates programs that get approved from those that stall is whether the company can show, flow by flow, who the money really belongs to.
This article explains what POBO and COBO mean, how they differ, how they appear in payment messages, and what banks and EMIs check before they let a company run them.
What POBO and COBO Actually Mean
Payments on behalf of (POBO) is an outbound flow. The company sends a payment from an account it holds, but the payment is made for a client. The client is the real payer: it owes the money, and the supplier, employee or contractor expects to be paid by that client.
Collections on behalf of (COBO) is an inbound flow. The company receives money into an account it holds, but the money is owed to a client. COBO is also called receivables on behalf of (ROBO) in some treasury and banking guidance.
In both cases the client does not hold its own account with the bank that processes the payment. It uses the company’s account and infrastructure instead. That is the commercial value of the model and also the reason it attracts scrutiny: a third party stands between the money and its real owner.
POBO vs COBO: The Key Differences
| POBO | COBO | |
|---|---|---|
| Direction | Outbound: the company pays for a client | Inbound: the company collects for a client |
| Real party | The client is the ultimate payer | The client is the ultimate beneficiary |
| Typical use | Supplier payments, payroll, contractor payouts, refunds | Customer payments, marketplace sales, invoice collection |
| Main control point | Knowing the client before releasing its payment | Matching each incoming payment to the right client |
| What usually goes wrong | Payer shown as the company instead of the client | Funds land in a pooled account with no clear owner |
POBO risk sits at the moment of payment: the company must know whose money is leaving and why. COBO risk sits at the moment of receipt: the company must know whose money has arrived and be able to prove it.
How On-Behalf-Of Payments Appear in ISO 20022
Cross-border and many domestic payment systems now use the ISO 20022 messaging standard. Unlike legacy SWIFT MT messages, ISO 20022 has dedicated fields for the parties behind a payment:
- Debtor: the party whose account is debited. In POBO, this is the company.
- Ultimate debtor: the party on whose behalf the payment is made. In POBO, this is the client.
- Creditor: the party whose account is credited. In COBO, this is the company.
- Ultimate creditor: the party the money is ultimately due to. In COBO, this is the client.
Swift’s market practice guidance on ultimate parties lists several common mistakes. These include copying the debtor’s details into the ultimate debtor field, entering a brand or department name instead of a legal entity, writing “NOTPROVIDED”, and showing a payment service provider as the debtor with its customer as the ultimate party.
The last point matters for fintechs. If the company only has technical control over a client’s own account, it is not the debtor. It is an initiating party, and the client is the debtor. True POBO and COBO apply only when the money moves through the company’s own account.
Industry guidance is also moving toward stricter, structured party data. Swift’s guidance notes that ultimate parties will need a name and full postal address, or a structured identifier such as an LEI, once the MT and ISO 20022 coexistence period ends. Payment systems are expected to identify all parties to a cross-border payment in a standardized way by the end of 2027.
Why Banks and EMIs Scrutinize On-Behalf-Of Models
From the account provider’s view, a company running POBO or COBO is a channel for other people’s money. The provider’s customer is the company, but the payments belong to its clients, whom the provider never onboarded.
Payment transparency guidance therefore expects the account provider to understand the on-behalf-of arrangement and confirm that it is permissible under local regulation. In practice, banks and EMIs usually ask:
- Who are the underlying clients? Their industries, countries and expected volumes, and how the company onboards and verifies them.
- What is the company’s regulatory status? Whether it holds a payment or e-money license, operates as an agent of a licensed firm, or relies on an exemption. A company that holds client funds without the right status is often the first thing a compliance team flags.
- How are client funds held? Whether they are segregated or safeguarded, and how the company’s own money is kept apart from client money.
- How is each flow screened? Sanctions and fraud screening on outgoing payments, and checks on incoming payers before funds are credited to a client.
- Can every payment be traced to one client? If funds pass through a pooled account without a clear owner, the provider cannot see who it is really serving.
None of these questions is unusual. They become a problem when a company answers them for the first time during onboarding, or answers them inconsistently across the application, the website and the flow descriptions.
Named Virtual IBANs: How COBO Works in Practice
The traditional weakness of COBO is reconciliation. If every client’s customers pay into one shared account, the company has to match payments by reference text, and any missing reference leaves funds unallocated.
Virtual IBANs solve this. The company holds one or more physical accounts with its provider, and each client receives its own virtual IBAN linked to that account. A payment to a client’s virtual IBAN is identified automatically, so the company can credit the right client ledger without manual matching.
Some providers also support named virtual IBANs, where the account name shown to payers is the client’s name rather than the company’s. This makes collections look local and familiar to the payer, and it keeps the ultimate creditor visible. It also raises the bar: the provider is effectively presenting an account in the client’s name, so it expects stronger due diligence on every client who receives one.
For the infrastructure behind client accounts, including safeguarding, ledgers and the choice between dedicated and virtual IBANs, see our guide on how to offer client IBANs as a fintech or payment company.
Which Model Does Your Business Need?
Start by mapping each flow by direction and owner rather than choosing a label.
- You only pay out for clients, such as payroll, contractor payments or supplier payments from a client’s balance: you need POBO.
- You only collect for clients, such as invoice collection or local payment acceptance for foreign sellers: you need COBO.
- Client money comes in and goes out: you need both. This is typical for marketplaces that collect from buyers and pay sellers, employer-of-record services that collect from employers and pay workers, and B2B trade businesses that collect from buyers and pay suppliers.
- You only initiate payments from accounts your clients own: this is not POBO. You are an initiating party, and the account provider will treat it differently.
Most fintechs find that they need both models sooner than they expected. Designing for both from the start, with the same client verification, ledger and screening logic on each side, is usually simpler than adding the second direction later.
Common Mistakes That Delay Approval
- Describing flows by product name instead of money movement. “We offer global accounts” does not tell a compliance team who pays whom.
- Pooling client funds with no ledger-level owner. Without a clear record of which client owns each balance, neither safeguarding nor screening can be shown to work.
- Showing the company as the real payer or beneficiary. Payment messages that hide the ultimate debtor or creditor lead to investigations and returned payments.
- Onboarding clients outside the provider’s risk appetite. One client from a restricted industry can put the whole program under review.
- Leaving regulatory status unclear. If the company’s license or agency arrangement does not cover holding or moving client funds, approval rarely moves forward.
How Bienrock Supports Fintechs With On-Behalf-Of Flows
Bienrock is a consulting company based in Geneva, Switzerland. It is not a bank and does not hold client funds. It acts as an intermediary between fintech or payment companies and a network of more than 200 banking partners across Switzerland, the UK, the EU, the UAE, Singapore, Hong Kong, Turkey and Africa.
For fintechs running POBO, COBO or both, the work usually covers:
- Mapping each flow by direction, owner, currency and corridor, so the account provider sees the actual money movement.
- Preparing the documentation that explains the company’s client base, onboarding, funds handling and screening.
- Identifying banking and EMI partners whose risk appetite covers on-behalf-of models, virtual IBANs and the company’s client industries.
The process starts with a free 30-minute consultation. Preparing documents usually takes 1 to 2 weeks and the application stage 2 to 4 weeks, so a typical case takes 4 to 8 weeks. Approval always remains the provider’s decision.
Frequently Asked Questions
What does POBO mean in payments?
POBO stands for payments on behalf of. A fintech, payment company or corporate treasury center sends a payment from its own account, but the payment is made for another party, who is shown as the ultimate debtor in ISO 20022 messages.
What does COBO mean in payments?
COBO stands for collections on behalf of, also called receivables on behalf of (ROBO). A fintech or payment company receives funds into its own account for another party, who is the ultimate creditor of the payment.
What is the difference between POBO and COBO?
POBO is outbound and COBO is inbound. In POBO the company pays for its client. In COBO it collects for its client. Many fintechs need both.
Do I need a license to offer POBO or COBO?
It depends on the jurisdiction and on how the company holds and moves client funds. Such companies often hold a payment or e-money license, work as an agent of a licensed firm, or rely on a specific exemption. Confirm your position with a regulatory advisor before launch.
Are virtual IBANs required for COBO?
Not strictly, but they are the most common way to make COBO work at scale. A unique virtual IBAN per client lets the company match incoming payments automatically, and named virtual IBANs show the client’s name to the payer.
Is initiating payments from a client’s own account the same as POBO?
No. If the client owns the account and the company only initiates payments from it, the client is the debtor and the company is the initiating party. POBO applies when the payment leaves the company’s own account.
Conclusion
POBO and COBO let a fintech or payment company give its clients payment capabilities without each client building its own banking setup. Account providers approve these models when the company can show who owns every payment, how client funds are held and how each flow is screened.
If you are launching payments or collections on behalf of your clients, or your current provider is asking questions about your flows, start with a case assessment at bienrock.ch.