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.

Prepaid is a different regulatory animal

Everything above applies to a prepaid programme as much as to a debit or credit one — the fulfilment, provisioning, controls, lifecycle and dispute mechanics do not change because the funds are pre-loaded. What does change is the compliance regime sitting on top, and it changes enough that a team porting a debit playbook onto a prepaid programme will get four things wrong in sequence. This section covers only what is specific to prepaid in the US; the operational scaffolding is the rest of this article.

The definition is broader than "the card says prepaid on it"

Regulation E, at 12 CFR 1005.2(b)(3), reaches four categories: payroll card accounts, government benefit accounts, anything "marketed or labeled as 'prepaid'" and redeemable at multiple unaffiliated merchants or at ATMs, and — the catch-all most teams miss — any account issued on a prepaid basis or capable of being loaded with funds thereafter whose primary function is transacting with multiple unaffiliated merchants, at ATMs, or person-to-person, and which is not a checking, share draft or NOW account.

That last limb is what pulls a good deal of fintech product into the prepaid regime without anyone having called it a prepaid card. The named exclusions are narrow: HSA/FSA/dependent-care and transit-reimbursement accounts, qualified disaster-relief accounts, the P2P function of closed-loop military accounts, gift products governed by 1005.20, and needs-tested government benefit accounts established under state or local law or administered by a state or local agency.

The disclosure regime is prescriptive, not principles-based

1005.18(b) mandates a short form and a long form, and the short form is a specified fee tile with specified terminology — periodic fee, per-purchase fee, two-tier ATM withdrawal fee, cash reload fee inclusive of third-party charges, two-tier balance-inquiry fee, two-tier customer service fee, inactivity fee with its trigger, a count of additional fee types, the two highest-revenue additional fee types, an overdraft/credit statement, an insurance-and-registration statement, and pointers to the CFPB and to the long form.

The registration-status statement has five prescribed variants keyed to whether the programme is insurance-eligible and whether identity verification happens before acquisition. At the unverified end, the required text is blunt: "Treat this card like cash. Not [FDIC] [NCUA] insured." The long form carries every fee with its imposition, waiver and reduction conditions — and explicitly bars using asterisks to explain those conditions.

The provision with the most commercial consequence

This is the one to read twice. Under 1005.18(e)(3), an institution is not required to comply with the Reg E liability limits and error-resolution requirements "for any prepaid account for which it has not successfully completed its consumer identification and verification process."

Read the scope carefully, because it is narrower than it first looks and the boundary is where programmes get into trouble:

• It applies to general prepaid accounts, and it is conditioned on disclosure — the institution must tell the consumer about the risk and must actually follow whatever verification process it has disclosed.
• It covers three distinct states, and they do not share a disclosure route. Where verification has not yet concluded or has concluded unsuccessfully, the prescribed Appendix A-7(c) model notice applies. Where the programme has no verification process at all, the requirement is different — under 1005.18(d)(1)(ii) the institution must describe its error-resolution process and liability limits, or state that there are none. Building one notice for all three states gets the third one wrong.
• It does not reach payroll card accounts or government benefit accounts. Neither is ever subject to the unverified-account carve-out, whatever their verification status. Read that as "not carved out" rather than "identical to a plain debit account": government benefit accounts run on their own modified timing regime at 1005.15(e), parallel to the prepaid one below. A programme that treats "prepaid" as one compliance bucket and applies the unverified carve-out across it will be applying it unlawfully to two of the four categories in the definition.

There is also a timing choice worth making deliberately rather than inheriting. Where a verified account uses transaction history in place of periodic statements, 1005.18(e)(1)–(2) offers two alternative compliance methods, not one rule with a ceiling: a 60-day window measured from account access or delivery of a written history, or — as an alternative safe harbour requiring no access tracking at all — a flat 120-day window measured from the transaction date. The second is materially cheaper to operate and is the reason the first is often not worth building.

Gift cards are a different subpart, not a lighter version of the same one

1005.20 governs gift certificates, store gift cards, and general-use prepaid cards marketed as gift cards. It sets its own narrower rules — a dormancy fee only after twelve months of inactivity, no more than one such fee per month, and a minimum five-year expiry — and it conspicuously does not extend periodic-statement, error-resolution or liability protections. A multi-merchant reloadable card that is not marketed as a gift card falls back into 1005.18 instead. The marketing copy, in other words, selects the regulatory regime.

FDIC pass-through insurance is conditional, and the conditions are where programmes fail

"FDIC-insured" on a prepaid programme means pass-through insurance under 12 CFR 330.7(a): funds owned by principals and deposited in the name of an agent or custodian are insured as if deposited by the principals. Two conditions gate it.

First, disclosure in the bank's records: 330.5(b)(1) recognises a fiduciary-relationship claim "only if the relationship is expressly disclosed, by way of specific references, in the 'deposit account records'" of the institution.

Second, ascertainable beneficial ownership: 330.5(b)(2) requires the details and the interests of other parties to be determinable "either from the deposit account records of the insured depository institution or from records maintained, in good faith and in the regular course of business, by the depositor or by some person or entity that has undertaken to maintain such records for the depositor." The practical reading matters — the beneficial-owner ledger does not have to live at the bank. It can sit with the programme manager or processor. But it has to exist, be kept contemporaneously in the ordinary course, and be producible on demand. A reconstruction after a failure is not what the rule contemplates.

Since January 2024 there is a sharper edge on the marketing side. Under 12 CFR 328.102(b)(5)(iv), a statement about pass-through coverage "that fails to clearly and conspicuously disclose that certain conditions must be satisfied" is itself a material omission and a violation — and Part 328 reaches any person making the representation, not only banks. Marketing "FDIC-insured" without the conditions is now the violation, independent of whether the conditions happen to be met.

Escheatment is state law, and there is no federal rule

There is no federal escheatment or unclaimed-property regime for prepaid balances. The CARD Act provision at 15 U.S.C. 1693l-1 is frequently mistaken for one; it is not. It sets a floor on fees and expiry only — no dormancy, inactivity or service fee unless there has been no activity for twelve months and disclosure conditions are met, no more than one such fee per month, and no expiry earlier than five years from issuance or last load. It says nothing about abandonment or reporting.

Abandonment is fifty separate answers, and they differ in mechanism, not just in duration. Delaware runs a dormancy clock: 12 Del. C. § 1133(14) presumes a stored-value or gift card abandoned five years after the later of purchase, load, balance verification or last indication of interest, with the amount unclaimed measured as the issuer's maximum cost of the underlying goods or services. California reaches the opposite outcome by a different route: because Civil Code § 1749.5 bans expiration dates and most dormancy fees outright, Code of Civil Procedure § 1520.5 leaves compliant gift certificates outside the unclaimed-property regime entirely — they do not escheat at all, rather than escheating late. Only non-compliant certificates carrying an expiration date fall back to the general three-year presumption.

Two states, two mechanisms, opposite results. Budget for per-state analysis rather than a dormancy-period lookup table.

Reg II: exempt from the cap, not exempt from Regulation II

Prepaid interchange economics differ sharply from debit, and this is why — with one caveat that applies to everything in this subsection. Regulation II is itself under active legal challenge. A North Dakota district court vacated it in full in August 2025 in Corner Post, Inc. v. Board of Governors, stayed its own ruling, and the Federal Reserve's appeal has been before the Eighth Circuit since. Everything below is the rule as currently in force, which the stay preserves; the interchange regulation by market reference tracks the litigation. 12 CFR 235.5(c) exempts from the interchange fee standard a general-use prepaid card that is not issued to access any other account of the cardholder, is reloadable and not marketed or labelled as a gift card, and is the only means of access to the underlying funds — except where all remaining funds are provided to the cardholder in a single transaction, which the rule expressly permits.

That exemption is clawed back by 235.5(d) if the card can carry an overdraft fee, or a fee for the first monthly in-network ATM withdrawal. A programme that monetises either loses the exemption and falls under the standard cap — which makes the fee schedule a pricing decision with an interchange consequence attached, not just a revenue line.

One distinction is routinely overstated in the other direction. The exemption names only §§ 235.3, 235.4 and 235.6 as inapplicable. It does not reach § 235.7, the network-exclusivity rule, which still requires that an electronic debit transaction be processable on at least two unaffiliated networks. Exempt prepaid programmes get uncapped interchange and still carry the dual-routing obligation. "Prepaid is outside Durbin" is wrong in a way that shows up during network negotiation.

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.