اصل اول: به سامانه‌های موجود دست نمی‌زنیم
در یک بانک، کارگزاری یا شرکت بیمهٔ بزرگ، سامانهٔ اصلی سال‌ها کار کرده و تغییرش پرخطر و پرهزینه است. برای همین یال‌تک فقط از سامانه‌ها می‌خواند. اتصال‌دهنده‌ها داده را از سامانهٔ اصلی بانکی، سامانهٔ معاملات، سامانهٔ صدور و خسارت یا انبارهٔ داده می‌خوانند و چیزی در آن‌ها نمی‌نویسند.
منابعی که پشتیبانی می‌شوند
- پایگاه‌های دادهٔ Oracle، SQL Server و PostgreSQL، با دسترسی فقط‌خواندنی یا از نسخهٔ تکثیرشده؛
- جریان‌های رویداد Kafka برای تراکنش‌ها و معاملات نزدیک به زمان واقعی؛
- فایل‌های دسته‌ای CSV که از راه SFTP می‌رسند؛
- APIهای REST سامانه‌های داخلی و بیرونی.
برای هر منبع یک نگاشت تعریف می‌شود: کدام جدول یا رویداد به کدام نوع گره یا یال تبدیل شود و کدام ستون‌ها ویژگی آن باشند. نگاشت‌ها نسخه دارند؛ اگر ساختار منبع عوض شد، معلوم است از چه تاریخی کدام نگاشت اجرا شده است.
تطبیق موجودیت و ساختن گراف
یک مشتری ممکن است در سامانهٔ سپرده با یک املا، در سامانهٔ تسهیلات با املای دیگر و در فهرست ضامن‌ها با شناسهٔ ناقص ثبت شده باشد. اگر این سه سطر سه گرهٔ جدا شوند، گراف تصویر غلطی می‌دهد. تطبیق موجودیت پیش از ساختن گراف سوابق مربوط به یک شخص یا شرکت را به هم وصل می‌کند؛ با قاعده‌های قطعی مثل کد ملی و شناسهٔ ملی و با قاعده‌های تقریبی مثل شباهت نام و نشانی.
هر ادغام قابل توضیح است. کارشناس می‌بیند چرا دو سطر یکی فرض شده‌اند و می‌تواند ادغام نادرست را باز کند. نتیجه در انبارهٔ گراف نگهداری می‌شود که برای پرس‌وجوهای چندگامی ساخته شده است، مثل «همهٔ شرکت‌هایی که با سه گام به این شخص می‌رسند».
موتور قاعده و کتابخانهٔ مقررات
قاعده‌ها روی گراف اجرا می‌شوند. هر قاعده یک الگوست، مثلاً چرخهٔ ضمانت یا واریزهای خرد به یک حساب، به‌همراه آستانه‌هایی که سازمان تنظیم می‌کند. کتابخانهٔ مقررات هر قاعده را به ماده یا دستورالعملی که به آن مربوط است پیوند می‌دهد. وقتی ناظر می‌پرسد «برای مادهٔ ۷ چه کنترلی دارید؟»، پاسخ فهرستی از قاعده‌ها با تاریخچهٔ تغییرشان است.
آستانه‌ها در کد نیستند. سقف گزارش‌دهی، بازهٔ زمانی و کمینهٔ اندازهٔ خوشه پارامترهایی‌اند که مسئول انطباق تنظیم می‌کند و هر تغییرشان سابقه دارد. فهرست الگوهای آماده را در نوشتهٔ ۱۳ الگوی تقلب و انطباق آورده‌ایم.
از هشدار تا گزارش
جریان کار در یال‌تک این مسیر را طی می‌کند:
- قاعده هشدار صادر می‌کند و زیرگرافی را که دلیل هشدار است همراهش می‌گذارد؛
- هشدار به پرونده تبدیل می‌شود و به کارشناس یا گروه مسئول می‌رسد؛
- کارشناس بررسی می‌کند، استعلام می‌گیرد، یادداشت می‌نویسد و پیش‌نویس گزارش معاملهٔ مشکوک را آماده می‌کند؛
- مسئول انطباق پیش‌نویس را تأیید می‌کند یا با توضیح برمی‌گرداند؛
- گزارش تأییدشده در قالب ساختاریافته یا با وب‌هوک به کانالی می‌رود که سازمان برای ارسال به مرکز اطلاعات مالی یا ناظر به کار می‌برد.
یال‌تک کانال رسمی ارسال به مرکز را جایگزین نمی‌کند. هر سازمان روش و سامانهٔ خودش را برای این کار دارد و یال‌تک خروجی را به همان شکلی تحویل می‌دهد که آن سامانه می‌خواهد.
درگاه استعلام
بخشی از داده بیرون از سازمان است: سوابق چک و تسهیلات، وضعیت مالیاتی، پرونده‌های قضایی، فهرست‌های تحریم و دادهٔ ثبتی شرکت‌ها. درگاه استعلام یال‌تک برای هر منبع مشخص می‌کند کدام گروه‌ها مجازند، سهمیهٔ روزانه چقدر است و ثبت هدف استعلام الزامی است یا نه. هر استعلام کد پیگیری می‌گیرد و پاسخش در پرونده می‌ماند.
این طراحی مستقیماً از مادهٔ ۶ و ۸ قانون مبارزه با پول‌شویی می‌آید: اطلاعات دستگاه‌ها باید در دسترس باشد، اما فقط برای کشف جرم و با ردپای قابل بازرسی.
امنیت و استقرار
یال‌تک در قالب کانتینر و درون مرکز دادهٔ خود سازمان مستقر می‌شود و داده از شبکهٔ سازمان بیرون نمی‌رود. کاربران از راه SSO و با Active Directory یا LDAP سازمان وارد می‌شوند و حساب و رمز جداگانه لازم نیست.
| موضوع | رویکرد |
|---|---|
| محل استقرار | کانتینر درون مرکز دادهٔ سازمان (on-premise) |
| ورود کاربران | SSO با Active Directory یا LDAP |
| دسترسی | نقش‌محور، در سطح فضا، پرونده و نوع داده |
| شناسه‌های حساس | ماسک کد ملی و شماره‌های هویتی برای نقش‌های غیرمجاز |
| ممیزی | گزارش تغییرناپذیر از مشاهده، استعلام، خروجی و تغییر قاعده |
| نگهداری سوابق | دورهٔ قابل تنظیم، هم‌خوان با نگهداری پنج‌سالهٔ مادهٔ ۷ |
چه کسانی با سامانه کار می‌کنند
در یک سازمان بزرگ چند نقش با سامانه سروکار دارند و هر کدام فقط بخشی از آن را می‌بیند:
- کارشناس انطباق یا تقلب هشدارها و پرونده‌های گروه خودش را بررسی می‌کند و پیش‌نویس گزارش می‌نویسد؛
- مسئول انطباق قاعده‌ها و آستانه‌ها را تنظیم می‌کند و گزارش‌ها را تأیید می‌کند؛
- مدیر سامانه کاربران، گروه‌ها، منابع داده و درگاه‌های استعلام را مدیریت می‌کند و لازم نیست محتوای پرونده‌ها را ببیند؛
- حسابرس داخلی یا بازرس گزارش ممیزی و تاریخچهٔ تصمیم‌ها را فقط می‌خواند.
جدا کردن این نقش‌ها بخشی از همان کنترل داخلی است که مادهٔ ۷ می‌خواهد. مدیر سامانه‌ای که پرونده‌ها را بخواند، یا کارشناسی که آستانهٔ قاعده‌ای را تغییر دهد که هشدارهایش را خودش بررسی می‌کند، نقطهٔ ضعف کنترل است. در یال‌تک هر دو حالت با تعریف نقش‌ها قابل جلوگیری است.
مرحله‌های اجرا
استقرار در سازمان بزرگ یک‌باره انجام نمی‌شود. چهار مرحله پیشنهاد می‌کنیم:
- شناخت و نگاشت داده: انتخاب یک خط کسب‌وکار برای آزمایش، فهرست منابع، بررسی کیفیت داده و نگاشت به مدل گراف؛
- آزمایش با دادهٔ تاریخی: اجرای قاعده‌ها روی دادهٔ گذشته، مقایسه با پرونده‌هایی که سازمان قبلاً کشف کرده و تنظیم آستانه‌ها؛
- بهره‌برداری: اتصال به دادهٔ جاری، راه‌اندازی جریان پرونده و گزارش و آموزش کاربران؛
- گسترش: افزودن واحدهای دیگر، منابع تازه و قاعده‌های بیشتر.
آزمون روی دادهٔ تاریخی مهم‌ترین مرحله است. اینجا معلوم می‌شود قاعده‌ها چند هشدار می‌سازند، چه سهمی از آن‌ها به پرونده‌های واقعی گذشته می‌رسد و تیم انطباق ظرفیت بررسی چند هشدار در روز را دارد. تصمیم دربارهٔ آستانه‌ها با همین عددها گرفته می‌شود، نه با حدس.
پیش از شروع چه چیزهایی لازم است
- یک مالک کسب‌وکار در واحد انطباق یا ریسک؛
- دسترسی فقط‌خواندنی به منابع داده یا نسخهٔ تکثیرشدهٔ آن‌ها؛
- محیط کانتینری یا ماشین مجازی در مرکز داده؛
- هماهنگی با واحد حقوقی دربارهٔ دامنهٔ استعلام‌ها و دورهٔ نگهداری.
معماری کامل را روی شکل در صفحهٔ استقرار سازمانی ببینید.
منابع
این مطلب تحلیل عمومی است و نظر حقوقی نیست؛ پیش از اجرا با واحد حقوقی تطبیق دهید.