---
title: "Does the recipient pay to receive a payout? Receiving fees on Pix, SPEI, ACH, RTP, SEPA, and SWIFT"
seoTitle: "Does the recipient pay to receive a payout? Fees by rail"
description: "Who pays when a payout lands: Pix rules for people and businesses, SPEI, ACH, RTP, SEPA's full-amount rule, SWIFT deductions, and the fee in the quote."
date: "2026-10-04"
updated: "2026-10-04"
category: "payments"
author: "BlindPay Team"
faq:
  - q: "Do recipients pay a fee to receive a Pix payment?"
    a: "Individuals usually don't. Banco Central do Brasil's Resolution BCB 19 bars banks from charging individuals, including sole proprietors, for receiving Pix transfers. A bank may charge an individual who receives Pix as payment for a sale, and it may charge businesses for sending and receiving. Any fee must appear on the receipt and in the bank's fee table."
  - q: "Do banks charge to receive a SPEI transfer in Mexico?"
    a: "SPEI itself is operated by Banco de México, which charges participating institutions a fixed fee plus a per-operation fee. What a bank charges its own customer is set by that bank. Mexican recipients should check their bank's fee schedule, since the rail does not deduct anything from the amount on the way in."
  - q: "Does a SEPA recipient receive the full amount?"
    a: "Inside the EU and EEA, yes by default. PSD2 Article 81 requires the payer's, payee's, and intermediary providers to transfer the full amount without deducting charges. A payee can agree with its own bank that the bank deducts its fee before crediting, but then the full amount and the fee must be shown separately to the payee."
  - q: "Why did a SWIFT payout arrive with less than was sent?"
    a: "Because correspondent and receiving banks can take fees from the principal along the way, depending on the charge code. With SHA or BEN, the recipient's side absorbs those deductions. Local rails like Pix, SPEI, ACH, RTP, and SEPA don't pass through a correspondent chain, so this kind of short payment is mostly a SWIFT problem."
  - q: "Who pays BlindPay's fee on a payout?"
    a: "You choose with cover_fees on the payout quote. With cover_fees false, the fee is deducted from the fiat amount the recipient receives. With cover_fees true, the fee is added on top of the stablecoin amount you send, so the recipient gets the full quoted amount. Payroll teams usually pick true so salaries land exact."
---

Usually not on local rails, but it depends on the rail, the recipient type, and their bank. Brazil bars Pix receiving fees for individuals on transfers. EU law makes SEPA credit the full amount by default. SWIFT is where intermediary banks take a cut from the principal. The provider's own fee is a choice you make in the quote.

Recipients ask this the week after their first payout. "I was told 5,400 and got 5,373." Somebody has to explain which layer took the difference. Three layers can.

**Key takeaways**

- Three parties can charge on a payout: the provider, the network or intermediary banks, and the recipient's own bank.
- Pix: banks can't charge individuals to receive a transfer. Businesses can be charged.
- SPEI: Banco de México charges banks, and each bank sets its own customer pricing.
- SEPA inside the EU and EEA must credit the full amount unless the payee agreed to a deduction shown separately.
- SWIFT is the rail where deductions from the principal are normal.
- On BlindPay, `cover_fees` decides whether the provider fee comes out of the recipient's amount or is added on top.

## Who can charge the recipient on a payout?

Three layers, and only one of them is in your quote.

1. **The provider fee.** What the payout provider charges for converting stablecoins and paying out. It shows up in the quote before anything moves. [How on/off-ramp providers make money](/resources/more/how-onramp-offramp-providers-make-money) breaks down where it sits: spread, flat fee, or both.
2. **Network and intermediary costs.** On local rails, the operator bills banks, not recipients. On SWIFT, correspondent banks can deduct from the amount itself.
3. **The recipient's bank fee.** The bank's own account pricing for incoming payments. It's set by the bank, under local rules, and no payout provider controls it.

The first one you choose. The second one you avoid by picking a local rail. The third one you can only check. The rest of this page goes rail by rail.

## Does a Pix recipient pay to receive?

Individuals generally don't. Businesses might.

Banco Central do Brasil's [Resolution BCB 19](https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolu%C3%A7%C3%A3o%20BCB&numero=19) prohibits the bank holding the account from charging a "cliente pessoa natural, inclusive empresários individuais" (an individual, including sole proprietors) for receiving funds sent as a transfer. Article 4 lists where fees are allowed:

- An individual receiving Pix "com a finalidade de compra", meaning as payment for a sale.
- A business (pessoa jurídica), for sending and receiving.

Article 7 adds a disclosure rule: any Pix fee must appear on the receipt of the transfer, on the account statement, and in the bank's published fee table.

For payouts, that splits cleanly. A contractor paid as a person, for work, receiving a transfer, normally sees no receiving fee. A Brazilian company receiving a supplier payment may, depending on its bank plan. If a business recipient complains about a deduction, ask for their bank's tariff table before you look at your own quote. [How to send USDC to a bank account in Brazil](/resources/more/how-to-send-usdc-to-bank-account-brazil) covers the payout side.

## Does a SPEI recipient pay to receive?

SPEI is run by Banco de México, which bills participating institutions, not end users. Banxico's SPEI page says it charges participants "una cuota fija y otra por operaciones" (a fixed fee and a per-operation fee) for using the system, and that SPEI runs on a 24/7 schedule ([Banco de México](https://www.banxico.org.mx/servicios/spei_-informacion-banco-mex.html)).

What a bank then charges its own customer for incoming SPEI is that bank's decision, set in its account terms. The rail doesn't skim the amount in transit. So the answer for a Mexican recipient is: check your bank's fee schedule. The CLABE format and other details a payout needs are in [Pix keys, CPF, and CLABE payout details](/resources/more/pix-key-cpf-clabe-payout-details).

## Do ACH and RTP recipients pay to receive in the US?

Neither rail deducts from the payment. Any fee is the receiving bank's account pricing.

ACH is governed by Nacha's operating rules, but what a bank charges for an incoming ACH credit is part of the account agreement. RTP, run by The Clearing House, offers "Instant Settlement: Final, anytime, every day" for payments up to $10 million per transaction ([The Clearing House](https://www.theclearinghouse.org/payment-systems/rtp)). Neither is a correspondent chain, so there's no intermediary bank in the middle taking a cut.

So the question for a US recipient is the same as in Mexico: what does my bank charge for an incoming ACH or RTP credit? The answer lives in their account fee schedule, and it can differ between a personal and a business account at the same bank.

## Does a SEPA recipient get the full amount?

Inside the EU and EEA, by default, yes. Article 81 of the Payment Services Directive (PSD2) requires the payer's provider, the payee's provider, and any intermediaries to transfer the full amount and "refrain from deducting charges from the amount transferred" ([EUR-Lex, Directive 2015/2366](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02015L2366-20250117#art_81)).

There's one exception. The payee and its own bank may agree that the bank deducts its fee before crediting, but then "the full amount of the payment transaction and charges shall be separated in the information given to the payee." So a SEPA recipient may see a fee, but it's visible on their statement as a separate line.

One scope note. BlindPay's SEPA destinations include non-EEA countries such as Switzerland and the United Kingdom ([payment methods](/docs/kb/payment-methods)). Banks there follow their own national rules, so check the recipient's bank.

## Why do SWIFT payouts arrive short?

Because SWIFT runs through correspondent banks, and the charge code decides who absorbs their fees. With OUR, the sender pays. With SHA, the sender pays its bank and the rest comes out of the principal. With BEN, everything comes out of the principal. [Hidden fees in international wires](/resources/more/hidden-fees-international-wires-our-sha-ben) walks through a short-paid $25,000 invoice.

BlindPay sends SWIFT (POBO/COBO) payouts in USD. Each carries a UETR for end-to-end tracking, and the MT103 confirms what was sent. When a beneficiary's bank needs a correspondent, the bank account takes optional intermediary bank fields ([bank accounts](/docs/bank-accounts)). Where the recipient's country has a local rail, use it instead.

## How do the rails compare?

| Rail | Region | Rule on receiving fees | What to check |
| --- | --- | --- | --- |
| Pix | Brazil | Banks can't charge individuals to receive a transfer; businesses can be charged (BCB Resolution 19) | Business recipients: their bank's tariff table |
| SPEI | Mexico | Banxico bills participating banks; customer pricing is each bank's own | Recipient's bank fee schedule |
| ACH | United States | No correspondent chain; any fee is the bank's account pricing | Recipient's account fee schedule |
| RTP | United States | Instant and final; any fee is the bank's account pricing | Recipient's account fee schedule |
| SEPA | EU and EEA | Full amount by default; a payee-agreed bank fee must be shown separately (PSD2 Art. 81) | Statement line for the fee |
| SWIFT | Global | Correspondents can deduct from the principal under SHA or BEN | Charge code and MT103 fields 71A, 71F, 71G |

## Who pays the provider fee on a BlindPay payout?

You decide, per quote. The `cover_fees` setting on a [payout quote](/docs/payout-quotes) has two values:

- `cover_fees: false`: the fee is deducted from the fiat amount the recipient receives. This is the most common setting.
- `cover_fees: true`: the fee is added on top of the stablecoin amount you send, so the recipient receives the full amount.

Payroll teams usually choose `true`, because a salary that lands 0.5% short starts a support thread.

Illustrative example. A company pays a Brazilian contractor about R$ 5,400 over Pix. The rate and fee here are made up to show the mechanics, not BlindPay pricing: an illustrative rate of 5.40 BRL per USDC and an illustrative total fee equal to R$ 27.

| Setting | You send | Recipient's quote shows | Bank fee (individual on Pix) | Lands in account |
| --- | --- | --- | --- | --- |
| `cover_fees: false` | 1,000 USDC | R$ 5,373.00 | R$ 0.00 | R$ 5,373.00 |
| `cover_fees: true` | 1,005 USDC | R$ 5,400.00 | R$ 0.00 | R$ 5,400.00 |

If the same payment went to a Brazilian company whose bank charged, say, an illustrative R$ 1.50 to receive, the last column would drop by R$ 1.50 in both rows. That fee is outside every payout quote, on any provider. BlindPay's actual fees vary by rail and network and are disclosed in the live quote before execute; there's no static rate card.

## What to do next

Before your first payout run to a new country, send one small test payment to a business recipient and one to an individual, and ask both what landed. Compare that with the `receiver_amount` on each quote. If the numbers match, set `cover_fees` once for the whole program and move on.