PLAYBOOK
A practical guide to launching a fintech that moves crypto and fiat with KYC/AML compliance built in, covering rails, non-custodial custody, licensing, stablecoins and card issuing.
By Lucía 12 min read 
Most founding teams that set out to launch a fintech make the same expensive decision in their first quarter: they build payment rails from scratch. Six months later the pattern is predictable. The first real customer arrives, the stack is not production-ready, compliance is a patch bolted on at the end, and the technical debt is already too large to pay down cleanly.
Launching a fintech that handles crypto and fiat payments does not require reinventing the infrastructure. It requires choosing the right foundations, and getting the parts that are hard to change (custody, compliance, licensing) correct on the first pass. This guide walks through what “production-ready” actually means, the foundations that must exist on day one, a reference architecture, and a realistic 90-day plan.
Engineering teams love to build. That instinct is exactly what sinks early fintechs. Payment rails look like a solved problem from the outside (move a number from A to B), but the parts that break in production are the ones you cannot see in a demo: reconciliation, settlement timing, failed and reversed transactions, sanctions hits, and the audit trail a regulator will ask for.
The trap is that building your own rails feels like progress while it quietly caps your ceiling. A fintech that grows on badly designed in-house infrastructure hits a wall fast: it cannot scale into a new market without rewriting the core, it cannot add a new asset without weeks of integration, and it cannot survive an audit without intense manual work. Choosing specialised B2B infrastructure is not outsourcing your product. It frees your engineers to build the thing that actually differentiates you.
Before you write a line of code, be honest about the bar. A crypto-and-fiat payment platform is production-ready when it can:
If your MVP cannot do these things, it is a prototype, not a platform. The good news is that none of them require you to build from zero.
Five things belong in your architecture from the first commit. Skipping any of them is the decision you will pay for later.
Your users think in their local currency. Your suppliers, investors or counterparties may settle in USDC, EUR or USD. A platform that treats each currency as a separate island turns every cross-border movement into an engineering problem.
Start with named accounts per user and a unified balance that can hold multiple currencies, backed by real bank details where the market needs them (US ACH, European SEPA, UK Faster Payments, and local rails such as CLABE, PIX or PSE in Latin America). Deposits should be able to auto-convert to a stablecoin so that value is instantly usable across the rest of the system.
This is the core. The market rewards flexibility, and flexibility comes from treating crypto and fiat as one rail rather than two:
When these three flows live behind one API, a payment from a peso wallet to a dollar bank account stops being a bespoke project and becomes a single call.
A card is how most users actually touch their money. Modern card issuing lets you launch virtual and physical Visa or Mastercard programs where the card spends directly from the user’s balance, crypto or fiat, with no pre-funding pools to manage. The important design choice is that the wallet connects to the card network so spending happens against the real-time balance, with granular limits, freeze controls and 3-D Secure built in.
Here is where many teams make a quiet but costly error: they treat custody as a pure security problem. It is also a regulatory and operational one.
In a custodial model you hold your users’ funds and keys. That places you inside safeguarding and money-transmission rules, forces segregation and audit obligations onto your balance sheet, and makes you the single richest target on the network.
In a non-custodial model users keep control of their own funds and every movement needs their approval. You run the program without ever holding customer money. This does not make compliance disappear, but it materially reduces the surface you have to safeguard and it changes the licensing conversation. For many products, non-custodial is the difference between needing a heavyweight licence yourself and being able to operate as an agent of a licensed partner.
Whichever model you choose, the non-negotiables are the same: fund segregation that is auditable in real time, complete traceability of every movement, and signing policies configurable to your product’s risk profile.
Compliance added after launch is the most expensive compliance there is. It means redesigning flows, migrating data and, in the worst case, pausing operations. Building with compliance from day one means:
The cleanest architectures ship these as part of the base stack, not as optional add-ons you integrate later.
Licensing is where founders freeze, usually because they assume they need everything themselves. You often do not.
| Question | Typical answer |
|---|---|
| Do you hold or transmit customer funds? | If yes, you likely need MSB registration and, in most US states, a money transmitter licence. |
| Are you non-custodial and an agent of a licensed institution? | You can often operate on your partners’ licences for the regulated parts. |
| Serving the EU? | Consider an EMI or payment-institution licence, and VASP/MiCA registration for crypto. |
| Serving specific US states or LATAM markets? | Licensing usually follows where your customers are, not where you are incorporated. |
The practical move is to map your licensing perimeter early: who controls the funds, which markets you serve, and which regulated parts can ride on partner licences. Get that map from counsel before you scale, not after.
For a crypto-and-fiat MVP in production in under 90 days, the minimum viable architecture is smaller than most teams expect:
A white-label option lets you launch this whole stack under your own brand, which shortens time to market without giving up control of the user experience. Your engineers integrate against one API surface instead of stitching together a liquidity provider, a custodian, a KYC vendor and a card processor, each with its own contract, failure modes and reconciliation quirks.
Days 1 to 15, scope and perimeter. Define the exact flows you need (accounts, on/off-ramp, cards, cross-border) and the markets you will serve. Map your compliance and licensing perimeter with counsel. Get a sandbox key and validate the API against one real flow end to end.
Days 16 to 45, integrate the core. Wire up accounts, the unified payments API and the compliance engine. Build onboarding with KYC in the flow. Implement webhooks and idempotency so your ledger is auditable and no event is processed twice.
Days 46 to 75, harden and add rails. Add card issuing and cross-border payouts. Test the unhappy paths: reversals, sanctions hits, network delays. Stand up the operations dashboard and your monitoring and reporting.
Days 76 to 90, controlled launch. Run a closed pilot with real users and real money at low limits. Confirm reconciliation, settlement timing and the audit trail hold under real conditions, then raise limits and open the doors.
The variable in this timeline is never the technology. It is your product scope and the compliance perimeter your chosen markets create.
Build the parts that are your product and your differentiation: the experience, the vertical logic, the data and relationships your users come for. Buy (or integrate) the parts that are undifferentiated, hard to get right, and expensive to maintain: the rails, custody, compliance plumbing and card processing.
The test is simple. If a component would look almost identical at any competent fintech, it is infrastructure, and infrastructure is not where you win. Your engineering time is the scarcest asset you have; spend it on the 20% that only you can build.
Deep dives on each foundation above:
Tokelia is the infrastructure for programmable money: virtual accounts, unified crypto-and-fiat rails, card issuing, cross-border payments and stablecoins, behind one API, with a non-custodial architecture and compliance built into the base stack rather than sold as add-ons. Money services are provided by Tokelia LLC, a company registered as a Money Services Business with FinCEN, with regulated banking delivered by licensed institutions, so you can launch under your own brand while the heavy, hard-to-change parts are already solved.
If you are scoping a launch, the fastest way to pressure-test this against your own use case is to walk a real flow with our team.
Not always. If you never take custody of user funds and you operate as an agent of a licensed institution, you can often launch on your partners' licenses. If you hold, convert or transmit customer money yourself, you need the relevant registrations (for example a Money Services Business registration and, in most US states, a money transmitter license). The right answer depends on who controls the funds and where your customers are, so confirm it with fintech regulatory counsel.
In a custodial model you hold your users' funds and keys, which puts you squarely inside money-transmission and safeguarding rules. In a non-custodial model users keep control of their own funds and approve every movement, so you run the product without holding customer money on your balance sheet. Non-custodial does not remove compliance obligations, but it changes your risk and regulatory profile and reduces the surface you have to safeguard.
Yes. A well-designed platform treats crypto and fiat as one ledger from the start, so you can enable stablecoin and crypto rails incrementally without re-architecting the core. The key is choosing infrastructure that unifies both from day one rather than bolting crypto on later.
Identity verification (KYC/KYB), sanctions and PEP screening, and transaction monitoring run at onboarding and on every transfer. For crypto, you also add wallet screening and travel-rule data exchange where required. The cleanest setups embed these checks in the flow rather than adding them as a separate step after launch.
The travel rule requires that originator and beneficiary information travel with qualifying transfers between regulated institutions. If your transfers touch regulated crypto or fiat rails above the applicable threshold, the rule applies. Modern infrastructure attaches this data to the transfer automatically, without slowing settlement.
BaaS lets you embed regulated financial features (accounts, cards, payments) into your product through an API, with the regulated activity delivered by licensed institutions behind the scenes. It shortens time to market because you build the experience while a provider handles the rails and much of the compliance plumbing.
Common ones include a FinCEN MSB registration and state money transmitter licenses in the US, an EMI or payment-institution licence in Europe, and a VASP or crypto-asset registration under regimes like MiCA. You do not necessarily need all of them yourself, since operating through licensed partners can cover the regulated parts while you own the product.
With API-based infrastructure and a non-custodial architecture, teams experienced with REST APIs can reach a working integration in a few weeks and a production MVP in under 90 days. The variable is not the technology but your product scope, the markets you serve and the compliance perimeter those markets create.
Coverage follows the licensed institutions behind each rail and the markets where your compliance is in place. Local instant rails, card networks and stablecoin corridors have different footprints, so availability is set market by market rather than being global by default.
Topics
Written by
LucíaCompliance & Regulatory
Lucía covers compliance and regulation at Tokelia. She writes about the licensing, KYC/AML and travel-rule questions that come up when a fintech starts moving crypto and fiat, and turns them into decisions a founding team can act on.
Tell us your use case and we’ll point you to the right layer: infrastructure, tokenization or Yakopay.
We use essential cookies to run this site and, only with your consent, analytics cookies to measure traffic. You can change your choice anytime. Cookie Policy