Trong việc phát triển hệ thống Core Banking (CBS), Tài liệu Yêu cầu Sản phẩm (PRD) có sự khác biệt rất lớn so với PRD của các ứng dụng SaaS hoặc di động thông thường. Trong khi một PRD SaaS tập trung chủ yếu vào giao diện người dùng (UI), các chỉ số tăng trưởng người dùng và trải nghiệm khách hàng, thì một PRD Core Banking phải ưu tiên hàng đầu cho tính toàn vẹn tài chính, tính nhất quán của giao dịch (transactional consistency), khả năng kiểm toán (auditability) và tuân thủ quy định (regulatory compliance).

Một tài liệu yêu cầu Core Banking thiết kế kém không chỉ dẫn đến những đánh giá tiêu cực từ người dùng; nó có thể gây ra các án phạt pháp lý, sổ cái mất cân bằng (unbalanced ledgers) và sai lệch tài chính lên tới hàng triệu đô la.

Hướng dẫn này phác thảo một cấu trúc toàn diện, chuẩn công nghiệp cho một PRD Core Banking, tập trung cụ thể vào các mô-đun cốt lõi như Hồ sơ Thông tin Khách hàng (CIF - Customer Information File), Tài khoản Thanh toán và Tiết kiệm (CASA - Current and Savings Accounts), và Sổ Cái Tổng Hợp (GL - General Ledger).

1. Tại sao PRD Core Banking lại Khác biệt

Một Hệ thống Core Banking hoạt động như nguồn chân lý duy nhất (ultimate source of truth) của một tổ chức tài chính. Khi cấu trúc các yêu cầu cho hệ thống này, các Product Manager (PM) và Business Analyst (BA) phải thiết kế với tư duy kỹ nghệ hệ thống (systems-engineering mindset).

SaaS PRDCore Banking PRD
Trọng tâm: Tăng trưởng người dùng, tương tác, UI/UX và quy trình onboarding nhanh chóng.Trọng tâm: Tính toàn vẹn dữ liệu, tính nguyên tử của giao dịch (transaction atomicity), sự cân bằng sổ cái và kiểm toán.
Thiết kế: Optimistic UI, nhất quán cuối cùng (eventual consistency), hợp đồng API đơn giản.Thiết kế: Nhất quán mạnh (strong consistency), thuộc tính ACID, kế toán kép (double-entry bookkeeping), các máy trạng thái (state machines) nghiêm ngặt.
Lỗi xảy ra: Gây khó chịu cho người dùng, các lỗi nhỏ có thể được hotfix nhanh chóng.Lỗi xảy ra: Thảm họa (GL mất cân bằng, double-spend/tiêu kép, vi phạm tuân thủ pháp lý).

2. Cấu trúc PRD Core Banking

Một PRD Core Banking mạnh mẽ nên được tổ chức thành các phần logic sau:

Phần A: Xác định Phạm vi & Domain (Domain & Scope Definition)

Mỗi mô-đun cốt lõi (CIF, CASA, GL, Khoản vay, Thanh toán) phải có ranh giới vận hành nghiêm ngặt. Bạn phải nêu rõ:

  • Mô-đun trong phạm vi (In-Scope): Ví dụ: “PRD này xác định việc tạo tài khoản thanh toán, phí duy trì tài khoản và các công thức tính lãi.”
  • Mô-đun ngoài phạm vi (Out-of-Scope): Ví dụ: “Phát hành thẻ, cổng thanh toán và thanh quyết toán ngoại tệ (FX) sẽ do các microservices bên ngoài xử lý và nằm ngoài phạm vi tài liệu này.”

Phần B: Hồ sơ Thông tin Khách hàng (CIF) & KYC

CIF là cơ sở dữ liệu gốc tập trung vào chủ thể (party-centric), chứa toàn bộ thông tin khách hàng. Trong phần này, hãy định nghĩa:

  • Mô hình Party-Centric: Cách dữ liệu hồ sơ tĩnh của khách hàng (tên, mã số thuế, thông tin liên hệ) ánh xạ tới nhiều tài khoản (CASA, khoản vay).
  • Các trạng thái vòng đời KYC/AML: Prospect (Tiềm năng) $\rightarrow$ Pending (Chờ duyệt) $\rightarrow$ Approved (Đã duyệt) $\rightarrow$ Expired (Hết hạn) $\rightarrow$ Restricted (Bị hạn chế).
  • Logic chống trùng lặp (Deduplication Logic): Quy tắc nghiêm ngặt để ngăn chặn việc tạo trùng lặp CIF (ví dụ: sử dụng quy tắc xác thực mã số thuế hoặc số CCCD/hộ chiếu).

Phần C: Quản lý Tài khoản (CASA)

Tài khoản Thanh toán (Current Accounts) và Tài khoản Tiết kiệm (Savings Accounts) đại diện cho động cơ quản lý nợ phải trả (liability engine) của ngân hàng. Phần này phải chi tiết hóa:

  • Máy trạng thái Tài khoản (Account State Machine):
    • Active (Hoạt động), Dormant (Ngủ đông), Frozen (Bị đóng băng), Restricted (Bị hạn chế), Closed (Đã đóng).
    • Định nghĩa chính xác sự kiện hệ thống hoặc kiểm soát thủ công nào sẽ chuyển đổi tài khoản giữa các trạng thái này.
  • Quy tắc của Công cụ Tính Lãi (Interest Engine Rules):
    • Quy tắc tính số dư hàng ngày (ví dụ: các quy ước đếm ngày Day Count Convention như Act/365 hoặc Act/360).
    • Trích trước lãi (Accrual) vs. Hạch toán lãi (Posting): Tích lũy lãi hàng ngày (accrual) nhưng chỉ hạch toán/chi trả lãi vào tài khoản theo tháng hoặc quý (posting).
  • Logic Thấu chi (OD - Overdraft):
    • Định nghĩa hạn mức thấu chi.
    • Bắt buộc xác thực giao dịch dựa trên Số dư Khả dụng (Available Balance = Ledger Balance - Hold/Block amounts) thay vì Số dư Sổ cái (Ledger Balance) để ngăn chặn mẫu lỗi Authorize Positive, Settle Negative (APSN).

Phần D: Xử lý Giao dịch & Kế toán Kép (Double-Entry Accounting)

Các bản cập nhật sổ cái Core Banking phải tuân thủ nghiêm ngặt các nguyên tắc kế toán.

  • Bắt buộc Kế toán Kép: Mỗi giao dịch tài chính phải tạo ra ít nhất hai bút toán (legs): một bên Nợ (Debit) và một bên Có (Credit). PRD phải validate: $$\sum \text{Debits} = \sum \text{Credits}$$
  • Tính Bất biến của Sổ Cái (Ledger Immutability): Các bản ghi lịch sử trong cơ sở dữ liệu không bao giờ được phép sửa đổi (update) hoặc xóa (delete). Nếu một giao dịch bị sai, PRD phải chỉ định một giao dịch bù trừ (Reversal - Giao dịch Đảo dòng) để điều chỉnh số dư.
  • Kiểm soát Trùng lặp (Idempotency Control): Yêu cầu client cung cấp một Idempotency-Key duy nhất để ngăn chặn việc hạch toán trùng lặp do cơ chế retry của mạng.

Phần E: Quy trình Phê duyệt Maker-Checker (Nguyên tắc 4 Mắt)

Để ngăn chặn gian lận nội bộ và sai sót vận hành, các cấu hình nhạy cảm và các giao dịch giá trị cao phải được định tuyến qua luồng Maker-Checker.

  • Phê duyệt tập trung dạng hàng đợi (Queue-Based Approval): Maker (Người tạo) tạo yêu cầu $\rightarrow$ Payload được ghi vào hàng đợi chờ duyệt $\rightarrow$ Checker (Người duyệt) phê duyệt hoặc từ chối payload $\rightarrow$ Giao dịch được thực thi.
  • Phân tách nhiệm vụ (Segregation of Duties): Người dùng đóng vai trò Maker cho một giao dịch cụ thể phải bị hệ thống chặn lập trình không cho phép làm Checker cho chính giao dịch đó.

Phần F: Yêu cầu Phi chức năng (NFRs)

Các NFR trong Core Banking là những rào cản chức năng bắt buộc. Chúng phải đo lường được:

  • Độ sẵn sàng (Availability): Mục tiêu uptime 99.999% với Thời gian Phục hồi tối đa (RTO - Recovery Time Objective) là 5 phút.
  • Toàn vẹn Dữ liệu: Tuân thủ nghiêm ngặt thuộc tính ACID của cơ sở dữ liệu đối với mọi giao dịch sổ cái.
  • Hiệu năng: Xử lý tối thiểu 5.000 Giao dịch trên giây (TPS - Transactions Per Second) với độ trễ (latency) dưới 100ms.
  • Nhật ký Kiểm toán (Audit Trail): Ghi lại toàn bộ trạng thái dữ liệu (trước và sau khi thay đổi) đối với các can thiệp thủ công, thay đổi tham số hệ thống và cấu hình database.

3. Quy trình Batch cuối ngày (EOD) và đầu ngày (BOD)

Không giống như các ứng dụng SaaS hiện đại hoạt động hoàn toàn theo thời gian thực (real-time), các ngân hàng vẫn phụ thuộc nhiều vào xử lý batch (theo lô) để chốt sổ ngày tài chính. Một PRD Core Banking phải thể hiện rõ ràng trình tự pipeline của EOD/BOD:

graph TD
    A[Cut-off / EOTI: End of Transaction Input] --> B[Interest & Fee Accruals]
    B --> C[Interest & Fee Posting]
    C --> D[Sub-ledger to General Ledger Reconciliation]
    D --> E[Trial Balance Validation]
    E --> F[Date Rollover / System Date Change]
    F --> G[BOD Initiation: Value-Dated Transactions]

Các Lưu ý Quan trọng cho Xử lý Batch:

  1. Ngày Hệ thống vs. Ngày Thực tế (System Date vs. Physical Date): Trong môi trường giao dịch 24/7, các kênh giao dịch online phải được phép hạch toán giao dịch ngay cả trong lúc EOD đang chạy. Hệ thống lõi phải định tuyến ngay lập tức các giao dịch này vào Ngày Làm việc Hệ thống Mới (New System Business Date) trong khi batch vẫn đang xử lý ngày cũ.
  2. Khả năng Khởi động lại (Restartability): Nếu một job batch bị lỗi (ví dụ do database lock), hệ thống phải hỗ trợ tiếp tục thực thi từ điểm checkpoint bị lỗi mà không làm hỏng trạng thái cơ sở dữ liệu lịch sử.

4. Tiêu chuẩn Tích hợp: ISO 8583 vs. ISO 20022

Một PRD Core Banking phải chỉ định cách sổ cái lõi chuyển đổi các gói dữ liệu thanh toán sang các định dạng thông điệp tiêu chuẩn.

  • ISO 8583 (Xử lý thẻ): Định dạng nén, mã hóa nhị phân được tối ưu hóa cho các giao dịch thẻ tín dụng/thẻ ghi nợ có lưu lượng lớn, độ trễ thấp tại các máy ATM và thiết bị POS.
  • ISO 20022 (Thanh toán hiện đại): Tiêu chuẩn thông điệp dạng XML/JSON hỗ trợ siêu dữ liệu phong phú (chẳng hạn như chi tiết chuyển tiền và các trường địa chỉ có cấu trúc) cần thiết cho chuyển tiền xuyên biên giới (SWIFT) và thanh toán thời gian thực (FedNow, SEPA).

PRD phải phác thảo Tầng chuyển đổi dữ liệu (Data Adapter layer) ánh xạ trực tiếp các trường thẻ cũ vào các mô-đun lõi nội bộ mà không làm mất mát ngữ cảnh thanh toán quan trọng.

Bảng kiểm tra Tóm tắt (Summary Checklist) cho PRD Core Banking

Khi đánh giá hoặc viết PRD cho hệ thống CBS của bạn, hãy đảm bảo đáp ứng đầy đủ các tiêu chí sau:

  • Quy tắc Sổ Cái: Số dư kế toán kép có được kiểm tra trước khi ghi nhận giao dịch không?
  • Kiểm tra Số Dư: Việc thấu chi và phong tỏa tài khoản có được xác thực dựa trên Số dư Khả dụng (Available Balance) thay vì Số dư Sổ Cái (Ledger Balance) không?
  • Tính Bất Biến: Có quy tắc nghiêm ngặt ngăn chặn các lệnh SQL UPDATE hoặc DELETE trên bảng lịch sử giao dịch không?
  • Khôi phục Batch: Luồng EOD batch có hỗ trợ rollback giao dịch và tiếp tục chạy từ các checkpoint không?
  • Maker-Checker Queue: Việc kiểm soát chéo (Maker-Checker) có được triển khai dưới dạng hàng đợi tập trung thay vì hardcode các cờ (flags) trong bảng không?
  • Idempotency: Tất cả các API tài chính có được bảo vệ bằng một khóa idempotency bắt buộc từ phía client không?