أتمتة استثناءات عمليات المدفوعات

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

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

ابدأ من رمز السبب، لا من النموذج

الحدس يدفعك إلى اللجوء لمُصنِّف يقرأ كل شيء ويتنبّأ بالإجراء. قاوِم ذلك في مقدّمة خط المعالجة. فحصّة كبيرة من الاستثناءات تحمل أصلاً سبباً قابلاً للقراءة آلياً. مرتجَع التحويل الآلي (ACH) يحمل رمز R، والتحويل الذي يرتدّ يحمل سبب حالة وفق معيار ISO 20022، ورد المبالغ المدفوعة بالبطاقة (chargeback) يحمل فئة سبب. بالنسبة لهذه، يكون العلاج حتمياً وينبغي أن تُشفِّره كقاعدة، لأن القاعدة قابلة للفحص والنموذج ليس كذلك.

• R01 عدم كفاية الرصيد: أعِد المحاولة وفق جدول، وضَع سقفاً لعدد المحاولات، ثم توقّف وأبلِغ بعد بلوغ السقف.
• R02 حساب مغلق: لا تُعِد المحاولة، وضَع علامة لتحديث الحساب، واكبح أي خصوم مستقبلية من ذلك الحساب.
• R03 لم يُعثَر على حساب: وجّه للإصلاح، لأن الرقم أو تفاصيل التوجيه على الأرجح خاطئة لا أن الحساب غائب فعلاً.

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

الإصلاح اقتراح مع مسار مراجعة

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

قسّم الإصلاحات حسب نطاق الأثر (blast radius). فتعبئة بنك وسيط ناقص من جدول مرجعي عملية منخفضة المخاطر وقابلة للعكس؛ فأتمِتها وسجّلها. أما تغيير رقم حساب المستفيد فليس قابلاً للعكس بمجرد تسوية الدفعة، فيبقى بيد موظف بشري حتى لو كان النموذج واثقاً. سؤال التصميم لكل نوع إصلاح هو رقم واحد: ميزانية الإيجابيات الكاذبة (false-positive budget) التي أنت مستعدّ لإنفاقها على ذلك الإجراء تحديداً. فتصحيح عنوان خاطئ يُهدر بضع دقائق، بينما تصحيح حساب خاطئ يعني دفعة مُوجَّهة إلى مكان خاطئ وعملية استرداد. هذان لا يمكن أن يتشاركا العتبة نفسها.

وحين يقترح النموذج فعلاً إصلاحاً، لا ينبغي أن يُضطرّ المُراجِع إلى إعادة بناء الحالة. جهّزها: التعليمة الأصلية، وما الذي فشل ولماذا، والإصلاح المُقترَح، والمصدر الذي جاء منه، وأي استثناءات سابقة للمستفيد نفسه. يؤكّد المُراجِع أو يتجاوز. وذلك التجاوز مثال مُعنوَن (labeled example)، وإذا التقطته مقابل الحالة المُدخَلة، حصلت على مجموعة تقييم (eval set) تنمو من صميم العمل نفسه بدلاً من عملية توسيم لمرة واحدة.

دِقّة تحليل الكيانات (entity resolution) تؤدّي عملاً أكبر مما تظن

تحت معظم استثناءات المدفوعات تقبع مشكلة مطابقة. هل هذا المرتجَع هو المستفيد نفسه المسجّل لدينا؟ هل الطرف المقابل في هذا التحويل هو الكيان القانوني نفسه الذي فحصته على قوائم العقوبات الأسبوع الماضي بتهجئة مختلفة قليلاً؟ هل المبلغ الذي عاد هو الأصل ناقصاً رسم مراسل، أم أنه دفعة مختلفة تماماً؟ هذه مشكلات تحليل كيانات ومعاملات (entity and transaction resolution)، وهي حيث يهمّ تتبّع النَّسَب (lineage). فإن لم تستطع تتبّع دفعة مُصلَحة رجوعاً إلى التعليمة التي أنتجتها وتقدّماً إلى التسوية التي أغلقتها، تحوّلت المطابقة في نهاية الربع إلى إعادة بناء يدوية.

نمطا فشل ينبغي الانتباه إليهما:

• الصحّة عند نقطة زمنية محدّدة (point-in-time correctness). حين تُدرّب نموذج إصلاح أو تُقيّمه، لا تُغذّه إلا بما كان معلوماً لحظة نشوء الاستثناء. فإن تضمّنت إحدى السمات الحلَّ الذي بلغه فريق العمليات في النهاية، فذلك تسريب (leakage)، ولن تصمد أرقامك خارج الخدمة عند الاحتكاك بالإنتاج.
• الانجراف (drift) في دليل الأطراف المقابلة. أدلّة المستفيدين وجداول المراسلين تتقادم. فإصلاحٌ كان صحيحاً في يناير مقابل تعيين رمز بنك (BIC) قديم يصبح خاطئاً في يونيو. أصدِر نسخاً (version) للبيانات المرجعية وسجّل أي نسخة قرأها إصلاح معيّن، كي يُفسَّر القرار مقابل حالة العالم في ذلك الوقت.

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