《互联网产品的服务端架构·交易、增长与平台化》附录 C 合规与风控检查清单

本附录是一份可勾选的清单，不是法律意见。具体条款以所在地法规与平台规则为准，涉及资质、税务、跨境的事项应咨询专业人士。

清单按「上线前 → 活动中 → 事后」三阶段组织，每条都对应一个可验证的系统行为，而不是一句口号。

主体与资质

交易类产品首先要能回答「谁在卖、卖给谁、凭什么卖」。

• 经营主体信息在页面可查，与实际收款主体一致。
• 特殊品类（食品、药品、医疗器械、出版物）具备对应许可。
• 支付渠道签约主体与经营主体一致，不一致时有代收代付协议。
• 跨境业务明确报关、税务与数据出境路径。
• 平台型业务完成商家入驻审核，留存资质材料与有效期。
• 资质到期前有提醒与自动下架机制。

资质不是一次性动作。许可证过期后商品仍在售，是常见的监管处罚点。系统里应该有「资质有效期」字段，并有到期任务。

价格与促销

价格相关的合规问题集中在「先涨后降」「虚构原价」「优惠不可用」三类。

• 划线价有真实成交记录支撑，保留历史价格。
• 促销活动开始前记录基准价，活动期间不随意调整。
• 优惠券、满减、会员价的使用条件在结算页明确展示。
• 叠加规则可计算、可复现，不依赖人工解释。
• 活动库存与限购规则在活动页写清。
• 秒杀类活动说明「数量有限、先到先得」，不承诺人人有份。
• 价格错误时的处理预案已确定（履约或取消并补偿）。

「先涨后降」在系统里表现为：活动前价格被上调，活动价等于原价。防范方式不是靠人工检查，而是把历史价格存下来，活动价与近 30 天最低价做自动比对。

价格错误（例如把 199 元标成 19.9 元）是高频事故。预案要事前定：是全部履约、全部取消，还是设阈值。临时决策往往会演变成舆情。

支付与资金

• 支付渠道具备相应牌照，不自行归集资金。
• 二清（二次清算）风险已评估，平台不代收代付给商家。
• 退款路径与原支付路径一致，原路退回。
• 退款时效在页面明示，超时有查询入口。
• 支付回调验签、验金额、验币种、幂等四项齐全。
• 对账每日执行，差异有归属与处理时限。
• 发票申请入口可用，开票主体与收款主体一致。
• 资金变动有完整流水，可导出、可审计。

二清是平台型业务的高压线。平台先收用户的钱、再结算给商家，如果没有支付牌照，就构成无证经营支付业务。合规做法是接入分账能力，资金由持牌机构直接结算。

隐私与数据

• 收集个人信息前有告知与同意，同意可撤回。
• 收集范围与业务目的匹配，不超范围采集。
• 敏感个人信息（身份证、银行卡、生物特征）单独同意、加密存储。
• 数据保留期限明确，到期删除或匿名化。
• 用户可查询、更正、删除自己的数据。
• 第三方 SDK 清单可查，共享数据有协议。
• 数据出境完成安全评估或采用标准合同。
• 日志中的手机号、地址、证件号脱敏。
• 权限最小化，运营查看敏感数据需审批与留痕。

「同意」不是一次弹窗。新增用途、新增共享方、新增采集字段，都需要重新告知。把同意记录做成带版本号的流水，才能在检查时说明「用户同意的是哪一版协议」。

数据删除要真删。标记删除但备份里还在，在监管检查中不算删除。备份的保留周期与删除策略要写进制度。

未成年人保护

• 有年龄识别或声明机制。
• 未成年人充值、打赏有限额与提醒。
• 未成年人退款通道可用，流程可查。
• 不向未成年人推送不适宜内容或诱导消费活动。
• 未成年人模式下的推荐、广告、社交功能有收敛。

未成年人退款是交易系统里的特殊流程：它往往发生在支付成功很久之后，且需要监护关系证明。系统要能按「用户 + 时间范围」检索订单，并支持部分退款。

营销与广告

• 广告内容可识别，标明「广告」。
• 不使用「国家级」「最高级」「第一」等绝对化用语。
• 效果承诺有依据，不虚构用户评价。
• 抽奖活动公示奖品、数量、中奖规则与开奖时间。
• 抽奖不设置「必须邀请 N 人才能提现」这类诱导链路。
• 短信、推送、电话营销有退订入口，退订立即生效。
• 营销频次有上限，夜间时段不打扰。

「邀请 N 人提现」类活动在多地已被认定为诱导分享。设计裂变活动时，奖励应与「被邀请人真实使用」挂钩，而不是与「邀请人数」挂钩。

退订要真退。用户点了退订，系统只改了偏好表、营销任务仍从旧名单取数，是常见的实现漏洞。退订名单应该在发送前统一过滤。

风控维度

风控的本质是用有限信号判断「这次请求是否可信」。常用维度如下。

单一维度都会误伤。判断要组合多个弱信号，而不是依赖一个强信号。例如「新账号 + 新设备 + 同一收货地址 + 短时间多单」比「新账号」可靠得多。

风控规则要有版本与回放能力。上线新规则前，用历史数据回放，估算拦截量与误伤率，再决定是否灰度。

处置动作

处置动作要分级，不能只有「放行」与「封号」两档。分级能让低风险用户继续使用，同时把资源集中在高风险case。

每次处置都要记录：命中规则、信号快照、动作、操作者（人或系统）、时间。没有快照，事后无法解释为什么拦。

申诉与复核

• 所有限制类处置都有申诉入口。
• 申诉有明确时限，超时自动升级。
• 申诉处理人能看到当时的信号快照。
• 误判可一键解除，并回流为规则优化样本。
• 申诉结果通知用户，说明原因类别。
• 高频申诉的规则进入复核队列。

没有申诉的风控是黑箱。黑箱短期有效，长期会积累大量客诉，也会让规则失去校准依据。

申诉数据是最好的规则评估数据。某条规则的申诉率与翻案率都高，说明它误伤严重，应该调整阈值或下线。

审计与留痕

• 运营后台的写操作记录操作者、时间、前后值。
• 敏感操作（改价、退款、发券、解冻）需要二次确认或审批。
• 审批记录不可删除，可导出。
• 数据导出有审批与水印。
• 定期审计高频操作者与异常时段操作。
• 离职人员权限及时回收。

审计日志要独立存储，不能和业务库放在一起。业务库被改，日志也跟着被改，审计就失去意义。

上线前检查

活动或功能上线前，逐条确认：

• 价格、库存、限购、优惠规则已配置并复核。
• 活动库存与商品库存分开，回补逻辑已测试。
• 风控规则已回放，误伤率在可接受范围。
• 退订、退款、申诉入口可用。
• 隐私告知与同意版本已更新。
• 客服话术与应急预案已准备。
• 监控指标与告警阈值已配置。
• 回滚方案已演练。

活动中检查

• 实时监控支付成功率、退款率、拦截率。
• 关注风控误伤客诉，必要时下调阈值。
• 关注库存与预算消耗速度，异常时熔断。
• 关注外部舆情与竞品动作。
• 大额、高频订单人工抽检。
• 记录所有临时调整，事后复盘。

事后复盘

• 统计实际参与人数、成交额、退款率、客诉量。
• 对比活动前后指标，区分自然波动。
• 复盘风控拦截与误伤，更新规则。
• 复盘价格与优惠规则漏洞。
• 归档活动配置、审批记录、监控截图。
• 输出可复用的检查项，补充进本清单。

消费者权益

• 七日无理由退货范围写清，不适用品类单独标注。
• 退货运费承担方在页面明示。
• 客服入口在订单页可直接触达，不隐藏在多层菜单。
• 自动续费在扣款前提醒，可随时关闭。
• 虚拟商品、课程、会员的退款规则在购买前确认。
• 预付费卡、储值余额有使用期限与退款路径。
• 投诉处理时限明确，超时可升级。

自动续费是投诉高发区。合规做法是扣款前若干天提醒、提供一键关闭、关闭后当前周期仍有效。把「关闭续费」做成需要联系客服，往往会被认定为设置障碍。

虚拟商品的退款规则要单独设计。已消费的课程、已使用的权益通常不支持无理由退款，但「未使用」的判定需要系统支持，例如记录首次使用时间。

反洗钱与交易监测

• 大额、高频、整数金额交易有监测规则。
• 同一收款方短时间多笔分散付款有聚合视图。
• 退款率异常高的账号进入复核。
• 优惠券、积分、余额的批量转移有阈值。
• 可疑交易有上报流程与留痕。
• 监测规则定期回放，评估误报率。

交易监测不是金融机构的专属。平台型业务如果存在资金归集、余额、虚拟币兑换，同样需要监测。规则可以先从「金额 + 频次 + 关系」三条起步，再逐步加维度。

监测规则要能解释。只输出「风险分 87」没有意义，要能说明命中了哪几条规则、各自的权重是多少。

第三方与供应链

• 第三方服务商清单可查，含用途、数据范围、合同有效期。
• 支付、短信、云服务有备选方案。
• 服务商变更时评估数据迁移与合规影响。
• 开放平台的应用有审核、配额与下线机制。
• 供应商访问生产数据需审批与留痕。
• 外包人员权限与在职员工同等管理。

第三方不是免责牌。用户数据交给服务商处理，平台仍然是责任主体。合同里要写清数据处理目的、期限、安全措施与违约责任。

开放平台的应用要能单独下线。某个第三方应用出问题，不应该影响整个平台；这要求权限、配额、回调都是按应用隔离的。

常见失败案例

• 活动价高于历史最低价。 被认定为虚假促销，活动被叫停。
• 优惠券可叠加但页面未说明。 用户结算时发现不能用，集中投诉。
• 风控只按 IP 拦截。 校园网、企业网用户被整体误伤。
• 退款只退到余额。 用户要求原路退回，产生资金合规争议。
• 未成年人充值无提醒。 家长集中申请退款，客服无法核验。
• 短信退订未生效。 用户投诉后仍收到营销短信，被监管部门约谈。
• 运营直接改库发券。 无审批、无流水，事后无法对账。
• 审计日志与业务库同库。 数据被修改后无法追溯。

这些案例的共同点是：系统在正常路径上都能跑通，问题出在「规则没写进系统」或「写了但没有校验」。合规与风控不是文档工作，是需要在代码里有对应判定的工作。

把合规写进研发流程

清单如果只在事故后使用，价值有限。更有效的做法是把它嵌进研发流程：

• 需求评审：涉及价格、促销、隐私、未成年人时，要求给出对应检查项。
• 技术方案：把「同意版本」「数据保留」「审计留痕」写进设计文档。
• 测试用例：每个处置动作至少有一个误伤与一个申诉用例。
• 上线检查：用清单作为发布单的必填项，而不是附录。
• 复盘：每次事故补充一条检查项，并注明来源。

合规需求常常以「加一个开关」的形式进入排期，最后没人记得开关的语义。把开关的默认值、生效范围、下线条件写进设计文档，能避免它变成永久配置。

对于跨境业务，还要把「数据存放在哪个区域」「哪些接口会出境」画进架构图，而不是只写在制度文件里。系统边界与合规边界不一致，是出海项目最常见的隐患。

清单怎么用

这份清单不适合一次性全部打勾。建议按业务阶段取用：

• 新业务上线：主体资质、价格促销、支付资金、隐私数据四节。
• 大促活动：价格促销、营销广告、风控维度、处置动作、上线前与活动中检查。
• 开放平台：主体资质、隐私数据、审计留痕、申诉复核。
• 出海业务：隐私数据、未成年人保护、数据出境、支付资金。

每次检查留下记录：谁检查、什么时候、发现了什么、怎么处理。没有记录的检查，等于没做。