金融科技的供应盘子有六块，其中一块根本不叫供应链，叫准入
先把六块拆开，因为它们的采购逻辑完全不同：有的可以谈价，有的只能按合规要求选，有的压根不能外包。
- 牌照与合规主体——这块严格说不是供应链，是准入。菲律宾对支付、汇款、电子货币、借贷等受监管业务设有牌照与登记要求，没有相应资质就不能开展对应业务，这一条没有变通空间。本文只陈述门槛存在，不涉及任何规避做法。
- 核心系统与技术栈——账务与账户系统、交易处理、对账与清结算、风控引擎、API 网关、以及承载它们的云或机房。自研、采购还是 SaaS，各有不同的监管含义。
- 数据——客户身份资料、交易记录、日志与审计追踪、备份与灾备。存在哪里、能不能被监管看到、谁能访问，是这一行最硬的约束之一。
- KYC 与反洗钱相关服务——身份核验、证件识别与活体检测、名单筛查、交易监控与可疑活动分析、以及相关记录保存。工具可以买，但判断与记录的责任在你。
- 资金侧的合作方——银行合作、清算与支付通道、收单与代付渠道、结算与资金归集安排。这一块决定业务能不能真正跑起来，也最容易被单点卡住。
- 客服与运营外包——客服坐席、争议与投诉处理、运营支持。菲律宾在这一块的供给能力很强，但涉及客户资料的处理，合规要求跟一般客服外包不同。
六块之中，第一块决定你能不能做，第二和第三块决定你能不能通过检查，第五块决定业务能不能跑，第四和第六块决定你会不会因为别人的疏漏被追责。税务与优惠这一条线不在本文范围，见 在菲律宾做金融科技与支付。主体设立与市场进入的判断属于 市场进入与立项。纯人力与座席型外包的组织逻辑可对照 BPO 的供应链。
哪些必须自己持有、哪些能外包、哪些外包了责任还在你
先记住这条：外包转移的是工作量，不是合规责任。监管看的是持牌或申牌主体，不是你的服务商。把这条想清楚，下面的边界就不难划。
不能外包的：牌照与资质本身，以及基于牌照的合规责任。受监管业务必须由持有相应资质的主体开展，董事与高管的适当性、合规职能的建立与运行、向监管的报告义务，都属于主体自身的义务。借用他人资质开展业务、或把受监管环节包装成技术服务来规避牌照要求，都不是可行路径，本文不讨论任何此类做法。
通常应自己掌握的：账务与资金处理的核心逻辑、客户与交易数据的所有权与可取回性、风控策略与阈值的最终决定权、以及对系统的审计与取数能力。即使系统是买来的或租用的，你也要能随时取出完整数据、能向监管演示流程、能在合同终止时把数据和业务迁走。
可以外包但责任仍在你的：身份核验与名单筛查、交易监控工具、部分技术运维、客服与投诉处理、以及部分后台运营。这些属于重大外包时，监管通常对事前通知或审批、合同必备条款、以及监管对服务商的检查权有要求。意思是：你的外包合同本身会成为被检查的对象。
实务上要在合同里写死的五项：服务水平与责任限额；数据条款（所有权、处理范围、跨境安排、保密与销毁）；审计权（你和监管方都要能查）；次级外包需事前同意；以及终止与退出安排（过渡期、数据返还格式、协助义务）。这五项缺一项，都会在出事时变成你自己的问题。具体要求以主管部门当期规定为准，个案请咨询执业律师，本文不构成法律意见。
核心系统与数据托管在哪里，是监管问题不是技术问题
选云区域之前先确认这条：受监管业务的核心系统与数据放在哪里，通常受到监管约束，而且监管方需要能够取得访问与检查。很多团队按延迟和价格随手选了区域，上线之后才发现要迁移，代价远高于一开始就选对。
要在选型阶段问清的六个问题：
- 数据存放在哪个法域，备份和灾备又在哪。主数据和备份分处不同法域是常见的疏漏来源。
- 跨境传输怎么安排。在菲律宾数据隐私法框架下，把处理交给境外服务商并不会免除控制者的责任，控制者对个人资料的保护义务仍然存在，相关合同条款与保障措施要落实。基础框架见 菲律宾数据隐私法对企业的基本要求。
- 监管与审计的可及性。监管方或其指定人员需要检查时，能不能取得系统访问与记录？这要在与服务商的合同里事先约定，临时申请通常来不及。
- 日志与记录保存。交易记录、身份资料与审计日志的保存期限与可读性要满足监管要求，不能因为换了供应商就断档。
- 灾备与恢复目标。恢复时间与恢复点目标要写进合同并做演练，不是写在方案书里就算数。
- 退出方案。合同终止时数据以什么格式返还、协助迁移的义务、以及原服务商的数据销毁证明。
另外两条容易漏的：一是个人资料的最小必要原则——客服外包、催收外包、营销外包时把整表客户资料交出去，是这一行最常见的合规瑕疵之一，正确做法是按业务需要限定字段、限定访问、留访问日志；二是数据处理者与控制者的关系要有书面协议，明确处理范围、安全措施、事故通报与协助义务。
KYC 与反洗钱供应商、银行与通道合作方：怎么选、怎么查、怎么被反向查
这一行的供应商尽调要做三层：主体真实性、能力证据、合同条款。第三层最容易被跳过，也最贵。
第一层，主体真实性。对方是不是真实注册、登记状态是否有效、经营范围与你要买的服务是否相符、地址与实际办公是否一致、有没有公开的不良记录。查册入口与文件清单见 菲律宾供应商尽职调查怎么做。
第二层，能力证据——要文件，不要演示。安全与合规方面的第三方评估或认证要看有效期与适用范围（很多认证只覆盖某个产品线或某个数据中心）；渗透测试与漏洞管理要看最近一次的报告摘要与整改闭环；事故历史要问过去的中断与泄露如何处置；客户参考要找同类业务规模的实际用户。对 KYC 与交易监控类供应商，还要看规则与模型是否可配置、判定结果是否可解释、记录是否可导出——因为出问题时要向监管解释的是你，不是供应商。
第三层，合同条款。除了上一节那五项，KYC 与 AML 类服务还要额外写清：服务范围与不覆盖的部分（避免你误以为已经全覆盖）、记录保存与可导出、误判与漏判的处理流程、以及升级与变更的通知义务。
资金侧的合作方会反向尽调你。银行与通道方在建立合作前，通常会审查你的股东与实际控制人背景、业务模式与资金流向、反洗钱制度与合规人员配置、客户构成与风险画像、以及历史合规记录。准备一份完整、真实、前后一致的材料包，比反复补件效率高得多。公司开户本身的门槛与材料可参考 菲律宾企业银行开户指南。本文不推荐任何银行、通道或平台产品，也不评价任何机构。
三类断供：通道断、系统断、人断，应对方式完全不同
金融科技的中断不像制造业那样表现为停产，而是表现为「交易做不了、钱到不了、客户找不到人」，而且三类断供的恢复路径完全不同。
第一类：资金通道中断。合作方终止、限额调整、临时风控收紧、或系统升级，都会让交易无法完成。可控的做法是：不把全部交易量押在单一通道上、建立可切换的路由能力、保持对账能力在通道切换后仍然完整、以及在合同里约定变更与终止的提前通知期。通道冗余不是等出事再建，因为新合作方的接入与尽调本身需要时间。
第二类：系统与技术中断。云区域故障、第三方 API 不可用、版本发布引入故障。要准备的有四样：明确的降级方案（哪些功能可以暂停、哪些必须保住）、演练过的恢复流程、面向客户的沟通模板、以及事件记录与上报机制——受监管业务通常对重大运营中断与信息安全事件有报告要求，具体以主管部门当期规定为准。
第三类：人的中断。客服外包换供应商或换班组、关键工程师离职、合规负责人空缺。这一类的应对靠制度不靠人：文档与操作手册可交接、账号与权限有清单且离职即回收、关键岗位有备份人选、外包切换的过渡期在合同里留足。合规负责人这类岗位空缺本身可能构成合规问题，不是普通招聘问题。
三类通用的一条：把源代码或系统的可迁移性当成风险项管理。对定制开发或深度依赖的系统，可以考虑源代码托管、接口与数据结构文档交付、以及退出时的协助义务，这些都要在签约时谈，事后没有筹码。
最容易踩的七个坑：前三个都是「以为外包了就不关我事」
这一行的坑高度集中在一个误解上：把供应商的结论当成自己的合规结论。
- 先上线再补资质。受监管业务必须由持有相应资质的主体开展，没有资质就不能做，整改的代价是业务停摆而不是补一张纸。资质规划应在产品设计之前，不是之后。
- 把 KYC 供应商的核验结果当成自己的合规结论。工具给的是输入，判断与记录责任在你。要能解释每一条判定的依据、能导出记录、能在被问到时还原当时的流程。
- 云区域按延迟和价格选，没确认托管地与监管可及性。上线后再迁移，成本和风险都远高于一开始选对。
- 外包合同没写审计权与次级外包条款。服务商把你的业务再转包给第三方而你不知道，是真实存在的风险；监管来查时你也拿不到访问权。
- 单一资金通道。通道一断业务就停，而新通道的接入与尽调需要时间，临时找来不及。
- 客服或催收外包时把整表客户资料给出去。正确做法是按业务需要限定字段与访问范围、留访问日志、并签署明确处理范围与安全义务的书面协议。
- 没有退出方案。合同终止时数据拿不回来、格式不可用、系统迁不走，这时候谈条件已经晚了。
还有一条底线要写明：任何规避牌照要求、规避反洗钱与客户身份识别义务的做法，都不在本文讨论范围，也不应作为商业方案考虑。
什么时候该找专业协助：业务模式对应哪一类资质、重大外包的通知与合同要素、数据托管与跨境安排、以及与银行和通道合作前的材料准备，建议在产品定型和第一份外包合同签署之前完成。其他行业把「许可条件反压供应链」这件事做得更极端的例子，可对照 矿业项目的本地供应链与 房地产开发的供应链。个案请咨询执业律师，本文不构成法律意见，也不构成投资建议。易行是私营咨询公司，与政府部门无隶属关系，持有 SEC 注册号 CS202009551、移民局认证 BI Accreditation No. CA-202624381-1、劳工部 DOLE 认证与退休署 PRA 认证。