Alpaca clears ~94% of tokenized US equity volume per its own December 2025 disclosure. Ondo, Dinari, Backed all route through them. Single-broker dependency is fine for an MVP. It's a structural risk for the next phase.
I get nervous when I read pitches that say "multi-broker" without showing the runbook. Every fintech founder I've sold infrastructure to in the last three years has a story about a payments processor, a BaaS vendor, or an issuer-processor going down for a day. They don't have to be told that single-vendor risk is real. They just need to see whether the vendor in front of them has actually built around it.
Every tokenized US equity in production today routes through Alpaca Securities. Ondo Global Markets, Backed Finance's xStocks, Dinari, and most newer entrants. Same broker-dealer underneath. Alpaca itself reports holding ~94% market share of tokenized US stocks and ETFs, with ~$480M in tokenized assets under custody (Alpaca, December 2025).
That's not a knock on Alpaca. They shipped the first developer-friendly broker-dealer API for global fintechs and then layered an Instant Tokenization Network on top. They built the picks and shovels. Everyone else, sensibly, bought them.
The next phase isn't going to look like this. Concentration is fine when the category is small. It becomes a structural risk when the category becomes systemically important, and I think tokenized US equities are on a path to systemic importance much faster than most builders are pricing in.
Operational. Brokers have outages. Ledger reconciliation issues. Software releases that break webhook delivery. The 2024 to 2026 era has been quiet on broker-side incidents because the volume is still small. At $1B+ tokenized AUC across the ecosystem, an Alpaca-side outage takes the entire tokenized US equity market offline simultaneously. There is no failover.
Commercial. A single upstream broker is a single counterparty in the pricing negotiation. As the broker's market power grows, the take rate moves in their favor. Every fintech that built on top of a single payments processor learned this lesson. Every fintech that built on top of a single payment-orchestration vendor learned the next-order version of it.
Regulatory. A single broker is a single regulatory exposure. If FINRA flags a clearing relationship for any tokenized-stock-specific reason, every downstream tokenizer freezes simultaneously. Concentration risk becomes regulatory contagion risk in this category, and that's the version that's hardest to recover from because nobody can engineer their way out of it.
Two prime brokers is harder to build than it sounds. Surface-level "we have multiple brokers" claims are usually empty in this category, and I think the implementation reality is worth describing because it tells you which vendors actually mean it.
At the order-routing layer, every mint or redeem has to route to the broker with better execution for that specific security at that specific moment. That's not load balancing. It's smart-order-routing with broker-specific quirks. Alpaca's fractional handling. IB's market-hour constraints. Settlement-cycle differences for less-liquid names. Fee schedules that vary by ticker.
At the reconciliation layer, a token issued against an IB-custodied share and one issued against an Alpaca-custodied share need to be fungible from the user's perspective. That requires a unified ledger that abstracts the broker-side custodian, with redemption logic that can fulfill from either side. Most multi-broker claims fall apart here. They're really "we have an Alpaca relationship and a backup IB account we don't actually use."
At the corporate-actions layer, dividends, splits, mergers, and tender offers are handled differently by every broker. A unified corporate-actions engine that normalizes events across IB and Alpaca is non-trivial to build. It's also the only way to give downstream developers a consistent API surface.
At the regulatory layer, each broker imposes different KYC pass-through requirements, different jurisdictional permissions, and different reporting cadences. A two-broker stack absorbs the complexity instead of pushing it onto the fintech.
The broker-to-exchange leg of any tokenized US equity transaction settles T+1 against DTCC, regardless of which broker custodies the underlying. Tokenization changes how the user experiences settlement. It doesn't change how DTCC settles. The broader category sometimes muddles this, and I think the credibility of every tokenizer depends on the distinction holding up under scrutiny.
What the user sees is instant. What the fintech sees on its books is instant. The broker-to-exchange leg is industry standard. None of those claims contradict each other. All of them require careful language.
If you're evaluating tokenized US equity infrastructure, I think single-broker dependency is fine for an MVP. It's a real risk for a production stack you intend to scale to millions of users or hundreds of millions in AUC.
The broker-redundancy question isn't "do you have two brokers." It's "what happens when broker A has an outage at 2pm on a Tuesday." If the answer is "we degrade to a backup we haven't tested," you have one broker.
Settlement claims should be tested the same way. Ask any infrastructure provider exactly which leg is instant and exactly which leg follows DTCC timelines. The vendors that can answer crisply on the first ask are the ones whose architecture is real.
Note on figures: the Alpaca market-share number is self-reported as of December 2025. Verify against current sources before quoting.
The two-broker architecture is harder to build, harder to operate, and the differentiator I'm most interested in stress-testing with early customers.
