EntityGate

Problem

要解决什么问题？

今天多数金融机构与平台在做企业客户 onboarding 时，真正拖慢速度的并不是收资料本身，而是 analyst 需要把来自工商注册、官网、公开新闻、股权图谱、交易模式描述和内部政策规则的碎片信息，手工拼成一个是否可信的判断。最痛苦的地方有四个：第一，很多企业主体结构复杂，受益所有权穿透需要反复查找与比对；第二，所谓“业务核验”往往依赖 analyst 凭经验判断公司网站、联系方式、经营描述和地区暴露是否可信；第三，即便得出了判断，还要把理由写成 audit-ready 的说明，方便后续复核；第四，客户一旦通过，后续持续监测又经常与初审脱节，导致机构只能不断重复调查。同一个流程里，速度、审慎、合规留痕和人力成本彼此拉扯，结果要么放行太慢影响收入，要么审查太松留下风险敞口。

目标用户

• 负责企业客户开户、商户入驻或高风险账户复审的银行、支付公司、B2B fintech 与 crypto 平台合规负责人
• 需要在增长速度与审慎审查之间做平衡，但不希望 headcount 随 case volume 线性增长的 compliance ops / onboarding ops 团队
• 为 marketplace、embedded finance 或跨境资金流平台设计风控与合规流程，希望把主体尽调做成标准化能力的产品与平台团队

Signals

来自新闻的关键信号

• spektr 明确把融资叙事放在『消灭金融服务里的人工合规工作』上，而不是泛化 AI 助手，说明市场已经开始奖励真正替代 analyst 手工步骤的 agent 基础设施。
• 新闻点名 KYC 与 KYB，意味着机会不在通用合规软件，而在开户、商户入驻与持续监控这些高频、可量化、离收入很近的环节。
• 产品强调 specialized AI agents 可以研究公司、解释信息、核实业务并生成结构化风险评估，说明核心价值在“完成工作”，不是只做信息汇总。
• 公司已在 Pleo、Santander Leasing、Mercuryo、Phantom、Monta 等客户中上线，证明这不是实验室演示，而是可嵌进真实金融流程的操作层。
• spektr 允许机构自定义 onboarding 和 monitoring 流程，再把 agent 网络嵌进去，这释放出一个很强的产品信号：赢家会是嵌入式执行层，而不是又一套孤立系统。
• NEA 领投 2000 万美元 Series A，说明资本也在押注一个判断：未来合规团队最值得付费的不是 dashboard，而是能把审查吞吐量与审计质量一起拉高的 execution engine。

Stack

当前技术栈

• 第一阶段先用静态展示页验证“主体信任操作面”这条叙事是否能打动银行、支付平台、marketplace 与 fintech 合规团队，再收集 demo 申请。
• 产品端优先做 Web 控制台，不替代现有 case management，而是围绕 entity、ownership graph、evidence item、decision memo 和 review run 五个核心对象组织体验。
• 后端可用 Postgres 或 Supabase 存储主体档案、图谱关系、证据快照与决策日志，再配合 job queue 执行批量公开数据抓取与定期监测。
• AI 层重点不是对话体验，而是 evidence-first 的 company research、文档理解、实体归一化、风险理由压缩与决策解释，保证每个结论都能追溯到来源。
• 集成层优先连接企业注册数据源、制裁/PEP 名单、网站抓取、内部 CRM / case system 与审计归档工具，让 EntityGate 成为现有流程上的智能执行层。
• 权限与治理设计必须从 Day 1 就考虑 reviewer、manager、auditor 三类角色，确保任何 AI 建议都可以被人工覆盖、注释和回放。

Risks

主要风险

• 如果公开主体数据覆盖不足或实体归一化做得不准，系统可能把不同公司混淆，反而放大误判风险。
• 金融机构对 AI 生成判断的容忍度有限，若解释链不够清晰，产品很容易被降级成“只能参考、不能依赖”的附属工具。
• 不同国家和行业的 KYC / KYB 规则差异很大，早期若想一口气覆盖所有地区，实施复杂度会迅速上升。
• 合规团队已有成熟 case system 与审批层级，若产品不能很好地嵌入现有流程，而是要求全面替换，落地阻力会很高。
• 一旦系统在高风险客户上给出误导性建议，带来的不仅是 false positive 成本，还可能是真实的监管与罚款暴露。