AWS Re:cap 07: 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 函式依需求運作，而非持續執行。

● 運算執行個體的存續時間有限，處理完成後便會釋放資源並盡量降低成本。