---
title: "FX policy template for stablecoin payouts: tolerances, approvals, and float limits"
seoTitle: "FX policy template for stablecoin payouts"
description: "A copyable FX policy for stablecoin payout teams: who can execute, re-quote tolerances, approval thresholds, float and depeg limits, and review cadence."
date: "2026-10-17"
updated: "2026-10-17"
category: "payments"
author: "BlindPay Team"
faq:
  - q: "What is an FX policy for stablecoin payouts?"
    a: "It is a short internal document that says who can move money, which quotes your team may accept, how far a re-quote can drift before someone approves it again, how much stablecoin you hold and where, and how often the numbers get reviewed. It turns judgment calls made under a 5-minute quote window into rules written in advance."
  - q: "What re-quote tolerance should a payout team set?"
    a: "Many teams start with an automatic band of around 50 basis points between the approved estimate and the live quote, and send anything wider back for approval. The right number depends on corridor volatility, so set it per corridor and revisit it monthly using your own re-quote delta data instead of a number copied from another company."
  - q: "Does BlindPay have roles that map to a maker-checker process?"
    a: "BlindPay instances have seven member roles: owner, admin, finance, checker, operations, developer, and viewer. The docs list owner, admin, finance, checker, and operations as the roles that hold the transaction-create permission for transfer quotes. The approval step itself is your process: decide who prepares a run and who signs it off before anyone executes."
  - q: "How much stablecoin should the policy allow us to hold?"
    a: "Set a floor and a ceiling in days of payouts, not in dollars. A floor of a few days covers refill time; a ceiling caps exposure to one token, one network, and one provider. The float sizing formula, refill time by rail, and the cost of holding a balance are worth working through before you pick the numbers."
  - q: "How often should the FX policy be reviewed?"
    a: "Review the numbers monthly and the whole document at least once a year, plus any time you add a corridor, a token, or a network. Monthly reviews look at expiry rate, re-quote delta, delivery success, and cost per delivered dollar, then adjust tolerances. The annual review checks roles, limits, and whether the policy still matches how money actually moves."
---

An FX policy for stablecoin payouts is a one-page rulebook: who can execute, which quotes you accept, how far a re-quote may drift before re-approval, how much stablecoin you hold, and when you review it. Quotes last 5 minutes, so the decisions have to be made before the quote exists. Copy the template below and fill in your numbers.

Most payout teams already have these rules. They just live in Slack threads and in one person's head. Writing them down is what lets a second person run payroll on a Friday without calling the first.

**Key takeaways**

- Decide approvals on estimates and tolerances, then let the run quote and execute live.
- Map duties to BlindPay's member roles: owner, admin, finance, checker, operations, developer, viewer.
- Set the re-quote tolerance per corridor in basis points and measure it monthly.
- Size the float in days of payouts, with a floor and a ceiling.
- Write the depeg and failed-payout playbooks before you need them.

## Why does a stablecoin payout team need an FX policy at all?

Because the 5-minute quote window removes the time to ask. A payout quote locks the rate and fees for 5 minutes, sometimes less on SEPA and Faster Payments ([cut-off times](/docs/kb/cut-off-times)). Nobody convenes a meeting inside that window.

Controls also pay for themselves. The ACFE's 2026 Report to the Nations, built from 2,402 real occupational fraud cases, says the presence of anti-fraud controls is associated with lower fraud losses and quicker detection ([ACFE](https://www.acfe.com/fraud-resources/report-to-the-nations)). Segregating who prepares a payment from who releases it is the oldest of those controls, and the COSO Internal Control framework, first issued in 1992 and refreshed in 2013, is where most auditors will look for it ([COSO](https://www.coso.org/internal-control)).

For the FX side specifically, the FX Global Code is the industry's set of good-practice principles, last updated in December 2024 and developed by central banks and market participants from 20 jurisdictions ([Global Foreign Exchange Committee](https://www.globalfxc.org/fx_global_code.htm)). It's written for wholesale FX, but its habits (know what you're being quoted, document how you execute) translate directly.

## What should the policy contain?

Ten sections. The template below is meant to be pasted into your wiki and edited. Brackets are yours to fill.

**1. Purpose and scope.** This policy governs every stablecoin-funded payout and on-ramp made by [Company] through [provider], in all corridors listed in section 3. It applies to employees and contractors with access to the payout dashboard or API keys.

**2. Roles.** Map each duty to a person and a role on the instance. BlindPay's [instance docs](/docs/learn/instances) list seven member roles:

| Role | Suggested duty in this policy |
| --- | --- |
| `owner` | Policy owner. Approves changes to sections 4 to 7 |
| `admin` | Manages members and API keys |
| `finance` | Prepares payout runs and funding transfers |
| `checker` | Second approver on runs above the threshold in section 5 |
| `operations` | Executes approved runs, handles exceptions |
| `developer` | Builds and maintains the integration, no money movement |
| `viewer` | Read-only for audit and support |

The docs list `owner`, `admin`, `finance`, `checker`, and `operations` as holding the transaction-create permission for transfer quotes, and member role changes need `owner`, `admin`, or `checker`. Instances also expose a `require_passkey` setting. The maker-checker step itself is your process: the person who prepares a run is never the one who signs it off.

**3. Approved corridors, rails, and providers.** List each corridor (for example USDC to BRL over Pix, USDC to MXN over SPEI, USDC to EUR over SEPA), the provider, and the date it was approved. New corridors need a liquidity check first; the [10-point liquidity scorecard](/resources/more/onramp-offramp-liquidity-scorecard) is a usable bar.

**4. Quote acceptance.** We execute only against binding quotes, inside their window, read from `expires_at`. We never execute a quote created more than [5] minutes earlier or retry an expired one; we re-quote. Staff check that the quote shows both the market rate and the rate after fees ([how to read an FX quote](/resources/more/how-to-read-an-fx-quote)).

**5. Approval thresholds and tolerances.** Runs are approved on an estimate with a tolerance, then quoted live:

| Run size (USD equivalent) | Approvers | Re-quote tolerance before re-approval |
| --- | --- | --- |
| Under [$10,000] | 1 (`finance`) | [100] bps |
| [$10,000] to [$250,000] | 2 (`finance` + `checker`) | [50] bps |
| Over [$250,000] | 2 + `owner` notified | [25] bps |

**6. Float limits.** We hold between [3] and [10] business days of payouts in stablecoins, across no more than [2] networks. Top-ups are made by `finance` and logged. [How much USDC to hold for payouts](/resources/more/how-much-stablecoin-float-for-payouts) has the sizing formula.

**7. Token and depeg limits.** Approved tokens: [USDC, USDT]. If an approved token trades below [$0.995] on [named reference source] for more than [1 hour], payouts in that token pause and `owner` decides next steps. [Stablecoin depeg risk](/resources/more/stablecoin-depeg-risk-payments) covers how to set the trigger.

**8. Exceptions and failed payouts.** Expired quotes are re-quoted, never forced. Failed or refunded payouts go to `operations` within [1 business day]. When stablecoins were already collected and the payout can't be delivered, 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 that refund is automatic, while USD payouts and payouts whose review times out are refunded after an operator review.

**9. Monitoring.** Weekly report on expiry rate, re-quote delta, delivery success, and cost per delivered dollar by corridor ([payout quality metrics](/resources/more/payout-quality-metrics-slippage-expiry-rate)).

**10. Review.** Numbers reviewed monthly by `finance` and `checker`. Whole policy reviewed every [12] months by `owner`, and whenever a corridor, token, or network is added.

## How do you set a re-quote tolerance?

Measure it, in basis points, between the approved estimate and the live quote. One basis point is 0.01%.

Illustrative example. Finance approves a run of R$ 400,000.00 in salaries, fixed in reais, on an estimate of 5.4000 BRL per USDC. When the run starts, the live quote shows 5.3820.

| Line | Value |
| --- | --- |
| Approved estimate | 5.4000 BRL per USDC → 400,000 / 5.4000 = 74,074.07 USDC |
| Live quote | 5.3820 BRL per USDC → 400,000 / 5.3820 = 74,321.81 USDC |
| Rate move | (5.4000 - 5.3820) / 5.4000 = 0.333% = 33 bps |
| Extra USDC | 74,321.81 - 74,074.07 = 247.74 USDC |
| Policy tier | $10,000 to $250,000, tolerance 50 bps |
| Decision | Within tolerance. The run proceeds without re-approval |

At 5.3460 the move would be (5.4000 - 5.3460) / 5.4000 = 100 bps, about 74,822.30 USDC needed. Outside tolerance: the run pauses and goes back to the checker.

Pick the band from your own data. If a corridor's typical re-quote delta is 20 bps, a 50 bps tolerance rarely bothers anyone and still catches a real move. [Should you wait for a better exchange rate?](/resources/more/should-you-wait-for-a-better-exchange-rate) explains why the policy should not let operators hold runs to time the market.

## How does the policy fit with forecasting and hedging?

The policy governs execution; the forecast governs budget. Your monthly FX budget sets the expected cost per corridor, and the policy's tolerances say how much the actual run may deviate before someone looks. [Forecasting FX costs on cross-border payouts](/resources/more/forecast-fx-costs-cross-border-payouts) shows the budget model.

Live quotes are not a hedge. If a large payable is due in 90 days, a forward from your bank fixes the economic rate, and the payout still runs on a live quote on the day. [Live quote vs forward contract vs fixed rate](/resources/more/live-quote-vs-forward-contract-vs-fixed-rate) covers that split. If you use forwards, add a section 11 naming the bank and the hedge ratio.

## What do auditors ask to see?

Evidence that the policy runs, not just that it exists. Expect requests for:

- The member list with roles, and the date each changed.
- Two or three payout runs with the prepared total, the approval, the live quotes, and the executed payouts.
- Every exception in a period: expired quotes, failed payouts, refunds, and how each closed.
- Monthly review notes showing a tolerance or float limit was actually revisited.

Store quote ids with each executed payout. A quote is the record of the price you accepted, and it's the first thing anyone asks for when a rate gets questioned months later.

## What to do next

Paste the ten sections into your wiki, fill sections 2, 5, and 6 this week, and assign roles on your instance to match. The [instance docs](/docs/learn/instances) show how to list and update member roles.