How to launch a crypto card programme
Most programmes are not delayed by the things teams plan for. They are delayed by scheme approval, KYC integration and card production, while everyone watches the API build that was never the bottleneck.
Decide who is issuing, before anything else
The first decision is which licensed entity issues the card, because it constrains every other decision. It determines which jurisdictions you can operate in, which customers you can onboard, what the product can legally do, and which regulator you answer to.
Teams routinely design a beautiful product, then discover the licensing reality does not support it in their target market, and rebuild. Doing it in the other order is less satisfying and considerably faster.
The delivery sequence
- 1Programme definition
Target segments, jurisdictions, card products, funding assets, expected volumes and the commercial model. This is the document everything else is built against, and vagueness here surfaces as rework later.
- 2Licensing and BIN route
Confirm the issuing entity and decide between your own BIN, a sponsored BIN, or platform-managed BIN ranges. This choice sets your earliest possible launch date more than any other.
- 3Platform and vendor selection
Issuing platform, processing, personalisation bureau, fulfilment, KYC and screening vendors. If you use a managed platform, most of these come bundled and this step collapses.
- 4Card design and scheme submission
Designs are produced against scheme design rules and submitted for approval. Start early. Approval cycles are not fast, and a rejected design costs you a full cycle.
- 5Integration build
Cardholder creation, issuance, funding, controls, webhooks and reconciliation, built against sandbox. Usually the most predictable phase, and the one teams over-plan for.
- 6KYC and AML integration
Connect your regulated onboarding process so its outcome gates issuance and funding. Consistently underestimated, because it crosses compliance, engineering and vendor boundaries at once.
- 7Compliance sign-off
Monitoring thresholds, exclusion list, risk-rating methodology, reporting, and the responsibility matrix signed by everyone named in it.
- 8Pilot
A bounded cohort with real cards. Prove onboarding, issuance, funding, authorisation, settlement, disputes and support end to end. Every programme finds something here.
- 9Production roll-out
Scale under the same framework once the pilot is proven and signed off. Production is a volume change, not a new project, if the pilot was designed honestly.
Where the time actually goes
| Phase | Commonly assumed | Usually true |
|---|---|---|
| API integration | The long pole | Predictable, and fully under your control |
| Card design approval | A formality | A real dependency with real cycle time |
| KYC and AML integration | A vendor plug-in | Cross-functional, and the most common slip |
| Card production and shipping | Fast | Manufacturing lead times are real |
| Scheme certification (own BIN) | Paperwork | Months, and gating everything behind it |
| Compliance sign-off | A final step | Needs to run in parallel, not at the end |
Launch virtual first
Virtual cards prove the entire flow that matters: a customer onboards, is verified, is issued a card, funds it, and spends. That is the whole system, minus manufacturing and logistics.
Launching virtual first lets you find the real defects, which are almost always in onboarding friction, funding edge cases and support tooling, while plastic is still in production. Programmes that wait for physical cards to test anything discover those same defects with cards already in the post.
What to instrument on day one
Build the operational visibility before the pilot, not after it: activation rate from issuance to first funding, funding success and failure reasons, authorisation approval and decline rates with decline reasons, time to first spend, support contact rate per hundred cards, and dispute rate. Decline reasons in particular tell you more in a week than a month of speculation, because a decline is a customer telling you exactly where the product broke.
Frequently asked questions
How long does it take to launch a crypto card programme?+
The dominant variables are whether you already hold a licence, whether you are using your own BIN or a managed one, and how quickly your KYC and AML integration can be completed. Programmes on managed BIN ranges with an existing licence move materially faster because scheme certification is already done.
What is the first thing to decide?+
Which licensed entity is issuing. Everything else, including product design, jurisdictions, funding assets and BIN route, follows from that answer. Teams that design the product first frequently rebuild it once the licensing reality lands.
Should we launch physical or virtual cards first?+
Virtual, in almost every case. Virtual cards prove the end-to-end flow, from onboarding through funding to authorisation, without card production and shipping on the critical path. Physical follows once the flow is proven.
What usually delays a launch?+
Scheme approval of card designs, KYC and AML integration, and card production lead times, roughly in that order. Almost never the API integration, which teams consistently overestimate and which is the one part fully under your control.
Shorten the critical path
Zen Card programmes launch on managed BIN ranges with scheme certification already complete, so the longest dependency is off your timeline.