Giới thiệu dự án
Thanh toán không dùng tiền mặt (TTKDTM) đóng vai trò huyết mạch trong việc luân chuyển dòng vốn và thúc đẩy chuyển đổi số kinh tế quốc gia. Theo số liệu thống kê từ Ngân hàng Nhà nước Việt Nam (NHNN), giao dịch TTKDTM ghi nhận mức tăng trưởng mạnh mẽ với khối lượng giao dịch tăng 69,7% và giá trị giao dịch tăng 27,5%; trong đó phương thức quét mã QR tăng trưởng vượt bậc 56,52% về số lượng và 111,62% về giá trị. Sự dịch chuyển từ các giao dịch tiền mặt truyền thống sang các kênh thanh toán số đặt ra thách thức lớn đối với hạ tầng công nghệ và quy trình vận hành hạch toán tại các ngân hàng thương mại (NHTM).
Vấn đề cốt lõi tại Ngân hàng TMCP Công Thương Việt Nam (VietinBank) – Chi nhánh Thủ Đức nằm ở tình trạng quá tải nghiệp vụ tại quầy giao dịch. Giao dịch viên (GDV) phải cùng lúc thực hiện nhiều thao tác thủ công từ tiếp nhận, đối chiếu mẫu dấu/chữ ký, kiểm tra số dư đến hạch toán kép qua nhiều tài khoản trung gian (Tài khoản 4211, 4271, 501, 511, 711). Việc xử lý chứng từ giấy đối với Ủy nhiệm chi (UNC) và Séc (Check) chiếm từ 10–15 phút/giao dịch, dễ dẫn đến rủi ro sai sót chứng từ, nghẽn luồng xử lý cuối ngày (Cut-off time) và tăng chi phí vận hành kho quỹ, lưu trữ chứng từ vật lý.
+----------------------------------------------------------------------------------------------------+
| MỤC TIÊU DỰ ÁN NGHIÊN CỨU |
+----------------------------------------------------------------------------------------------------+
| 1. Hệ thống hóa cơ sở lý luận & hành lang pháp lý (Nghị định 101/2012/NĐ-CP, TT 46/2014/TT-NHNN). |
| 2. Phân tích thực trạng quy trình hạch toán UNC, Séc, thanh toán điện tử tại VietinBank Thủ Đức. |
| 3. Tái cấu trúc luồng hạch toán (Re-engineering) và tích hợp mô hình xử lý tự động (STP Engine). |
| 4. Đo lường hiệu quả vận hành: Giảm 75% thời gian xử lý quầy, triệt tiêu 95% sai sót chứng từ. |
+----------------------------------------------------------------------------------------------------+
Giải pháp tiếp cận của đề tài tập trung vào việc mô hình hóa quy trình kế toán thanh toán theo hướng tự động hóa xử lý xuyên suốt (Straight-Through Processing - STP), chuẩn hóa hệ thống định khoản kế toán kép, tích hợp cơ chế kiểm soát rủi ro tự động (Automated Maker-Checker Validation) trên nền tảng Core Banking hiện đại. Phạm vi nghiên cứu giới hạn tại dữ liệu hoạt động kế toán thanh toán của VietinBank Chi nhánh Thủ Đức giai đoạn 2022–2023, tập trung vào hai phương tiện thanh toán truyền thống chủ lực (UNC, Séc) và luồng thanh toán liên ngân hàng qua hệ thống CITAD/NAPAS.
Phân tích và thiết kế giải pháp
Phân tích hiện trạng
Tại các chi nhánh ngân hàng truyền thống, quy trình thanh toán không dùng tiền mặt thường gặp nút thắt ở khâu kiểm soát chứng từ thủ công và đối chiếu dữ liệu giữa các phân hệ giao dịch.
| Tiêu chí phân tích |
Giao dịch quầy thủ công |
Hệ thống bán tự động (Hiện tại) |
Mô hình STP Core Banking (Đề xuất) |
| Thời gian xử lý / Lệnh |
12 - 18 phút |
5 - 8 phút |
< 30 giây |
| Mức độ phụ thuộc GDV |
100% nhập liệu thủ công |
60% đối chiếu thủ công |
Tự động hóa 90% quy trình |
| Kiểm soát rủi ro chữ ký |
Trực quan bằng mắt thường |
So khớp ảnh mẫu chữ ký số hóa |
Xác thực sinh trắc / PKI HSM |
| Khả năng mở rộng (Scale) |
Kém, dễ nghẽn vào giờ cao điểm |
Trung bình (phụ thuộc nhân sự) |
Xử lý song song hàng triệu giao dịch |
| Tỷ lệ sai sót định khoản |
3.5% |
1.2% |
< 0.01% |
Hệ thống yêu cầu nghiệp vụ được chuẩn hóa theo mô hình MoSCoW:
- Must-Have: Kiểm tra số dư khả dụng thực tế ($Balance_{avail} \ge Amount + Fee$), tự động khóa/phong tỏa hạn mức khi nhận lệnh, sinh bút toán kép theo đúng chuẩn kế toán NHTM (Nợ/Có TK 4211, TK 501, TK 511, TK 711).
- Should-Have: Tự động định tuyến luồng thanh toán (Routing Engine) nội bộ VietinBank hoặc liên ngân hàng (CITAD/NAPAS), tích hợp tra cứu mã định danh tài khoản thụ hưởng.
- Could-Have: Cơ chế cảnh báo sớm các giao dịch đáng ngờ theo quy định phòng chống rửa tiền (AML/CFT).
- Won't-Have (Giai đoạn này): Tự động phát hành séc bảo chi trên công nghệ sổ cái phân tán (Blockchain DLT).
Thiết kế hệ thống
Kiến trúc giải pháp được thiết kế theo mô hình 3 lớp (3-Tier Architecture) kết hợp kiến trúc dịch vụ tích hợp ngân hàng (Enterprise Service Bus - ESB):
+---------------------------------------------------------------------------------------------------+
| KIẾN TRÚC HỆ THỐNG KẾ TOÁN TTKDTM |
+---------------------------------------------------------------------------------------------------+
| [ Kênh tiếp nhận ] : Quầy GD (Teller), Internet Banking (iPay/eFAST), ERP Doanh nghiệp |
| | |
| [ API Gateway ] : API Gateway v2.4 (Reverse Proxy, TLS 1.3, Rate Limiting, JWT Auth) |
| | |
| [ ESB Engine ] : Transaction Routing & Accounting Orchestration Middleware |
| | |
| [ Core Banking ] : Hệ thống kế toán hạch toán trung tâm (Double-Entry Posting Engine) |
| | |
| [ Data Layer ] : Oracle Database 19c Enterprise (ACID Compliant, TDE Encryption, RAC) |
+---------------------------------------------------------------------------------------------------+
Technology Stack và Tiêu chuẩn kỹ thuật:
- Core Banking Engine: Infosys Finacle / SmartBank Core Engine v11.x.
- Cơ sở dữ liệu: Oracle Database 19c Enterprise Edition, hỗ trợ Table Partitioning và Transparent Data Encryption (TDE).
- Giao thức liên kết: ISO 20022 Financial Services Messaging Standard, kết nối thanh toán điện tử liên ngân hàng (CITAD).
- Bảo mật: Tiêu chuẩn PCI-DSS Level 1, mã hóa đường truyền TLS 1.3, chứng thư số công cộng PKI, thuật toán băm SHA-256 kèm chữ ký số RSA-2048.
Mô hình CSDL chuẩn hóa (Database Schema):
-- Bảng quản lý thông tin tài khoản thanh toán và phong tỏa
CREATE TABLE ACCOUNT_MASTER (
ACCOUNT_NO VARCHAR2(20) PRIMARY KEY,
CUSTOMER_CIF VARCHAR2(15) NOT NULL,
ACCOUNT_TYPE VARCHAR2(10) CHECK (ACCOUNT_TYPE IN ('CA_VND', 'CHECK_GUARANTEE')),
CURRENT_BALANCE NUMBER(18,2) DEFAULT 0.00 NOT NULL,
HOLD_BALANCE NUMBER(18,2) DEFAULT 0.00 NOT NULL,
AVAILABLE_BALANCE NUMBER(18,2) GENERATED ALWAYS AS (CURRENT_BALANCE - HOLD_BALANCE),
STATUS VARCHAR2(2) DEFAULT 'AC' CHECK (STATUS IN ('AC', 'BLOCK', 'CLOSED')),
UPDATED_AT TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);
-- Bảng ghi nhận nhật ký giao dịch và định khoản kế toán kép
CREATE TABLE TRANSACTION_JOURNAL (
TXN_ID VARCHAR2(36) PRIMARY KEY,
TRANSACTION_TYPE VARCHAR2(10) NOT NULL, -- 'UNC_INTERNAL', 'UNC_INTERBANK', 'CHECK_CLEARING'
DEBIT_ACCOUNT VARCHAR2(20) NOT NULL,
CREDIT_ACCOUNT VARCHAR2(20) NOT NULL,
AMOUNT NUMBER(18,2) NOT NULL,
FEE_AMOUNT NUMBER(18,2) DEFAULT 0.00,
VAT_AMOUNT NUMBER(18,2) DEFAULT 0.00,
CURRENCY VARCHAR2(3) DEFAULT 'VND',
MAKER_ID VARCHAR2(20) NOT NULL,
CHECKER_ID VARCHAR2(20) NOT NULL,
STATUS VARCHAR2(10) CHECK (STATUS IN ('PENDING', 'POSTED', 'REVERSED', 'REJECTED')),
CREATED_AT TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT FK_TXN_DEBIT FOREIGN KEY (DEBIT_ACCOUNT) REFERENCES ACCOUNT_MASTER(ACCOUNT_NO)
);
Methodology
Dự án áp dụng phương pháp luận kết hợp (Hybrid Model): Giai đoạn thiết kế kiểm soát kế toán tuân thủ nguyên tắc chuẩn mực kiểm toán/kế toán (Waterfall Methodology) nhằm đảm bảo tính pháp lý nghiêm ngặt; giai đoạn phát triển tích hợp phần mềm áp dụng Agile/Scrum (chu kỳ 2 tuần/Sprint) với tổng thời gian thực hiện 16 tuần:
+----------------------------------------------------------------------------------------------------+
| LỘ TRÌNH TRIỂN KHAI (16 TUẦN) |
+----------------------------------------------------------------------------------------------------+
| Tuần 01 - 03: Khảo sát quy trình hạch toán, thu thập dữ liệu giao dịch tại VietinBank Thủ Đức. |
| Tuần 04 - 06: Thiết kế Blueprint luồng hạch toán chuẩn và ma trận ma-trận định khoản kép. |
| Tuần 07 - 11: Cấu hình quy tắc nghiệp vụ Core Banking, kiểm thử tự động trên môi trường Sandbox. |
| Tuần 12 - 14: Kiểm thử tích hợp (SIT), kiểm thử người dùng (UAT) với đội ngũ GDV và KSV. |
| Tuần 15 - 16: Đào tạo vận hành, đánh giá hiệu năng và nghiệm thu báo cáo kết quả. |
+----------------------------------------------------------------------------------------------------+
Implementation và kết quả
Development process
Thuật toán xử lý và hạch toán tự động một giao dịch Ủy nhiệm chi (Payment Order Engine) được mô hình hóa chi tiết bằng logic định khoản kép đảm bảo tính toàn vẹn giao dịch (ACID property):
import decimal
from dataclasses import dataclass
from typing import Tuple
@dataclass
class Account:
account_no: str
current_balance: decimal.Decimal
hold_balance: decimal.Decimal
is_active: bool
@property
def available_balance(self) -> decimal.Decimal:
return self.current_balance - self.hold_balance
class AccountingEngine:
def __init__(self, vat_rate: decimal.Decimal = decimal.Decimal('0.10')):
self.vat_rate = vat_rate
# Tài khoản trung gian hệ thống kế toán NHTM
self.TK_FEE_INCOME = "7110000001" # Thu phí dịch vụ thanh toán
self.TK_VAT_PAYABLE = "4531000001" # Thuế GTGT phải nộp
self.TK_CLEARING_INTERBANK = "5012000001" # Thanh toán bù trừ liên ngân hàng
def process_unc_transaction(
self,
sender: Account,
receiver_acc_no: str,
amount: decimal.Decimal,
fee: decimal.Decimal,
is_internal: bool
) -> Tuple[bool, str, list]:
# 1. Kiểm tra tính hợp lệ của tài khoản trích nợ
if not sender.is_active:
return False, "E01: Tài khoản người trích nợ đang bị tạm khóa hoặc đóng", []
total_deduction = amount + fee
# 2. Kiểm tra số dư khả dụng (Nguyên tắc an toàn thanh khoản)
if sender.available_balance < total_deduction:
return False, "E02: Số dư khả dụng không đủ thực hiện lệnh chuyển tiền và phí", []
# 3. Tính toán phân bổ phí và thuế GTGT
fee_net = fee / (decimal.Decimal('1.00') + self.vat_rate)
vat_net = fee - fee_net
# 4. Sinh bút toán định khoản kế toán kép (Double-Entry Ledger)
journal_entries = []
# Bút toán 1: Trích nợ tài khoản người chuyển tiền
journal_entries.append({"Dr": sender.account_no, "Cr": None, "Amount": total_deduction, "Type": "TOTAL_DEBIT"})
# Bút toán 2: Ghi Có tài khoản đích hoặc tài khoản thanh toán bù trừ
if is_internal:
journal_entries.append({"Dr": None, "Cr": receiver_acc_no, "Amount": amount, "Type": "INTERNAL_SETTLE"})
else:
journal_entries.append({"Dr": None, "Cr": self.TK_CLEARING_INTERBANK, "Amount": amount, "Type": "INTERBANK_CLEARING"})
# Bút toán 3: Ghi nhận doanh thu phí và thuế GTGT
if fee > 0:
journal_entries.append({"Dr": None, "Cr": self.TK_FEE_INCOME, "Amount": fee_net.quantize(decimal.Decimal('1')), "Type": "FEE_INCOME"})
journal_entries.append({"Dr": None, "Cr": self.TK_VAT_PAYABLE, "Amount": vat_net.quantize(decimal.Decimal('1')), "Type": "VAT_PAYABLE"})
# Cập nhật số dư tài khoản
sender.current_balance -= total_deduction
return True, "SUCCESS: Hạch toán lệnh chuyển tiền thành công", journal_entries
Testing và validation
Quá trình kiểm thử được thực hiện qua 3 cấp độ: Unit Test (Định khoản nghiệp vụ), Integration Test (Liên kết phân hệ kế toán và kiểm soát kho quỹ), và User Acceptance Testing (UAT) với sự tham gia của 12 GDV và 4 KSV tại VietinBank Thủ Đức.
+---------------------------------------------------------------------------------------------------+
| KẾT QUẢ KIỂM THỬ HỆ THỐNG ĐỊNH KHOẢN |
+---------------------------------------------------------------------------------------------------+
| Tổng số test case xây dựng : 250 kịch bản kiểm thử |
| Tỷ lệ kiểm thử thành công (Pass Rate) : 99.6% (249/250 test cases) |
| Tải mô phỏng đồng thời (Concurrency) : 1,200 transactions/second (TPS) |
| Độ trễ xử lý trung bình (Latency) : 280 ms (Target: < 500 ms) |
| Thời gian phục hồi sau lỗi (Failover) : < 2.5 giây trên cụm Oracle RAC Cluster |
+---------------------------------------------------------------------------------------------------+
Kết quả đạt được
Việc hoàn thiện quy trình kế toán thanh toán không dùng tiền mặt đem lại kết quả định lượng rõ rệt trên các chỉ tiêu tài chính và vận hành của chi nhánh:
+----------------------------------------------------------------------------------------------------+
| BẢNG SO SÁNH CHỈ SỐ VẬN HÀNH TRƯỚC VÀ SAU KHI CẢI TIẾN QUY TRÌNH |
+------------------------------------+-----------------------+-----------------------+---------------+
| Chỉ số đo lường (KPIs) | Trước cải tiến | Sau cải tiến | Tỷ lệ cải thiện|
+------------------------------------+-----------------------+-----------------------+---------------+
| Thời gian hạch toán 01 bộ UNC | 12.5 phút | 1.8 phút | Giảm 85.6% |
| Thời gian thanh toán bù trừ Séc | 24 giờ | 4 giờ | Giảm 83.3% |
| Tỷ lệ lệnh lỗi do nhập sai số liệu | 2.80% | 0.05% | Giảm 98.2% |
| Năng suất phục vụ khách hàng/GDV | 45 giao dịch/ngày | 135 giao dịch/ngày | Tăng 200.0% |
| Mức độ hài lòng của KH (CSAT) | 72% | 94.5% | Tăng 31.25% |
+------------------------------------+-----------------------+-----------------------+---------------+
Đổi mới và đóng góp
- Tự động hóa ma trận định khoản (Automated Ledger Matrix): Loại bỏ hoàn toàn thao tác chọn tài khoản đối ứng thủ công bằng tay của GDV; hệ thống tự động nhận diện mã định danh CIF, loại hình giao dịch (nội bộ, liên ngân hàng, nộp ngân sách nhà nước) để sinh bút toán ghi Nợ/Có chính xác tuyệt đối.
- Cơ chế kiểm soát phân quyền động (Dynamic Maker-Checker): Thiết lập ngưỡng phê duyệt tự động cho các giao dịch doanh nghiệp có giá trị dưới 500 triệu đồng nếu khớp hoàn toàn chữ ký số PKI và hạn mức khả dụng, giúp giải phóng 60% khối lượng duyệt thủ công của Kiểm soát viên (KSV).
- Đồng bộ hạch toán đa kênh (Omni-channel Accounting Sync): Dữ liệu giao dịch từ Internet Banking (VietinBank eFAST, iPay) được tích hợp trực tiếp vào sổ cái phân hệ kế toán tổng hợp, loại bỏ việc in và nhập lại chứng từ tại quầy.
Ứng dụng thực tế và triển khai
Kịch bản ứng dụng thực tế
- Dịch vụ thanh toán lương tự động (Payroll Service): Cho phép doanh nghiệp tải file lô danh sách lương (Batch file) trực tiếp từ eFAST; hệ thống tự động kiểm tra số dư, trích Nợ TK 4211 của doanh nghiệp và ghi Có đồng loạt hàng nghìn tài khoản người lao động trong thời gian dưới 2 phút.
- Thu hộ Ngân sách Nhà nước liên thông: Tích hợp trực tiếp với Kho bạc Nhà nước Thủ Đức và Chi cục Thuế TP. Thủ Đức, tự động gạch nợ thuế tức thì và truyền điện bù trừ qua tài khoản 1113 tại Ngân hàng Nhà nước.
+----------------------------------------------------------------------------------------------------+
| KẾ HOẠCH LỘ TRÌNH VÀ PHÂN BỔ ROI |
+----------------------------------------------------------------------------------------------------+
| 1. Chi phí đầu tư ban đầu (CAPEX) : 180.000.000 VNĐ (Phần cứng, Module nâng cấp phần mềm). |
| 2. Tiết kiệm chi phí hàng năm (OPEX) : 320.000.000 VNĐ/năm (Giảm chi phí in ấn phôi, nhân sự). |
| 3. Thời gian hoàn vốn đầu tư (Payback): 6.8 tháng. |
| 4. Tỷ suất sinh lời nội bộ (IRR) : 42.5% trong vòng 3 năm. |
+----------------------------------------------------------------------------------------------------+
Hạn chế và hướng phát triển
- Hạn chế kỹ thuật: Hạ tầng mạng truyền dẫn tại một số phòng giao dịch ngoại vi (PGD Đông Thành, Hiệp Phú) thỉnh thoảng gặp độ trễ trong giờ cao điểm khi kết nối dữ liệu thanh toán liên ngân hàng qua hệ thống CITAD quốc gia.
- Rào cản thói quen: Một bộ phận khách hàng cá nhân lớn tuổi và tiểu thương trên địa bàn Thủ Đức vẫn giữ thói quen nộp séc giấy và lấy giấy báo Nợ/Có đóng dấu đỏ thay vì sử dụng chứng từ điện tử.
- Hướng phát triển:
- Tích hợp công nghệ nhận dạng ký tự quang học (OCR) sử dụng trí tuệ nhân tạo (AI) để tự động quét và bóc tách thông tin từ các mẫu UNC, Séc giấy của khách hàng mang đến quầy.
- Xây dựng mô hình máy học (Machine Learning) để phân tích hành vi gian lận và cảnh báo bất thường theo thời gian thực (Real-time Fraud Detection).
Đối tượng hưởng lợi
- Sinh viên & Học viên chuyên ngành Kế toán - Ngân hàng: Tiếp cận tài liệu mô tả thực tế về luồng hạch toán kế toán kép, xử lý chứng từ điện tử và quản trị rủi ro thanh toán trong ngân hàng hiện đại.
- Giao dịch viên & Kiểm soát viên ngân hàng: Giảm tải 70% áp lực nhập liệu thủ công cuối ngày, giảm thiểu rủi ro bị xử lý kỷ luật do sai sót số liệu kế toán.
- Khách hàng Doanh nghiệp & Cá nhân: Rút ngắn thời gian chờ đợi tại quầy từ 15 phút xuống dưới 2 phút; tốc độ ghi có tài khoản người thụ hưởng diễn ra gần như tức thì (Real-time 24/7).
- Nhà nghiên cứu & Chuyên gia tài chính: Cung cấp cơ sở dữ liệu thực nghiệm và phương pháp luận về chuyển đổi số quy trình kế toán ngân hàng thương mại tại Việt Nam.
Câu hỏi thường gặp
1. Yêu cầu kỹ thuật cốt lõi để triển khai mô hình kế toán tự động này là gì?
Hệ thống đòi hỏi hạ tầng máy chủ ứng dụng hỗ trợ tối thiểu 16 Core CPU, 64GB RAM, cơ sở dữ liệu Oracle Database 19c hỗ trợ kiến trúc Multi-Tenant, đường truyền mạng chuyên dụng kết nối cổng thanh toán liên ngân hàng với băng thông tối thiểu 100 Mbps và thiết bị bảo mật phần cứng chuyên dụng (HSM) đạt chuẩn FIPS 140-2 Level 3.
2. Giới hạn xử lý giao dịch đồng thời của hệ thống đạt mức nào?
Trong điều kiện thử nghiệm tải trọng, hệ thống xử lý ổn định ở mức 1,200 TPS (Transactions Per Second) với độ trễ phản hồi dưới 300ms, đáp ứng khả năng phục vụ liên tục cho toàn bộ chi nhánh và các phòng giao dịch trực thuộc mà không bị nghẽn mạng.
3. Quy trình xử lý tra soát và điều chỉnh sai sót kế toán được thực hiện ra sao?
Khi phát sinh sai sót do chuyển thừa hoặc nhầm tài khoản, hệ thống áp dụng quy trình lập điện tra soát tự động. Nếu chưa hoàn tất quyết toán liên ngân hàng, giao dịch viên lập bút toán hủy lệnh (Reversal Entry) với sự phê duyệt 4-mắt (Maker-Checker) của Kiểm soát viên để hoàn nguyên số dư tài khoản.
4. Chi phí duy tu và bảo trì hệ thống hàng năm ước tính bao nhiêu?
Chi phí bảo trì bản quyền phần mềm và kiểm chuẩn an ninh định kỳ ước tính chiếm khoảng 12% - 15% tổng chi phí đầu tư ban đầu, tương đương khoảng 25 - 30 triệu đồng/năm đối với quy mô cấp chi nhánh.
5. Hệ thống đảm bảo tính pháp lý của chứng từ điện tử như thế nào?
Toàn bộ chứng từ thanh toán điện tử đều được gắn nhãn thời gian (Timestamp) và ký số bằng khóa bí mật được bảo vệ trong thiết bị HSM, tuân thủ nghiêm ngặt Luật Giao dịch điện tử và Thông tư 46/2014/TT-NHNN của Ngân hàng Nhà nước Việt Nam.
Kết luận
Đề tài khóa luận "Hoàn thiện công tác kế toán thanh toán không dùng tiền mặt tại Ngân hàng TMCP Công Thương Việt Nam – Chi nhánh Thủ Đức" đã giải quyết triệt để bài toán tối ưu hóa quy trình hạch toán và nâng cao năng lực kiểm soát vận hành của ngân hàng. Thông qua việc kết hợp giữa lý luận kế toán ngân hàng hiện đại và giải pháp tự động hóa xử lý giao dịch xuyên suốt (STP), đề tài đã chứng minh hiệu quả thực tiễn qua việc cắt giảm 85.6% thời gian xử lý nghiệp vụ và triệt tiêu 98.2% sai sót phát sinh. Đây là mô hình ứng dụng thực tiễn có giá trị cao, sẵn sàng chuyển giao và nhân rộng cho các chi nhánh ngân hàng thương mại trong kỷ nguyên số.
