auxmoney: ائتمان قائم على الأحداث في أكبر سوق قروض بألمانيا

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

يلا على الجزء الأكثر إثارة فعلاً.

ما هي auxmoney

auxmoney أكبر سوق قروض في ألمانيا - منصة إقراض من نظير لنظير تربط المقترضين الأفراد بالمستثمرين المؤسسيين والأفراد. الحجم حقيقي. الإطار التنظيمي جدي. BaFin وGDPR وتوجيه الائتمان الاستهلاكي وقانون الإقراض الألماني - كل إطار من هذه له أسنان تعض بشكل مختلف حين تحرّك قرارات ائتمانية بالحجم.

انضممت كـPrincipal Software Engineer وArchitect. الوصف الوظيفي كان ما تسمّيه auxmoney “Playing Captain”: عميق اليدين في قاعدة الكود، ليس فقط رسم مربعات على الألواح البيضاء. كان يُتوقع مني فهم النظام بعمق كافٍ لتغييره، لا فقط مراجعة تغييرات الآخرين. هذا الفرق مهم ومقلَّل من شأنه. الهندسة المعمارية غير المرسّخة في كيفية عمل الكود فعلاً هي خيال علمي.

مسار تقييم الائتمان

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

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

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

قابلية التفسير التنظيمية ليست اختيارية؛ إنها المنتج

هذا هو الشيء الذي يشكّل كل قرار معماري في fintech أوروبي والذي تُقلّله محادثات المؤتمرات بشكل منهجي.

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

هذا يغيّر كيفية تصميم خط الأحداث. الأحداث غير قابلة للتغيير. تحمل metadata أكثر من payload في بعض الحالات: من أطلق القرار، أي نسخة نموذج استُشيرت، أي قاعدة اشتعلت، كيف بدت بيانات الإدخال وقت القرار. كل ذلك يبقى سنوات. على Kubernetes هذا يعني exactly-once consumer semantics وmessage handlers متكافئة وdead-letter queues تُراقَب فعلاً. اسألني شفت كام dead-letter queue متعاملة كأنها تخزين للكتابة فقط. الإجابة: كثير جداً.

إدخال أتمتة AI/LLM إلى مسار منظَّم

النموذج ليس الجزء الصعب. تمرير أتمتة LLM عبر مراجعة الامتثال، في مسار ائتمان إنتاجي، في بيئة مالية منظَّمة - هذا هو الجزء الصعب.

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

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

الهندسة المثيرة في نقطة تكامل الـseam: كيف يُتحقَّق من ناتج LLM قبل دخوله مسار القرار، وكيف تُبوّب عتبات الثقة القرار الأوتوماتيكي مقابل المراجعة اليدوية، وكيف يتفاعل تثبيت نسخة النموذج مع بقية إصدار schema الأحداث. لا شيء من هذا في أي درس تعليمي. إنه في الأماكن التي تلتقي فيها الهندسة المعمارية المجردة بالمتطلب التنظيمي المحدد.

Playing Captain في قاعدة كود عمرها عقد

“Playing Captain” ليست لقباً. إنها وصف لكيفية عملك. يداك في الكود، ليس فقط في الوثائق.

في قاعدة كود fintech تعمل منذ عقد، هذا يعني التنقل في ما يوجد فعلاً. خدمات PHP تسبق ترحيل Kubernetes. Microservices بـJava تسبق تبنّي Kafka. أدوات جديدة أنجزها شخص الربع الماضي. هذه ليست مشاكل legacy تخجل منها - إنها استثمار متراكم في نظام يتخذ قرارات ائتمانية حقيقية لمقترضين حقيقيين منذ سنوات. لا يمكنك تجاهلها ولا إعادة كتابتها كلها هذا الربع.

فتبني عند الحدود. تنشر domain events من حواف الأنظمة القديمة. تُعرّف العقد على مستوى Kafka topic وتدع كل خدمة تملك تنفيذها. خدمة PHP التي هي مصدر الحقيقة لحالة المقترض لا تُستبدل هذا الـsprint - بل تُلفَّف في واجهة أحداث تسمح لمسار تقييم الائتمان الجديد باستهلاكها دون معرفة تفاصيلها الداخلية. هذا هو النوع الوحيد من الترحيل الذي يصل للإنتاج فعلاً.

AWS تحت كل هذا: EKS لأحمال Kubernetes، MSK لـKafka المُدارة، RDS للحالة العلائقية التي تحتاج أن تكون علائقية. البنية التحتية ليست غريبة الأطوار. المشاكل في النطاق والأنظمة، لا في المنظومة التقنية.

ما يتركه لك هذا النوع من العمل

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

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

أعمل الآن على مشروع مفتوح المصدر Fulcrum - منصة تحكم local-first للوكلاء - ومتاح لمحادثات fintech والبنية التحتية المالية. إن كنت تبني بنية تحتية ائتمانية قائمة على الأحداث وتريد مقارنة ملاحظات حول طبقة تكامل الامتثال تحديداً، تعرف أين تجدني.