الذكاء الاصطناعي لتحديد المركز النقدي والتنبؤ به في الخزينة

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

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

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

ابدأ بالتصنيف، لا بالنموذج

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

هذا الإسناد هو موضع الهندسة الحقيقية، وهو مشكلة تصنيف بميزانية صارمة للإيجابيات الكاذبة (false positives). سطر كشف حساب بنكي يقرأ “SEPA CT REF 88213 ACME HLDG” يجب أن يُحلّ إلى طرف مقابل وكيان وعملة، ومثاليًا إلى الفاتورة التي يسدّدها. إن حلّ الكيانات (entity resolution) عبر نظام تخطيط الموارد (ERP) وتغذيات البنوك ونظام إدارة الخزينة (TMS) هو ما يقرر ما إذا كان المقبوض يستقر في الحساب الصحيح وفي اليوم الصحيح. إن أخطأته انحرف المركز دون سبب ظاهر، وهذا أسوأ من انحراف لسبب تستطيع رؤيته.

نبني هذا كخط أنابيب موسوم (labelled pipeline) مع مسار تدقيق:

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

المعالجة المباشرة (straight-through processing) هي الهدف للأغلبية عالية الثقة. أما المتبقي فيذهب إلى طابور يفرغه محلل في دقائق، وكل تصحيح يدوي يغدو تسمية تدريبية جديدة.

الصحة عند نقطة زمنية محددة هي اللعبة كلها

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

الدفاع هو أخذ لقطة (snapshot) لكل مُدخل كما كان في تاريخ التنبؤ ومنع أي استشراف مستقبلي (lookahead). وبشكل ملموس:

• خزّن كشوف الحسابات البنكية والبنود المفتوحة والجداول مع الطابع الزمني الذي أصبحت فيه معلومة، لا مجرد تاريخ قيمتها (value date).
• عند بناء متجه السمات لتاريخ التنبؤ T، استعلم عن العالم كما كان في T، بما في ذلك حقيقة أن بعض الفواتير كانت ما تزال مفتوحة وبعض المدفوعات ما تزال معلّقة.
• أعد بناء الاختبارات الرجعية بالطريقة نفسها، بتحريك موعد قطع متنقل عبر التاريخ، بحيث يكون الخطأ المُبلَّغ عنه هو الخطأ الذي ستحصل عليه فعلًا.

إن مخزن سمات (feature store) يخدم اللقطات كما كانت (as-of snapshots) يجعل هذا قابلًا للتنفيذ بدل أن يكون مشروع تنقيب أثري في كل تحليل. كما يمنحك التسوية التي تحتاجها للتدقيق: يمكن إعادة تشغيل كل تنبؤ في مواجهة المُدخلات نفسها التي رآها بالضبط، وهذا مهم حين يسأل أمين خزينة أو مدقق عن سبب انحراف رقم الثلاثاء الماضي.

انمذج المتبقي وكمّم عدم اليقين

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

نلائم توزيعات توقيت لكل فئة (per-category timing distributions) بدل تقدير نقطي وحيد. عميل بشروط سداد 30 يومًا اعتاد أن يدفع في اليوم الرابع والثلاثين بانحراف معياري خمسة أيام ينبغي أن يزيح المقبوض المتوقع ويوسّع نطاق ذلك اليوم، لا أن يحرّك نقطة فحسب. المخرج مركز يومي مع فترة ثقة، بحيث يرى أمين الخزينة ليس الرقم المركزي وحسب بل أين يقع فعلًا خطر العجز أو الرصيد الخامل.

انضباطان تشغيليان يبقيان الأمر أمينًا مع الوقت:

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

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