تخطّ إلى المحتوى
كل الرؤى الذكاء الاصطناعي للخزانة والمدفوعات

التحقق من المستفيد (Verification of Payee): كيف تجتاز مرحلة التطبيق

التحقق من المستفيد في الاتحاد الأوروبي ساري المفعول لمقدّمي خدمات الدفع في منطقة اليورو منذ أكتوبر 2025. ما الذي يفرضه فحص الاسم فعلياً على محرّكات المطابقة وملفات الشركات المجمّعة والبيانات الرئيسية.

5 دقائق قراءة #مدفوعات#احتيال#امتثال
متخصصون في القطاع المالي يعملون على مبادرة للذكاء الاصطناعي

منذ أكتوبر 2025، على مقدّم خدمات الدفع (PSP) في منطقة اليورو الذي ينفّذ تحويلاً دائناً أن يتحقّق أولاً مما إذا كان اسم المستفيد الذي قدّمه الدافع يطابق الاسم المسجّل على الحساب خلف رقم الحساب المصرفي الدولي (IBAN). دخل كتاب قواعد نظام التحقق من المستفيد (Verification of Payee) الصادر عن المجلس الأوروبي للمدفوعات (EPC) حيّز النفاذ في 5 أكتوبر 2025، وتبعه الالتزام القانوني بموجب لائحة المدفوعات الفورية في 9 أكتوبر 2025 لمقدّمي الخدمات في منطقة اليورو، مع إمهال مقدّمي الخدمات في دول الاتحاد خارج منطقة اليورو حتى 9 يوليو 2027. خُفّف وقع التطبيق بثلاث موجات انضمام ومنصّة اختبار وشهادة ذاتية من المجلس الأوروبي للمدفوعات، لكن الواقع التشغيلي قائم الآن: رحلة ذهاب وإياب عبر واجهة برمجية (API) بين مقدّمي خدمات الدفع، لكل دفعة، قبل الترخيص.

تُقرأ اللائحة وكأنها حماية بسيطة للمستهلك. أما الهندسة تحتها فبعيدة كل البعد عن البساطة، والشركات على جانب الإرسال في ملفات المدفوعات المجمّعة تكتشف أن التحقق من المستفيد هو في الخفاء برنامج بيانات رئيسية (master data) يرتدي شارة ضابط مكافحة احتيال.

المملكة المتحدة أجرت هذه التجربة أولاً. وصل تأكيد المستفيد (Confirmation of Payee) هناك عام 2019 كمبادرة سوق محلية، والدرس الذي خلّفه ذو حدّين: فحص الاسم يقلّل حقاً المدفوعات الموجّهة خطأً ومدفوعات الاحتيال، وهو يولّد احتكاكاً فعلياً حيثما اختُصرت الأسماء، أو اختلفت الأسماء التجارية عن الأسماء القانونية، أو تعارضت سجلّات الحسابات مع ما يتوقّعه الدافع. النسخة الأوروبية ترث الشقّين معاً، على مستوى ستّ وثلاثين دولة، مضمّنة في لائحة ملزمة لا في مرفق سوقي.

محرّك المطابقة هو المنتَج

القراءة الساذجة للتحقق من المستفيد هي تساوي السلاسل النصية بين مدخل الدافع وسجلّ صاحب الحساب. لا يمكن لأي نظام إنتاجي أن يعمل بهذه الطريقة. “Muller GmbH” مقابل “Müller Gesellschaft mit beschränkter Haftung”، و”J. van der Berg” مقابل “Johannes van der Berg”، واسم منقول حرفياً (transliterated) مقابل أصله بالحروف الأصلية: المقارنة الحرفية تفشل فيها جميعاً، وكل عدم تطابق كاذب هو دفعة مشروعة محجوبة ودافع يتدرّب على عدم الثقة بالتحذيرات.

على طبقة المطابقة أن تُطبّع قبل أن تقارن: حالة الأحرف، وعلامات الترقيم، والمسافات، وعلامات التشكيل (diacritics)، ولواحق الكيانات القانونية واختصاراتها، والصيغ المختصرة الشائعة للأسماء الأولى، وأعراف ترتيب الأسماء المحلية. ثم عليها أن تضع النتيجة ضمن دلالات استجابة النظام: تطابق (match)، أو تطابق قريب (close match)، أو عدم تطابق (no match)، أو غير متوفّر (unavailable)، على أن يحمل نطاق التطابق القريب اسم المستفيد الذي يحتفظ به الطرف المستجيب، ليرى الدافع ما يقوله السجلّ فعلاً.

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

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

الشركات: مشكلة الملفات المجمّعة

بالنسبة إلى فرق الخزانة والذمم الدائنة، لا وجود لتدفّق المستهلك، أي تحذير على شاشة وقرار بالمضيّ. تغادر المدفوعات عبر دفعات نظام تخطيط الموارد (ERP)، وقنوات الاتصال المباشر (host-to-host)، وبروتوكول EBICS، وملفات SEPA، بآلاف البنود في المرة الواحدة. المعالجة الآلية بين الأنظمة (machine-to-machine) لنتائج التحقق هي المطلوب، واللائحة تقرّ بعدم التوافق هذا: يجوز للدافعين من غير المستهلكين الإعفاء من الخدمة، ويجوز لهم العودة إليها.

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

الانكشاف الأعمق للشركات هو جودة البيانات. مورّد يُخزَّن اسمه القانوني بثلاث صيغ مختلفة عبر سجلّ المورّدين الرئيسي في نظام تخطيط الموارد (ERP) ونظام إدارة الخزانة (TMS) والنظام المحلي لشركة تابعة سيولّد حالات عدم تطابق على مدفوعات مشروعة تماماً. التحقق من المستفيد يدقّق فعلياً في بياناتكم الرئيسية للمستفيدين في كل تشغيل، في بيئة الإنتاج، مع تأخيرات الدفع بوصفها تقرير الأخطاء. الشركات التي كانت قد استثمرت في تنظيف سجلّ المورّدين قبل أكتوبر 2025 مرّ عليها التطبيق كأنه لم يحدث؛ أما التي لم تفعل فتقوم الآن بالتنظيف تحت ضغط تشغيلي، وهي الطريقة المكلفة.

ما يفعله بالاحتيال وما لا يفعله

اقتصاديات النظام تستهدف احتيال الدفعات المصرَّح بها (authorised push payment fraud) وإعادة توجيه الفواتير: هجمات تعتمد على إقناع دافع بإرسال المال إلى حساب يسيطر عليه المهاجم تحت اسم معقول. فحص الاسم في مواجهة الحساب قبل التنفيذ يهاجم هذا الاعتماد مباشرة، ويحوّل صنفاً من الاحتيال كان غير مرئي حتى محاولة الاسترداد إلى تحذير سابق للدفع.

الصراحة بشأن الحدود مهمّة لكل من يصمّم الضوابط المحيطة. لا يفيد التحقق من المستفيد حين يسيطر المجرم على حساب اسمه المسجّل يطابق الهوية المنتحَلة، أو حين تُخترق قناة مورّد مشروع نفسها فتأتي تفاصيل الحساب “الجديدة” مع اسم يجتاز التحقق، أو حين يتجاوز الدافع التحذير لأن الذريعة كانت مقنعة بما يكفي. الهندسة الاجتماعية تتكيّف؛ والنصوص الجاهزة تدرّب الضحايا بالفعل على تجاهل تحذيرات عدم التطابق. فحص الاسم طبقة واحدة، وأفضل عمله حين يغذّي الطبقات من حوله: تقييم الاحتيال السلوكي على الدفعة نفسها، وإشارات مخاطر حساب المستفيد، وضوابط تغيير المستفيد في إدراج المورّدين.

التشغيل: القياسات والتجاوزات وسجلّ التدقيق

عامل استجابات التحقق من المستفيد كتيار بيانات تشغيلي، لا كحكم على دفعة واحدة يُرمى بعدها. ثلاث ممارسات تفصل بين نشر يعمل فعلاً وخانة امتثال تُعلَّم بالصح.

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

الأسئلة الشائعة

هل ينبغي للشركة استخدام الإعفاء وإيقاف التحقق من المستفيد (VoP) للمدفوعات المجمّعة؟

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

من يتحمّل المسؤولية عند تجاوز تحذير تطابق قريب (close match) ثم تبيّن أن الدفعة احتيال؟

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

هل تغذّي رموز استجابة التحقق من المستفيد (VoP) شيئاً غير قرار الدفع؟

ينبغي لها ذلك. عدم التطابق مع مورّد قديم العلاقة عيب في البيانات الرئيسية يستحقّ الإصلاح عند المصدر. وعنقود من التطابقات القريبة على حساب مستفيد واحد من عدّة دافعين إشارة احتيال تستحقّ التصعيد. والاستجابات المتكرّرة بعدم التوفّر من مقدّم خدمات دفع مستجيب واحد مسألة اعتماد تشغيلي تستحقّ الطرح في نقاشات علاقتكم المصرفية. حين تُعامل نتائج التحقق كقياسات تشغيلية (telemetry) لا كبوّابة، فإنها تحسّن جودة البيانات وكشف الاحتيال وإدارة المورّدين.

قراءات ذات صلة

#مدفوعات

تشغيل SEPA Instant كنموذج تشغيلي

SEPA Instant مشكلة سيولة وضوابط على مدار الساعة ترتدي شارة المدفوعات. التمويل المسبق، وميزانيات العشر ثوانٍ، والمخاطر اللحظية لمسار لا يتوقف.

#احتيال

كشف عمليات الاحتيال والاحتيال بالدفع الفوري المُصرَّح به

في الاحتيال بالدفع الفوري المُصرَّح به (APP fraud) يقوم العميل نفسه بالتصريح بالدفعة. إليك كيف نُقيّم إشارات النية والإكراه للتدخّل دون حظر التحويلات المشروعة.

#البيانات-الأساسية

تنظيف بيانات الموردين والعملاء الأساسية باستخدام الذكاء الاصطناعي

السجلات الأساسية المكرّرة وغير المتطابقة تسبّب مدفوعات مزدوجة وتعطّل عمليات المطابقة. إليك منهج حلّ الكيانات (entity resolution) الذي نتبعه لتنظيفها.

#مدفوعات

تنسيق المدفوعات (payment orchestration) والتوجيه الذكي

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

تعمل على شيء مشابه؟

أخبِرنا عن بياناتك وسير العمل المحيط بها، وسنعطيك رأياً صريحاً.

احجز مكالمة تعريفية مدتها 30 دقيقة