مخطط goAML XML v5.0.2: مرجع الحقول الإلزامية لتقارير CTR وSTR
مرجع شامل للحقول الإلزامية في goAML XSD v5.0.2 لتقارير CTR وSTR — أسماء الحقول، وأنواع البيانات، وقواعد التكييف المحلي في كينيا، ومتطلبات التحقق.
حين يقدّم مسؤول الامتثال تقرير المعاملات النقدية (CTR) أو تقرير المعاملات المشبوهة (STR) إلى Financial Reporting Centre (FRC) في كينيا، فإن بوابة goAML التابعة لـ FRC لا تتلقى نموذجًا أو جدول بيانات، بل تتلقى ملف XML يجب أن يتوافق بدقة مع مخطط goAML XSD v5.0.2 — وهو مواصفة قابلة للإنفاذ آليًا لكل عنصر ونوع بيانات وقيد طول وقاعدة هيكلية يجب أن يستوفيها التقرير الصالح.
وتعود معظم حالات رفض التقارير المقدَّمة إلى أحد سببين جذريين: إما أن فريق تقنية المعلومات في المؤسسة المُبلِّغة أنشأ ملف XML لا يتوافق مع المخطط، وإما أن فريق الامتثال أعدّ بيانات لا تستوفي متطلبات الحقول الإلزامية الخاصة بكينيا، التي تُضاف فوق المخطط الأساسي. ويمكن تفادي المشكلتين كلتيهما بالمواد المرجعية المناسبة.
وهذا المقال هو ذلك المرجع. فهو يقدّم تفصيلًا شاملًا، حقلًا بحقل، لعناصر XML الإلزامية في تقارير CTR وSTR المقدَّمة إلى FRC في كينيا، وأنواع البيانات وقيود الصيغة التي يفرضها كل حقل، وقواعد التكييف المحلي الخاصة بكينيا التي تنطبق إلى جانب XSD الأساسي. وسيجد مطورو تقنية المعلومات الذين يبنون مسارات إنشاء XML، ومسؤولو الامتثال الذين يراجعون جودة البيانات قبل التقديم، كل ما يحتاجون إليه هنا.
فهم مخطط goAML XSD v5.0.2
ما معنى التحقق وفق مخطط XSD ولماذا هو مهم
XSD (XML Schema Definition، أي تعريف مخطط XML) مواصفة رسمية مكتوبة بلغة XML، تحدد البنية المسموح بها، وأسماء العناصر، وأنواع البيانات، وقيود القيم، وعدد مرات الظهور (إلزامي أم اختياري، والحد الأدنى والأقصى لمرات الظهور) لكل عنصر في مستند XML المقابل.
حين تتلقى بوابة goAML التابعة لـ FRC ملف XML الذي قدّمته، فإنها تمرّره على أداة للتحقق وفق مخطط XSD قبل أن يراه أي محلل بشري. وتفحص الأداة كل عنصر في الملف وفق القواعد المحددة في مخطط goAML XSD v5.0.2. فإذا خالف أي عنصر أي قاعدة — حقل إلزامي مفقود، أو تاريخ بصيغة خاطئة، أو سلسلة نصية تتجاوز طولها الأقصى، أو قيمة تعداد غير مدرجة في القائمة المسموح بها — أعادت الأداة خطأً في التحقق من المخطط، ورُفض التقديم بأكمله.
والتحقق من المخطط ثنائي النتيجة: فإما أن يجتاز الملف التحقق بالكامل، وإما أن يُخفق. والملف الذي يضم 99 عنصرًا صحيحًا وتاريخًا واحدًا مشوّه الصيغة يُخفق إخفاقًا لا يقل حسمًا عن ملف فيه أخطاء هيكلية جوهرية. ولهذا فإن التحقق وفق XSD قبل التقديم ليس أمرًا اختياريًا — بل هو الحد الأدنى المطلوب في أي عملية لإنشاء تقارير CTR أو STR.
مستويات التداخل الستة في المخطط
ينظّم مخطط goAML XSD v5.0.2 بيانات التقرير في بنية هرمية من ستة مستويات. وفهم هذا التسلسل الهرمي ضروري للمطورين الذين يكتبون شيفرة إنشاء XML، ولفرق الامتثال التي تراجع مخرجات XML.
المستوى 1: التقرير (Report) — العنصر الجذر في مستند XML. ويتضمن حقول ترويسة التقرير التي تحدد نوع التقرير، والمؤسسة المُبلِّغة، وتاريخ التقديم، ومسؤول الامتثال المسؤول عنه. ويبدأ كل تقرير CTR وSTR بهذا العنصر.
المستوى 2: المعاملة (Transaction) — عنصر واحد أو أكثر من عناصر المعاملة، متداخلة داخل عنصر التقرير (Report). ويصف كل عنصر Transaction معاملة مالية واحدة، بما في ذلك تاريخها ومبلغها وعملتها ونوعها. ويُنشأ تقرير CTR لكل معاملة مؤهِّلة تبلغ قيمتها حدَّ الإبلاغ، أي ما يعادل 15,000 دولار أمريكي، أو تتجاوزه. ويتضمن تقرير STR عادةً عنصر Transaction واحدًا أو أكثر مرتبطًا بالنشاط المشبوه المُبلَّغ عنه.
المستوى 3: الطرف (Party) — تتضمن كل معاملة عناصر Party تحدد الأفراد أو الكيانات على كل جانب من جانبي المعاملة. وتُصنَّف الأطراف حسب دورها: from_person أو from_entity للجانب المدين، وto_person أو to_entity للجانب الدائن. ففي الإيداع النقدي، يكون العميل هو from_person والبنك هو to_entity.
المستوى 4: الحساب (Account) — تتداخل عناصر Account داخل عناصر Party. وتتضمن رقم الحساب، ورمز الفرع، ونوع الحساب، وعملة الحساب الذي جرت عبره المعاملة. ويُشترط وجود عنصر Account حيثما كان رقم الحساب معروفًا.
المستوى 5: الهوية (ID) — تتداخل عناصر وثائق الهوية داخل عناصر Party من نوع الشخص الطبيعي (Person). وتسجّل نوع وثيقة الهوية (بطاقة الهوية الوطنية، أو جواز السفر، أو بطاقة هوية الأجانب)، ورقم الوثيقة، وبلد الإصدار، وتاريخ الانتهاء حيثما ينطبق. وبالنسبة إلى المواطنين الكينيين، يكون عنصر الهوية الوطنية (National ID) إلزاميًا.
المستوى 6: العنوان (Address) — تتداخل عناصر Address داخل عناصر Party (الأشخاص والكيانات). وتسجّل البلد، والمقاطعة/الولاية، والمدينة/البلدة، وعنوان الشارع للطرف. وفي التقارير المقدَّمة إلى FRC في كينيا، يُشترط على الأقل ذكر البلد والبلدة.
الفروق بين بنيتَي مخطط STR وCTR
يستخدم تقريرا STR وCTR كلاهما مخطط goAML XSD v5.0.2 الأساسي نفسه. ويُميَّز بينهما بقيمة العنصر report_type (CTR أو STR)، وبالحقول الإلزامية المحددة التي تنطبق على كل نوع.
في تقارير CTR، ينصبّ التركيز الإلزامي على دقة بيانات المعاملة: المبالغ، والعملات، وأنواع المعاملات، وهوية العميل المُتحقَّق منها برقم الهوية الوطنية. ولا ينطبق حقل السرد.
أما في تقارير STR، فينتقل التركيز الإلزامي إلى مسوّغات الاشتباه: فحقل reason (السرد) إلزامي ويجب أن يكون ذا مضمون حقيقي؛ ويجب ضبط العلامة is_suspicious على القيمة TRUE؛ ويجب تعبئة رموز المؤشرات؛ ويجب أن يربط السرد المعاملات بنمط معترف به من أنماط غسل الأموال. وتظل بيانات المعاملة مطلوبة، لكن المحتوى التحليلي للتقرير يحظى بوزن أكبر في المخطط.
الامتدادات الخاصة بالبلد في إعدادات FRC في كينيا
يتضمن مخطط goAML XSD v5.0.2 الأساسي، كما يوزعه مكتب الأمم المتحدة المعني بالمخدرات والجريمة (UNODC) لاستخدام جميع وحدات المعلومات المالية المشاركة، مجموعة قياسية من العناصر المطبّقة عالميًا. وقد هيّأ FRC في كينيا البوابة لفرض حقول إلزامية وقواعد عمل إضافية خاصة بالبيئة الرقابية والمالية في كينيا. ومنها:
- إلزامية رقم الهوية الوطنية للمواطنين الكينيين (يعامل المخطط الأساسي الهوية على أنها موصى بها، لا مطلوبة)
- إلزامية تصنيف قناة الأموال عبر الهاتف المحمول لمعاملات M-PESA وAirtel Money وT-Kash
- وجوب أن يطابق رمز الفرع فرعًا مسجلًا لدى Central Bank of Kenya (البنك المركزي الكيني)
- وجوب وجود رقم تسجيل الجهة لدى FRC، ووجوب مطابقته لسجلات FRC مطابقةً تامة
- حد أدنى معزز لطول السرد في حالات مؤشرات تمويل الإرهاب (TF)، يبلغ عمليًا 500 كلمة فأكثر
وتُفرض هذه القواعد الخاصة بكينيا في طبقة التحقق من قواعد العمل بعد التحقق من المخطط. فقد يجتاز الملف التحقق وفق XSD ومع ذلك يُخفق في فحوص قواعد العمل لدى FRC.
الحقول الإلزامية في تقارير CTR — مرجع شامل
الجدول 1: حقول ترويسة التقرير
| اسم عنصر XML | نوع البيانات | الحد الأقصى للطول | الإلزامية | ملاحظات خاصة بكينيا |
|---|---|---|---|---|
report_type | نص (تعداد) | 10 | إلزامي | يجب أن تكون القيمة CTR تحديدًا |
report_date | تاريخ | — | إلزامي | الصيغة: YYYY-MM-DD؛ ويجب أن يكون التاريخ الحالي أو تاريخًا قريبًا |
reporting_entity_id | نص | 50 | إلزامي | رقم تسجيل الجهة الصادر عن FRC؛ ويجب أن يطابق سجلات FRC مطابقةً تامة |
reporting_entity_name | نص | 200 | إلزامي | الاسم القانوني الكامل للمؤسسة كما هو مسجل لدى FRC |
reporting_person_name | نص | 100 | إلزامي | الاسم الكامل لمسؤول الامتثال المسؤول عن التقرير |
reporting_person_id | نص | 50 | إلزامي | الرقم الوظيفي لمسؤول الامتثال أو رقم هويته الوطنية |
reporting_person_title | نص | 50 | موصى به | المسمى الوظيفي (مثل: رئيس إدارة الامتثال، MLRO) |
report_reference | نص | 50 | إلزامي | مرجع فريد للتقرير تُنشئه المؤسسة المُبلِّغة؛ ويجب أن يكون فريدًا لكل تقديم |
ملاحظة خاصة بكينيا بشأن reporting_entity_id: صيغة رقم تسجيل الجهة لدى FRC هي FRC/INST/YYYY/NNNN. وحتى الاختلافات الطفيفة — كالمسافات الزائدة في النهاية، أو الأحرف الصغيرة، أو حذف الشرطات المائلة — تؤدي إلى الرفض بالخطأ ERR_045 لمخالفة قاعدة عمل. انسخ الرقم مباشرة من شهادة تسجيلك لدى FRC، وتحقّق منه حرفًا حرفًا.
ملاحظة خاصة بكينيا بشأن report_reference: لا يجوز إعادة استخدام المرجع الفريد للتقرير في تقديمات مختلفة. وتستخدم معظم المؤسسات صيغة تجمع بين رمز المؤسسة، ونوع التقرير، والتاريخ، والرقم التسلسلي (مثل NSBK-CTR-20260325-001). وتؤدي المراجع المكررة إلى الرفض بالخطأ ERR_008.
الجدول 2: حقول المعاملة
| اسم عنصر XML | نوع البيانات | الحد الأقصى للطول | الإلزامية | ملاحظات خاصة بكينيا |
|---|---|---|---|---|
transaction_date | تاريخ | — | إلزامي | الصيغة: YYYY-MM-DD؛ ويجب أن يقع ضمن فترة الإبلاغ |
transaction_amount | عشري | — | إلزامي | يُشترط وجود منزلتين عشريتين (مثل 1250000.00)؛ دون رمز العملة |
transaction_currency | نص (ISO 4217) | 3 | إلزامي | رمز ISO 4217 من ثلاثة أحرف؛ استخدم KES لا Ksh أو KSH |
transaction_type | نص (تعداد) | 30 | إلزامي | يجب أن يكون إحدى القيم: CASH_DEPOSIT، CASH_WITHDRAWAL، CURRENCY_EXCHANGE |
transaction_reference | نص | 100 | إلزامي | الرقم المرجعي للمعاملة في النظام المصرفي الأساسي |
account_number | نص | 50 | إلزامي | رقم الحساب الكامل كما هو في النظام المصرفي الأساسي |
branch_code | نص | 20 | إلزامي | رمز الفرع المسجل لدى CBK |
branch_name | نص | 100 | موصى به | اسم الفرع بصيغة مقروءة |
channel | نص (تعداد) | 30 | مشروط | مطلوب لمعاملات الأموال عبر الهاتف المحمول؛ انظر رموز القنوات في كينيا أدناه |
kes_equivalent_amount | عشري | — | مشروط | مطلوب عندما لا تكون قيمة transaction_currency هي KES؛ المبلغ المعادل المحوَّل وفق سعر CBK |
cbk_rate_date | تاريخ | — | مشروط | مطلوب عند تعبئة kes_equivalent_amount |
transaction_description | نص | 500 | موصى به | وصف موجز لغرض المعاملة إن كان معروفًا |
رموز القنوات في كينيا لمعاملات الأموال عبر الهاتف المحمول:
| القناة | قيمة التعداد في XML |
|---|---|
| M-PESA (Safaricom) | MOBILE_WALLET_MPESA |
| Airtel Money | MOBILE_WALLET_AIRTEL |
| T-Kash (Telkom Kenya) | MOBILE_WALLET_TKASH |
| أمين الصندوق في الفرع (نقدًا) | BRANCH_CASH |
| السحب النقدي من أجهزة الصراف الآلي (ATM) | ATM_CASH |
| الخدمات المصرفية عبر الوكلاء (نقدًا) | AGENT_CASH |
ملاحظة بشأن transaction_type في معاملات الأموال عبر الهاتف المحمول: إذا أودع عميل نقدًا لدى وكيل M-PESA وقُيّد المبلغ في حساب مصرفي، فإن قيمة transaction_type هي CASH_DEPOSIT، وقيمة channel هي MOBILE_WALLET_MPESA. فنوع المعاملة يصف طبيعة الحركة النقدية؛ والقناة تصف الآلية.
الجدول 3: حقول هوية العميل (خاصة بكينيا)
| اسم عنصر XML | نوع البيانات | الحد الأقصى للطول | الإلزامية | ملاحظات خاصة بكينيا |
|---|---|---|---|---|
person_first_name | نص | 100 | إلزامي | كما يرد في وثيقة الهوية؛ دون أحرف أولى مختصرة |
person_last_name | نص | 100 | إلزامي | اسم العائلة كما يرد في وثيقة الهوية |
person_middle_name | نص | 100 | اختياري | يُدرج إن كان واردًا في وثيقة الهوية |
date_of_birth | تاريخ | — | إلزامي | الصيغة: YYYY-MM-DD؛ ويجب أن يدل على عمر بالغ معقول |
gender | نص (تعداد) | 1 | موصى به | M أو F |
id_type | نص (تعداد) | 30 | إلزامي | NATIONAL_ID أو PASSPORT أو ALIEN_ID |
id_number | نص | 50 | إلزامي لمواطني كينيا | 8 أرقام للهوية الوطنية الكينية؛ وأحرف وأرقام لجواز السفر |
id_issuing_country | نص (ISO 3166-1 alpha-3) | 3 | إلزامي | KEN لكينيا؛ وبلد الإصدار لجوازات السفر |
id_expiry_date | تاريخ | — | مشروط | مطلوب لجواز السفر وبطاقة هوية الأجانب؛ الصيغة YYYY-MM-DD |
nationality | نص (ISO 3166-1 alpha-3) | 3 | إلزامي | KEN للمواطنين الكينيين |
occupation | نص | 100 | موصى به | كما هو مصرّح به في سجلات اعرف عميلك (KYC) |
address_country | نص (ISO 3166-1 alpha-3) | 3 | إلزامي | KEN للعملاء المقيمين في كينيا |
address_county | نص | 100 | إلزامي | المقاطعة الكينية (مثل Nairobi، Mombasa، Kiambu) |
address_town | نص | 100 | إلزامي | البلدة أو الضاحية |
address_street | نص | 200 | موصى به | اسم الشارع أو المجمّع السكني |
phone_number | نص | 20 | موصى به | يُدرج رمز البلد (+254 لكينيا) |
email_address | نص | 100 | اختياري | حيثما كان متاحًا في سجلات اعرف عميلك (KYC) |
قاعدة كينية بالغة الأهمية — صيغة رقم الهوية الوطنية: تتكون أرقام بطاقات الهوية الوطنية الكينية من 8 أرقام بالضبط. لا أحرف، ولا شرطات، ولا مسافات. والصيغة هي NNNNNNNN. ومن الأخطاء الشائعة:
- تقديم رقم من 7 أرقام (البطاقات الأقدم الصادرة قبل عام 1990 — وهي لا تزال هويات صالحة من 7 أرقام، ويجب تقديمها بـ 7 أرقام دون إكمالها بالأصفار)
- إدراج الرقم التسلسلي لحامل البطاقة بدلًا من رقم الهوية
- تقديم رقم التعريف الضريبي KRA PIN (الذي يبدأ بحرف) على أنه رقم هوية وطنية
- تقديم رقم جواز السفر لمواطن كيني لديه بطاقة هوية وطنية
أما بالنسبة إلى الرعايا الأجانب، فيجب أن تكون قيمة id_type هي PASSPORT، ويجب تقديم رقم جواز السفر. ولا يقبل FRC أنواع هويات أجنبية أخرى بديلًا عن جواز السفر عند الإبلاغ عن أطراف غير كينيين.
الحقول الإلزامية في تقارير STR — مرجع شامل
يستخدم تقرير STR بنية المخطط نفسها التي يستخدمها تقرير CTR لحقول المعاملة والهوية. وتتركز الحقول الإلزامية الإضافية الخاصة بتقرير STR في ترويسة التقرير (قسم مسوّغات الاشتباه) وفي عناصر تحليل الحالة.
| اسم عنصر XML | نوع البيانات | الحد الأقصى للطول | الإلزامية | ملاحظات خاصة بكينيا |
|---|---|---|---|---|
report_type | نص (تعداد) | 10 | إلزامي | يجب أن تكون القيمة STR تحديدًا |
reason | نص | 4000 | إلزامي | السرد الكامل لتقرير STR — أسباب الاشتباه. ويجب أن يكون ذا مضمون حقيقي. وتؤدي القيم الفارغة أو الشكلية إلى الرفض. |
is_suspicious | منطقي (Boolean) | — | إلزامي | يجب أن تكون القيمة TRUE في جميع تقارير STR |
subject_type | نص (تعداد) | 10 | إلزامي | PERSON أو ENTITY |
indicator_codes | نص | 500 | إلزامي | قائمة مفصولة بفواصل برموز المؤشرات المعتمدة من FRC والمنطبقة على الحالة |
transaction_description | نص | 1000 | إلزامي لتقارير STR | وصف واقعي موجز للمعاملة المشبوهة (أو المعاملات المشبوهة) |
reporting_person_name | نص | 100 | إلزامي | مسؤول الامتثال المسؤول عن التقرير |
reporting_person_id | نص | 50 | إلزامي | الرقم الوظيفي أو رقم الهوية الوطنية لمسؤول الامتثال مُقدِّم التقرير |
date_of_suspicion | تاريخ | — | إلزامي | تاريخ نشوء الاشتباه لأول مرة؛ الصيغة YYYY-MM-DD |
action_taken | نص | 500 | إلزامي في كينيا | يصف استجابة المؤسسة (المراقبة، أو تجميد الحساب، أو مراجعة بيانات اعرف عميلك (KYC)، وغير ذلك) |
tipping_off_acknowledged | منطقي (Boolean) | — | إلزامي | يجب أن تكون القيمة TRUE — تؤكد إقرار مسؤول الإبلاغ بحظر الإفصاح للعميل (tipping-off) بموجب POCAMLA |
ملاحظة بشأن طول حقل reason: مع أن الحد الأقصى الذي يسمح به المخطط لحقل reason هو 4,000 حرف، فإن التحقق من قواعد العمل لدى FRC يفرض حدودًا دنيا عملية بحسب نوع المؤشر. في حالات غسل الأموال (ML) المعتادة: حد أدنى يقارب 200 حرف (نحو 30–40 كلمة). وفي حالات مؤشرات تمويل الإرهاب (TF): حد أدنى يقارب 3,000 حرف (نحو 500 كلمة). والسرد الذي يستوفي الحد الأدنى التقني لكنه قاصر في مضمونه سيجتاز التحقق من المخطط، لكنه سيستدعي طلبات متابعة من FRC.
ملاحظة بشأن indicator_codes: يجب أن تكون رموز المؤشرات مأخوذة من قائمة رموز المؤشرات التي ينشرها FRC في كينيا. ويؤدي تقديم رموز مخصصة، أو رموز من تطبيق وحدة معلومات مالية في بلد آخر، إلى الرفض بالخطأ ERR_045 لمخالفة قاعدة عمل. وراجع المقال ذا الصلة مكتبة مؤشرات تقارير STR: أنماط غسل الأموال للبنوك الكينية (2026)EN للاطلاع على المرجع الحالي لرموز المؤشرات لدى FRC في كينيا.
حقول المعاملة في تقارير STR: تنطبق على تقارير STR جميع حقول المعاملة نفسها الواردة في جدول تقارير CTR أعلاه. والفرق الرئيسي أن تقرير STR قد يرتبط بمعاملات تقل كل منها على حدة عن حد الإبلاغ عن تقارير CTR البالغ ما يعادل 15,000 دولار أمريكي — فمعيار تقديم تقرير STR هو الاشتباه، لا المبلغ.
قواعد التحقق الخاصة بكينيا
التحقق من صيغة رقم الهوية الوطنية
كما سبق بيانه، يفرض FRC في كينيا تحققًا صارمًا من صيغة أرقام الهوية الوطنية. وتفحص قاعدة التحقق ما يلي:
- أن نوع الهوية هو
NATIONAL_ID— ويجب أن يحتوي الحقل على 7 أو 8 أرقام بالضبط (7 للهويات الأقدم، و8 للهويات الصادرة اعتبارًا من عام 1991 تقريبًا) - عدم وجود أحرف أبجدية أو مسافات أو شرطات أو فواصل أخرى
- ألا يتكون رقم الهوية من أصفار فقط أو من رقم واحد مكرر (فمثلًا يُخفق
00000000و11111111في فحوص المعقولية)
وأضمن طريقة لاجتياز هذا التحقق هي سحب رقم الهوية مباشرة من مصدر موثَّق لبيانات اعرف عميلك (KYC)، وإجراء فحص للصيغة قبل التقديم. فكثير من البنوك تحتفظ بأرقام الهوية في أنظمة اعرف عميلك لديها مسبوقةً بمسافات أو ملحقةً بأرقام تسلسلية — لذا احذف جميع المحارف غير الرقمية قبل إدراج الرقم في ملف XML.
قواعد تصنيف قنوات الأموال عبر الهاتف المحمول
يشترط FRC في كينيا تصنيف معاملات الأموال عبر الهاتف المحمول باستخدام رموز القنوات المحددة في الجدول 2 أعلاه. وقواعد التصنيف هي:
- يجب أن تستخدم أي معاملة تبدأ عبر M-PESA القيمة
MOBILE_WALLET_MPESA، بصرف النظر عمّا إذا كان المصدر أو الوجهة النهائية حسابًا مصرفيًا - يُصنَّف التحويل من البنك إلى M-PESA، من الحساب المصرفي للعميل إلى رقم M-PESA المرتبط به، بالقيمة
MOBILE_WALLET_MPESA - الإيداع النقدي لدى وكيل M-PESA الذي يُقيَّد في حساب مصرفي يُصنَّف
CASH_DEPOSITمع القناةMOBILE_WALLET_MPESA - يجب أن تستخدم عمليات السحب النقدي من أجهزة الصراف الآلي القيمة
ATM_CASH، لاBRANCH_CASH - يجب أن تستخدم الإيداعات النقدية عبر الخدمات المصرفية بالوكالة (مثل Equity Agents وCo-op Kwa Jirani) القيمة
AGENT_CASH
ويؤدي استخدام رمز قناة خاطئ — أو إغفال حقل القناة في معاملات الأموال عبر الهاتف المحمول — إلى الرفض بالخطأ ERR_045 لمخالفة قاعدة عمل.
اشتراط الطول المعزز للسرد في حالات مؤشرات تمويل الإرهاب
في تقارير STR التي تتضمن أي رمز من رموز مؤشرات تمويل الإرهاب (TF)، تقتضي الممارسة لدى FRC في كينيا أن يستوفي السرد في حقل reason معايير معززة من حيث الطول والتفصيل. ومع أن مخطط XSD لا يفرض عددًا معينًا من الكلمات، فإن التحقق من قواعد العمل لدى FRC يُحيل تقارير STR المتضمنة مؤشرات تمويل الإرهاب، التي يقل سردها عن نحو 3,000 حرف (قرابة 500 كلمة)، إلى المراجعة اليدوية، ومن المرجح أن يعقب ذلك طلب معلومات إضافية.
ويجب أن يتضمن السرد في حالات تمويل الإرهاب، إضافةً إلى العناصر الخمسة المعتادة: الولاية القضائية (أو الولايات القضائية) المرتفعة المخاطر المعنية تحديدًا، وأسماء أي كيانات أو أشخاص خاضعين للعقوبات وردت في تنبيهات الفحص، وقناة تحويل الأموال وآليته، واستجابة المؤسسة بما في ذلك أي تجميد للحساب أو إخطار للجهة الرقابية.
الحقول الإلزامية التي يفرضها FRC في كينيا إضافةً إلى XSD الأساسي
الحقول التالية اختيارية في مخطط goAML XSD v5.0.2 الأساسي، لكن طبقة قواعد العمل لدى FRC في كينيا تعاملها على أنها إلزامية:
| الحقل | وضعه في XSD الأساسي | وضعه لدى FRC في كينيا | سبب اشتراطه |
|---|---|---|---|
id_number للمواطنين الكينيين | موصى به | إلزامي | متطلبات العناية الواجبة تجاه العملاء (CDD) بموجب POCAMLA |
branch_code | موصى به | إلزامي | المطابقة مع سجل فروع CBK |
action_taken (STR) | اختياري | إلزامي | إرشادات FRC بشأن توثيق استجابة المؤسسة |
date_of_suspicion (STR) | اختياري | إلزامي | احتساب الامتثال لمهلة التقديم |
tipping_off_acknowledged (STR) | اختياري | إلزامي | تأكيد حظر الإفصاح للعميل (tipping-off) بموجب POCAMLA |
channel للأموال عبر الهاتف المحمول | اختياري | إلزامي | تصنيف أنماط الأموال عبر الهاتف المحمول |
أخطاء التحقق الشائعة في XML وكيفية إصلاحها
| رمز الخطأ | رسالة الخطأ | السبب الجذري | الإصلاح |
|---|---|---|---|
| ERR_001 | Schema validation failed: element <transaction_date> has invalid value | التاريخ ليس بصيغة YYYY-MM-DD (مثل 25/03/2026 أو 2026-3-25) | أعد تنسيق جميع حقول التاريخ بصيغة YYYY-MM-DD الصارمة؛ وأضف صفرًا قبل الأشهر والأيام المكونة من رقم واحد |
| ERR_002 | Schema validation failed: <transaction_amount> is not a valid decimal | يتضمن المبلغ رمز عملة (USD 15,000) أو فاصلًا للآلاف | احذف جميع المحارف غير الرقمية باستثناء النقطة العشرية؛ واستخدم الصيغة 15000.00 |
| ERR_003 | Schema validation failed: <transaction_type> value CASH is not in permitted enumeration | استخدام قيم مختصرة غير موجودة في تعداد المخطط | استخدم قيم التعداد بدقة: CASH_DEPOSIT، CASH_WITHDRAWAL، CURRENCY_EXCHANGE |
| ERR_004 | Schema validation failed: mandatory element <id_number> is missing | حقل رقم الهوية الوطنية فارغ أو غير موجود في XML | تأكّد من تعبئة id_number لجميع الأطراف التي تكون فيها قيمة id_type هي NATIONAL_ID |
| ERR_005 | Schema validation failed: <transaction_currency> value Ksh is not valid ISO 4217 | استخدام اختصارات غير قياسية للعملات | استخدم رموز ISO 4217 المكونة من ثلاثة أحرف: KES، USD، EUR، GBP |
| ERR_006 | Schema validation failed: element <reason> is empty | حقل reason (السرد) في تقرير STR فارغ أو لا يحتوي إلا على مسافات | اكتب سردًا ذا مضمون حقيقي؛ راجع كيفية كتابة سرد تقرير STR في goAML |
| ERR_007 | Schema validation failed: malformed XML — unexpected end element | وسم XML غير مغلق في الملف المُنشأ | تحقّق من بنية XML باستخدام محلل (parser) قبل التقديم؛ وابحث عن الوسوم غير المغلقة |
| ERR_008 | Business rule violation: duplicate report_reference value | استُخدم رقم مرجع التقرير نفسه في تقديم سابق | أنشئ رقمًا مرجعيًا فريدًا جديدًا وفق نظام الترقيم المرجعي في مؤسستك |
| ERR_012 | Business rule violation: reporting_entity_id does not match FRC registry | رقم تسجيل الجهة في XML لا يطابق سجلات FRC مطابقةً تامة | انسخ رقم التسجيل لدى FRC حرفًا حرفًا من شهادة التسجيل الرسمية الصادرة عن FRC |
| ERR_045 | Business rule violation: id_number format invalid for id_type NATIONAL_ID | يحتوي رقم الهوية الوطنية على محارف غير رقمية، أو طوله خاطئ، أو يتضمن محارف تنسيق | اختصره إلى 7–8 أرقام خالصة؛ وتحقّق منه مقابل النسخة الممسوحة ضوئيًا من وثيقة اعرف عميلك (KYC) الأصلية |
أتمتة إنشاء XML لتفادي أخطاء المخطط
لماذا يؤدي إنشاء XML يدويًا إلى حالات الرفض
كل ملف XML يُجمَّع يدويًا هو منتج حِرفي — والمنتجات الحِرفية تحمل معها الخطأ البشري. وأنواع الأخطاء التي تؤدي إلى الرفض هي تحديدًا الأخطاء التي يقع فيها البشر: تاريخ بصيغة DD/MM/YYYY بدلًا من YYYY-MM-DD، ومبلغ يتضمن فاصلة بوصفها فاصلًا للآلاف، وقيمة لنوع المعاملة تكاد تكون صحيحة لكنها تنحرف قليلًا، ورقم هوية وطنية تسبقه مسافة جاءت من ملف بيانات اعرف عميلك (KYC) المُصدَّر.
وحيثما يجري إنشاء XML يدويًا — سواء في محرر نصوص، أو ماكرو في Excel، أو نص برمجي مُعدّ خصيصًا — يصبح الرفض عند التقديم الأول أمرًا روتينيًا، وتضيف كل حالة رفض دورةً من إعادة العمل إلى الجدول الزمني للتقديم: العثور على الخطأ، وتصحيح البيانات، وإعادة إنشاء الملف، ثم إعادة التقديم.
ما الذي يفعله محرك XML المؤتمت على نحو مختلف
يقضي محرك إنشاء XML المؤتمت، المصمَّم خصيصًا للامتثال لمخطط goAML، على أنماط الإخفاق هذه على نحو منهجي:
- مطابقة الحقول مع مراعاة المخطط: يُطابَق كل حقل إدخال مع اسم عنصر goAML XSD المقابل له بدقة. فلا نسخ يدوي لأسماء العناصر.
- فرض أنواع البيانات عند الإدخال: لا تقبل حقول التاريخ إلا تواريخ صالحة، وتُخرجها بصيغة YYYY-MM-DD. وتحذف الحقول العشرية محارف التنسيق وتفرض منزلتين عشريتين.
- التحقق من قيم التعداد: تُختار قيم حقول نوع المعاملة والقناة ونوع الهوية من قيم التعداد المسموح بها بدقة — دون أي إدخال بنص حر.
- فرض قواعد العمل الكينية: يُتحقَّق من صيغة رقم الهوية الوطنية، وتسجيل رمز الفرع، وتصنيف قناة الأموال عبر الهاتف المحمول، ومطابقة رقم تسجيل الجهة لدى FRC، وذلك كله قبل إنشاء ملف XML.
- التحقق وفق XSD عند الإخراج: يُتحقَّق من ملف XML المُنشأ وفق goAML XSD v5.0.2 قبل إتاحته للتقديم. ولا تُعرض الملفات التي تُخفق في التحقق على مسؤول الامتثال حتى تُحلّ مشكلة البيانات الأساسية.
- رصد حد الإبلاغ لكل معاملة مع تحويل العملات: تُقيَّم كل معاملة نقدية فورًا مقابل حد الإبلاغ البالغ ما يعادل 15,000 دولار أمريكي، مع تسجيل سعر الصرف المطبَّق في تقرير CTR.
والنتيجة مسار تقديم يُنتج في كل مرة ملفات XML مطابقة للمخطط ومتوافقة مع متطلبات FRC في كينيا — بمعدل رفض يقترب من الصفر.
الأسئلة الشائعة
ما المستويات الستة لمخطط goAML XSD v5.0.2؟
التقرير (Report)، وهو الجذر، ويتضمن الترويسة التي تحدد نوع التقرير والمؤسسة وتاريخ التقديم ومسؤول الامتثال؛ والمعاملة (Transaction): التاريخ والمبلغ والعملة والنوع؛ والطرف (Party): from_person أو from_entity في الجانب المدين، وto_person أو to_entity في الجانب الدائن؛ والحساب (Account): الرقم ورمز الفرع والنوع والعملة؛ والهوية (ID): نوع وثيقة الهوية ورقمها وبلد إصدارها وتاريخ انتهائها؛ والعنوان (Address): البلد والمقاطعة والبلدة والشارع. ويُخفق الملف في التحقق إذا خالف أي مستوى قاعدةً ما، مهما صغرت.
ما الحقول التي يشترطها FRC في كينيا إضافةً إلى مخطط goAML الأساسي؟
رقم الهوية الوطنية للمواطنين الكينيين، ورمز الفرع (الذي يُطابَق مع سجل فروع CBK)، وقناة الأموال عبر الهاتف المحمول لمعاملات M-PESA وAirtel Money وT-Kash، وفي تقارير STR الحقول action_taken وdate_of_suspicion وtipping_off_acknowledged. وتفرض طبقة قواعد العمل لدى FRC هذه الحقول بعد التحقق وفق XSD، لذا قد يجتاز الملف المخطط ومع ذلك يُرفض.
ما الصيغة التي يجب أن يتخذها رقم الهوية الوطنية الكيني في ملف goAML؟
سبعة أو ثمانية أرقام، دون مسافات أو شرطات أو أحرف، ودون قيمة غير معقولة مثل رقم مكوّن من أصفار فقط. احذف كل محرف غير رقمي من سجل اعرف عميلك (KYC) قبل الإنشاء؛ فالصيغة الخاطئة تستدعي خطأ قواعد العمل ERR_045.
كيف تختلف ملفات CTR عن ملفات STR في المخطط؟
يشترك النوعان في مخطط XSD نفسه، ويُميَّز بينهما بالعنصر report_type. ويركّز تقرير CTR على دقة بيانات المعاملة وعلى الهوية المُتحقَّق منها، دون سرد. أما تقرير STR فيجب أن يتضمن سردًا ذا مضمون حقيقي في حقل reason، وأن تُضبط قيمة is_suspicious على true، وأن يحمل رموز المؤشرات وربطًا بنمط معترف به — ويجب أن يكون السرد أطول وأكثر تفصيلًا حين يوجد مؤشر على تمويل الإرهاب.
ما أخطاء التحقق الأكثر شيوعًا في goAML؟
التواريخ التي ليست بصيغة YYYY-MM-DD (ERR_001)، والمبالغ التي تتضمن رموزًا أو فواصل للآلاف (ERR_002)، وأنواع المعاملات غير الموجودة في التعداد (ERR_003)، وغياب id_number (ERR_004)، ورموز العملات غير المطابقة لمعيار ISO مثل Ksh (ERR_005)، وحقل reason فارغ في تقرير STR (ERR_006)، وتكرار report_reference (ERR_008)، وقيمة reporting_entity_id لا تطابق سجل FRC (ERR_012). ويبيّن الجدول أعلاه طريقة إصلاح كل خطأ.
ابنِ مسار التقديم لديك على أساس متين من فهم المخطط
فهم مخطط goAML XML هو الأساس لعملية موثوقة لتقديم تقارير CTR وSTR. وسواء أكانت مؤسستك تبني مسارها الخاص لإنشاء XML أم تُقيّم منصة مصممة لهذا الغرض، فإن مرجع الحقول وقواعد التحقق في هذا المقال يمنحانك ما تحتاج إليه لتحقيق النجاح من التقديم الأول باستمرار.
وتتولى منصة goAML من Creodata دورة الامتثال للمخطط كاملةً وتلقائيًا — من مطابقة الحقول وفرض أنواع البيانات، مرورًا بالتحقق من قواعد العمل الخاصة بكينيا، وصولًا إلى إخراج ملفات XML اجتازت التحقق وفق XSD. ويركّز فريق الامتثال لديك على التحليل؛ وتتولى المنصة المتطلبات التقنية للتقديم.
شاهد المنصة وهي تعمل في عرض توضيحي مباشر.
اطلب عرضًا توضيحيًا ← https://www.creodata.com/demo
مقالات ذات صلة:
