Card issuing: sponsor, processor and programme manager explained

Card issuing is not a single service. Launching a card programme means coordinating several distinct organisations and systems: the issuer that holds scheme membership, the BIN sponsor whose licence you may use, the processor that runs authorisations, and the programme manager that ties the commercial and operational pieces together. Each performs a different legal and operational role, and confusing them is one of the most common early mistakes. This guide explains who does what, how a transaction flows, where the money and the costs sit, and what to confirm before you commit.

Legal and regulatory status was reviewed on 7 July 2026.

Card programme ecosystem overview

A card programme is a chain of participants: the cardholder, the merchant, the acquirer on the merchant side, the card network, and the issuing side (issuer, BIN sponsor, processor, programme manager) on your side. Payment services and electronic money activity sit within a regulated framework, and the participants that hold permissions carry the associated obligations 1. Before evaluating any vendor, write down which of these roles you intend to outsource and which you will hold yourself. A provider may offer several roles at once, but that does not merge them — the responsibility map stays the same.

Card network or scheme

The card network (scheme) operates the rails that route authorisation, clearing and settlement messages between issuing and acquiring sides, and it sets the rulebook that participants must follow. The network does not “issue” your cards; it licenses members and enforces standards. Programme features, card ranges (BINs), and permitted use cases are governed by scheme rules, and material changes usually require scheme approval. Treat the scheme rulebook as a hard constraint on what your programme can and cannot do.

Issuer and BIN sponsor

The issuer is the regulated entity that issues cards to cardholders and carries the associated liabilities within the scheme. A BIN sponsor is an issuer (or scheme member) that lets your programme operate under its Bank Identification Number range and membership when you do not hold your own. These are related but not identical: not every partner that touches your cards is an issuer or BIN sponsor. A processor, for instance, is neither. Confirm exactly which legal entity issues the cards, which BIN range you use, and whether it is the sponsor’s or your own.

Issuer processor

The issuer processor runs the real-time systems that authorise transactions, apply spending controls, maintain card state, and expose the issuing API you build against. Many fintech “card APIs” are processor APIs. A processor is a technology role: strong processor capabilities do not make a company an issuer or a BIN sponsor, and you should not assume the processor holds scheme membership. Evaluate authorisation latency, uptime, control granularity, and how the processor coordinates with your ledger.

Programme manager

The programme manager coordinates the commercial and operational programme: it manages the relationship between you, the issuer/sponsor, the processor and other vendors, and often handles compliance operations, dispute handling and scheme reporting. Some providers combine programme management with issuing, processing or both. Bundling can simplify contracting, but ask the programme manager to state, in writing, which regulated entity performs each function so accountability stays explicit.

Ledger and account infrastructure

Cards move money, so a programme needs an accounting system of record for balances, authorisations, holds and postings. This ledger may be provided by the processor, by a separate core-banking or ledger system, or built in-house. Whichever model you choose, define how an authorisation places a hold, how a cleared transaction posts, and how reversals are recorded. See core banking versus ledger versus payment hub for how these layers differ.

Card manufacturer and personalisation bureau

Physical cards require a manufacturer and a personalisation bureau that encodes and prints each card and manages secure fulfilment. This introduces lead times, minimum order quantities, stock management and logistics for replacements. Virtual-only programmes avoid this entirely. If you plan physical cards, factor bureau onboarding and scheme design approval into your timeline early.

Token service provider and mobile wallets

A token service provider replaces the real card number (PAN) with a token for card-on-file and wallet use. Mobile wallet provisioning depends on the issuer, processor and network all supporting it. Wallet acceptance is never automatic and is subject to the wallet operator’s own requirements. The mechanics are covered in detail in 3-D Secure, tokenisation and mobile-wallet provisioning.

3-D Secure infrastructure

3-D Secure is the protocol used to authenticate the cardholder for certain transactions, especially online. Strong customer authentication requirements for payment transactions are set out in EU delegated legislation, and 3-D Secure is a common way to meet them 3. Your programme needs an access control server (ACS) capability, usually supplied by the issuer or processor. Authentication design affects fraud rates and customer experience, so treat it as a first-class part of the programme, not an afterthought.

KYC, AML and fraud systems

Cardholder onboarding, ongoing monitoring, sanctions screening and fraud detection are integral to a card programme. Using a vendor’s tools does not transfer the regulated entity’s legal responsibility for these controls. Design how identity verification, screening and transaction monitoring connect to card events, and align the split of duties in a written responsibility matrix — see KYC, KYB and transaction-monitoring architecture.

Authorisation flow from card tap to response

A single authorisation touches most of the chain:

1. The cardholder taps or enters card details at a merchant.
2. The acquirer sends an authorisation request through the network.
3. The network routes it to the issuer/processor.
4. The processor checks controls, balance and fraud rules, places a hold on the ledger, and (where required) triggers authentication.
5. An approve or decline response returns along the same path.

This happens in well under a second. Every participant in the path is a potential point of latency or failure, which is why uptime and clear operational ownership matter.

Clearing and settlement

Authorisation only reserves funds; clearing exchanges the final transaction records and settlement moves the actual money between scheme participants. Settlement timing, funding obligations and scheme reporting are governed by network rules. Understand when your programme must fund settlement, how settlement files reconcile against your ledger, and who is accountable when they do not match.

Funding and prefunding models

Programmes differ in how they fund spending. A prefunded model requires you (or the cardholder) to hold a balance before authorisation. Other models extend a settlement window or a credit line. Funding terms shape working capital, so confirm reserve requirements, prefunding accounts and top-up mechanics before signing.

Chargebacks, disputes and representment

When a cardholder disputes a transaction, scheme dispute rules govern the process: chargeback, representment (the merchant/acquirer response) and possible arbitration. On the issuing side you must handle disputes within scheme timeframes, maintain evidence and manage cardholder communication. Dispute operations are labour-intensive and are frequently underestimated. Clarify who runs disputes — you, the programme manager or the processor — and against which service levels.

Physical versus virtual cards

Virtual cards can be issued instantly and suit online, single-use and just-in-time funding scenarios. Physical cards add manufacturing, personalisation, logistics and replacement flows. Many programmes offer both. Choose based on your use case rather than defaulting to plastic, and remember that physical fulfilment lengthens the launch timeline.

Consumer, commercial and prepaid distinctions

Consumer, commercial (business) and prepaid cards are distinct product types with different scheme rules, cardholder expectations and, in some cases, different interchange treatment. The distinctions affect eligibility, controls and economics, so define your product type early — it constrains BIN selection and sponsor conversations.

Bundled versus modular programmes

A bundled provider supplies issuing, processing, programme management and sometimes the ledger under one contract. A modular approach lets you assemble best-fit components but requires you to integrate and coordinate them. Bundling reduces integration effort and vendor count; modularity increases control and portability. Neither is universally better — the right choice depends on your team, roadmap and tolerance for lock-in.

Programme economics

Card economics are made of several distinct cost and revenue lines. Model them separately rather than as one blended “per-card” number.

Processing charges

Fees charged by the processor for authorisation, transaction processing, API usage and platform access. Often a mix of per-transaction and fixed platform fees.

Scheme charges

Fees the network levies on participants for membership, transactions and assorted services. These are set by the scheme and passed through the chain.

Sponsorship

If you use a BIN sponsor, expect sponsorship and programme fees for use of their membership and oversight. These reflect the sponsor’s regulatory responsibility.

Manufacturing

For physical cards: card stock, personalisation, packaging and delivery, plus minimum order quantities and replacement costs.

Tokenisation

Token service and wallet provisioning may carry their own fees, depending on the provider and volumes.

Fraud and disputes

Fraud tooling, chargeback handling and potential losses. Interchange for certain card-based transactions is regulated in the EU, which affects the revenue side of card economics and should be understood rather than assumed 2.

Launch sequence

A realistic sequence usually runs: define product and card type → select scheme, sponsor/issuer and processor → secure programme approval → integrate processor and ledger → configure controls, 3-D Secure and fraud rules → complete compliance and testing → (for physical cards) design and personalisation approval → pilot → launch. Scheme and sponsor approval frequently sit on the critical path, so sequence them first.

• Product type and card form factor (physical/virtual) defined
• Scheme, issuer/BIN sponsor and processor roles confirmed in writing
• Regulated entity for each function documented
• Ledger, holds and posting behaviour specified
• 3-D Secure and fraud controls configured and tested
• KYC/AML responsibility matrix agreed
• Funding, prefunding and settlement obligations modelled
• Dispute and chargeback ownership and SLAs defined
• Programme approval and (if physical) personalisation approval scheduled
• Full economics modelled across processing, scheme, sponsorship, manufacturing and fraud

Provider responsibility matrix

Function	Typical owner	What to confirm
Scheme membership	Issuer / BIN sponsor	Which entity is a member, for which BIN
Card issuance	Issuer	Legal entity that issues to cardholders
Authorisation processing	Issuer processor	API scope, controls, uptime, latency
Programme coordination	Programme manager	Which functions it manages vs subcontracts
Ledger and balances	Processor / ledger / you	Holds, posting, reconciliation ownership
Physical fulfilment	Manufacturer / bureau	Lead times, minimums, replacements
Tokenisation / wallets	Token service provider	Wallet support and provisioning rules
Authentication (3-D Secure)	Issuer / processor	ACS provision and challenge design
KYC / AML / fraud	Regulated entity (accountable)	Written split of duties
Disputes and chargebacks	Programme manager / processor / you	Ownership and SLAs within scheme timeframes
Settlement funding	You / sponsor	Prefunding, reserves, settlement timing

Questions to ask providers

• Which regulated legal entity issues the cards, and which BIN range do we use?
• Are you the issuer, the BIN sponsor, the processor, the programme manager — or a combination?
• Which functions do you perform directly and which are subcontracted?
• How does authorisation work end to end, and what are your latency and uptime figures?
• How are holds, postings and reversals reflected in the ledger, and how does reconciliation work?
• Who owns disputes and chargebacks, and against which scheme timeframes and SLAs?
• What are the funding, prefunding and settlement obligations?
• What does scheme and programme approval require, and how long does it take?
• How is 3-D Secure provided, and how are fraud controls configured?
• What are the full costs across processing, scheme, sponsorship, manufacturing, tokenisation and disputes?

Common launch failures

• Treating a processor’s issuing API as if it made the vendor an issuer or BIN sponsor.
• Underestimating scheme and sponsor approval time on the critical path.
• Leaving dispute and chargeback operations undefined until after launch.
• Ignoring funding, prefunding and settlement timing until working capital is squeezed.
• Assuming wallet provisioning or physical fulfilment is fast and automatic.
• Blending all costs into a single per-card figure that hides scheme and sponsorship fees.
• Leaving KYC, AML and fraud responsibilities vague between the parties.

What this does not cover

This guide does not assess any specific provider, quote fees, or determine whether a programme is compliant for your business. It does not make a PCI compliance determination and does not confirm that any wallet will accept your cards. It complements — but does not replace — legal, regulatory and scheme-specific advice tailored to your programme.

FAQ

Is the card processor the same as the issuer?

No. The processor runs authorisation and card-management systems; the issuer is the regulated entity that issues the cards and carries scheme liabilities. A company can be both, but the roles are distinct and should be confirmed separately.

What is a BIN sponsor?

A BIN sponsor is a scheme member that lets your programme operate under its BIN range and membership when you do not hold your own. It is an issuing-side role with regulatory responsibility, not merely a technical service.

Do I need physical cards to launch?

No. Virtual cards can launch faster because they avoid manufacturing and fulfilment. Choose the form factor based on your use case; you can add physical cards later.

Who handles chargebacks and disputes?

It depends on your contracts. Disputes may be run by the programme manager, the processor or your own team, but they must be handled within scheme timeframes. Confirm ownership and service levels in writing before launch.

Does using an issuing platform transfer my compliance obligations?

No. Using a vendor’s tools does not transfer the regulated entity’s legal responsibility for KYC, AML and fraud controls. Document the split of duties and align it with your compliance framework.