关系感知型收件箱防火墙，在财务团队动账之前拦下 AI 生成的供应商与薪资诈骗。

1. AI 已经把鱼叉式钓鱼的前期调研和个性化自动化了，所以财务团队在高风险收件箱流程里，不能再靠粗糙的语言破绽识别诈骗。
2. 这个品类正在从静态过滤转向建立在发件人、基础设施和业务上下文上的自主调查，这正好支撑一款面向高风险请求的信任图谱产品。
3. 邮件仍然是最常见的入侵入口，所以 CISO 和财务控制负责人有充分理由为一款能在下游系统被碰到之前就拦住高额付款欺诈的产品批预算。
4. Fortune 500 和大规模邮箱部署说明，AI 原生邮件防御已经在生产环境里被市场接受，这降低了一个工作流垂直切入者的品类教育风险。

催化因素。 Ocean 的发布说明，AI 原生钓鱼防御已经成了一个真实存在的企业品类，原因正是攻击者如今能大规模做个性化，而买方也越来越看重建立在业务上下文上的自主调查。

产品部署在 AP 和薪资团队使用的 Microsoft 365 或 Google Workspace 共享收件箱里，持续建立一张活的图谱：包括已批准供应商、历史请求模式、常见审批人、已知银行账户，以及可信沟通路径。当邮件要求更新银行信息、发起紧急付款或改道薪资时，系统不会只给这封邮件打一个钓鱼分数；它会先判断请求背后的业务关系到底像不像真的，只要关键上下文是新的或对不上，就先冻结动作。用户会看到调查摘要、具体异常原因，以及带引导的带外核验流程，例如已验证回拨或 ERP 交叉核对，资金没法在核验前流出。安全团队因此多了一层交付后的响应能力，专门处理那些绕过过滤器的诈骗；财务团队则继续在自己已经习惯的收件箱工具里工作。

差异化。 大多数邮件安全产品都在网关层优化检测，而 AP 自动化工具默认收件箱本身已经可信。这个公司赢的正是两层之间的空档：它理解一条请求背后的真实供应商关系和财务流程，只要上下文和过往现实对不上，就直接卡住动作。时间一长，护城河会变成一张专有图谱——里面是被验证过的业务关系、异常模式和处置结果，绑定的是最贵的欺诈时刻，而不是泛化的垃圾邮件标签。

待完成任务

flowchart LR
  Buyer[Controller and CISO] --> Pain[AI-crafted payment and payroll scams]
  Pain --> Product[Relationship-aware inbox firewall]
  Product --> Outcome[Blocked fraud and faster verified approvals]

高管要点

• AI 生成的 BEC 越来越像真的，但财务团队仍然在共享收件箱里手动执行最危险的那个瞬间。
• 真正的市场空档不是再做一个宽泛邮件过滤器，而是在资金流出前，记住可信供应商、审批人和银行账户变更模式的工作流专用动作控制。
• 宽泛邮件安全厂商已经拿住安全预算，Trustpair 这一类厂商已经拿住付款核验预算，所以创业公司必须作为两层之间的低摩擦桥梁落地。
• 滩头市场足够大，能支撑一门像样生意；但采用与否，取决于能否证明低误报和审计级证据，而不只是更好的检测分数。

市场定义

这个机会落在云邮件安全、BEC 响应和 AP 反欺诈控制的交叉点上：软件盯住财务共享收件箱，判断一条请求是否符合既有业务关系，并在发件人、审批路径或银行信息显得陌生时拦下或放慢执行。

用户与买方

主要用户是在 Microsoft 365 或 Google Workspace 共享邮箱里干活的 AP 负责人、薪资运营人员和安全分析师。经济买方通常是财务控制负责人或 CFO 授权代表；而 CISO 或安全总监会做技术赞助，因为问题同时牵涉欺诈、邮件安全和控制合规。

购买触发点

• 最近一次或差点发生的 BEC 事件——涉及银行账户变更、紧急电汇或高管冒充——会立刻把预算紧迫性拉满。 [4][5][6]
• 安全团队被员工上报邮件队列淹没时，更愿意买能把用户上报自动转成全组织防护的自动化。 [11][28][38]
• 围绕供应商主数据和付款变更的 SOX、审计或保险审查，会逼着财务控制负责人去买可审计的工作流执行控制。 [7][60]

支付意愿

同类云办公安全产品已经把定价跑到每用户每月个位数美元，而 FBI 报告的 BEC 损失仍以十亿美元计；只要这层控制能明确降低欺诈敞口和审计负担，一个五位数年费就站得住。 [5][6][37]

品类动态

增长信号 21.3% CAGR

验证信号

• Ocean 声称已经在企业生产环境里保护数十万个邮箱、每月处理超过十亿封邮件。
• 相邻的云办公安全产品已经公开给出每用户个位数美元定价，说明收件箱相邻控制这笔预算是存在的。
• AP 自动化仍是一个增长很快的品类，说明财务团队并不是拒绝工作流软件，而是在持续购买。
• Trustpair 围绕 AP 欺诈、付款核验和银行账户验证的定位，说明财务负责人愿意为降低变更请求欺诈风险买单。

监管与技术约束

• Microsoft 共享邮箱并发用户超过 25 人后可靠性可能下降，因此复杂财务团队往往需要更精细的分段设计。
• Full Access 和 Send As 这类委派权限如果没配对，邮箱可见性和动作控制都会残缺。
• Google 的 Gmail 委派访问仅限同组织委派人，而且并发上也有现实约束，这会直接影响 Google 部署方案。
• 面向 SOX 的买方想看到的是围绕供应商主数据、付款控制和异常处理的可审计证据，而不是不透明的黑盒判决。

竞争分成三层。Abnormal、Material、IRONSCALES、Mimecast 这类宽泛邮件安全厂商，主打大规模检测或处置可疑邮件；Trustpair 这类财务反欺诈厂商，则在更靠后的环节核验银行账户和付款文件。拟议中的创业公司只有在中间那一层站稳才有机会：离收件箱够近，能理解社会工程；离 AP 工作流也够近，能在高风险变更被执行前把它拦下。

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

• 宽泛邮件安全平台. 它们能做行为基线并广泛拦截 BEC，但优化重点还是消息检测和处置，而不是财务专用审批逻辑或银行账户变更闸门。
• 云办公安全平台. 它们保护的是 Microsoft 365 和 Google Workspace 上的邮件、文件与账户，重心在安全姿态和事件响应，不在 AP 工作流记忆。
• 付款核验厂商. 它们在收款方和银行数据核验上做得很强，但通常是在请求已经进入 treasury 或 ERP 流程之后才介入，而不是在第一封被社会工程操纵的邮件触点上。
• Microsoft 和 Google 原生控制. 委派、邮箱权限和邮件规则这些原语都在，但它们只是管理员工具，不是专门面向供应商和薪资欺诈的工作流控制。
• AP 自动化套件. 它们能把发票处理和审批流跑顺，但默认进入工作流的那封邮件本身已经可信。

这家公司一开始应该做成面向 AP 共享收件箱的关系感知型动作控制层，而不是再做一套宽泛的邮件安全套件。第一个客户，是一家总部在美国、700–2,000 人、多实体结构的软件、专业服务或医疗服务公司；它通过 Microsoft 365 共享收件箱，每月处理 150+ 次供应商银行账户变更或紧急付款请求。购买触发点通常是最近一次供应商仿冒险情、网络保险续保，或审计发现，暴露出邮件付款变更控制太弱。研究支撑了一个聚焦但可信的滩头市场：若公司能拿下约 120 个客户、ACV 约 $30k，第 3 年可对应 $467.3M TAM、$183.8M SAM，以及模型化的 $3.6M SOM。产品应先部署进一个共享收件箱，从供应商、审批人和银行信息历史里搭起信任图谱，只在请求是新的或对不上时要求留痕的带外核验。这里的刻意取舍是：先比网关厂商或 AP 套件更早卡住资金流出的那个瞬间，即便这意味着先不做广泛的员工邮箱保护，也不碰完整 AP 自动化。最大的反证风险有两个：一是财务控制负责人不愿接受额外的流程摩擦，二是现有厂商靠捆绑的邮件安全和付款核验能力已经解决了足够多的问题。输入里还没有钉死两个关键参数——目标收件箱每月真实请求量，以及市场能容忍的误报阈值——所以计划必须尽早验证。

问题

• AP 和薪资团队至今还在共享收件箱里做高风险决定，一封足够逼真的邮件就可能触发银行账户变更、紧急电汇或薪资改道。
• 安全邮件网关和 AP 系统各自覆盖了流程的一段，但都不真正掌握财务员工决定一条邮件请求能不能执行的那个瞬间。
• 人工回拨清单如果不能在截止压力下被稳定触发、并被保留下来作为审计证据，最后往往只剩控制表演。

解决方案

• 在 Microsoft 365 或 Google Workspace 共享收件箱里插入一层控制，建立由已批准供应商、历史审批人、已知银行账户和常见请求模式组成的信任图谱。
• 当一封邮件要求更新银行信息、发起紧急付款或改道薪资时，只要发件人、流程或请求结果是新的，就先卡住动作，再引导用户做已验证回拨或 ERP 交叉核验，然后才放行。
• 给出可解释的异常原因和可审计的核验记录，让财务控制负责人、CISO 和审计方都能复盘为什么这条请求被拦下或被放过。

为什么我们会赢

• 这个切口比宽泛的邮件安全更窄，却正对最贵的欺诈时刻；这里买方痛感最强、预算最急、ROI 也最好量化。
• 一张绑定供应商历史、审批行为和处置结果的跨请求信任图谱，比再做一个钓鱼分类器更难复制，因为它会随着每一次高风险工作流审查持续变强。
• 产品补的是现有网关和 AP 工具之间的空档，而不是要把它们整套换掉，所以部署摩擦更低，也符合财务控制负责人现在的采购习惯。

里程碑

flowchart LR
  Wedge[AP shared inbox wedge] --> MVP[Trust graph and action gating MVP]
  MVP --> Proof[Blocked fraud and audit evidence]
  Proof --> Expansion[More inboxes integrations and workflows]

创始团队

实验路线图

风险评估

必须成立的条件

• 至少一半合格目标客户，在险情、保险复核或审计触发后，会把 AP 共享收件箱欺诈控制当成有预算的问题。
• 以 Microsoft 365 为先的部署，必须在不依赖重服务的前提下，30 天内产出有用的信任图谱决策。
• 只要不必要拦截率控制在被覆盖合法请求的大约 10% 以下，财务控制负责人就愿意接受这套带闸门的工作流。
• 客户在要求更广泛的邮件安全平台替代之前，一个 AP 收件箱切口必须先跑出至少 $30k 年 ACV。
• 宽泛邮件安全和付款核验现有厂商在真实对比评估里，必须仍然给不出足够强的财务场景动作控制。

待尽调问题

• 目标 AP 收件箱里，每月真实会打进来多少高风险的银行账户变更、紧急电汇和薪资改道请求？
• 真实交易里，谁会在险情或审计发现后最先拍板：财务控制负责人、资金负责人，还是 CISO？
• 财务团队在绕过产品之前，能接受多高的误报率和多长的额外审批延迟？
• 首个生产部署里，最关键的集成到底是哪一个：ERP 供应商主数据、银行账户核验，还是基于身份/HRIS 的审批人映射？
• 在并排评估里，Abnormal、Material、Ocean 和 Trustpair 在财务工作流上各自还卡在哪？

模型合理性

• 收入引擎. 基准情景收入来自付费客户从 15 个增长到 96 个、且混合 ACV 为 $45K；它并不是靠夸大的服务收入或一次性费用撑起来的。
• 必须跑对的事. 试点到生产的转化率，必须守住或高于商业计划里 50% 的目标，Y2 到 Y3 的客户数爬坡才会真的发生。
• 模型会失效，如果. 如果销售周期被拉长到 120 天，或毛利率掉向 65%，模型会在跑到 Q4Y3 盈亏平衡前先把现金打穿。
• 下一轮融资证明点. 一个可信的 seed 故事，来自 15+ 个生产客户、两条活跃伙伴、30 天内完成部署，以及朝月度 EBITDA 盈亏平衡持续逼近。

情景

敏感性

flowchart LR
  TargetAccounts --> QualifiedPilots
  QualifiedPilots --> PayingCustomers
  PayingCustomers --> Revenue
  Revenue --> GrossProfit
  GrossProfit --> Cash

警示项: 基准情景在 Y3 末只有 96 个客户，低于商业计划里约 120 个客户的 SOM 情景。 · Y3 过半的净新增都集中在下半年，因此任何转化滑坡都会很快挤压现金。 · 70% 的毛利目标默认银行账户核验和 ERP 证据集成主要由伙伴交付，而不是内部重服务团队承担。 · 公司要到 Q4Y3 才摸到月度 EBITDA 盈亏平衡，因此在激进扩张前仍需要克制招聘，也大概率还要再融一轮 seed。

• 现有厂商捆绑销售. 网关厂商或 ERP 套件可能补上一些轻量级工作流检查，再借分发能力拖慢市场采用。 缓解措施: 把重心放在交付后的动作控制、已核验关系记忆，以及网关和 ERP 都不擅长掌握的跨收件箱工作流覆盖上。
• 财务流程摩擦. 如果核验步骤把延迟拉得太高，AP 团队在季末或紧急付款窗口可能会绕过产品。 缓解措施: 先只覆盖最危险的请求类型，正常流程不碰，并用极小的额外审批时间证明欺诈损失确实下降。
• 早期训练数据稀疏. 新客户一开始未必有足够多带标签的欺诈历史，模型很难在第一天就把关系和异常判断准。 缓解措施: 先用确定性的供应商、银行账户和审批路径检查给模型打底，再随着核验结果和分析师反馈逐步学习。