Interchange projections miss in the same direction in almost every embedded finance program: actual interchange comes in below what was modeled. Sometimes 20% below. Sometimes 50%. Occasionally — in programs where the architecture decisions went particularly wrong — the miss is large enough to make the unit economics unworkable.
The reasons are predictable. They are all architecture decisions made before launch, often without realizing that a decision was being made at all. BIN structure, card type, network selection, data transmission quality, and the revenue sharing terms in the BaaS contract each determine a piece of the interchange rate. When any of them defaults to the vendor's standard configuration rather than a deliberate choice, the interchange ceiling drops.
Here's where the gap comes from.
The BIN structure decision you probably didn't know you were making
A Bank Identification Number (BIN) is the first six to eight digits of a card number. It identifies the issuing bank, the card network, the card type, and the product. Those attributes determine which interchange category a transaction qualifies for. Different BINs carry different interchange potential — and the BIN your program uses is determined by your sponsor bank and, in BaaS programs, often by the BaaS provider's default configuration.
Programs that don't specify BIN requirements end up with whatever BIN the BaaS platform assigns by default. That BIN may be optimized for the BaaS provider's portfolio, not for the program's transaction profile. The interchange difference between a well-chosen BIN and the default can be 30–80 basis points — which, at $50M monthly processing volume, is $150,000 to $400,000 per month in foregone revenue.
This decision needs to be made explicitly, with the interchange rate schedule in hand, before the bank and BaaS contracts are signed. Most programs discover they have the wrong BIN structure six months after launch, when changing it requires renegotiating with the bank and reissuing cards to existing customers.
Card type determines the interchange ceiling
Consumer debit, consumer credit, commercial debit, commercial prepaid, and commercial credit each have materially different interchange rate structures. The highest commercial card interchange rates — available on business credit and commercial card programs — can be 150–250 basis points on qualifying transactions. Consumer debit interchange is regulated under Durbin for large issuers and is typically much lower.
The card type your program issues is an architecture decision. For programs serving business customers, commercial card products unlock significantly higher interchange than consumer products — but require the right BIN, the right card program structure with the network, and a sponsor bank with commercial card issuing capability. Programs that default to consumer card products because they're simpler to launch leave commercial interchange rates permanently on the table.
The question to answer before launch: does your customer base qualify for commercial card products, and does your bank and BIN structure support the interchange categories those products access? Most programs don't ask it.
Level 2 and Level 3 data — where 30–60 basis points disappear
Card network interchange schedules have enhanced rates for transactions where additional data is transmitted with the payment. Level 1 is the baseline: basic transaction data. Level 2 adds tax amount, customer reference number, and merchant zip code. Level 3 adds full line-item detail — item descriptions, quantities, unit costs, product codes.
The interchange difference between Level 1 and Level 2 on a qualifying commercial card transaction is typically 10–20 basis points. Between Level 1 and Level 3, it's 20–40 basis points. For B2B programs processing commercial card payments, that spread is the difference between a viable interchange revenue model and one that doesn't cover costs.
The problem: transmitting Level 2 and Level 3 data requires that the data exists in the payment system at the time of the transaction, that the payment processor supports Level 2/3 data transmission, and that the BIN and card program are configured to receive the enhanced interchange rate. All three conditions need to be true simultaneously. Programs where any one is missing earn Level 1 rates on every transaction, indefinitely, without a clear signal that anything is wrong.
The verification step that most programs skip: after launch, pull a sample of commercial card transactions and verify which interchange category they actually settled at. If Level 2/3-qualifying transactions are settling at Level 1 rates, the data transmission is broken and the program is losing enhanced interchange on every transaction processed.
The revenue sharing terms in the BaaS contract
Even if BIN structure, card type, and Level 2/3 data are all optimized, the BaaS contract determines what percentage of the interchange the program sponsor actually keeps. BaaS providers share interchange — but the sharing ratio varies significantly by provider and is negotiable at contract signing, not after.
Standard BaaS interchange sharing agreements give the program sponsor 50–80% of interchange, with the BaaS provider and sponsor bank retaining the remainder. The exact split depends on the program's volume, the negotiating leverage the program brought to the table, and whether anyone pushed on the terms at all. Programs that accepted the first offer — or that didn't realize interchange sharing was negotiable — are permanently operating below their interchange ceiling.
At $30M monthly processing volume with 200bps average interchange, a 10-percentage-point difference in the sharing ratio (60% vs. 70% to the program sponsor) is $60,000 per month. That's the cost of accepting the first offer rather than negotiating.
Network selection and its interchange implications
Visa and Mastercard have different interchange rate schedules for the same transaction types. American Express and Discover have different economics entirely. The network your program uses — and whether your BIN supports transactions on multiple networks — affects the interchange category your transactions qualify for.
For most programs, Visa and Mastercard are the right primary networks. The decision is which one, and whether dual-network BIN access (allowing transactions to route over either network) is worth pursuing. Dual-network access can improve routing flexibility and, in some transaction categories, improve interchange rates by allowing the processor to route to the network with the more favorable rate for each transaction type.
This is a nuanced decision that depends on the program's transaction mix, the sponsor bank's network relationships, and the BaaS provider's routing capability. It's also a decision that needs to be made before the BIN is established and the card program is launched with the network.
What "designing for interchange" looks like
A program designed for interchange has five things defined before the first card is issued: the BIN structure and its interchange category implications for the program's transaction mix; the card type or types the program will issue and the interchange ceiling each unlocks; the Level 2/3 data requirements and the processor and BIN configuration to transmit and capture them; the interchange sharing terms in the BaaS and bank contracts; and a post-launch verification process that checks actual interchange rates against expected rates at the transaction level.
None of this is complicated once the decision framework is in place. What makes it complicated is that most programs encounter these decisions embedded in vendor conversations and contract terms, without a prepared framework for evaluating them. The vendor's default configuration becomes the program's architecture by default.
The programs that hit their interchange projections designed for interchange before they launched. The programs that miss are the ones that modeled interchange revenue against a rate they assumed rather than a rate they designed for — and signed contracts that locked in something lower without realizing it.