面向区域性银行和信用合作社的 agent 例外清理 OS——把按揭和 HELOC 档案在不靠人工返工的情况下推进成可决策文件包。

1. 银行已经在为可量化 ROI 的自动化买单，所以例外清理产品卖的是成本和吞吐，不是空泛的 AI 叙事。
2. Fiserv、Encompass 和 MeridianLink 的更深集成，让叠加层软件第一次真正可部署——客户不用先换整套核心系统栈。
3. 99.8% 字段准确率和 10x 审核提速，说明狭窄的生产工作流已经跨过了实时贷款档案运营所需的内部信任线。
4. 4 天清掉 600 笔贷款积压，说明积压事件是非常具体的预算触发器，不是抽象的效率目标。

催化因素。 Saris 的融资、与在位系统栈的集成，以及生产级准确率指标，说明银行现在已经相信：狭窄的 agent 工作流可以碰真实贷款档案。例外清理因此第一次成了能单独立预算的痛点。

产品接上银行的 LOS、文档仓库和核心数据，不要求机构替换现有系统。每来一份档案，系统都会按产品、网点和政策画像生成一张动态条件清单，再把提交的文件和抽取出的字段，与 Fiserv、MeridianLink、Encompass 里银行已知的数据逐项对比。像过期工资单、未签字披露、缺失保险页、借款人属性不一致这类常规差错，不再躺在分析师收件箱里，而是直接变成结构化跟进任务和面向借款人的请求。人工审核员只看那些确实需要判断的升级件，同时能看到触发例外的精确证据和政策规则。时间一长，公司会沉淀出一套专有数据：哪些例外清得最快、哪些网点最容易制造返工、哪些政策步骤最吃掉周期。

差异化。 这不是通用银行 copilot、OCR 供应商，也不是一堆 RPA 脚本外包。真正能守住的，是放贷机构专属的例外图谱：哪几类文件组合能满足哪条政策规则、什么差异可以安全自动放行、谁必须批准 override、以及日后面对审计或检查时要补哪类证据。这套运行图谱会在客户和产品之间越滚越厚，而现有核心系统、BPO 公司和通用 agent 平台都不擅长把它拼出来。

待完成任务

flowchart LR
  Buyer[按揭运营负责人] --> Pain[不完整贷款档案造成积压]
  Pain --> Product[例外清理 OS]
  Product --> Outcome[更快形成可决策档案，并保留审计轨迹]

高管要点

• 通用文档 AI 和完整贷款发起系统之间，确实空着一个可信切口：银行仍需要一套懂政策的例外清理层，能跨 LOS、核心系统、文档和沟通层跑起来。
• 最可信的滩头市场，是那些已经在跑 MeridianLink、Encompass 或 Fiserv、又想在不做核心系统迁移的前提下先把积压压下去的区域性银行和大型信用合作社。
• 无论按揭量回升，还是利率锁定带来 HELOC 周期，这类需求都成立，所以问题并不绑定某一种利率环境。
• 产品只有在“可审计、可治理”上做得足够明显才会赢；第三方风险、QC 和标准对齐本身就是产品的一部分，不是采购环节的附带文书。

市场定义

面向按揭与 HELOC 运营团队的软件：把不完整或互相冲突的贷款档案，转成与政策挂钩的例外队列；再把常规问题自动清掉，同时为每个动作保留可审计的证据链。

用户与买方

一线用户是区域性银行和大型信用合作社里的按揭运营负责人、HELOC 运营负责人、QC 经理和集中式预承保团队。经济买方通常是按揭运营负责人、消费金融 EVP，或对周期、人手、转化率和审计准备负责的 COO。

购买触发点

• 单笔贷款成本持续走高、又想在不增审核员的情况下做大产能，让人工例外处理很快被拿上 ROI 审视台。 [18][4][5]
• 按揭量回暖和 HELOC 需求上来，都会突然推高档案审核、条件追踪和借款人跟进工作。 [16][17]
• 贷后 QC 规则和缺陷率压力，让放贷机构在意的不只是速度，更是每次档案决策能不能说清。 [24][27]
• 数字化放贷升级和代理渠道交付要求，正把买方推向那些能接进现有 LOS 栈的工作流软件。 [11][25][32]

支付意愿

付费意愿是成立的。放贷机构已经在为“降低单笔发起成本、压缩周期、避免内部自研”买单，因此一层聚焦的例外清理软件，比宽泛的 AI 平台销售更容易讲清预算。 [18][2][7]

品类动态

增长信号 20.0% projected 2025-2026 mortgage originations growth

验证信号

• Saris 公开声称，银行工作流可实现 70% 任务自动化、具备可审计动作，并带来明确的生产率提升。
• MeridianLink 披露的 Saris 客户结果包括 99.8% 字段准确率、10x 审核提速、3x 处理能力，以及 4 天清掉 600 笔贷款积压。
• Blend 的案例表明，区域性银行愿意为消除人工工作流摩擦的数字化放贷升级拨预算，而不是内部自研。
• Freddie Mac 估算，更强的数字化能力每笔贷款最多可节省 $1,700，说明运营效率确实能和预算直接挂钩。

监管与技术约束

• HMDA 报送和公平放贷审查，要求按揭申请与承保数据的处理必须结构化且站得住脚。
• 跨机构第三方风险指引，抬高了任何自动化关键银行工作流供应商的尽调门槛。
• GSE 贷后 QC 要求放贷机构锁定高风险贷款并记录复核方法，这反过来强化了可追溯例外处理的必要性。
• 按揭数据交换和下游兼容性高度依赖 MISMO 等标准组织，因此产品数据模型必须能干净映射到现有行业 schema。

竞争按层分散。LOS 和核心系统厂商握着系统记录；数字化发起套件优化借款人漏斗；文档 AI 厂商优化抽取和条件生成；承保引擎自动化信用决策。真正空着的，是给存款类放贷机构用的跨系统例外编排：懂政策、能发起后续动作、会做人机升级、还能留下适合检查的审计轨迹，而且不要求替换现有系统。

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

• 云平台. 超大云厂商已能提供基础文档抽取和分类，但距离放贷机构特有的政策逻辑、网点级流程和审计级运营控制，还差得很远。
• 贷款发起系统. LOS 厂商很强于做系统记录，但它们自己的叙事更偏端到端发起流程，因此仍给专业化例外清理叠加层留下空间。
• 核心处理商. 与核心系统相连的贷款工具擅长拿数据和定价，却不是那种跨渠道处理文档差异、借款人跟进和例外证据的 agent 补救层。
• BPO 与人工运营. 外包商和代理伙伴能吞工作量，但不会沉淀成可复用的放贷机构政策图谱，也不会立刻生成会越用越强的软件型审计轨迹。

这家公司应该先从美国区域性银行和大型信用合作社的按揭、HELOC 档案例外清理层做起——前提是这些机构已经在 MeridianLink 或 Encompass 上跑流程，底下连着 Fiserv 等现有核心系统。最急的痛点不是通用文档进件，而是那些反复堆积的不完整、互相冲突、又带政策敏感性的档案队列：它们拖慢审批、抬高加班和 BPO 成本，也让管理层暴露在 QC 与审计压力下。第一版产品应是一套只读、按政策映射的工作流：识别低风险例外、起草跟进动作，只把真正需要判断的案例升级给人工，并为每份档案留下证据轨迹。GTM 应围绕付费试点展开，触发点是积压暴涨、网点扩张或审计发现，因为这些时刻既有预算紧迫感，也能量出清晰的前后对比。只要公司能成为那个“知道哪些例外可以放、需要哪些证据、并且能在 LOS、核心系统、文档和沟通层之间跑通”的系统，就有机会赢。护城河不在 OCR，也不在通用 agent，而在放贷机构专属的例外图谱、override 历史和由真实生产工作流沉淀出的基准数据。需要谨慎的点主要有三个：集成拖累、银行对自动清理的信任，以及滩头市场里是否真有足够多机构具备足以支撑年合同 $300k+ 的队列密度。前 12 个月因此要同时证明两件事：低风险例外可以在几乎不被审核员推翻的前提下被清掉；以及付费试点能在主流系统组合上稳定转成正式生产部署。

问题

• 区域性银行的按揭和 HELOC 运营团队，至今还要在 LOS 队列、电子表格、邮件和核心系统数据之间手工清不完整档案；一旦积压上来，放款转化就变慢，还会逼出加班或 BPO 成本。
• 银行还需要单档案级别的证据，去应对 QC、审计和第三方风险审查，所以黑箱自动化或通用 OCR 根本解决不了治理负担。

解决方案

• 在以 MeridianLink、Encompass、Fiserv 为中心的流程之上叠一层按政策映射的例外引擎：识别缺失或冲突条件、起草下一步动作，只把政策例外交给人工。
• 为每一次自动放行、跟进和升级都生成完整审计证据日志，让管理者能把吞吐提升拿给 QC、合规和检查团队讲清楚。

为什么我们会赢

• 围绕按揭和 HELOC 工作流的专项例外图谱，比通用文档 AI 更能守住：它沉淀的是放贷机构特有的规则、跟进顺序和 override 模式。
• 从只读、低风险条件类目起步，既能压低集成和信任摩擦，又能交出明确的积压与周期改善——这是在位厂商和 BPO 都很难干净呈现的价值。

里程碑

flowchart LR
  Wedge[Mortgage and HELOC exception clearance] --> MVP[Read-only policy-mapped MVP]
  MVP --> Proof[Backlog reduction and audit-ready evidence]
  Proof --> Expansion[More workflows and deeper integrations]

创始团队

实验路线图

风险评估

必须成立的条件

• 428 家滩头机构里，至少 30% 的集中式队列量和人力痛点足够大，能支撑年合同 $300k+。
• 第一版发布能自动清理或预处理至少 20% 的低风险例外，且审核员推翻率低于 1%。
• 只读集成加证据导出，就足以在拿到完整写回权限之前证明 ROI。
• 试点客户买单的核心是压积压和审计可解释性，而不是等 LOS 供应商自己把原生自动化补齐。
• 在主流 MeridianLink/Encompass + Fiserv 组合上，产品能在 90-120 天内完成实施。

待尽调问题

• 在按揭和 HELOC 队列里，哪些例外类型出现最频繁，且最适合先自动清理？
• 目标放贷机构里，真正符合每周档案量和集中式团队画像的有多少？
• 风险与合规团队在批准 agent 式清理正式生产前，究竟要求什么样的证据包？
• 当银行使用非 Fiserv 核心系统或定制文档仓库时，实施复杂度会增加多少？
• 为什么银行会买这层叠加软件，而不是延伸 Ocrolus、CANDOR、Coviance 或 LOS 原生流程？

模型合理性

• 收入引擎. 基础情景在 Y3 做到 $5.4M 收入：客户数从 Y1 的 2 个付费账户扩到 Q4Y3 的 22 个，同时靠工作流和量级扩张抬升混合 ACV。
• 必须做对的事. 试点必须足够快地转成正式生产，才能在 Q4Y2 做到 9 个客户；因为现金低点出现在伙伴扩张真正降低烧钱之前。
• 模型会失效的条件. 如果采购拖延让 Q4Y3 客户数低于 18 个，或毛利率长期停在 67% 左右，下行情景就会轻微跌破零现金，并被迫更早融资。
• 下一轮融资证明. 只要公司能拿出 8-10 个正式生产 logo、两套可复制系统组合，以及现有机构内的扩张收入，下一轮融资故事就最扎实。

情景

敏感性

flowchart LR
  Leads[线索] --> QualifiedPilots[合格试点]
  QualifiedPilots --> PaidPilots[付费试点]
  PaidPilots --> ProductionCustomers[正式生产客户]
  ProductionCustomers --> SubscriptionRevenue[订阅收入]
  SubscriptionRevenue --> GrossProfit[毛利润]
  GrossProfit --> Cash[现金]

警示项: 基础情景下，现金低点仍出现在模型转正 EBITDA 之前，所以试点转化节奏的滑坡，比温和的成本超支更危险。 · 到 Y3 时，混合 ACV 已高于最初约 $300K 的切口，这要求公司真正做出工作流扩张，而不只是多签 logo。 · LTV/CAC 看起来非常强，主要因为模型把流失率按高粘性企业软件处理，但目前还没有真实留存数据。

• 集成拖累. 如果创业公司必须先深度打通 LOS、核心系统和文档系统，银行部署很容易在价值显现前就卡住。 缓解措施: 先用只读叠加层和一个例外密集流程起步，证明积压下降和周期改善后，再逐步加深集成。
• 自动化信任缺口. 如果贷款和合规负责人担心隐藏错误或审查压力，可能不愿让 agent 直接清条件件。 缓解措施: 让人工继续把关政策例外，给每一步动作都露出单档案证据，并先从容易验证的低风险条件类目开始。
• 在位厂商功能侵蚀. 一旦用例被验证，LOS 供应商或 BPO 服务商可能很快补上基础 AI 审核功能。 缓解措施: 胜负手放在跨系统例外编排和跨在位系统栈的审计级证据，而不是单纯文档抽取。