The main red flags in a stablecoin payments provider are answers that stay vague about money, licenses, price or failure: no named entity holding your funds, no binding quote before signature, a sandbox that cannot fail, one speed claim for every rail, and no reference for each payment.
A product gap gets a specific answer; a red flag gets a general one. The framework is in choosing a stablecoin infrastructure provider.
What separates a red flag from a product gap
A gap is a missing feature with a date and a spec. A red flag is an answer that stays vague after you ask twice. It clusters around five subjects: who holds the money, what it costs, what happens when a payment fails, how long things take, and what happens when the provider has a bad day or you want out.
Send each question below in writing to every provider on your shortlist and keep the answers in their own words. Specific answers name an entity, a number, an API field or a page you can open; general ones say "fully supported".
What are the fourteen red flags, and which question exposes each?
The table runs in order of damage: who is responsible when something breaks (1 to 3), what you pay (4, 5), whether you can see a payment (6 to 10), and whether you can trust the vendor (11 to 14).
Fourteen red flags, the question to send, and what a specific answer contains.
# | Red flag | Question to ask any provider | A specific answer contains |
1 | Licensing without names | Which legal entity contracts with us, and which registrations cover our flow? | An entity name and registration identifiers you can look up yourself |
2 | No answer on who holds funds in transit | If you became insolvent today, whose property would the balance be? | A named holder, the contract clause, and the segregation model |
3 | Pooled money for payers you never onboarded | Can one account hold funds that belong to my customers' customers? | A written rule on pooling and on who must be onboarded |
4 | Price after signature | Can I create a quote with every fee line and an expiry in the sandbox today? | A response with rate, fee lines, final amount and expiry time |
5 | A pre-funding requirement with no formula | How much do you require us to hold, how does it scale, and where is it held? | A formula, a holder and a release condition |
6 | A sandbox that cannot fail | How do I force a rejected, expired or held payment? | A list of triggers and the status each one produces |
7 | One speed claim for every rail | What is the settlement time and the daily cut-off for each rail? | A per-rail table with cut-off times and holiday behavior |
8 | "We handle it" with no split | Which checks do you run, which stay with us, and how does an information request reach my customer? | A written split and the name of the hold status |
9 | Countries on a slide | When did your last production payout on this rail settle? | A rail name, a settlement time and a recent date |
10 | No trail per payment | What identifier, status history and signed event do I get for every payment? | A sample payout object and a sample signed webhook payload |
11 | No independent security attestation | Which security reports exist (SOC 2, penetration test), and which key controls does the API give me? | A report name and date, plus key rotation and IP allowlisting in the docs |
12 | No exit or export path | If we leave, how do we get our transaction history and balances out, and what does the contract say? | An export route, a withdrawal path and a contract clause |
13 | No escalation path or incident channel | Where do we report a failed payment, who answers, and how do we hear about an outage? | A support address, a reference to quote, a status channel and a written uptime figure |
14 | Silence on issuer and redemption risk | Who issues each stablecoin you support, and what happens to my payouts if one loses its peg? | An issuer per token, a redemption route and a written depeg procedure |
Money and licenses: the flags you cannot fix later
Ask for the contracting entity and every registration that covers your flow, then check each yourself. In the United States, a money services business registers with FinCEN, as FinCEN's MSB registration page explains, so ask for the registration details. That is not a state money transmitter license, so it answers only part of the question. In Brazil, virtual asset providers need Central Bank of Brazil (BCB) authorization under Resolution BCB 520 of 2025, with a transition regime in Article 88, so a provider can legitimately be mid-process.
On custody, ask whose property the balance is on the day the provider fails. The best public benchmark is the New York Department of Financial Services Industry Letter of September 30, 2025, which says equitable and beneficial interest should always remain with the customer. A provider that cannot show you the clause, the holder and the segregation model has answered. See what a custodial wallet is.
Flag 3 most often changes an architecture: a platform that holds one balance and tracks its users in a ledger asks the provider to move money for parties it has never seen, and some prohibit that. Get the rule in writing; the two models are compared in named virtual accounts versus pooled accounts.
On custody, Lumx wallets are held in custody by BitGo, which carries insurance. Every customer gets its own wallets on each supported blockchain, usable once approved, and the custodial wallets page describes them as segregated per customer. There is no omnibus account: balances are not mixed with each other or with Lumx's own. A balance is a stablecoin, not a deposit, because Lumx is not a bank. Two entities contract with customers: Lumx Sociedade Prestadora de Serviços de Ativos Virtuais Ltda (Lumx SPSAV Ltda), in Brazil, which has filed its application for the BCB authorization and operates under the Article 88 transition regime of Resolution BCB 520 of 2025, and Lumx US OP LLC, in Wyoming, a FinCEN-registered MSB. EUR and GBP payments run through a banking partner. On pooling, the nested payments docs tie every transaction to an onboarded customer, so a marketplace onboards each seller. A named virtual account takes the deposit already attributed to its customer; see the product page.
Price and pre-funding flags show up in the first afternoon
Flags 4 and 5 need no sales call. Open the sandbox and ask for a quote. A real quote returns the rate, every fee line, the amount the recipient receives and the expiry time. An "indicative" number cannot be modeled; how payout pricing works takes the fee lines apart. Pre-funding is the other place price hides: a deposit that grows with your volume, with no formula or named holder, is an unsecured loan to the provider.
On price, the Lumx exchange rate endpoint returns a floating quote or a locked one, and a locked quote carries an identifier, an expiry time in UTC, the base rate, a fee breakdown (Lumx fee, partner fee and total) and the final amount. The Lumx pricing model is "monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans". Lumx requires no deposit held against volume: no pre-funding means no capital parked in settlement accounts before a transaction, because conversion and settlement happen when the transaction starts. The standard agreement has a monthly minimum and no setup fee.
Sandbox, speed and trail: the operational flags
Speed claims come next. Pix (Brazil's instant payment system) and SPEI (Mexico's interbank system) run around the clock, ACH takes business days, and an international wire passes through intermediary banks that add days and fees. A provider with one number for every country has not measured them. Ask for a table with cut-offs and holiday behavior, like payout limits and cut-offs by rail.
Then the trail: an identifier you can quote to a bank, a status history, and a signed event. Ask for a sample payout object and webhook payload before the contract.
In the Lumx sandbox, test stablecoins and mock banking partners let you drive KYC (know your customer) and KYB (know your business) outcomes with test values in the tax ID field. The webhook catalog has a status per stage, including failed and expired. The cut-off page gives each rail its cut-off and settlement target. For the trail, settlement tracking is "UETR and MT103 confirmations on every SWIFT payout, per-rail reference on every transfer, webhooks". Webhooks are signed with HMAC-SHA256, and write requests accept an Idempotency-Key header, per the idempotency page.
Screening and coverage claims that sound complete and are not
Flag 8 is the answer "we handle it." No provider owns all of your screening, and the sentence hides what happens when a payment is held. Ask for a written split of which checks the provider runs, which stay with you, and how a request for information reaches your customer. An RFI (request for information, a compliance hold that asks for a document before a transaction clears) shows the provider has a process. See what KYB is.
Flag 9 is the country list. A country on a map is not a live rail, so ask when the last production payout on that rail settled. The Operator Map shows who operates where.
On screening, Lumx runs KYB on the customer, verifies each payout destination, uses Sumsub for KYC, and screens every transaction before it executes. Chainalysis KYT monitors blockchain activity for every type of wallet, including transfers received from external addresses, while fiat uses Lumx's own systems and banking-partner oversight. A flagged transaction is held as an RFI until the document arrives; KYB review targets one business day; the default transaction limits are published per verification level and are subject to revision. On coverage, the Coverage page lists each rail with its settlement time, and the supported countries page lists where customers are onboarded.
Vendor flags that surface in review
These four come up in a review, not a demo. For flag 11, a named report with a date is a specific answer. For flag 12, ask how history and balances leave and what the contract says about notice. Flag 13 is the provider's own failures: where a failed payment is reported, how you hear about an outage, and the contract's uptime figure. Flag 14 is the stablecoin itself: a USDC or USDT payout depends on an issuer that holds reserves and redeems on request, so ask what happens to in-flight payouts if a token loses its peg. See what USDC is and what USDT is.
On security, Lumx shows API keys once, lets you revoke and rotate them from the Dashboard, and supports an IP allowlist for production keys, announced in August 2026 with enforcement starting September 21, 2026. Lumx is compliant with SOC 2 and ISO 27001 but not yet certified, runs penetration tests, and publishes a service level agreement. Ask for anything beyond that in writing at operations@lumx.io. On exit, every transaction can be read through the API, the OpenAPI specification is downloadable, and a transfer sends stablecoin to an external wallet. The standard contract covers the sequence for returning funds on exit, an export of history and addresses, and a liability cap. On incidents, every error response carries a request ID and a code, and operations@lumx.io takes that ID. On issuers, Lumx works with USDC and USDT. Circle, the USDC issuer, is compliant with the GENIUS Act, and Lumx holds its own mint account at Circle in addition to buying USDC through BTG.
How I would run this list
I recommend sending the fourteen questions as a document, never asking them live on a call. A written answer can be forwarded to your risk lead and reread later. If a provider will not put an answer to flags 1, 2 or 8 in writing, I would treat that refusal as the answer and stop there, whatever the demo looked like. A vague answer from a salesperson is not yet one from the company, so I would ask again in writing and escalate to whoever owns the product. For a small pilot I would run only flags 1, 2, 4 and 6, which cost an afternoon.
When a stablecoin payments provider is the wrong tool
It is the wrong tool when your flows are domestic and a local bank already settles them in minutes.
Running the fourteen questions against Lumx
Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.
Most answers above link to a public docs page that can be read before anyone books a meeting. The contracting entities and custodian are named above. Any report beyond the service level agreement and a recent production payout are asked for in writing, like with any provider.
Methodology and sources
Read on November 1, 2026: the Lumx docs pages linked above; FinCEN's MSB registration page; and the New York Department of Financial Services Industry Letter of September 30, 2025, cited by name and date without a link because dfs.ny.gov blocks automated checks. Resolution BCB 520 of 2025 links to the BCB's official normative page, which serves its text through a script, so no claim here rests on its wording.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Irina Blok on Unsplash.
What are the red flags when choosing a stablecoin payments provider?
The main ones are no named contracting entity, no clear answer on who owns funds in transit, a price you only see after signing, a sandbox that cannot produce a failure, one speed claim for every rail, no identifier on each payment, and no answer on security, exit or issuer risk. Lumx publishes a sandbox, locked quotes with an expiry, and signed webhooks.
How do I check a provider's licensing claims?
Ask for the contracting entity and its registrations, then look them up yourself. In the United States, a money services business registers with FinCEN, which is separate from state licenses. In Brazil, check for Central Bank authorization or the transition regime under Resolution BCB 520 of 2025. Lumx SPSAV has filed its Brazilian application and operates under that transition regime, and Lumx US OP LLC is a FinCEN-registered MSB.
Is a sandbox that only returns success a red flag?
Yes, because the payments that cost you money fail, time out or get held. Ask how to trigger each outcome. The Lumx sandbox uses test stablecoins and mock banking partners with the same API surface as production, and KYC and KYB outcomes can be driven with test values in the tax ID field.
Should a provider quote one settlement time for every rail?
No. Pix and SPEI run around the clock, while ACH and wires follow business days and cut-offs. Lumx publishes a per-rail table: Pix and SPEI have no cut-off, ACH has a 2:00 PM ET cut-off, and FEDWIRE and USD SWIFT have a 3:00 PM ET cut-off, with FEDWIRE settling the same business day and SWIFT in 1 to 5 business days, as targets.
What security, uptime and exit answers should I ask a provider for?
Ask for any security report by name and date, the API key controls, a support address, the contract uptime figure and a written exit route. At Lumx, API keys can be rotated and IP-allowlisted, every error carries a request ID and code, support is at operations@lumx.io, and every transaction can be read through the API.
