معيار ISO 20022 كنموذج مجال وليس مشكلة XML
استمع إلى المقال
جارٍ تجهيز الصوت…
هندسة التقنيات المالية
أبدأ ISO 20022 بالمفهوم المالي لا بوسم XML. أرى قيمته في المفردات والنموذج المحكومين، لا في مشروع لمعالجة الصيغة فقط.
النموذج قبل الصيغة
يصف نموذج الأعمال الرسمي مفاهيم مالية متفقاً عليها وعلاقات تُشتق منها عناصر الرسائل. وتوضح الأسئلة الشائعة الرسمية أن المعيار يحدد منهجية تطوير ومستودعاً مركزياً، بينما XML وASN.1 صيغتا تسلسل مشتقتان.
لذلك لا تكفي عبارة «ندعم pacs.008». يجب تحديد عائلة الرسالة وإصدارها ودليل الاستخدام والسوق أو الشبكة. فالمجتمعات تقيد العناصر والتكرار وقوائم الرموز بطرق مختلفة.
استخدم مثال دفع واحداً حتى النهاية
في تحويل ائتماني لا تكفيني حقول sender وreceiver وreference. أحتاج إلى تمييز المدين والدائن والطرف المنشئ والأطراف النهائية ووكلائهم، ومعرف العملية من البداية إلى النهاية، ومعرف التعليمات والمعاملة، والغرض والمعلومات المنظمة للتحويل. قد تتشابه القيم في حالة بسيطة، لكنها تحمل أدواراً مختلفة عند التحقيق أو الإرجاع أو المطابقة.
أمرر المثال نفسه من واجهة القبول إلى النموذج الداخلي ثم رسالة السوق والاستجابة والقيد والمطابقة. عند كل حد أسأل: أي معنى احتُفظ به، وأي معنى اختُصر، وأين يوجد الدليل الأصلي؟ هذا يكشف مبكراً أن نموذج party عام أو حقل reference واحد لا يستطيع دعم دورة الحياة التي تبدو سليمة في العرض التجريبي.
لا تسطح المعنى في نموذج عام
قد يحتوي تحويل ائتماني على المدين والدائن والطرف المنشئ والأطراف النهائية والوكلاء وعدة معرفات. جمعها في party وreference يفقد الفروق التي يحتاجها التحقيق والمطابقة. أنشئ كتالوج ربط يحدد مسار المصدر، والتعريف، والإصدار، وقاعدة التحويل، ودلالة الغياب، ومدى الفقد، وصاحب القرار واختباراته.
احفظ الرسالة الأصلية المتحققة وفق سياسة الخصوصية والاحتفاظ. يستطيع النموذج الداخلي خدمة المنتج، لكن يجب أن يبقى الدليل متاحاً عندما يُختصر حقل أو يتغير تفسير السوق.
تشير صفحة ISO حول واجهات API وISO 20022 إلى إمكان استخدام دلالات النموذج في تبادلات API. لذلك يمكن أن تكون الواجهة JSON مع الحفاظ على المعاني والقيود؛ لا حاجة لنقل XML داخل كل خدمة.
اختر الحد المعياري بعناية
لا أجعل كل خدمة داخلية تعتمد مباشرةً على مخطط رسالة سوق بعينه، ولا أنشئ نموذجاً عاماً يمحو كل الفروق. أضع نموذج مجال واضحاً عند الحد الذي يملك المعنى التجاري، ثم محولات ذات إصدارات إلى ملفات الأسواق. تبقى الحقول التي يحتاجها المنتج والتحقيق والمحاسبة صريحة، وتظل الفروق الخاصة بالشبكة داخل طبقة تكامل يمكن تتبعها.
أوثق اتجاه كل تحويل وهل هو قابل للعكس. إذا لم يستطع النموذج الداخلي إعادة إنتاج قيمة أصلية، أحفظ الرسالة المتحققة أو مرجعها وفق سياسة الخصوصية والاحتفاظ. وعندما تتعدد الأسواق، لا أفترض أن عنصرين يحملان الاسم نفسه لهما قواعد الحضور والرموز والدلالة نفسها.
احفظ الامتدادات من دون التخلي عن الحوكمة
قد يسمح ملف سوق ببيانات تكميلية أو عناصر لا يفهمها الإصدار الحالي من المنتج. لا أسقطها بصمت ولا أسمح لها بتجاوز قواعد المجال. أحفظها في ظرف مسمى المصدر والإصدار، وأعرّف من يستطيع قراءتها، وأقيس الحقول غير المعروفة، ثم أقرر صراحةً هل تُرقّى إلى مفهوم مجال أم تبقى دليلاً خاماً.
هذا يوازن بين قابلية التقدم والتفسير. فالاحتفاظ بكل XML داخل عمود لا يصنع دعماً للمعيار، كما أن رفض أي إضافة يربط إطلاق المنتج بإصدار مركزي. المطلوب مسار محكوم يميز المعنى المعروف من الامتداد المحفوظ ويمنع كليهما من التحول إلى حقل نص حر مجهول السلطة.
عامل الربط ككود إنتاجي
وزّع الرسائل حسب الإصدار المعلن، ولا تخمّنه من الحقول. شغّل الإصدارين بالتوازي عند الترقية، واحفظ إصدار المربط مع العملية. اختبر بيانات التحويل المنظم، والأطراف الاختيارية، والرسوم، والإرجاع، والبيانات التكميلية، وقوائم الرموز الخارجية.
التحقق من مخطط XML يثبت البنية، لكنه لا يثبت توافق دليل السوق أو صحة رمز خارجي في تاريخ معين. أضف قواعد دلالية، وتعامل مع قوائم الرموز كبيانات مرجعية ذات مصدر وتاريخ تفعيل ورجوع.
راقب الحقول غير المربوطة، والاقتطاع، والرموز غير المعروفة، وفشل التحقق، وفروق المطابقة الناتجة عن فقد الدلالة. وفي الترقية، شغّل رسائل تاريخية عبر المربطين وصنّف الفروق قبل التفعيل.
قاعدتي التصميمية هي إظهار أربع طبقات: المفاهيم المالية، وتعريف الرسالة ودليل استخدامها، ومحول الصيغة، ونموذج المجال الداخلي. أختبر الربط وأحفظ الدليل، لأن سؤال «ما الحقيقة المالية؟» يبقى صالحاً بعد تغير XML.
ضوابط التشغيل والترقية
أتعامل مع فشل المخطط وفشل قواعد السوق وفشل الدلالة كفئات مختلفة. أسجل إصدار الرسالة ودليل الاستخدام والمحول وقائمة الرموز مع كل عملية، وأضع الرسائل غير القابلة للمعالجة في مسار استثناء لا يفقد الأصل. أراقب الاقتطاع والحقول غير المربوطة والرموز غير المعروفة والفروق بين الرسالة والقيد أو المطابقة.
عند الترقية أشغل الإصدارين بالتوازي على مجموعة رسائل تاريخية وحالات حدودية: أطراف اختيارية، وعناوين منظمة، ورسوم، وتحويلات متعددة، وإرجاع، وبيانات تكميلية. أصنف الفروق إلى متوقعة ومفقودة المعنى ومخالفة للملف. لا أبدل المسار الحي حتى يستطيع التشغيل تفسير كل فئة، ويملك خطة رجوع لا تغير معنى عمليات بدأت على الإصدار القديم.
معماريتي الدائمة ليست «XML في كل مكان» ولا «نموذج موحد لكل شيء». هي مفاهيم مالية مستقرة، وملفات استخدام ذات إصدارات، ومحولات مختبرة، ودليل أصلي يمكن الرجوع إليه. بهذه الحدود أستفيد من اللغة المشتركة للمعيار من دون نقل تعقيد كل شبكة إلى كل خدمة داخلية.
قبل ربط سوق جديد أبني مصفوفة تغطي القبول والتحقق والرفض والحالة والإرجاع والإلغاء والتحقيق والمطابقة، لا رسالة الإرسال وحدها. لكل حقل حاسم أحدد مصدره ووجهته وقاعدة غيابه واختباره وصاحبه. ثم أراجع عينات واقعية من الدليل الرسمي للملف، وأقارن الرسالة الخارجة بما دخل النظام وما رحله الدفتر.
أضع قوائم الرموز الخارجية تحت إدارة إصدار وتاريخ تفعيل، لأن رسالة صالحة بنيوياً قد تحمل قيمة لم تعد مقبولة في السوق. وأحفظ سبب الرفض كما وصل، بدلاً من اختزاله في PROCESSING_ERROR. عندما يظهر رمز أو عنصر غير معروف، أريد مساراً واضحاً للتحديث وإعادة المعالجة، لا إصلاحاً يدوياً داخل الإنتاج.
هذه الضوابط تجعل الترقية قراراً يمكن الرجوع عنه. أستطيع معرفة العمليات التي استخدمت كل إصدار، وإعادة تشغيل التحويل بلا إعادة إرسال الأثر، وشرح أي فرق في التحقيق أو المطابقة. هذا هو الدعم الحقيقي لـISO 20022 في رأيي: معنى محفوظ عبر دورة الحياة، لا ملف اجتاز مخطط XML مرة واحدة.
وأتفق مع أصحاب المجال على قاموس داخلي يربط الاسم بالتعريف الرسمي والاستخدام الفعلي في المنتج. لا أسمح لفريق أن يستخدم debtor بمعنى صاحب الحساب بينما يستخدمه آخر بمعنى منشئ الطلب. عند وجود فرق متعمد أسميه صراحةً في النموذج والمحول. هذا العمل يبدو أقل إثارة من توليد XML، لكنه يمنع النزاعات الدلالية التي تظهر لاحقاً في التحقيق والتقارير.
ما القرار الذي كنت ستتخذه؟
شارك سؤالاً أو تجربة أو رأياً مخالفاً. التعليقات متاحة للأعضاء المسجلين للحفاظ على نقاش مهني ومفيد.