> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lumx.io/llms.txt
> Use this file to discover all available pages before exploring further.

# POBO and COBO

> Pay and collect for your customers in their own name, without nesting

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](https://docs.lumx.io/compliance/nested-payments.md).

| **Scenario** | **Supported** | **Nesting (not supported)** |
| :- | :- | :- |
| Who owns the funds | The onboarded customer | A party Lumx hasn't onboarded |
| Whose obligation it is | The customer's own invoice, payroll, or supplier | The obligations of the customer's own clients |
| Account use | The customer's own commercial activity | Pooling funds for several third parties |

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](https://docs.lumx.io/compliance/nested-payments.md#when-written-approval-may-be-required).

## COBO: collecting payments

Where named accounts are available, each [virtual account](https://docs.lumx.io/concepts/accounts.md) 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](https://docs.lumx.io/guides/autoconversion-rules.md) or an [on-ramp transaction](https://docs.lumx.io/api-reference/transactions/on-ramp.md).

## 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](https://docs.lumx.io/additional-information/sender-of-record.md) for the sender on each rail.

### Who the payee is

Every payout goes to a [destination](https://docs.lumx.io/concepts/destinations.md) 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](https://docs.lumx.io/compliance/rfi.md#transaction-rfi).

### SWIFT payouts

* **Minimum:** 40 USD per payout.
* **Cut-off and settlement:** see [Payment rail cut-off times](https://docs.lumx.io/additional-information/sla-and-cutoffs.md).
* **Destination country:** payouts to [restricted countries](https://docs.lumx.io/compliance/supported-countries.md#restricted) aren't supported.

## 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.

```bash Request theme={null}
curl -X POST https://api-sandbox.lumx.io/transactions/off-ramp \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "destinationId": "e80d3137-eddd-4791-b9b8-6e36b289f284",
    "sourceCurrency": "USDC",
    "sourceAmount": "10000.00",
    "purpose": "TRADE_TRANSACTIONS",
    "memo": "INV-2024-10-1547"
  }'
```

## 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:

| **Rail** | **`state.reference`** |
| :- | :- |
| SWIFT | UETR, the end-to-end identifier the SWIFT network assigns once the wire is confirmed |
| FEDWIRE | IMAD, the identifier Fedwire assigns to domestic wires |
| ACH | The bank's booking reference, when available. It isn't an ACH trace number |

## Related resources

> [card] [Nested Payments](https://docs.lumx.io/compliance/nested-payments.md)
>
> Where paying or collecting for others becomes nesting.

> [card] [Sender of Record](https://docs.lumx.io/additional-information/sender-of-record.md)
>
> Whose name the payee sees, by rail.

> [card] [Destinations](https://docs.lumx.io/concepts/destinations.md)
>
> Holder relationships for every payout.

> [card] [Accounts](https://docs.lumx.io/concepts/accounts.md)
>
> Virtual accounts, named in your customer's name where available.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.