Card Issuing: How to Build and Scale Card Programs in Regulated Markets

What card issuing actually means today

Card issuing is the business of giving a cardholder a payment credential, a Primary Account Number (PAN) tied to a funding source, then approving and settling the transactions made with it. Acquiring sits on the merchant side of the same transaction, and processing is the technical plumbing that moves messages between the two. The issuer carries the cardholder relationship and the regulatory weight around the funds.

Card issuing used to be a back-office function inside large banks. It isn't anymore. Marqeta processed $291 billion in total volume across its modern card issuing platform in 2024, and Stripe has now created more than 275 million cards through its API. Neobanks and embedded finance platforms treat card programs as a revenue engine and a product surface.

The rest of this article follows a card from sign-up to settlement, then layers in the scheme rules and infrastructure decisions that shape every stage of card program management, including licensing obligations.

The card issuing lifecycle end to end

A single tap or online purchase touches at least six systems before the money lands in the merchant's bank account. If you want to know where a program will break, walk the card program management lifecycle in order. That's where regulatory exposure lives, and that's where the cost of friction appears.

Onboarding and customer intake

The card issuing lifecycle starts with an application. For consumer programs, that means collecting name, address, date of birth, government ID, and consent for the terms and the data processing. Commercial onboarding is heavier, because you're verifying a legal entity, its directors, its Ultimate Beneficial Owners (UBOs), and the company's source of funds.

The UX choices made here decide approval rates. Every extra screen costs conversions, but skipping a data field can mean a manual review queue that blocks the card from being issued the same day. Most modern issuers pre-fill identity data from document scans and bank account verification, then ask for only the fields that risk scoring actually needs.

KYC, KYB and sanctions screening

Know Your Customer (KYC) and Know Your Business (KYB) checks run on top of the application data, with sanctions screening attached to the same intake. The issuer checks identity against government registers and assigns a risk tier after screening names against Politically Exposed Persons (PEP) and sanctions lists from the Office of Foreign Assets Control (OFAC) and the European Union (EU), with United Nations (UN) lists covered too. Higher-risk customers get enhanced due diligence and ongoing transaction monitoring.

Requirements shift by jurisdiction. A UK Electronic Money Institution (EMI) follows the Money Laundering Regulations 2017, while a US program leans on the Bank Secrecy Act and FinCEN rules. Automation handles the bulk of low-risk checks. Human review still owns edge cases where mismatched documents or watchlist hits appear, as well as cases with unusual ownership structures.

Card creation and credential provisioning

Once a customer is approved, the issuer assigns a Bank Identification Number (BIN) and generates a PAN before card production. Physical cards go to a personalization bureau for printing and chip encoding. Virtual cards exist only in the issuing system and can be live in seconds.

The cryptographic work behind this sits inside Hardware Security Modules (HSMs). PCI DSS requirement 3.6.2 governs secure key storage, and payment HSMs must meet FIPS 140-2 Level 3 or PCI HSM certification. Tokenization for Apple Pay and Google Pay runs through schemes like the Visa Token Service, which generates a device-bound token so the real PAN never sits on the phone; Samsung Pay uses the same tokenization model.

Key credential responsibilities at this stage:

• BIN assignment, PAN generation, and CVV calculation inside the HSM

• PIN management, including PIN-block encryption and secure delivery to the cardholder

• Push provisioning into mobile wallets and tokenization lifecycle events

Authorization and transaction processing

When a card is tapped, the acquirer routes an authorization message through the scheme to the issuer. The issuer has to check the balance, run velocity rules, apply 3D Secure (3DS) where required, score the transaction for fraud, and respond. The clock is unforgiving. Netcetera publishes a 99.9% SLA on its issuer 3DS service, and scheme rules expect issuer responses inside a few hundred milliseconds.

When the issuer system is unreachable, the scheme can fall back to stand-in processing and approve low-risk transactions on the issuer's behalf, but those approvals come with risk the issuer still owns. A poor auth stack shows up immediately as declined transactions and lost interchange revenue, with customer churn close behind.

Clearing, settlement and reconciliation

Authorization is a promise. Clearing and settlement is the money moving. The acquirer submits clearing files, and the scheme nets the obligations between members before funds move through settlement accounts in the agreed currencies. Chargebacks and disputes flow back the same way, governed by scheme timelines that leave no room for missed deadlines.

Reconciliation has to match every authorization, clearing record, settlement entry, and ledger posting. For a licensed issuer this isn't optional. Regulators expect cent-perfect books, and any drift between the ledger and safeguarded funds is a finding waiting to happen.

Scheme compliance and BIN sponsorship

Visa and Mastercard publish thick rulebooks that govern fees, dispute handling, fraud monitoring, brand usage, and reporting. Their enforcement is real. Under Visa's surcharge rules, a first violation triggers a $1,000 fee and a remediation request, with penalties escalating to $150,000 after 150 days of continued non-compliance. Mastercard's fraud monitoring program escalates from $500 in month two up to $100,000 a month for issuers stuck in the program past 12 months.

Getting access to the schemes is itself a strategic choice. Becoming a principal member buys you direct connectivity and full control over BIN ranges, at the cost of capital and scheme fees, plus a vetting process that filters out everyone except banks and large fintechs. The alternative is BIN sponsorship, where you ride on a sponsor's principal membership and EMI or banking license. Airwallex describes a BIN sponsor as a financial institution that lets third parties use their BIN to issue cards without joining the network directly.

The trade-offs come down to three things:

• Speed and cost: sponsorship gets a program live in months instead of years, but you pay per-BIN and per-transaction fees on top of scheme costs

• Control and economics: principal membership maximizes margin and product freedom once volume is high enough to justify the overhead

• Accountability: Mastercard has tightened BIN sponsor oversight rules, so sponsors are responsible for partner compliance with payment network mandates

Program registration with the schemes and certifications determine the launch date more than the technology does, with mandatory reporting part of the same readiness work. Engineering can ship in weeks. Scheme readiness rarely moves faster than the rulebook allows.

Regulatory obligations in regulated markets

On top of scheme rules sits the supervisory regime. In the UK and EU, most issuers operate under an EMI license or a banking license. The Bratby Law summary of Policy Statement PS25/12 shows that an Authorised EMI must hold minimum initial capital of €350,000 or 2% of average e-money outstanding, whichever is higher. Customer funds must sit in a segregated trust account or be covered by insurance, ring-fenced from the firm's own capital.

The FCA also requires monthly safeguarding returns. Under SUP 16, all APIs, AEMIs, and SEMIs have the same obligation: each firm submits monthly reports on safeguarding arrangements within 15 business days of month-end. US programs face a different mosaic of state money transmitter licenses, plus federal oversight of the sponsor bank. Singapore runs its Payment Services Act regime through the Monetary Authority of Singapore (MAS). Each jurisdiction layers AML and counter-terrorist financing (CTF) obligations across the card issuing operational lifecycle, with consumer protection duties attached to the same regime.

Think of this layer as the cost of entry. The licensing, capital, safeguarding, and reporting obligations expand with scale. Outsourcing rules also bind you: regulators expect the issuer to retain accountability for any function it delegates to a processor or sponsor, and the same expectation applies to service providers.

Issuing infrastructure you actually need

A card issuing program is an integrated system. The pieces have to share data cleanly and fail predictably, with recovery that does not lose transactions.

The core components of any serious issuing infrastructure:

• Issuer processor that handles scheme connectivity, authorization, and clearing

• Card management system for lifecycle events, status changes, and reissuance

• Ledger that records every cardholder balance and movement with audit-grade accuracy

• Fraud and risk engine running real-time scoring on authorization messages

• Dispute and chargeback tooling aligned to scheme timelines

• Reporting stack for regulators, schemes, finance, and product teams

Feature lists sell well in sales decks. They don't determine whether a program scales. API quality and uptime do, with observability behind both. A processor that publishes a 99.99% Service Level Agreement (SLA) and exposes p95 and p99 latency by endpoint is doing something different from one that ships a glossy portal and a quarterly status email. When a card declines at a grocery checkout, the cardholder doesn't care that the dashboard has dark mode.

The issuing infrastructure also has to absorb the security overhead. Payment HSMs, key ceremonies, PCI DSS audits, and PCI Card Production requirements bind every component that touches a PAN. Cutting corners here is how programs lose their certifications and their sponsor banks in the same quarter.

Build, buy, or partner for card program management

Every team launching a program faces the same fork. The choice is whether to build the issuing infrastructure in-house or rely on outside providers, from point solutions to a full-stack partner that owns processing and scheme connectivity along with compliance.

Building card issuing infrastructure yourself makes sense if you have bank-scale volume and a deep engineering bench, with a roadmap that depends on owning every layer. The cost is years of work before you write your first authorization. The classic mid-market approach has been to assemble best-of-breed point solutions, a processor here, a KYC vendor there, a fraud engine bolted on, a card management system underneath. It works, but integration becomes the product. Alex Johnson of Fintech Takes argues that teams choosing this path should focus on providers that enable competitive differentiation and save money on the commoditized layers.

A partner model collapses the integration burden. You get a single contract for processing, scheme connectivity, compliance support, and tooling, in exchange for less control over individual components. For most fintechs launching their first card product, partner-led card program management is the pragmatic path because it shifts the regulatory and engineering load off the product team. Building still wins when scale and unit economics justify owning the stack end to end.

Scaling a program without breaking it

A program with 50,000 cards looks nothing like one with 5 million. Volume spikes during paydays and holidays test the issuer processor. Multi-currency settlement adds reconciliation complexity. Expansion into a new region brings a new license and a fresh set of scheme certifications, along with a new sponsor. According to the Nilson Report's 2024 figures, global card fraud losses reached $33.41 billion in 2024, and fraud patterns shift faster than rule-based engines can keep up.

Three pressure points show up first as programs grow:

• Authorization latency under load, which directly drives decline rates and merchant abandonment

• Dispute volumes, where a 0.1% chargeback ratio turns into thousands of cases a month and a full operations team

• Reconciliation drift between authorization, clearing, settlement, and the ledger, which compounds into reportable breaks

Scale exposes the foundations laid on day one. A processor that runs fine at 100 transactions per second can fail at 10,000. A ledger that batched reconciliation overnight can't survive multi-region settlement windows. The infrastructure choices made before the first card is issued either enable the next million cards or block them.

How EGS supports issuers behind the scenes

EGS provides the resilient fintech infrastructure for card program management that sits behind a card program, so the team running the product can rely on it instead of building it. That includes the issuer processor, scheme connectivity, ledger and reconciliation, fraud and dispute tooling, and the compliance support that comes with operating in regulated markets. The work that consumes most of an engineering and compliance team is the work EGS absorbs.

For a fintech or neobank, and for an embedded finance platform, this means the product team owns the cardholder experience and growth strategy while it also sets the proposition; the heavy operational and regulatory load runs on infrastructure built for it. The same issuing infrastructure architecture that supports a 10,000-card pilot keeps working when the program hits a few million cards in multiple currencies.

If you're planning a new card issuing program or rebuilding one that's outgrown its current setup, talk to the EGS team. We'll walk through your target markets and scheme requirements, then show you what card issuing looks like when the backend is someone else's problem, with timelines included in the plan.