> Bank Partner Selection | ExpandUp Architecture Method
Architecture — Bank Partner Selection

The bank conversation needs
to happen after the architecture is defined.

Sponsor bank selection should be driven by the program architecture, not availability. Most programs enter bank conversations before the program structure is defined — and the bank's requirements define the architecture by default.

Talk with us before your next vendor decision → ← Architecture Overview
Why Bank Selection Is an Architecture Decision

The bank relationship shapes every other program decision

WRONG SEQUENCE
Bank conversation before architecture
You explain what you're building. The bank explains what they'll support. The bank's requirements and risk appetite define your program parameters. You accept or walk. Most programs accept.
ARCHITECTURE-FIRST
Architecture defined before bank conversations
Program model, compliance framework, and commercial term requirements defined. Bank evaluated against the architecture. Conversations are structured around term negotiation, not discovery.
Bank Archetypes

Not all sponsor banks are the same program partner

TYPE 01
Fintech-Focused Community Banks
Built for fintech sponsorship. Know the program model. Faster compliance process. More flexible on commercial terms. Smaller balance sheet — may have concentration limits at scale.
TYPE 02
Regional and Mid-Size Banks
Larger balance sheet. Often better float economics. May have less fintech-specific compliance infrastructure. Longer onboarding. Often better for larger, more established programs.
TYPE 03
BaaS-Integrated Banks
Bank provides compliance sponsorship through a BaaS intermediary. Fastest time to market. Economics shared across three layers. Program rules determined by both bank and BaaS.
TYPE 04
Direct Program Banks
Direct bank relationship, no intermediary. Best economics. Requires bank to have appetite for your program type, volume, and compliance structure. Usually for larger, more established programs.
TYPE 05
Specialty Program Banks
Deep expertise in specific program types — prepaid, card issuing, lending-adjacent. Often the best technical fit for complex programs. Not the right fit for every segment.
TYPE 06
Credit Unions and Cooperative Banks
Member-owned structure creates different risk appetite. Sometimes excellent fit for community-facing or mission-aligned programs. Limited scale for high-volume programs.
Commercial Term Negotiation

The terms that need to be negotiated before the bank conversation

These are defined before the bank meeting, not during it. Walking in without prepared term requirements means accepting the bank's defaults.

Float economics
Who captures the interest on customer balances. What rate. Pass-through or pooled. This is negotiable — most programs don't negotiate it because they don't know to ask.
Revenue sharing structure
Interchange sharing, fee sharing, and revenue split across the bank-program relationship. The structure determines whether the bank is a cost or a partner.
Compliance cost allocation
Who bears the cost of BSA/AML, KYC/KYB, transaction monitoring. How compliance examination costs are allocated. Often left undefined and becomes a surprise cost.
Program exclusivity and term
Exclusivity provisions, minimum volume commitments, program term and renewal. All affect flexibility and leverage over the relationship.
Product expansion rights
What products can be added to the program over time. Which require separate approval. Whether the bank's consent is needed for product changes.
Examination and audit rights
What access the bank has to program operations. Examination scope. Response timelines. Remediation expectations.
Bank terms are Lever 05 in the monetization framework →
Preparation Framework

What goes into a bank conversation package

01
Program Model Document
Program type, customer segment, transaction profile, volume projections. Gives the bank what it needs to assess fit without discovery conversations.
02
Compliance Framework Summary
KYC/KYB design, transaction monitoring approach, OFAC screening, BSA/AML program. Shows the bank you've designed for their requirements.
03
Risk Appetite Summary
Customer risk profile, expected transaction patterns, return rate projections, fraud management design. Answers what the bank will ask before they ask it.
04
Commercial Term Requirements
Float economics, revenue sharing, compliance cost allocation prepared in advance. Entering the negotiation with defined requirements rather than accepting defaults.
05
Bank Evaluation Criteria
What you need from the bank — compliance appetite, technical capabilities, balance sheet, commercial terms. Used to evaluate multiple banks against a consistent framework.
06
Program Roadmap
Phase 1 program, expansion products, volume trajectory. Banks want to see where the relationship goes. Programs with clear roadmaps get better terms.
Protecting Migration Optionality

The contract terms that determine whether you can ever leave

The bank and BaaS contracts you sign at launch determine not just the economics of the program today, but your ability to restructure those economics as the program scales. Most programs underestimate the cost of migration — and sign contracts that make it harder than it needs to be.

Migrating off a BaaS platform — or restructuring the economics of a bank relationship — costs 3–5x what programs project. The migration involves engineering work to integrate directly with bank or processor infrastructure, potential card reissuance if the BIN migrates, compliance investment to support a more direct regulatory relationship, and operational disruption during the cutover. That cost is real. What makes it higher than necessary are contracts that were signed without the terms that preserve optionality.

TERM 01
Data portability
The program owns its customer data, transaction history, and card program data. The contract should specify that all data is available for export in a defined format at any time — not just at contract termination. Programs that can't access their own transaction history can't migrate their underwriting models, reconciliation records, or customer data without rebuilding from scratch.
TERM 02
BIN transfer rights
If the BIN is registered to the BaaS provider rather than the program sponsor, migrating the card program requires either reissuing all cards — major customer disruption — or negotiating a BIN transfer mid-program. The contract should address BIN ownership and transfer rights before signing, not when the migration is already in process and the BaaS provider has all the leverage.
TERM 03
Transition assistance obligations
The contract should define what technical and operational support the BaaS provider will provide during a migration — API access continuity, data export support, parallel operation period, and reasonable transition timelines. BaaS providers have no economic incentive to make migration easy. The contract is the only moment where the program has leverage to require it.
TERM 04
No exclusivity on bank relationships
Some BaaS arrangements include exclusivity provisions that prevent the program from establishing a direct relationship with the sponsor bank or another bank. These provisions directly block the most common migration path — moving from BaaS-intermediated economics to a direct bank relationship. They should be identified and negotiated out before signing, not discovered when the migration becomes necessary.

The same negotiating moment that sets float economics and revenue sharing terms also sets lock-in protections. These are not separate conversations — they are the same conversation, prepared together before the first bank or BaaS meeting begins.

Full analysis: Buy vs. Build vs. Partner — the infrastructure decision framework →
Payments Monetization

Float economics and revenue sharing are negotiated in the bank conversation — not discovered after it.

The bank relationship terms are Lever 05 in the payments monetization framework. Float economics, revenue sharing structure, and compliance cost allocation are all commercial terms — and all negotiable before the program launches.

See the full monetization framework →

Walk into the bank conversation prepared.

The bank conversation should be a negotiation, not a discovery session. We prepare the program documentation, compliance framework, and commercial term requirements before your first bank meeting.

Talk with us Next: Compliance & Readiness →
Want the complete sponsor bank selection framework? Evaluation criteria, red flags, the buy box problem, and how sponsor bank structure determines your monetization ceiling.
Read the framework →