---
title: "Stablecoin payouts for NGOs and aid programs: fixed local amounts, local rails, and donor-ready records"
seoTitle: "Stablecoin payouts for NGOs and aid programs"
description: "How aid programs use stablecoin payouts: lock the local amount each household gets, pay over Pix or SPEI, screen recipients, keep donor-ready records."
date: "2026-10-12"
updated: "2026-10-12"
category: "payments"
author: "BlindPay Team"
faq:
  - q: "Can NGOs use stablecoins to pay aid recipients?"
    a: "Yes, and some already do. UNHCR piloted cash assistance in Ukraine in 2022, delivering USDC on the Stellar network to a smartphone wallet, with cash-out at participating MoneyGram locations. Another model keeps the stablecoin leg behind the scenes: the program holds USDC, and each recipient gets local currency in a bank account over a domestic rail such as Pix in Brazil or SPEI in Mexico."
  - q: "How does a locked quote help an aid program?"
    a: "It fixes what the household receives before the money leaves. With a receiver-side quote, the program asks for an exact local amount, for example MX$ 3,000, and the quote returns how much USDC that costs. The recipient gets the promised amount, the program knows the dollar cost, and the exchange rate on the record matches the one actually used."
  - q: "Do aid payouts still need sanctions screening?"
    a: "Yes. Humanitarian purpose does not remove screening duties. OFAC's December 2022 action issued or amended general licenses for transactions in support of certain nongovernmental organizations' activities, but programs and their payment providers still screen recipients and counterparties. Expect onboarding questions about where you operate, who you pay, and how you verify eligibility."
  - q: "Are charities a high-risk category for payment providers?"
    a: "Often, yes. BlindPay's activity policy lists charities and NGOs among high-risk categories. That doesn't mean rejection. It means disclosure during onboarding, enhanced due diligence, and ongoing monitoring. Prepare your registration documents, funding sources, program countries, and a description of how beneficiaries are selected before you apply."
  - q: "What records should an NGO keep for each stablecoin payout?"
    a: "For every payment: the beneficiary ID, the quote ID, the market rate and the rate after fees, each fee line, the local amount received, the stablecoin amount sent, the timestamp, and the final status. Those fields let you report spend per household in both currencies, reconcile against the program budget, and answer a donor or auditor question about any single payment."
---

Aid programs use stablecoin payouts to fix the exact local amount each household receives, deliver it over a domestic rail like Pix or SPEI, and keep a per-payment record donors can audit. The program funds in dollars. A receiver-side quote converts at a locked rate, and the beneficiary sees local currency in their bank account.

Cash assistance has a simple goal: the right amount reaches the right person fast, and every dollar is accounted for. Stablecoin rails help with all three, but only if the program designs around quotes, screening, and records from the start. Why the rate on a payout costs what it does is explained in [how on/off-ramp providers make money](/resources/more/how-onramp-offramp-providers-make-money).

**Key takeaways**

- Fix the local amount, not the dollar amount. A receiver-side quote makes "MX$ 3,000 per household" a promise you can keep.
- Two delivery models exist: a stablecoin wallet with cash-out, or a local bank payout where the stablecoin stays behind the scenes.
- Humanitarian purpose doesn't remove screening. Expect enhanced due diligence at onboarding.
- Store the quote ID, both rates, and every fee line per payment. That is the donor report.
- Run payouts in batches with a fresh quote per row, executed inside each 5-minute window.

## What are the two ways to deliver aid on stablecoin rails?

Either the beneficiary holds the stablecoin, or the beneficiary only sees local currency. The choice depends on whether recipients have bank accounts.

The wallet model is what UNHCR piloted. Per Stellar's [UNHCR case study](https://stellar.org/case-studies/unhcr), the program first ran in 2022 in Ukraine, starting in Kyiv, Lviv, and Vinnytsia. Recipients receive USDC in the Vesseo smartphone wallet and can get cash at participating MoneyGram locations, with no bank account required. The case study credits the design with "full value transfer traceability and accountability."

The bank payout model fits programs whose recipients are banked, which covers much of Latin America. The program holds USDC, and each payout converts to local currency over a domestic rail. The household never touches a wallet.

| | Wallet with cash-out | Local bank payout |
| --- | --- | --- |
| What the recipient gets | USDC in a smartphone wallet | BRL, MXN, ARS, or COP in a bank account |
| Recipient needs | A smartphone and a cash-out point | A bank account or Pix key, CLABE, or CBU |
| FX moment | At cash-out, by the recipient | At the payout quote, by the program |
| Who carries rate risk after delivery | The recipient, until cash-out | Nobody, the amount is already local |
| Example | UNHCR Ukraine pilot | Pix or SPEI payout from a USDC balance |

BlindPay works in the second model: it pays bank accounts over Pix, SPEI, Transfers 3.0, ACH Colombia, ACH, SEPA, and SWIFT (POBO/COBO) from a stablecoin balance ([payment methods](/docs/kb/payment-methods)).

## Why should an aid program fix the local amount?

Because households budget in local currency. A transfer value set at "the equivalent of $160" turns into a different number of pesos every week, and families can't plan rent or food around a moving target.

A receiver-side quote fixes the other end. On a BlindPay payout quote, `currency_type: receiver` makes `request_amount` the local amount the bank account receives, and the quote returns the stablecoin cost ([payout quotes](/docs/payout-quotes)). [Paying an exact local amount](/resources/more/pay-exact-local-amount-receiver-side-quote) walks through the mechanics.

**Illustrative example.** A program pays 200 households in Mexico MX$ 3,000 each, over SPEI. At a quoted rate of 18.40 MXN per USDC after fees:

- USDC per household: 3,000 / 18.40 = 163.04 USDC
- Total for the cycle: 163.04 x 200 = 32,608.70 USDC (rounded per payment)
- If the peso weakens to 18.90 next cycle: 3,000 / 18.90 = 158.73 USDC per household, or 31,746.03 USDC in total

The household gets MX$ 3,000 both times. The program's dollar cost moves by 862.67 USDC between cycles, which belongs in the budget variance line, not on a family's kitchen table. Hold a buffer of a few percent in the float for that swing.

## How do screening and onboarding work for NGOs?

More slowly than for a typical business, so plan for it. BlindPay's [high-risk activities list](/docs/kb/prohibited-activities) names charities and NGOs. High-risk categories are allowed with disclosure during onboarding, enhanced due diligence, and ongoing monitoring.

Expect questions in four areas:

1. **Who you are.** Registration documents, governing body, and beneficial owners or controllers.
2. **Where the money comes from.** Donors, grants, and how funds reach the program.
3. **Where it goes.** Program countries and how beneficiaries are selected and verified.
4. **How you prevent diversion.** Eligibility checks, duplicate detection, and complaint handling.

Sanctions rules still apply. OFAC's [December 20, 2022 action](https://ofac.treasury.gov/recent-actions/20221220) issued or amended four general licenses, including one for "transactions in support of certain nongovernmental organizations' activities," effective upon Federal Register publication on December 21, 2022. Licenses define what is authorized. They don't replace screening of each recipient and counterparty. [How often to rescreen](/resources/more/ongoing-sanctions-screening-how-often-to-rescreen) covers the ongoing side.

Visibility matters too. Each beneficiary's bank account should be its own record, so the provider can see who receives every payment. One account paying many unseen parties is the pattern providers block.

## How do you run a distribution cycle?

As a batch with one quote per row. A list of 200 households is 200 payouts, each with its own quote and its own 5-minute window.

1. **Freeze the list.** Export eligible beneficiaries with their bank details and the local amount for this cycle.
2. **Check the float.** Sum the estimated USDC cost at the current rate plus your buffer.
3. **Quote and execute row by row.** Request each quote right before you execute it. Never quote the whole list first and execute later.
4. **Handle failures.** A rejected account detail becomes a follow-up task, not a silent skip. If a payout can't be delivered after the stablecoins are collected, BlindPay refunds them; on Pix and other non-USD local rails the refund is automatic.
5. **Close the cycle.** Reconcile delivered amounts against the list and report the USDC actually spent.

Pix settles in up to 5 minutes and SPEI in up to 10, per BlindPay's [cut-off times](/docs/kb/cut-off-times). [Batch payouts with live quotes](/resources/more/batch-stablecoin-payouts-live-quotes) has the row-by-row pattern in code.

## What should donors see in the records?

Every payment, in both currencies, with the rate that was actually used. Donors and auditors ask the same three questions: how much reached people, what did delivery cost, and can you prove a specific payment happened.

| Field | Where it comes from | What it answers |
| --- | --- | --- |
| Beneficiary ID | Your program system | Who was paid |
| Quote ID | Payout quote `id` | Which locked price applied |
| Market rate | `commercial_quotation` | What the market rate was at that moment |
| Rate after fee | `blindpay_quotation` | What the program paid per USDC |
| Fee lines | Quote fee fields | What delivery cost |
| Local amount | `receiver_amount` | What the household received |
| Stablecoin amount | `sender_amount` | What it cost in dollars |
| Status and timestamp | Payout webhooks | That it arrived, and when |

The gap between the two rates, plus the fee lines, is your cost of delivery per payment. Fees are per transaction, vary by rail and network, and are disclosed in the live quote before execute, so the record shows real numbers instead of a rate card estimate. For a consumer-style build where senders are individuals, [the remittance app guide](/resources/more/remittance-app-onramp-offramp-api) covers the disclosure side.

## What to do next

Pick one country and one rail, onboard on a development instance, and run a 10-row test cycle with receiver-side quotes. Export the record table above from the results and show it to your finance team before the first real distribution.