Kiến trúc hệ thống Loyalty
cho toàn hệ sinh thái Sun Group

1. Tóm tắt điều hành

Vấn đề. Sun Group đã có chương trình (Sun Signature) và đã có lõi loyalty (Amadeus Loyalty and Rewards). Phần còn thiếu nằm ở việc đưa hơn mười miền kinh doanh vào chương trình. Mỗi miền dùng hệ thống khác nhau (PSS, PMS của chuỗi quản lý quốc tế, ticketing, POS, REMS, HIS, core ngân hàng), thuộc pháp nhân khác nhau, và một số miền giữ dữ liệu được luật bảo vệ đặc biệt (sức khỏe, ngân hàng). Nếu mỗi miền tự tích hợp thẳng vào Amadeus, tập đoàn sẽ có hơn mười kiểu tích hợp, quy tắc hủy / hoàn điểm không thống nhất, không đối soát được điểm giữa các pháp nhân và phụ thuộc sâu vào một nhà cung cấp.

Mục 3 phân tích 20 thách thức riêng của một chương trình dùng chung cho nhiều miền. Cách giải chung là mô hình liên bang ba lớp: một phần cố định cho cả tập đoàn, một phần miền được cấu hình trong giới hạn, một phần miền tự quản.

Đề xuất: “mua lõi, tự làm lớp kết nối”.

1. Giữ Amadeus Loyalty and Rewards làm lõi: sổ điểm gốc, hạng hội viên, quy tắc tích / tiêu điểm, khuyến mại. Không thay vì vừa triển khai.
2. Xây Sun Loyalty Hub do Sun Group sở hữu: cổng duy nhất cho mọi miền. Hub nhận một sự kiện giao dịch chuẩn (Qualifying Activity), lọc dữ liệu theo quyền riêng tư, chống trùng, xử lý hủy / hoàn, gắn pháp nhân và nguồn chi trả, sau đó gọi lõi.
3. Sun ID là định danh hội viên duy nhất. Mã hội viên Sun Signature gắn 1–1 với Sun ID. Hồ sơ khách tại từng miền chỉ lưu liên kết.
4. Dịch vụ quyền lợi theo hạng (Entitlement) để mọi điểm chạm (quầy check-in, lounge, cổng Sun World, lễ tân, golf) tra hạng và quyền lợi trong dưới 100 ms, kể cả khi mất kết nối.
5. Sổ phụ nợ phải trả điểm và đối soát liên pháp nhân trên SAP FICO. Pháp nhân phát hành điểm trả tiền, pháp nhân cho tiêu điểm được hoàn tiền, NCB và đối tác mua điểm. Hạch toán theo doanh thu chưa thực hiện (TT200, tài khoản 3387) [TC] R25.
6. Mỗi miền có mẫu tích hợp riêng: y tế chỉ gửi số tiền và cơ sở, không gửi mã dịch vụ hay chẩn đoán; NCB chỉ gửi lệnh cộng điểm, không gửi chi tiết giao dịch thẻ; khách sạn do chuỗi quốc tế quản lý cần rà soát hợp đồng quản lý trước khi tích điểm tiền phòng.

Lộ trình. Ba đợt. Đợt 0 (Q4/2026 – Q1/2027): nền tảng Hub, Entitlement, đối soát. Đợt 1 (Q1 – Q3/2027): Phú Quốc trước, gồm Sun World, sân bay, F&B và dịch vụ khu nghỉ dưỡng do Sun tự vận hành, thương mại, duty free, để luồng bay – ở – chơi chạy trọn trước APEC 2027. Đợt 2 (Q3/2027 – Q1/2028): tiền phòng khách sạn, golf, y tế, show, Sun Ecosystem App. Đợt 3 (2028): liên minh đối tác ngoài tập đoàn, ví gia đình, điểm + tiền, AI cá nhân hóa ưu đãi.

2. Hiện trạng Sun Signature

2.1 Dữ kiện đã công bố

2.2 Hiện trạng logic (suy ra từ dữ kiện)

Hình 1. Hiện trạng logic. Các mũi tên tích hợp là suy luận từ việc tích điểm đã chạy; cách tích hợp thực tế (API, file, thủ công) chưa được công bố [?].

2.3 Khoảng trống so với mục tiêu “phục vụ toàn bộ miền”

3. Thách thức của một hệ thống loyalty cho nhiều miền và giải pháp

Chương trình của một thương hiệu chỉ cần một bộ quy tắc. Chương trình liên minh của một tập đoàn đa ngành phải dùng một đơn vị điểm, một thang hạng, một tài khoản cho các doanh nghiệp có biên lợi nhuận, tần suất mua, quy định ngành, hệ thống và pháp nhân khác nhau. Mọi thách thức bên dưới đều quy về một mâu thuẫn: thống nhất để khách thấy một chương trình, nhưng vẫn khác biệt để từng miền có lãi và tuân thủ được quy định riêng.

3.1 Cách giải tổng quát: mô hình liên bang ba lớp

Không chọn “tập trung hết” hay “mỗi miền một chương trình”. Thay vào đó, xác định rõ cái gì cố định cho cả tập đoàn, cái gì miền được cấu hình trong giới hạn, cái gì miền tự quản. Hầu hết giải pháp ở mục 3.2 là cách áp dụng mô hình này vào một thách thức cụ thể.

Hình 2. Mô hình liên bang ba lớp. Lớp 1 chỉ thay đổi qua hội đồng chương trình; lớp 2 do miền tự thay đổi trong dải đã duyệt (ví dụ tỷ lệ tích 1–10% doanh thu); lớp 3 không phụ thuộc chương trình.

3.2 Thách thức và giải pháp

Cột “Mới” đánh dấu cơ chế lần đầu đưa vào tài liệu ở mục này. Các cơ chế còn lại đã được thiết kế ở mục tham chiếu.

3.3 Danh sách kiểm tra trước khi đưa một miền vào chương trình

Áp dụng thực tế các giải pháp trên: một miền chỉ được mở tích / tiêu điểm khi đạt đủ các điều kiện sau.

4. Mục tiêu kinh doanh và nguyên tắc kiến trúc

4.1 Mục tiêu

4.2 Nguyên tắc kiến trúc

4.3 Bài học từ chương trình tương tự trong nước

VinClub của Vingroup (ra mắt 08/2024) là trường hợp gần nhất: một chương trình thay thế toàn bộ chương trình riêng của các đơn vị (VinFast, Vinhomes, Vinpearl, Vinschool, Vinmec); Vinmec ngừng tích điểm VinID; tỷ lệ hoàn điểm khác nhau theo đơn vị và hạng; sau đó mở rộng ra khoảng 30 thương hiệu trong Vincom [C] S29 [?] chi tiết theo kết quả tìm kiếm, chưa mở trang gốc. Ba điểm áp dụng cho Sun Group:

• Hợp nhất và chuyển đổi dứt khoán chương trình cũ của các đơn vị, có ngày chuyển đổi công bố trước (LP1).
• Tỷ lệ tích điểm cấu hình theo miền × hạng vì biên lợi nhuận mỗi miền khác nhau. Lõi phải hỗ trợ cấu hình này, Hub chỉ chuyển dữ liệu.
• Mở ra khách thuê mặt bằng và đối tác sau khi các miền nội bộ đã ổn định, để có thêm chỗ tiêu điểm. Ở Sun Group, phần này tương ứng mall, duty free và khách thuê của Sun Property (đợt 2–3).

5. Bản đồ năng lực loyalty

Phân rã năng lực K1.3 “Hội viên & loyalty” và X1.4 “Đối soát liên pháp nhân & chống gian lận” trong bản đồ năng lực EA thành cấp L3. Cột “Hệ thống” cho biết năng lực nằm ở lõi mua (Amadeus), lớp Sun Group tự sở hữu hay nền tảng dùng chung.

6. Loyalty phục vụ từng miền kinh doanh

Phần trọng tâm của tài liệu. Mỗi miền được thiết kế theo năm câu hỏi: hệ thống nguồn là gì · tích điểm khi nào · tiêu điểm và quyền lợi gì · tích hợp theo mẫu nào · ràng buộc đặc thù. Tên hệ thống của miền lấy từ landscape EA; phần lớn là [?] vì chưa có danh mục ứng dụng chính thức.

7. Kiến trúc logic mục tiêu

Lõi loyalty mua ngoài được bao bởi một lớp do Sun Group sở hữu. Kênh đi vào qua API Management và Sun ID; các miền đi vào qua Sun Loyalty Hub; mọi điểm chạm tra quyền lợi qua Entitlement Service; sự kiện điểm đi ra nền tảng dữ liệu và tài chính.

Hình 3. Kiến trúc logic mục tiêu. Xanh dương: Sun Group sở hữu. Xanh lục: lõi mua (Amadeus). Vàng: thành phần tài chính / quyền lợi. Đỏ nét đứt: miền dữ liệu nhạy cảm có bộ lọc biên. Tím nét đứt: ranh giới ngân hàng. SPA giữ tích hợp native với Amadeus; Hub đọc sự kiện flown để phục vụ tài chính và dữ liệu.

7.1 Trách nhiệm từng thành phần

8. Dữ liệu và định danh

8.1 Thực thể chính và chủ sở hữu

8.2 Sự kiện chuẩn Qualifying Activity

Mọi miền gửi cùng một hợp đồng sự kiện. Khóa idempotency = source_system + source_ref + activity_type + version. Hủy / hoàn là sự kiện mới tham chiếu sự kiện gốc, không sửa sự kiện cũ.

{
  "event_id": "01JF8Q…",                    // ULID
  "event_type": "qualifying_activity.completed",   // .pending | .completed | .reversed
  "schema_version": "1.2",
  "domain": "THEME_PARK",                   // AIRLINE | AIRPORT | HOTEL | THEME_PARK | GOLF | PROPERTY | RETAIL | HEALTHCARE | VENUE | BANK | DIGITAL
  "legal_entity": "SWG-0401805040",         // pháp nhân ghi nhận doanh thu
  "site": "SW-BANA",                        // cơ sở / điểm bán
  "source": { "system": "TICKETING", "ref": "TCK-2027-000123", "version": 1 },
  "member": { "sun_id": "SID-7c1e…", "presented_by": "DYNAMIC_QR" },
  "activity": {
    "type": "ADMISSION_USED",
    "service_date": "2027-04-30T09:12:44+07:00",
    "eligible_amount": 1150000, "currency": "VND",
    "product_group": "ADMISSION",           // nhóm chung, không chi tiết nhạy cảm
    "channel": "DIRECT_WEB",                // đại lý / đoàn sẽ bị loại ở Hub
    "quantity": 2
  },
  "reverses_event_id": null,
  "privacy_profile": "STANDARD"             // HEALTHCARE_MINIMAL | BANK_INSTRUCTION
}

Hồ sơ HEALTHCARE_MINIMAL chỉ cho phép sun_id, legal_entity, site, service_date, eligible_amount, product_group ∈ {HEALTH_CHECK, SERVICE_ROOM, OTHER}. Hồ sơ BANK_INSTRUCTION chỉ cho phép sun_id, points, product_code, bank_ref; NCB tự tính điểm trong ranh giới ngân hàng.

8.3 Định danh: Sun ID là khóa

• Đăng ký hội viên đồng nghĩa có Sun ID. Hội viên đã đăng ký trước qua SPA hoặc sunsignature.vn được đối chiếu và gắn Sun ID trong đợt 0. Tài khoản trùng được gộp có kiểm soát; sổ điểm giữ lịch sử của cả hai tài khoản.
• Liên kết với hồ sơ ở từng miền qua ba cách: (1) khách đăng nhập Sun ID trên kênh của miền; (2) khách xuất trình QR động (hiệu lực 60 giây, ký số) tại điểm chạm; (3) ghép theo quy tắc xác định (điện thoại + ngày sinh + họ tên) chỉ khi có consent liên kết, kết quả ghép cần khách xác nhận trên app.
• Mã bệnh nhân và CIF ngân hàng không rời khỏi miền ở dạng gốc. Bảng liên kết chỉ lưu token; chỉ miền đó giải token được.
• CDP ghép hồ sơ cho phân tích và tiếp thị (DT1.2), nhưng không quyết định hội viên. Nguồn sự thật về “ai là hội viên” là Sun ID cộng lõi loyalty.

9. Luồng nghiệp vụ chính

9.1 Tích điểm từ một miền bất kỳ

Hình 4. Luồng tích điểm. Mục tiêu: điểm hiện trên app trong 2 phút với giao dịch POS, trong 24 giờ với giao dịch theo lô (folio khách sạn, đợt thanh toán bất động sản).

9.2 Thanh toán bằng điểm tại POS (điểm + tiền)

Hình 5. Tiêu điểm theo mô hình giữ rồi chốt (hold / capture) như thanh toán thẻ. Luồng QR qua NCB iziMobile hiện có đi qua hệ thống NCB; mục tiêu là NCB gọi cùng API authorize / capture của Hub để quy tắc và đối soát thống nhất.

9.3 Đổi phần thưởng của miền khác (ví dụ: điểm từ SPA đổi đêm phòng)

1. Hội viên chọn phần thưởng trên Sun Ecosystem App. Catalog do Reward Orchestrator tổng hợp từ các miền, có giá điểm và tồn.
2. Hub giữ điểm (hold), gọi API của miền cung cấp để giữ chỗ: inventory vé thưởng của PSS, allotment phòng thưởng của khách sạn, vé Sun World.
3. Miền xác nhận → Hub chốt điểm, phát hành mã đặt chỗ hoặc voucher. Miền từ chối hoặc hết hạn giữ chỗ → Hub hủy hold.
4. Khi dịch vụ được dùng (check-out, quét cổng), miền gửi sự kiện reward.fulfilled → sổ phụ ghi phải trả giá hoàn trả cho pháp nhân cung cấp.
5. Khách không dùng (no-show) → áp chính sách: mất điểm hoặc hoàn một phần, tùy loại phần thưởng.

9.4 Nhận diện hạng tại điểm chạm

• Hàng không: hạng nằm trong hồ sơ FQTV của PNR, DCS tự áp ưu tiên check-in và hành lý (native Amadeus).
• Lounge, fast track, cổng ưu tiên Sun World, lễ tân, golf: nhân viên quét QR hội viên hoặc thẻ NCB Visa Sun Signature → Entitlement Service trả hạng, quyền lợi còn lại trong năm, cảnh báo (ví dụ đã dùng 4/4 Wowpass) → ghi nhận đã dùng.
• Khu xa (đỉnh Fansipan, đảo): thiết bị biên giữ bản sao danh sách quyền lợi được ký số, làm mới mỗi 15 phút; ghi nhận đã dùng được đồng bộ sau và đối chiếu chống dùng hai lần.

9.5 Hủy, hoàn và thu hồi điểm

9.6 Đăng ký và chuyển đổi hội viên

• Đăng ký từ bất kỳ kênh nào đều tạo hoặc dùng Sun ID → tạo hội viên trong lõi → phát sự kiện member.enrolled → các miền nhận để gắn liên kết.
• Đăng ký tại quầy (lễ tân, cổng): ghi số điện thoại, gửi đường link hoàn tất qua SMS / ZNS; giao dịch hiện tại vào “điểm chờ”, được ghi có khi khách hoàn tất trong N ngày.
• Chương trình cũ của các đơn vị (nếu có) chuyển đổi một lần theo tỷ lệ công bố, giữ hạng tương đương trong một kỳ (đúng cách SPA đã làm với chương trình tương đương [C] S29).

10. Tài chính điểm và đối soát liên pháp nhân

Sun Point có giá trị tiền (bài PR ghi khoảng 300 đồng / điểm [C] S30), được tiêu ở pháp nhân khác với pháp nhân phát hành, và được NCB, đối tác mua. Vì vậy cần một mô hình tài chính được Kế toán tập đoàn và kiểm toán chấp thuận trước khi mở thêm miền.

Hình 6. Mô hình “đơn vị vận hành trung tâm” thường dùng trong chương trình liên minh [TC]. Phương án thay thế: mỗi pháp nhân tự giữ nợ điểm và bù trừ song phương. Với hơn 10 pháp nhân, cách này cần đến n×(n−1) quan hệ đối soát, nên không khuyến nghị.

11. Yêu cầu phi chức năng

Các con số là mục tiêu thiết kế ban đầu [GĐ] L‑A01, cần hiệu chỉnh theo số liệu lượt khách, giao dịch POS và số hội viên thực tế mà CIO cung cấp. Nguyên tắc: thiết kế dư gấp 3 lần mức cao điểm đã đo (Tết, 30/4, hè).

12. Bảo mật, dữ liệu cá nhân và tuân thủ

12.1 Rủi ro gian lận và kiểm soát

12.2 Dữ liệu cá nhân (Luật BVDLCN 2025, Nghị định 356/2025)

• Xác định vai trò: đơn vị vận hành chương trình là bên kiểm soát dữ liệu loyalty; từng pháp nhân là bên kiểm soát dữ liệu giao dịch của mình; Amadeus và các nhà cung cấp là bên xử lý. Cần hợp đồng xử lý dữ liệu giữa các bên [TC] R13, R24.
• Consent tách theo mục đích: (1) tham gia chương trình; (2) chia sẻ dữ liệu giữa các pháp nhân trong tập đoàn; (3) tiếp thị; (4) cá nhân hóa bằng AI; (5) liên kết với NCB. Từ chối (3)–(5) không làm mất tư cách hội viên.
• Dữ liệu nhạy cảm: dữ liệu sức khỏe và dữ liệu tài chính – ngân hàng không vào lõi loyalty, CDP. Bộ lọc biên (mục 8.2) là kiểm soát kỹ thuật, có kiểm thử tự động trong CI.
• Trẻ em: hội viên từ đủ tuổi theo điều khoản (đề xuất 16 hoặc 18); giao dịch của trẻ em (vé Sun World) tích vào tài khoản người giám hộ.
• Quyền của chủ thể dữ liệu: xem, sửa, rút consent, xóa qua app và tổng đài, trong thời hạn Nghị định 356/2025 quy định. Khi xóa, sổ điểm được ẩn danh hóa thay vì xóa, vì chứng từ kế toán phải lưu theo thời hạn luật định.
• DPIA trước mỗi đợt mở miền mới; hồ sơ đánh giá chuyển dữ liệu ra nước ngoài nếu lõi hoặc CleverTap lưu ngoài Việt Nam.

12.3 Quy định khác cần pháp chế xác nhận

13. Quyết định kiến trúc (ADR)

14. Lộ trình triển khai

15. Mô hình vận hành và KPI

15.1 Vai trò

15.2 KPI

16. Rủi ro và câu hỏi mở

16.1 Rủi ro chính

16.2 Câu hỏi cần CIO và business owners trả lời

1. Pháp nhân nào là đơn vị vận hành Sun Signature? Ai là chủ chương trình?
2. Amadeus Loyalty and Rewards được lưu trữ ở đâu? Hợp đồng gồm những mô-đun, API, hạn mức, SLA nào? Có điều khoản xuất dữ liệu không?
3. Hiện tại SPA và Sun Property tích hợp với lõi bằng cách nào (API, file, nhập tay)? NCB chuyển lợi tức tiết kiệm thành điểm bằng cách nào?
4. Sun ID đã dùng cho những ứng dụng nào ngoài SPA? Ai sở hữu sản phẩm Sun ID?
5. Giá phát hành, giá hoàn trả của Sun Point? 300 đồng / điểm là giá trị khi tiêu hay giá nội bộ?
6. Hợp đồng quản lý của từng khách sạn có cho tích điểm Sun Signature trên tiền phòng không? Chủ sở hữu được nhận dữ liệu khách nào?
7. Bệnh viện Mặt Trời: những dịch vụ nào được phép tích điểm?
8. Số liệu năm gần nhất: lượt khách Sun World theo điểm, số giao dịch POS, số phòng đêm, số hành khách SPA, để hiệu chỉnh mục 11.
9. Các đơn vị có chương trình hội viên riêng nào cần chuyển đổi (ví dụ thẻ năm Sun World, hội viên golf)?

17. Nguồn và giả định

Nguồn công khai (S) — mã S15–S25 trùng với tài liệu EA

Chuẩn và văn bản tham chiếu (R)

Sổ giả định (L‑A)

Tài liệu dựa trên nguồn công khai đến ngày 12/11/2026 và thông tin người dùng xác nhận trong tài liệu EA. Không có quyền truy cập hệ thống nội bộ Sun Group; mọi mô tả hiện trạng kỹ thuật ngoài các nguồn trên là suy luận và được gắn nhãn.