Stablecoin Infrastructure for Fintechs: Buy or Build

11 min read
Robert Romaniuk
Stablecoin Infrastructure for Fintechs: Buy or Build

MiCA sets the permanent minimum capital for a crypto-asset service provider at EUR 50,000, EUR 125,000 or EUR 150,000 depending on the services offered (Regulation (EU) 2023/1114, Annex IV). That is the cheapest number in the entire build case, and the one every internal business case leads with. This article prices the other items (custody, KYT, Travel Rule, treasury and reconciliation) and names the point at which building stops being the rational choice for a fintech or PSP.

What “build” actually means, item by item

When a product team says “we’ll build stablecoin infrastructure for fintechs ourselves”, they are usually costing the integration: a node or a node provider, a wallet library, a webhook, a ledger entry. That is the visible tenth of it. The build is six systems, and most of them come with regulatory obligations attached.

Key management and custody. Key generation, HSM or MPC infrastructure, signing policy, quorum, key rotation, disaster recovery for a key you cannot reset, and segregation of client assets from your own. Under MiCA, custody and administration of crypto-assets on behalf of clients is a Class 2 service: EUR 125,000 permanent minimum capital under Annex IV, and more importantly, a licensable activity with its own liability regime.

Transaction screening (KYT) and sanctions. Pre-send screening of destination addresses, attribution data, exposure scoring, PEP and sanctions lists, alert triage, and a human review function that exists on a Friday afternoon. The screening vendor is the easy part; the alert-handling operation is a headcount line that does not shrink.

Travel Rule. In the EU this is Regulation (EU) 2023/1113, applicable since 30 December 2024, the same date the EBA’s Travel Rule Guidelines took effect (EBA, 2024). Compliance is not a data field. It is counterparty VASP discovery, a messaging protocol, handling of transfers to and from self-hosted addresses under Articles 14(5) and 16(2), including an assessment of whether the address is owned or controlled by your customer once a transfer exceeds EUR 1,000, and a policy for what you do when the data arrives incomplete.

Treasury and FX. Pre-funding, float, conversion spread, a hedging policy, and the question of which legal entity holds the stablecoin balance overnight. This is where a build quietly becomes a balance-sheet decision rather than an engineering one.

Reconciliation and accounting. Covered in its own section below, because it is the line item that most often decides the question.

The integration. The part you actually estimated.

What stablecoin infrastructure consists of. Stablecoin payment infrastructure is six systems, not one integration: key management and custody, transaction screening (KYT) and sanctions, Travel Rule messaging, treasury and FX, reconciliation into the general ledger, and the API integration itself. Most of the six carry regulatory obligations in the EU, and custody and transfers are licensed services under MiCA, which is why the build decision is a licensing decision before it is an engineering one.

The licensing burden, priced to the instrument

The capital figure is the floor, not the cost. What costs is authorisation, and the window for doing it informally has closed.

1 July 2026 was the outer limit of MiCAR’s grandfathering regime under Article 143(3): firms operating under pre-existing national regimes could continue only until that date or until authorisation under Article 63 was granted or refused, whichever came sooner. Member States were free to shorten the period, and many did. ESMA’s list of national choices shows 12 months for Germany, Ireland and Austria and six months for the Netherlands and Finland (ESMA, 2024). ESMA’s position for firms that missed the deadline is a wind-down, not a grace period: stop onboarding new EU clients, stop marketing, limit activity to closing out positions, keep custody only as long as strictly necessary, and maintain AML controls throughout (ESMA, 23 June 2026).

Three provisions are worth reading before a build decision, because each one converts an engineering estimate into an operating obligation:

  • Article 67(1): prudential safeguards at all times, at the higher of the Annex IV minimum or one quarter of the preceding year’s fixed overheads, reviewed annually. The second limb is the one that grows with you.
  • Article 67(4): safeguards must be Common Equity Tier 1 items, or an insurance policy covering the Union territories where services are provided, or a combination. Article 67(6) requires that cover to extend to risks including business disruption and system failure.
  • Issuing your own euro or dollar token is a different regime entirely. An e-money token issuer must be a credit institution or an authorised electronic money institution under Directive 2009/110/EC. Circle took that route in France, obtaining an EMI licence from the ACPR on 1 July 2024 (Circle, 2024). If anyone in the room has said “we’ll just mint our own stablecoin”, that is the path they are describing.

This article describes regulatory and market conditions for general information. It is not legal, tax, or financial advice. INXY Payments is a payment infrastructure provider, not a law or accountancy firm, and decisions with regulatory consequence should be reviewed by qualified counsel in the relevant jurisdiction.

Buy, build or embed: the comparison that matters

Three models, and the honest tradeoff for each. “Embed” here means a regulated provider sits behind your brand and your UX, with you as the distribution layer and the provider as the licensed principal.

CriterionBuild in-houseBuy (regulated rail, your own licence)Embed (provider is principal)
Who holds the authorisationYouYou, for your own activityThe provider
Minimum capital exposureAnnex IV floor plus 25% of fixed overheads, rising annuallySame, if you remain the licensed partyNone attributable to the crypto leg, subject to your own perimeter check
Custody liabilityYours, including key lossShared, defined by contractProvider’s
Time to first production paymentLongest: authorisation is the critical path, not codeMediumShortest
Chain coverageEach chain is a separate integration, screening config and ops runbookProvider’s coverage, extended on their roadmapProvider’s coverage
Margin on the payment legHighest, if volume justifies the fixed costMiddleLowest: you are reselling
Control over UX and dataTotalHighDepends on the integration: a host-to-host API leaves the UI with you
Where it failsFixed cost does not amortise below real volume; ops headcount is permanentProvider concentration risk; roadmap dependencyYou cannot differentiate on the thing your customers are paying for

The losing use case for each, including ours. Build loses when your projected volume is a forecast rather than a signed pipeline. Buy loses when the rail you bought becomes the product and you have no second supplier. Embed loses when stablecoin settlement is your differentiator: if the whole pitch to your own customers is faster settlement, outsourcing it entirely leaves you with nothing proprietary to sell.

Reconciliation is the line item that kills most build cases

Ask a fintech CFO which part of a stablecoin integration surprised them and you will rarely hear “custody”. You will hear reconciliation.

A stablecoin payment produces at least four events that must agree: the on-chain transfer with its own hash, confirmation depth and timestamp; the network fee, which is denominated in a different asset from the payment; the conversion to or from fiat, with a rate and a spread; and the fiat settlement to a bank account, which lands on its own calendar. None of those four share a primary key by default. Building the mapping into a chart of accounts that an auditor will accept is weeks of work that nobody scopes, and it has to be re-done for each chain you add, because finality semantics differ.

What no vendor will tell you: a buy or embed decision does not remove this work, it only moves the hard part. You still have to map the provider’s settlement report into your ledger, and a provider whose report does not expose the network fee as its own line will cost you more in month-end effort than they save you in integration. Ask for a sample settlement file during evaluation, not after contracting. If the fee is netted invisibly into the settlement amount, you have found a reconciliation problem you will own for years. INXY’s settlement report shows the network fee as its own line, and if you want to run that test against us first, talk to a payments specialist and ask for a sample file.

Chain coverage: the cost nobody models

Every additional chain is not a configuration flag. It is a distinct finality model, a distinct fee asset, a distinct congestion profile, distinct screening coverage from your KYT vendor, and a distinct set of off-ramp liquidity conditions. A build that supports one chain is a project. A build that supports the chains your customers actually use (and they will ask, because their own counterparties specify the network) is a programme.

For reference on the practical differences, our breakdown of TRC-20, ERC-20 and BEP-20 network costs sets out the tradeoffs that drive this. INXY supports major stablecoins on the networks customers use, with Travel Rule and AML screening built in rather than bolted on. The point is not the list. It is that each network on it carries its own permanent operational cost, and a build case that assumes marginal cost per chain is close to zero is wrong by an order of magnitude.

When build-vs-buy flips: the evaluation sequence

Work through these in order. The answer usually appears by step four.

  1. State the volume that is contracted, not forecast. Fixed-cost recovery is the whole build argument. If the volume is a projection, you are financing an option, not a payment rail.
  2. Decide whether the payment leg is your product or your plumbing. If your customers will never know which rail settled their payment, it is plumbing, and plumbing is bought.
  3. Price the authorisation path properly. Capital under Annex IV is a deposit, not a cost. The cost is legal, the application, the compliance hires, the governance arrangements, the time the application takes, and the revenue you do not earn while it is pending.
  4. Count the permanent ops headcount. Alert triage, counterparty VASP onboarding, failed-payout handling, month-end reconciliation. This is the number that does not appear in engineering estimates and never goes down.
  5. Model two chains, not one. Then model the third, which is the one a customer will demand six months after launch.
  6. Run a parallel pilot. Same payment flow through a bought rail and a prototype build, for one month, measured on landed cost, failure rate and hours of human intervention.
  7. Set the review trigger in advance. “We revisit build when monthly settled volume exceeds X for two consecutive quarters” is a decision. “We’ll build eventually” is not.

Where the flip actually sits. Building becomes rational when three things are true at once: settled volume is high enough that the per-transaction margin on a bought rail exceeds your fully loaded fixed cost; the payment experience is a differentiator your customers can perceive; and you already hold, or are already applying for, authorisation for an adjacent regulated activity so the compliance function is not a new department. Two out of three is not enough. For almost every fintech and PSP below that bar, the right answer is to buy a regulated rail and spend the engineering capacity on the product your customers are actually paying for, which is what INXY’s infrastructure for fintechs and PSPs is built to sit behind.

INXY is authorised as a crypto-asset service provider under MiCA, covering custody, exchange and transfer of crypto-assets on behalf of clients. Fintechs connect through a host-to-host API: they keep their own UI and flow, and the security, compliance screening and licensing are already in place behind it. Pricing starts from 0.1% per transaction, depending on volume, currency and corridor, with no setup or monthly fees.

What breaks in production

  • The KYT alert queue has no owner. Screening goes live, alerts accumulate, and nobody is rostered to clear them. Payments stop, and the reason is organisational, not technical.
  • Travel Rule data arrives incomplete from a counterparty VASP. Your policy for this must exist before the first transfer, not after. The EBA Guidelines require procedures for detecting missing or incomplete information, and “we’ll chase it” is not one.
  • Network fee asset runs dry. The payment is funded; the gas is not. Batches fail at 3 a.m. with a balance error on an asset nobody is monitoring.
  • A chain reorganisation after you credited the customer. Your confirmation-depth policy is a product decision disguised as a config value. Set it per chain, document it, and make support aware of it.
  • Partial batch failure. Forty of 5,000 payouts fail. If the ledger assumes all-or-nothing, the books are now wrong and the support queue is live.
  • The auditor asks how the network fee is recognised. If reconciliation was designed by the engineering team without finance in the room, this is where the build case is quietly re-opened.
  • Authorisation takes longer than the product roadmap. The commonest single failure of a build decision is not technical at all.

Decision framework

Four questions, in this order.

1. Is stablecoin settlement your product or your plumbing? Product means build or buy with your own licence. Plumbing means embed, and stop debating it.

2. Do you already hold a regulated authorisation and a compliance function? If yes, the marginal cost of build is far lower than the gross cost, and the calculation genuinely changes. If no, you are not costing a payment rail. You are costing a licensed business.

3. Can you name the second supplier? If a bought rail becomes a single point of failure for your revenue, that is a risk to price and mitigate contractually, not a reason to build.

4. What is the review trigger? Write the volume threshold and the date into the decision memo. A build decision taken at the wrong moment is usually a buy decision taken too late and then regretted twice.

Where INXY is not the answer. If you are a licensed credit institution or EMI with an existing treasury desk, an in-house compliance function and settled volume already at scale, your marginal cost of building is low enough that a bought rail is likely to cost you margin without buying much you do not already have. The same applies if your regulatory perimeter requires you to be the principal on every leg for reasons that have nothing to do with payments. Buying a rail earns its keep when it removes a function you would otherwise have to create, not when it duplicates one you already run. Our piece on offering stablecoins safely as a fintech covers the compliance side of that judgement in more detail. If you want to test the arithmetic against your own volumes and licence position, compare your current flow with our team and bring your settlement figures.

FAQ

What is stablecoin infrastructure for fintechs?

It is the set of systems a fintech or PSP needs to move value in stablecoins: custody and key management, transaction screening, Travel Rule messaging, treasury and FX, reconciliation into the general ledger, and the API layer. In the EU most of these carry regulatory obligations, so the decision to build is a licensing decision before it is an engineering one.

Do we need a MiCA licence to offer stablecoin payments in the EU?

If you provide crypto-asset services to clients in the EU, yes. MiCAR’s transitional regime ended no later than 1 July 2026 under Article 143(3), earlier in several Member States, and firms without authorisation under Article 63 are expected to wind down rather than continue. Embedding a provider authorised under MiCA as principal is the alternative. Confirm your own perimeter with counsel.

How much capital does a CASP need to hold?

Annex IV of Regulation (EU) 2023/1114 sets the permanent minimum at EUR 50,000 for Class 1 services, EUR 125,000 for Class 2 including custody and exchange, and EUR 150,000 for Class 3 including operating a trading platform. Article 67(1) requires the higher of that figure or one quarter of the previous year’s fixed overheads.

What does the Travel Rule require in the EU?

Regulation (EU) 2023/1113 extends originator and beneficiary information requirements to crypto-asset service providers and has applied since 30 December 2024, alongside the EBA’s Travel Rule Guidelines. Firms must detect missing or incomplete information, and Articles 14(5) and 16(2) govern transfers involving self-hosted addresses, including an ownership-or-control assessment above EUR 1,000.

Is it cheaper to build or to buy stablecoin rails?

It depends on contracted volume, not forecast volume. Building becomes rational when settled volume is high enough to recover a permanent fixed cost, the payment experience differentiates your product, and you already hold adjacent authorisation so compliance is not a new department. Below that, buying is almost always cheaper in total cost.

What is the difference between buying and embedding stablecoin rails?

Buying means you integrate a regulated rail while remaining the licensed party for your own activity. Embedding means the provider is the licensed principal and you are the distribution and experience layer. Embedding is faster and usually carries no capital exposure on the crypto leg, at the cost of margin and differentiation. Check your own perimeter either way.

Important notice for UK visitors

This website and its content have been produced and disseminated for persons outside of the United Kingdom. The information provided is not directed at or intended for distribution to, or use by, any person or entity located within the UK. The financial products and services mentioned on this website are not eligible for the UK. Cryptoassets are classified as Restricted Mass Market Investments in the UK, meaning that they are high-risk investments and are not suitable for most retail investors. We expressly disclaim any responsibility or liability for any access to or use of this website by any person located within the UK.