金融科技的供應盤子有六塊，其中一塊根本不叫供應鏈，叫准入
先把六塊拆開，因為它們的採購邏輯完全不同：有的可以談價，有的只能按合規要求選，有的壓根不能外包。
- 牌照與合規主體——這塊嚴格説不是供應鏈，是准入。菲律賓對支付、匯款、電子貨幣、借貸等受監管業務設有牌照與登記要求，沒有相應資質就不能開展對應業務，這一條沒有變通空間。本文只陳述門檻存在，不涉及任何規避做法。
- 核心系統與技術棧——賬務與賬户系統、交易處理、對賬與清結算、風控引擎、API 網關、以及承載它們的雲或機房。自研、採購還是 SaaS，各有不同的監管含義。
- 數據——客户身份資料、交易記錄、日誌與審計追蹤、備份與災備。存在哪裏、能不能被監管看到、誰能訪問，是這一行最硬的約束之一。
- KYC 與反洗錢相關服務——身份核驗、證件識別與活體檢測、名單篩查、交易監控與可疑活動分析、以及相關記錄保存。工具可以買，但判斷與記錄的責任在你。
- 資金側的合作方——銀行合作、清算與支付通道、收單與代付渠道、結算與資金歸集安排。這一塊決定業務能不能真正跑起來，也最容易被單點卡住。
- 客服與運營外包——客服坐席、爭議與投訴處理、運營支持。菲律賓在這一塊的供給能力很強，但涉及客户資料的處理，合規要求跟一般客服外包不同。
六塊之中，第一塊決定你能不能做，第二和第三塊決定你能不能通過檢查，第五塊決定業務能不能跑，第四和第六塊決定你會不會因為別人的疏漏被追責。税務與優惠這一條線不在本文範圍，見 在菲律賓做金融科技與支付。主體設立與市場進入的判斷屬於 市場進入與立項。純人力與座席型外包的組織邏輯可對照 BPO 的供應鏈。
哪些必須自己持有、哪些能外包、哪些外包了責任還在你
先記住這條：外包轉移的是工作量，不是合規責任。監管看的是持牌或申牌主體，不是你的服務商。把這條想清楚，下面的邊界就不難劃。
不能外包的：牌照與資質本身，以及基於牌照的合規責任。受監管業務必須由持有相應資質的主體開展，董事與高管的適當性、合規職能的建立與運行、向監管的報告義務，都屬於主體自身的義務。借用他人資質開展業務、或把受監管環節包裝成技術服務來規避牌照要求，都不是可行路徑，本文不討論任何此類做法。
通常應自己掌握的：賬務與資金處理的核心邏輯、客户與交易數據的所有權與可取回性、風控策略與閾值的最終決定權、以及對系統的審計與取數能力。即使系統是買來的或租用的，你也要能隨時取出完整數據、能向監管演示流程、能在合同終止時把數據和業務遷走。
可以外包但責任仍在你的：身份核驗與名單篩查、交易監控工具、部分技術運維、客服與投訴處理、以及部分後台運營。這些屬於重大外包時，監管通常對事前通知或審批、合同必備條款、以及監管對服務商的檢查權有要求。意思是：你的外包合同本身會成為被檢查的對象。
實務上要在合同裏寫死的五項：服務水平與責任限額；數據條款（所有權、處理範圍、跨境安排、保密與銷燬）；審計權（你和監管方都要能查）；次級外包需事前同意；以及終止與退出安排（過渡期、數據返還格式、協助義務）。這五項缺一項，都會在出事時變成你自己的問題。具體要求以主管部門當期規定為準，個案請諮詢執業律師，本文不構成法律意見。
核心系統與數據託管在哪裏，是監管問題不是技術問題
選雲區域之前先確認這條：受監管業務的核心繫統與數據放在哪裏，通常受到監管約束，而且監管方需要能夠取得訪問與檢查。很多團隊按延遲和價格隨手選了區域，上線之後才發現要遷移，代價遠高於一開始就選對。
要在選型階段問清的六個問題：
- 數據存放在哪個法域，備份和災備又在哪。主數據和備份分處不同法域是常見的疏漏來源。
- 跨境傳輸怎麼安排。在菲律賓數據隱私法框架下，把處理交給境外服務商並不會免除控制者的責任，控制者對個人資料的保護義務仍然存在，相關合同條款與保障措施要落實。基礎框架見 菲律賓數據隱私法對企業的基本要求。
- 監管與審計的可及性。監管方或其指定人員需要檢查時，能不能取得系統訪問與記錄？這要在與服務商的合同裏事先約定，臨時申請通常來不及。
- 日誌與記錄保存。交易記錄、身份資料與審計日誌的保存期限與可讀性要滿足監管要求，不能因為換了供應商就斷檔。
- 災備與恢復目標。恢復時間與恢復點目標要寫進合同並做演練，不是寫在方案書裏就算數。
- 退出方案。合同終止時數據以什麼格式返還、協助遷移的義務、以及原服務商的數據銷燬證明。
另外兩條容易漏的：一是個人資料的最小必要原則——客服外包、催收外包、營銷外包時把整表客户資料交出去，是這一行最常見的合規瑕疵之一，正確做法是按業務需要限定字段、限定訪問、留訪問日誌；二是數據處理者與控制者的關係要有書面協議，明確處理範圍、安全措施、事故通報與協助義務。
KYC 與反洗錢供應商、銀行與通道合作方：怎麼選、怎麼查、怎麼被反向查
這一行的供應商盡調要做三層：主體真實性、能力證據、合同條款。第三層最容易被跳過，也最貴。
第一層，主體真實性。對方是不是真實註冊、登記狀態是否有效、經營範圍與你要買的服務是否相符、地址與實際辦公是否一致、有沒有公開的不良記錄。查冊入口與文件清單見 菲律賓供應商盡職調查怎麼做。
第二層，能力證據——要文件，不要演示。安全與合規方面的第三方評估或認證要看有效期與適用範圍（很多認證只覆蓋某個產品線或某個數據中心）；滲透測試與漏洞管理要看最近一次的報告摘要與整改閉環；事故歷史要問過去的中斷與泄露如何處置；客户參考要找同類業務規模的實際用户。對 KYC 與交易監控類供應商，還要看規則與模型是否可配置、判定結果是否可解釋、記錄是否可導出——因為出問題時要向監管解釋的是你，不是供應商。
第三層，合同條款。除了上一節那五項，KYC 與 AML 類服務還要額外寫清：服務範圍與不覆蓋的部分（避免你誤以為已經全覆蓋）、記錄保存與可導出、誤判與漏判的處理流程、以及升級與變更的通知義務。
資金側的合作方會反向盡調你。銀行與通道方在建立合作前，通常會審查你的股東與實際控制人背景、業務模式與資金流向、反洗錢制度與合規人員配置、客户構成與風險畫像、以及歷史合規記錄。準備一份完整、真實、前後一致的材料包，比反覆補件效率高得多。公司開户本身的門檻與材料可參考 菲律賓企業銀行開户指南。本文不推薦任何銀行、通道或平台產品，也不評價任何機構。
三類斷供：通道斷、系統斷、人斷，應對方式完全不同
金融科技的中斷不像製造業那樣表現為停產，而是表現為「交易做不了、錢到不了、客户找不到人」，而且三類斷供的恢復路徑完全不同。
第一類：資金通道中斷。合作方終止、限額調整、臨時風控收緊、或系統升級，都會讓交易無法完成。可控的做法是：不把全部交易量押在單一通道上、建立可切換的路由能力、保持對賬能力在通道切換後仍然完整、以及在合同里約定變更與終止的提前通知期。通道冗餘不是等出事再建，因為新合作方的接入與盡調本身需要時間。
第二類：系統與技術中斷。雲區域故障、第三方 API 不可用、版本發佈引入故障。要準備的有四樣：明確的降級方案（哪些功能可以暫停、哪些必須保住）、演練過的恢復流程、面向客户的溝通模板、以及事件記錄與上報機制——受監管業務通常對重大運營中斷與信息安全事件有報告要求，具體以主管部門當期規定為準。
第三類：人的中斷。客服外包換供應商或換班組、關鍵工程師離職、合規負責人空缺。這一類的應對靠制度不靠人：文檔與操作手冊可交接、賬號與權限有清單且離職即回收、關鍵崗位有備份人選、外包切換的過渡期在合同裏留足。合規負責人這類崗位空缺本身可能構成合規問題，不是普通招聘問題。
三類通用的一條：把源代碼或系統的可遷移性當成風險項管理。對定製開發或深度依賴的系統，可以考慮源代碼託管、接口與數據結構文檔交付、以及退出時的協助義務，這些都要在簽約時談，事後沒有籌碼。
最容易踩的七個坑：前三個都是「以為外包了就不關我事」
這一行的坑高度集中在一個誤解上：把供應商的結論當成自己的合規結論。
- 先上線再補資質。受監管業務必須由持有相應資質的主體開展，沒有資質就不能做，整改的代價是業務停擺而不是補一張紙。資質規劃應在產品設計之前，不是之後。
- 把 KYC 供應商的核驗結果當成自己的合規結論。工具給的是輸入，判斷與記錄責任在你。要能解釋每一條判定的依據、能導出記錄、能在被問到時還原當時的流程。
- 雲區域按延遲和價格選，沒確認託管地與監管可及性。上線後再遷移，成本和風險都遠高於一開始選對。
- 外包合同沒寫審計權與次級外包條款。服務商把你的業務再轉包給第三方而你不知道，是真實存在的風險；監管來查時你也拿不到訪問權。
- 單一資金通道。通道一斷業務就停，而新通道的接入與盡調需要時間，臨時找來不及。
- 客服或催收外包時把整表客户資料給出去。正確做法是按業務需要限定字段與訪問範圍、留訪問日誌、並簽署明確處理範圍與安全義務的書面協議。
- 沒有退出方案。合同終止時數據拿不回來、格式不可用、系統遷不走，這時候談條件已經晚了。
還有一條底線要寫明：任何規避牌照要求、規避反洗錢與客户身份識別義務的做法，都不在本文討論範圍，也不應作為商業方案考慮。
什麼時候該找專業協助：業務模式對應哪一類資質、重大外包的通知與合同要素、數據託管與跨境安排、以及與銀行和通道合作前的材料準備，建議在產品定型和第一份外包合同簽署之前完成。其他行業把「許可條件反壓供應鏈」這件事做得更極端的例子，可對照 礦業項目的本地供應鏈與 房地產開發的供應鏈。個案請諮詢執業律師，本文不構成法律意見，也不構成投資建議。易行是私營諮詢公司，與政府部門無隸屬關係，持有 SEC 註冊號 CS202009551、移民局認證 BI Accreditation No. CA-202624381-1、勞工部 DOLE 認證與退休署 PRA 認證。