SWIFT

تحويلات SWIFT والتواصل عبر رسائل MT وMX

SWIFT (جمعية الاتصالات المالية العالمية بين البنوك) هي شبكة مراسلة آمنة تتيح للمؤسسات المالية، كالمصارف، إرسال واستلام رسائل موحّدة بشأن المعاملات المالية، مثل تعليمات الدفع وإشعارات التأكيد. ولا تحتفظ SWIFT بحسابات ولا تحوّل أموالاً، بل توفّر منصة آمنة وموثوقة لتبادل المعلومات فحسب.

تستخدم تحويلات SWIFT العادية سلسلة من أنواع الرسائل القياسية المعروفة برسائل MT (Message Type). وتتميز هذه الرسائل بصيغ وحقول محددة مسبقًا، مما يتيح للمؤسسات المالية فهم المعلومات الواردة فيها ومعالجتها بسهولة.

رسائل MX (ISO 20022) هي معيار أحدث للمراسلات المالية قائم على لغة XML (لغة الترميز القابلة للتوسعة). وتوفر صيغة أغنى وأكثر بنيةً، مما يتيح تبادلًا معززًا للبيانات ومعالجة مباشرة بالكامل (STP) أفضل. وتحل رسائل MX تدريجيًا محل رسائل MT في شبكة SWIFT، بهدف توفير قابلية أفضل للتشغيل البيني وإمكانات أفضل لمعالجة البيانات.

على الرغم من أن حوالات SWIFT التقليدية شكّلت العمود الفقري للمدفوعات الدولية لعقود، فإنها تنطوي على بعض القيود، منها محدودية الشفافية، وبطء المعالجة، وعدم هيكلة البيانات.

Swift 103+ STP (المعالجة الآلية الكاملة)

كان Swift 103+ STP صيغة MT القديمة المُحسَّنة للمعالجة المباشرة (STP)؛ ومنذ انتهاء فترة التعايش حلّ محلها دليل استخدام pacs.008 STP. وتتيح المعالجة المباشرة (STP) إتمام عملية الدفع بأكملها، من البدء حتى التسوية النهائية، إلكترونيًا دون الحاجة إلى تدخل يدوي.

ميزات إضافية:

1. صيغة موحدة: تتطلب التزامًا صارمًا بصيغة موحدة، مما يقلل الأخطاء والتأخيرات.
2. المعالجة الآلية: تُعالَج المعاملات آليًا، مما يضمن معالجة أسرع وأكثر كفاءة.
3. تقليل التدخل اليدوي: تتقلص الحاجة إلى الإدخال والتحقق اليدويين، مما يحدّ من مخاطر الأخطاء والتأخير.
4. تسوية أسرع: تُسوّى المعاملات بوتيرة أسرع مقارنةً بالأساليب التقليدية.

اعتبارات المعالجة المباشرة (STP):

1. دقة إدخال البيانات: يجب إدخال البيانات بدقة لتفادي التأخير أو الرفض.
2. الامتثال لمتطلبات الصيغة: يتعين على المصارف التأكد من الالتزام الصارم بمتطلبات صيغة 103+ STP.
3. البرمجيات والأنظمة: يتعين على المصارف توفير برمجيات وأنظمة ملائمة للتعامل مع المعالجة المباشرة (STP) بفاعلية

من الضروري التمييز بين تبادل الرسائل والتسوية. فشبكة SWIFT تنقل رسائل مالية منظمة بين المؤسسات، لكنها لا تنقل الأموال بنفسها ولا تحتفظ بأرصدة. ولا يكون تأكيد SWIFT، بما في ذلك رسالة pacs.008، صالحًا إلا إذا قابل معاملة فعلية جرت معالجتها ومطابقتها ضمن الأنظمة المصرفية للمؤسسات المشاركة.

لا ينبغي اعتبار أي مستند SWIFT منفرد أو لقطة شاشة أو رسالة يُبرز دون تحقق مؤسسي دليلاً على اكتمال التسوية.

تحويلات SWIFT gpi.

SWIFT gpi (مبادرة الابتكار في المدفوعات العالمية):

أُطلقت SWIFT gpi في عام 2017، وهي مبادرة تهدف إلى معالجة أوجه القصور في تحويلات SWIFT التقليدية من خلال تعزيز سرعة المدفوعات العابرة للحدود وشفافيتها وإمكانية تتبعها. وتستفيد SWIFT gpi من صيغ الرسائل MT وMX القائمة لتحسين خدمات الدفع. ومن أبرز ميزات SWIFT gpi:

• سرعة أكبر في المدفوعات: يبسّط gpi الإجراءات ويضع اتفاقيات مستوى خدمة (SLAs) أكثر إحكامًا بين المصارف، مما يؤدي إلى تقليص أزمنة تنفيذ المعاملات، وغالبًا ضمن دقائق أو ثوانٍ.
• تتبع المدفوعات: تتيح أداة gpi Tracker تتبع المعاملات في الوقت الفعلي، مما يعزز الشفافية ويقلل من التحقيقات اليدوية.
• شفافية الرسوم: يمكن للمصارف تزويد العملاء مسبقًا بمعلومات عن رسوم المعاملات، مما يتيح اتخاذ قرارات أفضل.
• بيانات أكثر ثراءً: يدعم gpi تبادل معلومات أكثر تفصيلًا وتنظيمًا، مما يسهّل تحسين المطابقة والامتثال التنظيمي.

تعالج خدمة SWIFT gpi أوجه القصور في تحويلات SWIFT التقليدية من خلال تعزيز المدفوعات عبر الحدود بتتبّع شامل من البداية إلى النهاية، ومعالجة أسرع، وبيانات أكثر ثراءً.

المعايير الرئيسية للمشاركين من غير مشاركي SWIFT gpi

عندما يرسل مشارك غير منضم إلى SWIFT gpi (كمصرف أو مؤسسة مالية غير مسجَّلة مباشرةً في gpi) تعليمات دفع إلى مصرف مشارك في gpi، يستطيع المصرف المشارك في gpi تحويلها إلى صيغ رسائل SWIFT المطلوبة (pacs.008 للتحويلات الائتمانية للعملاء، وpacs.009 COV لتحويلات التغطية، وpacs.009 للتحويلات الائتمانية بين المؤسسات المالية). ويتيح هذا التحويل المعالجة والتتبّع داخل شبكة gpi، شريطة أن تتضمن التعليمات بيانات كافية لاستيفاء الحقول الإلزامية والامتثال لقواعد gpi، مثل إمكانية التتبّع من طرف إلى طرف.

يقدّم المشاركون غير المنضمّين إلى gpi هذه المعلمات عادةً عبر مخططات الدفع المحلية أو واجهات البرمجة (APIs) أو الصيغ القديمة، ويتولى المصرف المنضمّ إلى gpi إضافة العناصر الخاصة بـ gpi (مثل إنشاء UETR إذا لم يُقدَّم، علمًا بأن تمريره اختياري بالنسبة للجهات غير المنضمّة إلى gpi). وقد تختلف المتطلبات الدقيقة بحسب الاختصاص القضائي والعملة والاتفاقيات الثنائية، إلا أن المعلمات الأساسية مستمدة من إرشادات CBPR+ (المدفوعات والتقارير عبر الحدود Plus) ومعايير ISO 20022. ومنذ انتهاء فترة التعايش في 22 نوفمبر 2025، تُتبادل تعليمات الدفع عبر الحدود بصيغة ISO 20022؛ وتُذكر مراجع حقول MT القديمة أدناه للاسترشاد فقط.
1. تحديد الأطراف (بيانات المدين والدائن)
تحدد هذه البيانات المُنشئ والمستفيد، بما يضمن الامتثال للتوصية 16 الصادرة عن FATF بشأن متطلبات قاعدة السفر.

• المدين/العميل الآمر: الاسم الكامل، والعنوان المنظّم (الشارع، المدينة، الرمز البريدي، البلد)، وبيانات تعريف الحساب (مثل IBAN أو رقم الحساب). وفي رسالتي MT 103/MT 202 COV السابقتين يقابل ذلك الحقل 50a؛ وفي pacs.008/pacs.009 يقابله <Dbtr> و<DbtrAcct>.
• الدائن/العميل المستفيد: الاسم الكامل، والعنوان المهيكل، وبيانات تعريف الحساب. ويقابل الحقل 59a في رسالتي MT103/MT202 COV السابقتين؛ و<Cdtr> و<CdtrAcct> في pacs.008/pacs.009.
• المدين/الدائن النهائي (عند الاقتضاء): في حال اختلافه عن الطرفين الرئيسيين، يُرجى إدراج بياناته لتعزيز الشفافية (اختياري لكنه موصى به لتتبع gpi). يقابل <UltmtDbtr>/<UltmtCdtr> في pacs.008/pacs.009.

سبب الاشتراط: يتيح التوجيه الدقيق وإجراء الفحوص التنظيمية؛ وقد يؤدي نقص البيانات إلى الرفض أو التأخير.

2. معلومات الوكلاء والتوجيه
تحدّد المؤسسات المالية المشاركة في السلسلة.

• وكيل المدين: رمز BIC (رمز تعريف المصرف) أو أي معرّف آخر للمصرف المُرسِل. ويقابل الحقل 52a في رسالة MT 103 السابقة؛ و<DbtrAgt> في pacs.008/pacs.009.
• مصرف الدائن: رمز BIC للمصرف المستلم. ويقابل الحقل 57a في الرسالتين السابقتين MT 103/MT 202 COV؛ والعنصر <CdtrAgt> في pacs.008/pacs.009.
• الوكلاء الوسطاء (إن كانوا معروفين): رموز BIC لأي مراسلين (حتى ثلاثة مستويات). يقابل الحقل 56a في رسالة MT السابقة؛ و<IntrmyAgt1-3> في رسالتي pacs.008/pacs.009.
• الوكلاء الآمرون/المأمورون: رموز BIC للمرسِل/المستلِم المباشر في السلسلة. اختيارية، لكنها تساعد في أسلوبَي التسلسل والتغطية.
• الوكلاء المُعطون للتعليمات السابقون (إن وُجدوا): في السلاسل متعددة المراحل، حتى 3 وكلاء سابقين.

سبب الإلزام: يضمن التوجيه الصحيح عبر الوسطاء؛ ويُفضَّل استخدام BICFI على الأسماء لتحقيق الدقة في pacs.009 COV.

3. تفاصيل المعاملة
العناصر المالية الأساسية للتسوية.

• المبلغ والعملة: مبلغ التسوية بين المصارف ورمز العملة وفق ISO 4217 (مثل USD وEUR). يقابل الحقل 32A في رسالتي MT 103/MT 202 COV السابقتين؛ والعنصر <IntrBkSttlmAmt> في pacs.008/pacs.009.
• المبلغ المحدد في التعليمات (Instructed Amount) (إن اختلف): المبلغ الأصلي قبل الخصومات.
• تاريخ التسوية بين المصارف: تاريخ القيمة المحدد للتسوية. يقابل جزءًا من الحقل 32A في رسائل MT؛ و<IntrBkSttlmDt> في pacs.008/pacs.009.
• أسلوب التسوية: يُحدَّد ما إذا كانت التسوية عبر نظام التسوية الإجمالية الفورية (CLRG)، أو بتغطية (COVE)، أو عبر وكيل (INDA/INGA). لا يوجد مكافئ مباشر في MT، لكنه مفهوم ضمنًا.

سبب الإلزام: يحدد نقل القيمة؛ وهو إلزامي لجميع الصيغ.

4. معرّفات المرجع والتتبع
لأغراض التتبع، ولا سيما في gpi.

• التعريف الشامل من البداية إلى النهاية: مرجع يربط السلسلة بأكملها (مثل الفاتورة أو معرّف المعاملة). <EndToEndId> في pacs.008/pacs.009.
• معرّف التعليمات: مرجع المُرسِل (محدود بـ 16 حرفًا في MT). يقابل الحقل 20 في MT السابق؛ <InstrId> في pacs.008/pacs.009.
• المرجع الفريد للمعاملة من طرف إلى طرف (UETR): معرّف فريد عالمي (UUID) للتتبع من طرف إلى طرف. وهو إلزامي في pacs.008/pacs.009، وفي الرسالتين السابقتين MT103/MT202 يرد في الحقل 121؛ وإذا لم تقدّمه قناة الإرسال، يولّده أول مصرف في السلسلة متصل بشبكة SWIFT.
• معرّف المعاملة: مرجع داخلي إضافي.

سبب الإلزام: يتيح تتبّع gpi وربط الرسائل (مثل ربط pacs.008 بـ pacs.009 COV)؛ ويُعد معرّف UETR العنصر الأساسي للتأكيدات الشاملة.

5. معلومات الغرض والخدمة
يصنّف نوع الدفعة.

• رموز الغرض وفئة الغرض: رموز ISO (مثل SALA للراتب) تبيّن طبيعة المعاملة. وهي مطلوبة في بعض المسارات؛ العنصران <Purp> و<CtgyPurp> في pacs.008.
• رمز مستوى الخدمة: يحدد خدمة gpi (مثل G001 لتحويل ائتماني للعملاء عبر gpi)؛ ولا ينبغي للمصارف غير المشاركة في gpi إدراج رموز خاصة بـ gpi ما لم يتم الاتفاق على ذلك. ويقابل الحقل 23E في MT؛ و<SvcLvl> في pacs.008/pacs.009.
• رمز الأداة المحلية: للأنظمة الخاصة (مثل التحويلات داخل المجموعة الواحدة).

سبب الاشتراط: يكفل الامتثال التنظيمي وأولوية المعالجة؛ وقد أصبح إلزاميًا بصورة متزايدة عقب التحول إلى معيار ISO.

6. التحويل والتعليمات الإضافية

• معلومات التحويل: غير منظمة (حتى 140 حرفًا) أو منظمة (مثل تفاصيل الفاتورة). تقابل الحقل 70 في رسالة MT 103 السابقة؛ و<RmtInf> في pacs.008/pacs.009.
• تعليمات للوكلاء: مثل /REC/ للمستلم، أو /ACC/ للحساب، أو تعليمات هاتفية (PHOB). وتقابل الحقل 72 في رسالة MT السابقة؛ و<InstrForNxtAgt>/<InstrForCdtrAgt> في pacs.008/pacs.009.
• مؤشرات توقيت التسوية: الأوقات المطلوبة (مثل CLSTm لتوقيت CLS).

سبب الإلزام: يوفّر السياق وتعليمات المعالجة؛ وهو ضروري لأساليب التغطية في pacs.009 COV.

7. البيانات التنظيمية وبيانات الامتثال

• التقارير التنظيمية: رموز أو تفاصيل (مثل الرقم الضريبي أو مؤشر الإبلاغ مثل CRED/DEB). ويقابل الحقل 77B في رسالة MT؛ و<RgltryRptg> في pacs.008/pacs.009.
• رموز أسباب الإرجاع (عند الاقتضاء في حالات الإرجاع): مثل AC04 للحساب المغلق، في الرسالة pacs.004 المرتبطة بالرسائل الأصلية.

سبب الاشتراط: يفي بالتزامات مكافحة غسل الأموال (AML) والتعرّف على العميل (KYC) والإبلاغ؛ وهو إلزامي في المسارات الخاضعة للتنظيم.

وفقًا لأفضل الممارسات، ينبغي للمشاركين من غير مستخدمي gpi هيكلة البيانات على نحو يتجنب اقتطاعها أثناء التحويل من MT إلى MX، والتشاور مع المصرف العضو في gpi بشأن الاحتياجات المحددة. وإذا انطوت عملية الدفع على أساليب التغطية، فيجب أن تتطابق تفاصيل العميل الأساسية عبر الرسائل (مثل pacs.008 إلى pacs.009 COV).

رسائل الدفع في SWIFT gpi

في إطار SWIFT gpi (ابتكارات المدفوعات العالمية)، تُعدّ رسائل الدفع الأصلية (مثل pacs.008 للتحويلات الخاصة بالعملاء أو pacs.009 COV لتحويلات التغطية) غير قابلة للتغيير بمجرد إرسالها. ولا يجوز للمصارف المستلمة تعديل محتوى هذه الرسائل أو تغييره مباشرةً، إذ صُمّمت رسائل SWIFT للحفاظ على السلامة وقابلية التدقيق على امتداد سلسلة الدفع. وبدلاً من ذلك، تُعالَج أي تغييرات أو تصحيحات أو إلغاءات عبر رسائل متابعة منفصلة، أو تحديثات الحالة عبر gpi Tracker، أو خدمات مخصصة مثل gSRP (gpi Stop and Recall Payment). ويضمن ذلك إمكانية التتبّع من طرف إلى طرف باستخدام المرجع الفريد للمعاملة من طرف إلى طرف (UETR).

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

شروط قيام المصارف المستلمة بطلب إجراء تعديلات أو تيسيرها
يجوز للمصارف المستلمة أن تطلب إجراء تعديلات (مثل تصحيح البيانات) أو أن تتخذ إجراءات تقتضي إدخال تغيير حين يتعذر تنفيذ الدفعة الأصلية وفق التعليمات. ويتم ذلك عادةً عبر رسائل الاستفسار (مثل MT 195/199) أو عبر الردود على الطلبات الصادرة من المرسِل. وتشمل أبرز الشروط ما يلي:

• أخطاء في تفاصيل الدفع: في حال وجود عدم دقة، كأن يكون حساب المستفيد غير صحيح (مثل حساب مغلق – الرمز AC04)، أو العملة خاطئة (الرمز CURR)، أو توجيه الوكيل غير صحيح (الرمز AGNT)، أو وجود مشكلات تقنية (الرمز TECH)، يجوز للمصرف المستلم تعليق الدفعة ومطالبة المُرسِل بتقديم بيانات مصححة أو إرسال دفعة جديدة. وبذلك يُتفادى الرفض الكامل مع إتاحة المجال للمعالجة.
• تعذّر قيد الدفعة: بموجب الرمز CUTA (Cancel Upon Unable to Apply)، إذا تعذّر قيد الدفعة بسبب عدم التطابق (مثل اختلاف الاسم/الحساب أو نقص التفاصيل)، يجوز للمصرف المستلم أن يطلب من المُرسِل تفاصيل الإلغاء أو التعديل لمعالجة الأمر.
• الاحتيال المشتبه به أو المعاملات غير المصرّح بها: في حالات الاحتيال (الرمز FRAD)، يستطيع المصرف المتلقي أن يكتشف المشكلات بصورة مستقلة وأن يبادر إلى إعادة الأموال دون طلب مسبق من المرسِل. ويستطيع أيضًا الرد على طلبات الاسترداد الواردة من المرسِل بحجز الأموال وطلب التعويض (الرمز INDM) إذا كانت الأموال قد قُيّدت بالفعل، وذلك للحد من المخاطر قبل إعادتها.
• المدفوعات المكررة أو غير المستحقة: تتيح رموز مثل DUPL (دفعة مكررة) أو UPAY (دفعة غير مستحقة) للمصرف المستلم الإشارة إلى المعاملة وطلب إلغائها إذا كانت خاطئة أو غير مبررة.
• مسائل تنظيمية أو متعلقة بالامتثال: إذا كان الدفع يخالف القوانين المحلية أو العقوبات أو متطلبات مكافحة غسل الأموال (الرمز LEGL)، فيجوز للمصرف المستلم رفضه أو تعليقه وطلب مستندات إضافية أو تعديلات من المُرسِل.
• قرارات العميل أو المستفيد: إذا رفض المستفيد الدفعة (الرمز CUST أو NOAS – عدم رد من المستفيد)، يجوز للمصرف المستلم إعادتها وإخطار المرسِل، وقد يطلب تأكيد التعديلات.
• القرارات المعلّقة: في الحالات المعلّقة (الرمز PDCR)، كالانتظار لصدور تفويض الخصم (RQDA) أو لورود رد من الوكيل التالي (PTNA)، يجوز للمصرف المستلم تعليق الدفعة وطلب تعليمات إضافية أو تعديلات لمتابعة التنفيذ.

وفي جميع الحالات، يجب أن تكون الطلبات مهيكلة بصيغة تتيح المعالجة الآلية (مثل تضمين UETR والمراجع الأصلية كالحقول 20/32A/50/59 والرموز المحددة في الحقل 79 من الرسائل) لدعم المعالجة المباشرة دون تدخل يدوي. وقد تُطلب اتفاقيات تعويض ثنائية إذا أُودعت الأموال في الحساب، ولا يقع على المصرف المتلقي أي التزام بقبول الطلبات، لكن عليه إعطاء الأولوية للطلبات العاجلة (مثل المتعلقة بالاحتيال).

العمليات المعنية

• الرد على طلبات الاسترداد الصادرة عن المُرسِل: يبادر المُرسِل (مصرف المدين) عادةً إلى طلب الاسترداد عبر MT 192/292 (أو ما يعادلها في ISO 20022 مثل camt.056) من خلال خدمة gSRP، ويُرسَل على التوالي أو مباشرةً إلى المصرف المستلم. وعلى المصرف المستلم أن يقرّ بالاستلام فورًا وأن يرد بالرسالة MT 196/296 (أو MT 199/299 إذا كانت مهيكلة)، مستخدمًا رموزًا مثل CNCL (ملغاة) وRJCR (مرفوضة مع بيان السبب) وPDCR (قيد الانتظار). وفي حال القبول، تُعاد الأموال عبر pacs.004 (إرجاع الدفعة).
• الإجراءات المستقلة للمصارف المستلمة: إذا اكتُشف احتيال داخليًا، يجوز للمصرف المستلم إعادة الأموال باستخدام pacs.004 مع بيانات مهيكلة، مع الإخطار عبر أداة التتبّع (Tracker) لتحديثات الحالة الآنية.
• طلبات التعديل/التوضيح: تستخدم المصارف المستلمة رسائل الاستفسار (مثل MT 195/295) لطلب تغييرات، كإضافة تفاصيل. وهذا شائع في المدفوعات المعلّقة.
• تكامل نظام التتبع: تُحدِّث جميع الإجراءات نظام التتبع gpi Tracker آنياً، ويمكن الاطلاع عليه عبر واجهات برمجة التطبيقات أو الواجهة الرسومية، بما يضمن الشفافية لجميع الأطراف. ويتعين على أعضاء gpi الالتزام بكتيبات القواعد الإلزامية الخاصة بـ gCCT (تحويل الائتمان للعملاء) وgCOV (التغطية) وgSRP.
• القيود وعوامل النجاح: لا تُضمن التعديلات؛ إذ يعتمد النجاح على مرحلة الدفع (فالتعديل قبل القيد أيسر)، وعلى تعاون المستفيد، وعلى الاختصاص القضائي. وفي حال تم القيد، يتطلب الإرجاع موافقة المستفيد أو تعهدًا بالتعويض. وتسمو اللوائح دائمًا على الإرشادات.

تنطبق هذه الممارسات أساسًا على أعضاء gpi، غير أن المصارف غير الأعضاء في gpi يمكنها المشاركة عبر بوابات الربط. وللاطلاع على أحدث التفاصيل، يُرجى الرجوع إلى كتيبات القواعد الرسمية الصادرة عن SWIFT، إذ تتطور العمليات (مثلًا مع الانتقال إلى ISO 20022).

الفصل بين الرسائل والتسوية في SWIFT gpi

يتولى SWIFT gpi في المقام الأول معالجة تعليمات الدفع وتتبعها عبر الرسائل (مثل صيغ ISO 20022 كرسالة pacs.008 لتحويلات العملاء، وpacs.009 للتحويلات المالية، أو رسائل MT 103/MT 202 القديمة)، بينما تتم حركة الأموال الفعلية بصورة منفصلة على مستوى التسوية. وتجري التسوية عادةً عبر علاقات الخدمات المصرفية للمراسلين (حسابات نوسترو/فوسترو)، أو المقاصة الثنائية، أو آليات المقاصة والتسوية (CSMs) مثل أنظمة التسوية الإجمالية الفورية (RTGS) (مثل T2، المعروف سابقًا باسم TARGET2، في أوروبا، وFedwire في الولايات المتحدة، وCHAPS في المملكة المتحدة). ويوفر متتبّع gpi رؤية فورية لحالة الرسائل، غير أن تحويل الأموال يعتمد على هذه الأنظمة الأساسية.

انتهت في 22 نوفمبر 2025 فترة التعايش الخاصة بتعليمات الدفع العابرة للحدود: فقد حلّت رسائل ISO 20022 (MX) مثل pacs.008 وpacs.009 محلّ تعليمات الدفع مثل MT103 وMT202، في حين يجري سحب فئات MT الأخرى في تواريخ لاحقة. ويوضح ما يلي كيفية حدوث عمليات الإرجاع وفكّ الحجز على مستوى الحساب والمقاصة والتسوية.

كيفية إعادة الأموال على مستوى الحساب/المقاصة/التسوية
تبدأ عمليات الإرجاع بعد نجاح طلب الاسترداد (عبر gSRP – خدمة gpi لإيقاف الدفع واسترداده) أو عبر الاكتشاف المستقل (مثل الاحتيال أو الأخطاء). وتستخدم خدمة gSRP رسالة camt.056 (طلب إلغاء الدفع) الصادرة عن المُرسِل، ويُردّ عليها برسالة camt.029 (نتيجة التحقيق). وعند القبول، يُنفَّذ إرجاع الأموال من خلال تعليمات دفع جديدة تعكس مسار التدفق، فيُخصم من حساب المصرف المستلم ويُقيَّد دائنًا عبر السلسلة. وهذا لا يمثّل تعديلًا للرسالة الأصلية، بل معاملة مستقلة.

أساليب التسوية الرئيسية وإجراءات الإرجاع
تحدد أساليب التسوية كيفية حدوث الإرجاع:

• CLRG (المقاصة عبر البنية التحتية للسوق): التسوية من خلال نظام التسوية الإجمالية الفورية (RTGS) أو آلية المقاصة والتسوية (CSM) (على سبيل المثال عبر مصرف مركزي). وتستخدم عمليات الإرجاع رسالة pacs.004 لتوجيه البنية التحتية للسوق إلى قيد مدين على حساب الوكيل المستلم وقيد دائن على حساب الوكيل السابق، وغالبًا ما يتم ذلك في الوقت الفعلي أو في اليوم نفسه.
• INGA (الوكيل المُصدِر للتعليمات يسوّي أولاً): يسوّي المُرسِل الأموال قبل إرسال الرسالة. وتُقيَّد المرتجعات عبر pacs.004 على حساب الوكيل المُستلِم للتعليمات بعد التسوية.
• INDA (يسوّي الوكيل المُكلَّف عند الاستلام): يسوّي المستلِم عند استلام الرسالة. وإذا لم تتم التسوية، تُرفض عبر pacs.002 (دون تحريك أي أموال)؛ أما إذا تمت التسوية، فتُعاد عبر pacs.004.
• COVE (طريقة التغطية): تُستخدم للمدفوعات ذات القيمة المرتفعة التي تتضمن تحويل تغطية (pacs.009 COV). وتتبع المرتجعات المسار العكسي: رسالة pacs.004 من وكيل المستفيد إلى الوسطاء، مع إجراء القيد المدين والدائن في حسابات المراسلين وفقًا لذلك.

إجراءات الإرجاع خطوة بخطوة على مستوى التسوية

1. الإطلاق والقبول: يطلب المُرسِل الاسترداد (مثلًا عبر camt.056 مع UETR). ويردّ المستلم (camt.029) ويقبل إذا كانت الأموال متاحة/لم تُقيَّد بعد لحساب المستفيد (ويكون الأمر أيسر قبل القيد). وإذا كانت قد قُيِّدت، فقد يلزم الحصول على موافقة المستفيد أو تعويض.

2. تعليمات إعادة الأموال: يصدر المستلم رسالة pacs.004 (إعادة الدفع) أو رسالة MT 103/MT 202 بصيغتها التقليدية مع رموز الإعادة (مثل RETN). وتتضمن هذه الرسالة ما يلي:

• المراجع الأصلية (UETR، ومعرّف المعاملة من طرف إلى طرف (End-to-End ID)، ومعرّف التعليمات).
• انعكاس الأدوار: يصبح الدائن الأصلي مدينًا، ويصبح وكيل المدين الأصلي دائنًا.
• تفاصيل التسوية: المبلغ/التاريخ الأصلي للتسوية بين المصارف، سعر الصرف (في حال تضمّنت العملية صرف عملات)، الرسوم (إن خُصمت).
• رمز سبب الإرجاع (مثل AC04 للحساب المغلق، وFRAD للاحتيال).
• حقل حساب التسوية (إن ورد في الرسالة الأصلية) لتحديد الحساب المراد قيد المبلغ فيه.

3. تنفيذ التسوية:

• تؤدي رسالة pacs.004 إلى الخصم من حساب نوسترو/فوسترو الخاص بالمصرف المستلم (المحتفظ به لدى الوكيل السابق أو البنية التحتية للسوق).
• تُقيَّد الأموال مجددًا حلقةً بعد حلقة عبر السلسلة، باستخدام طريقة التسوية نفسها (مثل تحويل التسوية الإجمالية الفورية (RTGS) في CLRG).
• في حال الإعادة الجزئية، يُذكر «PART» في حقل المعلومات الإضافية مع المبلغ المحتسب بالتناسب.
• يحدّث المتتبِّع الحالة (مثل «مُعاد») في الوقت الفعلي، وتكون ظاهرة عبر واجهة برمجة التطبيقات (API) أو الواجهة الرسومية (GUI).

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

5. إشعارات ما بعد الإرجاع: استخدم camt.053/054 (كشف الحساب/إشعار الخصم والإيداع) لتأكيد تحديث السجلات. لا تُستخدم رسالة pacs.004 مرة أخرى لـ«إرجاع إرجاع»؛ بل تُستخدم الاستفسارات بدلاً من ذلك.
تتم عمليات الإرجاع آلياً حيثما أمكن، ولكن قد يلزم تدخل يدوي لأغراض الامتثال أو إذا كانت الأموال مجمّدة. والاسترداد غير مضمون؛ إذ يعتمد في المقام الأول على مدى سرعة إرسال طلب الاسترجاع وعلى ما إذا كانت الأموال قد قُيّدت بالفعل. وإذا لم تتم التسوية (مثلاً في حال الرفض قبل التسوية)، فلا تنتقل أي أموال: استخدم pacs.002 بدلاً من ذلك.

كيفية الإفراج عن المدفوعات المعلّقة (الموافقة على تنفيذها) على مستوى الحساب/المقاصة/التسوية

تحدث حالات التعليق عندما يتعذّر تنفيذ دفعة على الفور (مثلًا بسبب أخطاء، أو فحوصات الامتثال، أو انتظار توضيحات)، فتُوضع في حالة «معلّقة» دون تسوية. ولا يُخصم أي مبلغ ولا يُقيَّد أي مبلغ إلى حين الحل. ويعرض gpi Tracker حالات مثل «On Hold» أو «Pending» (مثل الرمز PDCR)، ويتم الحل عبر رسائل الاستفسار (MT 195/199 أو camt.029).

الحالات التي تؤدي إلى فرض الحجز

• حالات عدم التطابق (مثل عدم تطابق الحساب والاسم – رمز CUTA).
• الفحوص التنظيمية (مثل العقوبات – رمز LEGL).
• في انتظار ردّ المستفيد (الرمز NOAS) أو تفويض الخصم (الرمز RQDA).
• ساعات توقف الأنظمة عن العمل أو المعالجة الدفعية لدى مصرف المستفيد.

عملية الإفراج على مستوى التسوية
1. إشعار التعليق: يرسل المستلم رسالة pacs.002 (تحديث الحالة) أو MT 199 برمز التعليق، ويحتفظ بالأموال في حساب معلّق/حساب ضمان إذا كانت التسوية جزئية (كما في طرق التغطية مثلاً).
2. المعالجة والحل: يقدّم المرسل التعديلات/التوضيحات (مثلاً عبر الرد بـ MT 195 أو camt.029). وإذا جرى الحل، يعطي المستلم «الضوء الأخضر» بمعالجة التعليمات الأصلية.
3. تنفيذ التسوية:

• يُفرج عن رسالة pacs.008/pacs.009 الأصلية من وضع الإيقاف.
• تتم تسوية الأموال بالطريقة المحددة: يُخصم من حساب المرسل ويُقيَّد في حساب المستلم (مثلاً عبر نظام التسوية الإجمالية الفورية RTGS في CLRG)، ثم يُقيَّد المبلغ نهائياً في حساب المستفيد.
• غالبًا ما تكون مرحلة المستفيد (من المصرف المستلم إلى العميل النهائي) هي التي تقع فيها حالات التأخير، ولا سيما في الأسواق التي تفرض ضوابط على رؤوس الأموال أو تفتقر إلى البنية التحتية الكافية.
• يتحدّث المتتبّع إلى «تم الإيداع» أو «مكتمل»، مع تأكيد ذلك برسالة pacs.002 (تقرير حالة الدفع).

4. في حال عدم الإفراج: إذا بقي الأمر دون حسم (مثلاً بعد انقضاء المهلة)، تُعاد الأموال عبر pacs.004 كما هو مبيّن أعلاه، أو تُرفض العملية عبر pacs.002 (دون تسوية).

تشترط قواعد gpi قيد المبالغ في الحساب في اليوم نفسه حيثما أمكن؛ وقد أفادت Swift في عام 2018 بأن نحو 50% من مدفوعات gpi قُيّدت خلال 30 دقيقة، وأن ما يقارب 100% منها قُيّد خلال 24 ساعة. وقد تؤدي عوامل مثل ضوابط رأس المال أو ساعات عدم عمل المصارف إلى إطالة فترات الاحتجاز، إلا أن gpi تركّز على الأتمتة للحدّ منها.

SwiftNet Instant

SwiftNet Instant. وهي منصة مراسلة لحظية منخفضة زمن الاستجابة متاحة على مدار الساعة طوال أيام الأسبوع، وتدعم التبادل الآمن لتدفقات المدفوعات الفورية بين آليات المقاصة والتسوية (CSMs) والمشاركين فيها.

يمكن للعملاء الاتصال بـ SwiftNet Instant باستخدام بنيتهم التحتية الحالية للاتصال بشبكة Swift وتأمين هذا الاتصال، بما في ذلك أجهزة VPN والخطوط المؤجرة ووحدات أمان الأجهزة (HSM). ويتحقق التكامل مع بيئة تقنية المعلومات في المصرف من خلال Alliance Gateway Instant (AGI).

يمكن لجميع الأطراف على امتداد سلسلة المدفوعات الفورية استخدام AGI ورسائل SwiftNet Instant. وتشمل التطبيقات بدء الدفع من خلال خدمة تراكبية، أو الاتصالات غير المباشرة للأعضاء مع عضو راعٍ، أو تلقي شركة ما تأكيدًا لعملية دفع.

يربط SWIFT Instant بين أنظمة الدفع الفوري المحلية لإتاحة معالجة المعاملات في الوقت الفعلي، داخل البلد الواحد وعلى الصعيد الدولي، باستخدام معيار ISO 20022. وتمثل هذه الأنظمة جهودًا متواصلة لتحديث عمليات الدفع وتبسيطها في القطاع المالي.

الخصم المباشر عبر SWIFT

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

تتضمن عملية بدء معاملة الخصم المباشر ضمن نظام SWIFT عادةً الخطوات التالية:

1. الاتفاق بين الدائن والمدين: يجب أن يوجد اتفاق مسبق بين الدائن والمدين يتضمن شروط وأحكام معاملات الخصم المباشر. وقد يشمل هذا الاتفاق أيضًا إعداد تفويض أو إذن يتيح للدائن تحصيل المدفوعات من الحساب المصرفي للمدين.
2. تبادل الرسائل: يبادر مصرف الدائن إلى الخصم المباشر بإرسال رسالة SWIFT إلى مصرف المدين – وهي في ISO 20022 رسالة pacs.003 (الخصم المباشر للعميل) أو pacs.010 (الخصم المباشر للمؤسسة المالية)، وكانت سابقاً MT 104 أو MT 204. وتتضمن هذه الرسالة تفاصيل المعاملة، كالمبلغ والعملة وبيانات حساب المدين وأي معلومات أخرى لازمة.
3. التحقق والتفويض: يتحقق مصرف المدين من تفاصيل المعاملة، ويفحص توافر الأموال في حساب المدين، ويؤكد التفويض بإجراء المعاملة. وإذا كانت جميع الأمور سليمة، يمضي مصرف المدين في خصم الأموال من حساب المدين.
4. تحويل الأموال: تتم تسوية الأموال بين مصرف المدين ومصرف الدائن عبر حسابات المراسلة أو عبر نظام للمقاصة والتسوية.
5. التأكيد: عند استلام الأموال، يرسل مصرف الدائن تأكيداً إلى الدائن يُخطره فيه بنجاح معاملة الخصم المباشر.

فيما يلي المتطلبات المسبقة لبدء معاملة خصم مباشر داخل نظام SWIFT:

1. الحسابات المصرفية: يجب أن يحتفظ كل من الدائن والمدين بحسابات مصرفية لدى مؤسسات مالية منضوية في شبكة SWIFT.
2. الاتفاق والتفويض: يجب أن يكون هناك اتفاق وتفويض مسبقان بين الدائن والمدين لإتاحة تنفيذ معاملات الخصم المباشر.
3. صيغ رسائل SWIFT: يجب على الدائن ومصرفه استخدام صيغ الرسائل المناسبة: pain.008 لبدء الخصم المباشر، وpacs.003 أو pacs.010 بين المصارف.
4. رسوم المصارف: ينبغي للدائن والمدين الاطلاع على أي رسوم مرتبطة بمعاملات الخصم المباشر ضمن نظام SWIFT، إذ قد تتفاوت هذه الرسوم بحسب المصارف والدول المعنية.

إدارة علاقات المراسلة (RMA) في رسائل SWIFT بين المصارف

في القطاع المصرفي والمالي، يُعدّ التواصل الآمن والفعّال بين المصارف أمرًا أساسيًا. وهنا يؤدي نظام SWIFT (جمعية الاتصالات المالية بين المصارف على المستوى العالمي) دورًا حاسمًا، إذ ينقل غالبية الرسائل الدولية بين المصارف. ومن العناصر الجوهرية التي تضمن أمن هذه الاتصالات وانتقائيتها تطبيق إدارة العلاقات (RMA).

ما هي RMA؟

تطبيق إدارة العلاقات (Relationship Management Application – RMA) هو تطبيق برمجي من SWIFT يتيح للمؤسسات المالية تحديد الأطراف المقابلة المسموح لها بإرسال رسائل SWIFT إليها، ويضمن حصر الاتصال عبر شبكة SWIFT بالمستخدمين الموثَّقين فقط. ويُعدّ RMA طبقة أمنية أساسية في إدارة الاتصالات بين المصارف، إذ يستبعد الرسائل غير المصرّح بها ويقلل مخاطر الاحتيال.

أهمية RMA

بالنسبة إلى المصارف العاملة في التمويل الدولي، مثل IFB، تُعد أداة RMA لا غنى عنها. فهي لا تعزز بروتوكولات الأمن فحسب، بل تضمن أيضاً الامتثال للأنظمة المصرفية العالمية. ومن خلال إدارة المؤسسات المخوّلة بإرسال الرسائل إليها، تستطيع المصارف منع طلبات المعلومات والتعليمات المالية غير المصرّح بها، وبذلك تحمي مصالحها ومصالح عملائها.

كيف تعمل RMA

تتضمن عملية RMA عدة خطوات رئيسية:

1. إنشاء علاقات RMA: قبل أن يتمكن مصرفان من تبادل المعلومات عبر SWIFT، يجب أن يتفقا بصورة متبادلة على إنشاء علاقة RMA. وهذا الاتفاق أشبه بمصافحة رقمية، تدل على الثقة والموافقة على التواصل.
2. تبادل المفاتيح: يرسل كل مصرف تفويض RMA عبر تطبيق RMA، ويقبله المصرف المقابل. وقد حلّ RMA محل التبادل الثنائي للمفاتيح (BKE) السابق؛ أما الرسائل نفسها فتتم مصادقتها عبر SWIFTNet PKI (البنية التحتية للمفاتيح العمومية).
3. ضبط إعدادات RMA: يستخدم كل مصرف أداة RMA لضبط الصلاحيات وتحديد أنواع الرسائل المقبولة من المصرف الآخر. ويمكن أن يتم ذلك على نحو عام أو بدقة أكبر لتشمل أنواعًا محددة من الرسائل وفئاتها الفرعية.
4. التفعيل والمراقبة: بمجرد تهيئة إعدادات RMA وتفعيلها، يمكن للمصارف مراقبة الرسائل الواردة للتحقق من امتثالها للأذونات المقررة. كما توفر RMA أدوات لتعديل الأذونات أو إلغائها إذا اقتضت ذلك احتياجات العمل أو الاعتبارات الأمنية.

التطبيقات العملية

بالنسبة إلى IFB، المتخصص في الاستثمار وإدارة الثروات للأفراد ذوي الملاءة المالية العالية والكيانات المؤسسية، توفر RMA عدة مزايا:

• أمن معزَّز: من خلال التحكم في حركة الرسائل، يستطيع IFB حماية معاملات العملاء والمعلومات الحساسة من الوصول غير المصرّح به.
• الكفاءة التشغيلية: تتيح المراسلات المبسّطة مع الجهات الموثوقة معالجة أسرع للرسائل المشروعة، مما يحسّن أزمنة الاستجابة ورضا العملاء.
• الامتثال التنظيمي: تساعد RMA على الامتثال للأنظمة المصرفية الدولية التي تفرض رقابة صارمة على تبادل المعلومات لمنع الجرائم المالية، مثل غسل الأموال والاحتيال.

RMA وMT799. يجوز للمصارف استخدام رسالة MT799 لطلب علاقة RMA أو تنسيقها، شريطة أن تتيح القناة ذلك. ويُمنح تفويض RMA ذاته في نظام RMA؛ ولا تؤدي رسالة MT799 وحدها إلى تفعيل أي إذن. وحيثما يغيب تفويض RMA اللازم لرسائل MT799، فلا يمكن تجاوزه بإرسال رسالة MT799 مباشرةً. ويُتفق عندئذٍ على الإعداد عبر خاصية التواصل الخاصة بـ RMA في بوابة إدارة العلاقات التابعة لـ Swift، المصممة للتنسيق مع الأطراف المقابلة قبل تبادل التفويضات، أو عبر قناة أخرى مسموح بها. ومن ثم قد يصف مصطلح «RMA عبر MT799» المراسلات المصرفية المصاحبة؛ أما تفويض RMA الفني فهو خطوة مستقلة.

باختصار

بالنسبة إلى IFB، لا يُعدّ التطبيق الفعّال لـ RMA مجرد متطلب تقني، بل أصلًا استراتيجيًا في عملياتها العالمية. فهو يعزز التزام المصرف بالأمن والامتثال التنظيمي، ويرفع في الوقت نفسه كفاءة شبكات اتصالاته. ومع استمرار تطور بيئة التمويل الدولي، تظل أدوات مثل RMA عنصرًا أساسيًا في ترسانة المصارف الملتزمة بأعلى معايير النزاهة التشغيلية وخدمة العملاء.

تشكّل تفويضات تطبيق إدارة العلاقات (RMA) العمود الفقري للتواصل الآمن والانتقائي بين المصارف، إذ تضمن التزام كل رسالة تُتبادل عبر شبكة SWIFT بأعلى معايير الأمان والتحقق الكامل من أصالتها. وبالنسبة إلى المصارف مثل IFB، يُعدّ فهم هذه التفويضات وإدارتها أمرًا بالغ الأهمية لحماية عملياتها وبناء الثقة مع شركائها حول العالم.

تعليمات مالية رقمية عبر السلسلة الكتلية من Swift

في سبتمبر 2025 أعلنت Swift أنها بدأت، بالتعاون مع أكثر من 30 مؤسسة مالية، تصميم دفتر أستاذ رقمي مشترك وتطويره. وفي 9 يوليو 2026 أعلنت Swift جاهزية الدفتر للاستخدام الأولي، مع استعداد 17 مصرفًا لإجراء تجارب حية لمعاملات الودائع المرمّزة: ANZ وBNP Paribas وBNY وCiti وDBS وبنك أبوظبي الأول وFirstRand وHSBC وItaú Unibanco وLloyds وبنك المشرق وMUFG وOCBC وStandard Chartered وUBS وUOB وWells Fargo. وسيركز التطبيق الأول على تمكين تعليمات فورية عبر الحدود على مدار الساعة طوال أيام الأسبوع بين المصارف، وهو تحسين جوهري في منظومة معالجة المعاملات الدولية.

جرى بناء النموذج الأولي المفاهيمي الأول بالتعاون مع Consensys. وقد صُمِّم السجل بوصفه سجلاً آمناً وغير قابل للتغيير وفورياً للتعليمات المالية بين المؤسسات. وسيقوم بتسجيل رسائل المعاملات وتسلسلها والتحقق منها، مع إنفاذ القواعد التشغيلية وقواعد الامتثال عبر العقود الذكية. ويُعدّ التشغيل البيني مبدأً محورياً: إذ سيرتبط السجل بالبنى التحتية القائمة والناشئة على حدّ سواء، مع الحفاظ على ما يميّز Swift من مرونة وثقة والتزام تنظيمي.

وكما أوضح خافيير بيريز-تاسو، الرئيس التنفيذي لشركة Swift:
«إن الجمع بين دفتر أستاذ مشترك ونظام المراسلة وواجهات برمجة التطبيقات ومعيار ISO 20022 القائمة لدى Swift يُنتج بنية أكثر قوة، بنية تدمج منذ البداية متطلبات المخاطر والضوابط والامتثال في مسارات المعاملات، مع إتاحة تعليمات فورية بين المصارف عبر الحدود على مدار الساعة طوال أيام الأسبوع، بالقدر نفسه من الثقة والأمان والمرونة وقابلية التوسع والتميز التشغيلي المعروفة عن Swift. وكل ذلك وفق النهج الذي اتبعناه دائمًا في الابتكار المسؤول.»

توسيع البنية التحتية

يكمّل السجل المشترك قنوات Swift القائمة ولا يحل محلها. وقد صُمّم لتوسيع نطاق التنسيق والتشغيل البيني، بما يضمن قدرة المؤسسات المالية على تبادل التعليمات بسرعة أكبر وبقدر أعلى من إمكانية التنبؤ وعلى نطاق عالمي حقيقي.

في مؤتمر Sibos، أكد بيريز-تاسو هذا النهج المزدوج المسار:
"يتعين على البنى التحتية المالية أن تحافظ على تركيز دؤوب على أساسيات التميز التشغيلي والامتثال التنظيمي والحوكمة. وفي الوقت نفسه، عليها أن تستعد للمستقبل. وفي Swift، يقوم نهجنا على الابتكار عبر مسارين متوازيين."

التعاون على مستوى القطاع

شاركت مؤسسات مالية من 16 دولة منذ البداية في صياغة تصميم السجل المشترك وحوكمته ومسار تطويره. ويؤكد هذا الجهد الجماعي إدراكاً مشتركاً مفاده أن النهوض بالبنية التحتية العالمية للتعليمات بين المصارف يتطلب حجماً وتعاوناً.

نظرة إلى المستقبل

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

لخّص بيريز-تاسو الرؤية قائلاً:
«هذه منصة قوية للمستقبل. ويمكن أن تكون أكثر قدرة على إحداث التحوّل في المستقبل.»

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

ما هو دفتر الأستاذ المشترك من Swift القائم على تقنية البلوكتشين؟
بنية تحتية قائمة على تقنية البلوكتشين توفر سجلاً مشتركاً وفورياً للتعليمات المالية بين المؤسسات، بما يتيح معالجة مستمرة ومتوافقة مع المتطلبات التنظيمية عبر الحدود.

لمن هو موجّه؟
المصارف والمؤسسات المالية التي يتعين عليها تقديم تعليمات معاملات أسرع وأكثر شفافية، مع الاستعداد للمستقبل الرقمي.

ما هي المزايا؟

• رؤية فورية للتعليمات وتسلسلها الزمني
• الامتثال الآلي عبر العقود الذكية
• قابلية التشغيل البيني عبر الشبكات التقليدية والرقمية
• المعالجة الآمنة لتدفقات القيمة المرمَّزة الخاضعة للتنظيم

كيف يتكامل ذلك مع منصة Swift؟
إنه يوسّع البنية التحتية الموثوقة لـ Swift، إذ يدمج قدرات التعليمات الرقمية مع الحفاظ على المرونة والأمن والامتثال.

ما هي حالة الاستخدام الأولى؟
تعليمات المعاملات بين المصارف عبر الحدود في الوقت الفعلي على مدار الساعة طوال أيام الأسبوع.

من المشاركون؟
أسهمت أكثر من 30 مؤسسة مالية من 16 دولة في صياغة التصميم؛ ويُجري 17 مصرفًا تجارب تشغيلية على أولى المعاملات الفعلية.

متى سيكون متاحاً؟
أعلنت Swift أن السجل جاهز للاستخدام الأولي في 9 يوليو 2026. وتُجري المصارف التجريبية معاملات فعلية أولية ضمن مرحلة تشغيل خاضعة للرقابة؛ وتظل التسوية النهائية تتم عبر الأنظمة القائمة. ومن المقرر توسيع الوظائف والإتاحة لاحقاً.

إذا كنتم ترغبون في معرفة المزيد حول كيفية تحويل الأموال عبر نظام الخدمات المصرفية للمراسلين، يُرجى التواصل مع رئيس الخدمات المصرفية للمراسلين لدينا، السيد Amri Elarisse