Các mẫu SQL dùng để phát hiện gian lận giao dịch

• Phát hiện gian lận thường bắt đầu không phải từ machine learning mà từ việc thiết kế đúng bảng và join, rồi dùng SQL để tìm các mẫu bất thường về tốc độ, vị trí, số tiền, merchant và khung giờ
• Velocity dùng để tìm các cụm giao dịch dồn vào trong thời gian ngắn của cùng một chủ thẻ, đồng thời cần điều chỉnh cửa sổ thời gian, ngưỡng và danh sách trắng cho false positive
• Impossible travel dùng LAG() và tính khoảng cách để phát hiện các trường hợp như thanh toán ở Chicago rồi 7 phút sau lại thanh toán ở Los Angeles, một tín hiệu mạnh của thẻ bị sao chép
• Bất thường về số tiền tìm các mức như $1.00, $99.99, $499.99 vốn có thể gợi ý việc test thẻ hoặc né quy tắc, nhưng không phù hợp lắm với giao dịch phúc lợi
• Khi kết hợp đột biến theo merchant, giao dịch ngoài khung giờ quen thuộc và các cột suy ra từ window function, có thể chấm điểm giao dịch bằng nhiều tín hiệu và rút ngắn chu kỳ lặp từ vài tuần xuống vài giờ

---

Các mẫu SQL để tìm dấu hiệu gian lận trong dữ liệu giao dịch

• Phát hiện gian lận thường bắt đầu không phải từ machine learning hay graph database mà từ bảng và join đúng cách, cùng với SQL để tìm ra các kiểu giao dịch bất thường
• Có thể áp dụng cho dữ liệu có dòng tiền và log để lại như thẻ tín dụng, yêu cầu thanh toán y tế, thương mại điện tử, POS, hay các chương trình trợ cấp của chính phủ
• Với một bộ dữ liệu mới, thường sẽ xây dần các mẫu theo thứ tự velocity, impossible travel, bất thường về số tiền, tập trung theo merchant, khung giờ bất thường, tín hiệu dựa trên window function

1. Velocity: quá nhiều giao dịch trong thời gian ngắn

• Khi ai đó muốn nhanh chóng rút cạn một thẻ hoặc tài khoản bị đánh cắp, thường sẽ xuất hiện mẫu giao dịch dồn dập trong thời gian ngắn trên cùng một chủ thẻ
• Truy vấn cơ bản sẽ gom các giao dịch trong 30 ngày gần nhất theo giờ và tìm các khoảng mà số giao dịch theo cardholder_id vượt ngưỡng
• Hai tham số điều chỉnh cốt lõi là kích thước cửa sổ thời gian và ngưỡng số lượng giao dịch
  • Có thể chạy song song các phiên bản 1 phút, 5 phút và 1 giờ để so sánh
  • Nhóm test thẻ có thể dồn giao dịch vào chỉ trong vài giây, trong khi nhóm gian lận phúc lợi có thể hoạt động trong nửa ngày, nên thang thời gian sẽ khác nhau
• Người dùng hợp lệ cũng có thể vượt ngưỡng
  • Người vận hành máy bán hàng tự động
  • Người nạp số lượng lớn thẻ trả trước
  • Sau vòng khám phá đầu tiên, sẽ cần danh sách trắng cho các đối tượng false positive như vậy
• Cách dùng sliding window có thể tính số giao dịch trong 5 phút gần nhất bằng COUNT(*) OVER (...) RANGE BETWEEN INTERVAL '5 minutes' PRECEDING AND CURRENT ROW
• QUALIFY hoạt động trên Snowflake, BigQuery, Databricks, Teradata
  • Với Postgres, cần bọc toàn bộ truy vấn trong CTE rồi lọc ở bên ngoài

2. Impossible travel: di chuyển bất khả thi về mặt vật lý

• Nếu một thẻ thanh toán ở Chicago rồi 7 phút sau lại thanh toán ở Los Angeles, rất có thể một trong hai giao dịch là giả
• Mẫu này là tín hiệu rất mạnh để phát hiện thẻ bị sao chép, vì gần như không có lý do hợp lệ nào để cùng một thẻ xuất hiện ở hai nơi xa nhau chỉ trong vài phút
• Truy vấn dùng LAG() để lấy thời gian và vị trí của giao dịch ngay trước đó, rồi tính khoảng cách và thời gian giữa vị trí hiện tại với vị trí trước đó
• haversine là hàm tính great-circle distance
  • Hầu hết các data warehouse đều có sẵn
  • Nếu không có thì cũng là loại hàm có thể tự viết được
• Ngưỡng ví dụ là 600mph
  • Vì tốc độ hành trình của máy bay phản lực thương mại vào khoảng 575mph, nên đây là mức ngay cả đi máy bay cũng không thể đạt được
  • Nếu hạ xuống 100mph thì có thể bắt được cả các trường hợp di chuyển nhanh trên mặt đất, nhưng cũng sẽ bắt đầu kéo theo các giao dịch hợp lệ của người đi máy bay hoặc cha mẹ chở con đi
• Cùng nhóm này còn có các tín hiệu bổ sung khác
  • Nếu trong 5 phút xuất hiện giao dịch ở hai thành phố xa nhau trong cùng một bang, có thể gợi ý nhóm sao chép thẻ hoạt động cục bộ
  • Nếu trong một giờ xuất hiện giao dịch ở nhiều ZIP code, có thể gợi ý nhóm skimmer đang di chuyển trong một khu vực
  • Giao dịch vượt biên giới trong vòng 10 phút có thể là tín hiệu của nhóm quốc tế

3. Amount anomalies: giao dịch bất thường ở các mức tiền cụ thể

• Trong gian lận có những mẫu số tiền xuất hiện thường xuyên nhưng lại hiếm trong hành vi sử dụng bình thường
• Ví dụ điều kiện có thể tìm các khoảng tiền sau
  • $1.00, $5.00, $10.00
  • từ $99.50 trở lên nhưng nhỏ hơn $100.00
  • từ $499.50 trở lên nhưng nhỏ hơn $500.00
• Các khoản tiền đô la tròn nhỏ thường là tín hiệu của test thẻ
  • Đây là quy trình kiểm tra xem các số thẻ lấy từ kho dữ liệu thẻ bị rò rỉ có còn hoạt động hay không trước khi đem bán lại
  • Rất hiếm khi chủ thẻ thực sự mua một món đồ có giá đúng $1.00
  • Cà phê thường là $4.73, đổ xăng thường là $52.81, chứ ít khi là số được làm tròn chính xác
• Các khoản tiền ngay dưới ngưỡng lại mang ý nghĩa khác
  • $99.99 có thể là cách né mốc $100 nơi nhiều nơi bắt đầu yêu cầu kiểm tra giấy tờ tùy thân
  • $499.99 có thể là cách né hạn mức ATM trong ngày là $500
  • Đây là tín hiệu cho thấy người giao dịch biết quy tắc và cố tình giữ ở ngay dưới ngưỡng
• Với giao dịch phúc lợi, mẫu số tiền làm tròn không hữu ích lắm
  • Phúc lợi không được test theo cùng cách như thẻ
  • Thông thường tín hiệu quan trọng hơn là người nhận trùng lặp

4. Suspicious merchants: tập trung bất thường theo từng merchant

• Nếu một đầu đọc thẻ, như đầu đọc ở trạm xăng, bị nhiễm skimmer thì nó có thể dẫn đến không chỉ một mà là hàng chục vụ gian lận
• Mọi thẻ dùng đầu đọc đó trong vài tuần đều có thể đã bị đưa vào cơ sở dữ liệu của ai đó
• Từ góc nhìn merchant, điều này xuất hiện dưới dạng số lượng thẻ không liên quan đến nhau tăng mạnh hơn bình thường trong thời gian ngắn, và cả số tiền giao dịch cũng tăng lên
• Một ví dụ ngưỡng đơn giản là gom theo merchant và theo giờ trong 7 ngày gần nhất để tính
  • số lượng thẻ duy nhất
  • tổng số giao dịch
  • tổng giá trị giao dịch
  • rồi tìm các khung giờ mà số thẻ duy nhất vượt 20 và tổng giá trị vượt $5000
• Ngưỡng tĩnh có vấn đề về hiệu chỉnh theo quy mô
  • Costco có thể vượt ngưỡng này trong 90 giây
  • Một hiệu sách cũ thì gần như không bao giờ vượt
• Cách tốt hơn là so sánh từng merchant với baseline lịch sử của chính nó
  • Gom giao dịch trong 60 ngày gần nhất theo giờ
  • Tính số lượng thẻ duy nhất trung bình của mỗi merchant dựa trên 168 bucket giờ lịch sử
  • Tìm các khoảng mà số lượng thẻ duy nhất hiện tại vượt quá 3 lần mức trung bình lịch sử
• 168 bucket giờ tương ứng với các khoảng theo giờ trong 7 ngày trước
  • Vì tính mùa vụ theo ngày và theo tuần rất quan trọng
  • Cùng một quán cà phê nhưng 2 giờ chiều thứ Ba và 9 giờ sáng thứ Bảy sẽ có baseline khác nhau
• Có thể dùng gấp 3 lần bình thường làm điểm khởi đầu
  • Đủ lỏng để không tạo ra quá nhiều cảnh báo
  • Nhưng vẫn đủ chặt để bắt được các khung giờ thực sự bất thường

5. Off-hours: giao dịch ngoài khung giờ sử dụng quen thuộc của cá nhân

• Hầu hết mọi người đều có thói quen chi tiêu
• Nếu một người làm việc từ 9 giờ đến 5 giờ bỗng nhiên bắt đầu đổ xăng lúc 3 giờ sáng, có thể thẻ của họ đang bị người khác dùng hoặc họ đang đi du lịch
• Việc có đang đi du lịch hay không có thể được kiểm tra thêm bằng các tín hiệu khác
• Truy vấn sẽ tính số giao dịch theo từng chủ thẻ và từng giờ trong 90 ngày gần nhất, rồi chỉ công nhận những giờ có từ 2 giao dịch trở lên là khung giờ quen thuộc
• Sau đó, nếu thời điểm của giao dịch mới nằm ngoài khoảng earliest_hour đến latest_hour của chủ thẻ đó thì sẽ bị phát hiện
• Điều kiện “có từ 2 giao dịch trong khung giờ đó trở lên” trong truy vấn bên trong là rất quan trọng
  • Nó ngăn việc một lần đổ xăng lúc đêm khuya tình cờ từ 3 tháng trước bị tính vào khung giờ quen thuộc
  • Nó điều chỉnh baseline theo thói quen thực tế thay vì chỉ dựa vào “đã từng xảy ra một lần”
• Nhược điểm là cần dữ liệu lịch sử
  • Tài khoản mới sẽ không có baseline
  • Với tài khoản mới, có thể dùng mẫu khung giờ của toàn bộ người dùng hoặc bỏ qua mẫu này cho đến khi tài khoản tích lũy đủ vài tháng dữ liệu

6. Kết hợp tín hiệu bằng window function

• Các mẫu dùng window function không hẳn là một loại gian lận riêng, mà là bước chuẩn bị để biến năm mẫu phía trên thành các tín hiệu có thể kết hợp được
• Có thể tạo sẵn các cột suy ra cho từng giao dịch như sau
  • thời gian đã trôi qua kể từ giao dịch trước: timestamp - LAG(timestamp)
  • merchant có thay đổi hay không: so sánh merchant_id trước đó với merchant_id hiện tại
  • tổng số tiền tích lũy trong 24 giờ gần nhất: SUM(amount) OVER (...)
  • đây là giao dịch thứ mấy trong ngày: ROW_NUMBER()
• Khi materialize các cột này, quy tắc gian lận sẽ rút gọn thành các biểu thức filter đơn giản
• Có thể tìm nhóm test thẻ bằng các điều kiện
  • là giao dịch thứ 5 trở đi trong ngày
  • cách giao dịch trước dưới 60 giây
  • merchant khác với giao dịch trước đó
• Nếu một giả thuyết gian lận mới có thể được biểu diễn bằng filter SQL thay vì một ticket kỹ thuật, chu kỳ lặp sẽ giảm từ vài tuần xuống vài giờ
• Kết quả là có thể bắt được nhiều gian lận hơn và nhanh hơn

Cách dùng các mẫu cùng nhau

• Không có mẫu nào đủ tốt nếu dùng riêng lẻ
• Mỗi mẫu đều có giới hạn rõ ràng
  • Velocity có false positive như người vận hành máy bán hàng tự động
  • Di chuyển bất khả thi về mặt địa lý sẽ bỏ sót các vụ gian lận xảy ra trong cùng một vùng đô thị lớn
  • Bất thường về số tiền hoạt động kém ngoài ngữ cảnh test thẻ
  • Quy tắc khung giờ bất thường cần dữ liệu lịch sử
• Trong thực tế, cách hiệu quả là chạy tất cả các mẫu và chấm điểm từng giao dịch bằng nhiều tín hiệu
• Giao dịch trúng 3 hoặc 4 tín hiệu thì gần như luôn là gian lận
• Giao dịch chỉ trúng 1 tín hiệu có thể chỉ là hành vi khác thường nhưng hợp lệ của chủ thẻ đang đi du lịch
• Nếu mới bắt đầu làm phát hiện gian lận thì nên bắt đầu từ Velocity
  • Nó làm lộ ra một lượng gian lận hữu ích
  • Bắt nhầm hoạt động hợp lệ tương đối ít
  • Chi phí chạy cũng thấp
• Nếu đã có đủ từ 1 đến 5 thì khoản đầu tư tiếp theo nên là các cột thô dựa trên window function
  • Chỉ cần tạo một lần là mọi analyst trong nhóm đều dùng được
  • Việc thêm mẫu gian lận tiếp theo sẽ không còn là một dự án riêng nữa

Những điểm cần lưu ý

• Xử lý NULL

  • Bảng giao dịch thực tế thường không dùng NULL gọn gàng như trong sách nhập môn SQL
  • Nhiều hệ thống legacy dùng giá trị sentinel như 9999-12-31 cho “không có ngày kết thúc”, hoặc 0001-01-01 cho “không có ngày bắt đầu”
  • Nếu lọc bằng IS NULL thì có thể âm thầm bỏ sót các dòng như vậy
  • Cần kiểm tra quy ước của từng bảng trước khi viết mệnh đề WHERE

• False positive

  • Mọi quy tắc đều có thể bắt nhầm các chủ thẻ thật đang có hành vi lạ nhưng hợp pháp
  • Các trường hợp bị gắn cờ cần người thật xem xét
  • Cần một vòng phản hồi để điều chỉnh ngưỡng dựa trên cái gì là gian lận thật và cái gì không phải
  • Tự động chặn chỉ với một quy tắc đơn lẻ có thể khiến mất khách hàng

• Quyền riêng tư

  • Nếu dữ liệu có PII thì phải tuân thủ chính sách sử dụng dữ liệu áp dụng cho nó
  • Nên làm việc trước trên dữ liệu đã khử định danh hoặc dữ liệu mẫu, rồi chỉ dùng dữ liệu production sau khi được phê duyệt

• Chi phí

  • Window function trên các partition lớn không hề rẻ
  • Nên lọc phạm vi ngày trước rồi mới áp dụng window function
  • Nếu chạy LAG() trước trên 2 năm giao dịch của toàn bộ tập dữ liệu rồi mới thêm WHERE, bạn có thể tiêu tốn rất nhiều ngân sách credit của data warehouse

[kaydash]

Đây là phương pháp từng được mượn dùng trước đây trong hệ thống kế toán ngân hàng và hệ thống kênh.

[GN⁺]

Ý kiến trên Hacker News

• Tiêu chí cho rằng chủ thẻ thực sự hiếm khi mua món có giá đúng $1.00 dường như còn tùy vào cách người bán đặt giá chứ nhỉ
  Khi ai đó mua gì đó trên website để thử thẻ tín dụng ăn cắp, người mua không thể tự chọn giá tùy ý
  Ngoài ra, cách nghĩ này có vẻ quá lệ thuộc vào bối cảnh như ở Mỹ, nơi thuế không được tính sẵn vào giá; ở nhiều khu vực khác thì mức giá tròn là chuyện rất phổ biến
  Cũng nghi ngờ liệu các tiêu chí khác trong bài có hoạt động tốt không. Ví dụ, nếu gắn cờ những người giao dịch ngoài khung giờ thường lệ trong vòng 90 ngày gần đây, trong khi trước đó họ thường có hơn 2 giao dịch ở khung giờ đó, thì có khi nửa số người sẽ bị dính chăng
  Không rõ đây là bài viết đang cố giản lược quá mức một lĩnh vực chuyên môn phức tạp thành các truy vấn SQL đơn giản, hay hoàn toàn chỉ là suy đoán và bịa đặt. Câu “sáu mẫu SQL dùng để bắt gian lận giao dịch” và “không có gì ở đây là điều tôi thực sự từng làm hoặc từng thấy” mâu thuẫn với nhau

  • “Giao dịch ngoài khung giờ thường lệ” có vẻ là một tiêu chí khá cơ bản
    Bình thường tôi không mua xăng, cà phê hay đồ ăn vặt lúc 2 giờ sáng, nhưng nếu rất hiếm khi làm vậy thì khả năng cao là vì một tình huống khẩn cấp cá nhân, và lúc đó tôi không muốn phải gọi cho ngân hàng
    Tôi biết bọn trộm cơ hội cũng có thể hoạt động vào giờ đó, nhưng chi phí false positive rõ ràng là có thật
  • Còn tệ hơn thế. Theo kinh nghiệm của tôi, cà phê thường có giá tròn số, và cũng có người cố tình bơm xăng cho đúng một số tiền tròn
    Ngoài ra còn có các cây xăng yêu cầu những mức tiền định sẵn như 10, 20, 50 euro
  • Có lần một đêm ở quán bar tôi đói bụng nên định mua một gói khoai tây chiên, nhưng mức thanh toán tối thiểu bằng thẻ là £5, nên tôi bảo cứ tính cho tôi £5 luôn
    Thế là thẻ bị khóa vì bị nghi là gian lận, khá là bực mình. Đó không phải chuyện tôi muốn xử lý trong tình trạng say lúc 2 giờ sáng
    Có khi nó đã bảo vệ tôi khỏi chính bản thân mình, nhưng vẫn rất phiền
  • Không biết giờ còn dùng không, nhưng trước đây có nơi như khách sạn hay công ty thuê xe dùng giao dịch $1.00 để kiểm tra tính hợp lệ của thẻ tín dụng trước khi đặt phòng hay thuê xe
  • Cách này có thể bị lách dễ dàng chỉ bằng cách thêm một chút dao động ngẫu nhiên vào giao dịch thử, và cũng có thể được cải thiện dễ dàng bằng phân tích thống kê tử tế
    Và kiểu nhận diện mẫu heuristic như thế này, nơi không ai kỳ vọng độ chính xác gần 100%, chẳng phải đúng là lĩnh vực AI nên làm tốt sao

• Tiêu chí “qua biên giới trong 10 phút là có tổ chức quốc tế” cũng có thể áp vào cả những người bình thường sống ở vùng giáp biên châu Âu
  Ngay cả khi loại trừ giao dịch thẻ không hiện diện, nó vẫn dường như đang giả định sai rằng mọi vị trí người bán đều được cấu hình chính xác, mọi giao dịch đều diễn ra tại cửa hàng vật lý, không có bán hàng lưu động, và mọi giao dịch đều được xử lý trực tuyến

  • Vài tuần trước khi tôi từ Mỹ sang Canada thì chắc cũng khoảng 10 phút

• Đọc đến cuối sẽ thấy đây là một bài tư vấn rỗng tuếch và tự mâu thuẫn. Gần như chắc chắn là bài viết do LLM tạo ra
  Bài viết nói “đội của bạn” không nên phụ thuộc vào bất kỳ mẫu nào, nhưng lại nói riêng mẫu 1 cũng có thể phơi bày “một lượng gian lận hữu ích”
  Cũng có những câu kỳ quặc như “mọi nhà phân tích trong nhóm sẽ dùng chúng, tức là window function, và việc thêm mẫu gian lận tiếp theo không còn là một dự án nữa”
  Rồi lại có một đoạn bàn luận ít liên quan rằng lọc IS NULL có thể không được áp dụng, dù gần như mọi ví dụ đều không dùng IS NULL, còn ví dụ duy nhất có dùng thì lại ở ngữ cảnh khác
  Nhìn chung đây là một bài chất lượng thấp và quá dài

• Hacker News, chuyện này cần được chỉ ra
  “Fixel Smith” là một nhân vật do AI tạo ra, và bài viết gần như không liên quan đến phân tích gian lận. Cái tên này còn được dùng cho gần như mọi thân phận có thể tưởng tượng ra: nhạc sĩ (1), tiểu thuyết gia (2), nhà phân tích gian lận (3), influencer (4)
  Bài này được hơn 220 điểm và hơn 70 bình luận, thế mà gần như chẳng ai nhận ra nó khá giả, và cũng không ai nhận ra đây là một nhân vật do AI tạo ra

  1. https://www.amazon.it/Forged-Soundtrack-Explicit-Fixel-Smith...

  2. https://fixelsmith.com

  3. https://analytics.fixelsmith.com/

  4. https://www.instagram.com/fixeltales/

  • Có vẻ gần đây Hacker News mắc phải thói quen khó chịu là đẩy lên những bài đăng AI chất lượng thấp kiểu này
    Tôi tự hỏi liệu làn sóng AI này đang phơi bày một sự thật khó chịu về khả năng phán đoán của cộng đồng, hay chỉ là thất bại của các cơ chế phòng vệ hiện có nên chỉ cần thay đổi chúng là được
  • Tôi đang xem bài trên điện thoại và chỉ liếc qua bình luận. Không phải lúc nào cũng dễ phân biệt bài nào do AI tạo hay đã được biên tập, nhưng ở đây chỉ cần nhìn mấy câu trích dẫn là đã thấy rõ ngay từ cái nhìn đầu tiên
    Nếu giả sử mọi bình luận đều được viết với thiện chí, thì việc ngay cả ở đây mà mức độ hiểu biết về AI vẫn thấp như vậy là khá đáng lo
  • Nhìn sơ qua cũng thấy hoặc đây là một cá nhân viết cực nhiều, hoặc là bot
    Mảng tiểu thuyết thì hầu như không liên quan đến các bài phân tích, còn các bài phân tích lại có vẻ mang văn phong LLM, nên tổng thể rất đáng ngờ. Nghĩ đến việc chủ đề bài gốc là gian lận thì cũng khá mỉa mai
  • Nếu hầu hết mọi người có thói quen điều tra tác giả của thứ họ đọc thì tôi còn thấy ngạc nhiên hơn
    Thành thật mà nói, tôi thường còn chẳng nhìn tên tác giả, chứ đừng nói đến các phần khác của website
  • Đây rõ ràng là một bài viết có thật. Đương nhiên nó trông như do LLM viết, nhưng nếu lời chỉ trích tệ nhất dành cho bài chỉ là nó trông giống LLM viết, thì có khi đó lại không phải chỉ trích thực chất
    Không rõ nội dung có bịa hay không, nhưng vẫn có thể phê bình chính nội dung bài viết mà không cần suy đoán nó do LLM viết hay là tiểu thuyết. Nó có nhiều lỗi cụ thể hơn thế rất nhiều

• Chúng tôi đang phát triển framework bảo mật mã nguồn mở tirreno
  Tôi thấy cách tiếp cận được mô tả ở đây đáng nghi. Ví dụ, di chuyển bất khả thi là một kỹ thuật hợp lệ và được dùng rộng rãi, nhưng nó liên quan đến hành vi người dùng trực tuyến dựa trên địa chỉ IP
  Trong tirreno có quy tắc riêng cho trường hợp IP rõ ràng đến từ Apple Relay hoặc VPN/Tor, và đó là các cờ riêng biệt
  Tôi cho rằng một phần hoặc toàn bộ ví dụ là do LLM tạo ra. Ngữ cảnh bị trộn lẫn, và trong thanh toán bằng thẻ thực tế không có nơi nào thu thập GPS hàng loạt cả

  1. https://github.com/tirrenotechnologies/tirreno

• Cái này giống kiểu “logic dựa trên luật lệ được mã hóa thành truy vấn SQL mà không có dữ liệu chứng minh” hơn
  Có rất nhiều ngưỡng, nhưng không có dữ liệu nào cho thấy những ngưỡng đó thực sự có ý nghĩa

• Khẳng định kiểu “phát hiện gian lận trong dữ liệu giao dịch chủ yếu là SQL, chứ không phải machine learning hay graph database hay bất cứ thứ gì Gartner đang thổi lên năm nay” chỉ có thể hợp lý nếu đang nói đến toàn bộ công việc program integrity
  Nếu cách làm đơn giản và thô hơn giải được bài toán thì có thể nó tốt hơn
  Khách hàng fintech thường muốn biết liệu giao dịch đang diễn ra ngay lúc này có phải gian lận hay không, và họ muốn câu trả lời trong vài mili giây cho dữ liệu nhiều chiều. Đây là loại bài toán ở quy mô mà cơ sở dữ liệu quan hệ khó đáp ứng các ràng buộc thời gian thực như vậy, nên thay vào đó nó được dùng cho các mục đích khác như nạp dữ liệu lịch sử
  Đó là lý do có cơ sở dữ liệu in-memory, engine xử lý dòng và cả machine learning
  Dù vậy, một số điểm của tác giả vẫn hợp lý, đặc biệt là vấn đề xử lý cảnh báo nhiều nhiễu là một bài toán phổ quát vượt ra ngoài kỹ thuật hiệu năng, nên tôi mong chờ bài tiếp theo

  • Theo kinh nghiệm của tôi, điều được mô tả chính xác hơn nên gọi là ngăn chặn gian lận chứ không phải phát hiện gian lận. Trong một hệ thống trưởng thành thì cả hai cùng tồn tại và bổ sung cho nhau
    Ở phần ngăn chặn, luôn bị ràng buộc bởi yêu cầu độ trễ, dữ liệu sẵn có và bức tranh không hoàn chỉnh về hành vi người dùng. Bạn dùng machine learning và luật để đưa ra quyết định nhanh, xử lý phần lớn trường hợp, nhưng với những ràng buộc đó thì không thể chặn chính xác mọi gian lận
    Phát hiện thì xử lý phần hậu quả sau đó. Thường sẽ có đội ngũ phân tích xem xét các giao dịch đã được chấp thuận để tìm dấu hiệu gian lận. Điều này đặc biệt quan trọng với các loại gian lận không có tín hiệu bên ngoài như chargeback hay khiếu nại của khách hàng. Platform integrity là một ví dụ, và các hệ thống chống rửa tiền trong fintech cũng phải chủ động đi tìm gian lận
    Lý do hai thứ này bổ sung cho nhau là vì các giao dịch được phát hiện sẽ trở thành label để huấn luyện và đánh giá mô hình ngăn chặn tiếp theo

• Bài viết nói rằng nếu thẻ được quẹt ở Chicago rồi 7 phút sau lại được quẹt ở Los Angeles thì một trong hai giao dịch là giả; tôi tò mò không biết điều đó hoạt động ra sao với mua sắm trực tuyến
  Nếu tôi ngồi trên ghế sofa mua đồ trên Amazon thì địa chỉ sẽ được ghi nhận ở đâu?
  Và cũng có những trường hợp ranh giới như vợ chồng dùng chung tài khoản online, rồi một người đang đi du lịch mua hàng bằng thông tin thẻ đã lưu sẵn

  • Việc quẹt, cắm hoặc chạm thẻ là giao dịch có hiện diện thẻ. Còn nhập số thẻ như khi mua sắm online là giao dịch không hiện diện thẻ
    Nhà bán lẻ và ngân hàng có thể phân biệt được sự khác nhau này
  • Có thể phân biệt qua metadata của giao dịch. Tôi từng làm ở công ty thẻ tín dụng
  • Tôi biết hệ thống có phân biệt giữa thẻ hiện diện và giao dịch không hiện diện thẻ

• Ý rằng “cách này không hoạt động cho đến khi tích đủ lịch sử, và tài khoản mới thì không có baseline” là một yếu tố trải nghiệm khách hàng bị đánh giá thấp
  Nếu tôi là khách hàng mới, hoặc thể hiện một kiểu hành vi mới, thì việc thẻ bị từ chối khiến tôi thấy phần mềm đang làm tốt việc của nó
  Nhưng nếu tôi đã có lịch sử trước đó mà chính tôi xác thực, vậy mà giao dịch vẫn bị từ chối, thì tôi sẽ bực vì một thuật toán ngây ngô và hoang tưởng

  • Động cơ của ngân hàng là giảm gian lận
    Giao dịch gian lận cuối cùng sẽ khiến ngân hàng phải gánh lỗ do hủy bỏ hoặc hoàn tiền. Còn giao dịch bị từ chối chỉ tạo ra một khách hàng bực bội, mà khách hàng thì than phiền xong cũng nhanh quên. Vì vậy gánh nặng của chi phí bị ngoại hóa chuyển sang phía khách hàng
    Do đó ngân hàng có động cơ mắc lỗi theo hướng thận trọng hơn, và sẵn sàng từ chối giao dịch ngay cả khi có false positive

• Chẳng phải cốt lõi của machine learning là học những quy tắc kiểu này từ dữ liệu sao
  Tôi nghĩ hướng đúng là dùng mô hình machine learning để tìm ra các mẫu tương ứng với gian lận, rồi đánh giá xem trong đó có cái nào hợp lý không. Làm vậy còn có thể phát hiện giả thuyết mới

  • Những gì không thể giải thích được và không thể cải tiến lặp lại theo cách quyết định được thì quá rủi ro cho việc từ chối giao dịch tài chính
    Nhà phân tích con người phải có khả năng giải thích cho đội compliance trong một email 5 phút vì sao một giao dịch cụ thể bị từ chối, và cần làm gì khác đi để tránh quyết định bất lợi đó
    Với machine learning, sửa được một vấn đề thì thường lại sinh ra hai vấn đề mới chưa lộ rõ. Về mặt hồi quy hoặc tác dụng phụ không lường trước khi mọi thứ thay đổi theo thời gian, SQL thường ít gây bất ngờ hơn

[aliveornot]

Tôi thắc mắc “số tiền tròn” là gì.. hóa ra là rounded.

[xguru]

Không hiểu sao lại dịch như vậy nữa T_T, tôi đã sửa lại rồi.