Mercury’s OCC Charter Moves It From Fintech Toward Direct Banking

Immad Akhund described Mercury’s OCC charter approval as the company’s move from “fintech to full banking.” The distinction he drew was operational: after more than two years of regulatory work, the approval allows Mercury to hold deposits directly and build lending products without relying on partner banks.

A TechCrunch article shown on screen used the same framing: “Mercury’s CEO on shifting from fintech to full banking.” Akhund called the approval “a massive milestone,” because it changes what Mercury can do inside its own structure. The capabilities he emphasized were direct deposit-taking and in-house lending products.

That matters because Mercury’s core customer base is startups, whose cash behavior is not the same as ordinary consumer or small-business banking. Startups often receive large deposits after fundraises and then spend those balances down over the following quarters or years. Akhund said Mercury is not taking duration risk with those deposits.

Jason Calacanis summarized the operating assumption: Mercury’s customers may need access to “a hundred percent of the funds” over the next one to two years. Akhund agreed, describing startup deposits as having “very high beta”: “Deposits fly in, deposits fly out.”

The risk, in Akhund’s telling, is that a bank can mistake a diversified set of startup accounts for a stable deposit base. He said the industry had previously assumed that startup deposits would average out across many companies: one startup raises money now, another raises tomorrow, and aggregate balances remain steady. He said that logic is only partly true because venture-backed startups move with the same funding cycle.

When markets are strong, Akhund said, “everyone’s raising and depositing money.” When markets are weak, “everyone’s drawing down money.” Calacanis connected that point to the previous two or three years, saying the startup industry experienced that pattern broadly and at unusual scale.

He compared the recent correction with earlier downturns, including the dot-com crash and 2008. In those earlier periods, he said, fundraising stopped for stretches of time. But in his view, the amount of previously raised and unspent startup capital entering the recent correction was different: “the money raised, and unspent was never in the hundreds of billions” in those earlier moments.

The banking point in Akhund’s explanation is that startup deposits cannot be understood only account by account. A single startup’s cash pattern is straightforward: raise money, hold it, spend it down. The harder problem is what happens across a portfolio of venture-backed companies when the funding environment changes.

Akhund’s objection to the simple diversification view was that startups are not independent in that way. They share a macro funding environment. In strong markets, many companies raise and deposit capital at the same time. In weak markets, many companies stop raising and burn through existing balances at the same time. The result is correlated deposit movement.

That is why Akhund emphasized that Mercury is not taking duration risk. He did not describe Mercury’s balance-sheet strategy in detail, but the principle he stated was clear: when customers may need their cash soon, and when many of them may need it under the same market conditions, the deposit base has to be treated as volatile.

The exchange puts Mercury’s charter approval in a more constrained frame than a simple graduation from fintech to bank. Akhund’s case is that Mercury can hold deposits directly and build lending products itself while still treating startup deposits as volatile and correlated. The opportunity is to bring more banking capabilities inside Mercury. The constraint is that the customer base can need liquidity quickly and collectively.

The charter is not only about deposits. Immad Akhund said Mercury has already offered venture debt “in a beta fashion” through partners, and that the company’s public application includes the ability to offer commercial lending products inside Mercury’s own bank.

Jason Calacanis framed the question through the traditional startup-finance model: banks generally do not give loans to startups; startups raise venture capital. Venture debt, in that model, comes alongside or after an equity raise. He described a typical structure as a startup raising $10 million and a venture-debt provider extending a $2 million or $3 million credit line against receivables or other assets.

Akhund said Mercury is “absolutely” working toward those kinds of products. But he did not describe venture debt as just another loan product attached to startup banking. His argument was that venture debt can make sense “if priced properly and underwritten correctly,” and that software can make the debt product better.

The examples Akhund gave were based on company operating patterns. A SaaS company could receive an MRR line tied to recurring revenue. A physical-products company, such as a CPG startup, could receive an inventory line. Akhund said Mercury already sees these cases. Calacanis separately described a more traditional venture-debt setup in which a credit line might be extended against receivables or other assets after a fundraise.

The product shift implied by the charter is therefore broader than replacing a partner bank. Akhund described a move from being dependent on partner banks toward a structure in which Mercury can hold customer deposits and offer commercial lending products through Mercury’s own bank. In his description, that means lending products organized around startup-specific operating signals: fundraises, SaaS revenue, MRR lines, and inventory needs.

Akhund’s narrower claim was that the charter approval is the step that enables Mercury to bring these products inside its own banking structure, and that venture debt and related commercial lending products are part of that path.

Avi Patel described Kled as an attempt to build “a truly open data marketplace.” A screenshot shown on screen displayed the Kled dashboard with the visible text “Kled Data Marketplace” and “Browse Categories,” presenting the product as a marketplace organized around discoverable data categories.

The immediate issue was a competitor Patel accused of copying Kled’s frontend. A post from Patel’s account was shown on screen with a side-by-side comparison of two similar interfaces. The visible text read: “Can’t believe a competitor literally copy-pasted our entire frontend. They even left our API keys in the source code. Unbelievable.”

Patel said the team learned about the site from users. His description was specific: the competitor had scraped Kled’s CSS and React components “entirely.” He said Kled called it out publicly because the copying was “so blatant.”

Patel’s point was concrete: he is building a data marketplace, and he said a competitor copied Kled’s interface so completely that Kled’s API keys were left in the source code. The API-key detail mattered because Patel was not only alleging a lookalike product; he was alleging a direct copy of Kled’s frontend source.