Does the recipient pay to receive a payout? Receiving fees on Pix, SPEI, ACH, RTP, SEPA, and SWIFT

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

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.

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

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). 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 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). Where the recipient's country has a local rail, use it instead.

How do the rails compare?

Who pays the provider fee on a BlindPay payout?

You decide, per quote. The cover_fees setting on a payout quote 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.

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.