أتمتة العناية الواجبة للعملاء: بنية CDD مدركة للولاية القضائية

---

في مكان ما في قاعدة الكود الخاصة بك، توجد عبارة if تقرر مدى عمق التحقق من العميل. تفحص البلد. تفحص مستوى المخاطر. تستدعي مزودًا. عندما يغير المنظم في إسبانيا قواعد العناية الواجبة المعززة، يعدل مهندس عبارة if، يكتب اختبارًا، ينشر، ويأمل ألا يتأثر أي فرع آخر.

هكذا تعمل معظم تطبيقات CDD. وهذا أيضًا لماذا يستغرق التوسع إلى ولاية قضائية جديدة أشهرًا بدلًا من أيام: منطق الامتثال مضمن في الكود، وليس معبرًا عنه كتكوين. كل بلد جديد يتطلب عمل تطوير. كل تغيير قاعدة يتطلب دورة إصدار. كل تدقيق يتطلب مهندسًا لشرح ما يفعله الكود، لأن مسؤول مكافحة غسل الأموال لا يمكنه قراءته مباشرة.

مشكلة CDD المرمزة

النمط معروف:

if country == "DE" and risk_level == "high":
    require_enhanced_document_verification()
elif country == "ES" and risk_level == "medium":
    require_standard_address_verification()
elif country == "DE" and risk_level == "low":
    require_basic_identity_check()

مبعثر عبر قاعدة الكود. كل فرع هو قاعدة امتثال مشفرة كمنطق تطبيق. المشاكل تتراكم:

• إضافة ولاية قضائية تعني تعديل الكود. النمسا تتطلب عمق تحقق عنوان مختلفًا عن ألمانيا. سويسرا لها متطلبات توثيق مختلفة عن كليهما. كل إضافة هي تغيير كود، دورة اختبار، نشر.
• تغيير قاعدة يعني تعديل الكود. يقرر مسؤول مكافحة غسل الأموال أن العملاء عاليي المخاطر في إسبانيا يحتاجون الآن تحقق مستندات معزز بدلًا من قياسي. هذا القرار يسافر عبر تذكرة، ينتظر في قائمة السباق، ينفذه مطور قد لا يفهم السياق التنظيمي بالكامل، ويُشحن في الإصدار التالي.
• تدقيق القواعد يعني قراءة الكود. عندما يسأل المنظم "ما العناية الواجبة التي تجرونها للعملاء عاليي المخاطر في ألمانيا؟"، الإجابة تتطلب مهندسًا لتتبع مسارات الكود وشرح منطق التفرع. فريق الامتثال لا يمكنه التحقق بشكل مستقل مما يفعله النظام.

نموذج السياسة

سياسة CDD هي سجل، وليست فرع كود. لها أربعة أبعاد:

سجل السياسة يقول: "للولاية القضائية X، عند مستوى المخاطر Y، أجرِ نوع الفحص Z بعمق W." النظام يخزنها كبيانات، قابلة للاستعلام، قابلة للتنسيخ، قابلة للتدقيق من غير المهندسين.

مجموعة سياسات مثال:

منطق الحل: عند تشغيل فحص CDD، يبحث النظام عن سياسة خاصة بالولاية القضائية أولًا. إذا لم توجد، يرجع إلى GLOBAL. هذا يعني: أطلق في بلد جديد بصفر تكوين، سياسات GLOBAL تُطبق تلقائيًا. ثم أضف تجاوزات خاصة بالبلد عندما يكون فريق الامتثال جاهزًا.

سلسلة الاحتياط:

بلد جديد، اليوم الأول: سياسات GLOBAL تُطبق. لا تغيير كود. لا نشر. يضيف مسؤول مكافحة غسل الأموال تجاوزات خاصة بالولاية القضائية من خلال واجهة الإدارة عندما تتطلب اللوائح المحلية عمقًا مختلفًا.

دورة حياة السياسة

السياسات ليست ثابتة. تتطور مع تغير اللوائح ومع تحسين فريق الامتثال لشهيته للمخاطر. يجب أن تكون دورة الحياة قابلة للتدقيق:

مسودة → نشطة → مؤرشفة.

سياسة نشطة واحدة فقط يمكن أن توجد لكل مجموعة ولاية قضائية × مستوى مخاطر × نوع فحص. تفعيل سياسة جديدة يؤرشف السابقة تلقائيًا. السياسة المؤرشفة تبقى في قاعدة البيانات، غير قابلة للتغيير، قابلة للاستعلام، بطابع زمني. يمكن للمدقق إعادة بناء أي سياسة كانت سارية لأي فحص في أي نقطة زمنية.

هذا مهم أثناء الفحص التنظيمي. السؤال ليس "ما سياسات CDD الحالية؟" إنه "ما السياسة التي كانت سارية عندما أعددتم العميل X في 15 مارس؟" إذا كانت السياسات فروع كود، الإجابة تتطلب تنقيبًا في git. إذا كانت السياسات سجلات مُنسَّخة، الإجابة استعلام قاعدة بيانات.

تجريد المزود

السياسة تحدد ماذا يُفحص. واجهة المزود تحدد كيف.

فحص CDD لتحقق العنوان يمكن تنفيذه بواسطة Loqate (API تحقق العنوان)، Google Places (الترميز الجغرافي)، مراجعة مستندات يدوية، أو مزيج. السياسة تقول "تحقق من العنوان بعمق معزز." تنفيذ المزود يقول "استدعِ Loqate، قارن مع السجل البريدي، علّم التناقضات للمراجعة اليدوية."

الفصل مهم عندما يتغير المزودون. التبديل من المزود A إلى المزود B هو تغيير تكوين في طبقة المزود. لا تغيير سياسة. لا تغيير كود في محرك CDD. نوع الفحص والعمق يبقيان كما هما، فقط آلية التنفيذ تتغير.

هذا نفس النمط المستخدم للتحقق من KYC: النظام يحتاج تحقق هوية. سواء نفذه Identomat أو Onfido أو Jumio هو خيار تكوين. تدفق الإعداد لا يعرف ولا يهتم أي مزود نشط.

ملفات تعريف الولايات القضائية

كل ولاية قضائية تحمل أكثر من تجاوزات سياسة CDD. تحمل المعلمات التنظيمية التي تؤثر على العمليات:

حساب أيام العمل يستخدم تقويم عطلات الولاية القضائية. "5 أيام عمل" في ألمانيا مختلفة عن "5 أيام عمل" في إسبانيا بسبب عطلات عامة مختلفة. فترة الاحتفاظ لمعاملات SEPA R، الموعد النهائي لإكمال فحص CDD، وقت معالجة التقارير التنظيمية، كلها تعتمد على التقويم الصحيح.

مسار التدقيق

كل فحص CDD يُسجَّل كسجل غير قابل للتغيير:

• إصدار السياسة الذي كان ساريًا
• نوع الفحص والعمق
• المزود المستخدم
• النتيجة (نجاح، فشل، مراجعة يدوية)
• الطابع الزمني (الإنشاء، الإكمال)
• المراجع (إذا كان تصعيدًا يدويًا)

سجل الفحص محمي من الحذف على مستوى قاعدة البيانات (مشغل يمنع عمليات DELETE على جدول التدقيق). التصحيحات هي سجلات جديدة، وليست تحديثات للموجودة. التاريخ الكامل محفوظ.

مسار المدقق: العميل → فحوصات CDD → لكل فحص: أي سياسة كانت نشطة، أي عمق طُبق، أي مزود نفذه، ما كانت النتيجة، من راجعه (إذا يدوي). كل ذلك من بيانات منظمة قابلة للاستعلام. لا حاجة لقراءة الكود.

التأثير التشغيلي

توسع السوق بدون هندسة. ولاية قضائية جديدة؟ سياسات GLOBAL الاحتياطية تُطبق فورًا. التجاوزات الخاصة بالبلد يضيفها فريق الامتثال من خلال واجهة الإدارة. لا مطور في الحلقة.

تغييرات القواعد بدون نشر. يحدّث مسؤول مكافحة غسل الأموال سجل سياسة. السياسة الجديدة تسري على الفحص التالي. السياسة القديمة تُؤرشف. مسار التدقيق يلتقط كلا الإصدارين والطابع الزمني للانتقال.

جاهزية الفحص التنظيمي. كل فحص قابل للتتبع إلى إصدار سياسة محدد. كل تغيير سياسة بطابع زمني ومنسوب. فريق الامتثال يمكنه الإجابة على أسئلة المنظم مباشرة، بدون دعم هندسي.

مرونة المزود. عقد مزود KYC ينتهي؟ بدّل إلى مزود جديد من خلال التكوين. سياسات CDD، الماذا، تبقى دون تغيير. فقط الكيف يتغير.

---

اقرأ المزيد: بنية الامتثال | الأمان والامتثال

---

المصادر:

• AMLD5، التوجيه 2018/843، المادة 13 (تدابير العناية الواجبة للعملاء)
• AMLD6، التوجيه 2024/1640، المادة 16-18 (النهج القائم على المخاطر لـ CDD)
• GoBD (مبادئ الإدارة والحفظ السليم للدفاتر)، احتفاظ 10 سنوات
• HGB §257، فترات الاحتفاظ بالسجلات التجارية