1. 金融科技产品合规评审全景

金融科技产品的合规评审，不是产品上线前的一次“盖章”，而是一条贯穿需求、设计、开发、上线、运营全生命周期的风险控制链。要做好这条链上的每一个判断，评审人员首先必须建立一张“全景地图”：谁在监管、管什么产品、评审要达成什么目标、风险控制在整个产品治理中处于什么位置。缺少这张地图，评审就容易退化为逐条对照法条的机械核对，既抓不住重点，也无法向业务解释“为什么这条不能做”。

一、监管格局：多头、分层、功能监管与穿透监管并行

我国金融科技监管的基本格局可以概括为“一委一行一总局一会”加地方金融管理部门的协同结构。中国人民银行负责支付结算、征信、反洗钱、金融科技规划与金融标准；国家金融监督管理总局负责银行保险机构及其科技合作、互联网贷款、助贷与融资担保相关业务；中国证监会及派出机构负责证券基金期货领域的金融科技应用与信息技术合规；国家网信办、工信部、公安部则在数据出境、个人信息保护、算法推荐、网络安全等级保护、App 备案等横向领域施加要求。地方金融管理局对区域性交易场所、小贷、融资担保等机构承担属地监管职责。

对评审人员而言，比记住机构名称更重要的是理解两条监管逻辑。第一条是功能监管：不论主体叫什么名字，只要实质从事支付、放贷、资管、保险、征信等金融业务，就要取得相应牌照或纳入相应规则。第二条是穿透监管：监管会穿透产品结构、股权结构和技术外壳，识别最终的资金来源、风险承担者和实际控制人。因此，一个“科技公司”包装下的产品，如果实质是向不特定公众归集资金并承诺收益，就不能以“我们不是金融机构”为由规避评审。

二、产品类型：按业务实质而非名称分类

金融科技产品形态繁多，但评审时更有效的方式是按业务实质归类，因为同类产品的监管要求高度相似。常见类型包括：支付与收单类（聚合支付、跨境支付、钱包账户）；信贷与助贷类（互联网贷款、联合贷、助贷、供应链金融）；财富管理与资管类（基金销售、智能投顾、理财代销）；保险科技类（互联网保险、保险经纪、UBI 车险）；征信与数据服务类（企业征信、个人征信、数据风控服务）；以及面向金融机构的技术输出类（核心系统、风控 SaaS、反欺诈引擎）。

分类的意义在于快速定位适用的监管规则。例如，助贷类产品需要重点关注《商业银行互联网贷款管理暂行办法》对合作机构准入、集中度、风险分担、数据使用的约束；而技术输出类产品虽然不直接持牌，但一旦接触金融机构的客户数据或生产系统，就会触发外包风险管理、数据安全与业务连续性要求。评审人员应在项目立项阶段就完成这一分类，并据此确定评审清单的“主规则集”。

三、评审目标：四个必须回答的问题

合规评审的目标不是“证明产品没问题”，而是“识别并处置风险”。落到具体项目上，评审要回答四个问题。第一，主体与业务是否持牌合规：产品涉及的业务是否需要牌照，合作方是否具备资质，是否存在无证经营或超范围经营。第二，数据与个人信息是否合法：采集是否取得有效同意，是否超范围采集，是否违规共享给第三方，是否满足最小必要原则。第三，消费者权益是否受保护：信息披露是否充分，是否存在误导性宣传，投诉与纠纷处理机制是否健全。第四，技术系统是否安全可控：是否满足等级保护要求，是否存在重大安全漏洞，业务连续性是否有保障。

这四个问题构成了评审的“底线清单”。任何一项无法通过，产品都不应上线；任何一项存在重大不确定性，都应设置整改期限或限制上线范围。评审结论通常分为“通过”“有条件通过”“不通过”三档，其中“有条件通过”必须明确整改事项、责任人和完成时限，并在上线后跟踪验证。

四、风险控制定位：第二道防线的独立把关

在金融机构和金融科技公司的治理结构中，风险控制通常按“三道防线”安排。第一道防线是业务部门和研发团队，他们在日常工作中直接控制风险；第二道防线是合规、风控、法务等职能部门，负责制定规则、独立评审、监督执行；第三道防线是内部审计和外部监管，对前两道防线进行再监督。合规评审属于第二道防线，其核心价值在于独立性：评审人员不能既做业务又做评审，也不能因为业务压力而降低标准。

理解这一定位，有助于评审人员把握两个边界。其一，评审不替代业务部门的风险责任，业务部门仍是风险的第一责任人；其二，评审不是“找茬”，而是帮助业务在合规前提下找到可行路径。例如，某助贷产品希望将风控模型输出给银行使用，评审人员不应简单否决，而应指出：模型输出涉及数据出域和外包风险管理，需要签订数据处理协议、完成安全评估、明确模型可解释性要求，并建议采用“模型在银行侧部署、数据不出行”的方案。这样的评审结论既守住了底线，也推动了业务落地。

五、从全景到行动：评审启动前的准备

在正式评审前，评审人员应完成三项准备。第一，确认产品分类与适用规则集，列出主规则和横向规则。第二，收集产品材料，包括业务流程图、数据流图、合作协议、隐私政策、系统架构说明和安全测试报告。第三，识别高风险点，例如是否涉及个人敏感信息、是否涉及资金归集、是否面向不特定公众、是否依赖境外服务。这三项准备完成后，评审才能有的放矢，而不是从零开始逐条询问。

下表给出一个简化的评审启动检查表示例，供实际项目参考。表中“风险等级”由评审人员根据业务实质判断，高等级项目应提交更高层级审批。

需要强调的是，这张表只是起点。真正的评审能力体现在对具体业务的理解上：同样是“数据共享”，在征信场景和营销场景下的合规要求完全不同；同样是“技术输出”，面向银行核心系统和面向银行营销系统，风险等级也相差很大。评审人员应在实践中不断积累“业务—规则—风险”的对应关系，形成自己的判断框架。

本章建立的全景地图，是后续所有评审工作的基础。监管格局决定了“谁说了算”，产品分类决定了“适用什么规则”，评审目标决定了“看什么”，风险控制定位决定了“怎么站位”。把这四件事想清楚，评审就不再是零散的法条核对，而是一套有逻辑、有重点、可解释的风险控制方法。