---
title: "What to ask a stablecoin payments provider: 30 due diligence questions"
seoTitle: "30 questions to ask a stablecoin payments provider"
description: "The questions to ask a stablecoin payments vendor before you sign: licensing, custody, pricing, rails, compliance, failure handling, security, and exit."
date: "2026-09-19"
updated: "2026-09-19"
category: "payments"
author: "BlindPay Team"
faq:
  - q: "What should I ask a stablecoin payments provider before signing?"
    a: "Ask whose licenses the flow runs under, who holds the funds at each step, whether you must pre-fund, what every fee is, which rails are live in production, how long holds can last, what happens when a payout fails, and how you get your data and funds out if you leave. Ask for documents, not just answers."
  - q: "What documents should a stablecoin payments vendor provide during due diligence?"
    a: "At minimum: a list of licenses and registrations with numbers, a SOC 2 Type 2 report or equivalent, a recent penetration test summary, an AML and sanctions policy statement, a flow-of-funds diagram, a sample itemized quote, and the contract terms for termination and data export."
  - q: "How do I know if a stablecoin provider is custodial?"
    a: "Ask who controls the funds between the moment they leave your wallet or bank account and the moment the recipient is paid, product by product. A provider can be non-custodial for one flow and custodial for another, such as a hosted wallet. Get the answer in the flow-of-funds diagram, not in a sales deck."
  - q: "What is a red flag when evaluating a stablecoin payments provider?"
    a: "Vague answers about licensing, a rate quoted without an itemized fee breakdown, forced pre-funding with no clear reason, no public API documentation, and no written answer about what happens to funds if the provider fails. Any one of these deserves a follow-up call. Two usually end the evaluation."
  - q: "How long should stablecoin provider due diligence take?"
    a: "For most fintechs, two to six weeks: a week for the questionnaire and documents, one to two weeks of sandbox testing, and a short production pilot on one corridor. Regulated institutions often take longer because vendor risk committees review the answers."
---

To run due diligence on a stablecoin payments provider, map your money flow first, then send the provider a written questionnaire covering licensing, custody, pricing, rails, compliance operations, failure handling, security, and exit terms. Ask for documents that back each answer, test the failure cases in a sandbox, and pilot one corridor in production before you commit volume.

The 30 questions below are the ones that separate providers in practice. Each comes with what a good answer sounds like. Copy them into your vendor questionnaire.

## What should you ask about licensing and regulation?

1. **Which licenses and registrations does my flow run under, yours or a partner's?** A good answer names each registration with its number, points to a public license page, and says plainly where a partner's license is used instead.
2. **What happens to my flow if a banking or licensing partner drops you?** A provider that sits behind a single partner can be switched off with no notice. A good answer names a backup for each critical rail and a notice commitment in the contract.
3. **Which countries can my customers onboard from, and which are prohibited?** A good answer is a published list, not "it depends."
4. **Who does KYC, KYB, sanctions screening, and the travel rule: you, me, or both?** A good answer is a written split of responsibilities. [What is a VASP](/resources/more/what-is-a-vasp) explains which obligations follow the license.
5. **Which regulatory changes will affect my flow in the next 12 months?** A good answer is specific and dated. See the [stablecoin regulation tracker](/resources/more/stablecoin-regulation-tracker-2026) for the regimes to ask about.

## What should you ask about custody and the flow of funds?

6. **Who holds the funds at each step, and for how long?** A good answer is a flow-of-funds diagram with a named holder at every step.
7. **Which of your products are custodial and which are non-custodial?** Honest providers split it by product. A hosted wallet is usually custodial even when the payout flow isn't. [Non-custodial payments explained](/resources/more/non-custodial-payments-explained) covers the difference.
8. **How are customer funds kept separate from your own?** Look for account-level segregation and a clear answer on where fiat sits in transit.
9. **What happens to funds in flight if you become insolvent?** A good answer explains the legal structure, not just "we're well capitalized."
10. **When a payout can't settle, where does the money go, how fast, and who pays the fees?** A good answer is status-level: which states return funds automatically and which need a ticket.

## What should you ask about pricing, liquidity, and pre-funding?

11. **Do I have to pre-fund, and how much?** If yes, ask why and what the capital buys you. [What "no pre-funding" means](/resources/more/no-pre-funding-stablecoin-payouts) shows the alternative.
12. **How is the rate set, and how long does a quote hold?** Live quotes with a short, explicit expiry beat a daily rate sheet.
13. **What are all the fees: spread, percentage, fixed, network, bank transfer, refund?** A good answer is an itemized quote. [Stablecoin API pricing explained](/resources/more/stablecoin-api-pricing-explained) lists the layers to look for.
14. **What are the per-transaction, daily, and monthly limits, and how do increases work?** Ask for the numbers by verification tier and the documents an increase needs.
15. **How deep is liquidity in my corridors on a Friday night?** Ask for the largest single payout they've settled in your top corridor outside business hours.

## What should you ask about rails, coverage, and settlement?

16. **Which rails are live in production today, per country?** Roadmap rails don't count. Ask for a test payout on each one you need.
17. **What are the cut-offs and real settlement times per rail, including weekends?** [Why cross-border payments are slow](/resources/more/why-are-cross-border-payments-slow) explains which delays a provider can remove and which it can't.
18. **Which networks and tokens do you support for payins and payouts?** Not every token is on every chain. Get the exact pairs.
19. **How do international wires work?** Ask whether SWIFT payments and collections run on behalf of your customers (POBO/COBO), whose name the beneficiary sees, and whether you get UETR tracking and MT103 confirmations.

## What should you ask about compliance operations?

20. **How long do KYC and KYB take, and which parts are automated?** A good answer gives times per tier, not a range from "instant" to "weeks."
21. **What triggers a hold, how long can one last, and how am I told?** Look for a status and a webhook, plus a maximum hold time.
22. **How do you monitor transactions in real time?** [Real-time transaction monitoring](/resources/more/real-time-transaction-monitoring-stablecoin-payments) covers what good looks like.
23. **How do requests for information work, and can I answer them by API?** Manual email chains don't scale past a few hundred customers.
24. **Where is the line on nested payments?** Paying on behalf of your onboarded customers is one thing. Moving money for their customers, whom the provider has never seen, is another. A good answer draws that line clearly.

## What should you ask about integration and operations?

25. **Does the sandbox behave like production, including failures?** Ask how to force a failed payout and a refund. [Sandbox vs production](/resources/more/stablecoin-api-sandbox-vs-production) lists what sandboxes usually miss.
26. **How do webhooks handle signatures, retries, and duplicate events?** See [stablecoin API webhooks](/resources/more/stablecoin-api-webhooks-reconciliation) for the checks your code will need.
27. **What's your uptime history, incident process, and support response time?** Ask for the last three incidents and how customers were told.

## What should you ask about security, data, and exit?

28. **Which security attestations do you hold, and can I see the report?** A SOC 2 Type 2 report shows controls tested over months. A Type 1 only checks the design at a single point in time.
29. **Where is my customers' data stored, and under which privacy regimes?** Ask about GDPR, and LGPD if you serve Brazil.
30. **If we leave, how do we get our data and funds out, and how long does it take?** A good answer is a clause in the contract, with a time limit.

## Which documents should you request?

Answers are cheap. Documents are harder to fake.

| Document | What it tells you |
| --- | --- |
| License and registration list | Who can legally move your money, and where |
| SOC 2 Type 2 report | Whether security controls worked over a period, not just on paper |
| Penetration test summary | Whether an outside team tried to break in, and what they found |
| AML and sanctions policy statement | How screening and escalation actually work |
| Flow-of-funds diagram | Who holds the money at every step |
| Sample itemized quote | Every fee, before you sign |
| Incident history | How the provider behaves on a bad day |
| Contract: termination, notice, data export | What happens when the relationship ends |

## What are the red flags?

- Licensing answers that stay vague after a follow-up.
- A single "all-in rate" with no itemized fees.
- Pre-funding required with no explanation of what it covers.
- No public API documentation, or docs that don't match the sandbox.
- No written answer about funds in flight if the provider fails.
- A sandbox that can't simulate a failure.

One red flag is a follow-up call. Two is usually the end of the evaluation.

## How should you score the answers?

Weight the categories by what your flow needs, score each answer from 1 to 5, and multiply.

| Category | Suggested weight | Questions |
| --- | --- | --- |
| Licensing and regulation | 20% | 1 to 5 |
| Custody and flow of funds | 15% | 6 to 10 |
| Pricing, liquidity, and pre-funding | 15% | 11 to 15 |
| Rails, coverage, and settlement | 15% | 16 to 19 |
| Compliance operations | 15% | 20 to 24 |
| Integration and operations | 10% | 25 to 27 |
| Security, data, and exit | 10% | 28 to 30 |

A payroll platform might move weight from integration to rails and settlement. A regulated bank will likely push licensing and security higher. The weights matter less than using the same sheet for every vendor. For a shorter pass, [how to choose a stablecoin API](/resources/more/how-to-choose-a-stablecoin-api) narrows it to six questions, and [how to choose an on/off ramp provider](/resources/more/how-to-choose-on-off-ramp-provider) adds a test for each criterion.

## How does BlindPay answer these questions?

Short answers to the questions buyers ask most:

- **Licensing (1).** BlindPay is registered with FinCEN as a Money Services Business (NMLS #2745309) and publishes the status of its US and non-US licenses on its [licenses page](/licenses).
- **Custody (6, 7).** Payouts from an external wallet are non-custodial: the stablecoins move only when the quoted payout executes, and a refunded payout returns them to the wallet that funded it. Managed wallets, in beta, are custodied by BlindPay.
- **Pre-funding and quotes (11, 12).** No pre-funding. Quotes lock the rate and fees for 5 minutes by default.
- **Limits (14).** Per-transaction limits start at $10,000 for KYC Standard, $30,000 for KYB Standard, and $50,000 for KYC Enhanced, with increases on documentation, as listed in the [KYC reference](/docs/kb/kyc).
- **Rails (16, 19).** ACH, wire, RTP, SWIFT (POBO/COBO) with UETR tracking and MT103 confirmations, Pix, PIX Safe, TED, SPEI, ACH Colombia, Transfers 3.0 in Argentina, and SEPA.
- **Compliance (20, 21, 24).** KYC Standard takes about 60 seconds, KYB 3 hours to 1 business day. Holds can last up to 30 days and show up as a status with a webhook. Nested payments aren't supported, as explained in [nested payments](/docs/kb/nested-payments).
- **Failure handling (10).** A refunded payout returns stablecoins right away. A failed payout doesn't refund automatically and goes to support. [Payout statuses explained](/resources/more/stablecoin-payout-statuses-explained) covers each state.
- **Sandbox (25).** Development instances force `failed` and `refunded` outcomes with sentinel amounts, so you can test failure paths before go-live.
- **Security (28, 29).** SOC 2 Type 2, GDPR and DORA compliant, independently pentested, with a public vulnerability disclosure program, as described on the [security page](/security).

## What should you do next?

Send this questionnaire to every provider on your shortlist in the same week, with the same deadline, and score the answers on one sheet. Then take the top two into a sandbox and force a failed payout on each. How a provider handles failure tells you more than any demo. For the basics of how the flows work, start with [stablecoin payments explained](/resources/more/stablecoin-payments-guide).