Choosing a stablecoin infrastructure provider is a counterparty decision wearing the costume of a product decision. The demo shows you an API and a dashboard, and both will look fine, because building a dashboard is the easy part. What you are actually deciding is whose balance sheet your customers' money sits on, whose authorization lets it move, and whose compliance team can freeze it on a Tuesday afternoon.
The evaluation below is ordered by how expensive the mistake is. Custody and licensing come first because they are the ones you cannot fix later without a migration. What the software itself should expose is a separate question, covered in what a stablecoin API is.
Start with who holds the money and under what authorization
Every other question is downstream of this one. Ask where a customer balance legally sits, in whose name, and which entity in the provider's group holds the relationship with the bank or the blockchain address. The answer is rarely one company. A provider operating across Brazil, Mexico and the United States is almost certainly a group of entities with different authorizations, and the one that signs your contract may not be the one that holds the funds.
That is not a red flag by itself. It becomes one when nobody can draw it for you. A provider that has thought about this has a diagram and hands it over; a provider that has not will answer with the word "partner" repeated in different sentences. Custody is a control question rather than a storage question, and what a custodial wallet is sets out the four sub-questions worth forcing an answer on: whose name the assets are in, whether they are segregated from operating funds, who can sign a movement, and what happens to the balance if the provider stops operating.
What you can verify yourself before any call
A surprising amount of what a provider tells you is checkable in about twenty minutes, without a meeting and without their help.
In the United States, a money services business has to register with the Treasury. The obligation, the deadline and the renewal cycle are published by FinCEN: registration is filed within 180 days of the business being established, uses Form 107, and must be renewed every two years. The registrant list is public and searchable, so "we are FinCEN-registered" is a claim with a lookup attached. Two things to check that people forget: the legal entity name on the registration should match the entity on your contract, and the registration should be current. Registration lapses quietly.
In Brazil, the Central Bank publishes the institutions authorized to operate in the foreign exchange market, and any conversion between reais and a foreign currency has to run through one of them under Law 14.286 of December 29, 2021. If your flow touches BRL at any point, the question is which authorized institution executes that leg, by name. The provider may not be it, which is fine; being unable to name it is not.
For the crypto side of the activity, Brazil's framework is Law 14.478 of December 21, 2022, and a MSB (money services business, the FinCEN registration category) in the United States is a different thing from a VASP (virtual asset service provider, the FATF term) in Brazil. A provider holding one does not hold the other.
Coverage claims mean nothing until you read them as rails
Every provider's site lists countries. The list is close to useless on its own, because "we support Mexico" can mean a local account that receives SPEI (Mexico's interbank transfer system, run by Banxico) in your customer's own name, or it can mean a wire to a partner who does the last mile in a way nobody will describe.
Read coverage as three columns instead: which currency, over which rail, into an account in whose name. Then ask for cut-off times per rail and what happens on a local holiday. Pix (Brazil's instant payment system, run by the Central Bank) runs continuously and has no cut-off, which makes it the easy case and a bad one to generalize from. ACH and SEPA settle in business days and queue behind holiday calendars that belong to the rail rather than to the provider. A provider that publishes its cut-offs has thought about your operations; a provider that answers "it depends" has told you the answer is worse than you would like.
What to get in writing before the pilot
Four things, and none of them are unusual to ask for.
The first is limits: per transaction, per day, per month, and how a raise is requested. Limits exist at every provider and the difference is whether they are visible in the API or discovered when a payout fails. The second is the escalation path for a held transaction, with a name or a channel and an expected response time, because a compliance hold on a customer payout is an operational incident on your side regardless of whose rule triggered it. The third is what happens to balances and to customer data on termination, written as a sequence rather than as a sentiment. The fourth is whether your business model is permitted at all, which matters more than it sounds.
That last one deserves a paragraph of its own. Platforms and marketplaces routinely plan to hold one pooled balance and track their users in an internal ledger. Many providers prohibit exactly that, because funds belonging to a party the provider has never onboarded look like a nested payment arrangement to the provider's own bank. If your architecture assumes pooling, get written approval before you build it, not after your first compliance review.
The parts that only show up after you sign
Sales conversations are about capability and the first year is about exceptions. What separates providers in practice is how they behave when something is wrong: whether a rejection carries a reason you can forward to your customer, whether an RFI (request for information, a compliance hold that asks for a document before a transaction clears) tells you which document and why, whether a status change reaches your system as an event or as an email to somebody who is on holiday.
I am on the other side of this table, answering these questionnaires rather than sending them, and the question that separates a serious buyer from a distracted one is almost never about pricing. It is some version of what happens to our customers' money if you stop existing. I notice that it is asked out loud in meetings and almost never written into the document, which means the answer never gets recorded anywhere either side can point at later. My own habit now is to answer it in writing whether or not it was asked that way, because a buyer who did not think to ask it is exactly the buyer who will need the answer.
How to run an evaluation that tells you something
Two weeks and a sandbox will tell you more than two months of calls. Pick the single flow that carries the most volume in your product, build it end to end against the sandbox, and then spend most of the time forcing failures: a rejected customer, a payout to a bad account number, a document that gets declined, a webhook your endpoint returns a 500 for. A provider's happy path is a marketing artifact. Its failure path is the product.
While you are in there, read the changelog. A public, dated changelog tells you the release cadence, whether breaking changes get notice, and whether the company writes things down. Its absence tells you something too.
When you should not be choosing a provider yet
If you cannot name the flow, the currencies and the counterparties, an evaluation will produce a preference rather than a decision. Providers are not interchangeable across use cases: the best choice for paying out to thousands of contractors is not automatically the best choice for holding a corporate dollar balance, and a provider that is strong in one corridor can be renting capacity in another.
Two other cases argue for waiting. If your volume is small and irregular, the integration cost may exceed what you save for another year, and the honest answer is to revisit later. And if the real problem is that your bank is slow rather than that your payments are cross-border, stablecoins are an expensive way to solve a banking relationship. We have talked people out of both, and the pattern of who actually benefits is in how B2B fintechs approach stablecoins.
Running this checklist 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, 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.
Applied to the questions above: custody is with the provider, which is a deliberate position rather than an omission, and the tradeoff it carries is set out in the custody explainer linked earlier. We are a registered money services business, and the point of the section above is that you should not take that from this page: the entity name on the contract is the one to put into the registrant search, and the same goes for every provider you are comparing us against. Currencies, rails and settlement times are published per country on the coverage page rather than described as a list of flags, and the per-rail cut-off times sit alongside them. Transaction limits are readable through the API per customer, with the used and remaining amounts, so a payout that would breach one is knowable before it is attempted rather than after.
The part worth stating plainly is the pooling rule, because it is the one that most often changes an architecture. Every payout debits the wallet of the customer it belongs to, into a destination registered under that same customer, or transfers to another onboarded customer. Holding funds for a party we have not onboarded is not permitted, and where a platform model genuinely needs a variation on that, it needs written approval first. That rule costs some flexibility, and it is the reason a platform's sellers each get their own balance and their own verification rather than a row in somebody's spreadsheet. What that looks like in an integration is described in global payments.
Verified on September 24, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Jakub Żerdzicki on Unsplash.
What is the single most important question to ask a stablecoin provider?
Where the money legally sits and in whose name. Everything else, including pricing and coverage, can be renegotiated or worked around, but custody arrangements are structural and changing them means migrating. Ask for the answer in writing, naming the entity that holds the funds.
How do I verify that a provider is actually licensed?
Use the public registers rather than the provider's website. In the United States, FinCEN publishes a searchable list of registered money services businesses, and registration must be renewed every two years, so check that it is current and that the entity name matches your contract. In Brazil, the Central Bank publishes the institutions authorized to operate in the foreign exchange market.
Is a provider that holds its own licences better than one that uses partners?
Not automatically. A provider with partner banks in six countries may serve you better than one with a single licence in one country, as long as it can name each partner and describe what happens if one of those relationships ends. The failure mode to avoid is a provider that cannot or will not draw the structure.
How long should an evaluation take?
Two to four weeks, most of it spent in a sandbox forcing failures rather than in meetings. Build your highest-volume flow end to end, then test a rejected customer, a failed payout and a document decline. If a provider cannot support that in a sandbox, that is itself a finding.
