Tại sao Quyết định Rủi ro đầu tiên nên là tạm thời

Hầu hết các đội ngũ chống gian lận và rủi ro đo lường tốc độ mà họ có thể đưa ra quyết định. Ít người đặt câu hỏi liệu quyết định mà họ đưa ra vào thời điểm khởi tạo còn đúng hay không sau một tuần.

Trong quy trình mở tài khoản và thẩm định, kết quả đối diện với khách hàng có thể cần phải ngay lập tức. Nhưng trạng thái rủi ro nội bộ nên vẫn có thể xem xét lại — vì gian lận vượt qua kiểm tra một lần thường chỉ trở nên rõ ràng sau khi các tín hiệu liên quan phát triển. Quyết định rủi ro đầu tiên nên là tạm thời, không phải cuối cùng.

Đây không phải là một lời kêu gọi mở lại hành trình của khách hàng trên mỗi tài khoản được phê duyệt. Đây là một lập luận hoạt động hẹp hơn: các tổ chức nên ngừng coi trạng thái rủi ro nội bộ đầu tiên là lời cuối cùng.

Điểm mù của việc kiểm tra một lần

Nhiều hệ thống quyết định được tối ưu hóa cho các kiểm tra theo thời gian đến. Một ứng dụng được gửi đến, các quy tắc được kích hoạt, các API bổ sung được gọi, một điểm số được tạo ra và trường hợp tiếp tục. Nếu người nộp đơn vượt qua, sự kiện được đóng lại.

Vấn đề là gian lận không phải lúc nào cũng xuất hiện ngay khi đến. Một tài khoản trông sạch sẽ tại T=0 có thể trở nên đáng ngờ tại T+7 hoặc T+30 — không phải vì dữ liệu ban đầu sai, mà vì ngữ cảnh mà chưa tồn tại đã xuất hiện.

Xem xét phiên bản đơn giản nhất của điều này: ba tài khoản được mở trong khoảng thời gian hai tuần, mỗi tài khoản có tên khác nhau nhưng chia sẻ một thuộc tính chung — một dấu vân tay thiết bị, một số điện thoại, hoặc một miền email. Tài khoản đầu tiên, được đánh giá một cách độc lập, không kích hoạt gì cả. Tài khoản thứ hai có thể dấy lên một tín hiệu nhẹ. Đến tài khoản thứ ba, mẫu thuộc tính chung trở nên rõ ràng. Nhưng nếu tài khoản đầu tiên chỉ được điểm số một lần và lưu trữ, không có hệ thống nào quay lại để đánh giá lại nó.

Điều này không phải là một trường hợp bên lề giả thuyết. Đây là khoảng trống cấu trúc trong bất kỳ quy trình quyết định nào đánh giá một lần và không bao giờ xem xét lại.

Tại sao khoảng trống vẫn tồn tại

Ba mặc định kiến trúc giữ cho điểm mù này tồn tại.

Các quy tắc bị ràng buộc vào dữ liệu theo thời gian đến. Hầu hết các động cơ quy tắc ràng buộc các biến tại thời điểm một sự kiện được tiếp nhận. Các giá trị có sẵn tại thời điểm khởi tạo — tên, địa chỉ, kéo từ cơ quan, ID thiết bị — là những giá trị duy nhất mà các quy tắc đó sẽ thấy. Nếu một nguồn thông tin bên thứ ba cập nhật tín hiệu rủi ro của nó hai ngày sau, hoặc nếu một mối quan hệ đồ thị hình thành mà không tồn tại tại thời điểm quyết định, đánh giá ban đầu sẽ không được hưởng lợi từ sự thay đổi đó.

Bổ sung được coi là một chi phí một lần. Các cuộc gọi API bên ngoài — xác minh danh tính, dấu vân tay thiết bị, tra cứu cơ quan — rất tốn kém. Về mặt kiến trúc và tài chính, các đội thiết kế chúng để kích hoạt một lần. Ý tưởng gọi lại những nguồn đó theo lịch trình, đối với các sự kiện đã được quyết định, hiếm khi được xây dựng vào quy trình.

Ngữ cảnh đồ thị là tĩnh tại thời điểm truy vấn. Ngay cả các đội sử dụng đồ thị thực thể để phát hiện gian lận thường truy vấn đồ thị tại thời điểm khởi tạo. Đồ thị tại T=0 chỉ phản ánh các mối quan hệ đã biết tại thời điểm đó. Nếu các nút và cạnh mới hình thành sau đó — liên kết người nộp đơn với một cụm chưa tồn tại — quyết định ban đầu sẽ không bao giờ được cập nhật.

Mỗi mặc định này đều hợp lý một cách độc lập. Cùng nhau, chúng đảm bảo rằng một loại gian lận sẽ bị vô hình về cấu trúc.

Thực tế của việc đánh giá lại định kỳ thực sự như thế nào

Giải pháp thay thế không phải là “thẩm định lại mọi tài khoản mãi mãi.” Đó là một mẫu kiến trúc cụ thể: lưu trữ sự kiện, lập lịch đánh giá lại, và ràng buộc các biến đúng lúc tại mỗi chu kỳ thay vì chỉ tại thời điểm khởi tạo.

Trên thực tế, điều này có nghĩa là ba điều xảy ra khác nhau.

Đầu tiên, phiên bản sự kiện — hồ sơ ứng dụng hoặc mở tài khoản gốc — được lưu trữ với một khoảng thời gian giữ có thể cấu hình. Nó không được lưu trữ vào bộ nhớ lạnh ngay khi một quyết định được đưa ra. Nó vẫn có sẵn để được đánh giá lại.

Thứ hai, động cơ quy tắc áp dụng cùng một bộ quy tắc theo lịch trình định kỳ. Các quy tắc tự chúng không thay đổi giữa các chu kỳ. Điều thay đổi là dữ liệu mà các quy tắc đó có thể thấy — vì một số biến được ràng buộc không phải vào tải trọng sự kiện ban đầu mà vào các giá trị được lấy từ các nguồn bên ngoài và các hệ thống nội bộ vào thời điểm đánh giá lại.

Thứ ba, đồ thị là một cấu trúc dữ liệu sống. Khi các sự kiện mới đến từ các ứng viên hoặc tài khoản khác, đồ thị cập nhật — các nút mới, các cạnh mới, các mẫu mối quan hệ mới. Khi một sự kiện được lưu trữ được đánh giá lại, ngữ cảnh đồ thị mà nó truy cập phản ánh trạng thái hiện tại, không phải trạng thái tại thời điểm khởi tạo.

Kết quả là một sự kiện được đánh giá là sạch sẽ tại T=0 có thể tạo ra một nhãn rủi ro khác tại T+14 — không phải vì một con người đã xem xét nó, mà vì cái nhìn của hệ thống về ngữ cảnh của sự kiện đó đã thay đổi một cách đáng kể. Khi một cuộc đánh giá lại sản xuất một nhãn đầu ra khác , một cảnh báo được kích hoạt. Cảnh báo đó đại diện cho một sự chuyển tiếp trạng thái đáng để điều tra — không phải một kết quả dương giả từ một ngưỡng tĩnh.

Kiến trúc cơ bản được tài liệu hóa trong Bằng sáng chế Hoa Kỳ 11,922,421 B2, trong đó tôi là đồng phát minh. Ví dụ làm việc của bằng sáng chế chứng minh chính xác kịch bản này: một tài khoản ban đầu sạch sẽ trở nên đáng ngờ chỉ sau khi một bản cập nhật đồ thị sau đó liên kết các tài khoản bổ sung thông qua một thuộc tính chung, và sự kiện được lưu trữ được đánh giá lại dựa trên ngữ cảnh đã được cập nhật.

Quy tắc bằng chứng cho tuyên bố này

Để chính xác về những gì tôi đang khẳng định và trên cơ sở nào:

Mẫu kiến trúc — đánh giá lại định kỳ với việc ràng buộc các biến đúng lúc và cập nhật liên kết đồ thị — được tài liệu hóa trong bằng sáng chế đã được cấp (hồ sơ công khai). Ví dụ làm việc của bằng sáng chế về phát hiện gian lận hồi tố thông qua cập nhật đồ thị là hồ sơ công khai.

Rằng việc đánh giá lại có độ khả thi hoạt động — với độ trễ dưới một giây, lịch trình có thể cấu hình và cảnh báo chuyển tiếp trạng thái — khi quyết định, bổ sung đồ thị và cảnh báo được thiết kế cùng nhau thay vì như các hệ thống riêng biệt: điều này được quan sát từ việc vận hành một hệ thống như vậy trong sản xuất qua nhiều người thuê xử lý các luồng sự kiện có khối lượng lớn.

Tuyên bố rằng quyết định một lần về cơ bản bỏ sót rủi ro phát sinh khi ngữ cảnh của thực thể liên kết hoặc dữ liệu bên thứ ba thay đổi sau khi khởi tạo là suy luận — nhưng nó theo trực tiếp từ kiến trúc. Nếu hệ thống của bạn đánh giá một lần và môi trường dữ liệu thay đổi, đánh giá ban đầu thì lỗi thời theo định nghĩa.

Điều này không có nghĩa là

Đánh giá lại định kỳ không phải là giám sát giao dịch theo thời gian thực. Giám sát giao dịch chấm điểm mỗi giao dịch khi nó xảy ra. Đánh giá lại chấm điểm lại một quyết định trước đó bằng dữ liệu mà không có sẵn khi quyết định đó được đưa ra. Chúng giải quyết các vấn đề khác nhau.

Đánh giá lại cũng không phải là huấn luyện lại mô hình. Các quy tắc và mô hình không thay đổi giữa các chu kỳ đánh giá lại. Điều thay đổi là đầu vào — cụ thể là các biến đúng lúc và ngữ cảnh đồ thị gắn liền với các quy tắc đó. Logic là không đổi; thế giới mà nó quan sát không phải vậy.

Và đánh giá lại không có nghĩa là mỗi khách hàng được phê duyệt đều gặp một sự kiện ma sát. Trạng thái rủi ro nội bộ được cập nhật một cách im lặng. Một cảnh báo chỉ được kích hoạt khi một cuộc đánh giá lại sản xuất một chuyển tiếp trạng thái có ý nghĩa — sạch sẽ để xem xét, hoặc xem xét để chặn. Trải nghiệm đối diện với khách hàng chỉ thay đổi nếu tổ chức quyết định hành động dựa trên chuyển tiếp đó.

Ba điều cần làm vào sáng thứ Hai

1. Kiểm tra tỷ lệ khởi tạo đến đánh giá lại của bạn. Đếm số lượng quy tắc quyết định của bạn chỉ kích hoạt tại thời điểm khởi tạo so với số lượng kích hoạt lại theo lịch trình đối với các sự kiện được lưu trữ. Nếu tỷ lệ lệch mạnh về phía chỉ khởi tạo, bạn có một điểm mù tạm thời.

2. Lập bản đồ các nguồn bổ sung đúng lúc của bạn. Xác định ba API bổ sung bên ngoài hàng đầu mà ngăn xếp quyết định của bạn gọi — dấu vân tay thiết bị, đồ thị, cơ quan, xác minh danh tính. Đối với mỗi cái, xác định xem nó được gọi một lần tại thời điểm khởi tạo hay trong mỗi chu kỳ đánh giá lại. Các nguồn chỉ được gọi một lần đang tạo ra một ảnh chụp tại thời điểm có thể đã lỗi thời vào thời điểm hình thành một mẫu gian lận liên quan.

3. Chạy một cơ sở đánh giá lại. Lấy mẫu 1,000 sự kiện mở tài khoản được phê duyệt trong 90 ngày qua. Đánh giá lại chúng với ngữ cảnh đồ thị hiện tại và thông tin bên thứ ba hiện tại. Theo dõi bao nhiêu sự kiện tạo ra chuyển tiếp trạng thái từ sạch sẽ đến xem xét hoặc từ xem xét đến chặn tại các mốc 7 ngày, 14 ngày, và 30 ngày. Xác định những chuyển tiếp nào đáng để cảnh báo và những chuyển tiếp nào nên giữ ở mức quan sát. Số lượng chuyển tiếp cho bạn một ước lượng cụ thể về những gì đánh giá một lần không xem xét lại.