پایش تراکنش، پرهزینهترین بخش هر برنامهٔ تطبیق است — نه بهخاطر پردازش، بلکه بهخاطر نیروی انسانی که باید هشدارها را بررسی کند. طراحی درست، همانقدر که دربارهٔ کشف است، دربارهٔ نکشتنِ ظرفیت بررسی است.
شناسایی مشتری، عکسی از یک لحظه است؛ پایش تراکنش، فیلمی از یک دوره. آییننامه اجرایی ماده ۱۴ الحاقی قانون مبارزه با پولشویی هر دو را میخواهد، اما تکلیف مربوط به دومی در یک مادهٔ کوتاه فشرده شده که پیامدهای فنی گستردهای دارد.
ماده ۸۱: نظارت خودکار، دادهکاوی، دو سال
ماده ۸۱ (اصلاحی ۱۴۰۴/۰۷/۲۷) مقرر میدارد مؤسسات مالی و بانک مرکزی جمهوری اسلامی ایران مکلفاند ظرف دو سال پس از تصویب آییننامه، بهمنظور ایجاد فرآیند نظارت خودکار جهت شناسایی عملیات مالی یا معاملات مشکوک به پولشویی و تأمین مالی تروریسم، نسبت به استقرار نرمافزارهای کشف تقلب بر روی همهٔ سامانههای خود، مبتنی بر روشهای دادهکاوی و مطابق با استاندارد الگوی رفتار مالی اقدام کنند.
چهار قید در این یک جمله وجود دارد که هرکدام یک تصمیم معماری را تحمیل میکنند:
- «نظارت خودکار» — یعنی بررسی نمونهای و دستی، اجرای این ماده نیست.
- «همهٔ سامانههای خود» — پوشش نباید به هستهٔ بانکی محدود شود. کارت، همراهبانک، اینترنتبانک، درگاه پرداخت، حواله و سایر کانالها هم مشمولاند.
- «مبتنی بر روشهای دادهکاوی» — این عبارت آگاهانه انتخاب شده است. قاعدهٔ «هر تراکنش بالای فلان مبلغ را علامت بزن» روش دادهکاوی نیست.
- «مطابق با استاندارد الگوی رفتار مالی» — یعنی مبنای سنجش، انحراف از الگوی رفتاری است، نه صرفاً عبور از یک عدد.
چرا پوشش همهٔ کانالها سخت است
در عمل، بزرگترین مانع اجرای این ماده نه الگوریتم است و نه سختافزار؛ یکپارچگی داده است. تراکنش کارتی در سوئیچ ثبت میشود، حواله در سامانهٔ دیگری، و پروفایل مشتری در هستهٔ بانکی. اگر این سه نتوانند به یک شناسهٔ واحد اربابرجوع گره بخورند، «الگوی رفتار مالی» قابل ساخت نیست — چون رفتار، در چند سیستم پخش شده است.
به همین دلیل، پروژههای پایش تراکنش عملاً پیش از آنکه پروژهٔ تحلیل باشند، پروژهٔ یکپارچهسازی دادهاند. کیفیت داده — بهویژه یکتایی شناسه و کامل بودن اطلاعات طرف مقابل — سقف دقت هر مدلی را تعیین میکند. جمعآوری این دادهها در یک منبع واحد، همان کاری است که انبار داده برایش ساخته میشود.
سه لایهٔ پایش
تجربهٔ استقرار نشان میدهد یک سامانهٔ پایش کارآمد معمولاً سه لایه دارد که مکمل یکدیگرند:
- لایهٔ قواعد صریح. سناریوهای مبتنی بر مقررات — مثل مغایرت با سطح فعالیت مورد انتظار یا تجمیع نقدی بالای آستانه. مزیتشان توضیحپذیری کامل است؛ محدودیتشان این است که فقط چیزی را مییابند که از پیش تعریف کردهاید.
- لایهٔ رفتاری. مقایسهٔ رفتار هر مشتری با خودش در گذشته و با همگروههایش. اینجاست که «استاندارد الگوی رفتار مالی» معنا پیدا میکند: یک تراکنش پنجاه میلیونی برای یک مشتری عادی است و برای دیگری بیسابقه.
- لایهٔ شبکهای. تحلیل ارتباط میان اشخاص و حسابها — الگوهایی مانند چرخش وجه میان مجموعهای از حسابها که تکبهتک عادی بهنظر میرسند. این لایه بدون نمایش گرافی داده عملاً غیرقابل بهرهبرداری است.
هیچیک از این سه لایه جایگزین دیگری نیست. لایهٔ اول برای دفاع در بازرسی لازم است، لایهٔ دوم برای کشف موارد نوظهور، و لایهٔ سوم برای الگوهایی که در سطح تکتراکنش دیده نمیشوند.
هشدار کاذب: مسئلهای که تطبیقی است، نه فنی
فرض کنید سامانهای روزانه هزار هشدار تولید میکند و تیم بررسی، ظرفیت دویست مورد در روز را دارد. نتیجه، صف انباشتهای است که هر روز بلندتر میشود. حالا به یاد بیاورید که تبصره ۱ ماده ۱۳۵ آییننامه، ارسال گزارش معاملات مشکوک را حداکثر تا پایان همان روز کاری الزامی کرده است.
یعنی نرخ بالای هشدار کاذب صرفاً یک ناکارآمدی نیست؛ مستقیماً یک تکلیف مقرراتی را نقض میکند. طراحی سامانهای که «هرچه بیشتر بهتر» هشدار میدهد، در واقع توانایی مؤسسه در رعایت مهلت را از بین میبرد.
چند تدبیر که در عمل مؤثرند:
- اولویتبندی بهجای صف تخت. هشدارها باید امتیاز داشته باشند و صف بر پایهٔ امتیاز مرتب شود، نه بر پایهٔ زمان ورود.
- تجمیع در سطح اربابرجوع. پنج هشدار روی یک مشتری باید یک پرونده بسازد، نه پنج مورد بررسی جداگانه.
- تنظیم آستانه بر پایهٔ داده. پیش از فعالسازی هر سناریو، اجرای آن روی دادهٔ تاریخی و برآورد حجم خروجی — تا سناریویی که روزی هزار هشدار میسازد، در محیط عملیاتی کشف نشود.
- حلقهٔ بازخورد. نتیجهٔ بررسی هر هشدار (واقعی/کاذب) باید ثبت و برای بازتنظیم سناریو استفاده شود.
- ثبت دلیل بستن. هشداری که بدون دلیل مستند بسته شود، در بازرسی همانقدر مسئلهساز است که هشداری که اصلاً تولید نشده.
پایش تشدیدشده برای دستههای خاص
پایش یکنواخت برای همهٔ مشتریان، نه با رویکرد مبتنی بر ریسک سازگار است و نه با متن آییننامه. چند تکلیف صریح، پایش متفاوت را الزامی میکنند:
- بند ۷ ماده ۷۹ برای مشتریان مشمول شناسایی مضاعف، «افزایش گلوگاههای کنترلی» و «تعیین و شناسایی الگوهای تراکنشهایی که به بررسی بیشتر نیاز دارند» را میخواهد؛
- بند ب ماده ۹ مکرر برای اشخاص سیاسی خارجی، «پایش دقیق و مستمر» و انطباق تراکنشها با اطلاعات منشأ وجوه را الزامی میکند؛
- ماده ۸۲ برای اشخاص تحت مراقبت، «نظارت مستمر و بیشتر» را مقرر میدارد.
هر سه، پارامتریبودن موتور پایش را ایجاب میکنند: مجموعهٔ سناریوهای فعال و آستانههایشان باید تابعی از طبقهٔ ریسک و برچسبهای مشتری باشد، نه یک پیکربندی سراسری.
توضیحپذیری، شرط بقای مدل
وقتی از دادهکاوی و مدلهای آماری استفاده میکنید، پرسشی که دیر یا زود از سوی بازرس مطرح میشود این است: «چرا این تراکنش علامت خورد و آن یکی نه؟» مدلی که پاسخ قابلفهمی برای این پرسش ندارد، در عمل قابل استناد نیست.
به همین دلیل، در حوزهٔ تطبیق، مدل توضیحپذیر با دقت متوسط معمولاً بر مدل جعبهسیاه با دقت بالاتر ترجیح دارد. حداقل انتظار این است که برای هر هشدار، سهم عوامل مؤثر و مقادیر آنها قابل بازیابی باشد و بتوان نتیجه را با نسخهٔ مشخصی از مدل و داده بازتولید کرد. کاربردهای گستردهتر این رویکرد را در یادگیری ماشین توضیح دادهایم.
آنچه سامانه باید بتواند
- دریافت رویداد از همهٔ کانالها با نگاشت به شناسهٔ واحد اربابرجوع؛
- سه لایهٔ قواعد صریح، رفتاری و شبکهای، با امکان فعال/غیرفعالسازی مستقل؛
- پیکربندی سناریو و آستانه بر پایهٔ طبقهٔ ریسک و برچسب مشتری، نه سراسری؛
- اجرای آزمایشی سناریو روی دادهٔ تاریخی پیش از فعالسازی، با برآورد حجم هشدار؛
- تجمیع هشدار در سطح اربابرجوع و اولویتبندی امتیازمحور صف بررسی؛
- ثبت نتیجهٔ بررسی و بازگرداندن آن به چرخهٔ تنظیم سناریو؛
- نسخهگذاری مدل و سناریو، برای بازتولید هر تصمیم گذشته؛
- مسیر یککلیکی از پروندهٔ هشدار به تولید گزارش معاملات مشکوک، برای رعایت مهلت همان روز کاری.
مهلتها و قالب گزارش نهایی را در گزارش معاملات و عملیات مشکوک و مبنای طبقهبندی ریسک را در رویکرد مبتنی بر ریسک آوردهایم.
این نوشته صرفاً جنبه اطلاعرسانی دارد و جایگزین متن رسمی آییننامه یا مشاورهٔ حقوقی نیست. بخشهایی از این یادداشت، تجربهٔ اجرایی است و نه الزام صریح مقررات؛ برای اقدام به آخرین متن ابلاغی مراجعه کنید.
میخواهید ببینید این الزامات در عمل چگونه اجرا میشوند؟
بازگشت به فهرست مقالات مقالات مدیریت ریسک
