- Phát hiện gian lận thường bắt đầu không phải từ machine learning mà từ việc nắm đúng bảng và phép join, rồi dùng SQL để tìm các mẫu bất thường về tốc độ, vị trí, số tiền, người bán và khung giờ
- Velocity dùng để tìm các cụm giao dịch dồn dập của cùng một chủ thẻ trong thời gian ngắn, và cần điều chỉnh cửa sổ thời gian, ngưỡng cùng whitelist để giảm dương tính giả
- Impossible travel dùng
LAG() và tính khoảng cách để bắt các trường hợp di chuyển bất khả thi về mặt vật lý, như thanh toán ở Chicago rồi 7 phút sau lại ở Los Angeles, đây là 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 có thể gợi ý hành vi test thẻ hoặc né quy tắc, nhưng không phù hợp lắm với các giao dịch trợ cấp/phúc lợi
- Khi kết hợp bùng nổ theo người bán, giao dịch ngoài khung giờ thường lệ và các cột suy diễn 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à phép join đúng, cùng với SQL để tìm 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 di chuyển và có 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 phúc lợi do chính phủ hỗ trợ
- Với một bộ dữ liệu mới, thường sẽ xây dựng các mẫu theo thứ tự velocity, impossible travel, bất thường về số tiền, tập trung theo người bán, 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 đó cố nhanh chóng rút cạn một thẻ hay tài khoản bị đánh cắp, sẽ xuất hiện mẫu giao dịch dồn vào cùng một chủ thẻ trong thời gian ngắn
- Truy vấn cơ bản sẽ gom giao dịch 30 ngày gần nhất theo từng 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 quan trọng là kích thước cửa sổ thời gian và ngưỡng số giao dịch
- Có thể chạy song song các phiên bản 1 phút, 5 phút, 1 giờ để so sánh
- Các nhóm test thẻ có thể dồn giao dịch chỉ trong vài giây, còn các nhóm gian lận phúc lợi có thể hoạt động trải dài nửa ngày, nên quy mô rất khác nhau
- Người dùng hợp lệ cũng có thể vượt ngưỡng
- Người vận hành quản lý 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á ban đầu, cần có whitelist cho các đối tượng dương tính giả 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 ở truy vấn ngoài
2. Impossible travel: di chuyển bất khả thi về mặt vật lý
- Nếu một thẻ được thanh toán ở Chicago rồi 7 phút sau lại thanh toán ở Los Angeles, thì khả năng cao một trong hai giao dịch là giả
- Mẫu này là tín hiệu mạnh để bắt thẻ bị sao chép, vì hầu như không có lý do hợp lệ nào để 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 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 khoảng cách cung lớn (great-circle distance)
- Hầu hết các data warehouse đều có sẵn
- Nếu không có thì cũng có thể tự viết ở mức tương đối đơn giản
- Ngưỡng ví dụ là 600mph
- Tốc độ bay hành trình của máy bay phản lực thương mại vào khoảng 575mph, nên mức này có nghĩa là ngay cả đi máy bay cũng không thể đạt được
- Nếu hạ xuống 100mph thì có thể bắt thêm các trường hợp di chuyển nhanh trên mặt đất, nhưng cũng sẽ bắt đầu dính cả những giao dịch hợp lệ như khách đang đi máy bay hoặc phụ huynh chở con đi đâu đó
- Cùng họ tín hiệu này còn có thể mở rộng thêm
- Giao dịch ở hai thành phố xa nhau trong cùng một bang trong vòng 5 phút có thể gợi ý nhóm sao chép hoạt động khu vực
- Giao dịch ở nhiều mã ZIP trong vòng một giờ có thể gợi ý nhóm skimmer đang hoạt động trong một vùng
- 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: bất thường ở các mức số tiền cụ thể
- Trong gian lận thường có những mẫu số tiền xuất hiện nhiều, nhưng lại hiếm gặp ở hành vi sử dụng bình thường
- Ví dụ điều kiện sẽ tìm các khoảng số tiền sau
$1.00, $5.00, $10.00- Từ
$99.50 trở lên và dưới $100.00
- Từ
$499.50 trở lên và dưới $500.00
- Các số tiền nguyên đô nhỏ thường là tín hiệu của test thẻ
- Đây là quy trình kiểm tra xem số thẻ lấy từ dump thẻ còn hoạt động hay không trước khi đem bán lại
- Chủ thẻ thật hiếm khi mua đúng món hàng giá chính xác
$1.00
- Cà phê thường là
$4.73, đổ xăng có thể là $52.81, tức là ít khi ra số tròn hoàn toàn
- Các mức ngay dưới ngưỡng lại mang ý nghĩa khác
$99.99 có thể là cách né mốc $100 vốn ở nhiều nơi 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 hằng ngày $500- Đây là tín hiệu cho thấy người giao dịch biết quy tắc và cố tình ở ngay bên dưới ngưỡng
- Với giao dịch phúc lợi, mẫu số tiền tròn thường không giúp được nhiều
- Phúc lợi không bị test thẻ theo cùng cách
- Thường thì người nhận trùng lặp mới là tín hiệu quan trọng hơn
4. Suspicious merchants: tập trung bất thường theo người bán
- Nếu một đầu đọc thẻ ở trạm xăng chẳng hạn bị nhiễm skimmer, hậu quả có thể không chỉ là một giao dịch mà là hàng chục giao dịch gian lận
- Tất cả thẻ từng dùng đầu đọc đó trong vài tuần có thể đã bị đưa vào cơ sở dữ liệu của ai đó
- Từ góc nhìn người bán, điều này sẽ hiện ra dưới dạng số lượng thẻ không liên quan tăng mạnh hơn bình thường trong thời gian ngắn, đồng thời tổng số tiền giao dịch cũng tăng
- Một ví dụ ngưỡng đơn giản là gom theo người bán và theo giờ trong 7 ngày gần nhất rồi tính
- Số thẻ duy nhất
- Tổng số giao dịch
- Tổng giá trị giao dịch
- Tìm các khung giờ mà số thẻ duy nhất vượt 20 và tổng tiền vượt
$5000
- Ngưỡng tĩnh có vấn đề về chuẩn hóa theo quy mô
- Costco có thể vượt ngưỡng này trong 90 giây
- Một hiệu sách cũ gần như chẳng bao giờ vượt
- Cách tốt hơn là so sánh mỗi người bán với đường cơ sở lịch sử của chính họ
- Gom giao dịch 60 ngày gần nhất theo từng giờ
- Tính số thẻ duy nhất trung bình của từng người bán dựa trên 168 bucket giờ trong quá khứ
- Tìm các khoảng mà số 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 là 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
- Làm điểm khởi đầu thì có thể dùng ngưỡng gấp 3 lần bình thường
- Đủ 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ật sự bất thường
5. Off-hours: giao dịch ngoài khung giờ sử dụng thường lệ của từng cá nhân
- Hầu hết mọi người đều có thói quen chi tiêu nhất định
- Nếu một người làm việc 9 giờ đến 5 giờ bỗng nhiên bắt đầu đổ xăng lúc 3 giờ sáng, có thể thẻ đang bị người khác sử dụng hoặc người đó đang đi du lịch
- Việc có phải đ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, sau đó chỉ công nhận những khung giờ có từ 2 giao dịch trở lên là khung giờ thường lệ
- Sau đó, nếu thời gian của giao dịch mới nằm ngoài khoảng
earliest_hour và latest_hour của chủ thẻ đó thì sẽ bị phát hiện
- Điều kiện “ít nhất 2 giao dịch trong khung giờ đó” ở truy vấn bên trong rất quan trọng
- Nó ngăn trường hợp một lần đổ xăng đêm khuya ngẫu nhiên cách đây 3 tháng bị tính là khung giờ bình thường
- Tức là baseline được căn theo thói quen thực tế, chứ không phải “từng xảy ra một lần”
- Điểm yếu là cần dữ liệu lịch sử
- Tài khoản mới sẽ chưa 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 tới 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ựa trên 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ó thể tạo sẵn các cột suy diễn theo từng giao dịch như
- Thời gian trôi qua từ giao dịch trước:
timestamp - LAG(timestamp)
- Có đổi người bán hay không: so sánh
merchant_id trước đó với merchant_id hiện tại
- Tổng 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ẽ được rút gọn thành những biểu thức lọc đơn giản
- Có thể tìm nhóm test thẻ bằng các điều kiện sau
- Từ giao dịch thứ 5 trong ngày trở đi
- Cách giao dịch trước chưa đến 60 giây
- Người bán khác với giao dịch ngay trước đó
- Nếu một giả thuyết gian lận mới có thể biểu diễn bằng bộ lọc SQL thay vì phải tạo engineering ticket, 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ó thể sinh dương tính giả 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 gian lận diễn ra trong cùng một vùng đô thị lớn
- Bất thường về số tiền không phù hợp lắm ngoài bối 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 mỗi giao dịch qua nhiều tín hiệu
- Giao dịch trúng ba hoặc bốn tín hiệu thì gần như luôn là gian lận
- Giao dịch chỉ trúng một tín hiệu có thể đơn giản là cách dùng khác thường nhưng hợp lệ của một chủ thẻ đang đi du lịch
- Nếu mới bắt đầu làm phát hiện gian lận, nên bắt đầu từ Velocity
- Nó giúp 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, 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 mới sau đó sẽ không còn là một dự án riêng biệt
Những điểm cần lưu ý
-
Xử lý NULL
- Bảng giao dịch thực tế thường không “sạch đẹp” như giáo trình SQL và nhiều khi không dùng
NULL
- 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 chỉ 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 cụ thể rồi mới viết mệnh đề
WHERE
-
Dương tính giả
- Mọi quy tắc đều có thể bắt nhầm những chủ thẻ thật có hành vi bất thường nhưng hợp pháp
- Các trường hợp bị gắn cờ cần có người xem xét thủ công
- Cần một vòng phản hồi để điều chỉnh ngưỡng dựa trên cái nào là gian lận thật và cái nào không
- Nếu tự động chặn chỉ bằng một quy tắc đơn lẻ, bạn có thể làm 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 tương ứng
- Nên làm việc trước trên dữ liệu đã khử định danh hoặc dữ liệu mẫu, và 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 trước theo phạm vi ngày tháng rồi mới áp dụng window function
- Nếu chạy
LAG() trước trên toàn bộ 2 năm dữ liệu giao dịch 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
1 bình luận
Ý 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
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
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
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
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
Đọ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 NULLcó thể không được áp dụng, dù gần như mọi ví dụ đều không dùngIS NULL, còn ví dụ duy nhất có dùng thì lại ở ngữ cảnh khácNhì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
https://www.amazon.it/Forged-Soundtrack-Explicit-Fixel-Smith...
https://fixelsmith.com
https://analytics.fixelsmith.com/
https://www.instagram.com/fixeltales/
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
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
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
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
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ả
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
Ở 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
Nhà bán lẻ và ngân hàng có thể phân biệt được sự khác nhau này
Ý 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
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à 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