为采用 Kalshi 事件合约的对冲基金提供控制平面，用来执行规则、对账持仓，并在监管审视下稳健运行。

1. 机构使用增长已经快到让合规团队面对的不是探索性试点，而是真正的生产上线期限。
2. Kalshi 正在明确建设大宗交易和券商集成，事件合约很快就会接入主流机构工作流。
3. 现在大部分美国交易活动集中在一个场所上，这让标准化的外部控制层开始具备商业可行性。
4. 交易规模在上升，各州挑战仍在持续，这让临时拼凑的合规流程突然变得危险。

催化因素。 Kalshi 的机构交易量增长了 800%，同时还在推进大宗交易和券商集成；这意味着基金正好在监管审视加剧之际，从试验阶段走向生产阶段。

搭建一层位于 Kalshi、券商通道和基金既有 OMS 或内部执行栈之间的事件合约控制平面。产品先吸收合约元数据，把每个市场归到已批准的策略桶里，再按交易台、交易员、司法辖区和规模执行交易前限制，并为合规委员会留下清晰的审计轨迹。交易后，它把成交标准化成基金层面的敞口、情景和对账视图，让运营团队不用写定制脚本也能结账。报告层再生成规则例外、可直接交给外部律师的审查包和董事会级摘要，让事件合约项目在机构治理里站得住脚。长期看，这套数据模型还能支撑其他另类合约类型的组合分析与资金配置。

差异化。 大多数风险工具默认资产类别是固定的，而通用合规软件又无法理解合约特定的事件触发条件、结算逻辑或司法辖区灰区。这家创业公司的切口，是一套为事件市场量身打造的合约分类体系和规则引擎，把审批和对账直接接进机构交易工作流。随着它看到越来越多的合约、例外模式和治理决策，它会积累出一套更难被内部团队复制的专有规则与审计数据集。

待完成任务

flowchart LR
  Buyer[对冲基金 COO 或 CCO] --> Pain[事件合约的人工审批与对账]
  Pain --> Product[事件合约控制平面]
  Product --> Outcome[更快上线，同时保持机构交易合规]

高管要点

• 机构事件合约交易正在比治理栈适应得更快地走向真实运营。
• 最强的切口不在纯执行，而在围绕交易场所特定合约的规则配置、审批和对账。
• 真正的竞争更多来自相邻监控套件、交易场所原生能力和内部扩展方案，而不是某个直接的品类龙头。
• 监管模糊性既是最大风险，也是买家愿意为专用控制层付费的原因。

市场定义

一类软件，帮助机构用户在交易场所规则、券商工作流和内部风控规则之间，对事件合约交易进行审批、监控和对账。

用户与买方

初始用户是美国宏观基金、自营交易公司以及少数正在增加事件合约接入能力的券商里的风险、合规和运营负责人；预算买家通常是 COO 或 CCO，因为痛点在治理和可审计性，而不只是下单。

购买触发点

• RFQ、FIX、子账户和券商式工作流，会把探索性交易直接变成生产级审批问题，而表格根本扛不住。 [1][14][22][24][26][36]
• 券商分发让事件合约更容易进入投委会和法务团队视野，也把书面化控制要求的门槛抬高了。 [3][44][46][47]
• 监控话术和执法压力正在提高一项成本：如果没有明确权限和审计轨迹，就放交易员去用新合约类别，会越来越贵。 [9][10][58][59][60]

支付意愿

当买家本来就在为监控、市场风险和报告工具拨预算时，这笔钱最容易站得住脚；在这种前提下，只要能缩短上线审批、减少人工复核和对账，一套聚焦事件合约的控制平面就能支撑六位数年费。 [48][49][50][52][53][58][59]

品类动态

增长信号 Kalshi 上机构交易量六个月增长 800%（平台特定数据，不是品类 CAGR）

验证信号

• Kalshi 已经上线了 RFQ、报价、子账户、结算以及面向 FCM 的数据接口，看起来已经是实打实的机构级基础设施。
• Robinhood 和 Interactive Brokers 正在明确把事件合约解释为可用于对冲的金融产品，把分发范围扩展到 Kalshi 直连之外。
• 相邻合规厂商现在已经直接推预测市场监控方案，这本身就在验证专业治理痛点的存在。
• Kalshi 正在公开投入监控合作伙伴和执法流程，这会进一步加大买家对可自证控制能力的要求。

监管与技术约束

• 生产级部署必须把参与者筛查、内幕交易控制和敏感市场的类别专属规则一起考虑进去。
• 集成不只是下单接口：买家需要 API/FIX 覆盖 RFQ、订单、持仓、子账户、结算和实时更新。
• 实体开户、授权用户配置和 Advanced API/FIX 接入，都会在基金实盘交易前引入运营前置时间。

这个市场分散在交易场所原生 API、广义监控厂商、券商接入层和内部扩展方案之间。如果一家专业产品能真正掌握合约分类体系、交易前权限逻辑和交易后可审计性，而不是直接去替代执行或监控系统，就还有空间。

为什么现有厂商不会默认胜出

• 原生交易场所工具. Kalshi 已经开放了 RFQ、FIX、子账户、持仓和结算等能力，但这些更像交易接入的积木，而不是面向基金定制的规则审批和可直接交给律师的审计工作流。
• 通用监控厂商. Eventus 和 Solidus 能监控市场滥用和市场风险模式，但它们并不是围绕策略级权限、实体专属规则手册或事件合约月末结账对账来构建的。
• 券商原生接入. Robinhood 和 Interactive Brokers 的作用在于分发和解释事件合约，但它们的工作流重心是客户接入和教育，而不是覆盖交易台、用户和法律解释差异的机构治理。
• 内部扩展方案. 基金当然可以把交易场所 API 接进自己的 OMS 备注和脚本里，但这样规则变更、受限人员逻辑和结算映射都得自己维护。

事件合约交易正在从探索性使用跨进机构生产工作流，但审批、监控和月末结账流程，今天仍主要靠法律备忘录、表格和内部脚本在撑。这家公司卖的是一层控制平面，面向正准备首次实盘部署 Kalshi 的美国宏观对冲基金和自营交易公司；这些客户在合规批准交易前，必须先拿到机器可读的权限、限额和审计证据。产品一开始故意切得很窄：只做 Kalshi 事件合约的交易前规则执行和交易后对账，不去替代 OMS、执行系统或大型监控套件。它的 GTM 打法围绕一个明确触发点展开：当基金开启实体开户、Advanced API 或 FIX 接入、RFQ 或券商连接时，COO 或 CCO 要么把控制流程正式化，要么就只能阻止上线。因此，定价应从六位数年费 SaaS 订阅加实施费起步，因为买家在为治理和运营风险下降买单，而不是为散户式订单流买单。最强的证据来自交易场所势能、美国流动性集中、机构工作流基础模块和清晰可见的监管推力；最大的缺口则是，真正处在近期活跃试点中的基金到底有多少，而不是只是在旁边关注这个赛道。如果这个客户池很浅，公司就该保持精干，把规则引擎产品化后迁移到相邻的受监管微型衍生品工作流，而不是硬押一个纯 Kalshi 的结局。

问题

• 在评估实盘事件合约交易的基金，今天依然依赖人工法律审查、表格权限和邮件审批，因为既有风控与合规栈并不能很好地给交易场所特定合约做分类和控制。
• 随着 Kalshi 增加 RFQ、券商、子账户和结算工作流，面对更大的仓位规模、月末结账要求和监管审视，人工控制会迅速变得脆弱。

解决方案

• 交付一层控制平面，把 Kalshi 的市场元数据转成机构自定义的策略桶、交易员权限、司法辖区规则和交易前敞口限额。
• 把成交、持仓和结算标准化成对账与审计输出，让合规和运营团队能更快批准上线，也能在不写定制脚本的情况下完成结账。

为什么我们会赢

• 产品直接瞄准拦住生产落地的真正瓶颈——规则审批和对账——而既有厂商更多盯着交易场所接入、监控告警或通用合规流程。
• 一套可重复使用的合约分类体系，加上不断积累的例外处理和治理数据，会随着新增上市合约、客户规则决策和接入交易台而持续升值。

里程碑

flowchart LR
  Wedge[第一批生产级 Kalshi 基金上线] --> MVP[规则与对账 MVP]
  MVP --> Proof[两家基金完成生产部署]
  Proof --> Expansion[券商模块与相邻交易场所扩张]

创始团队

实验路线图

风险评估

必须成立的条件

• 未来 12 个月内，至少有 10 家目标美国基金或自营交易公司已经上线或即将上线事件合约。
• COO 或 CCO 这类买家会把审批速度和可审计性视为值得单独拨预算的痛点，而不只是试点期的临时麻烦。
• 专业供应商相较内部脚本，能实质性缩短合规审批时间。
• Kalshi 或券商工作流的增长能持续足够久，让专业厂商在既有厂商反应过来前先拿下多家客户。
• 如果只做 Kalshi 的市场停滞，这套规则引擎也能迁移到相邻的受监管事件产品或微型衍生品上。

待尽调问题

• 有多少点名基金处在真实实施阶段，而不是只停留在探索？
• 到底是哪些具体控制缺口，让买家放弃既有的 OMS、监控或表格流程？
• 买家更偏好独立控制平面，还是既有供应商提供的嵌入式模块？
• 哪些合约类别在内部审批里摩擦最大，因此最适合成为第一批产品模板？
• Kalshi 未来自己用原生机构治理功能吃掉这个切口的可能性有多大？

模型合理性

• 收入引擎. 基准场景下的收入，来自创始人在第 1 年拿下的 2 个共创客户，按 $240K 综合 ARPU 变成 Q4Y2 约 7 个等效生产客户、Q4Y3 约 11.6 个。
• 必须跑通的前提. 公司必须尽快证明 COO/CCO 这类买家愿意为独立控制层买单，才能支撑第 2 年的首个 GTM 招聘。
• 模型失效条件. 如果销售周期比计划晚约 15%，模型会损失约 $335K 的第 3 年收入，并在下一轮融资前出现现金转负。
• 下一轮融资证明点. 一个站得住脚的种子轮故事是：在现金跌破约 $0.55M 之前，做到 6-8 个生产客户、1 条券商或顾问转介渠道，以及首个相邻交易场所规则试点。

情景

敏感性

flowchart LR
  TargetAccounts[目标账户] --> PaidPilots[付费试点]
  PaidPilots --> ProductionCustomers[生产客户]
  ProductionCustomers --> SubscriptionRevenue[订阅收入]
  SubscriptionRevenue --> GrossProfit[毛利润]
  GrossProfit --> Cash[现金]

警示项: 基准场景下，第 3 年末 EBITDA 仍为负，因此公司大概率还需要一轮 seed 融资，才能走到自我供血增长。 · 客户数之所以按“等效生产收入单位”建模，是因为付费试点和实施较重的第一批合同在早期会把服务收入和 SaaS 收入混在一起。 · 市场仍然围绕一个交易场所高度集中，因此监管或平台变化对需求和留存的打击，可能会比 P&L 里显示出来的更快。

• 监管边界收紧. 如果监管方或各州显著收紧可交易合约范围，初始市场增长就可能低于预期。 缓解措施: 先聚焦监管边界清晰的机构使用场景，并把规则引擎做成可迁移到相邻受监管事件产品和微型衍生品上的形态。
• 对 Kalshi 平台依赖过重. 过度依赖单一交易场所，会让公司暴露在 API、定价或分发变化的风险下。 缓解措施: 尽早通过券商和 OMS 工作流接入，这样无论事件合约通过哪里分发，产品都还有价值。
• 机构可能自研. 大型基金可能会选择扩展既有风控系统，而不是采购新供应商。 缓解措施: 先拿下中端市场的共创客户，把长尾的合约分类和审计工作流产品化，并证明比内部自研更快拿到审批。