کشف تقلب و کنترل ریسک: ردیابی مستند مسیر پول در مقیاس سوپراپ

مسئله

سوپراپی با بیش از ۴۰ سرویس، از کیف‌پول و پرداخت قبض تا خرید شارژ و پرداخت فروشگاهی، با الگوهای تقلبی مواجه بود که در محدوده مسئولیت یک تیم جا نمی‌گرفتند: تصاحب حساب، انتقال سریع پول میان کیف‌پول‌ها برای پول‌شویی و استفاده از کالاهای دیجیتال، مانند پرداخت قبض و شارژ، برای تبدیل سریع پول سرقت‌شده و قطع مسیر ردیابی.

محدودیت‌ها فقط فنی نبودند:

• داده‌های تراکنش در سامانه‌های جدا قرار داشتند: لاگ بانک، دفتر کل داخلی، داده پرداخت پذیرندگان مانند دیجی‌کالا و داده تأمین‌کنندگان خدمات مخابراتی و قبوض. این منابع برای تبادل داده با یکدیگر طراحی نشده بودند.
• بررسی دستی، چند تیم و چند ساعت زمان می‌خواست؛ در این فاصله پول همچنان جابه‌جا می‌شد.
• خروجی نهایی باید برای دستگاه قضایی قابل‌فهم می‌بود؛ جایی که قضات با پیش‌زمینه حوزوی، دانش فنی محدودی داشتند. نموداری که قاضی غیرفنی بتواند دنبال کند، به‌اندازه صحت خود ردیابی اهمیت داشت.
• در مرحله دریافت شکایت، گزارش اولیه اغلب از مأموری می‌رسید که چارچوبی برای فهم «خرید اینترنتی» نداشت؛ ردیابی چنین خریدی یک مسئله دشوارتر بود.

آنچه ساختم

سامانه‌ای ساختم که یک نفر بتواند کل پاسخ به تقلب را، از تشخیص تا تحویل مستندات قضایی، در کمتر از ۱۰ دقیقه اجرا کند.

تشخیص و مهار. قواعد خودکار، حساب‌ها را بر اساس نرخ و نوع خرید علامت‌گذاری می‌کردند. الگوی نشست غیرمجاز با رفتار عادی صاحب حساب تفاوت دارد و این اختلاف قابل‌تشخیص است. پس از تشخیص، سامانه نشست‌ها را قطع و اتصال توکن‌های دستگاه را لغو می‌کرد؛ میان تشخیص و مسدودسازی، اقدام دستی وجود نداشت.

ردیابی مسیر پول. مجموعه‌ای از پرس‌وجوها، پول را در انتقال‌های بازگشتی میان کیف‌پول‌ها دنبال می‌کرد. متقلب معمولاً پول را خرد می‌کند، جابه‌جا می‌کند و دوباره به اقلام قابل‌مصرف، مانند پرداخت قبض، شارژ یا خرید اینترنتی تبدیل می‌کند تا زنجیره ردیابی قطع شود. سامانه این زنجیره را در بیش از ۴۰ سرویس برنامه به‌صورت خودکار دنبال می‌کرد. دقت تشخیص مقصد نهایی پول حدود ۸۰ درصد بود. این عدد، عملکرد در برابر الگوهایی را نشان می‌دهد که عمداً برای دشوارکردن ردیابی طراحی شده‌اند؛ نتیجه آزمون کنترل‌شده آزمایشگاهی نیست.

تبدیل ردیابی به مستند قابل‌فهم قضایی. ابزاری با .NET ساختم که خروجی خام ردیابی، شامل لاگ بانک، سوابق تراکنش داخلی و ارجاع‌های رمزنگاری‌شده را به یک فایل مستقل Excel تبدیل می‌کرد. برگه‌ها به یکدیگر پیوند داشتند و نمودار مسیر پول به‌اندازه‌ای روشن بود که فرد بدون دانش فنی بتواند ببیند پول به کجا رفته و در نهایت چه کسی آن را دریافت کرده است. گلوگاه اصلی همین بود و سایر اجزای سامانه برای رفع آن کار می‌کردند. ردیابی فنی صحیح، اگر در دادگاه قابل‌ارائه و قابل‌فهم نباشد، کارکرد عملیاتی خود را از دست می‌دهد.

زیرساخت پرداخت و تسویه. این سامانه روی زیرساخت اختصاصی یک بانک اجرا نمی‌شد؛ شرکت بانک نبود. لایه واسط پرداخت و تسویه، موسوم به پرداخت‌یاری، را طراحی کردم تا مغایرت‌گیری را مستقیم انجام دهد. همچنین پردازش کارت‌به‌کارت را برای ۲۲ بانک ایرانی پیاده‌سازی کردم. هر بانک الزامات اتصال، کدهای خطا و رفتار پایان مهلت پاسخ متفاوتی داشت. این تفاوت‌ها را پشت یک رابط یکدست قرار دادم.

اثر عملیاتی

• پاسخ کامل به تقلب، شامل تشخیص، مهار، ردیابی و تهیه گزارش قضایی، از فرایندی چندتیمی و چندساعته به کاری با یک کارشناس و زمان کمتر از ۱۰ دقیقه تبدیل شد.
• سامانه در تمام ساعات شبانه‌روز و هفت روز هفته، ردیابی زنده بنا به درخواست ارائه می‌کرد؛ چه درخواست از مرجع انتظامی می‌رسید و چه مستقیم از فرد زیان‌دیده. در برخی موارد، سرعت پاسخ اجازه می‌داد پیش از نقدشدن وجوه، جابه‌جایی را متوقف کنیم.
• معماری اصلی پایش تراکنش و تسویه از حدود ۱۰۰ کاربر به ۳۰ میلیون کاربر مقیاس گرفت و همچنان مبنای سامانه‌ای است که تیمی حدوداً ۳۰۰نفره آن را نگهداری می‌کند.

ملاحظات اجرای سامانه مشابه

بخش دشوار، منطق ردیابی نبود. مسئله اصلی، ارتباط سامانه فنی با تصمیم‌گیرندگان غیرفنی در دو سوی فرایند بود: مأمور دریافت شکایت که خرید اینترنتی را نمی‌شناخت و قاضی‌ای که باید مسیر پول را روی صفحه می‌دید. رکوردهای پایگاه داده برای او کافی نبود. سامانه‌ای که در مرحله «تقلب را پیدا کردیم» متوقف شود و امکان اقدام فرد غیرفنی بر مبنای یافته‌ها را فراهم نکند، مسئله را کامل حل نکرده است.