Intercompany payments with stablecoins: funding a Latin American subsidiary with USDC

An intercompany payment with stablecoins works like any other cross-border payout: the parent sends USDC, the provider converts it, and the subsidiary receives local currency in its own bank account over Pix, SPEI, or another local rail. Two things are different. The payout counts as third party, and the paperwork behind it has to satisfy transfer pricing and FX rules.

The mechanics of fiat in, stablecoin across, fiat out are covered in what is a stablecoin sandwich. This page is about the group-treasury version, where the payer and the payee share an owner.

Key takeaways

• A subsidiary is a separate legal entity, so parent-to-subsidiary payouts are third party, not first party.
• Every intercompany transfer needs a reason on paper: a services invoice, a loan, or a capital contribution.
• Transfer pricing rules apply to the price, whatever rail settles it.
• Fund the subsidiary, then let it pay its own suppliers. Paying its bills from the parent's account looks like nesting.
• Local rails settle in minutes in Brazil and Mexico, so a subsidiary can be funded the morning payroll runs.

Why do groups fund subsidiaries with stablecoins?

Because the traditional route stacks delays and spreads on a payment that never leaves the group. A US parent wiring dollars to a Brazilian subsidiary pays its bank's FX markup, waits on correspondent banks, and often holds a buffer in the subsidiary's account to cover the gap. Nostro and vostro accounts explained shows why that buffer exists.

The Federal Reserve's FEDS Note of March 30, 2026 puts numbers on the chain: over 60 percent of wholesale payments go through one or more intermediaries, and the number of active correspondent banks fell about 30 percent in the decade to 2022. Fewer correspondents means longer chains for less common currency pairs.

With a stablecoin leg, the parent converts dollars into USDC once, then pays out in reais or pesos the day the money is needed. No idle float sits in the subsidiary's account waiting for a wire that may take three days.

Is a payment to your own subsidiary first party or third party?

Third party. A first-party payout goes to an account owned by the same entity that owns the funds. Your subsidiary is a different company with its own tax ID, even if you own 100 percent of it.

On BlindPay, bank accounts on SWIFT, ACH, wire, and RTP carry a required recipient_relationship field, and the right value here is subsidiary_or_affiliate (bank accounts docs). Setting first_party would fail the name check, because the beneficiary name has to match the customer. First-party vs third-party payouts covers what each value triggers.

Pix accounts don't carry the field at all. They take a name and a Pix key. The relationship still exists in your records, which is where an auditor will look.

Which intercompany flows can you pay this way?

The common ones, as long as each has a document behind it.

1. Service fees. The subsidiary invoices the parent for engineering, support, or sales work, usually on a cost-plus basis. The parent pays the invoice.
2. Cost reimbursements. The subsidiary fronts local expenses and invoices them back at cost.
3. Payroll funding. The parent funds the subsidiary's account ahead of payroll, and the subsidiary pays its employees locally. The underlying document is usually the services agreement or a funding resolution.
4. Intercompany loans. A loan agreement with an interest rate and repayment terms.
5. Capital contributions. Equity going into the subsidiary, backed by a board or shareholder resolution.

Each type is taxed and reported differently. In Brazil, Law 14.286/2021, the new FX framework, covers foreign capital in Brazil and the information companies report to the Banco Central do Brasil. A loan or a capital contribution is not a services invoice, so ask your local accountant which category each transfer falls into before you pay it.

Since February 2, 2026, Brazil's Resolution 521 also treats international payments with virtual assets as foreign exchange operations (Resolution BCB 521). The stablecoin leg doesn't put the payment outside the FX rules. It's an FX operation with a different settlement asset.

How does transfer pricing apply to a USDC payment?

Exactly as it does to a wire. Transfer pricing rules look at the price of a transaction between related companies, and ask whether unrelated parties would have agreed to it. That's the arm's length principle in the OECD Transfer Pricing Guidelines (2022 edition).

Brazil moved onto OECD-style rules with Law 14.596/2023, mandatory from January 1, 2024. Mexico applies the arm's length principle to related-party transactions in its income tax law (Ley del ISR, articles 179 and 180).

What the stablecoin changes is the evidence trail, and mostly for the better. Every payout has a quote with a locked rate, a fee breakdown, a timestamp, and an on-chain transaction hash, plus a bank-side reference. Keep three things together for each transfer:

• The intercompany agreement or invoice that sets the price.
• The quote, showing the exchange rate and fees at execution.
• The payout record, with its status history and bank reference.

How to book a stablecoin payout shows the journal entries on both sides, including the FX difference between the invoice date and the payment date.

Can the parent pay the subsidiary's suppliers directly?

It can look convenient. It's also where groups get into trouble.

If the parent's account pays a Mexican landlord for the subsidiary's office, the lease names the subsidiary, the payment comes from the parent, and the money settles an obligation that isn't the parent's. BlindPay's nested payments guide lists that exact pattern as a sign of nesting: payment documentation that names a different entity than the account holder.

The cleaner setup takes one extra step. Fund the subsidiary, then let the subsidiary pay its own bills. If the subsidiary needs its own payout flows, onboard it as its own customer, so every party is visible. The guide notes that a business rejected for nesting can be onboarded as its own instance at no additional setup cost.

How fast does the money reach the subsidiary?

Minutes on instant rails, days on the slower ones. Timing per the payment methods reference:

A compliance review can add time on any rail. SWIFT payouts to a subsidiary start on_hold and wait for the intercompany document, which has to be submitted within 30 days of payout creation and is reviewed within 8 days (SWIFT statuses). SWIFT payouts carry UETR tracking and MT103 confirmations, which treasury can match against the subsidiary's bank statement.

Illustrative example: a US parent funds a Brazilian subsidiary's monthly payroll of R$250,000. Treasury requests a quote for exactly R$250,000 the morning of payroll, executes within the 5-minute window, and the reais land over Pix before the payroll file runs. The parent held USDC, not a three-day buffer of reais.

How does BlindPay handle this?

The parent onboards once, adds the subsidiary's bank account with recipient_relationship set to subsidiary_or_affiliate where the rail asks for it, and requests a quote. The quote locks the rate and fees for 5 minutes. BlindPay combines a monthly plan with per-transaction fees that vary by rail and network, disclosed in the live quote before execute.

BlindPay operates as a non-custodial payment processor for payout flows from customer-controlled wallets: you authorize the exact amount and BlindPay executes that single transaction. If a payout cannot be delivered after the stablecoins are collected, BlindPay refunds them to the quote's refund wallet, or to the sending wallet when none is set; on Pix and other non-USD local rails the refund is automatic, while USD payouts and payouts whose review times out are refunded after an operator review. Optional BlindPay-managed wallets (beta) are custodial when you choose that path.

What to do next

List every intercompany flow your group runs today, and write next to each one the document that justifies it. Any flow without a document is the one to fix before you change the rail. Then request a test quote to your subsidiary's account on a development instance, following the payout quotes docs.