شاخص‌های معاملات مشکوک به دو شکل می‌رسند: جمله‌ای که می‌گوید چه چیزی مشکوک است، و قاعده‌ای که با عدد می‌گوید کِی. آنچه این دو را به هم وصل می‌کند، ساختار ثابتی دارد که مستقل از هر عدد، قابل طراحی است.

شاخص‌های شناسایی معاملات و عملیات مشکوک به دو شکل به مؤسسه می‌رسند. شاخص کیفی جمله‌ای است که می‌گوید چه رفتاری مشکوک است — «گردش نامتناسب با فعالیت»، «واریز خرد از شمار زیادی حساب و انتقال یکجا». شاخص کمی همان جمله است با عدد: در چه بازه‌ای، بیش از چه مبلغی، با چند تراکنش. اولی را کارشناس می‌فهمد؛ دومی را سامانه اجرا می‌کند.

فاصلهٔ این دو کم نیست. ماده ۸۱ آیین‌نامه از مؤسسات مالی پایش خودکار می‌خواهد و در بازار سرمایه، کمی‌سازی شاخص‌ها صریحاً از الزامات تأیید سامانه است. هر دو یعنی شاخص کیفی باید به قاعده‌ای تبدیل شود که بتوان اجرایش کرد، آزمودش و از آن در بازرسی دفاع کرد. این نوشته دربارهٔ ساختار چنین قاعده‌ای است — ساختاری که مستقل از هر عدد مشخص، قابل طراحی است.

پنج جزء یک قاعدهٔ کمی

وقتی ده‌ها قاعدهٔ کمی را کنار هم بگذارید، همه از اجزای یکسانی ساخته شده‌اند. تفاوتشان در مقدار است، نه در شکل:

پنج جزء یک قاعدهٔ کمی. مقدار عددی هر جزء را مؤسسه با دادهٔ خودش تنظیم می‌کند؛ ساختار قاعده ثابت است.
  • مبنای شناسایی قاعده روی چه چیزی اجرا می‌شود: تراکنش، تغییرات پروندهٔ مشتری، یا رفتار در قرارداد و تسهیلات. هر مبنا منبع دادهٔ جدای خودش را دارد.
  • جامعهٔ هدف قاعده برای چه کسی است: حقیقی یا حقوقی، مقیم یا غیرمقیم، نوع حساب. یک شاخص برای دو جامعه معمولاً دو آستانه می‌خواهد.
  • بازهٔ زمانی رفتار در چه پنجره‌ای سنجیده می‌شود: چند روز گذشته، غلتان یا تقویمی. پنجرهٔ کوتاه تند واکنش می‌دهد و پنجرهٔ بلند الگوی آهسته را می‌بیند.
  • پارامتر آستانه‌ای که قاعده را فعال می‌کند: مجموع مبلغ، شمار تراکنش، شمار طرف‌ها، یا نسبت به میانگین خودِ مشتری. اغلب دو پارامتر با هم.
  • قید زمینه‌ای شرطی که قاعده را دقیق می‌کند: شعبه یا منطقه، کد بابت تراکنش، نوع ارز یا نوع حساب.

این تفکیک فقط نظری نیست. سامانه‌ای که این پنج جزء را جدا از هم نگه دارد، می‌تواند پارامتر را بدون دست‌زدن به منطق قاعده عوض کند، یک قاعده را برای جامعهٔ تازه‌ای تکثیر کند، و در گزارش هشدار نشان دهد کدام جزء قاعده را فعال کرده است. سامانه‌ای که قاعده را یکجا در کد نوشته، هر تغییر کوچک را به یک پروژهٔ توسعه تبدیل می‌کند.

یک شاخص، دو آستانه

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

گام بعد، مقایسهٔ مشتری با خودش است. پارامتری که به‌جای عدد مطلق، «نسبت به میانگین خودِ مشتری در دورهٔ پیش» را می‌سنجد، ناهمگونی جامعه را خودبه‌خود جذب می‌کند. این همان منطق سطح فعالیت مورد انتظار است، این بار در لایهٔ قاعده.

پنجرهٔ غلتان یا تقویمی

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

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

از جمله تا قاعده

کمی‌سازی یک شاخص کیفی، یک مسیر پنج‌گامی است:

مسیر کمی‌سازی یک شاخص کیفی. گام چهارم همان است که بیشتر پروژه‌ها از آن می‌گذرند و بعد با سیل هشدار روبه‌رو می‌شوند.
  1. تعریف رخداد شاخص کیفی را به جمله‌ای تبدیل کنید که بتوان برایش «بله» یا «نه» گفت: دقیقاً چه رفتاری، از چه کسی، در چه بازه‌ای.
  2. نگاشت به داده برای هر واژهٔ آن جمله فیلدی در انبار داده پیدا کنید. واژه‌ای که فیلد ندارد، قاعده را اجرانشدنی می‌کند.
  3. پیشنهاد پارامتر آستانه را از توزیع دادهٔ خود مؤسسه بگیرید — مثلاً صدک‌های بالای گردش هر جامعهٔ هدف — نه از عددی که جای دیگری دیده‌اید.
  4. آزمون پس‌نگر قاعده را روی دادهٔ گذشته اجرا کنید: چند هشدار می‌داد، و چند مورد گزارش‌شدهٔ واقعی را می‌گرفت؟
  5. تنظیم و مستندسازی پارامتر، دلیل انتخابش و نتیجهٔ آزمون را ثبت کنید. قاعده‌ای که مستند ندارد، در بازرسی قابل دفاع نیست.

گام سوم نکته‌ای دارد که اغلب نادیده گرفته می‌شود: آستانه را از دادهٔ خودتان بگیرید. عددی که در یک مؤسسه درست کار می‌کند، در مؤسسه‌ای با ترکیب مشتری متفاوت یا بی‌اثر است یا پرهشدار. پارامتر، خروجی تحلیل توزیع دادهٔ هر مؤسسه است، نه عددی قابل انتقال.

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

چرا آستانه‌ها منتشر نمی‌شوند

شاید عجیب باشد که این نوشته دربارهٔ قواعد کمی است و حتی یک آستانهٔ واقعی ندارد. دلیلش ساده است: آستانه، نقشهٔ گریز است. کسی که بداند قاعده از چه مبلغی یا از چند تراکنش در چند روز فعال می‌شود، رفتارش را درست زیر همان مرز نگه می‌دارد. به همین دلیل ناظران پارامترهای شاخص‌های کمی را محرمانه به اشخاص مشمول ابلاغ می‌کنند، و مؤسسه هم باید پارامترهای خودش را اطلاعات طبقه‌بندی‌شده بداند — نه در مستندات عمومی، نه در ارائه‌های بیرونی، و نه در دسترس همهٔ کاربران سامانه.

این پیامد فنی هم دارد. سطح دسترسی به تعریف قاعده باید از سطح دسترسی به هشدار آن جدا باشد: کارشناس شعبه‌ای که هشدار را بررسی می‌کند، لزوماً نباید آستانه را ببیند. و تغییر پارامتر باید با ثبت کاربر، زمان و دلیل همراه باشد، تا هم قابل ممیزی باشد و هم تغییر ناخواسته یا مغرضانه آشکار شود.

قاعده بدون دیکشنری داده

بیشتر قاعده‌هایی که روی کاغذ درست‌اند و در عمل کار نمی‌کنند، در گام دوم شکست خورده‌اند: فیلدی که قاعده لازم دارد، در انبار داده نیست، یا هست و خالی است. پیش از نوشتن هر قاعده باید برای هر واژه‌اش فیلدی پیدا کرد — نوع مشتری، تاریخ افتتاح حساب، شعبه‌ای که تراکنش در آن انجام یا به آن ختم شده، کد و شرح بابت تراکنش، نوع ارز و نوع حساب، و نقش اشخاصی که در حساب اختیار دارند. و برای هر فیلد باید پرسید: از کدام سامانهٔ عملیاتی می‌آید، با چه تأخیری، و چند درصد رکوردها آن را پر دارند.

کد بابت نمونهٔ خوبی است. قاعده‌ای که دلیل تراکنش را می‌سنجد، فقط وقتی کار می‌کند که بابت در لحظهٔ ثبت، ساخت‌یافته و از فهرست بسته انتخاب شده باشد؛ اگر شرح آزاد باشد یا پیش‌فرض «سایر» بیشتر رکوردها را پوشانده باشد، قاعده عملاً کور است. این پیش از آنکه مسئلهٔ سامانهٔ مبارزه با پول‌شویی باشد، مسئلهٔ کیفیت داده است.

چه باید کرد

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

این نوشته صرفاً جنبه اطلاع‌رسانی دارد و به هیچ فهرست یا پارامتر مشخصی ارجاع نمی‌دهد. مبنای تکالیف، ماده ۸۱ آیین‌نامه و الزامات ابلاغی دستگاه متولی نظارت هر مؤسسه است؛ شاخص‌ها و پارامترهای ابلاغی ناظر را باید از مجاری رسمی و با رعایت طبقه‌بندی آن‌ها دریافت و نگهداری کرد.

می‌خواهید ببینید این الزامات در عمل چگونه اجرا می‌شوند؟


بازگشت به فهرست مقالات مقالات مدیریت ریسک