本教材從工程角度介紹一個現代銀行系統如何設計前端、後端、資料庫、交易流程、安全控管與 API。內容適合作為系統設計、金融科技後端、全端開發與面試準備教材。

注意：真實銀行系統會受到法規、內控、資安稽核與核心銀行主機限制，本教材以教學用架構為主，不構成金融或法遵建議。

Part A：銀行系統全貌

1. 銀行系統在解決什麼問題？

銀行系統的核心不是「顯示帳戶餘額」而已，而是要在高安全、高一致性、高稽核要求下，處理使用者的金錢狀態。

一個銀行系統至少要保證：

錢不能憑空產生或消失：每一筆金額變動都要能追溯。
交易要可回放、可稽核：任何餘額都能由交易明細重新推導。
使用者身分要可信：登入者必須是帳戶合法持有人或授權使用者。
操作要可控：大額交易、陌生裝置、可疑 IP 需要額外驗證。
系統要能容錯：網路斷線、重複送出、第三方延遲都不能造成重複扣款。

銀行系統常見功能包括：

開戶與客戶資料管理
登入與身分驗證
帳戶總覽
餘額查詢
交易明細查詢
行內轉帳
跨行轉帳
約定帳號管理
信用卡與貸款資訊
通知、對帳、報表與稽核

2. 銀行系統的角色與子系統

使用者角色

個人客戶：查詢帳戶、轉帳、繳費、管理卡片。
企業客戶：批次付款、多層簽核、薪資轉帳。
客服人員：協助查詢狀態，但通常不能直接更改金額。
營運人員：處理例外交易、對帳、人工審核。
稽核人員：查看操作紀錄與交易軌跡。
系統管理員：管理權限、服務設定、金鑰與維運。

核心子系統

Digital Banking Frontend：網銀、行動銀行、ATM UI。
API Gateway：統一入口、認證、限流、路由。
Identity Service：登入、MFA、裝置信任、Token。
Customer Service：客戶資料、KYC、風險等級。
Account Service：帳戶基本資料與狀態。
Transaction Service：轉帳、扣款、入帳、交易狀態。
Ledger Service：不可任意修改的會計分錄。
Risk Service：交易風控、詐騙偵測。
Notification Service：簡訊、Email、Push。
Audit Service：使用者與內部人員操作紀錄。
Core Banking System：真正的銀行核心帳務系統。

3. 典型銀行全端架構

教學版架構如下：

Web / Mobile App
       |
       v
API Gateway / BFF
       |
       +--> Identity Service
       +--> Customer Service
       +--> Account Service
       +--> Transaction Service
       +--> Risk Service
       +--> Notification Service
       |
       v
Core Banking Adapter
       |
       v
Core Banking System

為什麼需要 API Gateway？

API Gateway 通常負責：

TLS 終止
API 路由
Token 驗證
Rate limiting
Request ID 產生
基本 WAF 規則
API 版本管理
將外部 API 與內部服務解耦

為什麼常見 BFF？

BFF 是 Backend for Frontend，專門為某個前端通道提供 API。

例如：

Mobile BFF：回傳行動 App 需要的資料格式。
Web BFF：回傳桌面網銀需要的資訊。
Admin BFF：給內部營運後台使用。

BFF 可以避免前端直接呼叫太多微服務，也能把敏感邏輯留在後端。

4. 銀行前端、後端、核心主機的責任切分

前端責任

收集使用者輸入。
顯示帳戶、交易、錯誤與驗證狀態。
執行基本輸入檢查。
管理 UI 狀態與流程。
提供可理解的確認畫面。
觸發 MFA、OTP、裝置驗證。

前端不能負責：

決定交易是否真的成功。
信任本地餘額。
保存敏感憑證。
自行計算可用餘額並作為真實依據。
跳過後端風控與授權。

後端責任

驗證使用者身份與權限。
驗證帳戶狀態與交易限制。
執行風控。
建立交易、鎖定資源、處理狀態機。
寫入 Ledger。
呼叫核心銀行主機。
送通知與寫稽核紀錄。

核心銀行主機責任

核心銀行主機通常是帳務真相來源，負責：

帳戶餘額
會計分錄
扣款與入帳
日終批次
清算與對帳
法定報表資料

在很多銀行中，現代 API 後端不是直接改餘額，而是透過 adapter 呼叫核心主機。

Part B：前端系統設計

5. 前端功能模組

銀行前端通常切成以下模組：

Auth Module：登入、登出、MFA、忘記密碼。
Dashboard Module：總覽所有帳戶、卡片與提醒。
Account Module：帳戶詳情、餘額、明細、電子對帳單。
Transfer Module：行內轉帳、跨行轉帳、常用收款人。
Beneficiary Module：約定帳號、收款人管理。
Card Module：信用卡、金融卡、鎖卡、額度。
Profile Module：個人資料、通知設定、裝置管理。
Support Module：客服、爭議交易、訊息中心。

常見前端路由

/login
/mfa
/dashboard
/accounts
/accounts/:accountId
/accounts/:accountId/transactions
/transfer/new
/transfer/confirm
/transfer/result/:transactionId
/beneficiaries
/profile/security

6. 登入、裝置綁定與多因子驗證

銀行登入通常不是單純帳號密碼。

典型流程：

使用者輸入帳號與密碼。
後端檢查密碼、帳戶狀態與風險。
若裝置陌生或風險偏高，要求 MFA。
使用者輸入 OTP、推播確認或生物辨識。
後端簽發短生命週期 access token。
前端進入 dashboard。

Token 建議

Access token 生命週期短，例如 5 到 15 分鐘。
Refresh token 需要與裝置綁定。
高風險操作前重新驗證。
Token 不應放在 localStorage 儲存高敏感資訊。
Web 可使用 HttpOnly、Secure、SameSite Cookie。
Mobile 可用 Keychain 或 Keystore。

前端登入狀態

前端可以維護：

是否登入
使用者顯示名稱
權限摘要
Token 到期時間
目前裝置是否已信任

但不應保存：

完整密碼
OTP
完整卡號
身分證影本
未遮罩的敏感資料

7. 帳戶總覽與交易明細頁

帳戶總覽通常需要顯示：

帳戶名稱
帳號遮罩，例如 ***1234
帳戶類型
可用餘額
帳面餘額
幣別
最近更新時間
帳戶狀態

可用餘額 vs 帳面餘額

帳面餘額（ledger balance）：已正式入帳的餘額。
可用餘額（available balance）：扣除保留款、未完成交易後可使用的金額。

前端應清楚區分這兩者，避免使用者誤解。

交易明細常見欄位

{
  "transactionId": "txn_20260425_000001",
  "postedAt": "2026-04-25T10:15:30Z",
  "description": "Transfer to Alice",
  "direction": "DEBIT",
  "amount": "1000.00",
  "currency": "TWD",
  "status": "POSTED",
  "balanceAfter": "25000.00"
}

金額建議以字串傳輸，避免 JavaScript 浮點數誤差。

8. 轉帳流程 UI 設計

一個安全的轉帳流程通常分成三步：

輸入頁 - 選擇扣款帳戶 - 輸入收款帳號 - 輸入銀行代碼 - 輸入金額 - 輸入備註
確認頁 - 顯示扣款帳戶遮罩 - 顯示收款帳戶遮罩 - 顯示收款戶名或驗證結果 - 顯示金額與手續費 - 要求使用者確認
結果頁 - 顯示交易編號 - 顯示交易狀態 - 若 pending，告知使用者稍後查詢 - 提供下載或分享交易憑證

重要 UI 原則

金額欄位要有幣別與千分位。
確認頁不可只顯示前端暫存資料，最好從後端 quote API 取得。
送出按鈕要避免重複點擊，但後端仍必須做冪等控制。
錯誤訊息要能區分「輸入錯誤」、「權限不足」、「交易失敗」、「暫時處理中」。

9. 前端狀態管理與安全注意事項

建議的狀態分類

Server state：帳戶、明細、交易結果，應由 API 查詢。
UI state：彈窗、loading、步驟狀態，可放前端 store。
Form state：轉帳表單輸入，送出後應清除敏感欄位。
Auth state：登入狀態與使用者摘要，不應包含敏感秘密。

前端安全清單

所有 API 使用 HTTPS。
不在 console 印出 token、帳號、OTP。
錯誤監控工具要遮罩敏感欄位。
使用 CSP 降低 XSS 風險。
對高風險操作加入重新驗證。
登出時清除記憶體中的敏感資料。
頁面閒置一段時間後自動登出或鎖定。

Part C：後端系統設計

10. 後端服務分層

典型後端可以分成：

Controller / API Layer
        |
Application Service
        |
Domain Service
        |
Repository / Gateway
        |
Database / Core Banking / Message Broker

Controller / API Layer

負責：

解析 request
驗證 schema
取得 authenticated principal
回傳 HTTP response

不應放太多業務邏輯。

Application Service

負責編排 use case，例如：

建立轉帳
查詢帳戶
驗證 MFA
送出通知

Domain Service

負責核心規則，例如：

帳戶是否可扣款
金額是否超過限額
是否需要二次驗證
交易狀態是否允許轉移

Repository / Gateway

負責與外部系統互動：

Database
Core banking host
Fraud engine
Notification provider
Message broker

11. 核心資料模型

以下是教學版資料模型。

Customer

Customer
- id
- legalName
- dateOfBirth
- kycStatus
- riskLevel
- status
- createdAt

Account

Account
- id
- customerId
- accountNumber
- accountType
- currency
- status
- openedAt
- closedAt

Balance

Balance
- accountId
- currency
- ledgerBalance
- availableBalance
- updatedAt
- version

Transaction

Transaction
- id
- idempotencyKey
- type
- status
- fromAccountId
- toAccountId
- amount
- currency
- description
- createdAt
- updatedAt

LedgerEntry

LedgerEntry
- id
- transactionId
- accountId
- direction
- amount
- currency
- balanceAfter
- postedAt

AuditLog

AuditLog
- id
- actorType
- actorId
- action
- resourceType
- resourceId
- ipAddress
- userAgent
- requestId
- createdAt

12. 帳戶、餘額與 Ledger 設計

銀行系統最重要的觀念是：不要只存一個可以任意更新的 balance。

正確思路是：

Transaction 記錄業務事件。
LedgerEntry 記錄會計分錄。
Balance 是可被快速查詢的投影。

雙分錄概念

假設 A 轉帳 1000 元給 B：

A account: DEBIT  1000
B account: CREDIT 1000

整體系統中，借貸總額必須平衡。這個觀念可避免錢憑空消失或產生。

為什麼 Ledger 不應任意修改？

Ledger 是稽核證據。若交易錯誤，通常不會直接刪改原紀錄，而是建立 reversal 或 adjustment。

例如：

txn_001: A DEBIT 1000, B CREDIT 1000
txn_002: A CREDIT 1000, B DEBIT 1000  // reversal

這樣才能保留完整歷史。

13. 轉帳交易完整流程

行內轉帳流程

Client
  |
  | POST /transfers/quote
  v
Backend validates account and fee
  |
  | POST /transfers
  v
Risk check
  |
  v
Create transaction PENDING
  |
  v
Debit source account
  |
  v
Credit destination account
  |
  v
Write ledger entries
  |
  v
Mark transaction POSTED
  |
  v
Send notification

交易狀態機

CREATED
  -> PENDING_AUTH
  -> PENDING_RISK
  -> PROCESSING
  -> POSTED
  -> FAILED
  -> REVERSED

狀態設計很重要，因為金融交易常常不是同步完成。

跨行轉帳差異

跨行轉帳可能需要：

呼叫清算網路
等待外部銀行回覆
處理 timeout
處理 pending 狀態
對帳後補正

因此跨行轉帳 API 不應假設所有結果都能即時確定。

14. API 設計範例

查詢帳戶列表

GET /api/v1/accounts
Authorization: Bearer <access_token>

{
  "accounts": [
    {
      "accountId": "acc_001",
      "displayName": "Savings Account",
      "maskedAccountNumber": "****1234",
      "currency": "TWD",
      "availableBalance": "25000.00",
      "ledgerBalance": "26000.00",
      "status": "ACTIVE"
    }
  ]
}

建立轉帳報價

POST /api/v1/transfers/quote
Idempotency-Key: quote_20260425_001

{
  "fromAccountId": "acc_001",
  "toBankCode": "812",
  "toAccountNumber": "123456789012",
  "amount": "1000.00",
  "currency": "TWD"
}

{
  "quoteId": "quote_001",
  "amount": "1000.00",
  "fee": "15.00",
  "totalDebitAmount": "1015.00",
  "expiresAt": "2026-04-25T10:20:00Z",
  "requiresMfa": true
}

送出轉帳

POST /api/v1/transfers
Idempotency-Key: transfer_20260425_001
Authorization: Bearer <access_token>

{
  "quoteId": "quote_001",
  "mfaToken": "mfa_token_abc",
  "description": "Rent payment"
}

{
  "transactionId": "txn_001",
  "status": "PROCESSING",
  "createdAt": "2026-04-25T10:16:00Z"
}

查詢交易狀態

GET /api/v1/transactions/txn_001

{
  "transactionId": "txn_001",
  "status": "POSTED",
  "amount": "1000.00",
  "fee": "15.00",
  "currency": "TWD",
  "postedAt": "2026-04-25T10:16:10Z"
}

15. 交易一致性與冪等性

為什麼需要冪等性？

使用者按下轉帳後，可能發生：

手機網路斷線
前端 retry
使用者重複點擊
Gateway timeout
App 關掉後重開

如果後端沒有冪等控制，同一筆轉帳可能被扣兩次。

Idempotency-Key 設計

後端可以使用 (customerId, idempotencyKey) 作為唯一鍵。

第一次請求：

key = transfer_20260425_001
status = PROCESSING
response = transactionId txn_001

重複請求：

key = transfer_20260425_001
return same transactionId txn_001

資料庫交易

單一資料庫內的扣款、入帳、Ledger 寫入應放在同一個 transaction 中。

BEGIN
  lock source account balance
  validate available balance
  insert transaction
  insert debit ledger entry
  insert credit ledger entry
  update balances
COMMIT

如果涉及外部系統，不能簡單使用單一資料庫 transaction 解決，需要 saga、outbox 或補償交易。

Outbox Pattern

當交易成功後要送通知，不能在 DB commit 前直接呼叫外部通知服務。

建議：

在同一個 DB transaction 中寫入 outbox_events。
背景 worker 讀取 outbox。
發送 notification。
成功後標記 event processed。

這樣可避免「交易成功但通知事件遺失」。

Part D：安全、風控與維運

16. 銀行系統安全設計

認證 Authentication

密碼使用強雜湊，例如 Argon2id 或 bcrypt。
支援 MFA。
高風險操作重新驗證。
監控登入失敗與 credential stuffing。

授權 Authorization

使用者只能查詢自己的帳戶。
企業帳戶需支援角色與簽核流程。
內部人員使用 RBAC 或 ABAC。
高權限操作需要審批與完整 audit。

資料保護

傳輸使用 TLS。
敏感資料靜態加密。
Token、API key、金鑰放在 secret manager。
日誌遮罩帳號、卡號、身分證號。
測試環境不得使用未脫敏的正式資料。

API 防護

Rate limiting
WAF
Request signing for partner APIs
Replay protection
IP allowlist for internal APIs
mTLS for service-to-service

17. 風控與反詐騙

風控不是單一規則，而是一組信號。

常見風險信號：

新裝置登入
異常 IP 或國家
短時間多筆交易
首次轉帳給陌生收款人
大額轉帳
使用者行為異常
收款帳戶被多人檢舉

風控決策結果

ALLOW       允許交易
CHALLENGE   要求額外驗證
REVIEW      送人工審核
BLOCK       阻擋交易

風控整合點

登入後
新增約定帳戶時
建立轉帳 quote 時
真正送出轉帳時
交易完成後做事後偵測

18. 稽核、監控與可觀測性

Audit Log

所有高風險行為都應記錄：

誰做的
對哪個資源做的
做了什麼
從哪個 IP 與裝置
requestId 是什麼
結果成功或失敗
發生時間

Audit log 應避免被一般應用程式任意修改。

Observability

銀行後端至少需要：

Structured logging
Metrics
Distributed tracing
Error tracking
Audit trail
Business metrics

重要指標：

登入成功率
MFA 失敗率
轉帳成功率
pending 交易數
核心主機延遲
錯誤率
對帳差異數

19. 測試策略

單元測試

測：

金額計算
限額規則
狀態機轉移
權限判斷
Ledger 平衡

整合測試

測：

API schema
DB transaction
idempotency key
外部 adapter mock
outbox worker

端到端測試

測：

登入到查詢帳戶
轉帳 quote 到送出
MFA challenge
pending transaction 查詢
錯誤與 retry 流程

安全測試

測：

Broken access control
XSS
CSRF
SQL injection
Replay attack
Rate limit
Sensitive data leakage

20. 常見錯誤與面試重點

常見錯誤

用浮點數處理金額。
前端顯示成功就當成交易成功。
沒有 idempotency key。
直接覆寫 balance 而沒有 ledger。
不保留 reversal 紀錄。
把敏感資料寫到 log。
忽略 pending 狀態。
交易流程沒有 audit trail。
外部系統 timeout 就直接當失敗，卻沒有查詢最終狀態。

面試重點

如果面試被問「設計網銀轉帳系統」，回答可以依序說：

前端流程：輸入、確認、MFA、結果查詢。
後端 API：quote、submit、status。
資料模型：account、transaction、ledger、balance。
一致性：DB transaction、row lock、idempotency。
安全：auth、MFA、RBAC、audit、logging mask。
風控：rule engine、challenge、review。
外部整合：core banking adapter、timeout、reconciliation。
維運：metrics、tracing、alert、對帳。

總結

銀行系統的核心是「可信的金錢狀態管理」。

前端要讓使用者安全、清楚地完成操作；後端要負責認證、授權、風控、交易狀態、Ledger 與核心系統整合。真正困難的地方不在 CRUD，而在安全、一致性、冪等、稽核與例外流程。

只要掌握以下五個關鍵，就能理解大多數銀行全端系統設計：

金額用精確型別，不用浮點數。
餘額要能由 Ledger 追溯。
轉帳 API 必須冪等。
外部系統失敗不等於交易一定失敗。
所有高風險操作都要驗證、風控與稽核。

目錄