跳至主要內容
XSIS
金融區的辦公大樓

產業

金融科技與金融服務

串連銀行、支付與總帳,以實現即時準確並因應監理審查。

金融產品為何在連結處失敗

金融產品很少是單一系統。它由核心總帳、卡片處理、身分驗證、詐欺篩檢、支付管道以及背後的 ERP 組成。難點在於它們之間的連結,以及其中一個失敗時會發生什麼。我們先設計這些連結,並寫明失敗路徑。

  • 嚴格的監理截止日期

    沙烏地 ZATCA 第二階段、阿聯 PINT-AE 等電子發票強制要求,以及 DORA 等韌性規則,都有固定生效日期。

  • 不能外流的資料

    受監理銀行不能將客戶或財務紀錄傳送至境外的公開 AI 服務。

  • 人工對帳

    銀行、處理機構與 ERP 之間仍依賴批次檔案和試算表。

帶來什麼變化

  1. 即時總帳準確性

    每筆入帳、費用與結算自動對帳,異常轉交人工。

  2. 做好監理審查準備

    上線前即限制存取並留有日誌,所有變更可追溯。

  3. 主權 AI

    在您自有環境中執行的文件 AI 與助理,資料不出境。

從運河眺望黃昏時的杜拜天際線

我們的重點業務領域

金融科技是我們的重點產業。我們建置並整合銀行、支付公司、放款機構、財富管理機構、保險公司與錢包供應商所執行的軟體,並熟悉這些系統使用的標準:ISO 20022、ISO 8583、EMV、開放銀行 API,以及銀行仍依賴的檔案格式。

我們為受監理環境建置系統。存取受限並記錄,敏感資料不進入不需要它的地方,所有變更均可追溯。您的法遵與風險團隊在系統上線前就能了解其運作方式,而不是事後。

一名銀行櫃員在櫃檯與客戶一起清點現金

我們服務的領域

我們建置什麼

  • 針對零售與企業客戶的數位銀行應用與入口網站
  • 透過 API 封裝並擴充核心銀行系統的服務,而非替換核心
  • 用於付款檔案、核准、對帳單與現金部位的企業通路
  • 用於營運、支付調查與客戶服務的後台工具
  • 伊斯蘭金融技術與核心總帳擴充

典型整合

  • 核心銀行系統,透過其 API、訊息佇列或批次介面

我們建置什麼

  • 支付編排,將每筆交易路由至正確的閘道、收單機構或支付管道
  • 商家導入、入口網站與報表
  • 結算、費用計算與撥款服務
  • 對帳,比對交易、結算與銀行對帳單

我們建置什麼

  • 貸款申請受理:申請、文件蒐集與決策工作流程
  • 信用決策,採用授信團隊可複核的規則與可解釋模型
  • 貸款服務:還款排程、還款、欠款與催收
  • 經紀商與合作夥伴入口網站

典型整合

  • 徵信機構、開放銀行帳戶資料與身分驗證
  • 核心銀行或貸款總帳,以及透過直接扣款或卡片收款

我們建置什麼

  • 含投資組合、交易與文件的客戶入口網站與應用
  • 基於保管機構與市場資料的投資組合及客戶報告
  • 含適當性與風險輪廓問卷的客戶導入
  • 用於客戶檢視、方案與再平衡的顧問工具

典型整合

  • 保管機構、經紀商與市場資料供應商
  • 投資組合管理與 CRM 系統

我們建置什麼

  • 針對客戶與經紀商的報價與購買旅程
  • 針對產品、批單與續保的保單管理擴充
  • 含文件 AI、分流與狀態追蹤的理賠受理
  • 定價與風險資料管線

典型整合

  • 保單管理與理賠系統
  • 保費收取、退款與總帳

我們建置什麼

  • 支援儲值、轉帳、帳單支付與商家支付的錢包應用
  • 採用複式入帳與每日平衡的錢包總帳
  • 用於行動支付的發卡與權杖化卡片
  • 營運團隊可自行調整的限額、費用與會員獎勵規則

典型整合

  • 發卡處理機構與權杖化服務

我們建置什麼

  • 用於金融模擬的大型量化模型(LQM)
  • 高頻交易(HFT)系統
  • 即時詐欺、防制洗錢與行為異常偵測

典型整合

  • 市場資料供應商與交易場所

我們建置、串接與防護什麼

  • 數位通路

    Web 與行動銀行、錢包與投資應用,針對客戶設計,並按發薪日與月底的負載建置。

  • 核心擴充

    圍繞核心銀行或總帳系統的服務,在不進行高風險替換的前提下增加產品與通路。

  • 支付編排

    跨閘道、收單機構與支付管道的路由、重試與容錯移轉,每次嘗試均留下紀錄。

  • 客戶導入與 KYC

    客戶與企業導入,含身分驗證、篩檢與文件蒐集,並有清晰的人工複核路徑。

  • 詐欺與交易監控

    在交易發生時評分的規則與機器學習模型,暫留可疑交易待複核。

  • 對帳與財務

    跨總帳、處理機構、銀行與 ERP 的比對,使財務基於可信資料結帳。

  • 銀行介接

    透過主機對主機(host-to-host)通道、EBICS 或銀行 API,以 ISO 20022 與 MT 格式收發支付與對帳單。

  • 卡片處理

    透過 ISO 8583 或 API 連結收單機構、處理機構與發卡平台,門市使用 EMV 終端機,線上使用 3-D Secure。

  • 開放銀行

    透過受監理的銀行 API 與聚合平台取得帳戶資訊並發起支付,妥善處理客戶同意。

  • 身分、KYC 與防制洗錢

    身分驗證、制裁與政治公眾人物篩檢、負面媒體查核,所有結果保留供稽核。

  • ERP 與總帳

    入帳、費用與結算帶入 ERP,使財務與營運看到相同數字。

  • 卡片資料與 PCI DSS

    我們盡量透過權杖化與代管支付欄位,讓卡片資料不進入您的系統,從而縮小 PCI DSS 範圍。必須處理卡片資料時,我們依您的評估人員將測試的控制要求建置。

  • 強客戶認證

    我們建置支付與銀行規則要求的身分驗證流程,例如雙因素登入與交易簽章,僅使用您的風險團隊允許的豁免。

  • KYC 與防制洗錢控制

    客戶導入與監控保留法遵團隊所需的證據:檢查了什麼、何時、由哪個供應商、由誰做出決定。

  • 資料保護

    工作開始前我們議定個人與財務資料可儲存和處理的地點,並在適用時按 GDPR 以及阿聯 PDPL、沙烏地 PDPL 等當地法律設計。

  • 稽核軌跡與韌性

    對資金、限額與權限的每次變更均留下紀錄並可追溯,系統依營運韌性規則的要求,建置為能安全失效並復原。

我們的工作方式

  1. 檢視就緒程度

    首席工程師檢視範圍、系統、資料與監理需求。

  2. 設計連結

    首先設計整合層、其失敗路徑與稽核軌跡。

  3. 交付與營運

    在驗收關卡後分階段發布,隨後依約定服務等級進行託管營運。

數位金融產品,端對端銀行或錢包應用程式與單一 API 層通訊。其背後是身分驗證、卡片處理與核心總帳。交易發生時即時篩檢,任何可疑交易都會暫留,交由人工複核。人員客戶服務銀行或錢包應用程式Web 與行動裝置XSISAPI 層身分驗證、限額與稽核日誌第三方KYC 與防制洗錢供應商客戶導入與篩檢閘道卡片處理機構發卡與授權銀行核心銀行或總帳帳戶、餘額與入帳服務詐欺與交易監控規則與模型人員法遵與營運團隊複核暫留與轉介12REST/JSON · OAuth 2.03REST/JSONwebhook4REST/JSON · ISO 200225REST/JSON6ISO 8583789

數位金融產品,端對端

銀行或錢包應用程式與單一 API 層通訊。其背後是身分驗證、卡片處理與核心總帳。交易發生時即時篩檢,任何可疑交易都會暫留,交由人工複核。

  • 主流程
  • 非同步
  • 異常路徑
9 步流程

流程逐步說明

  1. 從 客戶 到 銀行或錢包應用程式:註冊、支付與轉帳(主流程)。
  2. 從 銀行或錢包應用程式 到 API 層:請求,經由 REST/JSON · OAuth 2.0(主流程)。
  3. 從 API 層 到 KYC 與防制洗錢供應商:身分與篩檢驗證,經由 REST/JSON · webhook(主流程)。
  4. 從 API 層 到 核心銀行或總帳:入帳與餘額,經由 REST/JSON · ISO 20022(主流程)。
  5. 從 API 層 到 卡片處理機構:發卡與控制,經由 REST/JSON(主流程)。
  6. 從 卡片處理機構 到 核心銀行或總帳:卡片交易,經由 ISO 8583(非同步)。
  7. 從 API 層 到 詐欺與交易監控:待篩檢交易,以事件流形式傳送(非同步)。
  8. 從 詐欺與交易監控 到 法遵與營運團隊:暫留待複核(異常路徑)。
  9. 從 KYC 與防制洗錢供應商 到 法遵與營運團隊:失敗或不明確的驗證轉介(異常路徑)。
ERP 到銀行:付款出,對帳單入已核准的付款以已簽章的 ISO 20022 檔案透過主機對主機(host-to-host)通道離開 ERP。狀態報告與對帳單以相同方式回傳,並與未清項核對。退件與未核對明細連同原因交予您的團隊。ERPERP付款批次、未清項、總帳XSIS整合層對映、驗證、簽章與調度閘道安全銀行通道主機對主機 SFTP、EBICS或銀行 API銀行銀行支付與資金管理服務對帳引擎比對規則與容差人員資金與財務團隊複核退件與差異1REST/JSON · IDoc2ISO 20022 pain.001OpenPGP3SFTP H2H4pain.002 · camt.053MT9405SFTP H2H6camt.0537REST/JSON8pain.002 RJCT910

ERP 到銀行:付款出,對帳單入

已核准的付款以已簽章的 ISO 20022 檔案透過主機對主機(host-to-host)通道離開 ERP。狀態報告與對帳單以相同方式回傳,並與未清項核對。退件與未核對明細連同原因交予您的團隊。

  • 主流程
  • 非同步
  • 異常路徑
10 步流程

流程逐步說明

  1. 從 ERP 到 整合層:已核准的付款批次,經由 REST/JSON · IDoc(主流程)。
  2. 從 整合層 到 安全銀行通道:已簽章並加密的付款檔案,經由 ISO 20022 pain.001 · OpenPGP(主流程)。
  3. 從 安全銀行通道 到 銀行:已送達銀行,經由 SFTP H2H(主流程)。
  4. 從 銀行 到 安全銀行通道:狀態報告與對帳單,經由 pain.002 · camt.053 · MT940(非同步)。
  5. 從 安全銀行通道 到 整合層:已接收並驗證,經由 SFTP H2H(非同步)。
  6. 從 整合層 到 對帳引擎:對帳單明細行,經由 camt.053(非同步)。
  7. 從 對帳引擎 到 ERP:已核對並入帳的分錄,經由 REST/JSON(主流程)。
  8. 從 整合層 到 資金與財務團隊:被拒絕的付款,附原因代碼,經由 pain.002 RJCT(異常路徑)。
  9. 從 對帳引擎 到 資金與財務團隊:未核對明細:對帳差異(異常路徑)。
  10. 從 資金與財務團隊 到 ERP:已更正並重新提交(異常路徑)。
卡片支付:收銀台授權,稍後結算,在 ERP 中對帳終端機或結帳頁向閘道發起請求,閘道向收單機構發起請求,收單機構再路由至卡組織與發卡機構。結算檔案稍後到達,並與 ERP 中的銷售及費用核對。逾時會觸發撤銷,避免重複向客戶扣款。POSEMV 終端機或線上結帳晶片、感應式與電子商務閘道支付閘道權杖化與路由銀行收單機構授權與結算第三方卡組織與發卡機構核准或拒絕ERPERP銷售、費用與撥款XSIS整合層結算解析與核對人員支付營運團隊對帳不符、爭議與拒付1EMV · REST/JSON2ISO 85833ISO 85834ISO 85835SFTP6REST/JSON7ISO 8583 04008

卡片支付:收銀台授權,稍後結算,在 ERP 中對帳

終端機或結帳頁向閘道發起請求,閘道向收單機構發起請求,收單機構再路由至卡組織與發卡機構。結算檔案稍後到達,並與 ERP 中的銷售及費用核對。逾時會觸發撤銷,避免重複向客戶扣款。

  • 主流程
  • 非同步
  • 異常路徑
8 步流程

流程逐步說明

  1. 從 EMV 終端機或線上結帳 到 支付閘道:授權請求,經由 EMV · REST/JSON(主流程)。
  2. 從 支付閘道 到 收單機構:授權,經由 ISO 8583(主流程)。
  3. 從 收單機構 到 卡組織與發卡機構:已路由至發卡機構,經由 ISO 8583(主流程)。
  4. 從 收單機構 到 支付閘道:已核准或拒絕,經由 ISO 8583(非同步)。
  5. 從 收單機構 到 整合層:結算與費用檔案,經由 SFTP(非同步)。
  6. 從 整合層 到 ERP:已結算銷售、費用與撥款,經由 REST/JSON(主流程)。
  7. 從 支付閘道 到 EMV 終端機或線上結帳:逾時無回應:自動撤銷,經由 ISO 8583 0400(異常路徑)。
  8. 從 整合層 到 支付營運團隊:結算不符或拒付(異常路徑)。
開放銀行:經客戶同意的資料與支付客戶給予同意,連接器保管權杖,每次呼叫銀行均經授權並記錄。同意過期或撤回時,應用程式會再次請客戶同意,而不是悄然失敗。人員客戶服務您的應用或平台資金管理、放款或會計XSIS開放銀行連接器同意、權杖與資料正規化銀行銀行 API 或聚合平台帳戶資訊與支付發起ERPERP 或總帳現金部位與對帳12REST/JSON3OAuth 2.0 · FAPI · REST4REST/JSON · webhook5REST/JSON6HTTP 401 · 4037

開放銀行:經客戶同意的資料與支付

客戶給予同意,連接器保管權杖,每次呼叫銀行均經授權並記錄。同意過期或撤回時,應用程式會再次請客戶同意,而不是悄然失敗。

  • 主流程
  • 非同步
  • 異常路徑
7 步流程

流程逐步說明

  1. 從 客戶 到 您的應用或平台:給予同意(主流程)。
  2. 從 您的應用或平台 到 開放銀行連接器:帳戶與支付請求,經由 REST/JSON(主流程)。
  3. 從 開放銀行連接器 到 銀行 API 或聚合平台:經授權的 API 呼叫,經由 OAuth 2.0 · FAPI · REST(主流程)。
  4. 從 銀行 API 或聚合平台 到 開放銀行連接器:餘額、交易與支付狀態,經由 REST/JSON · webhook(非同步)。
  5. 從 開放銀行連接器 到 ERP 或總帳:正規化交易,經由 REST/JSON(主流程)。
  6. 從 銀行 API 或聚合平台 到 開放銀行連接器:同意過期或撤回,經由 HTTP 401 · 403(異常路徑)。
  7. 從 開放銀行連接器 到 您的應用或平台:請客戶重新同意(異常路徑)。

如何開始

後續流程

  1. 約定時間

    我們的團隊會透過電子郵件與您約定會談時間。

  2. 諮詢前會談

    一次免費 30 分鐘線上預諮詢:我們盤點您的目標、系統與限制條件。

  3. 就緒評估

    在免費 48 小時就緒評估中,首席架構師對照 6 項就緒定義檢查您的專案,並建議合適的路線。

  4. 選擇路線

    範圍就緒的專案會收到一份有約束力的方案 3–5 個工作天內。概念階段的專案從 Blueprint Studio 開始。已上線系統若出現故障、缺乏文件或需要整合,則先進行 1–2 週 的診斷。Blueprint Studio 與診斷服務各收取固定費用,費用在方案中列明。

最快的切入點是 強制電子發票與 ERP 就緒衝刺,屬於我們的快速合作方案之一。

從何處開始

問題與解答

XSIS 做哪些金融科技工作?

金融科技是我們的重點產業。我們建置數位銀行與錢包應用、支付與結算服務、放款平台、財富管理報告與保險旅程,並將它們連結至銀行、卡片處理機構、KYC 供應商與 ERP 系統。未經客戶同意,我們不公布客戶名稱,因此我們透過所合作的系統與標準,以及與您架構師的技術交流來展示經驗。

貴公司能在我們的監理與資安要求內工作嗎?

可以。我們在您的政策內工作:您的存取規則、環境、變更流程與稽核要求。工作開始前我們議定資料處理方式、工程師可存取哪些環境,以及您的風險與法遵團隊需要哪些證據。我們清楚說明所採用的控制,便於您的評估人員審查。

我們必須替換核心銀行系統嗎?

通常不必。多數銀行透過將核心封裝為定義良好的 API,並在其周圍以服務方式建置新產品與管道,獲得更大收益。這能保持紀錄系統穩定,同時讓面向客戶的部分更快變化。確實必須替換核心時,我們分階段規劃遷移,在舊系統關閉前保持兩套系統對帳。

貴公司如何處理卡片資料?

我們的設計讓盡可能少的系統看到完整卡號。代管支付欄位、權杖化與卡組織權杖將卡片資料留在處理機構端,從而縮小您的 PCI DSS 範圍。系統必須處理卡片資料時,我們按適用的 PCI DSS 控制建置,並為您的評估人員記錄這些控制。

貴公司支援 ISO 20022 與即時支付嗎?

支援。我們建置可建立、驗證與讀取 ISO 20022 訊息的服務,既用於企業支付與報告(如 pain.001 與 camt.053),也用於即時與大額支付系統使用的銀行間訊息。每個支付體系與銀行都有自己的規則,因此我們依據其實作指南工作,並在其測試環境中測試。

貴公司能建置詐欺與交易監控嗎?

可以。我們將分析師可讀取與修改的規則,以及基於您自有資料訓練的機器學習模型結合,並解釋每次警示的原因。警示進入案件佇列,由分析師決定,其決定再回饋到規則與模型中。若您已使用專業篩檢供應商,我們會將其串接。

金融科技專案的成本由什麼決定?

涉及的系統與合作夥伴數量、適用的監理控制、系統必須處理的交易量與速度,以及合作夥伴在上線前要求的測試量。銀行或處理機構認證等合作夥伴開通,往往比程式碼更能決定進度。我們在需求探索後估算,並將工作拆分為可逐項提供資金並核准的階段。

從對話開始,而不是從合約開始。

告訴我們您需要建置、串接與防護什麼。架構師會與您逐項討論,然後建議從何處入手。