How can a platform offer issued cards to its users without becoming a bank?

Yes. The key is that the platform does not actually become the regulated card issuer. It operates a card program in partnership with a bank (or another appropriately licensed issuer), while the platform owns much of the customer experience and technology.

A typical U.S. setup looks like this:

                    CARD NETWORK
                 Visa / Mastercard
                        │
                        │
                 ┌──────▼──────┐
                 │ Issuing Bank │
                 │ / BIN Sponsor│
                 └──────┬──────┘
                        │
              ┌─────────▼─────────┐
              │ Card Processor     │
              │ authorization,     │
              │ ledger, settlement │
              └─────────┬─────────┘
                        │
                 ┌──────▼──────┐
                 │ Your Platform│
                 │ app + UX +   │
                 │ card controls │
                 └──────┬──────┘
                        │
                    End User

1. The bank is the actual issuer

The bank provides the regulatory infrastructure and typically holds the underlying customer funds. It also has the relationship with the card network and is responsible for the regulated issuing function.

The Federal Reserve explicitly describes this BIN-sponsor model: a bank that is a member of a card network can permit another company to issue cards using the bank's BIN. In a prepaid-card structure, the sponsoring bank generally holds the program funds in a pooled/omnibus account while individual balances can be tracked in subaccounts.

So when your platform says:

"We issued you a Visa card" the legal reality may be closer to:

"Our platform operates the card program; the card is issued by Bank X under Bank X's BIN."

2. The platform becomes the "program manager"

The nonbank platform usually handles things such as:

• onboarding users
• designing the card
• the mobile/web experience
• deciding who gets a card
• spending controls
• transaction notifications
• customer support
• maintaining its internal ledger
• integrating with the processor
• fraud/risk logic

The bank doesn't necessarily build your app. It provides the regulated banking/card infrastructure behind it.

This separation is explicitly contemplated by regulators: the Federal Reserve describes arrangements where a bank sponsors a fintech's access to payment systems and the fintech can perform recordkeeping and other operational functions.

3. The BIN is the critical piece

A BIN (Bank Identification Number) identifies the issuing institution/program on the card network.

The platform gets access to a BIN through the sponsoring bank. The processor then connects the platform's software to the network and bank.

For example:

User taps card
      ↓
Merchant
      ↓
Visa / Mastercard
      ↓
Issuing bank's BIN
      ↓
Card processor
      ↓
Platform's authorization logic
      ↓
"Approve" / "Decline"

The processor can make this feel almost entirely like your own infrastructure even though the regulated issuer is a separate institution. Modern issuing platforms explicitly support this architecture—for example, Stripe describes a processor-only model where its issuing infrastructure connects the network, card manufacturer and BIN sponsor, while the platform supplies the authorization endpoint and transaction logic.

4. Who actually holds the money?

This is an important distinction.

Suppose your platform shows:

Alice — $2,000 balance That doesn't necessarily mean your company has $2,000 of customer deposits on its own balance sheet.

A common structure is:

             Issuing Bank
                  │
        ┌─────────▼─────────┐
        │ FBO / pooled       │
        │ customer account   │
        │                    │
        │ $2,000 Alice       │
        │ $1,500 Bob         │
        │ $3,000 Carol       │
        └─────────┬─────────┘
                  │
          Platform's ledger
          tracks ownership
          of each balance

The bank can hold the pooled funds while the platform maintains the customer-level accounting. The Federal Reserve specifically describes this type of arrangement.

That's one of the major reasons the platform can provide a bank-like experience without itself being a bank.

5. But "not a bank" does not mean "unregulated"

This is the part people sometimes miss.

The platform isn't simply escaping regulation by putting another company's name on the card.

The bank has regulatory responsibilities, and the fintech may have its own obligations depending on exactly what it does. For example, regulators have emphasized that banks' customer-identification requirements can apply to prepaid-card users even when a third-party program manager markets and distributes the cards.

The bank therefore typically performs substantial due diligence and ongoing oversight of the fintech.

6. There are several different structures

"Card issuing without being a bank" can mean different things:

The exact regulatory answer depends heavily on what kind of card it is and what the platform does with the money.

The simplest mental model

Think of it as "Bank-as-regulated-backend + fintech-as-product layer."

The bank supplies:

license + BIN + regulated account + network membership + settlement + regulatory oversight

The platform supplies:

brand + app + customer + UX + product logic + authorization rules + distribution

The processor supplies:

the plumbing connecting all of it.

That's why companies can offer cards that look and feel completely proprietary without obtaining a bank charter themselves. The Federal Reserve's own regulatory commentary recognizes BIN-sponsor arrangements in which the sponsoring bank remains the issuer even though another entity distributes and operates the card program.

If you're thinking about building such a platform yourself, the interesting next question is the economics and architecture—i.e. exactly what contracts, licenses, bank relationships, processor, ledger, KYC/AML stack, and money flows you'd need to launch one.

A platform can offer branded debit, credit, or prepaid cards to its users without becoming a bank by leveraging Banking-as-a-Service (BaaS) and Card Issuing APIs.

In this model, the platform acts as the front-end user experience and product designer, while licensed financial entities handle the regulated backend.

How the Ecosystem Works

Key Components to Implement

• BIN Sponsorship: Your program operates under the Bank Identification Number (BIN) of a licensed partner bank. The bank sponsors your program into card networks like Visa or Mastercard.
• Compliance & KYC Layer: The BaaS provider or partner bank integrates Know Your Customer (KYC) and Anti-Money Laundering (AML) checks into your onboarding flow so that user identity verification meets legal standards without your company holding a banking charter.
• Ledger and Funds Flow: For prepaid or debit models, user funds are stored in FBO (For Benefit Of) accounts managed by the partner bank, legally separating user funds from your corporate operating cash and protecting them if your platform fails.
• Card Fulfillment & Tokenization: The infrastructure handles physical card manufacturing, shipping logistics, and integration with digital wallets like Apple Pay and Google Pay.

Are you looking to build a B2B expense management tool , a consumer fintech app , or something else? If you share your target use case , I can give you a better idea of the compliance hurdles and specific partner infrastructure you might need.

A platform can offer branded debit, credit, or prepaid cards to its users without holding a banking license by utilizing the Sponsor Bank (or BIN Sponsorship) and Banking-as-a-Service (BaaS) model.

In this arrangement, the non-bank platform handles the customer-facing experience, software, and distribution, while regulated financial institutions handle the legal, compliance, and ledger obligations under the hood.

The Three Pillars of Non-Bank Card Issuing

1. The Sponsor Bank (BIN Sponsor)
   • What it is: A chartered, FDIC-insured bank that legally issues the cards.
   • Why it matters: Only regulated banks have the authority to issue payment cards on major networks (Visa, Mastercard) and hold or manage underlying funds. The bank owns the Bank Identification Number (BIN) range and ensures compliance with federal regulations (KYC/AML).
2. The BaaS / Card-Issuing API Provider
   • What it is: The technological middleware connecting your platform to the sponsor bank and card networks. Popular providers include Stripe Issuing, Marqeta, Lithic, Unit, and Highnote.
   • Why it matters: They provide the APIs to programmatically issue virtual or physical cards, set spending limits, authorize transactions in real time, and handle tokenization for Apple Pay or Google Pay.
3. The Program Manager (Your Platform)
   • What it is: The software interface or marketplace your users interact with.
   • Why it matters: You design the UI, onboard the customer (collecting initial Know Your Customer data), decide who gets a card, and define the reward/utility mechanism.

How the Money and Liability Flow Work

• Funds Storage: User funds aren't stored by your software company; they sit in an FBO ("For Benefit Of") account managed by the sponsor bank. This ensures the funds are FDIC-insured (pass-through insurance).
• Authorization: When a user swipes a card, the merchant's request hits the card network, passes to the BaaS provider, and instantly pings your platform's API (to check if the user has an internal balance or credit limit). Your system responds approve/decline , and the sponsor bank settles the funds.
• Revenue Generation: Your platform makes money through interchange fees (a percentage paid by the merchant when a card is swiped) which are split between your platform, the BaaS provider, and the sponsor bank.

If you're looking to build out a card program, let me know:

• What is your platform's core use case (e.g., expense management, gig-worker payouts, consumer rewards)?
• Are you looking for virtual cards, physical cards, or both?

I can help you explore which BaaS architecture or vendor fits your model best.

A platform can offer cards without being a bank because the platform doesn't have to be the legal issuer of the card. It typically operates a card program on top of a regulated bank or licensed issuer.

A simplified U.S. structure looks like this:

User → Platform → Program/Issuer Bank → Card Network → Merchant

How it works

• The bank is the issuer. The bank provides the underlying regulated account/card relationship, has the BIN (Bank Identification Number), and is ultimately responsible for the banking activity. Regulators explicitly recognize arrangements where banks provide banking products through fintech companies.
• The platform is the program manager / fintech. The platform owns the customer experience: onboarding, app, card controls, transaction logic, rewards, etc. It contracts with the bank and often with a card processor.
• A card network provides the rails. Visa or Mastercard connects the issuer to merchants and acquirers. The bank's sponsorship can give the fintech access to the network. The OCC specifically describes banks sponsoring fintechs' access to payment and card networks.
• A processor handles the plumbing. A processor can connect the platform to the issuer, network, card manufacturer, authorization systems, and settlement processes. For example, Stripe describes an issuing model where cards are issued on behalf of a BIN sponsor.

What the customer sees

The experience can look completely like the platform's own product:

"Get your Acme Card" The physical/virtual card can carry Acme's branding, and Acme's app controls the card. But legally, the card may say something like:

"Card issued by XYZ Bank, N.A., pursuant to a license from Visa." The issuing bank remains the regulated entity behind the product. For prepaid products, for example, OCC guidance explicitly recognizes third-party program managers that design, manage, and operate programs involving cards issued by banks.

Who does what?

The important point is that "not a bank" does not mean "unregulated." The fintech still has substantial contractual, compliance, consumer-protection, AML/KYC, data-security, and operational obligations, while the partner bank has regulatory responsibilities for the activities it conducts through the fintech. Regulators specifically emphasize due diligence and ongoing third-party risk management for these relationships.

There are actually several models

1. Bank-sponsored debit/prepaid card

The most straightforward model:

Platform + sponsor bank + processor + Visa/Mastercard

The bank owns the underlying regulated relationship; the platform runs the product.

2. Bank-sponsored credit card

Similar architecture, but the bank is particularly important because someone has to extend the credit and bear/manage the associated lending risk. Banks can outsource significant portions of credit-card operations to third parties, but the bank remains subject to supervisory oversight.

3. Non-bank licensed issuer

In some jurisdictions, a platform can use an e-money institution, payment institution, or other licensed issuer rather than a traditional bank. The exact possibilities depend heavily on the country and the type of card/account.

4. Become the issuer yourself

The platform can eventually obtain its own banking or other financial license. That's much more expensive and operationally complex, so startups frequently begin with sponsorship.

The key conceptual distinction

Think of it as separating the product from the regulated financial institution.

The platform can own:

customer + app + brand + distribution + product design while the regulated institution owns:

regulated account/card relationship + issuance + access to payment rails + regulatory responsibilities That's why a company can truthfully say "we offer cards" without being a bank.

If you're thinking about this from the perspective of building such a platform, the next interesting question is exactly what the contractual/technical stack looks like—sponsor bank vs. BIN sponsor vs. issuer processor vs. program manager, and where the money actually sits at each step.

A platform can offer cards without becoming a bank because the platform doesn't have to be the legal card issuer. Instead, it partners with a licensed bank that acts as the issuer.

The basic structure is:

Platform → program manager/issuer processor → sponsor bank → Visa/Mastercard

How it works

1. A sponsor bank provides the regulated banking relationship

   • The bank already has the necessary banking charter and network membership.
   • It owns or sponsors the BIN (Bank Identification Number) associated with the cards.
   • The bank ultimately takes responsibility for the regulated issuing relationship, settlement, and applicable regulatory obligations.

2. The platform owns the customer experience

   • The platform designs the app, card experience, controls, rewards, and branding.
   • It can decide things like spending limits, virtual vs. physical cards, merchant categories, and when to freeze a card.
   • It may perform KYC/AML and transaction-monitoring functions under its agreement with the bank, but the bank retains oversight and regulatory responsibility.

3. An issuer processor runs the card technology

   • When the user makes a purchase, the transaction goes through the card network to the issuer processor.
   • The processor checks the user's account/balance, applies authorization rules, and sends the approve/decline response back through the network.

4. The bank handles the regulated money movement

   • For a debit/prepaid-style product, the underlying funds can be held in accounts at the sponsor bank, including structures where funds are held for the benefit of (FBO) end users.
   • The bank participates in network settlement and bears the relevant banking/network obligations.

So, for example, imagine a payroll platform wants to give every employee a branded Visa card:

PayrollCo creates the app and card experience.
Sponsor Bank is the actual issuing bank.
Issuer Processor maintains card/account records and handles authorizations.
Visa provides the payment network.
PayrollCo's users see a PayrollCo-branded card.

The customer may barely notice the bank's involvement, but legally and operationally the bank is an important part of the stack.

Why is this allowed?

Because being a technology/customer-facing platform isn't the same thing as being a bank. Banks routinely use third parties to deliver financial products. U.S. regulators explicitly recognize bank-fintech arrangements and expect banks to perform due diligence and maintain appropriate oversight of their fintech partners.

This is commonly called BIN sponsorship. Visa itself describes a card-launch stack as generally requiring a banking relationship, an issuer processor, and often a program manager; the BIN sponsor is the issuing bank that owns the BIN and handles key regulatory and settlement responsibilities.

The important catch

"Not a bank" doesn't mean "not regulated."

A fintech/platform can still have substantial obligations around:

• KYC/CIP and AML
• sanctions screening
• fraud and transaction monitoring
• consumer protection
• money transmission, depending on the product and structure
• data/security requirements
• card-network rules
• recordkeeping and reconciliation

And the sponsor bank doesn't simply "lend its license and walk away." Regulators emphasize that banks remain responsible for managing risks arising from third-party relationships.

One subtle distinction: debit vs. credit

For a debit/prepaid card, the basic model is relatively straightforward: the card accesses funds associated with an underlying account.

For a credit card, things get more complicated because you're introducing lending. The issuing bank generally needs to be the lender/credit issuer and is responsible for underwriting, credit-risk management, disclosures, collections, and related requirements. The OCC specifically treats credit-card issuing and lending as bank activities subject to its lending and risk-management framework.

In one sentence: the platform supplies the product and technology, while a licensed bank supplies the regulated issuing infrastructure and legal banking relationship. That's what lets a non-bank offer cards at scale.

To offer issued debit, credit, or prepaid cards without becoming a licensed bank, a non-bank platform typically acts as a program manager or distributor by partnering with regulated entities. This is achieved through the following approaches and frameworks:

• Banking-as-a-Service (BaaS) Providers : Platforms partner with specialized technology companies (such as Treasury Prime, Unit, or Marqeta) that provide the underlying API infrastructure, compliance tools, and connections to card networks.
• Issuing Banks (BIN Sponsors) : The actual financial backing and card issuance must come from a chartered financial institution (an FDIC-insured bank or credit union). This bank acts as the BIN (Bank Identification Number) sponsor , taking on regulatory responsibility for the ledger and deposits, while your platform handles the front-end user experience.
• Program Management : Your platform acts as the program manager, owning the customer relationship, branding, user interface, and distribution strategy, while adhering to the compliance, KYC (Know Your Customer), and AML (Anti-Money Laundering) requirements mandated by the partner bank.
• FBO (For Benefit Of) Accounts : User funds are typically held in pooled omnibus accounts at the partner bank structured as FBO accounts, ensuring that user funds remain segregated from the platform's operational capital and are often eligible for pass-through FDIC insurance.

Would you like to explore:

• Specific BaaS partners or BIN sponsors for your use case?
• The compliance and regulatory steps (KYC/AML) required to launch?
• The revenue-sharing model (interchange fees) for card programs?

A platform can offer branded physical and virtual payment cards to its users without holding a banking license by leveraging Embedded Finance and Banking-as-a-Service (BaaS).

In this arrangement, the software platform owns the user experience and the front-end branding, while regulated financial institutions handle the underlying legal, capital, and compliance requirements behind the scenes.

The underlying architecture relies on three foundational components:

1. The Sponsor Bank (or BIN Sponsor) : A licensed, FDIC-insured (in the U.S.) financial institution that legally issues the card, holds the underlying ledger or deposits, and assumes ultimate regulatory responsibility.
2. *The Issuer Processor / BaaS Provider * : The technological bridge (via APIs) that connects your platform to the card networks (Visa/Mastercard) and the sponsor bank. Providers like Stripe Issuing, Marqeta, Lithic , or Treasury Prime handle card generation, authorization routing, and real-time spend controls.
3. *Your Platform * : The user-facing software that dictates the visual design of the virtual/physical card, sets business logic (e.g., spending limits, category restrictions), and embeds the management dashboard natively into your application.

Key Steps to Launching an Embedded Card Program

1. Define the Card Product Type
   Determine whether your users need virtual cards (instant online generation for software/ads), prepaid reloadable cards (funds must be pre-loaded before spending), or debit/charge cards (tied directly to user earnings or a ledger managed via the sponsor bank).
2. Partner with a BaaS or Issuing API Provider
   Integrate with an issuer processor or embedded finance platform that provides developer-friendly APIs, SDKs for digital wallet tokenization (Apple Pay/Google Pay), and compliance modules.
3. Implement KYC / KYB (Know Your Customer / Business)
   Your platform will collect user identity information (SSN, ID documents, business registration), which is passed programmatically through your BaaS partner to the sponsor bank to run mandatory anti-money laundering (AML) and terrorist financing checks.
4. Establish Money Flow and Ledgering
   Configure how funds move into the card accounts via ACH, push-to-card, or platform balance splits, ensuring that user funds are safely segregated in FBO ("For Benefit Of") accounts at the partner bank.

If you'd like to narrow this down, tell me:

• What is your platform's primary use case (e.g., gig-worker payouts, B2B SaaS expense management, marketplace)?
• Are you looking to launch virtual cards, physical cards, or both?

I can help you explore the right technical partners and regulatory considerations for your specific model.

Yes. The key idea is that “issuing a card” and “being the bank” are separable roles.

A platform can put a card in a user's name and brand it with the platform's logo while a regulated bank remains the actual issuer behind the scenes.

The typical structure

Think of the stack as:

User → Platform → Card/issuing processor → Sponsor bank → Visa/Mastercard

For example:

1. The platform owns the customer experience.
   It decides who gets a card, spending limits, card controls, rewards, etc.

2. An issuing processor provides the technology.
   The processor handles things like authorization messages, card creation, transaction processing, ledgers, and connections to the card network. Stripe, for example, offers this infrastructure.

3. A sponsor/issuing bank provides the regulated banking relationship.
   The bank has the necessary relationship with the card network and can sponsor the fintech/platform's participation in the network. The OCC describes this type of bank sponsorship explicitly.

4. Visa or Mastercard provides the network.
   The transaction ultimately runs through the card network under the bank's sponsorship.

So the card might look like:

ACME Platform Card

but legally/operationally there is a regulated bank behind the program.

Who does what?

The exact allocation varies considerably by program. Regulators specifically recognize these bank-fintech arrangements and emphasize that the bank remains responsible for appropriate oversight and risk management even when a fintech performs substantial functions.

What is a BIN sponsor?

A particularly important concept is BIN sponsorship.

A BIN (Bank Identification Number) identifies the institution associated with a card range. A sponsor bank can make its card-network/BIN infrastructure available to a fintech program. The fintech then doesn't need to become a bank or establish its own direct card-network membership.

Stripe's documentation gives a concrete example: in its processor-only model, Stripe connects the program to the card network and BIN sponsor, and cards are issued on behalf of that sponsor.

But the platform doesn't escape regulation

This is the important catch.

Not being a bank does not mean “no financial regulation.”

Depending on what the platform actually does, it may have obligations around:

• KYC/customer identification
• AML
• sanctions
• transaction monitoring
• fraud
• consumer protection
• money transmission
• privacy/security
• state licensing
• card-network rules
• safeguarding/handling customer funds

And the sponsor bank will generally impose contractual requirements and monitor the program. U.S. banking regulators have specifically warned banks about operational, compliance, liquidity, consumer-protection and other risks in these arrangements.

A useful mental model

It's similar to airline ticketing:

• The platform owns the customer relationship and experience.
• The processor supplies the machinery.
• The bank supplies the regulated financial infrastructure.
• Visa/Mastercard supplies the payment network.

The platform can therefore say “we offer cards to our users” without saying “we are a bank.”

There are also more sophisticated models where the platform gets its own banking license or direct bank relationship and uses a processor merely as infrastructure. That gives the platform more control but also substantially more regulatory and operational responsibility.

If you're thinking about building such a platform yourself, the interesting next question is how the money actually moves—e.g. where the user's balance sits, who legally owns the funds, who holds the deposit, and how a $100 card purchase flows through all the entities. That's where the architecture gets much more interesting.

A platform can offer branded payment cards (virtual or physical) to its users without holding a banking license by utilizing Embedded Finance , specifically Banking-as-a-Service (BaaS) and Card-as-a-Service (CaaS) providers.

In this arrangement, the non-bank platform manages the user interface, brand, and customer relationship, while licensed financial institutions handle the heavily regulated backend infrastructure.

How the Architecture Works

1. The Sponsor Bank: A chartered, licensed traditional or digital bank legally issues the cards, holds the underlying deposits, and ensures compliance with federal/national banking regulations.
2. The BaaS / CaaS Middleware: Technology providers (such as Marqeta, Stripe Issuing, Unit , or Treasury Prime ) sit between the platform and the sponsor bank. They provide the developer-friendly APIs, ledgers, and tokenization tools required to create cards and process transactions.
3. The For-Benefit-Of (FBO) Account: User funds are stored in an FBO (or omnibus) account at the sponsor bank rather than on the platform’s balance sheet. The BaaS provider manages the sub-ledgers tracking individual user balances.
4. The Card Networks & Printers: Payment rails like Visa or Mastercard authorize the transaction flow, while personalization bureaus manufacture and ship physical cards.

Core Responsibilities of the Platform vs. Partner

Key Benefits for the Platform

• Speed to Market: Launching a card program takes weeks or months via APIs instead of the years and tens of millions of dollars required to charter a bank.
• Monetization: Platforms earn a cut of the interchange revenue generated every time a user swipes or taps their card.
• User Stickiness: Keeping users within your ecosystem for their financial needs dramatically increases platform retention.

If you're looking to build a card program, tell me:

• Are you targeting consumers or businesses (corporate expense cards)?
• Do you need physical cards, virtual cards, or both?

I can help outline the regulatory considerations or suggest specific infrastructure providers for your use case.

A platform can offer cards without becoming a bank because the platform usually isn't legally issuing the card. A regulated bank or licensed financial institution sits behind it as the issuer.

The common model looks like this:

                  ┌─────────────────────┐
                  │ Your Platform       │
                  │                     │
User ────────────►│ App / UX / APIs     │
                  │ Card controls       │
                  │ Ledger / product    │
                  └─────────┬───────────┘
                            │
                     Issuing processor
                            │
                  ┌─────────▼───────────┐
                  │ Sponsor / Issuer    │
                  │ Bank                │
                  │                     │
                  │ Legal card issuer   │
                  │ Regulatory duties   │
                  │ Network membership  │
                  └─────────┬───────────┘
                            │
                       Visa / Mastercard
                            │
                         Merchant

1. The bank is the actual issuer

A bank provides its BIN (Bank Identification Number) and its relationship with the card network. The non-bank platform operates the card program under that arrangement. This is generally called BIN sponsorship.

So if your company says:

"We'll give every customer a Visa debit card."

the legal reality can be closer to:

"Our bank partner will issue a Visa card to the customer, and our platform provides the technology and customer experience."

The card can have your brand on it, even though the regulated issuer is another institution.

2. An issuer processor connects everything

There is often another company between you and the bank/network.

For example:

Platform → issuer processor → sponsor bank → Visa/Mastercard

The processor handles things such as:

• creating virtual/physical cards
• authorization messages
• card status
• transaction webhooks
• PIN/tokenization infrastructure
• network connectivity
• settlement files

Modern issuing platforms expose this through APIs. For example, Stripe's documentation describes its issuer-processor model as connecting the card network, card manufacturer and BIN sponsor, while the platform controls its authorization logic and transaction infrastructure.

3. Your platform can control the product without being the bank

This is the important distinction.

You can potentially control:

• who gets a card
• card limits
• virtual vs. physical cards
• spend categories
• rewards
• UI/UX
• transaction approval logic
• freezes/unfreezes
• expense management
• notifications
• your own ledger

while the regulated institution handles the activities that legally require its license.

That's why companies can build products that feel like banking without holding a banking charter.

4. But "not a bank" doesn't mean "not regulated"

This is the part that often gets misunderstood.

The sponsor bank isn't simply "renting you its license." It remains exposed to regulatory and network risk. U.S. banking regulators explicitly recognize bank-fintech arrangements and expect banks to manage risks arising from them.

Depending on the product and jurisdiction, responsibilities can include:

• KYC/KYB
• AML/sanctions screening
• transaction monitoring
• fraud controls
• consumer protection
• dispute/chargeback processes
• safeguarding/handling customer funds
• network rules
• regulatory reporting
• recordkeeping
• suspicious-activity reporting

Exactly who performs each function is determined by the contracts, regulatory framework, product structure and jurisdiction.

5. There are actually several different models

For example:

The exact structure varies significantly by country. In the U.S., for example, a fintech can use a bank sponsor; in other jurisdictions, a regulated electronic money institution or payment institution may be able to issue certain types of cards without being a traditional bank.

A concrete example

Imagine you're building a SaaS platform for businesses.

You want:

"Every business gets a $10,000 corporate spending card."

You don't necessarily need to charter a bank.

Instead:

1. Your platform signs up the business.
2. Your compliance stack collects the required information.
3. Sponsor bank approves the program/customer according to its requirements.
4. Issuer processor creates the card.
5. The card uses the sponsor bank's BIN.
6. Your platform tells the processor: allow this card to spend $500 at this merchant.
7. Visa routes the transaction to the issuer/processor.
8. Your platform receives the transaction and updates its own UX/ledger.
9. Settlement occurs through the financial institutions involved.

The customer experiences your card, but legally and operationally there are several institutions underneath it.

The key business insight

If you're thinking about building such a platform, the hard part isn't actually manufacturing a Visa card or building a POST /cards API.

The hard part is determining where the regulated activity sits.

You essentially have to answer:

Who owns the customer relationship, who holds the money, who is the legal issuer, who bears credit/fraud risk, who performs KYC/AML, and who is responsible to the card network and regulator?

Once those responsibilities are properly allocated, a non-bank can build a surprisingly large portion of the user-facing financial product.

If you're considering this for a specific platform/business model, I can also break down the architecture—including sponsor bank, BIN, processor, ledger, custodial/FBO accounts, KYC, settlement, interchange, and exactly where the platform can make money.