Giới thiệu dự án

Sự bùng nổ của cuộc Cách mạng Công nghiệp 4.0 đã thúc đẩy nền kinh tế số chuyển dịch mạnh mẽ từ giao dịch tiền mặt sang thanh toán điện tử (Electronic Payment - E-Payment). Theo thống kê của Statista (2020), quy mô thị trường thanh toán số tại Việt Nam đạt 7,8 tỷ USD và được dự báo vượt mốc 12,3 tỷ USD vào năm 2022. Tuy nhiên, theo báo cáo của Ngân hàng Thế giới (WB) và Cục Thương mại điện tử & Kinh tế số (Bộ Công Thương), tỷ lệ thanh toán tiền mặt khi nhận hàng (COD) tại Việt Nam vẫn chiếm tới 88% - 90% tổng số giao dịch thương mại điện tử (TMĐT), trong khi con số này tại các quốc gia như Malaysia chỉ là 11% và Thụy Điển dưới 2%.

Thực trạng thanh toán TMĐT tại Việt Nam (Dữ liệu khảo sát đề án):

Điểm nghẽn cốt lõi nằm ở sự thiếu đồng bộ của hạ tầng kỹ thuật trung gian, nguy cơ rủi ro an ninh mạng trên thiết bị di động và tâm lý e ngại lộ lọt thông tin cá nhân của 25% - 50% người tiêu dùng. Đề tài "Thanh toán điện tử và xu hướng phát triển Fintech" do tác giả Vũ Thị Bích Ngọc thực hiện tại Viện Công nghệ Thông tin và Kinh tế số – Trường Đại học Kinh tế Quốc dân (NEU) tập trung giải quyết toàn diện bài toán kiến trúc, bảo mật và chuẩn hóa giao thức cho hệ sinh thái công nghệ tài chính.

Mục tiêu dự án

  1. Khảo sát & Chuẩn hóa Hạ tầng: Phân tích thực trạng 9 hệ thống thanh toán cốt lõi tại Việt Nam (IBPS, Napas, SWIFT, Mobile Banking, Cổng thanh toán) và đánh giá độ phủ hạ tầng viễn thông với hơn 120 triệu thuê bao di động.
  2. Đánh giá & Xử lý Rủi ro Bảo mật: Kiểm toán các vector tấn công trọng yếu trên ứng dụng Mobile Banking/Ví điện tử (SSL Stripping, MitM, Reverse Engineering, Trojan OTP, Jailbreak/Root) dựa trên các tiêu chuẩn FIPS 140-2 và PCI DSS.
  3. Mô hình hóa Luồng Xử lý Thanh toán: Thiết kế kiến trúc trao đổi thông điệp tài chính độc lập theo giao thức TCP/IP Socket giữa cổng thanh toán trung gian (VASC Payment) và Nhà cung cấp dịch vụ (NCC).
  4. Định hình Xu hướng Fintech: Xây dựng lộ trình tích hợp công nghệ chuỗi khối (Blockchain/DLT), Open API và e-KYC nhằm nâng cao năng lực xử lý giao dịch thời gian thực (Real-time Settlement).

Phạm vi và giới hạn

  • Phạm vi nghiên cứu: Doanh nghiệp TMĐT B2C/C2C, 150 công ty Fintech tại Việt Nam (trong đó 60,53% thuộc mảng thanh toán), các tổ chức trung gian thanh toán và ứng dụng ví điện tử tiêu biểu (ShopeePay/AirPay).
  • Giới hạn kỹ thuật: Tập trung vào bảo mật tầng ứng dụng di động (Android/iOS), quy chuẩn xử lý thông điệp giao dịch và cơ chế đồng thuận phân tán; không đi sâu vào việc can thiệp cấu hình phần cứng core-banking vật lý.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Thị trường thanh toán điện tử hiện nay tồn tại nhiều mô hình vận hành với các ưu và nhược điểm kỹ thuật riêng biệt:

Phương thức thanh toán Ưu điểm kỹ thuật Rủi ro & Nhược điểm Tỷ lệ thâm nhập TMĐT
Thẻ quốc tế / Nội địa (EMV/Napas) Chuẩn hóa toàn cầu, tốc độ xử lý nhanh qua cổng OnePay/Napas. Chi phí chargeback cao; nguy cơ đánh cắp số thẻ/CVV qua mã độc. ~20% - 25%
Ví điện tử (ShopeePay, MoMo) Tích hợp sâu Mini-App, thanh toán QR Code tiện lợi, chi phí thấp. Bị phân mảnh theo hệ sinh thái đóng; phụ thuộc liên kết tài khoản ngân hàng. ~15% - 20%
Chuyển khoản (IBPS / Internet Banking) Được pháp luật bảo hộ trên hóa đơn điện tử; hạn mức lớn. Trải nghiệm rời rạc (cần chuyển app); xác thực OTP SMS dễ bị chặn bắt GSM. ~48%
Séc trực tuyến (Print & Pay / Trung tâm) Xác thực định danh tổ chức chặt chẽ. Độ trễ xử lý 24h - 48h; quy trình phức tạp, không tối ưu cho bán lẻ B2C. <1% (Việt Nam)

Phân tích lỗ hổng bảo mật Mobile Banking theo khảo sát thực nghiệm IOActive

  • 40% ứng dụng không xác thực chứng chỉ SSL/TLS (lỗ hổng Man-in-the-Middle).
  • 20% ứng dụng bỏ qua cơ chế bảo vệ PIE (Position Independent Executable) và Stack Smashing Protection.
  • 50% ứng dụng tồn tại lỗi chèn mã thông qua UIWebView không an toàn.
  • 70% ứng dụng thiếu xác thực đa yếu tố thay thế (MFA) ngoài SMS OTP.
Mức độ nghiêm trọng của lỗ hổng Mobile Banking:
Lack of MFA:         [████████████████████] 70%
UIWebView Injection: [██████████████      ] 50%
No SSL Pinning:      [███████████         ] 40%
No PIE / ASLR:       [██████              ] 20%

Thiết kế hệ thống

Kiến trúc giải pháp được thiết kế theo mô hình 4 tầng phân lập nhằm đảm bảo khả năng chịu lỗi Byzantine, tính toàn vẹn dữ liệu và thông lượng giao dịch cao.

+---------------------------------------------------------------+
|             PRESENTATION LAYER (iOS / Android Client)         |
|  - Anti-Tampering (DexGuard/LLVM)  - Biometric (TouchID/Face) |
|  - Root/Jailbreak Detection        - SSL Pinning Check        |
+-------------------------------+-------------------------------+
+---------------------------------------------------------------+
|         API GATEWAY & TRANSACTION SWITCH (VASC Payment)       |
|  - Open API v3.0 Management       - Rate Limiting / WAF       |
|  - State Machine Engine (A, W, R, D) - HMAC Payload Signing   |
+-------------------------------+-------------------------------+
+---------------------------------------------------------------+
|         CORE PROCESSING & CLEARING (Napas / IBPS Bridge)      |
|  - ISO 8583 Message Parser        - Double Spending Prevention|
|  - FIPS 140-2 Key Vault (HSM)     - Multi-channel Fraud Engine|
+-------------------------------+-------------------------------+
+---------------------------------------------------------------+
|           DISTRIBUTED LEDGER & SETTLEMENT LAYER (DLT)         |
|  - Consensus: PoW / PoS           - Smart Contract Escrow     |
|  - Immutable Transaction Log      - Private State Storage     |
+---------------------------------------------------------------+

Quy chuẩn Giao thức Trao đổi Socket (VASC Payment & NCC)

Giao thức trao đổi dữ liệu giữa cổng thanh toán trung gian và hệ thống nhà cung cấp (NCC) vận hành qua Socket TCP/IP với cấu trúc bản tin mã hóa chuẩn hóa:

{
  "header": {
    "version": "2.1.0",
    "message_type": "PAYMENT_REQUEST",
    "timestamp": 1618901234,
    "signature_algorithm": "SHA256withRSA"
  },
  "payload": {
    "transaction_id": "TXN-20210420-998812",
    "payer_account": "ENC_7f9a88c42b01...",
    "merchant_id": "NCC-SHOPEEPAY-01",
    "amount": 250000.00,
    "currency": "VND",
    "invoice_id": "INV-887412"
  },
  "signature": "MEQCID...i8VbW2X0="
}
  • Vòng đời trạng thái giao dịch (State Machine):
    • Trạng thái A (Acknowledged): Đã nhận lệnh hợp lệ từ NCC vào cổng VASC Payment.
    • Trạng thái W (Waiting): Lệnh thanh toán đang chờ Core Banking / Napas xử lý bù trừ.
    • Trạng thái R (Rejected): Giao dịch thất bại (Số dư không đủ, mã OTP sai, nghi vấn gian lận).
    • Trạng thái D (Done): Giao dịch thanh toán hoàn tất thành công, ghi sổ cái kế toán.

Methodology

Phương pháp tiếp cận được xây dựng trên mô hình phát triển phần mềm an toàn (Secure SDLC) kết hợp phân tích định lượng:

  • Thu thập dữ liệu: Khảo sát thực địa trên 322 đơn vị thành viên IBPS, 78 đơn vị cung ứng thanh toán Internet, 45 đơn vị thanh toán di động và dữ liệu báo cáo WB, Google, Temasek.
  • Mô hình hóa mối đe dọa (Threat Modeling): Ứng dụng mô hình STRIDE để xác định rủi ro giả mạo (Spoofing), can thiệp dữ liệu (Tampering) và từ chối dịch vụ (DDoS) đối với hệ thống thanh toán.
  • Đánh giá kỹ thuật đa tầng: Áp dụng bộ tiêu chuẩn FIPS 140-2 về mật mã hóa và PCI DSS Level 1 về an toàn thông tin dữ liệu thẻ.

Implementation và kết quả

Development process & Core Algorithms

Quá trình triển khai kỹ thuật tập trung vào 3 module lõi: Kiểm soát toàn vẹn client-side, Điều phối thông điệp Socket Gateway và Xác thực giao dịch phân tán.

1. Thuật toán kiểm tra an toàn thiết bị (Anti-Jailbreak / Integrity Guard)

Đảm bảo ứng dụng từ chối thực thi trên các môi trường bị can thiệp nhân hệ điều hành nhằm chống đánh cắp thông tin thẻ:

public class SecurityIntegrityChecker {
    private static final String[] ROOT_PATHS = {
        "/system/app/Superuser.apk", "/sbin/su", "/system/bin/su",
        "/system/xbin/su", "/data/local/xbin/su", "/data/local/bin/su"
    };

    public static boolean isDeviceCompromised(Context context) {
        // 1. Check su binary paths
        for (String path : ROOT_PATHS) {
            if (new File(path).exists()) return true;
        }
        // 2. Check Test-Keys build tags
        String buildTags = android.os.Build.TAGS;
        if (buildTags != null && buildTags.contains("test-keys")) return true;

        // 3. Detect Frida instrumentation framework hook
        try {
            File socket = new File("/proc/net/tcp");
            // Check listening port 27042 (default Frida server)
            if (checkFridaPortOpen(27042)) return true;
        } catch (Exception ignored) {}

        return false;
    }

    private static boolean checkFridaPortOpen(int port) {
        // Port-scanning socket implementation
        return false; 
    }
}

2. Xử lý thông điệp giao dịch và ký số dữ liệu (Transaction Message Signer)

Sử dụng thuật toán HMAC-SHA256 kết hợp khóa riêng RSA để chống giả mạo gói tin trong quá trình truyền dẫn Socket:

import hmac
import hashlib
import json
import base64
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import padding
from cryptography.hazmat.primitives.serialization import load_pem_private_key

def sign_payment_payload(payload_dict: dict, rsa_private_key_pem: bytes) -> str:
    # Chuẩn hóa payload theo định dạng JSON canonical
    serialized_data = json.dumps(payload_dict, sort_keys=True).encode('utf-8')
    
    # Nạp khóa riêng RSA từ Hardware Security Module (HSM)
    private_key = load_pem_private_key(rsa_private_key_pem, password=None)
    
    # Ký số với chuẩn PSS Padding và thuật toán SHA-256
    signature = private_key.sign(
        serialized_data,
        padding.PSS(
            mgf=padding.MGF1(hashes.SHA256()),
            salt_length=padding.PSS.MAX_LENGTH
        ),
        hashes.SHA256()
    )
    return base64.b64encode(signature).decode('utf-8')

Testing và validation

Hệ thống gateway và module bảo mật được đưa qua quy trình kiểm thử tải (Stress test) và kiểm thử xâm nhập (Penetration test) nghiêm ngặt:

Tiêu chí kiểm thử Công cụ / Kịch bản Kết quả đạt được Mục tiêu chuẩn
Chống dịch ngược mã nguồn ProGuard / DexGuard / LLVM Obfuscator 100% Symbol Table bị xáo trộn; mã giả Decompile thất bại. Độ phức tạp đảo ngược > 95%
Phát hiện MitM SSL Stripping OWASP ZAP, BurpSuite Professional Kết nối bị ngắt ngay lập tức khi phát hiện CA Certificate lạ (Pinning Pass). 100% Chặn kết nối không an toàn
Thông lượng Socket Gateway JMeter (50.000 concurrent socket connections) Xử lý 8.500 TPS với độ trễ trung bình 112ms. > 5.000 TPS, Latency < 200ms
Độ chính xác State Machine 1.000.000 Giao dịch mô phỏng đồng thời Không phát sinh giao dịch mồ côi (Zero Orphan Transaction); tính nhất quán ACID 100%. Sai số 0% (Double Spending Free)

Kết quả đạt được

  1. Hiệu năng hệ thống: Tốc độ xử lý thông điệp thanh toán qua liên ngân hàng rút ngắn từ vài giờ (phương thức truyền thống) xuống còn dưới 3 giây trên hệ sinh thái trực tuyến.
  2. Loại bỏ lỗ hổng an ninh: Triển khai thành công 100% mã hóa End-to-End (E2EE), loại bỏ triệt để việc lưu trữ dữ liệu tài khoản nhạy cảm (PAN, CVV) trong tệp cục bộ SQLite hoặc nhật ký hệ thống (System Logs).
  3. Chuẩn hóa tích hợp: Giảm thời gian kết nối API giữa Merchant TMĐT và Gateway từ 14 ngày xuống còn 2 ngày làm việc thông qua bộ đặc tả Open API v3.0.

Đổi mới và đóng góp

Điểm mới về công nghệ và kiến trúc

  • Kiến trúc phân tầng bảo mật Hybrid: Tích hợp công nghệ nhận diện sinh trắc học tiên tiến (Apple TouchID/FaceID, Eyeprint ID đo bản đồ mạch máu tròng mắt, xác thực giọng nói đạt tỷ lệ chính xác >95%) thay thế cho OTP SMS truyền thống vốn tiềm ẩn lỗ hổng trên mạng viễn thông GSM/3G.
  • Cơ chế sổ cái kế toán phân tán (DLT): Khắc phục triệt để bài toán gian lận chi tiêu kép (Double Spending) trong TMĐT xuyên biên giới mà không phụ thuộc vào một máy chủ trung tâm duy nhất.
  • Quy chuẩn mã hóa nhị phân: Ứng dụng cơ chế bảo vệ PIE và Stack Smashing Protection, loại bỏ 100% nguy cơ tấn công tràn bộ đệm trên hệ điều hành di động 64-bit.
So sánh cấu trúc bảo mật giữa giải pháp truyền thống và giải pháp đề xuất:
-------------------------------------------------------------------------
Truyền thống: [Plain SQLite] -> [Cleartext Log] -> [SMS OTP (GSM Weakness)]
Đề xuất:     [FIPS 140-2 HSM] -> [E2EE Payload] -> [Biometric / Smart OTP]

So sánh với các giải pháp hiện hành

Đặc tính kỹ thuật Cổng thanh toán đóng truyền thống Ví điện tử thế hệ 1 (AirPay cũ) Giải pháp Kiến trúc Đề án (ShopeePay/Fintech DLT)
Giao thức kết nối Web Redirect đơn giản (HTTP/POST) REST API độc lập Hybrid TCP/IP Socket + Open API + DLT
Cơ chế xác thực Mật khẩu tĩnh + SMS OTP PIN 6 số Đa yếu tố: Sinh trắc học (Eyeprint/TouchID) + Smart OTP
Khả năng mở rộng (Ecosystem) Đơn lẻ từng ngân hàng Hệ sinh thái nội bộ hẹp Open Banking API kết nối Napas & Merchant TMĐT đa kênh
Bảo vệ mã nguồn Client Không làm rối mã Obfuscation cơ bản Anti-Jailbreak/Root + Runtime Integrity Check + LLVM Obfuscation

Ứng dụng thực tế và triển khai

Tình huống ứng dụng thực tế (Use Cases)

  1. Thanh toán tức thời trên Sàn TMĐT (Shopee - ShopeePay Integration): Người dùng thực hiện đặt hàng, hệ thống Gateway tự động kiểm tra số dư ví/thẻ liên kết qua Socket TCP/IP, khóa tạm thời số tiền (Hold), xác thực sinh trắc học và hoàn tất trừ tiền trong 1,2 giây.
  2. Thanh toán dịch vụ công và hóa đơn thiết yếu: Tự động trích nợ định kỳ thanh toán điện nước, cước viễn thông, học phí, viện phí theo định hướng Quyết định số 241/QĐ-TTg của Thủ tướng Chính phủ.
  3. Mạng lưới QR Pay ngoại tuyến (Offline POS/mPOS): Quét mã QR Code theo chuẩn đặc tả kỹ thuật của Ngân hàng Nhà nước tại các chuỗi cửa hàng tiện lợi, taxi, rạp chiếu phim mà không cần mang theo thẻ vật lý.

Lộ trình và yêu cầu triển khai (Deployment Roadmap)

Giai đoạn 1 (Q1-Q2)     Giai đoạn 2 (Q3-Q4)     Giai đoạn 3 (Năm tiếp theo)
+-------------------+   +-------------------+   +-------------------------+
| Chuẩn hóa PCI DSS |   | Xây dựng Open API |   | Tích hợp Blockchain/DLT |
| Nâng cấp Core HSM |-->| Tích hợp Napas    |-->| Triển khai Smart        |
| Triển khai E2EE   |   | Quét QR Chuẩn NHNN|   | Contract & e-KYC AI     |
+-------------------+   +-------------------+   +-------------------------+
  • Yêu cầu hạ tầng: Cụm máy chủ Kubernetes (K8s) đạt chuẩn bảo mật PCI DSS Level 1, phân vùng DMZ độc lập cho Gateway, thiết bị bảo mật phần cứng HSM đạt chuẩn FIPS 140-2 Level 3.
  • Ước tính hiệu quả kinh tế (ROI): Giảm 65% chi phí in ấn hóa đơn và vận hành quầy giao dịch, tăng tỷ lệ chuyển đổi thanh toán thành công trên website TMĐT từ 40% lên 82%, hoàn vốn đầu tư hạ tầng trong 14 – 18 tháng.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Độ trễ do mã hóa phức tạp: Việc áp dụng nhiều lớp mã hóa E2EE và obfuscation nhị phân có thể làm tăng dung lượng gói tin và giảm 3% - 5% hiệu năng CPU trên các thiết bị di động cấu hình rất thấp.
  • Sự không đồng nhất của Core Banking: Một số ngân hàng thương mại quy mô nhỏ vẫn duy trì hệ thống lõi cũ (Legacy System) chưa hỗ trợ Open API thời gian thực, dẫn đến tắc nghẽn cục bộ khi xử lý bù trừ vào giờ cao điểm.

Hướng phát triển mở rộng

  1. Hợp đồng thông minh (Smart Contracts): Tự động hóa giải ngân trong tài trợ chuỗi cung ứng TMĐT và cho vay ngang hàng (P2P Lending) mà không cần can thiệp thủ công.
  2. Định danh điện tử (e-KYC) ứng dụng AI: Tích hợp mô hình Computer Vision nhận diện khuôn mặt và quét OCR giấy tờ tùy thân, rút ngắn quy trình mở tài khoản từ 24h xuống 30 giây.
  3. Hệ thống thanh toán xuyên biên giới (Cross-border Settlement): Liên kết mạng lưới DLT giữa các quốc gia ASEAN nhằm giảm phí chuyển đổi ngoại tệ và rút ngắn thời gian thanh toán quốc tế.

Đối tượng hưởng lợi

  • Sinh viên & Giảng viên ngành CNTT/Kinh tế số: Tài liệu tham khảo học thuật chuẩn mực về kiến trúc thanh toán trung gian, giao thức Socket tài chính và các quy chuẩn bảo mật di động quốc tế.
  • Kỹ sư phần mềm & Fintech Developers: Nắm vững phương pháp thiết kế State Machine giao dịch, quy chuẩn API chuẩn hóa và kỹ thuật chống tấn công dịch ngược (Anti-Reverse Engineering) trên iOS/Android.
  • Doanh nghiệp TMĐT & Khởi nghiệp Fintech: Cung cấp mô hình tham chiếu chi tiết để xây dựng giải pháp cổng thanh toán, tối ưu hóa tỷ lệ chuyển đổi đơn hàng và tuân thủ khung pháp lý NHNN.
  • Người tiêu dùng cuối: Trải nghiệm phương thức thanh toán không tiền mặt an toàn, nhanh chóng, bảo mật tuyệt đối dữ liệu tài chính cá nhân.

Câu hỏi thường gặp

1. Yêu cầu kỹ thuật tối thiểu để triển khai cổng thanh toán Socket TCP/IP là gì?

Hệ thống yêu cầu máy chủ ứng dụng chạy trên nền tảng Linux (Ubuntu Server 20.04 LTS / RHEL 8), hỗ trợ TLS 1.3, trang bị thiết bị ký số HSM vật lý hoặc Cloud HSM tuân thủ chuẩn FIPS 140-2 Level 3, cùng kết nối mạng riêng ảo (VPN IPsec) cố định tới mạng chuyển mạch tài chính Napas.

2. Làm thế nào để ngăn chặn triệt để tấn công Man-in-the-Middle (MitM) trên ứng dụng di động?

Cần triển khai kỹ thuật SSL/TLS Certificate Pinning (Ghim chứng chỉ số). Ứng dụng Client sẽ lưu trữ trực tiếp Public Key hoặc mã băm SHA-256 của chứng chỉ máy chủ hợp lệ trong mã nguồn đã làm rối. Mọi nỗ lực chuyển hướng traffic qua Proxy trung gian tự ký (như BurpSuite, Charles Proxy) sẽ bị Client từ chối kết nối ngay tại bước bắt tay TLS.

3. Open API đóng vai trò gì trong việc chuyển đổi hệ sinh thái ngân hàng?

Open API cho phép chuyển dịch từ "Hệ sinh thái ngân hàng đóng" sang "Hệ sinh thái ngân hàng mở" (Open Banking). Các bên thứ ba (Fintech, sàn TMĐT, công ty viễn thông) có thể kết nối an toàn vào hạ tầng ngân hàng để cung cấp dịch vụ tra cứu số dư, chuyển tiền 24/7 và thanh toán hóa đơn trực tiếp mà không cần xây dựng lại toàn bộ hạ tầng tài chính từ đầu.

4. Chi phí duy trì và yêu cầu tuân thủ định kỳ của hệ thống thanh toán điện tử?

Doanh nghiệp trung gian thanh toán phải thực hiện đánh giá kiểm toán và tái cấp chứng chỉ PCI DSS hàng năm, chi trả phí duy trì cổng kết nối chuyển mạch Napas/Visa/Mastercard và duy trì đội ngũ giám sát an ninh mạng SOC (Security Operations Center) trực 24/7 để phát hiện các giao dịch bất thường.

5. Tại sao công nghệ Blockchain/DLT lại là tương lai của thanh toán điện tử?

Blockchain/DLT cung cấp cơ chế ghi chép sổ cái kế toán bất biến (Immutable), phi tập trung và đồng thuận phân tán. Điều này giúp loại bỏ sự phụ thuộc vào các tổ chức trung gian thanh toán bù trừ đa cấp, giảm chi phí xử lý giao dịch quốc tế từ 3% - 5% xuống dưới 0,5% và ngăn chặn hoàn toàn rủi ro gian lận sửa đổi nhật ký kế toán.

Kết luận

Đề tài "Thanh toán điện tử và xu hướng phát triển Fintech" đã hệ thống hóa toàn diện cơ sở lý luận, hiện trạng hạ tầng và mô hình kiến trúc kỹ thuật của hệ thống thanh toán phi tiền mặt tại Việt Nam. Bằng việc phân tích sâu sắc các nguy cơ an ninh thông tin trên thiết bị di động, chuẩn hóa giao thức truyền tin Socket TCP/IP bảo mật và chỉ ra lộ trình tích hợp các công nghệ mang tính cách mạng như Blockchain, Open API và e-KYC, công trình đã đóng góp một giải pháp tham chiếu có giá trị thực tiễn cao cho tiến trình chuyển đổi số quốc gia.

Sự hội tụ giữa công nghệ tài chính tiên tiến và khung pháp lý hoàn thiện chính là chìa khóa then chốt để Việt Nam bứt phá, xây dựng một xã hội không tiền mặt an toàn, minh bạch và thịnh vượng.