The embedded finance market is no longer a bet on the future. According to research from BCG, the total addressable market for embedded finance across North America and Europe sits at $185 billion, spanning payments, capital solutions, accounts, and card issuing. That number has grown 25% in two years. Every platform company is entering this space. Most are discovering the hard way that their issuing infrastructure can’t keep up.
The issuing partner market has largely solved one problem: getting platforms to launch. Sandbox access, onboarding support, a feature list that checks the right boxes. What it hasn’t solved is what happens after go-live, when transaction volume climbs, product complexity grows, and the platform needs its issuing infrastructure to behave less like a vendor and more like a foundation.
The gap isn’t in getting started. It’s in what the infrastructure can actually do under pressure. In 2026, card issuing is best understood as a layer within a broader financial system, impacting how efficiently card programs can be built, scaled, and adapted over time.
Below is a capability gap analysis drawn from what embedded finance platforms actually need from a card issuing platform, and where most BaaS issuing partners fall short.
Gap 1: Configurability That Goes Below the Surface
Most issuers offer configuration. Few offer it at the depth platforms actually need. Spend controls, velocity limits, merchant category restrictions, and card behavior that can be modified in real time via API, without a support ticket, a custom development engagement, or a product roadmap request from a vendor that has 40 other clients ahead of you.
True configurability should align with the specific business needs of the platform, ensuring the card issuing solution supports unique requirements and operational goals.
The distinction matters: configuration as a UI feature versus configuration as a programmable layer. The first gives you a set of pre-built toggles. The second gives you the ability to build whatever your business logic requires and change it on the fly. For platforms building differentiated products, only the second version is useful at scale.
Gap 2: Real-Time Decisioning and Authorization Controls
Platforms building embedded finance products need authorization logic that reflects their business rules, not the issuer’s defaults. That means real-time transaction decisioning, dynamic controls tied to user state or account balance, and the ability to set or adjust credit limits in real time based on user activity. This enables platforms to act on a transaction while it’s in flight, not after it settles.
Issuers evaluate applicants’ creditworthiness by reviewing credit scores, income levels, and financial history. These factors inform credit limit decisions and impact transaction approval.
Most issuers apply static rule sets or batch logic. Real-time control is either unavailable or treated as a custom development project. Platforms end up accepting the issuer’s logic as the ceiling, or they build around it, which adds cost, latency, and a new point of failure to every transaction.
Gap 3: An Embedded Ledger Built for Multi-Product Complexity
Card issuing doesn’t exist in isolation on a modern platform. It sits alongside accounts, wallets, and money movement workflows. The issuing partner’s ledger architecture either supports that complexity or it doesn’t.
Legacy ledger design treats card issuing as a standalone product. A charge goes out, a balance changes, a settlement file arrives. That model breaks down the moment a platform needs to support multiple funding sources, virtual accounts, balance logic across account types, or real-time reconciliation between card spend and other financial activity.
An embedded ledger built for the platform layer makes all of that native, not bolted on. The data model supports multi-product complexity from the start, which means platforms can build more sophisticated products without rebuilding their financial infrastructure every time they add a new capability.
Virtual accounts allow businesses to manage multiple accounts under a single umbrella, simplifying financial management and reporting. They can be integrated with existing financial systems for real-time visibility and seamless transactions. Using virtual accounts can also enhance cash flow management by allocating funds to specific purposes or projects without opening multiple bank accounts. Businesses can issue virtual cards linked to virtual accounts, providing employees with secure spending options while maintaining control over budgets and spending limits.
Gap 4: Full Card Platform Capability Without Integration Sprawl
Platforms need flexibility across card types and use cases, whether that’s physical cards, virtual cards, single-use cards, or cards tied to specific spend policies or user types. The issuing partner should support the full range of card capabilities from a single integration point. This includes enabling a diverse range of card products (credit, debit, and virtual cards) within a comprehensive card program to facilitate payment processing and customer engagement.
The problem is that many issuers built their infrastructure around a narrow set of original use cases. Expanding beyond that, whether into new card types, different funding structures, or more complex card program logic, means new integration work, new agreements, and new points of failure. Integration flexibility is essential for supporting new card products and efficiently scaling card programs, ensuring seamless onboarding and alignment with business growth.
Every capability that requires a separate integration is a separate risk surface, a separate vendor relationship to manage, and a slower path to market for the platform. Card issuance should be a single, flexible capability, not a patchwork of add-ons.
With advanced API integration, businesses can issue physical or virtual cards with their own branding at scale, streamlining operations and enhancing financial management.
Gap 5: Multi-Rail Support Without Operational Tax
Platforms want to move money across ACH, RTP, wire, and other payment rails without stitching together a different vendor for each one. Most issuing partners support card rails natively and treat the rest as referrals or integrations that the platform is responsible for managing. To meet modern business needs, platforms must be able to process transactions efficiently across different payment rails, ensuring smooth and secure payment workflows.
The result is familiar: every additional rail is a new contract and a new latency problem. The platform pays a coordination tax in engineering time and operational overhead just to move money the way its users expect.
Multi-rail support built into the issuing infrastructure means that capability is available through a single integration. No middleware. No additional vendor relationships for what should be table-stakes money movement.
By bridging acquiring and card issuing, businesses can optimize cash flow and ensure funds flow seamlessly between different parts of the business.
Gap 6: Program Management Without a Middleware Layer
Card program management, cardholder servicing, dispute handling, and compliance workflows are often handled by the issuing partner in name only. Issuers must navigate complex frameworks like KYC (Know Your Customer), AML (Anti-Money Laundering), and PCI DSS data security standards to ensure regulatory compliance. In practice, platforms are stitching together the issuer, a BaaS middleware layer sitting between them and the actual infrastructure, and their own ops team to cover the gaps. Integrated card management features are essential for comprehensive program oversight, enabling financial institutions to efficiently manage card lifecycles, authorizations, and fraud detection within a unified platform.
That middleware layer exists because issuing infrastructure wasn’t built to expose direct control to the platform operator. Platforms pay for it in three ways: added cost on every transaction, added latency, and added risk because every intermediary is another potential point of failure. A true BaaS issuing partner eliminates the middleware by building direct program management into the platform layer from the start. Streamlined dispute resolution processes and robust risk management systems are also critical to ensure compliance, operational security, and effective handling of financial disagreements.
Card issuers are responsible for confirming that cardholders have adequate funds or credit, processing card transactions, settling previously approved transactions, and handling chargeback requests.
Gap 7: Scalability That Doesn’t Require Starting Over
Platform businesses are not linear. Volume spikes. New verticals get added. Products evolve in ways that weren’t scoped in the original contract. Issuing infrastructure should handle that expansion as a matter of course, not as a trigger for a new commercial conversation.
The reality is that structures and technical limits that worked at 10,000 cards often don’t hold at 500,000. Platforms discover this after the fact. What looked like a scalable partnership at launch becomes a limitation at exactly the moment when momentum is highest and disruption is most costly. Infrastructure that scales with the platform, is a foundational requirement that doesn’t get enough attention in the evaluation process.
Gap 8: Transaction Monitoring and Transaction-Level Visibility in Real Time
Reconciliation, fraud monitoring, and product analytics all depend on transaction data, and they depend on it now, not in an end-of-day settlement file. Platforms need transaction-level data in real time, surfaced in a format they can actually use. Effective fraud detection mechanisms are essential for card issuers, who monitor for unusual activities. This allows them to freeze cards temporarily if suspicious behavior is detected.
Legacy reporting infrastructure was built for the issuer’s needs: regulatory reporting, settlement, internal reconciliation. Platforms end up building their own data layer on top of it to get the visibility they need to operate. That’s an engineering cost that compounds over time and grows with transaction volume. Real-time data access built into the issuing platform means platforms can run their operations on live data, not yesterday’s file.
The Card Issuing Partner Evaluation Checklist
Before signing with a card issuing platform, ask these eight questions directly. Vague answers are an answer.
- Configurability: Can card controls, spend limits, and program behavior be modified in real time via API?
- Authorization controls: Does the platform support real-time decisioning against your business logic, or does the issuer apply static rules?
- Ledger architecture: Was the ledger built for multi-product complexity, including virtual accounts and multiple funding sources, or does it treat card issuing as a standalone module?
- Card capabilities: What card types and program structures are supported natively, and what requires a separate integration or agreement?
- Rail support: Which payment rails are natively supported, and which require additional integrations or third-party vendors?
- Program management: Does the platform expose direct program management to the operator, or does it require a middleware layer to access core functionality?
- Scalability: How does pricing and infrastructure capacity change as card volume grows, and what triggers a commercial renegotiation?
- Data access: Is transaction-level data available in real time, and in what format is it surfaced?
The Issuing Market Has a Scale Problem
Getting a card program live is no longer a differentiator. The issuing market has mostly solved for launch. What it hasn’t solved for is the platform that needs its infrastructure to grow with it. It needs to adapt to new product requirements, and behave like a foundation rather than a vendor relationship to be managed.
The platforms building embedded finance that actually works are not the ones who found the fastest path to their first card. They’re the ones who built on infrastructure designed for the platform layer from the start.
Qolo was built for that layer. If you’re evaluating issuing infrastructure for your embedded finance product, we’d like to show you the difference. Request a demo and get started.
Source: BCG, “Embedded Payments and Finance: A $185 Billion Opportunity,” October 2024.
