Blueprint · 06 Card issuance program

A card program, from BIN sponsorship to disputes lifecycle.

Reference architecture for a greenfield card program. BIN sponsorship → activation → controls → disputes lifecycle. Issuer-of-record optional — works with a sponsor bank or with your own license. Virtual-first with physical card provisioning when you need it. For fintechs whose hero product is the card itself.

The use case

If the card is the product, the issuance program is the foundation.

Card-first fintechs (rewards programs, expense management, gig-worker payroll, neobanks) live or die on three things: BIN flexibility, controls granularity, and disputes UX. Cards as a product look simple from outside; the back-office is a multi-vendor multi-state-machine sprawl. Klyqo collapses the sprawl.

Virtual-first
Issuance pattern
Per-card
Controls granularity
D+0 to D+2
Physical fulfilment
Sub-second
Authorization decisions
The architecture

Cards are easy until they aren’t. Klyqo absorbs the “aren’t.”

The card lifecycle has eight states (issued, activated, blocked, lost, expired, replaced, terminated, disputed) and every state machine touches three or four vendors. Klyqo normalizes the lifecycle as journey definitions; vendor changes are binding changes.

Compliance railPCI-DSS scope minimised; network rules per scheme; AML on funding
Layer 5 · Channels
Cardholder + operator surfaces
Mobile walletWeb bankingOperator consolePush notifications
Risk railFraud + dispute patterns inline; per-card behavioral monitoring
CompliancePer-card audit trail; PSD2 SCA on issuance + controls + disputes
Layer 4 · Klyqo · the Banking OS
Runtime + marketplace dispatch
ComposeDispatchRunObserveIssueActivateControlDispute
RiskReal-time fraud scoring; auto-block on anomalies
ComplianceIssuer responsibilities (or sponsor’s); scheme reporting
Layer 3 · Marketplace primitives & providers
Card-specific capabilities
Issuance · Marqeta / Stripe Issuing / LithicNetwork · Visa / MastercardFraud · Sift / SardineDisputes · ChargehoundWallet provisioning · Apple/Google Pay
RiskFraud + dispute vendors integrated as marketplace capabilities
ComplianceSponsor bank as issuer of record (or your own licence)
Layer 2 · Issuing layer
Sponsor bank or your own issuing licence
BIN sponsorshipSettlementScheme membershipNetwork connection
RiskSpend authorizations enforced against limits at the issuer
ComplianceCard scheme rulebook + jurisdiction-specific licensing
Layer 1 · Foundation (yours)
Sponsor / licence · capital · scheme membership
BIN sponsor or licenceScheme depositInsurance
RiskIssuing capital + scheme deposits define program ceiling
The canonical journey

Issue, activate, control, dispute — all one journey definition.

A user requests a new card in your product. Klyqo orchestrates the full lifecycle from issuance through dispute resolution. The state machine lives in the journey definition, the vendor calls live in the bindings, and every state transition lands in the audit log.

klyqo / journeys / card-lifecycle · LIVE
01
Card requesteduser action · eligibility check inline
< 1 s
02
Virtual card issuedMarqeta / Stripe Issuing · sent to wallet
~5 s
03
Activation + wallet provisioningApple/Google Pay push provisioning
~15 s
04
Controls configuredlimits, MCCs, channels, geo applied
user-driven
05
Authorization streamscheme → issuer → Klyqo policy → decision
< 200 ms / auth
06
Dispute initiated (if needed)in-app flow → Chargehound → representment
days to weeks
07
Lifecycle eventlost / replaced / terminated · per scheme rules
< 1 min
The providers used

What you pick from the marketplace.

A card issuance program uses six marketplace providers. Issuer selection is the biggest decision; Klyqo’s issuer adapters normalize the API differences so swapping is a binding change, not a re-build.

Issuance · processor
Marqeta / Stripe Issuing / Lithic
Pick by geography + scheme + cost. Klyqo normalizes the processor API.
In flight
Network · scheme
Visa / Mastercard
Sponsor-level membership; Klyqo handles network-specific message formats.
Roadmap
Fraud · real-time
Sift / Sardine
Sub-100ms scoring on every authorization. Per-merchant + per-cardholder.
Roadmap
Disputes · lifecycle
Chargehound
Automated representment for clear-cut cases; operator workflow for the rest.
Roadmap
Wallet · provisioning
Apple Pay / Google Pay
Push provisioning at issuance. Re-provisioning on replacement.
Roadmap
Sponsor / issuer of record
(varies)
Sponsor bank or your own issuing licence. Klyqo adapts to the sponsor’s shape.
Roadmap
What this blueprint is and isn’t

Honest about the build.

The work this blueprint represents

Card programs look like a card and feel like a state machine with 30 transitions. The work is in the disputes lifecycle (every chargeback path has scheme-specific rules), the controls (every limit type touches the processor in a slightly different way), and the wallet provisioning (Apple Pay and Google Pay have different push-provisioning quirks). Klyqo doesn’t make these easier; it makes them swappable.

What you bring: the BIN sponsorship (or your own issuing licence), the cardholder base, the program economics, the compliance officer. What Klyqo brings: the runtime, the issuer adapters, the disputes lifecycle templates, the controls model, the wallet provisioning flows. What we figure out together: which issuer for your geography + cost profile, which fraud vendor for your transaction shape, what controls surface lands with your buyer.

If you’re launching a card-first product and you want flexibility on the issuer for the next decade: talk to us before you marry one and have to redo the integration when their pricing changes.

Launching a card program?

If you’re building a card-first product — rewards, expense, gig payroll, neobank — the first conversation is short. Tell us about the geography, the BIN arrangement, the program economics, the cardholder profile. We’ll tell you which issuer + fraud + disputes combo fits and how fast Klyqo can wire it.

Email diogo@klyqo.com Response within two business days