Back to Blog

What Navan's S-1 Reveals About the Future of BYOC

What Navan's S-1 Reveals About the Future of BYOC

The corporate travel and expense management industry just got its most detailed look at the economics, architecture, and strategic logic behind Bring Your Own Card. When Navan filed its S-1 in September 2025 ahead of its Nasdaq IPO, it didn't just reveal the financials of a $537 million revenue business — it exposed the exact trade-offs, infrastructure decisions, and market dynamics that define BYOC as a category. For anyone building or operating a travel management or expense platform, the filing is required reading. Here's what it tells us.

Navan Connect: from product feature to strategic wedge

Navan launched Navan Connect in June 2023, allowing companies to link existing corporate Visa and Mastercard cards into its platform for real-time expense automation — without switching card programs. American Express followed in July 2025 through the Amex Sync Commercial Partner Program. On the surface, it's a simple value proposition: keep your existing cards, get Navan's software.

Underneath, the S-1 reveals something more deliberate. Navan Connect isn't just a feature — it's the company's primary mechanism for expanding its addressable market beyond companies willing to adopt a new corporate card. The filing makes clear that before Connect, Navan's expense management product required companies to use Navan-issued cards. That's a high-friction sales motion in a market where banking relationships are deeply entrenched, especially at midmarket companies with existing card programs they don't want to disrupt.

Connect removed that friction entirely. And the growth that followed tells the story: Navan disclosed over $1 billion in BYOC transaction volume since January 2024. The product now supports approximately 250 banks across 100 currencies, with major co-branded deployments through Citi, Citizens Financial Group, Rho, and Brex.

The interchange trade-off, laid bare

The most striking disclosure in the S-1 is also the most counterintuitive: Navan earns zero interchange revenue on cards enrolled through Navan Connect.

This is a deliberate, structural decision. When a company uses Navan's own corporate card, Navan earns interchange on every transaction — typically 1.5 to 2.5% of volume. When that same company connects an existing card through Navan Connect, the interchange flows to the original issuing bank. Navan gets nothing from the transaction itself.

Why would a company voluntarily forgo revenue on what is likely its fastest-growing product surface? The S-1 answers this directly through the revenue model: approximately 90% of Navan's revenue is usage-based (per-trip fees, supplier commissions, payment economics on Navan-issued cards), with roughly 10% coming from subscription fees — primarily from Navan Expense, which serves both Navan Card and Navan Connect users.

The strategic logic is that once a company's expense data flows through Navan — regardless of which card generated it — the platform becomes the system of record for spend visibility, policy enforcement, and reconciliation. That centrality justifies the subscription revenue and creates high switching costs at the software layer. As one former Navan executive put it publicly: Connect would cannibalize interchange, but they were giving most of it back as rebates to customers anyway.

The S-1 essentially describes a strategic paradox: Navan delivers high-value software without bearing liability for the underlying transactions. Credit risk, fraud exposure, and regulatory compliance all stay with the third-party issuer. Navan gets the data, the workflow lock-in, and the subscription revenue — with dramatically lower capital requirements and customer acquisition costs.

The infrastructure underneath: direct network integrations, not aggregators

The S-1 also confirms what Navan's engineering team has discussed publicly: Navan Connect is built on direct integrations with Visa and Mastercard at the card network level — not through consumer-grade financial data aggregators like Plaid, Yodlee, or MX.

This distinction matters enormously. Aggregator-based feeds typically operate through screen-scraping or Open Banking APIs connected to bank accounts, delivering settled transaction data with delays of one to several days. Navan's direct network integrations receive authorization-level data — the transaction notification arrives at the point of swipe, before settlement. This is what enables real-time policy checking, instant categorization, and same-day reconciliation.

Navan's CTO and co-founder Ilan Twig described the genesis publicly: the team approached Visa and found an existing API that could be adapted for their use case. Mastercard had no equivalent, so Navan's engineers effectively built one. The resulting infrastructure is patent-pending.

The S-1 also discloses a significant risk factor: Navan's BYOC capability depends on maintaining contractual relationships with card networks, and termination of those agreements "could harm Navan's business, financial condition, results of operations, and prospects." This is an unusually direct acknowledgment of concentration risk — and it reveals both the strategic value and the structural fragility of building direct network integrations.

What the S-1 tells us about policy enforcement on third-party cards

There's an important nuance in the filing that's easy to miss. On Navan-issued cards, the company acts as the issuer (through a banking partner) and has full authorization-level control — hard declines, MCC blocking, real-time spend limits. On BYOC cards through Navan Connect, the model is primarily advisory and notification-based.

When a BYOC card is swiped, Navan receives the authorization notification in real time and checks it against company policy. If the transaction violates policy, Navan can instantly notify the employee and flag the expense. But because Navan is not the issuer, it cannot unilaterally decline transactions on third-party cards. The degree of pre-authorization blocking depends on the issuing bank's participation level and bilateral agreements.

The S-1 claims third-party cards achieve "near-parity" with Navan's native cards. This is largely accurate for post-authorization workflows — categorization, reconciliation, analytics, and flagging. For pre-authorization hard controls, the parity claim is aspirational rather than fully realized across all configurations.

This is a meaningful distinction for platforms evaluating BYOC strategies. Real-time visibility and post-swipe policy enforcement are achievable today through network-level integrations. Pre-swipe hard blocking on third-party cards requires issuer cooperation that varies by bank and program.

What this means for the rest of the industry

Navan's S-1 didn't just describe one company's strategy. It validated an entire category — and simultaneously exposed the barrier to entry.

The filing confirms several things that were previously assumed but never publicly documented at this level of detail. First, BYOC works at scale. Over $1 billion in transaction volume, 250+ banks, 100 currencies, major co-branded bank partnerships — this isn't an experiment. Second, the interchange trade-off is real but manageable. Forgoing card revenue in exchange for software subscription revenue and expanded market reach is a viable business model, as long as the software layer is sticky enough to justify the subscription. Third, the infrastructure is hard. Multi-year engineering investments, patent-pending technology, direct network contracts with concentration risk — this is not something most platforms can replicate quickly.

That third point is where the implications get interesting. Navan built this over years with a dedicated team and deep network relationships. The S-1's own risk disclosures make clear how dependent the capability is on maintaining those relationships. For every other travel management platform, expense management company, or corporate card program considering BYOC, the question becomes: build or buy?

Building means replicating Navan's multi-year investment in direct Visa, Mastercard, and Amex integrations — each with its own technical requirements, compliance standards, and contractual frameworks. It means maintaining those integrations as networks evolve their APIs and data formats. And it means doing all of this while the market moves: platforms that already have BYOC capabilities are using them to win deals today.

The alternative is infrastructure. Companies that abstract the complexity of card network integrations into a single API can deliver the same real-time authorization data, multi-network coverage, and structured transaction fields — without requiring each platform to negotiate and maintain direct network relationships independently.

The market is bifurcating

Looking at the broader competitive landscape, the expense management market is splitting along a clear fault line. On one side: card-as-platform players like Ramp, Brex, and BILL/Divvy that require proprietary cards for full functionality, monetizing through interchange. Their software is subsidized or free, but they structurally cannot serve companies unwilling to switch card programs. On the other side: software-as-platform players like Navan that treat the card as a data input, not a revenue center, and monetize through subscriptions.

Navan's S-1 provides the financial proof that the software-as-platform model works. But it also reveals that building the infrastructure to support it is a multi-year, multi-million-dollar commitment with ongoing operational complexity.

For midmarket travel management platforms especially — where unmanaged spend is highest and card program control is lowest — the BYOC capability that Navan built represents both the competitive standard they need to meet and a cautionary tale about what it takes to get there independently.

The platforms that ship BYOC fastest will capture the market segment that card-first competitors structurally cannot reach. The S-1 made the opportunity undeniable. Now it's a question of execution speed.

See how Astrada works for
your platform's use case