TL;DR
If you run a fintech, marketplace, or payment platform that moves money for other businesses, you have probably come across the terms POBO and COBO. Both are on-behalf-of payment models, but they solve different problems and carry different compliance requirements.
This post breaks down the difference, when each applies, and how they work together.
What POBO and COBO Actually Mean
POBO (Payment on Behalf Of) is for money moving out. Your platform instructs a licensed infrastructure provider to pay a third party, but the payment carries your underlying merchant as the actual remitter. The beneficiary sees the merchant's name in the payment message, not your platform's name.
COBO (Collection on Behalf Of) is for money moving in. Your platform collects funds from a third party into a named virtual account, where your underlying merchant is the true beneficiary. The payer sends money to an account in the merchant's name, and the funds are credited and reconciled accordingly.
The key distinction is direction. POBO is disbursement infrastructure. COBO is collection infrastructure. Both require the infrastructure provider to maintain transparency about who the actual parties to the transaction are.
When to Use POBO
POBO is the right model when your platform needs to send payouts to third parties on behalf of your merchants or customers. Common scenarios include:
A remittance platform sending money to beneficiaries in multiple countries on behalf of its customers. An EOR platform paying contractors in 15 markets on behalf of the employer. A B2B marketplace disbursing payments to sellers after a transaction settles. A trade finance company paying overseas suppliers on behalf of its importer clients.
In all these cases, the platform is initiating the payment, but the actual remitter is the underlying business or individual. Under ISO 20022 and SWIFT's CBPR+ messaging standards, the payment message must separately identify the ordering institution (your platform's infrastructure provider) and the ultimate debtor (your merchant) [1]. Fintechs that send all payouts under their own name, masking the actual originator, face increasing rejection rates at destination banks and regulatory scrutiny from correspondent banks.
The compliance requirement for POBO is sub-entity KYB. Every underlying merchant that your platform sends payouts for needs a verified entity with the infrastructure provider. This entity ID is passed with each payout call, and the provider maps it to the verified remitter name in the payment message. For a full walkthrough of how on-behalf-of payout flows work, including entity management and SWIFT message formatting, see the guide linked below.
When to Use COBO
COBO is the right model when your platform needs to collect payments from third parties and credit them to your merchants. Common scenarios include:
A SaaS platform collecting subscription payments from enterprise clients on behalf of its resellers. A B2B marketplace receiving payment from buyers that needs to be attributed to specific sellers. A freight platform collecting payment from shippers that will be disbursed to carriers. An invoice financing platform collecting repayments from borrowers on behalf of lenders.
The compliance requirement for COBO is named virtual account provisioning. The VA is opened in the merchant's name, not your platform's name. When a payer sends a bank transfer to the VA, they see the merchant's name as the account holder, which reduces confusion and failed payments. Incoming transfers are screened for sanctioned senders and flagged if the remitter's industry does not match the expected business relationship.
COBO without named VAs is a compliance risk. If all collections land in a single omnibus account under your platform's name, you lose the audit trail that regulators require for on-behalf-of flows.
What Changes on the Compliance Side
The compliance requirements for POBO and COBO are different because the risk profiles are different.
With POBO, the primary risk is masquerading: a fintech using payout rails to send money for an unverified entity, or an entity that misrepresents its business activity. The mitigation is sub-entity KYB. Every underlying merchant needs a verified entity with the infrastructure provider, and that entity ID is passed with every payout. The provider verifies the business, screens against sanctions lists, and checks that the remitter's industry classification matches the stated business activity. Without this, the fintech is effectively laundering the identity of its merchants through its own name [1].
With COBO, the primary risk is receiving funds from sanctioned or unverified senders. The mitigation is inbound transfer screening: every incoming payment to a named VA is checked for sanctioned senders, flagged if the remitter's industry does not align with the merchant's expected business, and held for review if the transaction pattern deviates from what was stated at onboarding.
There is also a licensing dimension. Licensed fintechs (MPI, MTL, MSB, EMI or equivalent) can be part of the fund flow and take on direct regulatory accountability. Unlicensed technology service providers can use the infrastructure, but the licensed provider acts as the regulated counterparty. This distinction determines the onboarding process, the level of compliance reliance, and who bears regulatory risk at each step.
For a comprehensive breakdown of entity management, KYB workflows, and licensing requirements by fintech type, see our white-label POBO infrastructure guide.
Quick Decision Framework
If your platform pays third parties on behalf of your merchants: you need POBO. If your platform collects from third parties and credits your merchants: you need COBO. If your platform does both (which most marketplaces, EOR platforms, and trade finance companies do): you need both.
The infrastructure provider you choose should support both models through the same integration, with shared entity management across POBO and COBO flows. Creating separate entities for payouts and collections adds unnecessary complexity and compliance overhead.
For platforms evaluating on-behalf-of infrastructure, the five criteria that matter most are: licensing coverage across your target jurisdictions, actual remitter name in SWIFT messages (not the provider's name), named VA provisioning for collections, batch entity onboarding via API, and local payout depth in your key markets.
Sources:
[1] SWIFT. ISO 20022 for Financial Institutions: Focus on Payments Instructions. https://www.swift.com/standards/iso-20022
