مقدمه: مبلغ یکسان، زمینه متفاوت
یک سامانه پایش تراکنش دو واریز ۹۰ میلیون ریالی را نشان می‌دهد. اگر نرم‌افزار فقط مبلغ را ملاک قرار دهد، احتمالاً برای هر دو رفتار یکسانی دارد. اما تحلیلگر تطبیق می‌داند که «یکسان بودن مبلغ» به معنی «یکسان بودن توضیح اقتصادی، طرف معامله و سطح ابهام» نیست.
در یک پرونده ممکن است واریز مربوط به قرارداد معتبر، از حساب یک خریدار شناسایی‌شده و منطبق با تغییرات واقعی فعالیت شرکت باشد. در پرونده دیگر، همان مبلغ از شخص ثالثی با رابطه نامشخص دریافت شده باشد و مستند تجاری کافی برای آن در دسترس نباشد.
هوش مصنوعی قرار نیست براساس یک عدد حکم به پول‌شویی بدهد؛ باید نشان دهد کدام رویداد با اطلاعات مورد انتظار سازگار نیست، چرا به رسیدگی نیاز دارد و کدام شواهد هنوز ناقص‌اند. تشخیص نهایی فعالیت مشکوک و اقدام قانونی یا سازمانی از اختیارات مسئولان مجاز است.
مبنای خبر: عامل رسیدگی به هشدار AML وارد مرحله عرضه تجاری شد
در ۱۵ اکتبر ۲۰۲۶، شرکت فناوری مالی FIS اعلام کرد عامل هوشمند AML Investigations Agent برای بانک‌های مستقر در آمریکا به‌صورت تجاری عرضه شده است. این عامل پیش‌تر در ۴ مه ۲۰۲۶ در قالب همکاری FIS و Anthropic معرفی شده بود؛ بنابراین معرفی اولیه و عرضه تجاری دو رویداد متفاوت‌اند.
به گفته سازنده، ابزار جدید به‌جای برخورد یکسان با همه هشدارها، نوع مشتری، سابقه فعالیت، رفتار مورد انتظار و زمینه تراکنش را در پرونده بررسی می‌کند، شواهد مرتبط را از سامانه‌های مجاز کنار هم می‌گذارد و نتیجه پیشنهادی را به داده منشأ متصل می‌کند. در سازوکار اعلام‌شده، هیچ پرونده‌ای بدون تأیید صریح تحلیلگر بسته نمی‌شود.
FIS همچنین برآوردهایی از صرفه‌جویی زمانی در مراحل بررسی اولیه و عمیق پرونده منتشر کرده است؛ این اعداد پیش‌بینی مبتنی بر تحلیل گردش‌کار شریک طراحی محصول هستند، نه نتیجه مستقلاً اندازه‌گیری‌شده پس از استفاده عمومی. این مقاله هیچ درصدی را به‌عنوان کارایی قطعی AI گزارش نمی‌کند.
نکته اصلی برای سازندگان نرم‌افزار مالی در ایران، اتصال داده تراکنش، شناخت مشتری، دلیل هشدار و تصمیم انسانی در یک زنجیره قابل ممیزی است؛ نه ادعای قابل‌استفاده‌بودن محصول آمریکایی در شبکه بانکی ایران.
چرا آستانه ثابت مبلغ برای تصمیم کافی نیست؟
مبلغ تراکنش فقط یکی از ویژگی‌های پرونده است. نوع فعالیت اقتصادی، نوسان فصلی، دامنه معمول عملیات، مبدأ و مقصد وجوه، اسناد قرارداد، نسبت پرداخت‌کننده با مشتری و تغییرات اخیر مشخصات کسب‌وکار می‌توانند در تحلیل نقش داشته باشند.
راهنمای رسمی FFIEC درباره پایش فعالیت مشکوک تأکید می‌کند معیارهای فیلتر باید متناسب با مشتری، محصول، خدمت و ریسک باشند و به‌صورت دوره‌ای آزمون شوند. در عین حال، اتکای صرف به سابقه تاریخی مشتری هم ممکن است گمراه‌کننده باشد؛ اگر خود الگوی قبلی نامتناسب یا مسئله‌دار بوده باشد، «شبیه گذشته بودن» الزاماً نشانه ایمن‌بودن نیست.
به همین دلیل، یک سامانه مناسب دو پرسش جدا می‌پرسد: «این تراکنش نسبت به سابقه خود مشتری چه تفاوتی دارد؟» و «با توجه به توضیح معتبر فعالیت، مستندات و ریسک‌های مربوط، آیا آن تفاوت نیازمند رسیدگی است؟»
مثال آموزشی: دو واریز برابر و دو مسیر بررسی متفاوت
همه اطلاعات، مشتریان و مبلغ‌های این بخش کاملاً فرضی هستند. واحد ارقام «میلیون ریال» است و هیچ‌کدام از عددهای جدول، آستانه قانونی یا معیار قطعی شناسایی تخلف محسوب نمی‌شوند.
| داده فرضی | مشتری الف | مشتری ب |
|---|---|---|
| مجموع واریز ماه اول در سه ماه قبل | ۲۰ | ۷۵ |
| مجموع واریز ماه دوم در سه ماه قبل | ۲۵ | ۸۵ |
| مجموع واریز ماه سوم در سه ماه قبل | ۱۵ | ۸۰ |
| میانگین ساده ماهانه این سه ماه | ۲۰ | ۸۰ |
| واریز تازه مورد بررسی | ۹۰ | ۹۰ |
| نسبت واریز تازه به میانگین فرضی | ۴٫۵ برابر | ۱٫۱۲۵ برابر |
| توضیح و مدرک اولیه | قرارداد جدید و پرداخت‌کننده شناسایی‌شده | پرداخت‌کننده جدید و رابطه تجاری نامشخص |
| وضعیت پیشنهادی | کنترل قرارداد و تغییر الگوی فعالیت | بررسی منشأ و ارتباط طرف معامله |
برای مشتری الف، میانگین سه ماه گذشته برابر است با (۲۰ + ۲۵ + ۱۵) ÷ ۳ = ۲۰ میلیون ریال. واریز جدید ۹۰ میلیون ریالی، ۴٫۵ برابر آن است. این تغییر به‌تنهایی ثابت نمی‌کند واریز مشکوک یا مجرمانه است؛ ممکن است شرکت قرارداد واقعی تازه‌ای امضا کرده و ماهیت فعالیتش تغییر کرده باشد.
برای مشتری ب، میانگین برابر (۷۵ + ۸۵ + ۸۰) ÷ ۳ = ۸۰ میلیون ریال است. مبلغ جدید تنها ۱٫۱۲۵ برابر میانگین آموزشی است، اما طبق فرض مثال از پرداخت‌کننده‌ای با رابطه نامشخص رسیده است. بنابراین احتمالاً بررسی منشأ و اسناد مرتبط اهمیت بیشتری پیدا می‌کند.
در این مثال، عدد نسبت ۴٫۵ یا ۱٫۱۲۵ «امتیاز ریسک» نیست و هیچ‌کدام قانون هشدار قطعی ندارند. فقط نشان می‌دهند چرا یک سامانه خوب نباید درباره هر دو مشتری صرفاً براساس عدد واریز قضاوت کند.
حتی ممکن است پس از رسیدگی مشخص شود تراکنش مشتری ب کاملاً عادی است و برای مشتری الف نیز بررسی بیشتری لازم باشد. هدف الگوریتم، اولویت‌دهی مستند برای بررسی است نه پیش‌داوری درباره اشخاص.
چهار لایه اطلاعاتی که باید کنار هم بررسی شوند
لایه اول، داده معتبر تراکنش است: شناسه غیرتکراری، تاریخ، مبلغ، ارز، کانال دریافت، حساب مرتبط، وضعیت نهایی تراکنش و سوابق اصلاح یا برگشت. تراکنش برگشتی یا تکرارشده نباید بدون توضیح، به‌عنوان عملیات جدید شمرده شود.
لایه دوم، شناخت مجاز مشتری و فعالیت مورد انتظار است: نوع کسب‌وکار، حوزه عملیاتی، الگوی معمول فعالیت، اطلاعات تأییدشده و تاریخ آخرین به‌روزرسانی آنها. برخی داده‌ها ممکن است قدیمی یا ناقص باشند؛ سیستم باید کیفیت و سن آنها را نمایش دهد.
لایه سوم، زمینه معامله است: قرارداد، فاکتور، رسید، ارتباط اقتصادی طرف معامله، توضیحات مجاز و رویدادهای مرتبط. وجود یک فاکتور نیز به‌تنهایی صحت معامله یا اصالت همه اسناد را اثبات نمی‌کند.
لایه چهارم، سیاست کنترل و تصمیم است: معیارهای مصوب، گروه ریسک، علت فعال‌شدن هشدار، نتیجه بررسی، نظر موافق یا مخالف، اسناد ناقص و فردی که تصمیم را تصویب کرده است.
یک مدل زبانی می‌تواند چهار لایه را خلاصه کند، ولی اعداد و روابط باید از سامانه‌های اصلی و قواعد آزمون‌پذیر بازیابی شوند و نتیجه نهایی از مسیر مجاز عبور کند.
مرز بین هشدار، پرونده و نتیجه چیست؟
«هشدار» علامت می‌دهد الگویی با معیار کنترل نیازمند توجه است. «پرونده بررسی» مجموعه اطلاعات گردآوری‌شده و ارزیابی تحلیلگر است. «نتیجه» پس از رسیدگی حرفه‌ای و طی گردش‌کار مصوب ثبت می‌شود.
بستن یک هشدار با توضیح موجه، به معنی گواهی دائمی درباره مشتری نیست. همچنین بازماندن پرونده، وقوع جرم یا تخلف را اثبات نمی‌کند. تشخیص و گزارش‌دهی قانونی در هر حوزه قضایی باید طبق قوانین و مقررات همان حوزه انجام شود.
در چارچوب آمریکا، راهنمای FFIEC مراحل شناسایی هشدار، مدیریت هشدار، تصمیم درباره گزارش فعالیت مشکوک، تکمیل گزارش و پایش فعالیت مستمر را تفکیک می‌کند. این توصیف رویه نظارتی آمریکا است؛ نمی‌توان اصطلاح SAR، تشریفات آن یا آستانه‌های آن را بدون بررسی به سامانه‌ها و تکالیف ایران تعمیم داد.
هشت کنترل نرم‌افزاری برای پایش هوشمند و قابل دفاع
۱. نسخه معتبر نمایه مشتری: نوع فعالیت، بازه فعالیت مورد انتظار، گروه ریسک و تاریخ تأیید باید صاحب و نسخه داشته باشند. اگر اطلاعات ناقص یا قدیمی است، AI نباید آن را واقعیتی قطعی تلقی کند.
۲. تفکیک داده تراکنش و تفسیر AI: مبلغ، تاریخ، صاحب حساب و وضعیت عملیات از منبع معتبر دریافت شوند. دلیل هشدار و روایت مدل جدا ذخیره شود تا روایت جای داده اصلی را نگیرد.
۳. قواعد ریسک متناسب با زمینه: در کنار تغییر نسبت به سابقه مشتری، ویژگی‌های کسب‌وکار، اطلاعات معتبر جدید و معیارهای مستقل مصوب لحاظ شوند؛ تنظیم معیار نباید صرفاً برای کاهش تعداد هشدارها دستکاری شود.
۴. کنترل داده تکراری و دیررس: شناسه تراکنش، وضعیت برگشت، بسته دریافت و زمان آخرین به‌روزرسانی بررسی شوند. یک عملیات دوبار به‌عنوان شاهد مستقل شمرده نشود و دیررس‌بودن اطلاعات پنهان نماند.
۵. پیوند هر گزاره با سند: اگر سیستم می‌نویسد «طرف معامله جدید است»، باید به اطلاعات نسخه‌دار طرف معامله اشاره کند. اگر اطلاعات کافی در دست نیست، نتیجه «نیازمند بررسی» باشد، نه برچسب اتهامی.
۶. مسیر تصمیم انسانی: پیشنهاد اولویت، تکمیل مدارک و طبقه‌بندی پرونده توسط AI مجاز باشد، اما بسته‌شدن پرونده و تصمیم‌های دارای اثر قانونی، اعتباری یا عملیاتی فقط با اختیار مشخص انجام شوند.
۷. محرمانگی و تفکیک دسترسی: داده‌های حساس مشتریان و پرونده‌های بررسی به حداقل افراد لازم محدود شوند. استفاده از مدل خارجی نیازمند بررسی مجازبودن انتقال و نگهداری داده و سیاست امنیتی سازمان است.
۸. آزمون و پایش تغییر مدل: تغییر الگوی کسب‌وکار، داده ناقص، خطای منبع، موارد هشدار کاذب و موارد ازدست‌رفته با نمونه مرجع انسانی بررسی شوند. تغییر نسخه قواعد و مدل باید دلیل، تأیید و امکان بازسازی داشته باشد.
چرا کم‌شدن تعداد هشدارها همیشه موفقیت نیست؟
اگر یک سامانه با افزایش بی‌دلیل آستانه‌ها، تعداد هشدارها را نصف کند، الزاماً کیفیت کشف بهتر نشده است. ممکن است پرونده‌هایی که باید بررسی می‌شدند دیگر دیده نشوند.
در ارزیابی عملی، باید هشدار درست و نادرست، موارد مهم ازدست‌رفته، زمان جمع‌آوری شواهد، تعداد پرونده‌های فاقد منشأ و میزان اصلاح قضاوت پیشنهادی AI توسط تحلیلگر سنجیده شود. برای برآورد برخی از این شاخص‌ها، نمونه‌های مرجع و بررسی مستقل لازم است و تمام رویدادهای فاقد هشدار نیز نباید از آزمون کنار گذاشته شوند.
خروجی مدل نباید درباره شخص حقیقی یا حقوقی عباراتی مانند «پول‌شویی تأیید شد» بنویسد مگر نتیجه‌ای واقعاً با شواهد و فرایند قانونی مربوط احراز شده باشد؛ برچسب آموزشی مدل یا امتیاز آماری چنین جایگاهی ندارد.
شش آزمون پذیرش پیش از اتصال به اطلاعات واقعی
برای محیط آزمایشی، داده‌های کاملاً ساختگی تولید کنید و از پیش توسط مسئول تطبیق مشخص کنید که چه مواردی باید بررسی شوند:
آزمون اول: واریز بزرگ‌تر از سابقه همراه با قرارداد معتبر و تغییر واقعی حجم کسب‌وکار؛ سامانه باید امکان توضیح و رسیدگی داشته باشد، نه نتیجه اتهامی خودکار.
آزمون دوم: واریز هم‌اندازه فعالیت معمول، اما با پرداخت‌کننده یا ساختار معامله متفاوت و فاقد توضیح کافی؛ سامانه نباید فقط به شباهت مبلغ اکتفا کند.
آزمون سوم: مشتری تازه‌وارد با تاریخچه بسیار کوتاه؛ سیستم نباید میانگین بی‌اعتبار را مبنای قطعی قرار دهد.
آزمون چهارم: مشتری فصلی با الگوی فعالیت متفاوت در ماه‌های مختلف؛ افزایش فصلی نباید بدون بررسی با الگوی غیرعادی اشتباه شود.
آزمون پنجم: تراکنش برگشتی یا داده تکراری از دو منبع؛ نباید دو شاهد مستقل و دو مبلغ جدید ساخته شود.
آزمون ششم: تغییر اطلاعات شناخت مشتری بعد از ایجاد هشدار؛ زمان مؤثر نسخه داده و سابقه بررسی قبلی باید حفظ شود.
معیار پذیرش شامل میزان پوشش داده، توان ردیابی هشدار تا تراکنش، شفافیت دلایل، خطای اولویت‌بندی، امنیت دسترسی و امکان بازبینی انسانی است. آستانه ثابت ملی یا درصد دقت مدل را از این مثال‌ها نمی‌توان استخراج کرد.
اجرای آزمایشی چهار هفته‌ای
هفته اول: دامنه پایش مجاز، انواع مشتری، داده‌های تراکنش، منابع شناخت مشتری، مالکان داده و مسئولان تصمیم را مشخص کنید. الزامات قانونی و سازمانی ایران باید توسط کارشناس ذی‌صلاح بررسی شوند.
هفته دوم: جدول تراکنش‌های معتبر، نمایه نسخه‌دار فعالیت مورد انتظار و ثبت شواهد را بسازید. چند پرونده ساختگی با نتیجه از پیش تعیین‌شده آماده کنید.
هفته سوم: موتور قاعده‌محور برای ساخت هشدار را مستقل از مدل زبانی آزمون کنید؛ AI صرفاً می‌تواند توضیح و سازمان‌دهی شواهد را انجام دهد. خطاهای مثبت کاذب و موارد جاافتاده را با بازبینی مستقل تحلیل کنید.
هفته چهارم: فهرست هشدارهای باز، دلایل اولویت، کیفیت شواهد، زمان بررسی و وضعیت تأیید انسانی را در یک داشبورد قرار دهید. فقط پس از قبولی آزمون امنیت و کنترل حرفه‌ای، استفاده محدود از داده مجاز واقعی را بررسی کنید.
فرصت نرم‌افزاری برای حسابداران برتر
پیشنهاد توسعه «موتور هوشمند پایش تراکنش‌های غیرعادی و کاربرگ رسیدگی مبتنی بر ریسک» است؛ ماژولی برای واحدهای مجاز کنترل مالی، تطبیق و مؤسسات مالی که داده تراکنش، نمایه مشتری و سند اقتصادی را در پرونده‌ای قابل ردیابی جمع می‌کند.
لایه قطعی باید شناسه‌سازی تراکنش، قواعد مصوب، نسخه‌بندی، ردیابی اطلاعات، صف هشدار، ثبت تاریخچه تصمیم و کنترل دسترسی را اجرا کند. لایه AI می‌تواند تفاوت رویداد جدید با رفتار مورد انتظار را توضیح دهد، موارد دارای داده ناکافی را مشخص کند و بسته شواهد را برای تحلیلگر آماده سازد.
پشتیبانی از تاریخ شمسی و میلادی، ریال و تومان، شناسه‌های قانونی معتبر، تفکیک نهادها و سطوح اختیار و حفظ محرمانگی برای طراحی مناسب ایران مهم است. این یک پیشنهاد محصول است، نه ادعای وجود قابلیت در نرم‌افزارهای فعلی مجموعه. پیش از عرضه، انطباق با قواعد و تکالیف قانونی مربوط به مبارزه با پول‌شویی، حفاظت از داده و فعالیت نهاد استفاده‌کننده باید به‌طور مستقل بررسی شود.
جمع‌بندی: هدف هوش مصنوعی کشف سؤال بهتر است، نه صدور اتهام سریع‌تر
دو تراکنش با مبلغ یکسان الزاماً وضعیت یکسانی ندارند. اما تفاوت زمینه اقتصادی نیز به‌تنهایی مجوز نتیجه‌گیری درباره تخلف نیست. سامانه قابل اتکا باید بتواند بگوید چه رویدادی رخ داده، چرا نیازمند توجه است، کدام شواهد آن را توضیح می‌دهند، چه داده‌ای هنوز نداریم و چه کسی درباره آن تصمیم گرفته است.
زنجیره مطلوب چنین است:
تراکنش معتبر ← فعالیت مورد انتظار و اطلاعات به‌روز مشتری ← معیار کنترل مصوب ← هشدار با منشأ قابل پیگیری ← بررسی شواهد موافق و مخالف ← تصمیم و تأیید انسانی.
هوش مصنوعی سرعت جمع‌آوری و تحلیل را بالا می‌برد؛ مسئولیت قضاوت و گزارش‌دهی در جایگاه قانونی و حرفه‌ای خود باقی می‌ماند.
