Build vs Buy Stablecoin Payments: In-House or API?

Build vs buy stablecoin payments is the choice between running your own wallets and liquidity, bank connections, a licence and a compliance program, or renting them through a provider's API. Most companies whose product is not the payment rail itself should buy, because licensing and banking partners, not code, set the timeline and the cost of an in-house build.

What do you have to build to run stablecoin payments yourself?

Moving a stablecoin between two wallets is the easy part. A payout to a supplier in São Paulo or Mexico City adds nine more components, each a vendor contract, a hire or both. The table sets what building each means against what Lumx's API does at that point.

What an in-house build owns, and what Lumx's API covers for the same row (docs.lumx.io, read November 1, 2026).

The buy side of the table is what a stablecoin API packages. Hiring engineers cannot shorten the licensing row, and the banking row depends on counterparties with their own schedules. The integration side is covered in how to integrate a stablecoin API, and the reconciliation row has its own accounting guide in how to reconcile stablecoin transactions.

Staffing and timeline for an in-house build

Every figure in this section is an illustrative assumption for a team starting from zero on two or three corridors outside Brazil, or on a licensed-partner route. None of it is a Lumx statistic, and none comes from a client. The in-house Brazil path is longer, as the next section shows. Replace each number with your own before any business case.

Illustrative assumptions for an in-house build, two to three corridors outside Brazil, starting from zero.

Read the table as a range, not a plan: 7 to 9 people and 12 to 18 months before the first live corridor outside Brazil, with the licensing and bank rows on the critical path. At an assumed fully loaded cost of $150,000 per person-year, that team costs $1.05 million to $1.35 million for one year, before licence fees, outside counsel, vendor minimums and the capital a bank asks you to hold. A second corridor repeats the bank and legal work, so cost grows with each country, not each dollar moved.

Licensing and banking: what in-house means in Brazil and the United States

In Brazil, the Central Bank of Brazil (BCB) set the regime for virtual asset service providers in 2025. Resolution BCB 519 of 2025 covers authorization, Resolution BCB 520 of 2025 covers how a provider must operate and holds the transition rule in Article 88, and Resolution BCB 521 of 2025 links virtual asset payments to the foreign exchange framework. A company that wants to run stablecoin payouts under its own name needs to become, or partner with, a PSAV (Prestadora de Serviços de Ativos Virtuais, Brazil's virtual asset service provider authorization). The filing window for companies already operating closed on October 30, 2026. After a filing, the BCB has up to 360 days for phase one and 720 more for phase two, close to three years, under Resolution BCB 108 of 2021 as amended by Resolution BCB 549 of 2026. An in-house Brazil path is therefore longer than the staffing table's range. Our summary of the rules, with dates and open points, is in the PSAV guide.

In the United States, federal registration is the floor. 31 CFR 1022.380 requires a money services business to register with FinCEN, and FinCEN's registration page, read on November 1, 2026, says Form 107 is due within 180 days after the business is established and renewal comes every two years. The same page lists civil penalties of up to $5,000 per violation and up to 5 years of criminal penalties for operating unregistered. Registration is not a state licence: state money transmission regimes differ, and most require their own application. Our explainer on FinCEN MSB registration covers the federal side.

Other jurisdictions run their own virtual asset regimes (see what a VASP is), so an in-house build is one licensing project per market.

Buying outsources the rail and the local arrangement. It does not outsource your own obligations toward your customers: your AML program, customer due diligence and the regulatory perimeter in your market stay with you, so ask your counsel what applies before assuming a provider covers it. Which countries Lumx onboards, and where onboarding is restricted, is on the supported countries page.

When does the build pay for itself?

Build cost is mostly fixed and buy cost scales with volume, so the break-even is a volume. The formula is the annual run cost of the in-house team and contracts, minus the provider's platform fee, divided by the provider's per-transaction cost as a share of volume.

With the illustrative $1.05 million to $1.35 million above and a placeholder all-in rate of 0.5% of volume (not a Lumx rate), break-even sits near $210 million to $270 million a year on a single payment stream. Treat that as a floor, since run cost after the build year still carries vendor fees and held capital. Below it, the provider is cheaper before counting the year of delay. Above it, a build looks reasonable only if the licences are in hand.

To fill the buy side, ask Lumx for three inputs. Its commercial terms are a monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans. The standard agreement has a monthly minimum with a ramp-up period and no setup fee, so request the platform fee, the per-transaction fee and the minimum with its ramp-up in writing.

The formula leaves out time to revenue, since a year of build is a year without the corridor, and opportunity cost, what the same engineers would have shipped on your own product. Put both in front of finance.

When building makes sense

Building is right when the rail is the product or the margin. Four cases:

• You are already a licensed payments company, and the spread on the rail is your business model.

• One corridor carries enough volume to justify direct bank and liquidity relationships there, and you hold the local authorization.

• You need behavior that no provider offers, and you checked at least three providers before concluding it.

• Your regulator expects you to hold the activity in-house, which is common for banks and for some regulated payment institutions.

If none fits, the build competes with your roadmap. A buyer should start with choosing a stablecoin infrastructure provider, and the operator map shows who does what.

Hybrid splits

Most teams land in between. You own the ledger and customer experience and buy the rails. Or you own custody for treasury and buy the last mile into local currency. Or you own the onboarding flow and buy the verification behind it. A hybrid keeps control where customers see it and outsources what needs a licence or a bank, on one condition: the provider can see every payer and payee. Lumx requires each payout to debit a wallet that belongs to an onboarded customer, or to move to another onboarded customer, because pooling funds for unboarded third parties is not allowed under its nested payments rules, unless Lumx has approved the structure in writing. The sibling guide on first-party vs third-party payouts covers the design. A hybrid that depends on pooling needs a different design.

I would not let engineering size this decision from the prototype. I would ask the compliance lead and the treasury lead to estimate their rows first, because the licensing and banking rows set the date and the cost, and the code rows follow. I would approve a build only when the company already holds the authorization for its first corridor, and otherwise treat the first year as a buy.

When buying is the wrong call

Buying is the wrong call in three situations. If your regulator or your bank partner requires you to operate the activity yourself, a provider cannot hold it for you. If you pay out in a single corridor at very high volume and already have the licence, the provider's per-transaction fee becomes the largest line in your cost base. And if the stablecoin leg is incidental, a few payments a month, a local bank transfer may be the better answer, which when not to use blockchain payments covers.

Buying has its own risk: one provider is one point of failure, so read the exit terms and data portability first (provider contract terms).

What the buy path looks like on 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.

The sequence is short. You create the customer and the customer accepts the terms of service. Verification runs, with KYB (know your business, the verification of a company and its owners) targeting one business day, and the wallet and local-currency accounts become usable once the customer is approved. You register the payout destination, request a quote, and create the payout. Each step reports through signed webhooks, and a held transaction appears as an RFI (request for information, a compliance hold that asks for a document before a transaction clears) that you answer through the API. The flow is detailed on the global payments product page and the coverage by country page.

On timing, an API integration with Lumx typically takes two to three weeks through to go-live. That compares with 12 to 18 months in the illustrative build above, and longer for in-house Brazil. A sandbox runs against test stablecoins and mock banking partners, so the integration can be tested before any real money moves. The next step is to run your own payout in the sandbox and time it.

Methodology and sources

Lumx product facts come from docs.lumx.io pages read on November 1, 2026: coverage, stablecoin wallets, transactions, exchange rates, identity verification, transaction limits, nested payments, idempotency, webhooks, environments and payment rail cut-off times.

FinCEN's MSB registration page was read on November 1, 2026, and the deadline, the renewal period and the penalty figures come from it. 31 CFR 1022.380 is cited by section number. BCB Resolutions 519, 520 and 521 of 2025, 108 of 2021 and 549 of 2026 link to the BCB's official normative pages, which serve their text through a script, so no claim here rests on our reading of their wording and the article and deadline references are those in our published PSAV guide. Staffing, duration, cost per person and break-even rate are illustrative assumptions, not Lumx data.

Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.

Cover photo: Lance Grandahl on Unsplash.