A third-party payment in Brazil is a transfer in which the payer, or the account that receives the money, belongs to someone other than the business that owns the funds and the invoice. It is routine when the provider can see and verify every party. It becomes a problem when one account moves money for parties nobody onboarded.
This guide covers both directions: a payer who is not your customer, and a payee who is not you. It is written for payments, operations and compliance leads at platforms that move money in Brazil over Pix (Brazil's instant payment system, run by the Central Bank), with a named virtual account in the customer's name on the receiving side.
What counts as a third-party payment in Brazil?
Three cases, and providers treat them differently. Brazilian rules do not ban third-party payments as such. The verdicts below are provider policy, here Lumx's, and not a statute. The test is who owns the money and whose obligation it pays: if the answer to both is the onboarded customer, the payment is first-party, even when a bank or a payment arrangement sits in the middle. A group company that is the real payer or payee is a third party; one that only routes the customer's own money is not.
The three third-party cases, what the provider checks in each, and whether it fits Lumx's rules, read from the Lumx documentation on November 6, 2026.
Case | Example | What gets checked | Fits Lumx's rules? |
A third party pays in | A buyer's group treasury entity pays your customer's invoice | The payer against the flow of funds your customer declared, and the invoice | Yes, if it matches the declared flow. An unusual payer can trigger a hold |
A third party is paid | A company pays a supplier, a contractor or a subsidiary, or a parent pays a subsidiary's supplier from its own wallet | The relationship the sender declares, the purpose, and the payee's name and tax ID | Yes, with the relationship declared accurately. A parent paying a subsidiary's supplier is allowed with the flow of funds approved in writing |
A pass-through | A platform pays or collects for its own clients, whom the provider never onboarded | Whose money it is, and whose business it pays for | No, unless every party is onboarded or approved in writing |
A subsidiary and its parent are third parties to each other: two legal entities, each with its own CNPJ (the Brazilian company taxpayer ID), its own KYB (know your business, the verification of a company and its owners) and its own money. The payout-only version of this split is in first-party vs third-party payouts.
How a Brazilian account identifies its holder
Every account holder in Brazil has a CPF (the Brazilian individual taxpayer ID) or a CNPJ, and Pix ties each payment key to it. The Pix regulation, Resolution BCB 1 of August 12, 2020, has the central directory store the individual's full name (civil name or social name, as registered in the CPF) or the company name as registered in the CNPJ (Article 59). Since July 1, 2025 the bank registering a key must also validate that name against the CPF or CNPJ (Article 57, item III, added by Resolution BCB 457 of March 6, 2025).
That is what makes a third-party payee checkable: a provider has a tax ID and a registered name to match against what the sender typed. The rail cannot say why the money is moving, so relationship and purpose are asked separately.
On Lumx, a payout destination carries the holder's details, and it has to be approved before any payout uses it. The verification includes sanctions screening and a payee name check run by the banking partners. On Pix the payee's statement shows the customer as the sender, per the Lumx sender-of-record page, so a supplier sees the paying company and not the platform.
Paying a third party: supplier, contractor or subsidiary
When a customer pays someone else, Lumx asks it to declare the relationship on the destination. SELF marks the customer's own account, and twelve other values cover everyone else: HOLDING_COMPANY, SUBSIDIARY_COMPANY, BRANCH_OFFICE, BUSINESS_PARTNER, SUPPLIER, CUSTOMER, CREDITOR, DEBTOR, FRANCHISEE, EMPLOYEE, RELATIVE and FRIEND. Only SELF accepts the PERSONAL_ACCOUNT purpose.
How common Brazilian payees map to a declared relationship, from the Lumx destinations documentation and the purpose codes the Lumx team confirmed on November 2, 2026.
Payee | Relationship | Note |
The customer's own account |
| The only relationship that takes |
A supplier's invoice |
| Purpose |
A contractor |
| The value covers employees and contractors |
A subsidiary funded by its parent |
| Purpose |
A refund to a client |
| For refunds and rebates owed to clients |
Declaring a third party does not slow every payout down. Lumx asks for no document on each one, and first-party and third-party payments have the same limits, KYB and onboarding. It changes how a flagged payout is read: if monitoring holds it, compliance sends an RFI (request for information, a compliance hold that asks for a document before a transaction clears), usually asking for the relationship between sender and receiver, the purpose, the expected outcome and context such as an invoice. A hold unanswered for 24 hours may be refunded to the sender.
The payout itself is a stablecoin off-ramp from the customer's wallet. For the contractor version of this flow, see paying contractors in Brazil with stablecoins.
Being paid by a third party
The opposite case is the payer your customer did not plan for: a parent company paying a subsidiary's invoice, or a buyer's treasury entity that has a different name from the buyer on the contract. The receiving side is a named account in the customer's own name, so the payer sends to details that identify the customer as the beneficiary, and the payer's bank may compare the name it sees with the name it was given.
A provider can only judge an unusual payer against something. On Lumx that something starts at KYB, where the business declares its source of funds, expected volume and counterparties, and it becomes the expected flow of funds. A third party can fund an on-ramp or a deposit if the payment is coherent with that flow. When a payer looks out of the ordinary, the deposit can be held with an RFI, and a hold that goes unanswered can end in a return to the payer.
Counterparties are collected in the KYB transactional information, so a payer in the business's normal flow is already on record. The mechanics of a deposit that does not arrive are in receiving USD payments, and the account structure behind the name check is in named accounts compared with pooled accounts.
When does a third-party payment become nesting?
When the money or the obligation belongs to a party the provider cannot see. Lumx documents the test as one question before any transaction: whose money is it, and whose business does it pay for? If either answer is an entity Lumx has not onboarded, it is nesting.
What the Lumx documentation allows and refuses for the three models that most often cross the line, read on November 6, 2026.
Model | Allowed | Nesting |
Marketplace | Each seller is onboarded as its own customer, and the platform collects its fee as a partner fee | Buyer funds land in the platform's account and are distributed to sellers who were never onboarded |
Payroll provider | Each employer holds its own account and pays from it | The provider pays employees of several employers from its own account |
Payment processor | Every merchant whose funds move is onboarded, or covered by a written structure | One relationship moves funds for many merchants the provider has not seen |
Some layered models can be approved in writing after enhanced due diligence, by emailing compliance@lumx.io before the first payment. Operational convenience, internal sub-ledgers and contracts with the platform's own clients are not enough. A flagged structure can be delayed, rejected or reversed.
The structures a provider refuses outright are covered in which activities providers refuse outright.
Onboard the party you pay for
I tell every platform that wants to pay or collect for its own clients the same thing: onboard each client as a customer before the first payment, even if it adds weeks to the launch. A written approval for a layered structure is possible, but it is the slower and narrower road, and a structure that a provider approved will survive a hold that a workaround will not.
Who verifies the parties, and who reports
The provider verifies the customer, then every destination. On Lumx, each business customer completes KYB, with documents and associated parties, and each end user is its own customer with its own KYC (know your customer, the verification of an individual). An individual verified on the partner's own Sumsub account, under a data-sharing agreement with Lumx, can bring that verification through a share token, which saves the document upload and the liveness check. The limits are covered in what a provider can reuse, and the checks themselves are explained in what KYB is.
On reporting, the Lumx team confirmed that Lumx reports its customers' operations to the Receita Federal (Brazil's federal tax authority) and COAF (Brazil's financial intelligence unit) as the SPSAV (a Brazilian virtual asset service company) that filed for authorization and operates under the transition regime. Lumx reports under IN RFB 1.888/2019, IN RFB 2.291/2025 (DeCripto) and the Annex II-A report to the Central Bank (Article 82-A of Resolution BCB 521/2025). The transition regime is Article 88 of Resolution BCB 520 of November 10, 2025: companies already running these activities must request authorization within 270 days of the resolution taking effect on February 2, 2026. Lumx filed its request on October 27, 2026. A platform that is itself a VASP (virtual asset service provider) in Brazil reports its own operations; this post does not describe any other duty of the client. The wider picture is in AML for fintechs using stablecoins.
When a third-party structure is the wrong tool
Three situations call for a different design.
You hold money for clients you have not onboarded. A pooled balance distributed off the platform is the textbook nested structure, and Lumx lists client trust and pass-through accounts among the activities it does not support.
The invoice and the payer do not match. If the invoice names one entity and a different one pays, fix the paperwork before the money moves: ask the payer to pay from the invoiced entity, or have the invoice reissued to the entity that pays.
The party you pay for is one the provider refuses. Onboarding it does not change that.
What a third-party payment looks like on Lumx in Brazil
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.
Take a Brazilian company that pays a supplier and is paid by a buyer's group entity in one week. It registers the supplier as a destination with SUPPLIER as the relationship, the supplier's Pix key and tax ID, and waits for approved. The payout is an off-ramp from the company's wallet, with TRADE_TRANSACTIONS as the purpose and the invoice number as the memo, and the supplier's bank statement shows the company as the sender. If monitoring flags the payout, the hold and the RFI arrive on the channel the company already uses with Lumx, by email or Slack, and the 24-hour clock starts.
On the collection side, the company shares the Pix details of its named BRL account with the buyer. A foreign company can hold that account without a local entity in Brazil, and it activates as soon as KYB is approved. The buyer's group entity pays from its own bank account, the deposit is matched against the flow declared at KYB, and an unusual payer can produce an RFI instead of a credit. The named virtual accounts page describes the product and coverage by country and rail is listed separately.
Methodology and sources
Product facts come from the Lumx documentation pages on nested payments, POBO and COBO, destinations, sender of record, request for information, accounts, identity verification, KYC reuse and prohibited business activities, all read on November 6, 2026. Pix key rules come from the text of Resolution BCB 1 of August 12, 2020 (Articles 57 and 59, as amended through Resolution BCB 457 of March 6, 2025), read on the Central Bank's norms API on November 6, 2026. The transition regime and the 270-day period come from Article 88 of Resolution BCB 520 of November 10, 2025, whose Article 92 sets February 2, 2026 as its start; the Annex II-A reference is Article 82-A of Resolution BCB 521 of November 10, 2025, both read on the same API on November 6, 2026. The Receita instruments are named from the Receita Federal crypto-assets page, read the same day; their texts were not, so no filing deadline is stated. Relationship and purpose pairings, the 24-hour hold window, the reporting position and the October 27, 2026 filing date were confirmed by the Lumx team on November 2 and 6, 2026.
Verified on November 6, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: TECNIC Bioprocess Solutions on Unsplash.
What are third-party payments in Brazil?
A third-party payment in Brazil is a transfer where the payer or the receiving account belongs to someone other than the business that owns the funds and the invoice, such as a buyer's group company paying an invoice or a company paying a supplier. It is accepted when the provider can verify every party. On Lumx, the customer declares the payee's relationship on each destination, and anything that moves for a party Lumx never onboarded is nesting.
Can a third party pay into my business account in Brazil?
Yes, if the payment fits the flow of funds you declared when you were verified. An unusual payer can put the deposit on hold with a request for information, and a hold that goes unanswered for 24 hours may end in a return to the payer. On Lumx, third-party collections are permitted, and the counterparties declared at KYB are the baseline a deposit is read against.
What do I declare when I pay someone else's account?
You declare who the payee is to you and why you are paying. The relationship says whether the payee is a supplier, an employee, a subsidiary or another party, and the purpose says what the payment is for. On Lumx, the relationship goes on the destination, only SELF accepts a personal-account purpose, and a flagged payout is held until you answer the compliance questions.
When does paying for my own clients become nesting?
When those clients are not onboarded with the provider and their money moves through your account. The test is whose money it is and whose business it pays for. On Lumx, each seller, employer or merchant has to be its own customer, or covered by a structure approved in writing through compliance@lumx.io before the first payment.
Who reports third-party payments to the authorities in Brazil?
Each provider reports under its own status. On Lumx, the team confirmed that Lumx reports its customers' operations to the Receita Federal and COAF, under IN RFB 1.888/2019, IN RFB 2.291/2025 and the Annex II-A report, as the SPSAV that filed for authorization on October 27, 2026 and operates under the transition regime. A platform that is itself a VASP in Brazil reports its own operations.
