POBO for payment platformsPay the supplier in your client's name.

POBO for a payment platform means paying a supplier's invoice for a business client. The platform sends the money. The payment names the client as the payer and carries the invoice reference. The supplier's bank sees who owes the invoice. Without that, banks query the payment or send it back.

General information, not legal advice. Check the rules that apply to your licence with your regulator.

What is POBO for a payment platform?

POBO stands for payment on behalf of. One party pays, another party owes the money.

Most guides on page one describe corporate treasury. A group's central entity pays suppliers for its own subsidiaries. This guide covers a different case. A PSP, fintech or remitter pays suppliers for business clients it does not own.

The flow is the same each time:

1. Your client, an importer or a merchant, owes a supplier abroad.
2. The client sends you the invoice and funds the payment, often in local currency.
3. You check the client, the supplier and the invoice.
4. The payment leaves through your bank or provider, with your client named as payer.
5. The supplier receives the money and matches it to the invoice.

The demand is easy to spot. Platforms serving importers and manufacturers get asked for it first. Platforms with a USD account in their own name start doing it too. They pay their clients' suppliers from that account.

How is it different from treasury POBO?

The label is the same. The risk and the rules are not. Calling a flow POBO does not exempt it from a payment licence.

Who is who in the payment message?

Since November 2025, banks send cross-border payments over Swift as ISO 20022 messages. Each party has a named role in the message. Four roles matter here.

This is how the Payments Market Practice Group (PMPG) set it out in November 2023. Its March 2025 update keeps the rule. A PSP paying for a client with an account or wallet is an agent. The client is the debtor. Swift's own guidance sets the same agent rule. The 2025 paper adds the case of a bank that serves a PSP. That bank is an intermediary agent. The PSP's client is still the debtor.

ISO 20022 also has a separate on-behalf-of field for the party that really owes the money. The PMPG says a PSP's client does not go there. That field is for a firm paying from its own account for someone else. Think of a law firm's client trust account, or a treasury centre paying for a subsidiary. The Wolfsberg Group's payment transparency standards of 2023 draw the same line.

Practice still varies at the first step. Some banks list the platform as the debtor, because the account is in its name. Your client then goes in the on-behalf-of block. The PMPG calls that set-up an error. Some providers show you as debtor agent only if you have your own BIC. Ask your bank which set-up it uses. Get the answer in writing, with a sample message.

Getting the fields wrong has a cost. The PMPG lists errors that slow payments down:

• The same party twice. The debtor's details copied into the on-behalf-of field.
• Wrong content. A product name, a department or a trade name in the on-behalf-of field.
• Empty values. "NOTPROVIDED" in place of a real name and address.
• The wrong party. Your platform named in the on-behalf-of field.

What does the supplier's bank see?

When the payment is built well, the supplier's bank sees four things:

• Payer name. Your client's registered company name.
• Payer address. At least town and country.
• Reference. The supplier's invoice number.
• Paying institution. Your platform or your bank, as agent.

Addresses are moving to a stricter format. Swift planned to stop accepting fully unstructured addresses in November 2026. On 27 August 2026 it delayed that release, with a new date still to be set. Fedwire moved its own release to November 2027. Banks are still asking for town and country in their own fields. Collect both for every client and supplier now.

When the payment is built badly, the supplier's bank sees your platform's name. The invoice says another company. Someone at the bank has to decide whether that is fine.

Why do banks query POBO payments?

A correspondent bank checks every party in the chain. A payment from one company for another's debt can look like a red flag. Four triggers are common:

• Name mismatch. The payer on the message is not the buyer on the invoice.
• No trade link. No invoice number, or a vague purpose like "payment".
• Missing address. No town and country for the payer.
• Unknown underlying client. The bank cannot tell who really sent the money.

A query is a message back up the chain. It asks who the payer is, what the payment is for, and for a copy of the invoice. Until you answer, the payment waits. Some banks return it instead.

Keep the invoice on file before the payment leaves. Reply to a query with the invoice, the client's details and the purpose. Do it the same day.

What do you need from each client?

POBO moves the compliance work to the front. You pay for a client, so you vouch for them.

• KYB on the client. Registration, owners, directors, business activity, expected suppliers and volumes.
• The supplier's details. Legal name, bank, account number, address with town and country.
• The invoice. Supplier name, buyer name, amount, currency and invoice number.
• The purpose. Goods or services, in plain words.

Documents are not always clean. Some market traders issue receipts, not invoices. Decide in advance which documents you accept and for which amounts.

If you work through a provider, ask how it handles your clients. Some onboard each of your clients again. Others rely on your KYB once they have reviewed your compliance team. Reliance spares your clients a second onboarding. It also puts your controls under the provider's review.

Rules on payer data keep rising. On 18 June 2025, the FATF revised Recommendation 16 on payment transparency. In the revised text, the payment chain starts at the institution that takes the payer's instruction. When you pay for a client, that is often you. FATF expects the changes in force by the end of 2030. Each country must still adopt them in its own law.

How do you prove the supplier was paid?

The supplier will ask for proof. Your client will forward that question to you.

Over Swift, the usual proof is the bank's record of the outgoing payment. For a long time that was the MT103, and many suppliers still ask for it by name. See how to read an MT103. Some routes give a payment confirmation from the provider instead. Check which document each route gives before you promise one to a client.

For payouts on local rails rather than Swift, a local partner makes the last leg. See what a payout partner does.

What should you ask a POBO provider?

1. Where does my client's name go in the message, and can I see a sample?
2. Is my platform shown as agent, and which fields carry my client's address?
3. Do I need my own BIC to be shown as agent?
4. Do you carry the invoice number to the supplier, unchanged?
5. Do you onboard each of my clients, or rely on my KYB?
6. Which documents do you accept as proof of the trade?
7. What proof of payment do I get, per route?
8. How do you send me a bank query, and how fast must I answer?
9. What happens to a returned payment, and how long does the refund take?
10. Does my own licence let me pay third parties for clients in my country?

The last question is for your own regulator, not the provider. Ask it first.

FAQ

For PSPs and fintechs

If you pay suppliers for your business clients, see how to pay suppliers in your client's name. Read more on our work with PSPs and fintechs, or talk to our team.