A 90-Day Plan to Launch Your Fintech MVP

Most teams that set out to launch a fintech treat the 90-day question as a purely engineering one. It is not. The MVP you can build in a quarter is limited far less by code than by two things that are slow to change: your regulatory perimeter and your custody model. Get those right early and the build compresses. Get them wrong and no amount of engineering saves the timeline.

This is a concrete, phase-by-phase plan to reach a production MVP in 90 days. It assumes you integrate regulated rails rather than building them from scratch, which is the only realistic path to that timeline. For the architecture behind it, read the companion guide on how to build a crypto and fiat payment platform. Here we focus on sequencing: what to do, in what order, and what to decide before you write code.

How long does launching a fintech MVP actually take?

A production MVP in under 90 days is realistic for a focused team using API-based infrastructure, but only if the regulated parts ride on licensed partners. The three variables that move the date are product scope, the number of markets, and whether you need your own authorization. Applying for your own license is measured in months, sometimes over a year, and runs on a separate clock from your build. The plan below assumes you launch on partner licenses first and pursue your own authorization in parallel if your model requires it.

1. Days 1 to 10: define the model and the perimeter

Before anything technical, write down exactly what your product does and who touches the money. Your regulatory perimeter is defined by one question: do you ever control customer funds? If you hold, convert or transmit customer money, you are inside money-transmission and safeguarding rules. If users keep control of their own funds and approve every movement (a non-custodial model), your surface shrinks and your licensing conversation changes.

Decide four things this week:

• The core flows you actually need for launch (accounts, on and off ramp, cards, cross-border).
• The markets you will serve first, because licensing follows your customers, not your incorporation.
• Your custody model, custodial versus non-custodial, because it drives everything downstream.
• Whether the regulated parts can ride on partner licenses while you own the product experience.

If you are unsure which custody model fits, the custodial versus non-custodial comparison walks through the tradeoffs.

2. Days 11 to 25: choose your regulatory path

Your regulatory path is the single biggest determinant of cost and timeline, so resolve it before you build. In most markets you have three broad options, and they are not mutually exclusive.

Path	What it means	Time to launch	Best when
Ride partner licenses	You operate as an agent of licensed institutions that hold the regulated activity	Weeks to a few months	You want speed and a lean start, and your model is non-custodial or thin on custody
Get your own authorization	You apply for a license (for example an e-money or payment-institution authorization)	Many months, sometimes over a year	You need full control of the regulated activity or partner routes do not fit your market
Hybrid	Launch on partner licenses now, pursue your own authorization in parallel	Launch in weeks, authorize later	You want to be live while building toward independence

Where your model requires an authorization, the category matters. Many markets separate the activity of issuing electronic money and moving payments from the activity of connecting investors with borrowers. In Mexico, for instance, its fintech law defines distinct figures for each: an electronic-payment-funds institution for e-money and payments, and a collective-financing institution for crowdfunding. Different activity, different license, different rules. Pick the one that matches what you actually do, and confirm the classification with counsel because it varies by market.

For a deeper map of registrations across regions, see licenses to move crypto and fiat: MSB, money transmitter, EMI and MiCA.

3. Days 20 to 30: budget capital, costs and runway

Set your budget once the regulatory path is clear, because the path changes the numbers by an order of magnitude. Applying for your own license usually requires minimum capital set by the regulator, plus legal, audit and ongoing supervision costs. Launching on partner licenses trades some recurring fees for far lower upfront capital and a much shorter path to revenue.

Build your budget around these buckets:

• Legal and regulatory: counsel, entity setup, and the authorization process if you pursue one.
• Minimum capital: required only if you hold your own license; the amount is set by the regulator, often varies with your activities and volume, and should be confirmed with counsel rather than assumed.
• Technology: integration of the payments API, wallet layer, compliance engine and dashboard.
• Compliance operations: KYC/KYB checks, transaction monitoring, and periodic audits, which are recurring, not one-time.
• Runway: enough to survive the pilot and reach real transaction volume.

Do not treat minimum capital figures you find online as fixed. They differ by market, by activity, and change over time, so model your own numbers with counsel and your providers.

4. Days 31 to 50: build the core

The core is smaller than most teams expect, because the hard, undifferentiated parts are integrated rather than built. Your minimum viable stack has four pieces: a unified payments API, a wallet and custody layer, a compliance engine, and an operations dashboard.

Treat crypto and fiat as one ledger from the first commit. That single decision lets you launch with fiat and add stablecoin rails later without re-architecting. Wire webhooks for every transaction event and make every write idempotent so no event is processed twice and your ledger stays auditable. A create-payment call should look roughly like this, with an idempotency key protecting you against retries and duplicates:

curl -X POST https://api.yourprovider.com/v1/payments \
  -H "Authorization: Bearer $API_KEY" \
  -H "Idempotency-Key: 4f1a9c2e-7b3d-4e6a-9f21-8c0d5b2a1e77" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": "250.00",
    "source_currency": "MXN",
    "settlement_currency": "USDC",
    "beneficiary": { "type": "bank_account", "rail": "ach", "account_ref": "acct_9f2b" },
    "metadata": { "order_id": "ord_10432" }
  }'

The provider then posts asynchronous updates to your webhook as the payment moves through states (created, screened, settled or failed), and your ledger reconciles against those events. If you want the reasoning behind this design, the Banking-as-a-Service guide explains how the regulated activity sits behind the API you integrate.

5. Days 51 to 65: wire compliance into the flow

Compliance belongs inside the product flow, not bolted on after launch, because retrofitting it means redesigning flows and migrating data. Build KYC/KYB into onboarding as a step users cannot skip, run sanctions and PEP screening at onboarding and on every transfer, and monitor transactions with rules you can configure per market.

If you move crypto, add wallet screening and travel-rule data exchange where thresholds require it, attached to the transfer automatically so settlement does not slow down. The mechanics of all of this are covered in how KYC and AML work for crypto and fiat payments. The principle for the plan is simple: if a check is not in the flow by day 65, it will be far more expensive to add in month six.

6. Days 66 to 80: add rails and harden

With the core and compliance live, add the rails that make the product useful and then attack the failure paths. Card issuing that spends directly from the balance, cross-border payouts to local rails, and on and off ramps between crypto and fiat are the common additions at this stage.

Then test what breaks in production, not what works in a demo: reversals, sanctions hits, network congestion, partial failures and duplicate events. Stand up the operations dashboard so your team can manage settlements, alerts and reports without touching the database. This is where a prototype either becomes a platform or reveals that it never was one.

7. Days 81 to 90: run a controlled launch

Launch to a closed pilot with real users and real money at low limits before you open the doors. The pilot exists to prove three things under real conditions: reconciliation holds, settlement timing is predictable, and the audit trail is complete. Only when those hold do you raise limits and widen access.

Keep the perimeter narrow for the pilot, one market and a short list of flows, so that any issue is easy to isolate. A clean pilot is worth more than an impressive feature list, because it is the evidence a partner bank or regulator will actually ask to see.

The 90-day plan at a glance

Here is the full sequence in one view, which doubles as the checklist to run against each week.

Phase	Days	Focus	Exit criteria
Scope	1 to 10	Model, flows, markets, custody	Perimeter written and agreed
Regulatory path	11 to 25	Partner licenses, own authorization or hybrid	Path chosen, classification confirmed
Budget	20 to 30	Capital, costs, runway	Funded plan with realistic numbers
Core build	31 to 50	API, ledger, webhooks, idempotency	One real flow end to end
Compliance	51 to 65	KYC/KYB, screening, monitoring	Checks live inside the flow
Rails and hardening	66 to 80	Cards, cross-border, failure paths	Unhappy paths tested
Controlled launch	81 to 90	Closed pilot at low limits	Reconciliation and audit trail hold

Five things to get wrong at your peril

1. Starting with code. The perimeter and custody model gate everything. Decide them in week one.
2. Assuming you need every license yourself. Much of the regulated surface can ride on partner licenses. Map it before you scale.
3. Treating minimum capital as a fixed number. It varies by market and activity. Model it with counsel, not with a blog figure.
4. Adding compliance last. It is the most expensive way to do it. If it is not in the flow, it is not done.
5. Skipping the pilot. A clean run at low limits is your strongest evidence. Do not trade it for a faster public launch.

Where Tokelia fits

Tokelia is the infrastructure for programmable money: virtual accounts, unified crypto-and-fiat rails, card issuing, cross-border payments and stablecoins behind one REST API, with SDKs, webhooks and idempotency built in, a non-custodial architecture, and compliance in 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 and lean on partner licenses for the regulated parts while your team builds the product.

If you are scoping a 90-day launch, the fastest way to pressure-test this plan against your own model is to walk a real flow with our team. Talk to us and get a sandbox key.