Loyalty 2 — Points engine: tích, tiêu & nghĩa vụ điểm

13 thg 7, 2026 4 lượt xem
#banking
#accounting
#loyalty
#redemption
#point-liability
#points

Loyalty 2 — Points engine: tích, tiêu & nghĩa vụ điểm

Nếu bài Tổng quan loyalty mô tả tại sao ngân hàng chạy chương trình khách hàng thân thiết, thì bài này đi vào cỗ máy làm điểm chạy được: points engine. Đây là hệ thống chịu trách nhiệm biến một giao dịch thẻ thành một số điểm, giữ số điểm đó đúng trạng thái theo thời gian, cho phép khách đổi điểm lấy giá trị, và — quan trọng không kém — ghi nhận số điểm chưa đổi như một khoản nợ trên bảng cân đối kế toán của ngân hàng.

Điểm thưởng nhìn bề ngoài có vẻ đơn giản: "chi 10.000đ được 1 điểm". Nhưng khi triển khai thật, points engine phải xử lý: quy tắc tích điểm cấu hình được theo loại giao dịch và hạng khách, việc giao dịch có thể bị hoàn/hủy sau khi đã cộng điểm, điểm hết hạn, và nghĩa vụ kế toán khi điểm chưa đổi. Toàn bộ những mảnh ghép đó tạo nên nội dung bài này. Tất cả con số dưới đây là minh họa nguyên lý, không phải mức thực tế của bất kỳ ngân hàng nào.

Earn rules — Quy tắc tích điểm

Trái tim của points engine là rule engine (bộ máy quy tắc): một tập cấu hình quyết định mỗi giao dịch sinh ra bao nhiêu điểm. Ngân hàng cần rule engine thay vì code cứng, vì marketing thay đổi ưu đãi liên tục (chiến dịch cuối tuần, nhóm hàng ưu đãi theo mùa) và không thể build lại hệ thống mỗi lần.

Các loại quy tắc tích điểm phổ biến:

  • Theo giá trị giao dịch (base earn): quy tắc nền, ví dụ 1 điểm cho mỗi 10.000đ chi tiêu bằng thẻ. Đây là tỷ lệ tích cơ bản áp cho hầu hết giao dịch mua sắm.
  • Theo loại giao dịch / MCC (bonus multiplier): MCC (Merchant Category Code) phân loại điểm chấp nhận thẻ theo ngành. Ngân hàng có thể nhân hệ số ở nhóm ưu đãi, ví dụ chi tiêu tại nhóm nhà hàng (MCC 5812) hoặc du lịch được x3 điểm, chi siêu thị được x2 điểm. Xem thêm về MCC và luồng giao dịch tại Nghiệp vụ thẻ tín dụng.
  • Bonus theo sự kiện: thưởng một lần khi mở thẻ (welcome bonus), khi đạt mốc chi tiêu ("chi đủ 20 triệu trong 3 tháng đầu được 500 điểm"), hoặc theo dịp sinh nhật.
  • Theo hạng khách (tier accelerator): khách hạng cao tích nhanh hơn — hạng Vàng x1.2, hạng Bạch kim x1.5 trên cùng mức chi. Cơ chế hạng được mô tả chi tiết ở Hạng & quyền lợi.
  • Loại trừ (exclusions): không phải giao dịch nào cũng tích điểm. Các khoản thường bị loại: rút tiền mặt (cash advance), các loại phí (phí thường niên, phí trễ hạn, lãi), giao dịch nạp ví/chuyển tiền, và giao dịch đã bị hoàn. Loại trừ là điểm dễ sai và dễ bị lạm dụng nhất — cần định nghĩa rõ ràng trong rule engine.

Một điểm thiết kế quan trọng: rule engine nên chấm điểm theo thứ tự ưu tiên và có quy tắc gộp/không gộp (stacking). Ví dụ một giao dịch nhà hàng của khách hạng Bạch kim: base earn + bonus MCC nhà hàng + accelerator hạng — có gộp cả ba hay chỉ lấy quy tắc cao nhất? Đây là quyết định nghiệp vụ phải khai báo tường minh.

# Cau hinh earn rules (minh hoa)

RULE base_earn         : 1 diem / 10.000d           uu tien 100  gop=yes
RULE mcc_dining_x3     : MCC in (5811,5812,5814) -> nhan 3.0     uu tien 50   gop=yes
RULE mcc_grocery_x2    : MCC in (5411,5422)      -> nhan 2.0     uu tien 50   gop=yes
RULE tier_platinum     : tier = PLATINUM         -> nhan 1.5     uu tien 20   gop=yes
RULE welcome_bonus     : su kien = CARD_ACTIVATED -> +500 diem    mot lan
EXCLUDE cash_advance, fee_*, wallet_topup, reversed_txn

# Tinh cho 1 giao dich nha hang 1.500.000d, khach PLATINUM:
#   base   = 1.500.000 / 10.000        = 150 diem
#   x3 dining                          = 150 * 3   = 450
#   x1.5 platinum                      = 450 * 1.5 = 675 diem

Redemption / burn — Tiêu điểm

Redemption (hay "burn", đối lập với "earn") là khi khách đổi điểm lấy giá trị. Đây là mặt chi phí của chương trình và là nơi khách cảm nhận được giá trị thật. Các hình thức đổi điểm phổ biến:

  • Đổi quà / voucher: catalog quà tặng, e-voucher mua sắm, vé xem phim.
  • Trừ vào sao kê (statement credit): dùng điểm để giảm dư nợ thẻ. Đơn giản, được khách ưa chuộng, dễ hạch toán.
  • Đổi dặm bay (miles): chuyển điểm sang chương trình dặm của hãng hàng không.
  • Chuyển sang đối tác (transfer to partner): đổi điểm sang chương trình của bên thứ ba theo tỷ lệ thỏa thuận.

Ba tham số cấu hình quan trọng của redemption:

  • Tỷ giá điểm → giá trị (redemption rate): ví dụ 1 điểm = 100đ khi trừ sao kê, nhưng 1 điểm = 150đ khi đổi vé máy bay. Tỷ giá thường khác nhau theo kênh — đây chính là công cụ ngân hàng dùng để định hướng khách đổi điểm vào kênh có lợi.
  • Ngưỡng tối thiểu (minimum threshold): ví dụ phải có tối thiểu 500 điểm mới được đổi. Ngưỡng giúp giảm chi phí xử lý các giao dịch đổi vụn vặt.
  • Kênh đổi (redemption channel): app, internet banking, tổng đài, hoặc website đối tác.

Giá trị mỗi điểm khi đổi (redemption value per point) là con số cốt lõi để định giá cả chương trình: nó vừa quyết định sức hấp dẫn với khách, vừa là đầu vào để tính nghĩa vụ điểm (xem phần kế toán bên dưới).

Vòng đời & trạng thái điểm

Điểm không phải cứ tích là dùng được ngay. Mỗi lô điểm đi qua một vòng đời trạng thái rõ ràng, và points engine phải quản lý đúng từng chuyển tiếp:

  • pending (chờ xác nhận): điểm được tính ngay khi giao dịch authorize, nhưng chưa khả dụng. Lý do: giao dịch thẻ có thể bị hủy trước khi ghi sổ chính thức (posting), hoặc có cửa sổ tranh chấp/hoàn hàng. Nhiều ngân hàng giữ điểm ở pending vài ngày đến vài tuần.
  • posted / available (khả dụng): giao dịch đã ghi sổ chính thức và qua cửa sổ an toàn, điểm chuyển sang khả dụng và khách có thể đổi.
  • redeemed (đã đổi): khách đã dùng điểm để đổi giá trị — điểm rời khỏi số dư khả dụng.
  • expired (hết hạn): điểm quá thời hạn hiệu lực mà chưa đổi — bị thu hồi (xem phần expiry).
  • reversed / clawed back (thu hồi): khi giao dịch gốc bị hoàn (refund), hủy hoặc chargeback, số điểm đã cộng phải bị thu hồi — gọi là clawback. Đây là điểm nối trực tiếp với nghiệp vụ thẻ: xử lý reversal và chargeback được mô tả ở Nghiệp vụ thẻ tín dụng.

Xử lý clawback là một trong những phần dễ sai nhất. Nếu điểm còn ở trạng thái pending khi giao dịch bị hủy, chỉ cần bỏ lô pending. Nhưng nếu điểm đã posted và thậm chí đã bị đổi, thì thu hồi phức tạp hơn: số dư có thể âm tạm thời (khách "nợ điểm"), và ngân hàng phải có chính sách xử lý (trừ vào điểm tương lai, hoặc quy đổi ra tiền). Chống lạm dụng kiểu "mua để lấy điểm rồi hoàn hàng" (points farming) là một chủ đề của Gian lận & tuân thủ.

Expiry & breakage

Expiry (hết hạn) là cơ chế điểm mất hiệu lực nếu không đổi trong thời hạn quy định. Hai kiểu phổ biến:

  • Theo thời gian tuyệt đối: điểm hết hạn sau N tháng kể từ ngày tích (ví dụ 24 tháng), bất kể khách có hoạt động hay không. Thường áp dụng theo lô (FIFO — điểm cũ nhất tiêu trước, hết hạn trước).
  • Theo không hoạt động (inactivity): toàn bộ điểm hết hạn nếu tài khoản không phát sinh earn/burn nào trong N tháng.

Việc chọn chính sách expiry phải cân bằng: hết hạn quá gắt làm khách bực và mất niềm tin; không hết hạn thì nghĩa vụ điểm phình mãi không giảm.

Breakage là khái niệm kế toán quan trọng gắn liền với expiry: đó là phần điểm được phát ra nhưng sẽ không bao giờ được đổi (do hết hạn, do khách quên, do số dư quá nhỏ dưới ngưỡng). Breakage không phải chuyện xấu về mặt tài chính — ngược lại, nó làm giảm chi phí thực tế của chương trình so với số điểm đã phát. Nhưng nó phải được ước lượng và xử lý cẩn thận trong kế toán, vì nó trực tiếp quyết định ngân hàng ghi nhận bao nhiêu doanh thu và trích lập bao nhiêu nghĩa vụ.

Point liability & kế toán

Đây là phần khiến points engine không chỉ là chuyện marketing mà là chuyện của phòng tài chính. Nguyên tắc cốt lõi: điểm đã phát cho khách là một nghĩa vụ nợ (liability) của ngân hàng. Khi khách tích điểm, ngân hàng đã "hứa" sẽ cung cấp giá trị trong tương lai — và lời hứa đó là một khoản nợ phải ghi nhận, không phải chi phí đã tiêu.

Cách ước tính point liability (mức khái niệm):

Point liability = So diem chua doi
                  x Gia tri uoc tinh moi diem
                  x Ty le du kien se doi (redemption rate ky vong)

Vi du (minh hoa):
  So diem chua doi           = 1.000.000.000 diem
  Gia tri moi diem           = 100d
  Ty le du kien se doi       = 80%   (=> breakage 20%)

  Liability = 1.000.000.000 x 100 x 0.80 = 80.000.000.000 d

Con số tỷ lệ dự kiến đổi (và phần bù của nó là breakage) là ước lượng thống kê dựa trên lịch sử: có bao nhiêu phần trăm điểm phát ra thực sự được đổi trong quá khứ. Ước lượng này phải được rà soát và điều chỉnh định kỳ — nếu hành vi khách thay đổi (đổi nhiều hơn dự kiến), liability phải tăng lên.

Góc IFRS 15 (mức khái niệm). Chuẩn mực IFRS 15 xem điểm thưởng có giá trị vật chất (material right) như một nghĩa vụ thực hiện (performance obligation) riêng trong giao dịch gốc. Nghĩa là: khi khách chi tiêu và được tích điểm, một phần giá trị giao dịch được hoãn lại (deferred revenue) như khoản nợ, thay vì ghi nhận doanh thu ngay toàn bộ. Doanh thu hoãn này chỉ được ghi nhận khi điểm được đổi (nghĩa vụ được thực hiện) hoặc khi hết hạn. Đối với phần breakage, IFRS 15 hướng dẫn ghi nhận doanh thu breakage theo tỷ lệ, dàn đều theo pattern khách đổi điểm — không ghi nhận ngay toàn bộ tại thời điểm phát điểm. Ngân hàng chỉ ghi nhận breakage khi mẫu hình dữ liệu cho thấy khả năng điểm đó không đổi là ít khả năng đảo ngược. (Đây chỉ là mô tả nguyên lý; áp dụng thực tế cần chuẩn mực và tư vấn kế toán cụ thể.)

Tóm lại vòng đời kế toán của một lô điểm: phát điểm → ghi tăng nghĩa vụ (deferred) → điểm được đổi → giảm nghĩa vụ, ghi nhận chi phí/doanh thu tương ứng → phần không đổi (breakage) → hoàn nhập nghĩa vụ, ghi nhận doanh thu breakage theo tỷ lệ. Trích lập và điều chỉnh dự phòng chạy song song và được cập nhật theo breakage thực tế quan sát được.

Kiến trúc điểm

Về mặt hệ thống, nguyên tắc số một là: sổ cái điểm (points ledger) phải tách khỏi sổ cái tiền (general ledger). Điểm không phải tiền tệ pháp định; trộn hai thứ vào một sổ gây rối loạn đối soát và kế toán. Points ledger là hệ thống riêng chuyên ghi các bút toán điểm.

Nguyên tắc thiết kế points ledger:

  • Append-only / bất biến (immutable): mỗi biến động điểm (earn, redeem, expire, reversal) là một bản ghi mới, không bao giờ sửa/xóa bản ghi cũ. Số dư là kết quả cộng dồn (running balance) của các bản ghi. Cách này cho phép đối soát hoàn hảo và truy vết mọi thay đổi — cực kỳ quan trọng khi tranh chấp với khách hoặc kiểm toán.
  • Số dư điểm (balance): không lưu như một con số có thể ghi đè, mà tính từ ledger; nếu cache số dư để truy vấn nhanh thì phải đối chiếu định kỳ với tổng ledger.
  • Real-time vs batch: earn có thể xử lý real-time (cộng điểm pending ngay khi authorize) hoặc batch (chạy cuối ngày theo file giao dịch). Nhiều ngân hàng dùng lai: pending real-time, chuyển available theo batch sau khi posting. Chi tiết mô hình dữ liệu và xử lý stream/batch được bàn ở Kiến trúc dữ liệu loyalty.
# Points ledger (append-only, minh hoa)

ledger_id | cust | txn_ref  | type     | points | status    | ts
----------+------+----------+----------+--------+-----------+------------------
L0001     | C123 | T900011  | EARN     |  +675  | PENDING   | 2026-06-20 10:15
L0002     | C123 | T900011  | POST     |     0  | AVAILABLE | 2026-06-23 02:00   # PENDING->AVAILABLE
L0003     | C123 | R700005  | REDEEM   |  -500  | REDEEMED  | 2026-06-25 14:30   # doi voucher
L0004     | C123 | T900011  | REVERSAL |  -675  | REVERSED  | 2026-06-28 09:00   # hoan giao dich goc

# So du C123 = 675 - 500 - 675 = -500 diem  => can chinh sach xu ly so du am

Kiểm soát & đối soát

Points engine cần các chốt kiểm soát:

  • Đối soát điểm phát vs earn hợp lệ: tổng điểm ghi trong ledger phải khớp với điểm lẽ ra được tính từ các giao dịch hợp lệ (không tính giao dịch loại trừ). Chạy đối soát định kỳ để phát hiện điểm phát sai.
  • Đối soát liability: tổng số dư điểm khả dụng × giá trị điểm phải khớp với con số liability trên sổ kế toán.
  • Chống lạm dụng: phát hiện mẫu hình bất thường như tích điểm rồi hoàn hàng hàng loạt, tài khoản đổi điểm bất thường, khai thác lỗi tỷ giá đổi. Chủ đề này thuộc Gian lận & tuân thủ.

Use case thực tế

Bối cảnh: Khách C123 hạng Bạch kim, chi tiêu 5.000.000đ tại một nhà hàng (MCC dining, được x3).

  1. Tích điểm. Rule engine chạy: base = 5.000.000 / 10.000 = 500 điểm; x3 dining = 1.500; x1.5 platinum = 2.250 điểm. Points ledger ghi bản ghi EARN +2.250, trạng thái PENDING (chờ giao dịch posted).
  2. Chuyển khả dụng. Sau 3 ngày giao dịch posted, batch chuyển lô điểm sang AVAILABLE. Số dư khả dụng của C123 tăng 2.250 điểm.
  3. Kế toán. Tại thời điểm phát, một phần giá trị giao dịch được hoãn lại (deferred revenue) tương ứng nghĩa vụ 2.250 điểm × 100đ × tỷ lệ đổi kỳ vọng.
  4. Đổi voucher. Khách đổi 2.000 điểm lấy voucher trị giá 200.000đ (tỷ giá 1 điểm = 100đ). Ledger ghi REDEEM −2.000, trạng thái REDEEMED. Nghĩa vụ điểm giảm tương ứng, doanh thu hoãn được ghi nhận. Số dư còn 250 điểm.
  5. Xử lý khi hoàn giao dịch. Giả sử vài ngày sau khách hoàn một phần bữa ăn trị giá 5.000.000đ (chargeback/refund toàn bộ). Points engine phải clawback 2.250 điểm đã cộng. Nhưng khách chỉ còn 250 điểm khả dụng vì đã đổi 2.000. Ledger ghi REVERSAL −2.250 → số dư = −2.000 điểm (âm). Theo chính sách, ngân hàng trừ khoản âm này vào điểm tích tương lai, hoặc thu hồi giá trị voucher đã cấp. Đây chính xác là tình huống clawback sau redeem trong sơ đồ vòng đời.

Ghi nhớ

  • Rule engine là trái tim tích điểm: base earn theo giá trị, bonus theo MCC/sự kiện, accelerator theo hạng, và exclusions (rút tiền mặt, phí) phải khai báo tường minh.
  • Điểm đi qua vòng đời pending → available → redeemed / expired / reversed; xử lý clawback khi hoàn/hủy/chargeback là phần dễ sai nhất, có thể tạo số dư âm.
  • Breakage = điểm không bao giờ đổi; nó làm giảm chi phí thực nhưng phải được ước lượng và điều chỉnh liên tục.
  • Điểm đã phát là nghĩa vụ nợ. IFRS 15 xem điểm là performance obligation → hoãn doanh thu (deferred revenue), ghi nhận khi đổi; breakage ghi nhận theo tỷ lệ dàn đều, không ghi ngay.
  • Kiến trúc: points ledger tách khỏi tiền, append-only bất biến để đối soát; số dư tính từ ledger; kết hợp real-time (pending) và batch (available).
  • Kiểm soát: đối soát điểm phát vs earn hợp lệ, đối soát liability, và chống lạm dụng points farming.

Liên quan: Tổng quan loyalty · Hạng & quyền lợi · Kiến trúc dữ liệu loyalty · Gian lận & tuân thủ · Nghiệp vụ thẻ tín dụng

Bài viết liên quan

Dòng chảy dữ liệu core -> ODS -> DWH -> BI, mô hình dữ liệu cốt lõi và bộ ví dụ SQL thực hành chạy được.

13 thg 7, 2026 7

Mô hình dữ liệu giao dịch thẻ, các KPI thẻ, phân tích chi tiêu & phát hiện gian lận, kèm ví dụ SQL chạy được trên sandbox.

13 thg 7, 2026 5

Bản chất kinh doanh của ngân hàng: trung gian tài chính, bảng cân đối, NIM và vì sao dữ liệu quan trọng.

13 thg 7, 2026 4

Kiến trúc core banking, CIF, các phân hệ và xử lý online vs batch/EOD.

13 thg 7, 2026 4