إنشاء ملفات XML وفق goAML XSD v5: الدليل التقني الشامل

إذا سبق أن حاولت بناء تقرير goAML بصيغة XML من الصفر، فأنت تعلم أن العملية أعقد بكثير مما تبدو للوهلة الأولى. فالإصدار 5.0.2 من مخطط goAML الصادر عن مكتب الأمم المتحدة المعني بالمخدرات والجريمة (UNODC) يعرّف أكثر من 200 عنصر، يخضع كثير منها لقيود تعداد صارمة، وكلها مرتبة في تسلسل هرمي شديد التداخل، مع مجموعات مختلفة من العناصر الإلزامية بحسب ما إذا كنت تُنشئ تقرير المعاملات النقدية (CTR) أو تقرير المعاملات المشبوهة (STR). ثم تضيف وحدات المعلومات المالية (FIU) على المستوى الوطني متطلبات تحقق إضافية فوق المخطط الأساسي — وهذه المتطلبات تتغير.

وتُخفق معظم المحاولات الأولى لإنشاء XML لنظام goAML عند التقديم. فالتقرير يبدو صحيحًا في محرر النصوص، وملف XML سليم البنية (well-formed). لكن بوابة وحدة المعلومات المالية تُعيد خطأ تحقق في حقل يقع على عمق ثلاثة مستويات في التسلسل الهرمي للأطراف، وهو منسَّق تنسيقًا صحيحًا لكل البلدان الأخرى باستثناء هذا البلد. فيُجري المطور إصلاحًا، ويعيد الإنشاء، ويعيد التقديم، ليواجه خطأً مختلفًا. وقد تستغرق دورة التكرار هذه أيامًا.

هذا الدليل موجَّه إلى مديري تقنية المعلومات والمطورين والمعماريين التقنيين المسؤولين عن بناء قدرات إنشاء XML لنظام goAML أو تقييمها. ويتناول بنية المخطط، ومواضع الإخفاق الشائعة، والامتدادات الخاصة بكل بلد، وبنية مسار متين لإنشاء XML.

---

نظرة عامة على مخطط goAML XML v5.0.2

تاريخ مخطط goAML

خضع برنامج goAML الصادر عن UNODC لعدة مراجعات كبرى للمخطط منذ نشره الأول في منتصف العقد الذي بدأ عام 2000. وكان الإصدار 3 من المخطط هو السائد لدى الجهات السبّاقة إلى اعتماده، ولا يزال يُصادَف في عمليات النشر القديمة لدى وحدات المعلومات المالية. وأدخل الإصدار 4 تغييرات هيكلية مهمة على عناصر المعاملات والأطراف، فحسّن دعم هياكل الملكية المعقدة والمعاملات العابرة للحدود.

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

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

بنية المخطط: التقرير ← المعاملة ← الطرف ← الحساب ← وثيقة الهوية ← العنوان

يتبع التسلسل الهرمي لمستند goAML XML بنية منطقية تحاكي تقرير المعلومات الاستخبارية المالية في الواقع العملي:

التقرير (Report) هو العنصر الجذر. ويتضمن تعريف الجهة المُبلِّغة، والبيانات الوصفية للتقديم، وبيانات الشخص المُبلِّغ، وسجل معاملة واحدًا أو أكثر.

تقع عناصر المعاملة (Transaction) مباشرة تحت عنصر التقرير (Report). ولكل معاملة نوع ومبلغ وعملة وتاريخ ووصف. ويمكن أن يتضمن التقرير الواحد معاملات متعددة — وهذا شائع في تقارير CTR حين يُجري العميل عدة معاملات نقدية خلال فترة الإبلاغ.

وتصف عناصر الطرف (Party) الأفراد أو الكيانات القانونية المشاركة في المعاملة. وتُربط الأطراف بالمعاملات عبر العناصر from_person وto_person وfrom_entity وto_entity، ويتضمن كل منها سجل الطرف المتداخل. ويمكن الإشارة إلى الطرف الذي يظهر في معاملات متعددة بمعرّفه بدلًا من تكراره كاملًا في كل معاملة.

وتلتقط عناصر الحساب (Account) الحسابات المالية المعنية — أرقام الحسابات المصرفية، ورموز الأنواع، والمؤسسة المالية التي تحتفظ بالحساب. وتُربط الحسابات بجانب المعاملة الخاص بكل منها (from_account، to_account).

وتقع عناصر وثيقة الهوية (ID Document) داخل سجلات الأشخاص، وتلتقط الهوية الوطنية، وجواز السفر، ورخصة القيادة، وغيرها من وثائق التحقق من الهوية. والهوية الوطنية إلزامية للأشخاص الكينيين بموجب قواعد التحقق لدى FRC.

وتلتقط عناصر العنوان (Address) العناوين الفعلية أو البريدية للأشخاص والكيانات. وتختلف قواعد التحقق من العناوين من بلد إلى آخر — فبعض وحدات المعلومات المالية يشترط التفاصيل حتى مستوى الشارع، وبعضها الآخر يقبل ذكر البلد وحده للأطراف غير المقيمة.

الفروق بين مخططَي STR وCTR

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

تقارير CTR تشترط العنصر transaction_amount بدقة عشرية تامة، وCASH نوعًا للمعاملة، وتفاصيل الحساب كاملة على جانبي المعاملة. ويجب أن يتسق مبلغ حد الإبلاغ عن تقارير CTR ورمز العملة اتساقًا تامًا مع الحد المعلن في ملف تعريف البلد. ويجوز دمج عدة معاملات نقدية في فترة الإبلاغ نفسها في تقرير CTR واحد.

أما تقارير STR فتشترط ضبط العلامة is_suspicious على true، وعنصر reason غير فارغ يصف سبب الاشتباه في المعاملة، ونصًّا سرديًا ذا طول ومضمون معتبرين، ورمز مؤشر واحدًا على الأقل يشير إلى نمط معروف من أنماط غسل الأموال من قائمة المؤشرات لدى وحدة المعلومات المالية، وبيانات reporting_person. ويجوز أن تتضمن عناصر المعاملات في تقرير STR معاملات غير نقدية وأنماطًا مجزّأة تقل كل منها على حدة عن حدود الإبلاغ عن تقارير CTR.

تنزيل XSD الرسمي من UNODC

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

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

---

بنية مستند goAML XML

فيما يلي مثال مشروح لتقرير CTR سليم البنية وفق goAML v5.0.2، لجهة مُبلِّغة كينية خيالية. وجميع بيانات الجهات والأشخاص خيالية تمامًا.

<?xml version="1.0" encoding="UTF-8"?>
<Report xmlns="http://goaml.unodc.org/goaml/en">
  <!-- Reporting entity identification — must match FIU registration exactly -->
  <rentity_id>KE-FRC-12345</rentity_id>
  <rentity_branch>NAIROBI-HQ</rentity_branch>

  <!-- Submission metadata -->
  <submission_code>E</submission_code>          <!-- E = Electronic -->
  <report_code>CTR</report_code>                <!-- CTR or STR -->
  <entity_reference>CTR-2026-0001</entity_reference>  <!-- Internal reference -->
  <fiu_ref_number></fiu_ref_number>             <!-- Blank on first submission; FIU populates on acceptance -->
  <submission_date>2026-03-25</submission_date>  <!-- YYYY-MM-DD strictly required -->
  <currency_code_local>KES</currency_code_local> <!-- ISO 4217 currency code -->

  <!-- Reporting person — the compliance officer or designated MLRO -->
  <reporting_person>
    <gender>M</gender>               <!-- M or F — not Male/Female -->
    <title>Mr</title>
    <first_name>James</first_name>
    <last_name>Mwangi</last_name>
    <birthdate>1980-05-15</birthdate>  <!-- YYYY-MM-DD — not optional for Kenya FRC -->
    <id_number>12345678</id_number>    <!-- National ID of reporting person -->
    <!-- Address and phone elements follow here -->
  </reporting_person>

  <!-- One or more transaction elements -->
  <transaction>
    <transactionnumber>TXN-2026-00123</transactionnumber>
    <transaction_location>NAIROBI-CBD-BRANCH</transaction_location>
    <date_transaction>2026-03-24</date_transaction>  <!-- Date of transaction -->
    <teller>T001</teller>                             <!-- Teller/officer ID -->
    <currency_amount>
      <amount>1250000.00</amount>    <!-- Exactly 2 decimal places required -->
      <currency_code>KES</currency_code>
    </currency_amount>

    <!-- Transaction type — must be valid enumeration value from XSD -->
    <transaction_type>CASH_DEPOSIT</transaction_type>

    <!-- The depositing party (from side) -->
    <from_person>
      <gender>F</gender>
      <title>Ms</title>
      <first_name>Wanjiru</first_name>
      <last_name>Kamau</last_name>
      <birthdate>1985-11-20</birthdate>
      <id_number>87654321</id_number>
      <id_type>NATIONAL_ID</id_type>   <!-- Enumeration — must match XSD allowed values -->
      <address>
        <address_type>HOME</address_type>
        <city>Nairobi</city>
        <country>KE</country>  <!-- ISO 3166-1 alpha-2 -->
      </address>
    </from_person>

    <!-- The receiving account (to side) -->
    <to_account>
      <institution_name>First National Bank Kenya</institution_name>
      <institution_code>KE-FRC-12345</institution_code>
      <account>
        <account_number>1234567890</account_number>
        <account_name>Wanjiru Kamau</account_name>
        <account_type>SAVINGS</account_type>  <!-- Enumeration -->
        <currency_code>KES</currency_code>
        <opened>2022-06-15</opened>
      </account>
    </to_account>
  </transaction>

</Report>

يوضح هذا المثال عدة متطلبات تنسيق بالغة الأهمية نتناولها بالتفصيل في الأقسام التالية. والبنية صحيحة لتقرير CTR أساسي، لكن التقارير في بيئة الإنتاج تتطلب عناصر إضافية لأنماط المعاملات المعقدة، وتعدد الأطراف المعنية، والتقارير متعددة المعاملات.

---

العناصر الإلزامية والاختيارية حسب نوع التقرير

يلخّص الجدول التالي العناصر الرئيسية ومتطلباتها في نوعي التقارير CTR وSTR. وقد أُشير إلى الامتدادات الخاصة بوحدات المعلومات المالية دون حصرها — فارجع دائمًا إلى وثائق التحقق الحالية الخاصة بكل بلد.

---

التحديات الشائعة في إنشاء XML

مشكلات الترميز: UTF-8 دون BOM

تشتهر تطبيقات بوابة goAML بصرامتها الشديدة في ما يخص ترميز المحارف. فيجب أن يحدد إعلان XML ترميز UTF-8، ويجب حفظ الملف بترميز UTF-8 دون علامة ترتيب البايتات (BOM). وكثيرًا ما تكتب مكتبات XML المصممة أساسًا لبيئة Windows علامة BOM لترميز UTF-8 افتراضيًا، مما يدفع بوابة goAML إلى رفض التقديم بخطأ ترميز كثيرًا ما يُشخَّص خطأً على أنه خطأ في المخطط.

إذا كان ملف XML يُنشأ على نظام Windows باستخدام XmlWriter في ‎.NET، فتأكّد من إنشاء أداة الكتابة باستخدام new UTF8Encoding(false) — إذ تمنع المعلمة false صراحةً إخراج علامة BOM. وفي Python، استخدم encoding='utf-8' دون الصيغة utf-8-sig. وهذا من أكثر الإخفاقات الصامتة شيوعًا في التطبيقات الأولى لإنشاء XML.

صرامة صيغة التاريخ: YYYY-MM-DD دائمًا

يتطلب كل حقل تاريخ في مخطط goAML صيغة ISO 8601، أي YYYY-MM-DD. وكثيرًا ما تخزّن الأنظمة المصرفية الأساسية في شرق أفريقيا التواريخ وتصدّرها بصيغة DD/MM/YYYY، وهي الصيغة المقروءة السائدة في المنطقة. لذا يجب أن توحّد طبقةُ تحويل جميعَ بيانات التواريخ الواردة قبل دخولها مسار إنشاء XML.

أما التواريخ المخزنة في صورة أرقام تسلسلية في Excel (وهو أمر شائع في ملفات CSV المُصدَّرة من بعض الأنظمة المصرفية الأساسية) فتتطلب تحويلًا مختلفًا. فتاريخ 1 يناير 1900 هو الرقم التسلسلي 1 في نظام التواريخ في Excel؛ وتاريخ 25 مارس 2026 هو الرقم التسلسلي 46106. ويجب على أي نظام لإنشاء XML يستهلك بيانات معاملات مُصدَّرة من Excel أن يعالج هذا التحويل صراحةً.

الدقة العشرية: منزلتان عشريتان بالضبط

يجب تنسيق عناصر المبالغ بمنزلتين عشريتين بالضبط. فمبلغ 1,250,000 شلن كيني يجب أن يظهر بالصيغة 1250000.00، لا 1250000، ولا 1,250,000.00 (دون فاصل للآلاف)، ولا 1250000.0. ويعرّف XSD عناصر المبالغ بالنوع xs:decimal مع القيد fractionDigits بالقيمة 2. ويجب تقريب المبالغ الناتجة عن عمليات القسمة في الشيفرة وتنسيقها صراحةً قبل إدراجها في XML.

الحقول المنطقية: true/false بأحرف صغيرة

يستخدم العنصر is_suspicious وغيره من الحقول المنطقية في مخطط goAML النوع المنطقي (boolean) في XML Schema، الذي يقبل true وfalse (بأحرف صغيرة) أو 1 و0. وكثير من المطورين، ولا سيما من يعملون بلغات لا تميّز بين الأحرف الكبيرة والصغيرة في تمثيل القيم المنطقية، يُنشئون دون قصد True أو False أو TRUE أو FALSE — وكلها تُخفق في التحقق من المخطط. وتقبل بعض تطبيقات بوابة goAML القيمتين 1/0، لكن ذلك يتفاوت؛ لذا استخدم دائمًا true/false لتحقيق أقصى قدر من التوافق.

قيود التعداد: أنواع المعاملات وأنواع الهوية

يعرّف مخطط goAML مجموعات تعداد صارمة لعناصر منها transaction_type وid_type وaccount_type وgender وaddress_type وsubmission_code. ويجب أن تطابق كل قيمة تُدرج في هذه العناصر إحدى القيم المسموح بها المعرّفة في XSD مطابقةً تامة. وإذا كان نظامك المصرفي الأساسي يستخدم جداول رموز مختلفة — كأن يخزّن أنواع المعاملات في صورة رموز رقمية مثل 01 و02 و03 — فلا بد من طبقة لمطابقة الرموز تحوّلها إلى قيم التعداد في goAML قبل إنشاء XML.

وهذه المطابقة خاصة بكل بلد أيضًا. فالمخطط الموسَّع لدى FRC في كينيا يضيف قيمًا إضافية لنوع المعاملة خاصة بقنوات الأموال عبر الهاتف المحمول (MOBILE_WALLET_MPESA، MOBILE_WALLET_AIRTEL، MOBILE_WALLET_TKASH) غير موجودة في مخطط UNODC الأساسي. وإنشاء تقرير بنوع معاملة من المخطط الأساسي لمعاملة أموال عبر الهاتف المحمول مقدَّمة إلى FRC في كينيا سيجتاز التحقق وفق XSD الأساسي، لكنه سيُخفق في التحقق على المستوى الوطني.

المسافات البيضاء والعناصر الفارغة

لمخطط goAML قواعد محددة بشأن العناصر الفارغة مقارنةً بالعناصر المحذوفة. فبالنسبة إلى العناصر الاختيارية التي لا قيمة لها، يكون النهج الصحيح حذف العنصر كليًا من ملف XML المُنشأ — لا إدراج وسم فارغ. فالعنصر <fiu_ref_number></fiu_ref_number> سليم البنية من الناحية التقنية، لكن بعض تطبيقات بوابة goAML ترفضه بوصفه غير مطابق للمخطط حين يكون العنصر معرّفًا بقيد minLength قيمته 1. والسلوك الصحيح هو حذف fiu_ref_number كليًا حين لا توجد قيمة لتعبئته.

وفي المقابل، يجب ألا تتضمن العناصر الإلزامية ذات القيم مسافات بيضاء في بدايتها أو نهايتها. فالعنصر <institution_code> KE-FRC-12345 </institution_code> سيُخفق في التحقق لدى التطبيقات الصارمة. وينبغي تشذيب جميع القيم النصية قبل إدراجها.

---

امتدادات XML الخاصة بكل بلد

كيف يوسّع FRC في كينيا مخطط XSD الأساسي

ينشر Financial Reporting Centre في كينيا ملف تعريف للتحقق يوسّع مخطط UNODC XSD الأساسي بمتطلبات إلزامية إضافية. وأبرز الامتدادات الخاصة بكينيا ما يلي:

إلزامية الهوية الوطنية: لأي مواطن كيني يظهر بصفة from_person أو to_person في التقرير، يكون العنصران id_number وid_type إلزاميين — لا اختياريين كما هما في المخطط الأساسي. ويجب أن تكون قيمة id_type هي NATIONAL_ID للمواطنين الكينيين. ويجب على الرعايا الأجانب تقديم PASSPORT.

تصنيف قنوات الأموال عبر الهاتف المحمول: يجب أن تستخدم المعاملات التي تشمل M-PESA أو Airtel Money أو T-Kash قيم التعداد الموسَّعة لدى FRC للعنصر transaction_type (MOBILE_WALLET_MPESA، MOBILE_WALLET_AIRTEL، MOBILE_WALLET_TKASH)، ويجب أن تتضمن العنصر mobile_money_agent_code حين تُجرى المعاملة عبر وكيل.

اشتراط تاريخ ميلاد الشخص المُبلِّغ: مع أن مخطط UNODC الأساسي يعامل تاريخ الميلاد على أنه اختياري في العنصر reporting_person، فإن قواعد التحقق لدى FRC في كينيا تجعله إلزاميًا. وتُرفض التقارير التي تخلو من تاريخ ميلاد الشخص المُبلِّغ.

حد الإبلاغ عن تقارير CTR: يبلغ حد الإبلاغ عن تقارير CTR في كينيا 15,000 دولار أمريكي أو ما يعادلها بأي عملة أخرى، بموجب المادة 44(6) من POCAMLA والمادة 40(1) من POCAMLR 2023 (تعميم FRC رقم 4 لسنة 2023). ويجب الإبلاغ عن كل معاملة نقدية منفردة تبلغ الحد أو تتجاوزه، مع تسجيل المبلغ بالعملة الأصلية، وسعر الصرف المطبَّق، والمبلغ المعادل بالدولار الأمريكي في ملف XML لتقرير CTR. ولا يُجمَّع النشاط الذي يقل عن الحد في اليوم نفسه في تقرير CTR؛ وحيثما بدا أنه تجزئة، تقدّم المؤسسة تقرير STR.

امتدادات مركز FIC في زامبيا

يطبّق Financial Intelligence Centre (مركز المعلومات المالية) في زامبيا ملف تعريف للتحقق خاصًا به فوق مخطط UNODC الأساسي. ومن أبرز الفروق عن كينيا: رمز العملة (ZMW)، واختلاف حدود الإبلاغ عن تقارير CTR، وتعدادات لأنواع المعاملات خاصة بزامبيا. ويشترط مركز FIC أيضًا رقم تسجيل النشاط التجاري (Business Registration Number) للأطراف من الكيانات، وهو يُطابَق مع حقل مختلف عن الحقل الذي يفضّله FRC في كينيا.

ولا تستطيع المؤسسات التي تتوسع من كينيا إلى زامبيا إعادة استخدام محرك لإنشاء XML مهيّأ لكينيا دون تعديل إعدادات ملف تعريف التحقق.

لماذا لا ينجح قالب XML واحد في جميع البلدان

هذا هو السبب الجوهري لإخفاق أدوات إنشاء goAML XML الجاهزة المبنية لبلد واحد حين تُنشر في بيئات متعددة البلدان. فمخطط UNODC XSD الأساسي يوفر الإطار الهيكلي. ثم تطبّق وحدات المعلومات المالية الوطنية قواعد تحقق تغيّر العناصر الإلزامية، وتوسّع مجموعات التعداد، وتضيف عناصر خاصة بكل بلد بالكامل. والقالب المبرمج بشكل ثابت لـ FRC في كينيا سيُنشئ XML غير صالح لهيئة FIA في أوغندا، والعكس صحيح.

ويجب أن يعمل محرك إنشاء XML متعدد البلدان في بيئة الإنتاج وفق ملفات تعريف إعدادات خاصة بكل بلد، تحدد قواعد التحقق المنطبقة، والحقول الإلزامية، وامتدادات التعداد، وتفاصيل نقاط الاتصال (endpoints) لدى وحدة المعلومات المالية في كل بلد مستهدف.

---

التحقق وفق XSD في الشيفرة

التحقق من مخطط XML في ‎.NET باستخدام XmlSchemaSet

في ‎.NET، يجري التحقق وفق goAML XSD باستخدام الفئة System.Xml.Schema.XmlSchemaSet مع XmlReader مهيّأ بإعدادات التحقق. وتُحمِّل العملية ملف XSD (أو الملفات، إذا كان امتداد البلد ملف XSD منفصلًا يُضاف فوق الأساسي)، وتضيفه إلى مجموعة المخططات، ثم تتحقق من مستند XML المُنشأ وفقه قبل محاولة التقديم.

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

ويجب أن تجري خطوة التحقق بعد اكتمال إنشاء XML، ولكن قبل تسلسل المستند (serialisation) إلى حمولة التقديم. فمحاولة التحقق في منتصف الإنشاء (بينما لا يزال المستند قيد البناء) تُنتج أخطاء مضللة، لأن العناصر الإلزامية التي ستُضاف لاحقًا تُوسَم على أنها مفقودة.

التحقق في Python باستخدام lxml

يمكن لمطوري Python الذين يستخدمون مكتبة lxml الاستعانة بالفئة lxml.etree.XMLSchema للتحقق القائم على XSD. والنمط المتبع هو تحليل ملف XSD إلى كائن XMLSchema، ثم استدعاء .validate() على شجرة المستند المُنشأ. وتوفر الخاصية XMLSchema.error_log القائمة الكاملة لأخطاء التحقق مع معلومات المسار.

ومن دقائق lxml أن المكتبة صارمة في التعامل مع مساحات الأسماء (namespaces). فيجب أن يظهر إعلان xmlns الخاص بمخطط goAML على العنصر الجذر، وأن يطابق مساحة الاسم المعلنة في XSD مطابقةً تامة. ومن الأخطاء الشائعة إنشاء ملف XML بمعرّف URI لمساحة الاسم يختلف اختلافًا طفيفًا (كأن تُضاف شرطة مائلة في نهايته، أو يختلف en عن EN)، مما يؤدي إلى إخفاق التحقق من المخطط بالخطأ «no matching global element declaration» بدلًا من خطأ محدد على مستوى الحقل.

نهج الربط باستخدام JAXB في Java

يستخدم مطورو Java الذين يعملون مع goAML عادةً JAXB (Java Architecture for XML Binding) لإنشاء روابط فئات Java مباشرة من XSD. إذ يقرأ المترجم xjc ملف XSD ويُنتج فئات Java مشروحة (annotated) لكل نوع في المخطط، إلى جانب شيفرة التحويل إلى XML ومنه (marshalling وunmarshalling). ويصبح إنشاء التقرير عندئذٍ مسألة بناء شبكات من كائنات Java المترابطة (object graphs) وتحويلها إلى XML — إذ تطبّق أداة التحويل (marshaller) في JAXB قيود المخطط تلقائيًا أثناء التسلسل.

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

أدوات التحقق من XSD عبر الإنترنت للاختبار

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

---

بناء مسار متين لإنشاء XML

يتألف مسار إنشاء goAML XML الملائم لبيئة الإنتاج من خمس طبقات متمايزة، لكل منها مسؤولية محددة.

1. طبقة توحيد البيانات

تصل بيانات المعاملات الواردة من الأنظمة المصرفية الأساسية بصيغ لا يمكن استخدامها مباشرة في goAML XML. وتتولى طبقة التوحيد تحويل صيغة التاريخ (من DD/MM/YYYY إلى YYYY-MM-DD)، وتوحيد دقة المبالغ، وتوحيد ترميز المحارف، وحذف المحارف الخاصة غير المسموح بها في XML (البايتات الصفرية، وبعض محارف التحكم). كما تقتطع قيم الحقول حين تتجاوز البيانات الواردة الطول الأقصى المحدد في المخطط.

2. طبقة التحقق من قواعد العمل

قبل أن يبدأ إنشاء XML، تتحقق طبقة قواعد العمل من أن بيانات الحالة المجمَّعة تستوفي جميع المتطلبات الدلالية لنوع التقرير. ففي تقرير CTR: هل يبلغ مبلغ المعاملة الحد أو يتجاوزه؟ هل رقم الحساب موجود؟ هل نوع المعاملة من أنواع المعاملات النقدية؟ وفي تقرير STR: هل يوجد رمز مؤشر واحد على الأقل؟ هل السرد غير فارغ وبطول كافٍ؟ هل ضُبطت قيمة is_suspicious على نحو صحيح؟

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

3. طبقة إنشاء XML

تأخذ طبقة إنشاء XML البيانات الموحَّدة التي اجتازت التحقق من قواعد العمل، وتبني مستند goAML XML. والنمط المعماري الموصى به هو أدوات البناء المُدرِكة للمخطط (schema-aware builders) — أي فئات أو دوال تبني عناصر محددة من المخطط انطلاقًا من كائنات نموذج البيانات. وكل أداة بناء مسؤولة عن نوع واحد من العناصر (PersonBuilder، AccountBuilder، TransactionBuilder)، وتطبّق التنسيق المناسب، ومطابقة قيم التعداد، ومنطق تضمين العناصر أو استبعادها وفق ملف تعريف البلد المستهدف.

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

4. طبقة التحقق بعد الإنشاء

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

5. طبقة التقديم والتتبع

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

---

متى تستخدم محركًا جاهزًا لإنشاء XML

عبء الصيانة حين يحدّث UNODC مخطط XSD

أصدر UNODC عدة إصدارات من XSD لمخطط goAML، وسيستمر هذا النمط. وحين تنشر وحدة معلومات مالية وطنية إصدارًا جديدًا من XSD، تحتاج شيفرة إنشاء XML الداخلية إلى التحديث والاختبار والنشر — وغالبًا تحت ضغط الوقت، لأن وحدات المعلومات المالية تحدد مهلًا للانتقال. وإذا كان محرك إنشاء XML لديك يُصان داخليًا، فإن كل تحديث للمخطط يقع على عاتق فريق التطوير لديك، ويتنافس مع أولويات التطوير الأخرى.

تحديثات القواعد الخاصة بكل بلد

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

أما المنصة الجاهزة فتتضمن هذه التحديثات في نموذج ترخيصها — فتغييرات المخطط مشكلة المزوّد، لا مشكلتك.

إطار اتخاذ قرار البناء أو الشراء

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

---

اتخذ الخطوة التالية

تتضمن منصة Creodata لتقارير goAML في مجال مكافحة غسل الأموال محركًا لإنشاء XML جاهزًا لبيئة الإنتاج، تجري صيانته وفق goAML XSD v5.0.2 الحالي، مع ملفات تعريف للتحقق خاصة بكل بلد: FRC في كينيا، وهيئة FIA في أوغندا، ووحدة FIU في تنزانيا، ومركز FIC في زامبيا، ومركز FIC في رواندا. ويتولى المحرك الترميز، وتنسيق المنازل العشرية، وتوحيد التواريخ، ومطابقة قيم التعداد، والتحقق وفق XSD تلقائيًا — فتتعامل فرق الامتثال مع نماذج منظَّمة، لا مع XML.

شاهد محرك إنشاء XML وهو يعمل في عرض توضيحي مباشر: اطلب عرضًا توضيحيًا على creodata.com/demo

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

ما إصدار مخطط goAML الذي ينبغي أن أُنشئ XML وفقه؟

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

لماذا ترفض بوابة goAML ملفًا اجتاز التحقق محليًا؟

عادةً ما يكون السبب واحدًا من أربعة: علامة ترتيب بايتات (BOM) لترميز UTF-8 كتبتها مكتبة XML في Windows؛ أو امتداد خاص بالبلد لا يتضمنه ملف XSD المحلي لديك، مثل أنواع معاملات الأموال عبر الهاتف المحمول لدى FRC في كينيا؛ أو عنصر اختياري فارغ كان ينبغي حذفه؛ أو فحص لقواعد العمل يجري بعد التحقق من المخطط — كرقم للجهة المُبلِّغة لا يطابق سجل وحدة المعلومات المالية، أو مرجع تقرير مكرر.

ما صيغ التاريخ والمبلغ والقيم المنطقية التي يشترطها goAML XSD؟

التواريخ بصيغة ISO 8601، أي YYYY-MM-DD فقط. والمبالغ من النوع xs:decimal بمنزلتين عشريتين بالضبط ودون فواصل للآلاف (1250000.00). والقيم المنطقية true أو false بأحرف صغيرة. ويجب توحيد الملفات المُصدَّرة من الأنظمة المصرفية الأساسية بصيغة DD/MM/YYYY، والتواريخ التسلسلية في Excel، والقيم مثل True أو FALSE، قبل الإنشاء.

ما بنية تقرير goAML بصيغة XML؟

التقرير ← المعاملة ← الطرف ← الحساب ← وثيقة الهوية ← العنوان. ويتضمن التقرير معاملة واحدة أو أكثر؛ وتسمّي كل معاملة الأطراف على الجانبين (from_person أو from_entity، وto_person أو to_entity)، وحساباتهم، ووثائق هويتهم، وعناوينهم. ويحتاج تقرير CTR إلى أنواع معاملات نقدية وتفاصيل حساب كاملة؛ ويحتاج تقرير STR إلى ضبط is_suspicious على true، وسرد ذي مضمون حقيقي في reason، ورمز مؤشر واحد على الأقل.

من أين أنزّل ملف goAML XSD الرسمي؟

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