Corporate-Card Fintechs: A Structural Reference

The corporate-card fintech category emerged in the mid-2010s and grew rapidly through the late 2010s and early 2020s. Brex (founded 2017) was the first of the modern wave to scale, followed by Ramp (2019), Mercury (2017, originally a banking product with card features added later), Rho (2019), Divvy (2016, since acquired by Bill.com), Airbase (2017), Stripe Corporate Card (2019), and others. The category serves a customer segment that the traditional bank-issued business-card market underserved: small and mid-sized businesses that needed corporate-card features (no personal guarantee, deposit-based credit lines, accounting integration, employee-card management at scale) without requiring the corporate-banking-relationship overhead that traditional bank corporate-card products imposed.

For an applicant evaluating the category, the structural commonalities matter more than the marketing differences between specific issuers. Each of these products sits in roughly the same regulatory, banking, and underwriting framework, and the category-level features (no-PG, deposit-based underwriting, charge-card structure, accounting integration, virtual cards, expense-management software) are broadly similar across members. The choice between specific issuers is typically driven by the depth of accounting integration with the applicant's specific ERP, the relative reward economics in the applicant's spend categories, and the user-experience preferences of the founding or finance team.

The Regulation Z corporate-card carve-out

The reason the corporate-card category can exist with no-personal-guarantee structures and different fee mechanics is regulatory. Regulation Z (12 CFR Part 1026) implements the Truth in Lending Act and most of the Credit CARD Act. Most of Reg Z's consumer-protection provisions apply specifically to credit extended to consumers (defined as natural persons) for personal, family, or household purposes. Credit extended to a corporation, partnership, or other business entity where the issuer reasonably determines the credit will be used for business purposes falls outside the scope of most of Reg Z's consumer-protection requirements.

What this allows. A corporate-card product issued to a corporation is not bound by the CARD Act's fee-cap framework, by the consumer-credit disclosure timing requirements, by the consumer-credit dispute procedures, or by the personal-guarantee-disclosure obligations that personal-card issuers face. The issuer can structure the product to underwrite the corporation directly, with the corporation as the sole obligor, and price it according to commercial-credit norms rather than consumer-credit norms.

What this requires. The credit must actually be extended to the corporation, not to the founder or owner as an individual. The credit must be used for business purposes. The corporation must be a real legal entity with the capacity to be obligor under commercial-credit law. These conditions sound trivial; in practice they shape the product architecture of every fintech corporate card in the market, and they explain why these products require the applicant to be an entity with an EIN, why the application is in the entity's name, why the cardholder agreement is between the issuer and the entity, and why the personal-guarantee question is typically resolved at the application stage and not relitigated later.

The site's CARD Act and consumer protections reference covers the scope-of-coverage question in detail.

The sponsor-bank model

Every fintech corporate-card product is issued by a chartered US bank, sometimes called the sponsor bank, partner bank, or BIN-sponsor bank. The fintech is not itself a bank; it does not hold a national or state banking charter, it does not directly hold FDIC-insured deposits, and it does not directly issue card credentials registered with the Visa or Mastercard networks. The chartered sponsor bank provides those legal and regulatory components, and the fintech provides the customer-facing product, the underwriting and risk model, the technology platform, the customer experience, and the marketing.

The sponsor-bank model is publicly disclosed for each fintech corporate-card product. The card itself typically carries language identifying the issuing bank ("Issued by [Bank Name] pursuant to a license from Visa/Mastercard"). The cardholder agreement names the bank as the issuer and counterparty. The CFPB card-agreement database, where applicable, lists the bank as the issuer of record.

Why the model exists. Bank chartering is expensive and slow; building a fintech product on top of a chartered partner bank lets the fintech move quickly without acquiring its own charter. The sponsor bank earns fee income from the relationship; the fintech captures the customer experience and the equity-value creation. Each side specializes.

What can change. Sponsor-bank relationships are commercial contracts and can be renegotiated, transferred, or terminated. The corporate-card fintech market has seen several sponsor-bank transitions over the past several years, generally handled through cardholder-notification processes. The cardholder's relationship continues with the fintech; the underlying issuance bank may change, with associated card-number and BIN changes. For most cardholders the transition is transparent; for cardholders with substantial vendor-recurring-charge dependencies on the specific card number, the transition can be operationally awkward and is worth being aware of.

The structural implication. A fintech corporate-card relationship is, in legal substance, a relationship with the sponsor bank, layered with a product and software relationship with the fintech. Cardholders should be aware of who the sponsor bank actually is on any given product, which is disclosed in the cardholder agreement and on the card itself.

Deposit-based underwriting

The structural underwriting innovation that defines the corporate-card fintech category is the shift from credit-history-anchored underwriting to deposit-history-anchored underwriting. The mechanics matter because they explain why a startup with $5M of fresh venture capital can be approved for a $500K credit line by a fintech corporate-card issuer while being declined by a traditional bank-issued small-business card issuer with the same personal-credit profile.

The integration. The applicant grants the issuer read-only access to the business bank account, typically through Plaid or a similar account-data aggregator. The issuer's underwriting model can then see, in near real time, the deposit balance, the inflow pattern (size and cadence of deposits), the outflow pattern (size and cadence of expenses), and the volatility of the account.

The model output. The model computes the entity's repayment capacity directly from cash flow. A $400K monthly burn against $5M of cash implies 12 months of runway. A $200K monthly outflow against $1M of average balance and $250K monthly inflow implies a sustainable cash position. The credit line is sized as some fraction of these observed quantities, with the specific multipliers proprietary to each issuer.

The refresh cadence. The deposit data refreshes continuously through the bank-account integration. The credit line can move up as deposits grow (a startup that closes a fresh round sees its credit line scale shortly after the funds settle) or down as the runway shortens (a startup that has burned through most of its cash without fresh funding can see the line reduced). The dynamic nature of the line is a real feature, not a bug, of the deposit-based model.

The limit of the model. Deposit-based underwriting works for entities with substantial observable cash. It does not work for entities that have meaningful revenue but minimal cash balance (a high-velocity working-capital business that turns inventory faster than it accumulates cash), for entities with bank balances at a non-integrated institution, or for very early-stage entities pre-funding. These applicants either need to provide alternative underwriting signal (audited financials, term-sheet documentation for equity-based underwriting) or pursue a different product category.

The no-PG structural premise

The no-personal-guarantee positioning of most corporate-card fintech products follows directly from the Regulation Z carve-out and the deposit-based underwriting model. If the entity can be underwritten on its own cash flow, the personal guarantee from the founder is not needed to make the credit decision; if the credit is extended to the entity rather than to the founder personally, the PG is structurally inappropriate. The two pieces fit together.

What this means in practice. The cardholder agreement names the entity as the obligor; the founder signs in their capacity as an officer of the entity, not as a personal guarantor; the founder's personal-credit signal (if pulled) is for KYC purposes rather than for credit underwriting; on default, the issuer's recourse is to the entity's remaining assets, not to the founder's personal assets.

What can complicate it. Some fintech corporate-card products that are positioned no-PG have personal-guarantee clauses on smaller credit-line tiers, on applicants who fail certain underwriting criteria, or on applicants in the seed/early-seed phase before substantial cash has been deposited. The product's general no-PG positioning is the dominant case; the exceptions are real and are documented in the specific cardholder agreement that the founder actually signs. Reading the agreement at the time of application, rather than relying on the marketing summary, is the only way to confirm the operative structure.

The site's personal-guarantee reference covers the legal mechanics of the guarantee and the conditions under which the no-PG corporate-card category is accessible to specific entities. The site's VC-backed startup reference covers the application of the no-PG model to the venture-backed entity case in detail.

Accounting and ERP integration as the product wedge

The most consistent feature across corporate-card fintech products, and arguably the largest source of competitive differentiation between the category members, is the depth of integration with general-ledger accounting and ERP systems. The standard integrations include QuickBooks Online, Xero, NetSuite, Sage Intacct, and (for larger entities) the major enterprise ERPs.

What the integration does. Each card transaction is automatically pushed to the ERP at the moment of posting, with a recommended GL classification based on the merchant category and any custom tagging rules the entity has set up. The cardholder can attach a receipt photo and a business-purpose memo to each transaction directly in the card-platform mobile app. The ERP-side workflow (review, recategorize, approve) happens on the same record. Month-end close is materially faster than the manual reconciliation process that defines traditional bank-card statements.

Why this matters. For a business that processes hundreds or thousands of card transactions per month, the integration is the primary value of the corporate-card fintech category over a comparable traditional product. The reward economics on the corporate-card category are often less favorable per dollar of spend than on a well-optimized bank-issued business-card portfolio; the integration cost saving offsets that gap and often exceeds it for entities at scale.

The category members differentiate primarily on integration depth and on accompanying spend-management software features (approval workflows, policy enforcement, real-time spend visibility, employee-onboarding flows, virtual-card issuance, multi-entity support). For an applicant choosing between members of the category, the integration question for the specific ERP the entity uses is usually the dominant selection criterion.

The category members at a structural level

The category includes a number of named providers, each with the same general structural shape (sponsor-bank issuance, corporate-card category positioning, deposit-based or hybrid underwriting, accounting integration, no-PG on the marketed products) but different customer-segment focus, software feature depth, and reward structure. The site does not rank these providers; the editorial position is that the choice between them depends on the applicant's specific ERP, customer-segment fit, and feature requirements, none of which the site can evaluate in general.

Brex launched into the venture-backed startup market and has expanded to serve mid-market and enterprise customers, with a treasury account and software-spend-management product alongside the card.

Ramp launched with a spend-management software focus alongside its card, with savings-recommendation and procurement-automation features, serving both startups and mid-market.

Mercury launched as a business-banking product for startups, with cards added as part of the integrated banking experience.

Rho serves mid-market and growth-stage businesses with a treasury, banking, and card stack.

Divvy/Bill.com serves a small-and-mid business segment with a spend-management focus.

Airbase serves mid-market and enterprise with comprehensive spend-management features.

Stripe Corporate Card serves Stripe's ecosystem of online-business customers, leveraging Stripe's existing payment-processing relationships.

Float serves Canadian businesses primarily, with similar structural features.

The list is not exhaustive and the category continues to evolve. The structural pattern (sponsor-bank, deposit-based, no-PG corporate card with accounting integration) is the durable thread.

Trade-offs against bank-issued business cards

For an applicant comparing the corporate-card fintech category to traditional bank-issued business cards, a few trade-offs recur.

No carried-balance option. Most fintech corporate cards are structurally charge cards. The balance is due in full each cycle. A business that needs the option of carrying a balance during a working-capital cycle needs either a separate revolving credit instrument (bank line of credit, traditional business credit card alongside the corporate card) or needs to size operations against the always-pay-in-full constraint.

Deposit dependency. The credit line scales with observed deposits. A business that drains its operating account regularly may see its credit line reduced; a business with a meaningful deposit balance maintains its line. This dynamic is operationally different from a fixed-line bank card and requires management.

Bureau reporting may be thinner. Some fintech corporate cards do not report to either personal or business credit bureaus. For a business actively building a business-bureau file, the absence of reporting is a small disadvantage. The card-agreement disclosure or the issuer's customer materials state the reporting policy for any specific product.

Sponsor-bank stability. The sponsor-bank relationship is a real dependency. Sponsor-bank changes have happened and have produced operational friction for cardholders. The corporate-card fintech market is younger and more concentrated than the traditional bank-issued business-card market; an established Chase Ink relationship has more durability through any single corporate-action event than a fintech corporate-card relationship layered on a sponsor-bank arrangement.

Integration depth pays off at scale. The accounting-integration value is meaningful for businesses processing many transactions per month and is incidental for businesses processing few. For a 2-person consulting firm with 20 transactions per month, the integration value is small and a traditional bank card may serve as well or better. For a 50-person company with 2,000 transactions per month, the integration value is substantial and is often the dominant selection criterion.