السلام عليكم يا جماعة الخير، معكم أخوكم أبو عمر.
بتذكر قبل حوالي عشر سنين، كنا بنشتغل على ربط نظام مدفوعات لمتجر إلكتروني كبير. في يوم من الأيام، علقت حوالة مهمة جايّة من عميل في ألمانيا. أسبوعين والحوالة “ضايعة في الطوشة”، لا هي وصلت ولا هي رجعت. بعد شد وجذب وتحقيقات، اكتشفنا المصيبة: خطأ بسيط في حرف واحد في عنوان العميل المكتوب في حقل نصي حر داخل رسالة SWIFT MT 103 القديمة.
يومها، نظام الامتثال في البنك الألماني اعتبرها عملية مشبوهة وجمّدها. قضينا أيام وليالي على التلفونات والفاكسات (نعم، الفاكسات!) لنثبت إنه الموضوع مجرد خطأ مطبعي. البيانات كانت محدودة، غامضة، وتشبه شفرة قديمة أكثر من كونها معلومات مالية. وقتها قلت لحالي: “يا زلمة، لازم يكون في طريقة أحسن من هيك!”.
وها نحن اليوم، هذه “الطريقة الأحسن” أصبحت واقعاً اسمه ISO 20022، وهي على وشك أن تغير وجه المدفوعات العالمية إلى الأبد. فخلونا نفهم شو القصة، وكيف بنقدر نستعد إلها تقنياً كمطورين وشركات.
ما قصة رسائل SWIFT MT القديمة؟ ولماذا حان وقت رحيلها؟
تخيل أنك ترسل برقية قديمة. لديك عدد محدود من الكلمات، وعليك أن تختصر كل شيء برموز وأكواد غريبة. هذا هو بالضبط عالم رسائل SWIFT MT (Message Type) التي خدمت النظام المالي لعقود.
هذه الرسائل، مثل MT 103 (حوالة عميل) أو MT 940 (كشف حساب)، كانت فعالة في وقتها، لكنها اليوم تعاني من مشاكل جوهرية:
- بيانات محدودة وغير مهيكلة: معظم المعلومات المهمة (مثل عنوان المرسل أو تفاصيل الفاتورة) كانت تُكدس في حقول نصية حرة، مما يجعل معالجتها آلياً كابوساً حقيقياً.
- نقص في الشفافية: من الصعب تتبع مسار الحوالة بدقة أو معرفة سبب أي خصومات تمت عليها في الطريق.
- صعوبة في الامتثال: الأنظمة الآلية لمكافحة غسيل الأموال (AML) وتمويل الإرهاب (CFT) تجد صعوبة في تحليل هذه البيانات الفقيرة، مما يؤدي إلى الكثير من الإنذارات الكاذبة (false positives) وتأخير المدفوعات، زي ما صار معنا بالضبط.
ببساطة، العالم تغير، والتكنولوجيا تطورت، وهذه الرسائل أصبحت مثل سيارة قديمة في سباق فورمولا 1. جميلة كتراث، لكنها غير صالحة للمستقبل.
مرحباً بـ ISO 20022: اللغة الموحدة للمدفوعات
إذا كانت رسائل MT هي البرقية، فإن ISO 20022 هو البريد الإلكتروني الحديث والغني بالبيانات. هو ليس مجرد تحديث، بل هو ثورة حقيقية في كيفية تبادل المعلومات المالية. إنه معيار عالمي مفتوح لتبادل الرسائل المالية الإلكترونية.
ما الذي يجعله مختلفاً؟
- بيانات غنية ومهيكلة: بدلاً من الحقول النصية الحرة، يستخدم ISO 20022 بنية XML (أو JSON)، مما يعني أن كل جزء من المعلومات له مكانه المحدد. العنوان مقسم إلى شارع، مدينة، رمز بريدي، ودولة. تفاصيل الفاتورة لها حقولها الخاصة. هذا يعني وداعاً للتخمين وأهلاً بالدقة.
- شفافية كاملة: يمكنك إرفاق كم هائل من البيانات مع الدفعة المالية. تخيل أنك ترسل حوالة ومعها الفاتورة الأصلية، بوليصة الشحن، وشروط الدفع، كلها في رسالة واحدة مهيكلة!
- أتمتة فائقة: البيانات المهيكلة تعني أن الأنظمة يمكنها قراءة وفهم ومعالجة المدفوعات من البداية إلى النهاية (Straight-Through Processing – STP) دون تدخل بشري، مما يقلل الأخطاء والتكاليف بشكل كبير.
- امتثال أسهل: البيانات الواضحة والمفصلة تجعل عملية التحقق والامتثال أكثر كفاءة ودقة.
مقارنة عملية: MT 103 مقابل pacs.008 (ISO 20022)
زي ما بنحكي عنا، “الصورة بألف كلمة”. دعونا نرى مثالاً بسيطاً يوضح الفرق الشاسع بين النظامين. لنفترض أن “أبو ماهر” يريد إرسال 1500 دولار إلى “شركة النجاح” مقابل فاتورة رقم INV-2023-123.
رسالة SWIFT MT 103 التقليدية:
تبدو كشفرة، أليس كذلك؟ لاحظ كيف أن اسم وعنوان المرسل والمستفيد وتفاصيل الفاتورة كلها في حقول نصية حرة.
:20:TXNREF987654
:32A:231225USD1500,00
:50K:/12345678
ABU MAHER AL-NAJJAR
15 FALASTIN ST
NABLUS
:59:/87654321
AL-NAJAH CO.
23 AL-QUDS AVE
RAMALLAH
:70:/INV/INV-2023-123
رسالة pacs.008.001.08 (المكافئة في ISO 20022):
انظر إلى الوضوح والتنظيم! كل معلومة في مكانها الصحيح. هذه ليست مجرد بيانات، هذه معلومات ذات معنى.
<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08">
<FIToFICstmrCdtTrf>
<GrpHdr>
<MsgId>MSGID-20231225-1</MsgId>
<CreDtTm>2023-12-25T10:30:00</CreDtTm>
<NbOfTxs>1</NbOfTxs>
<SttlmInf>
<SttlmMtd>INDA</SttlmMtd>
</SttlmInf>
</GrpHdr>
<CdtTrfTxInf>
<PmtId>
<EndToEndId>TXNREF987654</EndToEndId>
</PmtId>
<IntrBkSttlmAmt Ccy="USD">1500.00</IntrBkSttlmAmt>
<Dbtr>
<Nm>Abu Maher Al-Najjar</Nm>
<PstlAdr>
<StrtNm>15 Falastin St</StrtNm>
<TwnNm>Nablus</TwnNm>
<Ctry>PS</Ctry>
</PstlAdr>
</Dbtr>
<Cdtr>
<Nm>Al-Najah Co.</Nm>
<PstlAdr>
<StrtNm>23 Al-Quds Ave</StrtNm>
<TwnNm>Ramallah</TwnNm>
<Ctry>PS</Ctry>
</PstlAdr>
</Cdtr>
<RmtInf>
<Strd>
<RfrdDocInf>
<Tp>
<CdOrPrtry><Cd>CINV</Cd></CdOrPrtry>
</Tp>
<Nb>INV-2023-123</Nb>
</RfrdDocInf>
</Strd>
</RmtInf>
</CdtTrfTxInf>
</FIToFICstmrCdtTrf>
</Document>
الفرق واضح كالشمس. النظام الجديد يسمح للآلات بفهم سياق المعاملة، وهذا يفتح أبواباً لا حصر لها للابتكار.
كيف نستعد تقنياً؟ خارطة طريق عملية من أبو عمر
التحول قادم لا محالة، والبنوك المركزية حول العالم بدأت بالفعل في تطبيقه. السؤال ليس “هل” سنتحول، بل “كيف” و”متى”. إليكم خارطة طريق عملية من واقع خبرتي:
الخطوة الأولى: الفهم والتحليل (اعرف عدوك وصديقك)
قبل كتابة أي سطر كود، يجب أن تفهم أنظمتك الحالية. اجلس مع فريقك واطرح هذه الأسئلة:
- أين في أنظمتنا نتعامل مع رسائل SWIFT MT؟ (أنظمة الدفع، التسويات، التقارير، أنظمة الامتثال).
- ما هي البيانات التي نستخدمها حالياً؟ وما هي البيانات الإضافية التي يمكن أن نستفيد منها في ISO 20022؟
- ما هي تأثيرات هذا التحول على قواعد البيانات، واجهات برمجة التطبيقات (APIs)، وتجربة المستخدم؟
نصيحة أبو عمر: ارسموا خريطة لتدفق البيانات (Data Flow Diagram) من نقطة دخول رسالة الدفع إلى نقطة خروجها. هذا سيجعل الصورة أوضح للجميع.
الخطوة الثانية: استغلال فترة التعايش (Coexistence)
الخبر الجيد أن التحول لن يحدث بين ليلة وضحاها. هناك فترة انتقالية (حتى نوفمبر 2025) ستتعايش فيها رسائل MT و MX (رسائل ISO 20022) معاً. هذا يعني أنك قد تستقبل رسالة MX وتحتاج لإرسال رسالة MT، أو العكس.
يمكنك استخدام خدمات ترجمة، مثل خدمة Transaction Manager من SWIFT، كحل مؤقت للتعامل مع هذه الفترة. لكن لا تعتمد عليها كحل دائم. الهدف النهائي هو أن تكون أنظمتك قادرة على التعامل مع رسائل ISO 20022 بشكل أصلي (natively).
الخطوة الثالثة: شغلة رسم الخرائط (Data Mapping)
هذه هي أصعب وأهم خطوة تقنية. يجب أن تقوم بعملية “رسم خرائط” دقيقة بين الحقول في رسائل MT القديمة والحقول الجديدة في رسائل MX. يا جماعة، هاي مش بس شغلة “copy-paste”. بدها فهم عميق لطبيعة البيانات في كلا النظامين.
على سبيل المثال، حقل العنوان النصي في MT 103 يجب أن يتم تحليله وتقسيمه بشكل صحيح إلى حقول الشارع، المدينة، الدولة في pacs.008. هذا قد يتطلب استخدام بعض الذكاء الاصطناعي أو تقنيات معالجة اللغات الطبيعية (NLP) للبيانات القديمة غير النظيفة.
الخطوة الرابعة: التطوير والاختبار (قيس قبل ما تغيص)
بناءً على التحليل ورسم الخرائط، حان وقت العمل:
- تحديث الأنظمة: قد تحتاج إلى تحديث أو استبدال بعض الأنظمة الأساسية لتكون قادرة على معالجة هياكل XML المعقدة والبيانات الكبيرة.
- بناء المحولات (Parsers/Mappers): ستحتاج إلى كتابة كود يقوم بتحليل (parsing) رسائل XML الواردة وإنشاء (generating) رسائل XML صادرة وفقاً لمعيار ISO 20022.
- الاختبار المكثف: لا تستهينوا بهذه الخطوة. استخدموا بيئة الاختبار (Sandbox) التي توفرها SWIFT والبنوك لاختبار كل السيناريوهات الممكنة: رسائل صحيحة، رسائل خاطئة، حالات حدودية (edge cases)، إلخ.
الخطوة الخامسة: ما بعد الهجرة.. الابتكار!
الهدف من ISO 20022 ليس فقط مواكبة التغيير، بل الاستفادة منه. بعد أن تستقر أنظمتك على المعيار الجديد، ابدأ بالتفكير:
- كيف يمكننا استخدام بيانات الفواتير المفصلة لتحسين عملية التسوية الآلية لحسابات عملائنا؟
- هل يمكننا تقديم خدمة تتبع للمدفوعات لعملائنا تشبه خدمة تتبع شحنات أمازون، باستخدام بيانات التتبع الموجودة في الرسائل؟
- كيف يمكننا تحليل البيانات الغنية هذه لتقديم رؤى مالية أفضل لعملائنا أو لتحسين تقييم المخاطر لدينا؟
هنا يكمن الذهب الحقيقي، وهذه هي الفرصة التي تفرق بين الشركات التي “تنجو” من التحول والشركات التي “تزدهر” بسببه.
الخلاصة: الزبدة
موت رسائل SWIFT MT القديمة ليس حدثاً حزيناً، بل هو ولادة لعصر جديد من الشفافية والكفاءة والابتكار في عالم المدفوعات. التحول إلى ISO 20022 هو مشروع كبير ومعقد، لكنه حتمي ومفيد على المدى الطويل.
نصيحتي الأخيرة لكم كمطورين وفرق تقنية: لا تنتظروا حتى اللحظة الأخيرة. ابدأوا اليوم بالتعلم والتحليل والتخطيط. هذا التحول ليس مجرد تحديث تقني، بل هو فرصة ذهبية لإعادة التفكير في كيفية بناء أنظمة مالية أذكى وأفضل وأكثر خدمة للمستخدم النهائي.
يلا يا جماعة، شدوا حيلكم، المستقبل بانتظار المبدعين. 😉
