Skip to main content
Payment on behalf of (POBO) and collection on behalf of (COBO) let your platform send and receive international payments for your customers without each of them opening a bank account abroad. Both work because the customer is onboarded with Lumx and holds a virtual account issued by a Lumx banking partner. Where named accounts are available, the account is in the customer’s own name, so the payer and the payee see your customer, not your platform.
  • POBO (outbound): you pay a supplier, employee, or other counterparty for an obligation that belongs to your customer.
  • COBO (inbound): you collect a payment that belongs to your customer, such as a client paying their invoice.

​
Where the line is

POBO and COBO only work for parties Lumx can see. That’s what separates them from nested payments. If your customer wants to pay or collect for their own clients, each of those clients has to be onboarded as a Lumx customer too. For structures that need written approval, see When written approval may be required.

​
COBO: collecting payments

Where named accounts are available, each virtual account is issued in your customer’s name, so the payer sends funds to bank details that identify your customer as the beneficiary. Share the account’s deposit details from an autoconversion rule or an on-ramp transaction.

​
POBO: sending payments

​
Whose name the payee sees

On rails with named accounts, the payee’s bank statement shows your customer as the sender: the legal name registered during verification. See Sender of record for the sender on each rail.

​
Who the payee is

Every payout goes to a destination registered under the customer, with a holder.relationship that declares who the payee is:
  • SELF for the customer’s own account. Only SELF destinations accept purpose: "PERSONAL_ACCOUNT".
  • A third-party relationship, such as SUPPLIER, EMPLOYEE, or BUSINESS_PARTNER, for everyone else.
Declare the relationship accurately. It’s what lets compliance match the payout to your customer’s obligation.

​
Documents and holds

Lumx doesn’t ask for a document on every third-party payout. If transaction monitoring flags a payout, it’s put on hold and compliance reaches out with a request for information (RFI), usually asking for the relationship with the payee, the purpose of the payment, and supporting context such as an invoice. See Transaction RFI.

​
SWIFT payouts

​
The reference the payee sees

Pass the payment reference, usually your customer’s invoice number, as memo on the off-ramp. On SWIFT, memo maps to field 70 of the MT103 message, the only field the payee’s bank shows as the payment reference. It accepts up to 128 characters, but only the first 30 reach the payee, so put the invoice number first and keep it short.
Request

​
Tracking a payout

After a payout settles, the transaction’s state.reference carries the identifier your customer or their payee can use to trace the payment with the banks. It’s a single string, and which identifier it holds depends on the rail:

Nested Payments

Where paying or collecting for others becomes nesting.

Sender of Record

Whose name the payee sees, by rail.

Destinations

Holder relationships for every payout.

Accounts

Virtual accounts, named in your customer’s name where available.