Building a Card Program
Card programs fail before
Card programs fail before
the first card
is issued.
The failure happens at the architecture stage — when the program model, interchange economics, sponsor bank requirements, and compliance framework weren't defined before the build started.
First conversation: 30-minute architecture diagnostic. No cost. No commitment.
Card Program Types
Debit, prepaid, and credit — three different architectures
Debit
Debit Card Programs
DDA-linked. Reg E consumer protections apply. Debit interchange — typically Durbin-exempt at most program sizes, which means higher interchange rates than Durbin-regulated. Requires sponsor bank DDA relationship and deposit program structure.
Prepaid
Prepaid Card Programs
Stored value architecture. FDIC pass-through design considerations. KYC/KYB requirements vary significantly by program type and load limits. Interchange varies by program structure and card network. Flexible use cases from payroll to benefits to rewards.
Credit / Charge
Credit & Charge Card Programs
Underwriting requirements, Reg Z / TILA compliance, bank credit risk appetite. Highest interchange potential — especially commercial credit. The most complex program architecture, but also the most economically powerful when designed correctly.
Interchange Economics
What card program interchange actually looks like
The economics that determine whether a card program is worth building — and who captures what.
Level 1 vs Level 2 vs Level 3
Level 1 is the baseline commercial interchange rate. Level 2 data (tax amount, customer reference) adds ~10–20bps. Level 3 data (line-item detail) adds another ~20–40bps. Most commercial card programs leave 30–60bps on the table by not transmitting enhanced data.
Commercial vs Consumer Rates
Commercial card interchange rates are significantly higher than consumer rates. A well-structured commercial card program captures 150–250bps or more. Consumer debit is typically 100–130bps for Durbin-exempt programs.
What Determines Your Rate
Card type, merchant category, transaction size, data level transmitted, network (Visa vs Mastercard vs other), and BIN configuration. The program architecture determines the ceiling — and most programs are designed well below it.
Who Captures Interchange
Who captures interchange is a program design decision. In BaaS programs, the default is often for infrastructure to capture a significant share. Direct programs and well-structured hybrid programs retain substantially more for the program sponsor.
BIN Sponsorship Effect
The BIN sponsor (typically the issuing bank) and their relationship with the card network affects interchange rates and program rules. Bank selection and BIN structure are economic decisions, not just compliance decisions.
Architecture Requirements
Five components every card program requires
01
Card Network Relationship (Visa / Mastercard)
BIN sponsorship, program rules, network reporting. The network relationship is foundational — it determines program parameters, rules, and interchange rate structure.
02
Sponsor Bank Relationship
Compliance requirements, float economics, program terms. The most important commercial relationship in the program — and the one most frequently entered without adequate preparation.
03
Card Issuance Infrastructure
Physical and virtual card production, PIN management, activation flows. Infrastructure selected to fit the program architecture — not the other way around.
04
Transaction Processing
Authorization, clearing, and settlement architecture. Network connectivity, processor selection, and data flow design all determined by program model.
05
Compliance Framework
KYC/KYB program, dispute management, network rule compliance. Defined before infrastructure selection — compliance requirements constrain infrastructure options.
When companies work with ExpandUp on card programs
First card program design (debit, prepaid, or credit)
Architecture, economics, and compliance framework defined before the first vendor conversation.
Card program economics restructuring
Interchange architecture, fee structure, and bank terms renegotiated post-launch when economics aren't working.
Sponsor bank preparation for card program
Program package, compliance documentation, and commercial term framework prepared before bank conversations begin.
BIN sponsorship selection
Bank evaluation against program-specific criteria — not just availability or familiarity.
Post-launch interchange optimization (Level 2/3)
Level 2/3 data transmission design for commercial card programs leaving interchange on the table.
Payments Monetization
The interchange architecture is the revenue architecture.
BIN structure, card type, network selection, data level transmission, and program model are all economic decisions. Most card programs are designed well below their interchange ceiling because those decisions were made by infrastructure rather than by the program sponsor.
See how we design card program revenue →Define the architecture before the first BaaS demo.
Every card program locks in its economics at the architecture stage. The decisions made before vendor selection determine the program's margin ceiling for years.