A first-party payout is a transfer to a bank account owned by the same legal entity that owns the funds. A third-party payout is a transfer to a different entity, such as a supplier, an employee or a subsidiary. The difference decides what the sender must declare, what the provider verifies, and how many questions compliance asks afterwards.
What is the difference between a first-party and a third-party payout?
Two questions settle it: whose money is being sent, and who owns the receiving account. If both are the same legal entity, the payout is first-party. If the account belongs to anyone else, it is third-party, even inside the same group.
First-party and third-party payouts side by side, using the holder relationships in the Lumx docs read on November 1, 2026.
First-party payout | Third-party payout | |
Who owns the receiving account | The customer that owns the funds | Another legal entity or person |
Typical case | A company cashing out to its own bank account | Paying a supplier, an employee or a creditor |
What the sender declares | One value: self | One of twelve relationships, from supplier to friend |
What the provider can check directly | The destination's tax ID and holder type against the customer's own | The declared relationship, the holder data and the bank's validation of it |
Purpose that fits | Personal account (moving funds to an account the customer owns) | Trade transactions, professional services, expenses reimbursement and the rest |
What compliance can ask on review | The same questions as any held transaction: relationship, purpose, expected outcome | Those questions, plus documents such as an invoice or contract that name the customer |
A subsidiary and a parent company are third parties to each other: two legal entities, each with its own tax ID, its own KYB (know your business, the verification of a company and its owners) and its own money. The checks are compared in KYC, KYB and KYT.
At this point Lumx asks for the same declaration on every destination. Each destination carries a holder.relationship: SELF when the destination belongs to the same legal entity as the customer, and one of twelve third-party values otherwise.
One company, three payouts
A Brazilian company makes three payouts in a month. It cashes out USDC to its own BRL account: the holder is the company, the relationship is SELF, the purpose is personal account, and the tax ID on the destination has to be the company's own. It pays a US supplier's invoice: the holder is the supplier, the relationship is SUPPLIER, the purpose is trade transactions, and the invoice is the document that backs it. It moves funds to a subsidiary: the holder is another legal entity, the relationship is SUBSIDIARY_COMPANY, the purpose is LOAN for intercompany funding, and the subsidiary's own tax ID goes on the destination.
All three leave the same wallet. Only the first can be checked against the customer's record; the other two are checked against what the company says they are.
What each side has to prove
A first-party payout has to prove ownership, which a provider checks by comparing the holder's tax ID and holder type with the customer record. A third-party payout has to prove that the declared relationship is the real one and that the payment fits it, so the evidence moves to the relationship and the purpose. Banks add their own validation on top of either, and the split between the two is covered in why payouts get rejected.
On Lumx the first-party check is an answer the API gives when the destination is created: a SELF destination whose holder type or tax ID differs from the customer's is refused. The tax ID is the field to get right on both sides: a CPF (the Brazilian individual taxpayer ID) or a CNPJ (the Brazilian company taxpayer ID) for Brazil, and the matching identifier for each other country in the docs' tax ID reference. Every destination also goes through verification, sanctions screening included, and a payout cannot be executed to a destination that is not approved.
Does the name or tax ID on the account have to match?
For a first-party payout it has to match the customer, by definition. For a third-party payout there is no customer record to match against, so the question is who checks that the name and tax ID given belong to the account. Three layers can, and they do not run the same check.
The three layers that can check a payee, and what each one looks at.
Layer | What it looks at | Who runs it |
The payment rail | Whether the account identifier points to a real account, and the name checks that rail has | The banks and the scheme, under each rail's own rules |
The sending provider | Whether a | The provider, when the destination is created |
Compliance review | Whether the relationship and the purpose make sense against the documents | The compliance team, when a transaction is held |
Name checks differ between Pix (Brazil's instant payment system) keys, SPEI (Mexico's interbank transfer system), SWIFT and SEPA. One rule is worth naming for euro payers: Regulation (EU) 2024/886, adopted on March 13, 2024, requires euro-area payment providers to offer a verification of the payee's name against the IBAN.
On Lumx, the checks on the destination are the SELF comparison, which covers the name as well as the holder type and tax ID, and the verification the banking partners run, which includes the payee-name check (VoP or CoP) where the rail has one. That result counts toward approving the destination, and Lumx does not return a separate VoP or CoP verdict. A tax ID that bank validation rejects comes back as INVALID_TAX_ID, a 400. The rest of a third-party payee is read at review, where compliance may ask for supporting documentation.
Which relationship fits which payout
One value is first-party, and twelve are third-party.
Every holder relationship in the Lumx docs, with the payout it describes and which side of the line it falls on. Read on November 1, 2026.
Relationship value | The destination belongs to | Side |
| The same legal entity as the customer | First-party |
| The parent or controlling company | Third-party |
| A subsidiary or controlled entity | Third-party |
| A branch, regional office or division | Third-party |
| A strategic partner or joint-venture collaborator | Third-party |
| A vendor paid for goods or services | Third-party |
| One of the customer's clients, for refunds or rebates | Third-party |
| A lender or a party the customer owes | Third-party |
| A party that owes the customer, in a settlement | Third-party |
| A franchisee operating under the customer's brand | Third-party |
| An employee or contractor on payroll or reimbursement | Third-party |
| A family member, for remittances | Third-party |
| A personal acquaintance, for P2P transfers or gifts | Third-party |
Four cases are easy to get wrong. A contractor is declared as EMPLOYEE. An affiliate or a creator is BUSINESS_PARTNER, and a beneficiary of an insurance claim is CUSTOMER, like a refund to a buyer. An importer paying a foreign vendor is SUPPLIER with the purpose trade transactions. And a P2P remittance carries the purpose BILLS, or PERSONAL_ACCOUNT when the money goes to the sender's own account. A company paying another entity in its own group is never SELF: use HOLDING_COMPANY for a parent and SUBSIDIARY_COMPANY for a subsidiary.
I would treat the relationship as a statement the payer's finance team signs, not a dropdown a developer fills in. The invoice or the contract already says who the payee is to the company, so the field should be filled from that document at the moment the payee is added, and not guessed later from the account number. When a team cannot say which of the thirteen values is true for a payee, I would rather hold that payee than pick the closest one, because the wrong value is a rejection today or a compliance question later.
A marketplace is the case that looks like a third-party payout and is not one. Each seller is onboarded as its own customer with its own wallet, and the payout is an off-ramp from the seller's wallet to a destination of the seller's, with relationship: SELF. The seller is paying itself, and the seller's money stays in the seller's wallet, never in a platform balance.
Why third-party payouts draw more questions
A payment to someone other than the owner of the funds has more ways to be something else: a real supplier invoice, or a pass-through for a party the provider has never seen. The amount does not tell them apart, so providers ask for the relationship and purpose.
The records have a legal source. In the United States, 31 CFR 1010.410(e) requires a nonbank financial institution to keep, for each transmittal of funds of $3,000 or more, the transmittor's name and address, the amount, the payment instructions and as many of the recipient's identifiers as were received with the order. It binds the institution moving the funds, not the sender.
Purpose is the field that carries this to the bank. Lumx's purpose codes include trade transactions for supplier invoices and import or export settlement, professional services for consulting or legal fees, and expenses reimbursement for employees and contractors. Banks use the purpose for AML screening, and a mismatch can hold the payment or trigger an RFI (request for information, a compliance hold that asks for a document before a transaction clears).
On Lumx, a payout flagged by transaction monitoring is put on hold, and compliance usually asks for the relationship between sender and receiver, the purpose and the expected outcome, by email or Slack. If the customer does not answer within 24 hours, the transaction may be refunded to the sender, so a payee declared correctly at the start is the shortest route through that review.
When is a third-party payout the wrong tool?
It is the wrong tool for moving someone else's money. Settling the customer's own debt to its own vendor is ordinary. A payout that moves another business's money to that business's vendor, through the customer's account, is nesting.
The Lumx compliance docs give one test before any transaction: whose money is it, and whose business does it pay for? If the answer to both is the onboarded customer, the payout fits. If either side names an entity that was never onboarded, it is nesting, and no relationship value changes that. Labeling a pass-through payment SUPPLIER does not make it the customer's supplier, and marking a business payee SELF fails the tax ID match.
The fix in the docs is to onboard every legal entity whose money moves as its own customer. For the account side of the same rule, see named virtual accounts versus pooled accounts.
On Lumx, a model that would otherwise look nested is permitted only when Lumx has approved it in writing and the customer operates strictly inside it. Pre-approval goes to compliance@lumx.io, and the docs say operational convenience, internal sub-ledgers and contracts with your own customers are not enough on their own. Transactions that fail the visibility test can be delayed, rejected or reversed.
Limits and rails by relationship
Limits follow the verification tier and the transaction type. Limit, KYB and onboarding are the same for first-party and third-party payouts; what changes is Lumx's risk appetite, which its high-risk and nested-structure rules cover. The published defaults, subject to change soon: for KYB Standard, $50,000 per transaction and $100,000 per day and per month, and for individuals, KYC (know your customer) Standard, $7,500 per transaction and $15,000 per day and per month. The detail is in payout limits by rail.
The rail follows the destination's country and currency. A company moving USDC to its own Brazilian account pays out over Pix, as in sending USDC to Brazil, and a supplier in Mexico is paid over SPEI to a CLABE (the 18-digit Mexican bank account number). The pairs: USDC to BRL and USDC to MXN.
The coverage page lists the live rails per country and currency, and the LATAM operator map shows who operates in each market. A rail not enabled for the project returns RAIL_NOT_ENABLED, whatever the relationship.
What this looks like on a payout with Lumx
Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.
The customer is the onboarded business, and every payout debits the customer's own wallet. The customer registers a destination with the holder's details and the relationship, waits for destinations.approved, and then sends the payout with a purpose that matches. A first-party payout carries PERSONAL_ACCOUNT, and a third-party one carries the purpose that describes what the money is for.
On a Pix payout the recipient sees the customer's name as the payer, not Lumx, because BRL accounts are named in the customer's own name. Named virtual accounts explains why, the product page shows the accounts, and global payments the pieces per country.
What breaks, and how it surfaces: a mismatched SELF destination is refused when the destination is created, with HOLDER_TYPE_MISMATCH or HOLDER_TAX_ID_MISMATCH as a 403, and a destination reports its progress through destinations.under_verification, destinations.approved and destinations.final_rejection. A payout flagged by transaction monitoring is held and goes to a request for information. Branch on the error code, since the message text can change. The KYB that onboards the customer in the first place is explained in what KYB is.
Methodology and sources
Product behavior was read on November 1, 2026 from the Lumx docs pages on destinations, nested payments, limits, request for information, purpose codes, errors and marketplaces. The US record-keeping rule was read in the text of 31 CFR 1010.410 on November 1, 2026, paragraph (e) on nonbank financial institutions.
Regulation (EU) 2024/886 of March 13, 2024 links to the official EUR-Lex page, which returned a bot-verification page on November 1, 2026, so the text itself was not read.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Walter Martin on Unsplash.
What is the difference between first-party and third-party payouts?
A first-party payout goes to an account owned by the same legal entity that owns the funds, and a third-party payout goes to any other person or company. On Lumx every destination declares a relationship, SELF for first-party and one of twelve other values for third-party, and a SELF destination must match the customer's tax ID and holder type.
Do third-party payouts need extra documents?
The API takes the relationship and the purpose, and compliance can request supporting documentation when it reviews a payout. On Lumx, a held payout gets a request by email or Slack, and a transaction left unanswered for 24 hours may be refunded to the sender.
Does the beneficiary name have to match the account in a third-party payout?
The name and tax ID must belong to the account, but a third-party payee has no customer record to be compared with, so the check moves to the rail and to compliance review. Each rail has its own name checks, and euro payers fall under Regulation (EU) 2024/886 of March 13, 2024. On Lumx, a SELF destination is compared with the customer's name, tax ID and holder type, the banking partners run the payee-name check, a tax ID that bank validation rejects returns INVALID_TAX_ID, and the rest is read on review.
Can I pay my customers' customers from my account?
Only when they are visible to the provider. Paying never-onboarded parties with someone else's funds is nesting, whatever the label. On Lumx, each legal entity whose money moves is onboarded as its own customer, and any layered structure needs written approval from compliance first.
What happens if I mark a third-party payee as SELF?
The first-party checks catch it. A SELF destination whose holder type differs from the customer's returns HOLDER_TYPE_MISMATCH, and one whose tax ID differs returns HOLDER_TAX_ID_MISMATCH, both as 403 errors when the destination is created. On Lumx the fix is to register the payee with the relationship that is true, such as SUPPLIER or EMPLOYEE, and pick the purpose that matches.
