尼泊尔银行专用的 FRAML 本地化操作系统，让银行快速落地本地 PEP 覆盖、FIU 达标报告和统一反欺诈管控。

1. 一家具名尼泊尔银行已经买单这个品类，证明预算和紧迫性是真实存在的，而不是假设。
2. 尼泊尔专属 PEP 覆盖和 NRB/FIU 报告是明确的采购标准，所以本地化才是护城河，不是可有可无的服务附加项。
3. 买家正在从单点合规工具转向统一 FRAML 工作流，把反欺诈和 AML 调查场景合并在一起。
4. 微服务部署和本地尼泊尔实施伙伴降低了采用风险，足以让银行从试点走向生产环境。

催化因素。 Machhapuchchhre Bank 现场选定了一套统一、基于微服务、尼泊尔本地化的 AML 系统，说明买家正在从通用合规工具转向本地化 FRAML 技术栈。

该产品叠加在银行的核心、渠道和交易系统之上，提供持续维护的尼泊尔 PEP 与实体数据包、NRB 和 FIU 报告模板，以及制裁、AML 和反欺诈的本地规则库。它把告警统一到一个调查员控制台，让可疑账户、支付模式和欺诈信号被当作一个案件处理，而不是分散在三个队列里。微服务架构让银行可以逐步采用各模块，并与本地实施伙伴一起在当地部署，与来源中描述的落地模式一致。随着时间推移，公司可以在相似银行之间对假阳性调优和调查工作流做基准对比，加深护城河。

差异化。 大多数 AML 厂商把最难的最后一公里工作丢给银行或本地系统集成商自己搞——把本地法规、PEP 覆盖和报告格式翻译成能用的操作流程。这家公司把这一层产品化为软件，而不是一次性服务，同时把反欺诈和合规案件并入同一工作流。它的优势会随着监管映射、本地数据覆盖和银行专属调优不断累积，而这些恰恰是通用全球平台难以逐个市场维护的部分。

待完成任务

flowchart LR
  Buyer[Head of AML at Nepali bank] --> Pain[Manual local PEP and FIU reporting]
  Pain --> Product[Nepal FRAML localization OS]
  Product --> Outcome[Faster compliant launches and unified investigations]

高管要点

• 需求信号是真实的，但很集中：Machhapuchchhre Bank 已经选择 ZIGRAM 的尼泊尔本地化统一 AML/反欺诈技术栈，证明只要把本地化和工作流统一打包在一起，尼泊尔市场上确实有买家愿意为这个品类掏钱 [16][17][20]。
• 本地化——而不是原始检测模型——才是可信的切口。FIU-Nepal 持续更新 STR/SAR 和 TTR 指引，APG 认为商业银行相对其他金融机构更成熟，但市场其余部分在筛查和监管上仍有缺口 [4][5][6]。
• 尼泊尔的数字化规模足以制造痛点，但单靠自身还撑不起风投级规模：NRB 名录上仍只有 20 家商业银行，但 2023/24 财年移动银行用户已达到 2465 万，QR 支付笔数增长 117.03% [1][2]。
• 横向的现有厂商已经覆盖了通用技术栈。Oracle、NICE Actimize、Tookitaki 和 ComplyAdvantage 都在卖监控、筛查或案件管理模块，所以创业公司必须以尼泊尔专属编排层的身份取胜，而不是再造一套通用全套件 [22][26][29][32]。
• 第三年 SOM 靠几家客户就能达到，但如果不做区域扩张，TAM 依然有限；本地市场天花板是真实存在的，除非尼泊尔能变成一套可复用的本地化引擎，服务南亚周边市场和支付机构 [1][2][36][37]。

市场定义

市场定义：为南亚金融机构本地化金融犯罪管控的软件与数据层——把客户和支付筛查、交易监控、反欺诈告警统一、案件管理，以及针对尼泊尔特定义务的 FIU 达标报告结合在一起，而不是通用的全球 AML 模块 [3][5][6][18][19][22][29][32][35]。

用户与买方

日常使用者是尼泊尔商业银行的 AML/FCC 运营负责人、相当于 MLRO 的团队，以及反欺诈运营经理；经济买家通常是负责数字渠道风险和监管管控的 CRO、合规负责人或 COO [1][2][4][16][17]。

购买触发点

• NRB/FIU 审查、内部审计，或可疑活动报告整改工作，会暴露出还有多少本地申报逻辑仍停留在表格和人工调查员手里。 [4][5][6]
• 数字支付增长推高了告警量，让现有人手更难同时管理分开的反欺诈、筛查和 AML 队列。 [2][14][15]
• 银行现代化或换厂商项目，为一层更轻的本地化方案，或与本地伙伴一起部署的统一 FRAML 技术栈，打开了机会窗口。 [16][17][20][21]

支付意愿

公开定价信息很少，但付费意愿是可信的：一家尼泊尔商业银行已经买下了这个品类，现有厂商把这些产品定位成企业级风险平台，相邻市场的案例研究关注的是扩充合规团队，而不是替换免费工具。预算科目已经存在于银行风险/合规现代化和支付筛查项目之中。 [16][17][22][25][26][38][39]

品类动态

增长信号 2025-2030 年全球 AML 市场复合年增长率 17.8%

验证信号

• Machhapuchchhre Bank 在 2026 年 7 月选择了 ZIGRAM，证明尼泊尔已经有真实银行为这个品类掏出预算。
• ZIGRAM 分别与 AMNIL 和 Dolma 建立了尼泊尔联盟，说明一套可用的实施生态已经存在。
• NRB 的报告显示数字渠道的采用规模，足以制造真实的 AML/反欺诈告警量和运营痛点。
• Tookitaki 和 ComplyAdvantage 都在宣传聚焦降低假阳性和扩充合规运营的案例研究，说明买家对改善工作流有真实需求。

监管与技术约束

• FIU-Nepal 在 2025 年 7 月更新的 STR/SAR 指引中，新增了类别和上游犯罪指标。
• TTR 规则在 2025 年 7 月修订，更新了分行业的阈值和豁免规定。
• APG 发现商业银行和较大金融机构的自动化筛查能力，比市场其余部分更强。
• NRB 的支付监管检查发现，部分支付机构存在尽职调查不足、AML-CFT 项目预算缺失的问题。

ZIGRAM 是最直接的威胁，因为它已经把尼泊尔本地化和统一技术栈、本地伙伴模式绑在了一起。Tookitaki 靠聚焦 APAC 的 FRAML 运营和降低假阳性竞争，ComplyAdvantage 靠 API/数据驱动的筛查监控竞争，NICE Actimize 和 Oracle 则靠广泛的企业级套件竞争。尼泊尔市场里真正的替代品，仍然是现有 AML 模块加表格加系统集成商的组合，不是完全没有软件 [16][17][18][19][20][21][22][23][24][26][27][28][29][30][32][33][35]。

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

• 全球 AML 套件. Oracle 和 NICE Actimize 已经覆盖监控、筛查、反欺诈和监管报告，但它们的公开资料是横向通用的，尼泊尔专属的申报内容和本地落地的复杂性，仍然留给客户或伙伴生态自己解决。
• APAC 反金融犯罪套件. Tookitaki 更贴近工作流，在 FRAML/案件管理上宣称很强，但它公开的定位是 APAC 通用型，而不是明确针对尼泊尔本地化。
• 以 API 为主的筛查与数据厂商. ComplyAdvantage 在全球筛查数据、模块化监控和案件工作流上最强，但它的定位仍是原生 API 风险基础设施，而不是尼泊尔专属的监管内容包。
• 本地伙伴加全栈模式. ZIGRAM 已经证明本地实施联盟有助于拿下尼泊尔的交易，但同样的模式也可能留出空间，给一个更轻的厂商中立叠加层——如果银行只想要本地化而不想换掉整套系统。
• 内部工作流加系统集成商. 退路仍然是表格、人工调查，以及东拼西凑的现有模块；APG 和 NRB 的证据显示这种方式能运转，但水平参差不齐，尤其是在最大几家银行之外。

尼泊尔 FRAML 本地化操作系统应该从一层厂商中立的本地化叠加层起步，服务那些已经在跑进口 AML 或反欺诈工具、外加人工本地流程的尼泊尔商业银行。研究显示需求真实存在：Machhapuchchhre Bank 已经买下一套尼泊尔本地化的统一技术栈，FIU-Nepal 又在 2025 年更新了 STR/SAR 和 TTR 指引，本地 规则维护和申报准确性因此变得紧迫。第一款产品不是又一个通用检测引擎，而是尼泊尔专属的 PEP/RCA 数据、FIU 达标报告包、统一告警分流和调查员案件处理，部署在现有系统之上，并由本地伙伴协助落地。 第一个客户是一家拥有 25-75 家分支机构、有自建移动应用、数字支付量在增长、即将迎来 NRB 或 FIU 审查或现代化项目的尼泊尔商业银行。第一单应该是针对一个银行主体、一条报告工作流的付费试点，只有 当平台自动填充大部分申报字段、减少人工案件准备、缩短调查周期后，试点才会转化为正式合同。这个切口 有吸引力，因为买家集中、痛点与监管直接挂钩，而且叠加层比整套系统推翻重建更容易快速验证。市场是 真实的但规模不大：建模得出的 SAM 约为 800 万美元，第三年 SOM 约为 160 万美元，所以风投级机会 取决于能否把这套本地化引擎复用到斯里兰卡或相邻的受监管机构。研究尚未证实现有厂商的渗透率、 在岸部署要求或可信定价点，因此叠加层的中标率、部署架构和 ACV 都必须在头 12 个月内验证。

问题

• 尼泊尔商业银行仍在拼凑全球 AML 模块、基于表格的本地 PEP 核查，以及人工 STR/SAR/TTR 准备工作， 而数字支付量的上升正在推高告警数量。
• 分散的反欺诈和 AML 队列造成重复调查、升级变慢、审计留痕变弱，恰好撞上 NRB/FIU 监管趋严的时点。
• 通用厂商覆盖了监控和筛查的广度，但把尼泊尔专属的申报逻辑、本地数据维护和监管机构认可的工作流， 留给了银行或系统集成商自己解决。

解决方案

• 交付一套尼泊尔本地化叠加层：维护好的 PEP/RCA 与报告映射、带版本号的 STR/SAR/TTR 规则包， 以及面向监管机构申报的可审计证据生成。
• 把反欺诈、筛查和 AML 告警统一到一个调查员队列和案件文件里，且不强迫银行第一天就替换现有 监控技术栈。
• 通过模块化连接器和本地伙伴部署，让银行可以先上一个主体、一条工作流，验证效果后再加模块。

为什么我们会赢

• 这家公司卖的正是现有厂商和系统集成商仍当作定制工作的最后一公里产品缺口：尼泊尔专属数据、 申报模板，以及紧跟规则变化的调查员工作流。
• 厂商中立的叠加层比整套系统替换更容易让银行买单，因为它能塞进现有的现代化预算，也降低了 核心系统切换的风险。
• 跨银行调优数据、申报模板历史和本地伙伴部署手册会不断积累，形成通用全球套件难以逐个市场 维护的护城河。

里程碑

flowchart LR
  Wedge[Nepal bank localization overlay] --> MVP[PEP plus FIU report pack plus unified casework]
  MVP --> Proof[2 production bank references and faster filings]
  Proof --> Expansion[Sri Lanka or adjacent institution pack]

创始团队

实验路线图

风险评估

必须成立的条件

• 尼泊尔 20 家商业银行中至少有 6 家，本地 PEP 审查或 FIU 报告的主要部分仍靠人工完成， 且在 24 个月内面临已列入预算的现代化或审计触发点。
• 前 6 个正式意向客户中至少有 3 家更倾向厂商中立的叠加层，而不是整套系统替换或纯系统 集成商项目。
• 头 3 个试点能在 90 天内自动填充 70% 以上的必填 STR/SAR 或 TTR 字段，并把案件准备 耗时中位数降低至少 30%。
• 至少 50% 的付费试点能转化为 25 万美元以上的年度软件合同，且服务收入不超过首年收入的 30%。
• 到第 18 个月，斯里兰卡或相邻机构规则包能复用至少 60% 的尼泊尔内容、规则和工作流模型。

待尽调问题

• 尼泊尔 20 家商业银行中已经有多少在用 Oracle、NICE、Tookitaki、ZIGRAM 或自建工作流， 哪些最容易以叠加层的方式卖进去？
• 目标银行是否要求可疑活动案件数据必须在岸或本地部署，这对毛利率和落地速度有什么影响？
• 前 2 个共创客户的 FIU 申报字段和案件准备步骤中，目前还有多少比例是人工完成的？
• 在不拥有完整交易监控引擎的情况下，这家公司能否赢过 ZIGRAM 和现有套件厂商？
• 哪个第二市场能以最少的全新监管内容复用尼泊尔规则包：斯里兰卡银行，还是尼泊尔支付机构？

模型合理性

• 收入引擎. 基准收入的驱动来自把 2 个付费试点转化为第二年第四季度的 4 家尼泊尔生产环境银行，再加上第三年第四季度新增的 2 家相邻市场付费机构，以及客户内部扩展。
• 必须做对的事. 本地伙伴必须把部署周期稳定控制在接近 90 天的目标内，让试点客户在模型加入第二名销售和相邻市场动作之前完成转化。
• 模型失效的临界点. 如果成熟客户实际价值停留在约 $360K ARR，或者试点转生产拉长到接近 120 天，下行情形会在区域验证出现之前把现金推到零以下。
• 下一轮融资的证明. 一旦有了 4 家尼泊尔生产环境客户、1 次扩展成功案例和 1 个相邻市场付费试点，且服务收入仍低于商业计划设定的新客户首年收入 30% 门槛，种子轮就站得住脚。

情景

敏感性

flowchart LR
  TargetBanks[Target Nepal banks] --> PaidPilots[Paid pilots]
  PaidPilots --> NepalProduction[Nepal production banks]
  NepalProduction --> Expansion[Expansion modules]
  NepalProduction --> Adjacent[Adjacent-market pilot]
  Expansion --> Revenue[Revenue]
  Adjacent --> Revenue
  Revenue --> GrossProfit[Gross profit]
  GrossProfit --> Cash[Cash]

警示项: 尼泊尔核心银行市场只有 20 个买家，错过一两个目标客户就会显著影响第二、三年的数字。 · customersEop 既包含付费试点也包含生产环境主体，所以在试点和生产环境混合的季度里，纯经常性生产客户数低于对外展示的付费客户总数。 · 只有当伙伴协助的部署真正稳定在 90 天以内、且本地化维护没有塌陷成高服务投入的工作时，第三年第四季度才能实现 EBITDA 转正。 · ZIGRAM 已经拿下一个真实的尼泊尔银行部署案例，所以叠加层与整套系统的定位必须保持清晰，否则 90 天转化假设会打滑。 · 现金是按 EBITDA 建模的，所以企业计费里程碑、实施预付款或延迟回款都可能让实际现金曲线偏移几个月。

• 本地市场天花板. 如果扩张逻辑不成立，仅靠尼泊尔市场可能撑不起风投级回报。 缓解措施: 把尼泊尔当作验证点，再将可复用的本地化包产品化，推向南亚周边银行和资金转移市场。
• 现有厂商挤压. 一旦需求得到验证，全球 AML 厂商或本地系统集成商可能会把尼泊尔本地化能力捆绑进自己的产品。 缓解措施: 在监管映射、伙伴分销渠道和统一反欺诈加 AML 工作流数据上抢先一步——这些恰恰是服务公司难以标准化复制的部分。
• 合规准确性责任风险. 本地 PEP 覆盖或 FIU 报告模板中的错误，可能损害早期银行客户的信任。 缓解措施: 每次发布前，用带版本号的规则包配合人工审批流程、本地合规专家和参考银行验证来把关。