Post-trade break engine for brokerages launching institutional crypto, reconciling venue, clearer, and custodian books.

1. EDX is funding trading, clearing, settlement, and global operations together, so institutional crypto volume can scale faster than distributors' internal post-trade teams.
2. FlowConnect makes it easier for brokerages and banks to turn on digital-asset access without building their own stack, which shifts the bottleneck from connectivity to allocation and reconciliation.
3. Because the infrastructure is being sold on traditional-market expectations, buyers will expect equities-style controls around breaks, allocations, and books before they scale crypto programs.
4. The trust-bank and regulatory-footprint push gives compliance-heavy institutions a path to go live now, which turns custody-ready books-and-records control into an immediate budget line.

Catalyst. EDX is simultaneously funding trading, clearing, settlement, FlowConnect, and an OCC-trust custody footprint, so institutions can add crypto access faster than they can build a matching post-trade operating layer.

Build a post-trade control plane that ingests execution fills from institution-only venues, normalizes asset and account identifiers, and applies allocation rules for each client sleeve or legal entity. The platform matches those records against central-clearing and qualified-custody data, flags quantity, price, or settlement-instruction breaks, and opens role-based exception workflows before books are finalized. It also generates client confirms, finance-ready end-of-day files, and audit evidence showing how each fill moved from execution through custody. The first product is intentionally narrow—same-day allocation and reconciliation for outsourced spot crypto—but the same data model can extend into financing, margin, and cross-venue treasury workflows.

What's different. Venue providers, clearinghouses, and custodians each own their own leg of the workflow, but none is incentivized to be the neutral system of record across all three. Traditional brokerage back-office vendors assume batch settlement, familiar security identifiers, and no wallet-state complexity, while crypto-native exchange tooling rarely serves broker-dealer control requirements. By sitting at the break point between execution, clearing, and custody, this company can accumulate proprietary mapping rules, client-allocation logic, and exception histories that become more valuable as customers add accounts, venues, and asset types.

Jobs to be done

flowchart LR
  Buyer[Brokerage ops lead] --> Pain[Manual crypto allocations and reconciliation]
  Pain --> Product[Post-trade break and allocation engine]
  Product --> Outcome[Scale institutional crypto without middle-office sprawl]

Executive takeaways

• [6][7][9][10][30][60] Institutional crypto go-to-market is moving faster than operations teams can adapt: EDX is funding clearing and settlement, Prometheum is enabling broker-dealers to clear crypto in traditional accounts, and CME has already extended regulated crypto derivatives to 24/7 trading.
• [11][12][1][2][58][59] The bottleneck is operational, not connectivity: SEC and FINRA guidance has improved the participation path, but books-and-records, auditability, and exception handling still sit with the broker-dealer.
• [15][17][19][21][23][37] Competition is real but fragmented. Talos, Fireblocks, Copper, Paxos, and BitGo each own part of the workflow, yet the neutral client-allocation and cross-book reconciliation layer remains weakly served.

Market definition

[7][8][14][19][24][30] The relevant market is post-trade control software for institutional crypto brokerage programs that sit above venue, clearing, custody, and internal books. The job is to allocate fills, reconcile records, surface breaks, and generate audit-ready evidence before books close.

Customer and buyer

[30][31][58][59] Day-to-day users are digital-asset operations, brokerage-technology, finance operations, and compliance teams inside broker-dealers and private-bank brokerage platforms. The economic buyer is typically the COO, Head of Digital-Asset Operations, or Head of Brokerage Technology because the pain shows up as breaks, delayed books, audit burden, and launch friction rather than as alpha.

Buying triggers

• The first live venue/custodian launch or correspondent-clearing agreement forces daily client allocation and reconciliation workflows into the open. [7][8][9][30][31]
• Weekend and 24/7 markets make batch middle-office processes visibly inadequate once clients expect always-on execution and settlement readiness. [24][32][60]
• Compliance, audit, or custody reviews require durable stock records, control evidence, and searchable post-trade audit trails. [1][2][11][12]

Willingness to pay

Budget is most likely to come from brokerage-technology modernization, custody/compliance readiness, and post-trade risk reduction rather than from a speculative crypto line item; the ROI case is fewer breaks, less manual data gathering, faster close, and cleaner audit evidence. [31][58][59]

Category dynamics

Growth signal 133% CAGR in adjusted stablecoin volume since 2023 (proxy for always-on digital-asset settlement demand)

Validation signals

• EDX raised $76 million to expand trading, clearing, settlement, product development, and global operations.
• Prometheum launched correspondent clearing, custody, and trading for broker-dealers and RIAs and cleared ETH directly in a brokerage account.
• Ripple Prime integrated with EDX around net settlement, collateral management, and capital-efficient prime workflows.
• CME moved crypto futures and options to 24/7 trading and saw more than 7,200 contracts trade over the inaugural weekend.

Regulatory & technical constraints

• Broker-dealers touching crypto asset securities still need defensible possession or control, stock records, counts, annual audits, and durable communications records.
• Off-exchange settlement stacks do not share one authoritative book: delegated balances, exchange-calculated P&L, and partner-platform allocations all need normalization.
• Crypto markets operate 24/7 while many brokerage operations and finance systems remain batch-oriented and business-hours centric.
• Cross-border expansion will face uneven stablecoin, custody, and crypto-intermediary frameworks even if the U.S. path improves.

[15][17][19][21][23][58][59] Competition is converging from multiple adjacent stacks: front-to-back trading systems, wallet and treasury control platforms, off-exchange settlement networks, and regulated brokerage infrastructure. The default substitute remains spreadsheets, portal exports, and adapted legacy middle-office workflows until volumes or auditors make that operating model fail.

Why incumbents do not win by default

• Trading and portfolio platforms. Talos can cover execution, portfolio, and some settlement workflows, but its center of gravity is the broad institutional trading stack rather than a neutral tri-party break engine tuned for broker-dealer books and records.
• Wallet and treasury control platforms. Fireblocks is strong on wallet governance, connected venues, and secure movement of assets, but the customer still has to map venue, clearer, custodian, and internal-ledger state into one client-allocation truth.
• Custody and settlement networks. BitGo, Copper, and Anchorage each reduce counterparty risk and improve settlement efficiency, but each is optimized around its own custody and settlement leg instead of being the neutral exception-management layer across the full workflow.
• Regulated brokerage and clearing infrastructure. Paxos and Prometheum validate that broker-dealers want regulated crypto brokerage infrastructure, but these providers are aligned to powering brokerage rails rather than acting as an independent controller above multiple venues and custodians.
• Legacy middle-office stacks. Traditional post-trade platforms already sell to banks and brokers, but they are built around established securities workflows and are not yet the default operating system for 24/7 crypto exceptions, custody state, and wallet-linked settlements.

Crypto Posttrade Break Engine should be built as a U.S.-first post-trade control plane for broker-dealers and private-bank brokerage platforms that are turning on institutional spot crypto through outsourced venues and qualified custodians. The first credible customer is a regional broker-dealer or private-bank brokerage platform that has already chosen one venue and one custodian, is moving from pilot trades to live client allocations, and cannot close the books cleanly with spreadsheets and portal exports. The immediate pain is not exchange access; it is allocating fills to the right client sub-accounts, matching venue, settlement, custody, and internal-book records, and producing audit-ready evidence before close in a 24/7 market. The product should therefore start as a paid launch deployment for one provider pattern and then convert into annual software once the customer relies on it for daily exceptions, same-day close, and books-and-records support. Research suggests a real but still early software category, with an estimated $315.0M TAM, $112.5M beachhead SAM, and $8.4M year-3 SOM, plus a plausible expansion path into confirmations, financing, margin, reporting, and eventually tokenized-securities middle office. Why believe: infrastructure providers are accelerating institutional crypto launch readiness, while no named competitor clearly owns neutral client allocation, cross-book reconciliation, and audit evidence for broker-dealers. Why doubt: the current corpus does not quantify actual break frequency, median time to close, or direct willingness to pay for a standalone neutral layer before venues and custodians bundle enough baseline workflow. The first 90 days should therefore be spent collecting live exception logs, proving onboarding time for one venue and custodian pattern, and converting at least one paid launch deployment into annual production.

Problem

• Launch-stage broker-dealers and private-bank brokerage platforms can now buy crypto execution, clearing, and custody through outsourced providers, but they still have to allocate each fill to the right client sleeve and reconcile venue, clearer, custodian, and internal books before close.
• The default workflow is spreadsheets, CSV exports, adapted equities tools, and email escalation, which creates books-and-records risk, slows same-day close, and forces operations headcount growth exactly when firms want to scale institutional crypto programs.

Solution

• Deliver a neutral post-trade control plane for one venue, one settlement or clearing leg, one qualified custodian, and one internal books export that normalizes identifiers, maps fills to client sub-accounts, and surfaces quantity, fee, price, or settlement-instruction breaks before books are finalized.
• Package the first deployment as a launch-readiness implementation plus exception workflow with audit-ready evidence, then expand inside the account to more entities, endpoints, asset classes, and adjacent post-trade workflows.

Why we win

• Venue, custody, wallet, and trading vendors optimize their own leg of the workflow, while generic post-trade stacks are not designed for 24/7 crypto settlement and custody-state complexity; the neutral reconciliation layer is the gap between them.
• Each customer deployment creates reusable mapping tables, exception playbooks, and benchmark data on break types and settlement timing that improve onboarding speed and make the product harder to replace than a point integration.

Milestones

flowchart LR
  Wedge[Launch-stage broker-dealer crypto post-trade wedge] --> MVP[One venue plus one custodian allocation and break engine]
  MVP --> Proof[Same-day close and audit-ready evidence]
  Proof --> Expansion[Provider-neutral digital-asset middle-office OS]

Founding team

Experiment roadmap

Risk assessment

What must be true

• Launch-stage broker-dealers must experience enough recurring allocation and reconciliation pain that a neutral control layer beats adding one or two operations hires.
• At least half of early paid pilots must convert to annual contracts above $200k ARR because the workflow repeats every trading day and during every audit.
• One venue plus one custodian plus one internal-book pattern must cover enough of the day-one pain that onboarding stays under roughly 60 days.
• Provider-neutral exception handling must remain meaningfully better than bundled venue, custody, or wallet modules for multi-provider customers.
• The product must expand from spot post-trade into adjacent middle-office workflows before the initial launch beachhead saturates.

Open diligence questions

• What do anonymized exception logs from 3-5 launch-stage broker-dealers show about break frequency, break types, and time to close?
• Which budget owner actually signs first: COO, brokerage technology, operations, or compliance?
• How often do target customers run one provider pair versus multiple venue, prime, and custody relationships, and how soon does that complexity appear?
• What exact features would make Talos, Fireblocks, BitGo, or Paxos good-enough substitutes in the first year?
• Can the company land through CSV and read-only workflows first, or do buyers require deeper ledger and ticketing integrations before paying?

Model sanity

• Revenue engine. Base revenue is driven by moving from 3 paying logos at Y1 exit to 28 by Q4Y3 while blended annual value rises from pilot-heavy pricing to about $270K per mature production logo.
• Must go right. The model only works if one venue-custodian pattern really onboards in 60 days or less so gross margin can rise toward 70% before the company adds a broad sales bench.
• Model breaks if. The downside case and sales-cycle sensitivity show that slower launch triggers or services-heavy onboarding can push cash close to $0.1M before the seed-ready proof point is secure.
• Next-round proof. The next financing case is 8-9 production logos, two active channel partners, and repeatable sub-60-day onboarding by month 24, which is exactly what the $2.5M ask is sized to fund with buffer.

Scenarios

Sensitivity

flowchart LR
  TargetAccounts[Target launch-stage accounts] --> PaidDeployments[Paid launch deployments]
  PaidDeployments --> ProductionLogos[Annual production logos]
  ProductionLogos --> EndpointExpansion[Second endpoints and workflow expansion]
  EndpointExpansion --> Revenue[Revenue]
  Revenue --> GrossProfit[Gross profit]
  GrossProfit --> Cash[Cash and runway]

Flags: The base case still assumes the company reaches 28 paying logos by Q4Y3 inside a niche U.S.-first beachhead, so channel-partner execution is the fastest way this model can miss. · customersEop includes paid launch deployments as well as annual production contracts, so recurring-only production logos trail the headline count through most of Y1 and slightly at the month-24 milestone. · Gross margin reaches the 70% target only if data normalization, audit-pack setup, and weekend exception playbooks become templated rather than remaining bespoke services. · The researched SOM implies roughly 30 customers at about $280K ARR, but the base case underwrites 28 logos at about $270K to stay below the full aspiration. · Cash is modeled as EBITDA, so enterprise procurement timing, pilot prepayments, or customer-specific implementation costs could shift actual cash by a few hundred thousand dollars versus the simplified roll-forward.

• Adoption pace lags the signal. Institutional distributors may still move slower than the funding headlines suggest, delaying the first wave of customers. Mitigation: Start with firms that have already chosen one venue and one custodian, then sell into the mandatory launch window between pilot connectivity and live client allocations.
• Venue or custodian bundling. EDX, a qualified custodian, or a brokerage-platform vendor could add a basic reconciliation module and compress the initial wedge. Mitigation: Stay neutral across venues and custodians, focus on client-level allocation and exception workflows, and win where customers need one system across multiple providers.
• Integration and data-model complexity. Heterogeneous APIs, exports, and asset identifiers could make deployments slow and expensive if the product tries to cover too many stacks at once. Mitigation: Launch with a narrow read-write workflow for one venue/custodian pattern, standardize a canonical schema, and productize implementation playbooks before broadening coverage.