Google Play 金融服务政策 2026：借贷类应用的牌照与合规清单

在 Google Play 上，「钱」不是普通品类，而是受监管的品类。只要你的应用涉及放贷、撮合放贷，或就资金提供建议，Google Play 金融服务政策（Financial Services）就适用于你。而 2026 年有两件事必须并行完成：一是每个已发布应用都要在 Play Console 提交的金融功能申报（Financial features declaration），二是借贷类应用在目标国家必须满足的牌照与信息披露要求。

本文只讲第二件事，面向「正在准备提交」的团队，而不是事后申诉的人。内容包括：必须在商店信息里公开的内容（最高年化利率 APR、最短与最长还款期限、一笔具代表性的总成本示例）、借贷与信贷类应用被明确禁止申请的八项权限、需要随申报一起上传的国家牌照（印度、印度尼西亚、菲律宾、尼日利亚、肯尼亚、巴基斯坦、泰国与美国）、先薪到账（Earned Wage Access）与个人贷款被区别对待的原因，以及最常导致拒审的几类问题。先说一句最关键的：Google 必须能证明你的开发者账号与牌照持有人之间存在关联，其余问题都比这一点好解决。

一、两项义务，多数团队只准备了其中一项

Google 把这件事拆成了两层。申报是 Play Console 里的一张表，位置在「政策与计划 → 应用内容」（Policy and programs → App content）下的金融功能项，它是「保持上架」的前置条件，而不是上架当天的补充材料。政策规则则是这张表被拿来对照检查的标准：信息披露、禁用权限、国家牌照。

适用范围的写法比多数人以为的更宽：

• 所有在 Google Play 上有已发布应用的开发者都必须完成申报，包含封闭测试、开放测试与正式版轨道上的应用，以及通过 Play 更新的预授权与预装应用。
• 应用若提供金融功能，必须逐项勾选实际涉及的功能：个人贷款直接放贷方、贷款撮合方、发薪日贷款、银行服务、循环信贷额度、先薪到账、小额信贷银行、移动支付与数字钱包、转账与汇款、分期购买协议、奖励与积分、先买后付、加密货币钱包与交易所、NFT 销售与交易、股票交易与组合管理、众筹与互助会、信用监测与征信、财务建议、保险。
• 若一项都不涉及，仍必须提交该表，并勾选「我的应用不提供任何金融功能」。
• 只有系统服务与私有应用可以豁免。

类别要选准。明明是直接放贷方却申报成「贷款撮合方」，或反过来，会直接改变你需要提供哪一类文件；申报内容与商店信息不一致，是最快触发政策处置的路径之一。

二、借贷类应用必须在自己商店信息里写清的内容

「个人贷款」的定义很宽：个人、机构或实体以非循环方式向消费者放出的资金，且用途不是购置固定资产或教育。发薪日贷款、P2P 贷款、车辆抵押贷款都在范围内；房贷、车贷与信用卡这类循环额度不在范围内。

凡是提供个人贷款的应用——无论是直接放贷、引流获客，还是把消费者对接到第三方放贷机构——都必须把应用类别设为「财务」，并在商店信息中披露：

1. 最短与最长还款期限。用户在下载之前就能看到自己有多少时间还款。
2. 最高年化利率（APR），通常指把利息加上各项费用与其他成本、折算到一年后的比率，或按当地法律口径计算出的同类比率。
3. 一笔具代表性的总成本示例，包含本金与全部适用费用。不是区间，也不是「低至」，而是一个算出来的例子。
4. 隐私政策，全面披露个人与敏感用户数据的访问、收集、使用与共享方式，并符合政策设定的限制。

还有一条硬性禁止：推广「放款后 60 天内必须一次性还清」的个人贷款应用不被允许——Google 称之为短期个人贷款（short-term personal loans）。这类产品再怎么披露也过不了。

三、美国市场：36% 的上限与 TILA 口径

在美国，Google 不允许年化利率达到或超过 36% 的个人贷款应用上架，且必须按《贷款真实性法》（TILA）一致的口径展示最高 APR。这条规则同样覆盖直接放贷方、引流方，以及所有把消费者对接到第三方放贷机构的应用——分销链条铺得再细，也不能替代牌照。

落到执行上：合规团队算出的 APR 与商店列表里的数字必须是同一个数、同一种算法。如果应用内的披露用的是 TILA APR，而列表里写的是名义利率，被审核的就是列表里的那个数字。

四、借贷与信贷类应用禁止申请的八项权限

这一节最容易让已经做好的包直接出局。个人贷款应用、以撮合个人贷款或循环额度为主要目的的应用、贷款周边应用（贷款计算器、贷款攻略等），以及先薪到账应用，都不得访问照片、通讯录等敏感数据。被点名的权限是明确的：

• READ_EXTERNAL_STORAGE
• READ_MEDIA_IMAGES
• READ_MEDIA_VIDEO
• WRITE_EXTERNAL_STORAGE
• READ_CONTACTS
• READ_PHONE_NUMBERS
• ACCESS_FINE_LOCATION
• QUERY_ALL_PACKAGES

理由不只是隐私口号。读取通讯录与相册是暴力催收类产品的经典工具，所以政策选择一刀切，而不是逐案判断。两个工程细节必须注意：禁止范围包含周边应用，同团队打包的贷款计算器不能豁免；由第三方 SDK 合并进合并清单（merged manifest）的权限同样被计入。要审的是最终合并清单，不是源码清单。

五、国家牌照：要上传什么，以及文件必须指向谁

面向下列国家或地区的借贷应用，Google 要求提供牌照或注册证明，通过金融功能申报收集。真正的门槛比「有牌照」更高：Google 必须能证明你的开发者账号与你提交的文件之间存在关联，并且随时可能要求补充材料。

• 印度——只有提交牌照、且出现在印度储备银行（RBI）「Digital lending apps (DLAs) deployed by Regulated Entities」名单上的应用，才能提交个人贷款应用审核。若你本身不放贷，只是为持牌 NBFC 或银行提供撮合平台，必须在申报中如实说明，并在应用描述中显著列出所有注册 NBFC 与银行的名称。
• 印度尼西亚——依据 OJK 第 77/POJK.01/2016 号条例从事信息技术类借贷服务的应用，必须提交有效牌照副本供审核。
• 菲律宾——通过线上借贷平台（OLP）放贷的融资与借贷公司，必须取得菲律宾证券交易委员会（SEC）注册号与授权证书（CA）编号，并在应用描述中披露公司名、商号、PSEC 注册号与 CA 编号。P2P 等借贷型众筹必须通过 SEC 注册的众筹中介完成交易。
• 尼日利亚——数字放贷机构（DML）必须完成联邦竞争与消费者保护委员会（FCCPC）《数字借贷有限临时监管/注册框架与指引（2022）》的相关要求，并取得可核验的 FCCPC 批准函。贷款聚合方须提供服务文件，以及每一家合作 DML 的联系方式。
• 肯尼亚——数字信贷提供方（DCP）须完成注册并持有肯尼亚中央银行（CBK）牌照。仅做平台的运营方必须如实申报，并提供合作方的 DCP 牌照副本。实践中 Google 只接受出现在 CBK 官方「Directory of Digital Credit Providers」名录中的实体所提交的申报与牌照。
• 巴基斯坦——须提交巴基斯坦证券交易委员会（SECP）批准其提供或撮合数字借贷服务的证明。同时，每家 NBFC 放贷方只能发布一款数字借贷应用；试图为同一 NBFC 发布多款的，可能面临开发者账号及关联账号被终止。短期贷款应用原则上不允许，仅有法律明确许可的极少数例外。
• 泰国——面向泰国、利率达到或超过 15% 的个人贷款应用，必须持有泰国央行（BoT）或财政部（MoF）颁发的有效牌照，并在列表展示持牌贷款服务方名称、开发者法人名称、最高利率与全部费用。利率低于 15% 的应用还须额外注明自身为 BoT/FPO 体系外的非受监管贷款提供方。

可以看出每个国家要的东西并不相同：名单成员资格、牌照副本、注册编号、批准函，或直接在列表里写明的披露项。在应用描述里写一句「我们持有牌照」，一条都不算满足。

六、先薪到账不是个人贷款，但同样要申报

Google 对先薪到账（EWA）单独立了定义：用户取用的是当期已经赚到但尚未发放的工资；还款通过工资扣款或绑定银行账户的自动扣款完成，自动扣款失败时不额外收取利息、罚金或费用；可支取金额严格限于当期已赚工资，不预支未来收入；收费方式是低额固定费或按比例的交易费，而非利息。Google 的指引把每笔约 1–5 美元，或垫付金额的 1–5% 视为合理且透明的费用区间。

EWA 应用同样要把类别设为「财务」，披露还款条款、全部费用（含订阅费与交易费）以及具代表性的总成本示例。上文的国家要求在该司法辖区适用范围内同样覆盖 EWA。把一笔昂贵的高息短贷包装成「EWA」，并不会让它脱离个人贷款规则的约束。

七、申报在 Play Console 里怎么走完

1. 打开 Play Console，进入政策与计划 → 应用内容。
2. 在金融功能一栏点击开始，勾选应用实际提供的全部金融功能，或声明不提供任何金融功能，然后点下一步。
3. 若需要额外交件，必须把国家表格里的每一行都填完——每一行都会展开，收集该国指定的那一类文件。
4. 点保存提交。材料还在路上可选暂存草稿；点放弃更改则整张表需要重填。

提交的信息会随应用审核一并被检查。发现问题会通过邮件、Play Console 通知，以及政策状态页面（政策与计划 → 政策状态）呈现。申诉之前先看这一页：它通常直接点名是哪一项申报出了问题，而不是只给一个结论。

八、出问题通常长什么样

• 主体对不上。牌照属于关联公司、合作 NBFC 或一个与开发者账号无法建立映射的品牌名称。这是最常见的卡点，重传同一份 PDF 解决不了。
• 商店信息缺项。没有最高 APR、没有还款期限，或总成本示例写成了营销话术而不是算式。
• 权限没清干净。统计或归因 SDK 把 READ_PHONE_NUMBERS、QUERY_ALL_PACKAGES 合并进清单，而判定依据是真正发出的那个包。
• 巴基斯坦同一放贷方多款应用。政策把它当作账号级风险处理，而不是应用级问题。
• 合作方名单没写进描述。多个司法辖区要求持牌合作方出现在商店列表本身，而不只是应用内部。

九、提交前的十二项自查

1. 应用类别已设为财务。
2. 金融功能申报已提交——若确实不涉及，也已勾选「不提供任何金融功能」。
3. 列表中的最高 APR 已按当地法律口径（美国为 TILA）写好。
4. 最短与最长还款期限已写明。
5. 具代表性的总成本示例包含本金与每一项费用。
6. 隐私政策已上线，且与实际数据处理一致。
7. 合并清单中不含八项禁用权限。
8. 第五节表格要求的国家牌照已逐国上传，且在有效期内。
9. 开发者账号与牌照持有人之间的关联关系已有文件支撑，能用一句话解释清楚。
10. 在要求披露的国家，已把持牌合作方（NBFC、银行、DCP、DML）写进应用描述。
11. 面向美国市场：没有任何一笔贷款达到或超过 36% APR，且全球范围内没有 60 天内一次性还清的产品。
12. 团队内有明确的人负责政策邮件，补充材料的通知不会在回复窗口内被漏读。

十、KappS 在这件事里的位置

KappS 负责规模化发布里的运营侧：让开发者账号、付款资料与商店信息处在经得起平台复核的状态。对金融类应用而言，这意味着准备并提交合规材料——梳理某个市场需要哪些申报与牌照，把文件组合成「牌照持有人与账号明确对应」的一套材料，对照披露规则检查商店信息，并在发包前复核清单权限。

我们不提供任何「替代牌照」的做法。Google 的要求很直接：放贷主体必须在当地确实取得放贷资格；不存在「列表做得漂亮就能顶替牌照」的版本，走这条路的结果通常是账号被终止，而不是通过审核。真正稳的路很朴素——如实申报、真实牌照、诚实的数字。

资料来源（Google 官方文档）：Play Console 帮助中心——金融服务政策（个人贷款、先薪到账、通用要求、各国特定要求）；《提供金融功能申报信息》；金融功能申报类别清单；权限政策；美国《贷款真实性法》（TILA）APR 计算口径。