FSI Meetup 2025 Q4 - PayPal 金融交易資料對帳器

場次筆記

PayPal 簡介：

PayPal 是一家全球支付服務供應商，每年處理的支付總額達 1.7 兆。
業務遍及全球 200 個市場，擁有 4.3 億個活躍帳戶。
每秒約處理 900 筆交易，在黑色星期五和網路星期一等假日購物季期間會達到高峰。

關鍵問題：

確保龐大交易量的準確性並完成對帳。
對 PayPal 內部多個系統、外部處理商及網路之間的交易進行對帳。
配對交易，確保沒有資料或財務差異。
驗證財務紀錄準確反映客戶的實際付款。

對帳流程：

交易流經 PayPal 的系統，並記錄於多個內部帳本中。
交易會傳送至外部處理商進行清算，再由網路確認。
PayPal 將交易款項結算給商家。
對帳涉及配對 PayPal 內部系統、處理商確認資訊，以及資金結算摘要（當日結束、T+1、T+2）中的交易。
主要目標：確保交易不會遺失，且不存在任何差異。

對帳為何重要：

三方配對問題：PayPal 內部帳本、外部處理商紀錄，以及網路確認資訊。
對財務準確性與客戶信任至關重要。
確保財務紀錄反映客戶的實際付款。

高階架構：

著重說明 PayPal 如何實現近乎即時的對帳。
用來因應此問題之規模與複雜度的技術和策略。

業務影響：

對帳時間從 24 小時縮短至 15 分鐘。
提高準確性，將差異降至最低。
提升客戶信任與營運效率。

PayPal 對帳系統的延伸討論

三方配對問題： PayPal 內部帳本：

記錄 PayPal 系統內的交易。

外部處理商：

在其本機系統中登錄交易。

網路確認：

確認交易是否已成功完成。

職責：

PayPal 負責配對交易從進入系統到與商家結算之間每個階段的紀錄。
由於交易量龐大，人工對帳並不可行。

搭配規則引擎的自動化狀態機：

採用自動化狀態機和高階規則引擎。
經過設定，可處理與外部供應商之間的交易作業，以及確認資訊和資金摘要的時程。
確保高效率地完成交易對帳。

對帳的重要性：

對理解「系統顯示發生的情況與實際發生的情況」至關重要。
確保交易可供稽核，並符合監管標準（PCI DSS）。
清楚記錄交易何時入帳及結算。

舊有系統目前的不足：

舊有系統仰賴每日結束時的批次處理。
採用儲存後處理機制，交易全天持續累積，並於當日結束時進行對帳。
為避免影響效能與延遲，並未使用直接的營運資料存放區作為單一事實來源。
採用從 Oracle GoldenGate 取得資料的 ETL 系統。
ETL 管線涉及轉換與格式化，因此可能造成資料不相符或不一致。

改善需求：

從批次處理轉向近乎即時的處理。
降低對 ETL 系統的依賴，以盡量減少資料轉換問題。
強化自動化，確保對帳準確且及時。

舊有系統的問題：

因為必須等到當日結束才能納入所有交易，所以會產生延遲。
只有在當日結束時才會配對交易並關帳。
這項延遲是個重大問題。

目標：

轉換至雲端的新世代平台。
運用 AWS 基礎設施解決上述問題。

新解決方案的主要目標：涵蓋支付生命週期的端對端資料完整性：

從紀錄進入即時支付處理系統的那一刻起，確保資料完整性。
跨 PayPal 內部多個系統追蹤交易。
使用正確的識別碼與時間戳記連結所有交易。
配對傳送給處理商的出站檔案與從網路或供應商收到的入站紀錄。

自動化狀態驅動配對邏輯：

從儲存後處理機制轉向串流處理機制。
縮短整個對帳週期。

即時監控：

在配對內部系統中的交易或外部供應商紀錄時識別例外狀況。
記錄所收到紀錄與本機帳本交易配對失敗的例外狀況。
由營運團隊針對這些已記錄的例外狀況採取行動。

技術架構：資料注入：

資料注入對帳器的來源。

對帳流程：

執行對帳所涉及的方法與流程。

對帳結果的儲存：

對帳結果的儲存方式。

營運團隊的運用方式：

營運團隊如何使用對帳例外狀況並採取行動。

高階技術對帳概觀範圍界定：

上游支付處理系統已抽象化，不納入討論。
討論範圍從即時支付卡處理器開始。

即時支付卡處理器：

使用 EKS 服務接收每日數百萬筆交易（預計每天約 3 億筆交易）。
每筆交易都記錄在 AWS DynamoDB 中，作為單一事實來源與營運資料存放區。

資料流：

[ 1 ] 從 DynamoDB 到 Kinesis Data Stream：
記錄在 DynamoDB 中的交易會透過 Kinesis Data Stream 以串流方式傳送。
Kinesis 管理交易順序。
[ 2 ] Amazon Data Firehose：
根據不同的業務參數將交易分組並切分。
[ 3 ] AWS S3：
交易會記錄在 AWS S3 中。
S3 是交易的次要資料存放區，但在檔案處理方面則是主要資料存放區。

對帳流程：

[ 1 ] PayPal 中的入站交易：
PayPal 中已處理的交易會轉換成檔案格式並存放於 AWS S3。
[ 2 ] 外部合作夥伴處理：
分塊檔案會轉換成檔案，並由外部合作夥伴處理。
外部合作夥伴傳回的入站紀錄會送回 S3。

以 AWS S3 作為中央來源：

S3 同時保存內部交易軌跡，以及以入站檔案形式收到、經外部處理的交易。

資料處理：

EventBridge 排程：
每 15 分鐘觸發 AWS EMR 叢集上的 Apache Spark。
使用預先設定的規則引擎，對 S3 中的交易進行分散式處理。

規則引擎：

由多個狀態圖組成。
將交易分類並判定終止狀態。
包含根據市場營運、外部合作夥伴，以及資料匯出／匯入截止時間制定的複雜規則。

技術對帳架構 Apache EMR 叢集與規則引擎：

Apache EMR 叢集使用規則引擎配對交易。
對帳成功的結果會寫回 AWS S3。
例外狀況會傳送至 AWS EventBridge，由其觸發 Lambda 函式來補充資訊，並將例外狀況回報至 S3。

儲存與營運層面：

資料以 parquet 檔案格式儲存在 S3 中。
在 parquet 檔案之上設定 Apache Glue Catalog。
營運團隊可以使用 Amazon Athena，以 SQL 方式查詢資料。
建置於 Glue Catalog 之上的客製化 UI 入口網站，可提供特定日期、結算或合作夥伴的詳細對帳狀態與結果。

架構重點：主動－主動式架構：

跨多個 AWS 區域運作。
以零復原點目標（RPO）和零復原時間目標（RTO）確保高可用性。
若某個區域停止運作，另一個區域可無縫處理交易。
使用 Amazon Kinesis Data Stream 和 DynamoDB 管理處理中的交易，以確保跨區域的一致性。

技術與架構決策：

AWS EMR 與 Redshift 的比較：
曾考慮使用 Redshift 建置資料湖解決方案，但基於成本效益而選擇 AWS EMR。
將 EMR 叢集延伸至核心處理系統，並運用現有的 S3 資料存放區。
使用 AWS EMR 實現問題陳述所要求的目標，達成低成本的解決方案。

新對帳解決方案的業務影響準確性：

從三個 9 提升至四個 9。

速度：

對帳時間從 24 小時縮短為 15 分鐘一個週期。
水平擴展叢集可確保無論交易量多寡（100 萬至 3 億筆交易），處理時間皆維持一致（最長 30 分鐘）。

降低風險：

加快對帳速度（15 分鐘內）可盡量降低潛在詐欺與風險。
能更快針對系統或外部問題採取行動。

成本最佳化：

基於成本效益，選擇 AWS EMR 叢集，而非資料湖解決方案。
EMR 叢集和 Lambda 函式依需求運作，而非持續執行。
運算執行個體的存續時間有限，處理完成後便會釋放資源並盡量降低成本。

FSI Meetup 2025 Q4 - PayPal 金融交易資料對帳器

回顧系列

場次筆記