Phiên bản đa ngôn ngữ: Bài viết này có phiên bản tiếng Anh chuẩn quốc tế tại Phase 4A: Middle Platform, SOFAStack & CTU AI Risk Engine (tanhdev.com).
📖 Bản tiếng Anh (English Edition)
← Chương trước: Phase 3: Quy Trình Vận Hành & Stress Testing | Mục lục Series | Chương tiếp theo: Phase 4B: SOFAStack, RocketMQ & Storage →
Answer-first: Nền tảng Middle Platform (Trung Đài) chuẩn hóa toàn bộ nghiệp vụ thanh toán kết hợp hệ thống AI CTU (Complex Transaction Unit) thực hiện chấm điểm rủi ro, phân tích đồ thị và ngăn chặn gian lận tự động trên 8 chiều dữ liệu trong vòng dưới 100ms với tỷ lệ báo động giả dưới 0.1%.
Điều kiện tiên quyết: Nắm vững kiến trúc Middle Platform (Trung Đài), xử lý luồng sự kiện phân tán và các mô hình học máy phát hiện gian lận thời gian thực.
Giai đoạn 4: Tổng quan Công nghệ
4.1 Kiến trúc Middle Platform (Nền tảng trung tâm - 中台架构)
graph TB
subgraph Biz ["Business lines ( frontend app )"]
B1["Tmall"]
B2["Taobao"]
B3["Fliggy / others"]
end
subgraph MP ["Middle Platform — năng lực dùng chung"]
P1["Payment platform"]
P2["Risk CTU"]
P3["User / Member"]
P4["Marketing"]
end
B1 --> P1
B2 --> P1
B3 --> P1
B1 --> P2
B2 --> P3
B3 --> P4
MP --> INF["Hạ tầng: LDC / OceanBase / RocketMQ"]
style MP fill:#e8f4f8,stroke:#2a7da0
Lịch sử Phát triển (2015+)
2015: Alibaba công bố "Chiến lược Middle Platform"
↓
Đại Trung Đài, Tiểu Tiền Đài (Nền tảng giữa lớn + Tiền sảnh nhỏ)
↓
2018: Toàn bộ hệ thống được chuyển lên cloud
↓
2020: Nền tảng dữ liệu Cloud-native
Khái niệm cốt lõi: “Đại Trung Đài, Tiểu Tiền Đài”
┌──────────────────────────────────────────────────────────────┐
│ Mô hình Middle Platform │
├──────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ TIỀN SẢNH (Nhỏ) │ │
│ │ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │ │
│ │ │Tmall│ │Taobao│ │Ele.me│ │Fliggy│ │... │ │ │
│ │ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ │ │
│ └──────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ NỀN TẢNG TRUNG TÂM (Lớn) │ │
│ ├──────────────────┬──────────────────┬────────────────┤ │
│ │ │ │ │ │
│ │ Nền tảng │ Nền tảng │ Nền tảng │ │
│ │ Nghiệp vụ │ Dữ liệu │ Công nghệ │ │
│ │ │ │ │ │
│ │ • Trung tâm User │ • MaxCompute │ • Hạ tầng Cloud│ │
│ │ • Trung tâm SP │ • DataWorks │ • DevOps │ │
│ │ • Trung tâm Đơn │ • Analytics │ • Bảo mật │ │
│ │ • Thanh toán │ • AI/ML │ • Giám sát │ │
│ │ │ │ │ │
│ └──────────────────┴──────────────────┴────────────────┘ │
└──────────────────────────────────────────────────────────────┘
Nền tảng Dữ liệu Trung tâm (Thống nhất dữ liệu)
Bốn Giai đoạn Phát triển
| Giai đoạn | Thời kỳ | Đặc điểm |
|---|---|---|
| 1. Phân tán | 2009-2012 | Rời rạc, các ốc đảo dữ liệu |
| 2. Vòng lặp đóng dọc | 2012-2015 | Các hệ thống dọc nhỏ lẻ |
| 3. Middle Platform | 2015-2018 | Phương pháp luận thống nhất |
| 4. Cloud-Native | 2018+ | Trên cloud, kiến trúc Lake House |
Các Công nghệ Cốt lõi
MaxCompute:
- Hơn 100.000 máy chủ trong cluster
- Hơn 200.000 nhân viên sử dụng hàng ngày
- Xử lý 12 PB bảng dữ liệu
- Thời gian phản hồi truy vấn: “Ngày lễ Double 11 cũng nhanh như một ngày bình thường”
DataWorks:
- Phát triển cộng tác All-in-one
- Nền tảng quản trị dữ liệu
- Quản lý dữ liệu toàn trình (Full-procedure)
Lake House:
- Kiến trúc big data thế hệ mới
- Hợp nhất Data warehouse + Data lake
- Chi phí hầu như không tăng khi nghiệp vụ kinh doanh phình to
Các Thách thức Quản trị Dữ liệu đã được giải quyết
| Thách thức | Giải pháp |
|---|---|
| Ai sở hữu dữ liệu? | Mô hình sở hữu rõ ràng |
| Bảng dữ liệu lõi 12 PB | Một bản sao hợp nhất, truy cập chung |
| Nên xóa phần dữ liệu nào? | Quản lý vòng đời dữ liệu thông minh |
| Hơn 100 phòng ban | Chuẩn hóa các mô hình dữ liệu |
4.2 Bảo mật & Kiểm soát Rủi ro
graph LR
TX["Giao dịch đến"] --> RULE["Rule layer<br/>(chặn nhanh, <1ms)"]
RULE -->|"qua rule"| GNN["GNN inference<br/>(đồ thị quan hệ dựng sẵn)"]
GNN --> DEC{"Quyết định <100ms"}
DEC -->|"an toàn"| PASS["Cho qua — vào lõi thanh toán"]
DEC -->|"rủi ro"| HOLD["Giữ / kiểm tra tay"]
style DEC fill:#e8f4f8,stroke:#2a7da0
Ant Shield (Kiến Thuẫn - 蚁盾)
Định vị: Hạ tầng bảo mật cấp độ tài chính
┌──────────────────────────────────────────────────────────────┐
│ Kiến trúc Ant Shield │
├──────────────────────────────────────────────────────────────┤
│ │
│ Hành động của Người dùng │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Lớp Đánh giá Rủi ro │ │
│ │ ┌───────────────────────────────────────────────┐ │ │
│ │ │ Bộ não Thông minh CTU │ │ │
│ │ ├───────────┬───────────┬───────────┬───────────┤ │ │
│ │ │ Danh tính │ Lịch sử │ Hành vi │ Phân tích │ │ │
│ │ │ Thiết bị │ Tài khoản │ Giao dịch │ Mạng lưới │ │ │
│ │ └───────────┴───────────┴───────────┴───────────┘ │ │
│ │ │ │
│ │ Điểm thời gian thực: 0-100 (Mức độ Rủi ro) │ │
│ │ Thời gian xử lý: < 0.1 giây │ │
│ └──────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Ra quyết định & Hành động │ │
│ │ │ │
│ │ Rủi ro Thấp │ Rủi ro Vừa │ Rủi ro Cao │ │
│ │ ─────────► │ Cảnh báo │ Chặn/Duyệt │ │
│ │ Thanh toán │ "Vui lòng │ Tài khoản bị │ │
│ │ Bình thường │ xác nhận" │ hạn chế │ │
│ └──────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘
Bộ não Kiểm soát Rủi ro CTU
Tám Chiều Đánh giá Rủi ro:
| Chiều đánh giá | Kiểm tra điều gì | Ví dụ |
|---|---|---|
| Sở thích | Mô hình hành vi | Lần đầu chuyển khoản > 1000 CNY |
| Tài khoản | Lịch sử tài khoản | Tài khoản mới, chưa từng giao dịch |
| Danh tính | Cấp độ xác minh | Thiết bị chưa được xác minh |
| Giao dịch | Số tiền, tần suất | Đột biến về số tiền chuyển |
| Thiết bị | Dấu vân tay thiết bị | Đăng nhập từ thiết bị mới |
| Vị trí | Địa lý | Đăng nhập từ vị trí bất thường |
| Mối quan hệ | Phân tích mạng lưới | Không có bạn bè chung |
| Hành vi | Các mẫu thao tác | Vội vàng, bị thao túng từng bước |
Nghiên cứu Tình huống Thực tế: Vụ lừa đảo cô Li:
Dòng thời gian:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
T+0: Cô Li nhận cuộc gọi (Giả mạo CSKH Taobao)
↓
T+1: Bị dẫn dụ vào trang web lừa đảo
↓
T+2: Chuẩn bị chuyển ¥2,200
↓
CTU Cảnh báo: "Có thể có rủi ro lừa đảo"
Điểm rủi ro: Trung bình (chiều đánh giá mối quan hệ)
↓
T+3: Cô Li phớt lờ cảnh báo, chuyển ¥2,200
↓
T+4: Kẻ lừa đảo dụ dỗ chuyển tiếp ¥8,000
↓
CTU CHẶN: "Người nhận được xác nhận là kẻ lừa đảo"
Điểm rủi ro: Cao (hành vi + mối quan hệ)
Hành động: Hạn chế tài khoản
↓
T+5: Cô Li yêu cầu gỡ hạn chế (đã bị lừa)
Tổng thiệt hại: ¥10,200
Cảnh sát vào cuộc
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phân tích Mối quan hệ:
- Tài khoản trống (không có bạn bè) → Khả nghi
- Không có giao dịch chung trong quá khứ → Cảnh báo
- Hồ sơ tín dụng xấu → Bất thường
- Có liên kết với tài khoản trong danh sách đen → Chặn
Phát hiện Lừa đảo Thời gian thực ở Quy mô Lớn
Hiệu năng:
- Thời gian xử lý: < 0.1 giây
- Thông lượng: 544K+ TPS trong dịp Double 11
- Tỷ lệ báo cáo sai (False positive): < 0.1%
- Độ phủ: 100% giao dịch
Kiến trúc:
Luồng giao dịch ──► Trích xuất đặc trưng ──► Mô hình ML
│ │
▼ ▼
Phân tích Graph thời gian thực Điểm rủi ro
│ │
└────────┬───────────┘
▼
Động cơ Ra quyết định
│
┌─────────┴─────────┐
▼ ▼
Chấp thuận Chặn/Thử thách
4.3 Luồng Xử lý Thanh toán
Vòng đời Giao dịch
┌──────────────────────────────────────────────────────────────┐
│ Vòng đời Giao dịch Thanh toán │
├──────────────────────────────────────────────────────────────┤
│ │
│ 1. KHỞI TẠO │
│ Người dùng bấm "Thanh toán" │
│ │ │
│ ▼ │
│ 2. KIỂM TRA RỦI RO (CTU) │
│ ┌─────────────────────────────────────────────┐ │
│ │ Phân tích 8 chiều < 0.1s │ │
│ └─────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 3. XÁC THỰC DANH TÍNH │
│ • Mật khẩu / Sinh trắc học │
│ • Xác thực Token │
│ │ │
│ ▼ │
│ 4. KIỂM TRA SỐ DƯ │
│ • Có đủ tiền không? │
│ • Hạn mức tín dụng? │
│ │ │
│ ▼ │
│ 5. XỬ LÝ GIAO DỊCH │
│ ┌─────────────────────────────────────────────┐ │
│ │ Kiến trúc LDC: │ │
│ │ • Định tuyến tới đúng RZone │ │
│ │ • 2PC Cục bộ hoặc Phân tán │ │
│ │ • OceanBase: Sao chép Paxos │ │
│ └─────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 6. QUYẾT TOÁN (SETTLEMENT) │
│ • Ghi nợ người gửi │
│ • Ghi có người nhận │
│ • Cập nhật số dư (chuẩn ACID) │
│ │ │
│ ▼ │
│ 7. THÔNG BÁO │
│ • Push notification │
│ • Xác nhận SMS │
│ • Tạo biên lai │
│ │ │
│ ▼ │
│ 8. HOÀN TẤT │
│ Phản hồi cho người dùng │
│ Tổng thời gian < 1 giây │
└──────────────────────────────────────────────────────────────┘
Kiến trúc Quyết toán (Settlement)
┌──────────────────────────────────────────────────────────────┐
│ Hệ thống Quyết toán │
├──────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Tài khoản │ │ Ký quỹ (Escrow) │ Tài khoản │ │
│ │ Người gửi │◄──┤ Alipay │◄──┤ Người nhận │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ │ ┌────────────┴────────────┐ │ │
│ │ │ Lõi Quyết toán │ │ │
│ │ ├────────────────────────┤ │ │
│ │ │ • Bù trừ (Netting) │ │ │
│ │ │ • Thanh toán bù trừ │ │ │
│ │ │ • Đối soát │ │ │
│ │ │ • Xử lý theo lô │ │ │
│ │ └────────────────────────┘ │ │
│ │ │ │ │
│ └─────────────────┴─────────────────┘ │
│ │
│ Quyết toán hàng ngày: T+0 (thời gian thực) hoặc T+1 (lô) │
└──────────────────────────────────────────────────────────────┘
Đảm bảo chuẩn ACID ở Quy mô Khổng lồ
Thách thức: Đảm bảo ACID với 544.000 TPS cho các giao dịch phân tán
Giải pháp:
| Đặc tính | Triển khai |
|---|---|
| Tính Nguyên tử (Atomicity) | 2PC + Paxos (điều phối viên không phải điểm mù duy nhất) |
| Tính Nhất quán (Consistency) | Đồng thuận Paxos, sao chép đa số |
| Tính Cô lập (Isolation) | MVCC (Kiểm soát đồng thời đa phiên bản) |
| Độ bền bỉ (Durability) | Write-ahead log + Lưu trữ Paxos |
2PC dựa trên Paxos:
2PC Truyền thống: 2PC OceanBase:
┌─────────┐ ┌─────────┐
│ coord │ │ Paxos │ ← Điều phối viên được sao chép!
│ (SPOF) │ │ group │
└────┬────┘ └────┬────┘
│ │
┌───┴───┐ ┌───┴───┐
│ │ │ │
▼ ▼ ▼ ▼
R1 R2 R1 R2
SPOF = Điểm mù lỗi duy nhất (truyền thống)
Paxos = Đồng thuận phân tán (OceanBase)
Kiểm soát đồng thời MVCC:
- Đa phiên bản để việc đọc không chặn việc ghi
- Read committed snapshot
- Giao dịch khả tuần tự (Serializable) khi cần thiết
Thông lượng
| Thành phần | Double 11 2019 | Double 11 2020 |
|---|---|---|
| Alipay TPS | 544.000 | 583.000 |
| Alipay QPS | 61 triệu | Cao hơn |
| POLARDB TPS | 87 triệu | Cao hơn |
| Lô quyết toán | Hàng tỷ | Hàng tỷ |
4.4 SOFAStack - Kiến trúc Phân tán Cấp độ Tài chính
Các Thành phần Cốt lõi
┌──────────────────────────────────────────────────────────────┐
│ Nền tảng SOFAStack │
├──────────────────────────────────────────────────────────────┤
│ │
│ Lớp Dịch vụ (Service Layer) │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ • SOFABoot (Phiên bản nâng cấp của Spring Boot) │ │
│ │ • SOFARPC (RPC hiệu năng cực cao) │ │
│ │ • SOFAMesh (Service mesh) │ │
│ │ • SOFAArk (Cô lập theo module) │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ Lớp Phần mềm trung gian (Middleware) │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ • SOFAMQ (Hàng đợi tin nhắn) │ │
│ │ • SOFATracer (Distributed tracing) │ │
│ │ • SOFALookout (Giám sát) │ │
│ │ • SOFARegistry (Service discovery) │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ Lớp Dữ liệu (Data Layer) │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ • OceanBase (Cơ sở dữ liệu phân tán) │ │
│ │ • SOFADashboard (Nền tảng vận hành) │ │
│ └──────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘
Các Tính năng Chính
| Tính năng | Lợi ích |
|---|---|
| SOFABoot | Phát triển nhanh chóng, sẵn sàng cho doanh nghiệp |
| SOFARPC | 200.000+ TPS mỗi node, hỗ trợ nhiều giao thức |
| SOFAMesh | Giao tiếp service-to-service, mTLS an toàn |
| SOFAMQ | Chuyển giao exactly-once, 10 triệu+ TPS |
Tóm tắt Technology Stack
┌─────────────────────────────────────────────────────────────┐
│ Technology Stack Alipay Double 11 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Frontend (Tiền sảnh) │
│ ├── Mobile Apps (iOS/Android) │
│ ├── Web (React/Vue) │
│ └── Mini Programs (Tiểu chương trình Alipay) │
│ │
│ API Gateway │
│ ├── Định tuyến lưu lượng (Nhận biết LDC) │
│ ├── Giới hạn tốc độ (Rate limiting) │
│ └── Xác thực danh tính │
│ │
│ Lớp Dịch vụ (SOFAStack) │
│ ├── SOFABoot + SOFARPC │
│ ├── SOFAMesh (Service mesh) │
│ └── Logic nghiệp vụ (Java/Go) │
│ │
│ Phần mềm trung gian (Middleware) │
│ ├── RocketMQ (Hàng đợi tin nhắn) │
│ ├── Tair (Cache phân tán) │
│ └── SOFAMQ │
│ │
│ Lớp Dữ liệu (Data Layer) │
│ ├── OceanBase (Distributed SQL) │
│ ├── POLARDB (Cloud-native DB) │
│ └── OSS (Object storage) │
│ │
│ Hạ tầng (Infrastructure) │
│ ├── PouchContainer (Container runtime) │
│ ├── Kubernetes (ACK) │
│ ├── Alibaba Cloud │
│ └── Kiến trúc LDC (RZone/GZone/CZone) │
│ │
│ Bảo mật & Rủi ro │
│ ├── Ant Shield │
│ ├── Kiểm soát rủi ro CTU │
│ └── Phát hiện lừa đảo thời gian thực │
│ │
└─────────────────────────────────────────────────────────────┘
4.5 Môi Trường AI & Agentic Commerce (2025-2026)
Từ năm 2025, hệ sinh thái Alipay đã có một bước nhảy vọt quan trọng từ hệ thống xử lý đồng thời (high-concurrency) đơn thuần sang một nền tảng “Agentic Commerce” mạnh mẽ được điều khiển bởi AI.
AI Payment Infrastructure
- AI Wallet & Token Pay: Giải pháp thanh toán toàn diện bằng AI cho phép các AI Agent thực hiện giao dịch thay mặt người dùng một cách an toàn. Điều này đánh dấu sự chuyển dịch sang thương mại tự động hóa thực sự.
- Tương tác thông minh: Thay thế chatbot truyền thống bằng các AI Agent có khả năng quản lý chi tiêu, săn mã giảm giá và tối ưu hóa quyết định mua sắm trong thời gian thực.
- Merchant AI: Các nhà bán hàng áp dụng AI persona để livestream, tự động phân phối coupon tối ưu và tinh chỉnh lộ trình logistics nhằm đáp ứng nhu cầu khổng lồ mùa Double 11.
Mở rộng Toàn cầu & Trải nghiệm Liền mạch
- Alipay+: Cổng thanh toán toàn cầu tích hợp hơn 50 ví điện tử và ứng dụng ngân hàng, hỗ trợ du lịch và thương mại điện tử xuyên biên giới vô cùng mượt mà.
- Alipay Tap!: Giải pháp thanh toán không tiếp xúc qua mã QR bùng nổ, giúp hoàn tất thanh toán tức thì mà không cần thao tác vào app, giảm thiểu đáng kể ma sát trong quá trình check-out.
Tiếp theo: Giai đoạn 5 - Tổng hợp & Bài học Kinh nghiệm ➔
🔗 Đọc thêm các chuyên đề liên quan:
- Kiến trúc Microservices Golang & DDD
- Triển khai Agentic AI Swarm trong Production với OpenClaw & LiteLLM
- Kiến trúc Microservices Golang gRPC: Protobuf, TLS & Middleware
← Chương trước: Phase 3: Quy Trình Vận Hành & Stress Testing | Mục lục Series | Chương tiếp theo: Phase 4B: SOFAStack, RocketMQ & Storage →
❓ Câu Hỏi Thường Gặp (FAQ)
Middle Platform (Trung Đài) giải quyết vấn đề gì mà microservices không giải quyết?
Microservices tách nhỏ theo nghiệp vụ; Middle Platform tách theo năng lực dùng chung: thanh toán, rủi ro, user, marketing là platform cho mọi business line phía trên gọi xuống. Vấn đề được giải: cùng một năng lực (ví dụ kiểm soát rủi ro) không bị viết lại trong từng app — một lần build, nhiều lần dùng, một chỗ nâng cấp. Đổi lại: nếu platform không tách interface sạch, mọi business line dính chạm nhau qua nó — Trung Đài là đầu tư vào interface, không chỉ vào code.
CTU risk control dưới 100ms — vì sao constraint đó khó và làm sao đạt được?
Vì nó nằm trên critical path của thanh toán: chậm CTU là chậm toàn bộ cú thanh toán — không thể “thêm worker” như batch job. Ba đòn bẩy của Ant: (1) feature engine thuần in-memory với model đã load sẵn (không gọi model server qua mạng trong request path), (2) GNN (graph neural network) đánh giá mối quan hệ giao dịch trực tiếp trên đồ thị đã dựng sẵn — tính phức tạp dời về offline, request path chỉ làm suy luận, (3) quyết định phân tầng: rule nhanh chặn trước (dưới ms), model chỉ xử lý phần thắc mắc. Kết quả là risk decision hoàn thành trong khi thanh toán vẫn giữ p99 dưới 20ms tổng.
Đội nhỏ có cần Middle Platform không — hay đó là chuyện của tập đoàn?
Ở quy mô nhỏ, Middle Platform thường là over-engineering: 2-3 service dùng chung một thư viện là đủ “platform” thực dụng. Tín hiệu cần thật: khi 3+ business line cùng cần một năng lực (ví dụ: notification, payment, auth) và mỗi nơi tự viết. Quy tắc thăng cấp giống mọi chương khác — pain-triggered: xuất hiện năng lực bị viết lần thứ ba thì đó là lúc tách platform, không phải trước.
📚 Nguồn nghiên cứu (verification anchors)
| Claim | Nguồn |
|---|---|
| 544K TPS (2019), 583K TPS (2020), 61M QPS, 10M+ RocketMQ, SOFARPC 200k+ TPS | Ant Group public reporting (corpus series — hệ thống đóng, trích “Ant-reported”) |
| TPC-C 707 triệu tpmC | Kết quả TPC audit công khai |
| Chuỗi GMV 2009–2021; 256K TPS 2017 | Wikipedia: Singles’ Day (trích Reuters/Bloomberg/CNBC/MarketWatch) |
| Kiến trúc chương này | Corpus series (Phase tương ứng) |
Bản nghiên cứu: reports/research-alipay-executive-summary-100-rounds.{md,json} (ledger Ch1) + research-alipay-phases-consolidated-100-rounds.md (dossier hợp nhất Ch2–Ch9), mirror cả 2 repo. Ghi chú grounding: các con số đỉnh là Ant-reported (hệ thống đóng); TPC-C là con số duy nhất được audit độc lập.