Issuing Programme Operations: Running a Card Programme Day to Day

Every card programme article that starts with BIN sponsorship stops at the same point: the sponsor is signed, the processor is chosen, the program manager relationship is live. Then the programme has to actually run — cards get produced, tokens get pushed into wallets, spend controls get configured, cardholders dispute charges, a sponsor account needs funding every settlement cycle, and someone has to explain to an auditor why the fraud rate moved. That's a different job from structuring the deal, done by different people, on a different clock, and it's where most of the operational risk in a card programme actually lives.

Scope note. Card issuing and BIN sponsorship owns programme setup and structure — what BIN sponsorship buys, who the issuer-processors are, who is legally the issuer of record, how the economics and liability are structured, and the contract terms that decide your exit. This article picks up after that structure exists and covers running it: production, provisioning, controls, lifecycle, disputes, fraud, funding, and the metrics that tell you whether the programme is healthy. Where a topic is genuinely about structure or liability doctrine rather than day-to-day operation, this article links back rather than repeating it.

The operating roles: who is accountable for what

Visa's own partner-type framework draws four roles, and getting the operational boundary between them wrong is the single most common mistake operators make once a programme is live. The BIN sponsor is the issuing bank: it "holds cardholder funds, and takes on the role of managing risk and local country regulations." The issuer-processor is the operator's "direct connection to the issuing bank and networks" — it keeps the system of record, manages issuance, authorises transactions, and communicates with settlement entities. The programme manager "oversees your card program on the issuing bank's behalf," running relationships, marketing, and day-to-day profitability, and is typically the party actually managing the programme through its lifecycle.

The trap is treating operational proximity as accountability. The programme manager and issuer-processor are who an operator talks to every day — support tickets, dispute queues, spend-control changes all run through them. None of that moves legal or regulatory accountability off the sponsor. When a regulator or a scheme asks who is responsible for a fraud pattern or a mishandled dispute, the answer is the entity whose name sits on the scheme membership, not whichever vendor's dashboard the operator uses daily. Card issuing and BIN sponsorship covers why liability sits there, under Regulation E and the interagency CIP guidance that treats a programme manager as the bank's agent, not its customer — this article assumes that boundary and builds the operational playbook on top of it. Build every runbook here around the assumption that the sponsor can demand visibility into it, because it eventually will.

Card production and personalisation: virtual first, physical on demand

Most modern programmes issue virtual cards as the default and physical cards as a deliberate, separate decision, because a virtual card exists the moment it's created — no fulfilment vendor, no shipping, no waiting for plastic before the programme can transact. Physical production runs through dedicated fulfilment partners: Marqeta's documentation lists regional print and personalisation vendors — IDEMIA, Perfect Plastic Printing, Arroweye Solutions, CPI, and G+D among others — each with fixed daily order cutoffs (09:00 UTC for Perfect Plastic Printing and Arroweye, 23:00 UTC for IDEMIA) feeding a production run that typically reaches a "shipped" status roughly three to four days after the order is placed, before carrier transit time is added on top. That production-to-ship window is a fixed cost every physical card carries that a virtual card doesn't — worth weighing against whichever use case actually needs plastic (in-person spend, ATM access) rather than defaulting to it out of habit.

Personalisation itself is mostly configuration, not manual work: card products carry branding, colour, and print specifications set once per product, with individual cards embossed or printed against a serial or named pattern (Marqeta gives the example of a static prefix plus enumeration, like "Driver 01," "Driver 02"). The decision that matters more than the artwork is which fulfilment partner and cutoff schedule the programme commits to, since that schedule sets how fast an operator can replace lost or damaged physical inventory at volume — covered below under lifecycle.

Token provisioning: getting a card into a wallet

Provisioning is the process of getting a card's credentials into Apple Pay, Google Pay, or Samsung Pay — either the cardholder manually adding it in the wallet app, or an issuer pushing it in directly from their own banking app ("in-app" or "push" provisioning). Visa's own developer documentation for this flow names the two friction points that matter operationally: "yellow-path token step-up authentication" and "manual CVV2 entry." A provisioning attempt that clears cleanly is on the "green path"; one that needs additional identity verification before Visa or the issuer completes the tokenisation is "yellow path" — Visa's own term for exactly this scenario. Visa's documentation states that provisioning through its in-app SDK route can avoid the yellow-path step-up requirement; the same documentation separately describes the SDK running device and token eligibility checks before the wallet request is sent. Visa doesn't spell out the mechanism connecting the two, so treat it as the SDK's general design intent rather than a documented causal chain.

The operational consequence: a card that fails to provision and a card that stalls on yellow path and never gets completed look identical in a naive success/failure metric, but they're different problems — one a rejection, the other an abandoned flow. Do not invent a target provisioning success rate — Visa does not publish one, and it varies by issuer, market, and wallet. Build a funnel instead: attempts, green-path completions, yellow-path triggers, and yellow-path completions, tracked separately, so a drop in "cards in wallets" can be diagnosed as a rejection problem or a step-up abandonment problem before deciding what to fix. The deeper architecture question — whether the credential is a network token or a PSP-managed token, and how that plays out for tokenization — is covered from the merchant side in network tokens vs PSP tokens; this section is about the issuer-side act of getting a credential into a digital wallet in the first place. What happens to that credential once it's stored — expiry, reissue, PSP portability — is covered from the acquiring side in card credential lifecycle and Account Updater operations; the lifecycle section below is the issuer-side mirror of those same events.

Authorisation and spend controls

Every authorisation against an issued card should hit a spend-control layer before anything resembling a fraud model, because spend controls are deterministic and cheap to evaluate, while fraud scoring is probabilistic and comparatively expensive. Two processors' documentation give a concrete sense of what that layer looks like in production. Stripe's Issuing spending controls block by MCC category, merchant country, merchant ID, or card presence, and set spending limits per authorisation or over a rolling interval; an unconfigured card still isn't unlimited — Stripe applies a default $500-per-day limit if no spending_limits are set, plus an unconfigurable $10,000-per-authorisation ceiling regardless of other controls. Marqeta's velocity controls run the same idea with different vocabulary: an amount and/or usage (transaction-count) limit inside a velocity window of day, week, month, lifetime, or per-transaction, layered with MCC allow/deny rules, applicable at the program, card-product, or individual-cardholder level, with spend across a cardholder's multiple cards counted cumulatively.

Geographic controls follow a similar pattern at the network level: Visa Transaction Controls lets a cardholder block international transactions entirely or allow purchases only from selected countries, alongside turning the card fully on or off — a control that doubles as instant blocking, covered below. The point that gets missed: spend controls and fraud rules are not the same layer and shouldn't be tuned together. A velocity limit that's too tight produces false declines on legitimate spend spikes; one that's too loose does nothing to stop the fraud pattern a real-time risk model would have caught. Tune each independently, and instrument declines by which layer produced them — a control-layer decline and a risk-layer decline are different problems with different fixes.

Card lifecycle: activation, replacement, reissue, expiry, and portfolio conversions

A card's usable life runs through predictable stages, each with a slightly different mechanic depending on why it's happening. Activation gates use — Stripe's model requires a card's status to be active before authorisations can be approved, and physical cards are generally recommended to stay inactive until the cardholder actually receives them, so a card lost in transit can't be used. Replacement splits by cause: Stripe distinguishes lost/stolen replacement, which issues a new card number, security code, and expiry date (the original must be cancelled first), from expired or damaged replacement, which keeps the same card number but issues a new security code and expiry date, letting the cardholder keep using the original until the replacement activates. That distinction matters for card-on-file continuity: Stripe automatically pushes updated card-on-file details to acquiring merchants for expiry/damage replacements, but deliberately not for lost/stolen ones, since a merchant who already has the old (compromised) number shouldn't be handed the new one automatically.

Reissue is the issuer-initiated version of the same event — typically triggered by a fraud signal or a BIN-level security concern rather than the cardholder reporting anything. Portfolio conversions and BIN migrations are the same mechanic at a much larger scale: when a sponsor bank sells a card book, migrates processors, or an operator moves BINs, an entire range of cards gets reissued at once rather than trickling in gradually. Neither Account Updater nor network-token propagation is built around this as a special case — both process a portfolio conversion the same way they'd process any other reissue, just at a volume that can outrun their normal catch-up cadence, producing a correlated spike in stale-credential declines concentrated in one BIN range. The mitigation isn't prevention — a migration can't be un-triggered once decided — it's sequencing: stagger the reissue where sponsor and scheme rules allow it, pre-notify cardholders before old cards stop working, and expect a support-volume spike sized to the migration, not the programme's steady-state baseline. Card credential lifecycle and Account Updater operations covers what a BIN migration does to the acquiring side of the same stored-credential base.

Card status management and instant blocking

Every major issuer-processor exposes a small set of card states, and the operational leverage sits almost entirely in how fast an operator can move a card between them. Adyen's model runs four statuses — inactive, active, suspended, and closed — where suspension is explicitly a temporary, reversible block on processing (set the status back to active to resume), while closure is explicitly permanent and irreversible. That distinction is the point of instant blocking as a tool: a cardholder who reports a card missing needs it suspended in seconds, not closed, because "missing" often resolves itself and a permanent closure forces a full replacement cycle for what might have been a false alarm. Reserve closure for confirmed loss, theft, or fraud.

Some blocking is automatic rather than operator-triggered. Adyen, for instance, automatically blocks a card from further 3D Secure attempts after five consecutive failed authentications — a PSD2/Strong Customer Authentication requirement — lifting the block after an hour, or sooner if the support team verifies the cardholder's identity directly. Visa Transaction Controls gives the cardholder their own version of the same lever: turning the card fully on or off from a banking app without contacting support — instant, cardholder-initiated, and reversible. Build instant blocking into the cardholder-facing app wherever the UX allows it; the fastest fraud response is the one that doesn't wait for a support queue.

Issuer-side dispute operations

This is the discipline operators most often confuse with merchant-side chargeback representment, and it runs in the opposite direction. Merchant-side chargeback representment defends a business against a claim an issuer has already filed. Issuer-side dispute operations are upstream of that: the cardholder brings a complaint to the issuing programme, which has to decide whether to file a dispute against the acquiring merchant, gather evidence, and submit within a scheme deadline that varies by reason. Stripe's implementation of Visa's rules shows how tight those windows are: most fraud and processing-error disputes must be filed within 110 days of the transaction, authorisation disputes within 65 days, and most consumer disputes within 110 days of the expected delivery or cancellation date; Mastercard requires authorisation, incorrect-amount, and duplicate disputes within 80 days. A dispute can be filed only once, with no later edits or supplemental evidence — get it right the first time or lose the claim on a technicality.

The workflow, per Adyen's and Galileo's documentation, moves through a consistent shape regardless of processor: a dispute is drafted, submitted to the scheme, the acquiring merchant is notified and has a window (roughly 30–45 days, scheme-dependent) to accept liability or counter with evidence, and the case resolves in the issuer's favour (chargeback) or the merchant's (second presentment, potentially arbitration). Where Regulation E applies — debit disputes in the US — the issuer has 10 days to investigate before owing provisional credit, extendable to 45 or, for certain transaction types, 90 days; cardholders generally have 60 days post-statement to raise a dispute. That clock is set by the network and the regulator, not negotiable with the cardholder, and the issuer's own speed at collecting evidence determines whether a winnable case is won or lost on a missed filing window.

At scale, Visa's own resolution infrastructure does a meaningful share of this automatically: Visa Resolve Online (VROL) auto-assigns case liability for roughly 80% of disputes on Visa transactions, leaving the remaining fifth as genuinely contested cases needing an analyst's judgment. Tools like Visa's Order Insight, which shares digital receipt data with issuer call centres so a cardholder can be shown "you did buy this" before a dispute is filed, exist because a meaningful share of disputes start as recognition failures — Visa cites 35% of cardholders mistakenly flagging a legitimate transaction as fraudulent, and 41% of debit cardholders saying they're less likely to reuse a card after a dispute. The lesson: the cheapest dispute is the one prevented at the call-centre stage, not the one won after filing.

Fraud controls and the false-decline trade-off

Every fraud rule an issuer tightens trades two error types against each other: too loose lets bad transactions through; too tight declines legitimate cardholders and calls it a win. The second failure mode is harder to see in a dashboard, because a false decline doesn't generate a chargeback or a loss line — it just looks like a normal decline, indistinguishable from a genuinely risky transaction the system correctly stopped, unless the programme instruments for it specifically. This is the trade-off Adyen's own authorisation architecture manages in real time: internal checks (card expiry, CVC, available balance) run alongside custom transaction rules and, where the issuing platform wants final say, relayed authorisation — a real-time webhook to the operator's own servers that must return an approve/decline decision within 2000 milliseconds, fast enough to sit inline in the authorisation flow unnoticed.

What that infrastructure enables — richer transaction context before deciding — is the same lever a recent Marqeta/Riskified case study illustrates, with the appropriate caveat attached. Over a 30-day window, an unnamed "top-tier U.S. card issuer" using merchant-side risk data in Marqeta's Real-Time Decisioning product reported authorisation-rate gains of 5.9%, 1.4%, and 1.6% across ticketing, gaming, and retail merchants respectively, and a 25% reduction in false declines with certain merchants. Treat that as one vendor-reported example of the trade-off's shape, not a benchmark — no baseline volume or authorisation rate was disclosed, and it covers one issuer over one month. Do not adopt a false-decline reduction target from someone else's case study. Build your own instrumentation instead: track declines by reason code so a stale-credential or issuer-side risk decline is visible as its own category, distinct from a genuine insufficient-funds or fraud-confirmed decline — the same soft-decline-versus-hard-decline distinction that matters on the acquiring side, just decided by the issuer here. Only once that instrumentation exists does a false-decline number mean anything, measured against your own baseline, not someone else's press release.

Settlement and funding

Card issuing programmes are generally prefunded, not post-paid: the operator holds a balance with the issuer-processor (or the sponsor, depending on structure) ahead of spend, and authorisations draw against it in real time. Stripe's own funding documentation states the mechanic plainly — to avoid insufficient-funds declines, the account needs enough in its Issuing balance before the spend happens, not after. That's the structural difference from a traditional credit relationship: a shortfall doesn't generate an invoice or a grace period, it generates declines at the point of sale, in front of the cardholder — a materially worse failure mode than a delayed settlement file.

Funding mechanics vary by rail and region. In the US, Stripe's default is a pull-funded top-up from an external bank account, which can take up to 5 business days to land; in the UK and Europe, the default flips to a push-funded top-up, with settlement timing depending on which payment rail carries it. Where the operator already runs payments through the same provider, balance transfers from an acquiring balance into the issuing balance settle far faster — instantly in the US, within a business day in the UK/Europe for Stripe specifically. The implication is a treasury one as much as a payments one: whichever funding rail is slowest sets the floor for how much buffer balance the programme needs to avoid a shortfall-driven decline spike, and that buffer is itself a cost — capital sitting in a non-interest-bearing balance rather than deployed elsewhere. A rolling reserve-style buffer against spend volatility should be sized against the slowest funding path the programme actually uses, not the fastest one available in theory.

Scheme compliance and monitoring from the issuer's seat

Two obligations sit specifically with an issuing programme rather than being inherited automatically from the sponsor bank's licence. The first is dispute-and-fraud reporting into the scheme's own resolution infrastructure — VROL for Visa, as covered above — which makes the programme's dispute-ops team a direct participant in scheme-level case management, not merely a data source the sponsor queries. The second is PCI DSS scope, which extends to every entity in the chain that stores, processes, or transmits cardholder data, not just the sponsor bank; Card issuing and BIN sponsorship covers the annual-validation obligation this creates for issuers directly connected to the network, and it applies to the issuer-processor and programme manager layers in practice, not just the licence-holder.

Beyond the scheme's own infrastructure, the sponsor bank's own audit and monitoring cadence is where most of a programme's actual reporting burden lands day to day — not because the scheme demands a specific report format from the operator directly, but because the sponsor, which does answer to the scheme and its own regulator, needs the programme's numbers to answer for it. Build the reporting pack the sponsor will ask for before being asked: transaction volume and mix, dispute and fraud rates against the programme's own baseline, spend-control override frequency, and incident log entries with resolution times. A sponsor that has to chase an operator for this data treats the friction itself as a risk signal, independent of what the numbers say.

Portfolio health: cost per active card, activation, and breakage

Card issuing and BIN sponsorship covers the revenue side of programme economics in depth — interchange as a revenue line, gross vs. net interchange revenue-share structures, and how sponsor bank size changes the number. This section is the operating-cost mirror of that: the metrics that tell an operator whether the programme's cost base is healthy, independent of what it earns per transaction.

Cost per active card, not cost per issued card, is the number to run the programme against. A card issued but never used still carries whatever per-card platform fee the issuer-processor charges, whatever fulfilment cost went into producing it if physical, and whatever support overhead comes from a cardholder wondering why it doesn't work. Dividing total programme cost by issued-card count flatters a programme that's been issuing cards without a matching activation push; dividing by active cards (spending within a defined recent window, chosen deliberately and applied consistently) tells the truer story.

Activation rate — the share of issued cards ever used at all — is the leading indicator that a card-count growth number is hollow. A programme growing issued cards 20% quarter over quarter while activation rate falls is manufacturing a worse cost-per-active-card number even as its headline metric looks healthy. Breakage — funds loaded, authorised, or reserved against a card that are never actually captured or spent — matters specifically for prepaid and gift-style programmes, where unclaimed balances are a real (if regulatorily constrained) source of margin, and should be modelled deliberately rather than discovered in a finance reconciliation months later. None of these three numbers has an industry-standard target this article will assert — cost structures and cardholder bases vary too much for a borrowed benchmark to mean anything. Compute all three against the programme's own trend line, and treat a sustained adverse move as the trigger for investigation, not the absolute level.

Operational KPIs, incident management, and sponsor oversight

Pull the metrics from every section above into one operating dashboard rather than leaving them scattered across the processor's, programme manager's, and sponsor's separate views: provisioning funnel completion (green-path vs. yellow-path), spend-control decline rate by control type, dispute win rate and average time-to-file relative to the scheme deadline, false-decline rate against the programme's own baseline, funding buffer days-of-cover against the slowest funding rail in use, and the three portfolio-health numbers above. A programme that can't produce this set on demand is flying on whatever its processor's default dashboard surfaces, which is rarely the shape a sponsor's audit actually asks for.

Incident management deserves its own runbook, not an ad hoc response the first time something breaks: a defined severity scale (a single card compromised vs. a BIN-wide reissue vs. a processor outage affecting live authorisations), a clear escalation path naming who calls the sponsor and at what threshold, and a post-incident review that feeds back into the KPI set above rather than living only in a support ticket. Sponsor oversight is not adversarial by default, but it is real: expect scheduled audit requests, expect the sponsor's risk appetite to shift deal terms if volume, MCC mix, or dispute/fraud rates move materially, and expect that the fastest way to damage the relationship is a bad metric the sponsor discovers before the operator reports it. Surface the numbers proactively; that habit does more for the relationship than any single KPI improving.

What to read next

Card issuing and BIN sponsorship is the structural companion to this article — BIN sponsorship mechanics, the issuer-processor landscape, liability doctrine, program economics, and contract terms, all upstream of the operations covered here. Card credential lifecycle and Account Updater operations covers what happens to a stored credential — including one provisioned through this article's token flow — from the acquiring/merchant side once it's in a vault. Network tokens vs PSP tokens is the deeper architecture comparison behind the provisioning section above, and chargeback representment for merchants is the mirror-image discipline to this article's issuer-side dispute-operations section, run from the opposite side of the same case. VAMP: Visa Acquirer Monitoring Programme covers the acquirer-side equivalent of the scheme-level monitoring this article's compliance section addresses from the issuer's seat. Multi-entity, multi-MID payment architecture covers the merchant-account structure question for operators who also acquire, alongside issuing, across brands or entities.