Card programmes rarely slip because of engineering. They slip because a compliance question was answered late, a support process did not exist, or nobody decided what happens when a cardholder overpays.
This is the list in the order things actually bite.
1 · Eligibility and structure
- Legal entity confirmed, with ownership structure documented
- Business model explained in terms the issuer will assess
- Target markets listed — and confirmed against issuer licences
- Programme type decided: white-label or co-branded
- BIN sponsor and issuer identified
- Expected volumes modelled, with the assumptions written down
Where this slips: target markets. Teams assume global availability, then discover the issuer's licences do not cover their second-largest market. Confirm the list before it reaches a roadmap.
2 · Compliance
- KYC/KYB flow designed, with the split between you and the issuer agreed
- Sanctions and PEP screening in place
- Transaction monitoring rules defined
- AML policy documented and approved
- Data protection basis established, including cross-border transfers
- Complaints procedure written
- Regulatory reporting owner named
Where this slips: the split. "The issuer handles compliance" is never wholly true — you own the customer relationship, so onboarding and monitoring of your users typically sit with you. Get the boundary in writing.
3 · Product decisions
- Virtual, physical, or both at launch
- Funding model: prepaid, credit, or converted at authorisation
- Currency support and who bears FX
- Spending controls: limits, categories, geographies
- Card design approved by the network
- Replacement and expiry policy
- Fee schedule finalised and disclosed
Where this slips: card design. Network artwork approval takes longer than teams expect, and physical manufacturing cannot start until it clears. Submit early.
4 · Engineering
- Sandbox integration complete
- Webhook handling with idempotency and out-of-order tolerance
- Ledger separating authorisations from settlements
- Reconciliation process, in a format finance will actually use
- Freeze/unfreeze exposed to support
- Monitoring and alerting on authorisation failures
- Load tested against projected peak
Where this slips: reconciliation. It is treated as a reporting task and discovered to be a data-model problem in the first month of real volume.
5 · Support readiness
- Support team trained on card states and what each means
- Dispute and chargeback process documented, with owners
- Lost/stolen card procedure, including out of hours
- Escalation path to the issuer defined
- Cardholder-facing help content written
- Response-time targets agreed
Where this slips: disputes. Nobody owns them until the first one arrives, and by then the clock is already running against a network deadline.
6 · Launch
- Internal cards issued and used in production first
- Small closed pilot with real cardholders
- Monitoring watched daily through the pilot
- Rollback plan if authorisation rates look wrong
- Comms ready for cardholders, support and stakeholders
- Success metrics agreed before launch, not after
Where this slips: skipping the pilot. Every programme that went straight to full launch found something in week one that a twenty-person pilot would have caught for free.
The realistic timeline
Virtual-only co-branded programmes move fastest. White-label with physical cards takes considerably longer, and the long pole is almost always approvals — network artwork, issuer sign-off, market eligibility — not code.
The teams that launch on schedule are the ones that started section 1 and section 2 in parallel with engineering, rather than treating compliance as a gate at the end.
Start with the honest version
Before committing to a date, answer these three:
- Which markets are actually approved, today?
- Who owns disputes, in writing?
- What happens in week one if authorisation rates are worse than modelled?
If any answer is vague, that is where the delay will come from.
Book a scoping call and we will work through the list against your specific programme.