自有品牌合规监控 SaaS：可复现 risk-score、KYT 案件队列与 fund-flow 逐跳追踪
做自有品牌的合规 SaaS，最忌讳的是把三个第三方供应商的仪表盘转售给客户——你既控制不了口径，也无法把决策沉淀进自己的产品。合规客户真正要的是：onboarding 时的风险评分要可复现、可解释；持续监控要能在你自己的 UI 里流转成案件，而不是导出一张静态表；追查资金时要能按 hop 一跳一跳看清对手方与暴露。1st Node 把 risk-score、KYT、counterparty graph 与 fund-flow trace 放在一把 key、一个 credit 余额上，让你把合规能力做成自己的产品。
面临的挑战
合规产品的价值在于“可复现”和“可流转”。可复现是指：一次 onboarding 的 risk-score 决策，事后必须能拿出当时的 score、confidence、exposure 来解释，否则监管或客户质询时无从对证。可流转是指：KYT 的告警不能只是一封邮件或一张导出的 CSV，而要在产品里形成案件队列，让合规专员能分派、复核、结案。追查资金时，又需要 counterparty graph 和 fund-flow trace 按 hop 展开，量化到 mixer 或受制裁集群的 exposure。如果这些能力来自三个转售的供应商仪表盘，你既拼不出统一的案件流，也无法把决策数据存进自己的库。
- Address risk-score / exposureC3
- Transaction screening / KYTC3
- Counterparty graphC3
- Fund-flow trace (hops)C4
onboarding 时产出可复现的 risk-score
客户 onboarding 时跑 risk-score，并把 score、confidence、exposure 一并保存下来，让每一次风险决策都可复现：事后能还原当时依据了什么、置信度多少、暴露在哪。这样面对内控回溯或监管质询，决策不是黑箱，而是有据可查的记录。评分能力挂在你自己的产品里，不依赖外部仪表盘。
KYT 在你的 UI 里形成案件队列
持续监控用 KYT，但产出的不是静态导出，而是在你自己的 UI 里形成案件队列：告警进入队列，合规专员可以分派、复核、结案，形成可管理的工作流。监控数据留在你的产品内，你控制界面与流程，而不是把客户导去第三方仪表盘。
counterparty graph 加 fund-flow trace 按 hop 追查 exposure
追查资金用 counterparty graph 加 fund-flow trace，按 hop 一跳一跳展开对手方关系与资金流向，量化到 mixer 或受制裁集群的 exposure。分析师能看清某地址距离高风险集群有几跳、暴露多大。这与 risk-score、KYT 共用一把 key，替代原本要转售的三个供应商仪表盘。
该架构交付什么
- onboarding 的 risk-score 连同 score/confidence/exposure 一并保存，风险决策可复现、可对监管与客户解释。
- KYT 在你自己的 UI 里形成可分派、可复核、可结案的案件队列，而不是一张静态导出表。
- counterparty graph 与 fund-flow trace 按 hop 追查对 mixer 及受制裁集群的 exposure，一把 key 替代三个转售供应商仪表盘。
常见问题
监管来查时，我怎么证明当初 onboarding 的风险判定是怎么来的？
risk-score 在评分时就把 score、confidence、exposure 一并保存，决策可复现：你能还原当时的评分依据、置信度和暴露情况，面对内控回溯或监管质询都有据可查，而不是一个说不清来源的黑箱结论。
KYT 告警是给我一份导出文件，还是能在我自己的系统里处理？
是在你自己的 UI 里形成案件队列，而非静态导出。告警进入队列后，合规专员可以分派、复核、结案，监控数据和工作流都留在你的产品内，由你掌控界面与流程。
充值、拿密钥、上线。
自助开通。支持加密货币或银行卡。按额度计费——重型原语更贵，简单调用很便宜。
获取 API 密钥