Stripe Radar rất xuất sắc trong việc của mình: chấm điểm giao dịch ngay khi tiền được chuyển. Nhưng chính khoảnh khắc không có giao dịch mới là nơi vấn đề của chúng tôi xuất hiện.
Chúng tôi cung cấp dùng thử miễn phí 7 ngày. Để bắt đầu, người dùng lưu thẻ nhưng không bị tính phí — về mặt kỹ thuật, đó là một SetupIntent của Stripe, không phải thanh toán. Không có giao dịch nghĩa là không có sự kiện tại thời điểm thanh toán, đồng nghĩa các quy tắc mạnh nhất của Radar không có gì để đánh giá vào thời điểm quan trọng nhất: khi một tài khoản gian lận được tạo và bắt đầu tiêu hao credits dùng thử.
Đây là câu chuyện về cách chúng tôi chuyển từ việc xử lý gian lận thủ công sang vận hành một lớp phòng chống gian lận tự động, liên tục từng phút — xây dựng dựa trên chính sản phẩm của chúng tôi, Zero.
Radar rất tốt. "Tốt" không phải là "hoàn hảo."
Stripe Radar thực sự hiệu quả trong vai trò của mình. Được huấn luyện trên $1 nghìn tỷ USD giao dịch mỗi năm, các mô hình của nó nhận diện thẻ đã từng thấy 92% lần, và Stripe báo cáo Radar giảm gian lận trung bình 32% cho các doanh nghiệp sử dụng.
Nhưng hãy đọc lại con số đó: giảm, không phải loại bỏ. Mức giảm trung bình 32% là rất lớn — nhưng vẫn còn nhiều áp lực gian lận đến với bạn, và Stripe rất thẳng thắn về lý do. Chính họ nói: "giảm số lượng dương tính giả thường làm tăng khả năng gian lận thật lọt qua." Việc lọt này không phải lỗi của mô hình; đó là cái giá phải trả để không chặn khách hàng thật. Mỗi đội chống gian lận đều chủ động chọn mức độ cho phép lọt qua.
Với sản phẩm dẫn dắt bằng dùng thử, lỗ hổng này còn lớn hơn con số tiêu đề — vì phần mạnh nhất của Radar thậm chí không được kích hoạt.
Vì sao một cổng chỉ có thể giảm, không thể loại bỏ
Có một lý do sâu xa khiến một hệ thống kiểm tra tại thời điểm thanh toán chỉ giảm chứ không thể chấm dứt gian lận, và nó không nằm ở mô hình của Stripe — mà ở thời điểm và thông tin. Khi thẻ vừa được thêm vào, khách hàng chưa làm gì cả. Không có lịch sử đăng nhập, không có hành vi sản phẩm, không có mẫu sử dụng để học hỏi — chỉ có thẻ và vài tín hiệu mạng. Radar phải đưa ra quyết định dựa trên lát thông tin mỏng nhất, vào thời điểm ít dữ liệu nhất.
Đó là giới hạn thực sự. Bạn có thể điều chỉnh cổng, nhưng không thể cung cấp dữ liệu chưa tồn tại. Thông tin thực sự phân biệt kẻ lạm dụng với khách hàng chủ yếu chỉ xuất hiện sau khi cổng đã phải quyết định.
Giai đoạn 1: Chữa cháy trong cửa sổ chat
Phản ứng đầu tiên của chúng tôi hoàn toàn thủ công. Khi bị tấn công, ai đó mở cuộc trò chuyện với agent và xử lý trực tiếp: lấy danh sách đăng ký mới, xem thẻ, tìm mẫu, khóa tài khoản thủ công.
Cách này hiệu quả, nhưng không mở rộng được. Mỗi sự cố đều bắt đầu lại từ đầu. Kiến thức — vòng gian lận này trông thế nào, tín hiệu nào đáng tin — chỉ nằm trong đầu một người và một đoạn chat, rồi biến mất khi đóng cửa sổ.
Chúng tôi cũng rút ra bài học đắt giá ở phía khách hàng thật: khi muốn thu hút lại người dùng thật bỏ dở thanh toán, một email gửi nhầm đến địa chỉ gian lận gây hại thực sự — nó xác nhận địa chỉ đó còn hoạt động. Mọi tự động hóa đều phải phân biệt được khách hàng thật và kẻ cài cắm.
Giai đoạn 2: Gia cố cửa trước bằng Radar
Bước tiếp theo là đẩy mọi thứ có thể lên Radar — danh sách chặn và quy tắc tốc độ tại bước thêm thẻ, điều chỉnh theo áp lực thực tế. Đây là bước đi đúng đắn, và nó đã ngăn được các cuộc tấn công thô sơ nhất.
Nhưng hai giới hạn xuất hiện nhanh chóng. Đầu tiên là điều Stripe tự thừa nhận: hệ thống kiểm tra tại thời điểm thanh toán là nút điều chỉnh đánh đổi, không phải bức tường — tăng lên thì chặn cả khách thật, giảm xuống thì gian lận lọt qua nhiều hơn. Thứ hai là đặc thù của dùng thử: 32% chỉ có khi thanh toán, còn dùng thử bằng SetupIntent thì không có gì để chấm điểm. Nếu bạn không bật Radar cho phương thức thanh toán lưu sẵn, hệ thống sẽ không chạy — và kể cả khi bật, chỉ có các quy tắc Block, Allow và 3DS áp dụng cho SetupIntent. Hành động "Review" — cho phép con người xem lại — sẽ không bao giờ được kích hoạt.
Vậy nên lớp mạnh nhất trong hệ thống mặc định lại không hoạt động đúng lúc cần nhất. Radar là cổng ở cửa trước. Chúng tôi cần một tuần tra phía sau.
Giai đoạn 3: Lớp thứ hai, xây trên Zero
Sau khi đăng ký, bức tranh thông tin đảo ngược. Tài khoản bắt đầu để lại dấu vết — và phần giá trị nhất nằm ở hệ thống mà bên xử lý thanh toán không thấy: nhà cung cấp định danh, Clerk.
Chúng tôi cấp quyền truy cập Clerk cho Zero. Clerk biết những điều Stripe không biết: cách tài khoản được tạo, phương thức và email đăng ký, phiên và thiết bị đứng sau, và thời điểm chính xác so với mọi đăng ký khác trong ngày. Stripe biết thẻ. Không hệ thống nào tự nó kể được toàn bộ câu chuyện — nhưng agent có thể đọc cả hai và liên kết dữ liệu giữa chúng. Gian lận mà cổng không thấy sẽ lộ rõ khi so sánh: một tài khoản mới mà định danh đăng nhập không khớp với định danh thanh toán, tạo cách nhau vài phút với một nhóm tài khoản tương tự. Liên kết này là điều cổng kiểm tra tại thời điểm thanh toán không thể làm — nhưng agent giám sát cả hai hệ thống thì làm được.
Dựa trên nền tảng dữ liệu phong phú đó, chúng tôi chạy các tác vụ Zero định kỳ vài phút một lần trên dữ liệu đăng ký và thanh toán trực tiếp. Ba nguyên tắc định hình chúng:
1. Tuần tra, không chỉ kiểm soát. Thay vì chỉ đánh giá một thời điểm, agent quét mọi đăng ký gần đây theo vòng lặp ngắn, liên kết dữ liệu tài khoản và thanh toán để phát hiện tài khoản lọt qua cửa trước.
2. Phân tầng phản hồi theo mức độ tin cậy. Không phải tín hiệu nào cũng xử lý như nhau. Mẫu có độ tin cậy cao sẽ tự động xử lý — tài khoản bị tạm ngưng và hủy dùng thử ngay lập tức, vì hành động này có thể đảo ngược và chậm trễ sẽ gây thiệt hại. Tín hiệu độ tin cậy thấp không bao giờ tự động xử lý; chúng được tổng hợp thành báo cáo cho con người xem xét. Quyết đoán khi an toàn, thận trọng khi chưa chắc.
3. Lưu vết kiểm toán cho con người. Mọi hành động tự động đều ghi lại chính xác tín hiệu kích hoạt, để có thể kiểm tra — và đảo ngược — trong vài giây. Tự động hóa không kiểm toán được là tự động hóa không thể tin cậy.
Chúng tôi cũng áp dụng sự cẩn trọng tương tự cho phía khách hàng thật. Một tác vụ riêng tìm người dùng thật bỏ dở thanh toán và soạn email thu hút lại để con người duyệt — qua bộ lọc gian lận nghiêm ngặt, để không xác nhận địa chỉ xấu. Cùng một engine, mục tiêu ngược lại.
Tác động đến hiệu quả kinh tế
Khi tuần tra hoạt động, số liệu thay đổi ngay lập tức. Hãy nhìn vào nhóm đăng ký thuộc top 10% — những tài khoản gây thiệt hại lớn nhất. Lượng tài nguyên dùng thử mà một tài khoản này tiêu tốn trong vài giờ đầu đã giảm từ khoảng $4 xuống còn $0.25 — giảm 94%. Trung bình trên mọi đăng ký mới cùng kỳ, thiệt hại trên mỗi tài khoản giảm khoảng 85%.
Hình dạng của sự thay đổi nói lên tất cả. Phần lớn đăng ký không gây thiệt hại gì; tổn thất luôn tập trung ở nhóm tài khoản nặng, chỉ tồn tại để tiêu hao credits dùng thử. Tuần tra không làm giảm số lượng đăng ký — mà cắt bỏ phần đuôi đó. Không phải ít đăng ký hơn. Mà là sạch hơn.
Vì sao chọn agent, không phải script
Chúng tôi có thể viết một cron job. Nhưng chúng tôi không làm vậy vì một lý do: mối đe dọa thay đổi nhanh hơn chu kỳ phát hành. Khi kẻ tấn công đổi chiến thuật, chúng tôi chỉ cần cập nhật hướng dẫn cho tác vụ bằng ngôn ngữ tự nhiên và logic mới sẽ hoạt động ngay lần chạy tiếp theo — không cần deploy, không cần migrate schema, không cần ticket. "Quy tắc" chỉ là một prompt, và prompt thay đổi nhanh như kẻ tấn công.
Đó là bài học thực sự. Radar là công cụ đúng cho rủi ro tại thời điểm thanh toán, và chúng tôi tận dụng tối đa. Nhưng sản phẩm dẫn dắt bằng dùng thử có điểm mù cấu trúc mà không công cụ kiểm tra tại thời điểm thanh toán nào che phủ được — và giải pháp không phải là engine quy tắc lớn hơn. Đó là một lớp thứ hai, nhanh, kiểm toán được, luôn hoạt động và có thể lập trình lại với tốc độ của mối đe dọa.
Gợi ý cho đội ngũ sản phẩm dùng thử
- Xác định các thời điểm không có giao dịch. Bất cứ nơi nào người dùng nhận giá trị trước khi thanh toán đều là lỗ hổng mà công cụ kiểm tra tại thời điểm thanh toán không nhìn thấy.
- Bổ sung lớp, không thay thế. Giữ Radar ở cửa trước. Thêm tuần tra liên tục sau khi đăng ký.
- Liên kết dữ liệu giữa các hệ thống. Bên xử lý thanh toán và nhà cung cấp định danh mỗi bên giữ một nửa bức tranh. Gian lận lộ rõ ở phần giao nhau.
- Phân tầng hành động theo độ tin cậy, và ghi lại mọi hành động. Chỉ tự động khi có thể đảo ngược và tín hiệu mạnh; chuyển phần còn lại cho con người.
- Tối ưu hóa tốc độ thích ứng. Trong chống gian lận, đội thay đổi quy tắc nhanh nhất sẽ thắng.
Bạn tò mò một agent luôn hoạt động có thể tự động hóa gì trong hệ thống của mình? Khám phá Zero.
Ghi chú: Số liệu Radar là số công bố của Stripe (stripe.com/radar; "A primer on machine learning for fraud detection"). Số liệu tổn thất phản ánh chi phí tài nguyên trên mỗi đăng ký mới trong vài giờ đầu sau đăng ký, đo trên các giai đoạn trước và sau khi triển khai, loại trừ tài khoản nội bộ; mẫu sau triển khai vẫn còn sớm và sẽ ổn định hơn theo thời gian.
