سامانه Kavach با تحلیل گراف‌های ارتباطی، نقاط کور امتیازات ریسک بانکی را

تصور کنید در یک بانک کار می‌کنید و با امتیازی بالا برای ریسک تراکنش مواجه می‌شوید؛ این عدد دلیلی برای بررسی است، اما هرگز نباید حکم نهایی باشد. همین فلسفه، هسته مرکزی Kavach (به معنای سپر) است؛ یک بازرس کلاهبرداری عامل‌محور (Agentic) که توسط تیم PixelPaws برای رویداد TigerGraph x Hacker House Goa ۲۰۲۶ توسعه یافته است.

بیشتر سامانه‌های تشخیص کلاهبرداری یا مدل‌های جعبه‌سیاه (Black-box) هستند که بدون توضیح تراکنش‌ها را علامت‌گذاری می‌کنند، یا موتورهای قانون‌مند سخت‌گیرانه‌ای‌اند که حملات نوظهور را نمی‌بینند. این چالش‌ها پیش‌تر در پروژه‌های مشابهی مانند GraphSentinel مورد بررسی قرار گرفت که هدفش تبدیل جعبه‌سیاه تشخیص تقلب به مسیری قابل حسابرسی بود. Kavach در این میان، تعادلی ایجاد کرده است تا هر تصمیم به شواهد قابل ردیابی متصل باشد و انسان همچنان قدرت تصمیم‌گیری نهایی را داشته باشد. وظیفه‌ای که به این تیم محول شد بسیار گسترده بود: تحلیل ۵۹۰,۷۴۲ تراکنش، بررسی ۵,۵۶۵ پرونده بسته شده و مدیریت ۲۰ هشدار باز. از میان این ۲۰ هشدار، نیمی از آن‌ها قانونی بودند و هدف سیستم این بود که تشخیص دهد کدام نیمی کلاهبرداری است، میزان ضرر را تعیین کند و سیاست‌های مکتوب کلاهبرداری بانک را اجرا نماید.

در دنیای واقعی، یک تراکنش با ریسک بالا ممکن است صرفاً یک خرید غیرمعمول باشد. یک سیستم سنتی ممکن است به سادگی کارت را مسدود کند. اما Kavach به‌جای مسدود کردن سریع کارت، آن امتیاز ریسک را تنها به عنوان یک نقطه شروع در نظر می‌گیرد و یک عامل (Agent) — شبیه به یک کارآگاه دیجیتال که تمام سرنخ‌ها را دنبال می‌کند — را برای بررسی روابط پیرامون تراکنش اعزام می‌کند. این عامل بررسی می‌کند که آیا مثلاً چندین حساب مختلف از یک دستگاه مشترک استفاده کرده‌اند یا خیر، تا بفهمد آیا امتیاز ریسک در حال «دروغ گفتن» است یا واقعاً خطری وجود دارد.

معماری بازرسی

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، حذف توهم در محیط‌های حساس مالی حیاتی است. به همین دلیل، معماری Kavach بر پایه یک خط لوله ساختاریافته و دقیق است: جمع‌آوری $ \rightarrow $ شناسایی $ \rightarrow $ ارزیابی $ \rightarrow $ اقدامات اولیه $ \rightarrow $ پرسش از مشتری $ \rightarrow $ پاسخ شبیه‌سازی شده $ \rightarrow $ ارزیابی مجدد $ \rightarrow $ اقدامات نهایی $ \rightarrow $ فراخوانی موارد مشابه $ \rightarrow $ روایت‌گری $ \rightarrow $ ثبت در گراف $ \rightarrow $ فایل پاسخ.

این سامانه از مدل Groq openai/gpt-oss-120b برای تولید متن و خلاصه‌سازی استفاده می‌کند، اما طبق مستندات پروژه، مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — به‌شدت از صدور حکم نهایی منع شده است. هر پاسخ باید شامل سه بخش باشد: یک پرونده داخلی (شامل حکم، الگو، تراکنش‌های متأثر، کارت‌های متصل، میزان ضرر و شواهد)، یک گزارش فعالیت مشکوک (SAR) در صورتی که سیاست‌های بانک آن را ایجاب کند، و بهترین اقدام بعدی. از آنجایی که هر شناسه (ID) باید حتماً در داده‌ها وجود داشته باشد و نتایج بر اساس یک کلید مخفی امتیازدهی می‌شوند، LLM تنها به نوشتن خلاصه و روایت SAR از روی یک فایل JSON حاوی حقایق محدود شده است. اگر مدل دچار لغزش شود، یک قالب (Template) پیش‌فرض جایگزین آن می‌شود تا دقت سیستم فدای خلاقیت مدل نشود.

جزئیات عملیاتی این بازرس دیجیتال به شرح زیر است:

• جمع‌آوری (Gathering): عامل تاریخچه کارت، کارت‌های متعلق به مشتری، پروفایل دستگاه و هر کارت دیگری که روی آن دستگاه ثبت شده، منطقه صورت‌حساب، پرونده‌های بسته‌ای که با هر یک از این موارد در ارتباط بوده‌اند و تاریخچه حساب پایه را استخراج می‌کند.
• شناسایی (Detection): شناسگرها در سه خانواده اصلی اجرا می‌شوند:
  • تک‌کارتی (Single-card): بررسی توالی تراکنش‌ها، دستگاه، منطقه، پرچم‌های تطبیق، امتیاز ریسک و گفته‌های مشتری.
  • متقاطع (Cross-card): شناسایی حلقه‌های دستگاه (Device rings)، الگوهای مبالغ ثابت و رگبارهای تکراری تراکنش.
  • تاریخچه‌ای (History): بررسی سوابق تکرار تخریب حساب و پیشینه‌های مربوط به دستگاه.
• ارزیابی (Assessment): سیستم قوی‌ترین سیگنال از هر گروه شواهد مستقل را با استفاده از log-odds ترکیب می‌کند. این کار از «تورم سیگنال» جلوگیری می‌کند؛ به این معنا که ۱۰ هشدار مرتبط با یک دستگاه، تنها به عنوان یک دلیل واحد شمرده می‌شوند تا وزن شواهد به طور کاذب بالا نرود.
• موتور سیاست‌ها (Policy Engine): تمام اقدامات بر اساس «سیاست کلاهبرداری نسخه ۱.۰» اجرا می‌شوند که به صورت کد پیاده شده است. این شامل قوانین R1 تا R10، جدول تاییدات و دستورالعمل خاص بخش 3a است که تصریح می‌کند «یک پرونده لزوماً یک گزارش نیست». این موتور قانون به قانون مورد تست واحد (Unit-test) قرار گرفته است.

بهره‌گیری از TigerGraph برای زمینه عمیق

برای تامین این حجم از داده و ایجاد ارتباطات پیچیده، تیم از TigerGraph برای نقشه‌برداری از مشتریان، کارت‌ها، تراکنش‌ها، پروفایل‌های دستگاه، دامنه‌های ایمیل، مناطق صورت‌حساب، پرونده‌های بسته شده بانک و گره‌های InvestigationCase (پرونده‌های بازرسی) متعلق به خود عامل استفاده کرد.

عملکرد فنی و مقیاس‌پذیری

این سیستم که روی محیط Savanna (نسخه 4.2.5، سطح رایگان) اجرا شده، یک مجموعه داده عظیم را مدیریت کرد:

• بار داده: ۵۹۰,۷۴۲ تراکنش، ۲۰۲,۴۴۰ حساب پایه، ۹,۷۰۵ پروفایل دستگاه و ۵,۵۶۵ پرونده بسته شده.
• یال‌ها (Edges): تقریباً ۳.۳ میلیون یال که از طریق کارهای بارگذاری GSQL در دسته‌های ۵۰ هزار خطی در حدود ۶ دقیقه وارد شدند.
• کوئری‌ها: ۲۰ کوئری نصب شده (۱۷ ابزار گراف و ۳ جست‌وجوی برداری) که هر کدام در حدود ۱۰۰ میلی‌ثانیه پاسخ می‌دهند.
• یکپارچگی: عامل کد یکسانی را از طریق pyTigerGraph یا سرور MCP TigerGraph اجرا می‌کند. یک تست برابری (Parity test) در برابر یک نسخه DuckDB تضمین می‌کند که هر دو مسیر پاسخ‌های یکسانی ارائه می‌دهند.

یکی از حیاتی‌ترین قابلیت‌ها، پیمایش دو-گام (Two-hop traversal) است: تراکنش $ \rightarrow $ پروفایل دستگاه $ \rightarrow $ تراکنش $ \rightarrow $ کارت. این مسیر خاص به Kavach اجازه می‌دهد بپرسد: «دیگر چه اتفاقاتی روی این دستگاه رخ داده است؟» و همین مکانیزم است که سخت‌ترین پرونده‌های کلاهبرداری را می‌شکافد.

علاوه بر این، Kavach با استفاده از TigerVector و بردار معنایی (Embedding) ۳۸۴-بعدی برای هر یادداشت تحلیلگر در پرونده‌های بسته و متن سیاست‌ها، عمل می‌کند. این قابلیت به عامل اجازه می‌دهد با اجرای vectorSearch() پرونده‌های بسته‌ای را پیدا کند که تحلیلگران پیش‌تر آن‌ها را به عنوان «مستند نشده» برچسب زده بودند، به‌ویژه برای رگبارهای تراکنشی زیر ۵۰۰ دلار. هر بازرسی جدید به عنوان یک گره InvestigationCase با بردار معنایی خاص خود ثبت می‌شود و بدین ترتیب یک حافظه دائمی برای پرونده‌ها ایجاد می‌گردد.

موانع پیاده‌سازی

در طول ساخت، دو مشکل فنی خاص رخ داد. اول، تیم متوجه شد که کلمه proxy در لیست ویژگی‌ها (Attribute lists) یک کلمه رزرو شده است، اما این تداخل تنها زمانی رخ می‌دهد که ویژگی دیگری بعد از آن بیاید. دوم، یک فضای کاری جدید حاوی یک راهکار نمونه با نوع جهانی Card بود که با اسکیمای تیم تداخل داشت؛ این مشکل با بازسازی گراف با استفاده از انواع محلی (Graph-local types) در یک عملیات تغییر اسکیما حل شد.

داده‌ها چه فاش کردند؟

در طول توسعه، تیم دریافت که داده‌های خام اغلب با فرضیات شهودی در تضاد هستند. آن‌ها پیش از نوشتن کد عامل، ۲۰ پرونده SQL را به صورت دستی بررسی کردند و به بینش‌های حیاتی رسیدند:

• سوتفاهم‌های هویتی: یک شناسه کارت لزوماً یک شخص نیست. چون customer_id از فیلد صادرکننده کارت مشتق شده بود، یک شناسه کارت ۱۰,۳۳۲ تراکنش را در ده‌ها منطقه مختلف تجمیع کرده بود. برای رفع این مشکل، آن‌ها حساب پایه را به صورت card1 | billing region | account start day (با استفاده از D1، تعداد روزهای سپری شده از زمان افتتاح حساب) بازسازی کردند.
• قدرت برچسب‌ها: پرونده‌های بسته شده یک مجموعه برچسب تقریباً کامل ارائه دادند. تراکنش‌های تایید شده به عنوان کلاهبرداری، ۳.۴٪ از ترافیک ماه جولای تا اکتبر را تشکیل می‌دادند. نکته قابل توجه این بود که حسابی که پیش‌تر یک پرونده کلاهبرداری تایید شده داشت، در ۱,۰۵۹ پرونده بعدی نیز کلاهبردار بود و در هیچ موردی تبرئه نشد.
• کالیبراسیون امتیازات: امتیازات ریسک جهانی نیستند. امتیازی بالای ۰.۸ برای محصول C (بدون رکورد هویتی) نشان‌دهنده ۹۷٪ احتمال کلاهبرداری بود، اما برای محصول R این احتمال تنها ۹٪ بود. این رویکرد کالیبراسیون یادآور سیستم KestrelQuant است که در آن وتوی باینری جای خود را به تنظیم پویای ریسک داد. کالیبراسیون امتیازات بر اساس ماه‌های بسته شده باعث شد بسیاری از هشدارهای «ریسک بالا» به درستی به عنوان تراکنش‌های قانونی بسته شوند.
• سوگیری انتخاب (Selection Bias): هر پرونده بسته شده‌ای که تبرئه شده بود، یک هشدار مثبت کاذب با امتیاز بالا (۰.۸۲ تا ۰.۹۴) بود. برای جلوگیری از این اشتباه که تصور شود «دستگاه جدید» دلیلی برای تبرئه است، تیم نسبت احتمال هر سیگنال را در هر محصول، هم در برابر کل جمعیت و هم در برابر پرونده‌های تبرئه شده اندازه گرفت.
• الگوهای متقاطع کارت‌ها: پروفایل دستگاهی که در ۶ ماه تنها روی ۵ کارت دیده شده و حدود ۱۰۰ دلار از کارت ۵ مشتری مختلف در ۶ روز پرداخت کرده بود، در سطح هر کارت عادی به نظر می‌رسید. اما این شکل از رفتار ۷ تا ۱۱ برابر بیشتر در موارد کلاهبرداری رایج بود و باعث شد Kavach طبق قانون R6 توصیه به نظارت کند.
• کلاهبرداری‌های مستند نشده: دو الگوی خاص یافت شد که در هیچ گونه‌شناسی مستندی نبودند: چهار خرید آنلاین زیر ۵۰۰ دلار در ۳۰ دقیقه که در ده‌ها کارت تکرار شده بود، و یک پروفایل تلفنی اسکریپت شده پشت یک پروکسی ناشناس که مبالغ کمی را از ۲۸ کارت خریداری می‌کرد. Kavach این‌ها را «مستند نشده» برچسب زده و طبق قانون R9 گزارش می‌کند.

نتایج و اعتبارسنجی

از میان ۲۰ هشدار باز، Kavach توانست ۱۱ مورد کلاهبرداری، ۸ مورد قانونی و ۱ مورد نامشخص (که با شواهد ارجاع داده شد) را شناسایی کند. تمام ۲۰ فایل از فیلتر اعتبارسنجی عبور کردند.

در مواردی که شواهد غیرقطعی بود، Kavach طبق قانون R1 پیش از مسدود کردن، اقدام به تایید کرد. سیستم پاسخ مشتری را بر اساس شواهد جمع‌آوری شده شبیه‌سازی می‌کند: شواهد متمایل به کلاهبرداری منجر به انکار، شواهد متمایل به قانونی منجر به تایید، و شواهد متوازن منجر به عدم پاسخ در ۲۴ ساعت (قانون R4 و سپس ارجاع طبق R8) می‌شود.

تحلیل: تغییر پارادایم هوش مصنوعی در کلاهبرداری

Kavach نشان‌دهنده تغییر از هوش مصنوعی «پیش‌بین» به هوش مصنوعی «بازرس» است. با سلب قدرت تصمیم‌گیری از LLM و تبدیل آن به یک روایت‌گر، تیم توانست مشکل توهم را در محیط‌های حساس مالی حل کند. هوش واقعی در اینجا نه در مهندسی پرامپت، بلکه در اسکیمای گراف و کالیبراسیون شواهد نهفته است.

برای متخصصان، این ثابت می‌کند که موثرترین عامل‌های هوش مصنوعی آن‌هایی هستند که نرده‌های حفاظتی (Guardrails) سخت‌گیرانه‌ای دارند. استفاده از تست برابری بین TigerGraph و نسخه DuckDB تضمین می‌کند که منطق عامل فارغ از لایه داده، ثابت بماند. این معماری، هوش مصنوعی را از یک اوراکل جعبه‌سیاه به یک تحلیلگر فارنزیک دیجیتال شفاف تبدیل می‌کند.

برای بررسی بیشتر این رویکرد، توسعه‌دهندگان می‌توانند پیاده‌سازی کوئری‌های GSQL و مدل شواهد را در گیت‌هاب پروژه مشاهده کنند: https://github.com/MONSTERBOY110/hhgoa-tigergraph.

گام بعدی شما

• بررسی پیاده‌سازی کوئری‌های GSQL و مدل شواهد در مخزن گیت‌هاب پروژه برای درک نحوه ترکیب گراف و LLM.
• مطالعه روش کالیبراسیون امتیازات ریسک بر اساس داده‌های تاریخی برای کاهش نرخ مثبت کاذب (False Positive).
• آزمایش رویکرد «تفکیک روایت از تصمیم» در عامل‌های هوش مصنوعی برای حذف توهم در محیط‌های حساس.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.