مراقبة AML المستمرة
تعيد المراقبة فحص العملاء المقبولين يوميًا مقابل قوائم محدَّثة وتنقل الجلسة عندما يتجاوز شيء جديد عتبتك - 0.07 دولار سنويًا، دون أي تكامل إضافي.
تعيد المراقبة فحص كل جلسة سبق قبولها يوميًا مقابل قوائم محدَّثة. أي نتيجة جديدة تتجاوز عتبة المراجعة لديك تنقل الجلسة إلى In Review؛ وأي نتيجة تتجاوز عتبة الرفض تنقلها إلى Declined. في الحالتين تحصل على webhook من نوع status.updated. التكلفة 0.07 دولار سنويًا، ولا تحتاج إلى أي تكامل إضافي.
#لماذا لا يكفي فحص لمرة واحدة
الفحص عند الإعداد يخبرك بما قالته القوائم في ذلك اليوم. تُضاف تصنيفات جديدة، وتتراكم وسائل الإعلام السلبية، ومن كان نظيفًا في مارس قد يخضع للعقوبات في أغسطس. إذا كان التزامك يشمل إبقاء العناية الواجبة تجاه العملاء محدَّثة - وهو ما ينطبق على معظم الأعمال الخاضعة للتنظيم - فإن فحصًا واحدًا لا يفي بذلك.
#كيف تعمل
تتوفر المراقبة تلقائيًا للجلسات التي أُجري فيها فحص AML، دون أي عمل تكامل إضافي:
- اختر الأشخاص الذين تريد الاستمرار في فحصهم، ثم فعّل المراقبة.
- ضع علامة على الأشخاص الذين تريد الاستمرار في فحصهم - المراقبة لكل شخص، لا لكل مؤسسة.
- أي تطابق جديد يعيد فتح الجلسة، لذا يظهر هنا بدلًا من صندوق وارد.
- فحوص يومية آلية. تُعاد فحص كل جلسة سبق قبولها مقابل قاعدة بيانات قوائم المراقبة والعقوبات الكاملة.
- مقارنة العتبات. تُقارَن النتائج الجديدة مقابل عتبتي المراجعة والرفض نفسيهما اللتين ضبطتهما في سير عملك.
- تغيير الحالة. أي نتيجة جديدة تتجاوز عتبة المراجعة تنقل الجلسة إلى In Review. وفوق عتبة الرفض، تنقلها إلى Declined.
- Webhook. يتلقى تطبيقك webhook من نوع
status.updatedمع الحالة المحدَّثة وتفاصيل النتائج الجديدة، بنفس صيغة أي webhook آخر. - الكونسول. يظهر التغيير على الجلسة مع النتائج الجديدة جاهزة للحل.
#ما يجب أن تصمم من أجله
يمكن أن تغيّر الجلسة المقبولة حالتها لاحقًا. إذا كان تكاملك يعامل Approved كحالة نهائية ويتوقف عن الاستماع، فستفوّت بالضبط الأحداث التي وُجدت المراقبة لتوصيلها.
على وجه التحديد:
- استمر في معالجة
status.updatedللجلسات التي سبق أن وسمتها كمُتحقَّق منها. - لا تتجاهل webhook لمجرد أن الجلسة أغلقتها قبل أسابيع.
- اجعل حالة المستخدم الخاصة بك قادرة على الخروج مجددًا من حالة "مُتحقَّق منه" - وهذا عادةً هو التغيير الأصعب، لأنه قرار متعلق بالمنتج لا مجرد معالج برمجي.
تُطلَق webhooks فقط عندما تتغير الحالة فعليًا. عدم وجود نتيجة جديدة تتجاوز العتبة يعني عدم وجود حدث - لذا فإن الصمت هو الحالة الطبيعية وليس دليلًا على أن المراقبة لا تعمل. إذا احتجت إلى تأكيد إيجابي، تحقق من الجلسة في الكونسول بدلًا من انتظار webhook من الطبيعي ألا يصل أبدًا.
#ما هي تكلفته
0.07 دولار سنويًا لكل شخص مُراقَب. وهي ليست جزءًا من الفئة المجانية.
تُسعَّر سنويًا لا لكل فحص، بحيث لا تُضاعِف الوتيرة اليومية التكلفة - وهذا ما يجعل المراقبة المستمرة ميسورة التكلفة عند الحجم الكبير بدلًا من أن تكون شيئًا تُقنِّنه.
#التفعيل والإيقاف
تُضبط المراقبة لكل سير عمل، إلى جانب خطوة AML. وبما أنها تنطبق على الجلسات اعتبارًا من لحظة تفعيلها، فإن تفعيلها لا يبدأ مراقبة قاعدة عملائك المقبولين الحاليين بأثر رجعي - خطط لعملية تعبئة رجعية إذا احتجت إلى تغطية العملاء التاريخيين.
#توفير الطاقم اللازم للتعامل مع النتيجة
الجزء الذي تُقلل الفرق من شأنه ليس التكامل - بل أن المراقبة تولّد طابورًا متكررًا. تحتاج النتيجة الجديدة إلى نفس عمل الحل الذي تحتاجه نتيجة الإعداد: هل هذا عميلك، وهل يهم الأمر، ودوّن السبب. راجع التعامل مع نتائج AML.
إذا لم يتولَّ أحد مسؤولية ذلك الطابور، تنتج المراقبة تنبيهات تبقى دون قراءة، وهذا أسوأ من عدم المراقبة أصلًا - فأنت الآن لديك دليل على أنك أُبلِغت ولم تفعل شيئًا.
#المراقبة ليست مراقبة المعاملات
شيئان مختلفان بأسماء متشابهة:
- مراقبة AML تعيد فحص الشخص مقابل القوائم بمرور الوقت. هذه المقالة.
- مراقبة المعاملات تقيّم المعاملات مقابل قواعد أثناء حدوثها. راجع كيف تعمل مراقبة المعاملات.
قد تحتاج إلى كليهما فعلًا، وهما تُفوتَران بشكل منفصل.