تحويلات IP/IP وIPZip

من بروتوكول الإنترنت إلى بروتوكول الإنترنت (IPIP)

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

غير أنه من المهم الإشارة إلى أن التحويلات من عنوان IP إلى عنوان IP ليست شائعة ولا موصى بها في القطاع المصرفي لأسباب عدة، منها المخاوف المتعلقة بالأمن والموثوقية والامتثال. وتوضح النقاط التالية سياق هذه المخاوف:

1. الأمن: قد تكون التحويلات من عنوان IP إلى عنوان IP أقل أمانًا مقارنة بالشبكات المصرفية الراسخة، مثل SWIFT أو ACH، التي تطبّق طبقات متعددة من الأمن والتشفير والمصادقة. وقد يعرّض الاتصال المباشر بين عنواني IP المعلومات الحساسة لتهديدات أمنية محتملة، منها الاختراق والتصيّد الاحتيالي وهجمات الوسيط.
2. الموثوقية: إن استخدام التحويلات من عنوان IP إلى عنوان IP لا يضمن موثوقية المعاملة، إذ لا توجد معايير أو بروتوكولات معترف بها عالميًا للتحويلات القائمة على عناوين IP في القطاع المصرفي. وقد يؤدي ذلك إلى مشكلات محتملة في معالجة المعاملات وتتبعها ومطابقتها.
3. الامتثال: تخضع المصارف والمؤسسات المالية للعديد من الأنظمة والمتطلبات، بما فيها سياسات مكافحة غسل الأموال (AML) واعرف عميلك (KYC). وقد لا تلتزم التحويلات من عنوان IP إلى عنوان IP بهذه المتطلبات التنظيمية، مما قد يعرّض الأطراف المعنية لمخاطر قانونية ومالية.

وبدلاً من التحويلات من عنوان IP إلى عنوان IP، تفضّل المصارف والمؤسسات المالية استخدام شبكات راسخة، مثل SWIFT أو RTGS أو ACH/المدفوعات الفورية، ومعايير المراسلة مثل ISO 20022 لتيسير تحويلات الأموال الآمنة والموثوقة والمتوافقة مع الأنظمة بين المؤسسات المختلفة.

الفروق الرئيسية بين خوادم الاتصالات وخوادم دفتر الأستاذ/الحسابات في المصارف

في التكنولوجيا المصرفية، تؤدي الخوادم دورًا حاسمًا في ضمان سلاسة تنفيذ المعاملات المالية وحفظ السجلات. وتعتمد المصارف على نوعين رئيسيين من الخوادم، هما خوادم الاتصالات وخوادم دفتر الأستاذ/الحسابات. وعلى الرغم من أن كليهما بالغ الأهمية، فإن لكلٍّ منهما غرضًا مختلفًا ويتعامل مع أنواع مختلفة من البيانات.

خوادم الاتصالات

تشكل خوادم الاتصالات العمود الفقري لتبادل البيانات الآمن بين المصارف والمؤسسات المالية. وفيما يلي أبرز وظائف خوادم الاتصالات وخصائصها:

1. تبادل آمن للبيانات: تيسّر هذه الخوادم تبادل البيانات بصورة آمنة، بما يضمن إمكانية نقل المعلومات المالية الحساسة بين المؤسسات دون المساس بسلامتها.
2. البروتوكولات والمعايير: تعتمد على بروتوكولات قياسية مثل SWIFT وSEPA وACH وغيرها للتواصل بين المصارف، بما يضمن الاتساق والموثوقية عبر مختلف المنصات.
3. التشفير والمصادقة: حفاظًا على الأمان، تعتمد خوادم الاتصال أساليب تشفير متقدمة وبروتوكولات مصادقة صارمة تحمي البيانات أثناء نقلها.
4. معالجة المعاملات: تتولى هذه الأنظمة في المقام الأول معالجة طلبات المعاملات والرسائل والتعليمات، وتعمل وسيطًا ينقل المعلومات اللازمة لتنفيذ المعاملات.
5. لا تحريك للأموال: من المهم الإشارة إلى أن هذه الخوادم لا تنقل الأموال ولا تحدّث أرصدة الحسابات بصورة مباشرة؛ بل تقتصر على تيسير الاتصالات اللازمة لتنفيذ هذه الإجراءات.

خوادم دفتر الأستاذ/الحسابات

أما خوادم دفتر الأستاذ والحسابات فهي الجهة الحافظة للسجلات المالية للمصرف. وفيما يلي أبرز خصائصها:

1. الاحتفاظ بالسجلات المالية: تخزّن هذه الخوادم السجلات المالية الأساسية للمصرف وتحتفظ بها، بما يضمن تسجيل كل معاملة بدقة.
2. تسجيل المعاملات: تتولى تسجيل جميع المعاملات، بما فيها القيود المدينة والدائنة، وهي مسؤولة عن تحديث الأرصدة الحالية للحسابات وحفظها.
3. إدارة دفتر الأستاذ العام: تتولى خوادم دفتر الأستاذ إدارة دفتر الأستاذ العام للمصرف إلى جانب حسابات العملاء الفردية، مما يتيح رؤية شاملة للوضع المالي.
4. سلامة البيانات: يُعدّ ضمان اتساق البيانات وسلامتها أمراً أساسياً، إذ إن هذه السجلات ضرورية لدقة التقارير المالية والامتثال.
5. تدابير أمنية قوية: نظرًا إلى حساسية البيانات، تعتمد خوادم الدفاتر عادةً تدابير أمنية أشد صرامة، تشمل طبقات إضافية من التشفير وضوابط وصول مشددة.

يبدأ خادم الاتصالات المعاملات ويُيسّرها، أما خادم دفتر الأستاذ فيسجّلها في نهاية المطاف ويعكسها في دفاتر المصرف بعد التحقق منها.

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

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

وبوجه عام، فإن البروتوكولات وإن كانت أساسية لتبادل المعلومات بصورة آمنة وفعالة في معاملات IPIP، فإن العملية المتكاملة تشمل أنظمة إضافية لنقل العملات والأصول والالتزامات وحقوق الملكية فعلياً، وتسويتها، وتسجيلها قانونياً، وإعداد التقارير المالية بشأنها، بما يضمن تنفيذ المعاملة بأكملها وفق المعايير المصرفية التنظيمية.

تحويل IP ZIP

الإرسال الآمن القائم على الملفات لتعليمات الدفع المؤسسية

يُفهم التحويل عبر IP ZIP على أفضل وجه بوصفه وسيلة آمنة قائمة على الملفات لنقل تعليمات الدفع المهيكلة وبيانات المعاملات المرتبطة بها مباشرةً بين أنظمة مؤسسية موثَّقة الهوية عبر شبكة بروتوكول الإنترنت.

تتطلب المصطلحات دقة خاصة.

إن عملية الإرسال عبر IP ZIP ليست نظام مقاصة ولا نظام تسوية ولا قناة دفع ولا آلية مستقلة لتحويل القيمة النقدية. فأرشيف ZIP ليس سوى حاوية نقل. والاتصال عبر IP هو قناة الاتصال. أما المعلومات الواردة في الأرشيف فتشكّل تعليمات أو مجموعة بيانات أو رسالة معاملة.

وبناءً على ذلك:

تنقل IP ZIP معلومات الدفع وتعليماته، ولا تقوم بذاتها بتسوية الأموال.

من الناحية المفاهيمية، يشبه ذلك التمييز المنطبق على رسالة ISO 20022 pacs.008 (تحويل ائتماني للعملاء بين المؤسسات المالية). فقد تتضمن رسالة pacs.008 تعليمات عالية الهيكلة لتحويل ائتماني بين المصارف، غير أنه لا يجوز الخلط بين الرسالة نفسها وبين الحركة النهائية لأموال المصرف المركزي أو أموال المصارف التجارية أو أرصدة حسابات المراسلين وتسويتها.

ينطبق المبدأ نفسه على إرسال ملف مضغوط بصيغة ZIP عبر IP.

2. ملف ZIP بوصفه حاوية آمنة للمعاملات

يعمل مكوّن ZIP بصورة أساسية بوصفه آلية للحَوْسَبة في حاويات وتجميع الملفات وحزمها.

بدلًا من إرسال مكوّنات المعاملة كلٌّ على حدة، يجوز للمؤسسة المُنشِئة تجميع الملفات ذات الصلة في حزمة واحدة خاضعة للرقابة.

وبحسب المواصفات الثنائية المتفق عليها، قد تتضمن هذه الحزمة ما يلي:

• تعليمات الدفع المهيكلة؛
• رسائل الدفع بصيغة XML؛
• مجموعات بيانات متوافقة مع ISO 20022؛
• كائنات المعاملات بصيغة JSON؛
• سجلات المعاملات بصيغة CSV أو بصيغة ثابتة التنسيق؛
• ملفات المدفوعات بين المصارف ذات الصيغ الخاصة بالمؤسسة؛
• معلومات المدين والدائن؛
• معلومات حساب المُنشئ والمستفيد؛
• معرّفات المعاملات؛
• معلومات العملة والمبلغ؛
• تواريخ التنفيذ وتواريخ القيمة المطلوبة؛
• تعليمات المصرف المراسل؛
• معلومات المصرف الوسيط؛
• معلومات التحويل؛
• معلومات توجيه التسوية؛
• وثائق الامتثال؛
• مراجع KYC أو KYB؛
• معلومات مصدر الأموال؛
• بيانات المعاملات (manifests)؛
• التوقيعات الرقمية؛
• دوال التجزئة التشفيرية؛
• الشهادات؛
• الأختام الزمنية؛
• ملفات المطابقة؛ و
• إجماليات المراقبة.

وعليه، قد يتضمن الأرشيف كلًّا من تعليمات الدفع الأساسية والمعلومات المساندة اللازمة للتحقق من صحة تلك التعليمات وتوثيقها ومعالجتها وتسويتها.

الضغط أمر عرضي من الناحية التقنية. أما الغرض الرئيسي فهو التعبئة المنضبطة والإرسال.

ومن ثمّ لا ينبغي اعتبار أرشيف ZIP دليلًا على أن الأموال المشار إليها في الأرشيف موجودة أو متاحة أو غير مرهونة أو قد جرت تسويتها.

3. تعليمات الدفع المهيكلة

إذا صُمِّمت على النحو الملائم، فقد تؤدي تعليمات الدفع الواردة ضمن حزمة IP ZIP وظيفة مماثلة لوظيفة الرسائل المالية المهيكلة التقليدية.

فعلى سبيل المثال، يمكن لمؤسسة أن ترسل تعليمات بصيغة XML تتضمن حقولًا تقابل المعلومات التي ترد عادةً في رسالة ISO 20022 pacs.008، بما في ذلك:

• معرّف الرسالة؛
• تاريخ الإنشاء ووقته؛
• عدد المعاملات؛
• معلومات التسوية؛
• الوكيل المُصدِر للتعليمات؛
• الوكيل المُكلَّف بالتنفيذ؛
• المدين؛
• حساب المدين؛
• وكيل المدين؛
• وكيل الدائن؛
• الدائن؛
• حساب الدائن؛
• المبلغ المحدد في التعليمات؛
• العملة؛
• الطرف المتحمل للرسوم؛
• تحديد هوية الدفعة؛
• التعريف من طرف إلى طرف؛ و
• معلومات التحويل.

والفارق الجوهري هو أن بنية البيانات لا تحدد آلية التسوية.

يمكن أن يستلم النظام المستقبِل تعليمات دفع سليمة من الناحية الفنية، وأن يوثّقها ويقبلها، في حين تبقى التسوية المالية المقابلة معلّقة.

وبالتالي:

استلام التعليمات ≠ استلام الأموال

توثيق التعليمات ≠ تسوية الأموال

نجاح استيراد الملف ≠ قيد الأموال النهائية في حساب المستفيد

إقرار الخادم بالاستلام ≠ تأكيد التسوية

ويُعدّ هذا التمييز أساسياً في تعامل IFB مع منهجيات التحويل البديلة.

4. بروتوكولات الإرسال

ينبغي أن تتم عمليات إرسال ملفات IP ZIP المؤسسية حصرًا ضمن بيئة اتصالات خاضعة للرقابة وموثّقة.

بحسب الترتيب التقني الثنائي، قد يتم الإرسال باستخدام تقنيات من قبيل:

SFTP

يوفر بروتوكول نقل الملفات الآمن عبر SSH نقلًا مشفرًا ومصادقة للخادم ومصادقة مضبوطة للمستخدمين.

ينبغي عادةً تفضيل المصادقة بالمفتاح العام على المصادقة بكلمة المرور وحدها في الاتصال المؤسسي.

FTPS

يجوز حماية FTP عبر TLS حيثما تتطلب البنية التحتية القديمة ذلك، شريطة تطبيق التحقق المناسب من الشهادات ومعايير التشفير وضوابط الوصول.

HTTPS / REST API

يجوز إرسال الحزمة عبر نقطة اتصال HTTPS موثّقة أو بنية API باستخدام TLS وآليات مصادقة مناسبة على مستوى التطبيق.

بروتوكول TLS المتبادل

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

ويوفّر ذلك حماية أقوى بكثير ضد نقاط الاتصال غير المصرّح بها مقارنة بمصادقة الخادم من طرف واحد وحدها.

VPN

يمكن إنشاء شبكة افتراضية خاصة (VPN) من نوع IPSec بين المواقع، أو ما يعادلها، لتكوين نفق خاص مشفَّر بين المؤسسات المشاركة قبل إجراء الإرسال على مستوى التطبيق.

اتصال خاص مخصَّص

حيثما تبرر أحجام المعاملات أو متطلبات الأمن أو الملامح المخاطرية للمؤسسات ذلك، يجوز أن تُستكمل عملية الإرسال عبر شبكة الإنترنت العامة بربط شبكي مخصص أو خاص، أو أن يحل محلها.

يجب الاتفاق على البروتوكول الدقيق ثنائيًا قبل التفعيل التشغيلي.

5. مصادقة نقطة النهاية

يجب على المؤسسة المتلقية أن تتحقق من أن الرسالة المرسلة صادرة فعلًا عن المؤسسة التي يُزعم أنها تمثلها.

وقد تشمل الضوابط ذات الصلة ما يلي:

• الشهادات الرقمية المؤسسية؛
• أزواج مفاتيح SSH العامة والخاصة؛
• شهادات TLS المتبادلة؛
• بيانات اعتماد واجهة البرمجة (API)؛
• إدراج عناوين IP في قائمة السماح؛
• المصادقة عبر الشبكة الافتراضية الخاصة (VPN)؛
• وحدات الأمان المادية (HSM)؛
• تثبيت الشهادات عند الاقتضاء؛
• مصادقة إدارية متعددة العوامل؛
• حسابات خدمة خاضعة للرقابة؛
• ضوابط الوصول القائمة على الأدوار؛ و
• الفصل بين بيئات الإنتاج وبيئات الاختبار.

لا يُعدّ عنوان IP وحده دليلاً كافياً على هوية المؤسسة.

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

6. التشفير

ينبغي عادةً إرساء السرية على أكثر من مستوى واحد.

تشفير النقل

ينبغي تشفير قناة الاتصال باستخدام بروتوكول حديث مهيأ على النحو الملائم، مثل TLS أو SSH.

وهذا يحمي المعلومات أثناء النقل.

تشفير حمولة الرسالة

وحيثما اقتضى الأمر، يجوز كذلك تشفير حزمة المعاملة نفسها.

ويوفّر ذلك حماية للمعلومات المالية بمعزل عن قناة النقل، ويمكن أن يخفّض بصورة ملموسة التعرّض للمخاطر في الحالات التي تُخزَّن فيها الملفات مؤقتاً أو تمرّ عبر بنية تحتية وسيطة أو تُؤرشَف أو تُعالَج بصورة غير متزامنة.

التشفير أثناء التخزين

ينبغي حماية الملفات التي تنتظر المعالجة داخل بيئات تخزين خاضعة للرقابة، مع ضوابط وصول مناسبة وتشفير للبيانات المخزّنة.

غير أن التشفير يحقق السرية، لكنه لا يثبت صحة المعاملة من الناحية المالية.

7. سلامة التشفير

ويجب أن تكون المؤسسة المستقبِلة قادرة أيضًا على تحديد ما إذا كانت الحزمة المرسلة قد جرى تعديلها بعد إنشائها.

ومن ثمّ يمكن إنشاء قيمة تجزئة تشفيرية (hash) للحزمة أو للملفات المكوّنة لها.

على سبيل المثال:

حزمة المعاملة الأصلية
← توليد تجزئة تشفيرية (hash)
← إرسال الحزمة
← يحتسب النظام المستقبِل التجزئة بصورة مستقلة
← مقارنة التجزئة المحتسبة بالتجزئة المرسلة أو الموقّعة

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

يجوز استخدام خوارزميات التجزئة التشفيرية الحديثة، مثل الخوارزميات المنتمية إلى عائلتي SHA-2 أو SHA-3 بحسب ما يناسب التنفيذ، للتحقق من سلامة البيانات.

8. التوقيعات الرقمية

يؤدي التوقيع الرقمي وظيفة تختلف اختلافًا جوهريًا عن وظيفة التشفير.

يحمي التشفير السرية.

تساعد التجزئة التشفيرية (الهاشينغ) في ترسيخ سلامة البيانات.

يمكن للتوقيع الرقمي المنفَّذ على النحو الصحيح أن يساعد في إثبات ما يلي:

1. الأصالة - جرى توقيع الحزمة باستخدام المفتاح الخاص ذي الصلة؛
2. السلامة - أي أن البيانات الموقَّعة لم تتعرض لأي تغيير لاحق؛ و
3. المساءلة - يمكن ربط التوقيع ببيانات الاعتماد المؤسسية ذات الصلة، وذلك رهنًا بإطار البنية التحتية للمفتاح العام (PKI) والحوكمة المعمول به.

ينبغي للمؤسسة المستلِمة التحقق من التوقيع بمطابقته مع الشهادة الموثوقة أو المفتاح العام المقابل قبل دخول تعليمات المعاملة في مرحلة معالجة المدفوعات.

ينبغي حماية مفاتيح التوقيع الخاصة بالشكل المناسب، ويُفضَّل ذلك من خلال بنية مؤسسية لإدارة المفاتيح، ومن خلال وحدات الأمان المادية (Hardware Security Modules) عند الاقتضاء.

9. الحماية من إعادة الإرسال والتكرار

يتطلب إرسال الملفات المالية ضوابط تحول دون تقديم التعليمات الصحيحة نفسها مرارًا.

ومن ثمّ ينبغي أن تتضمن البنية المصممة على نحو ملائم معرّفات فريدة للمعاملات وضوابط مناسبة، مثل:

• معرّفات فريدة للرسائل؛
• معرّفات معاملات فريدة؛
• الأختام الزمنية؛
• أرقام التسلسل؛
• معرّفات الملفات؛
• اكتشاف الرسائل المكررة؛
• ضوابط عدم التكرار (idempotency)؛
• سجلات حالة المعالجة؛ و
• المطابقة مع التعليمات التي سبقت معالجتها.

ينبغي للمؤسسة المستلمة رفض التعليمات المكررة أو عزلها أو التحقيق فيها وفق إجراء التشغيل المتفق عليه.

10. التحقق من الملفات

ينبغي أن يؤدي الاستلام الناجح للملف إلى بدء التحقق منه، لا إلى التسوية التلقائية.

قد تُخضع بيئة المعالجة الآمنة الطرد لعدة ضوابط متتالية:

المرحلة 1 – التحقق من النقل

تأكيد وصول الطرد عبر قناة معتمدة.

المرحلة 2 – مصادقة نقطة الاتصال

التأكد من هوية النظام المُرسِل وبيانات الاعتماد المؤسسية.

المرحلة 3 – ضوابط البرمجيات الخبيثة وأمن الملفات

فحص الأرشيف والملفات المكوّنة له قبل إدخاله إلى البنية التحتية للمدفوعات.

المرحلة 4 – التحقق التشفيري

التحقق من قيم التجزئة والتوقيعات والشهادات.

المرحلة 5 – التحقق الهيكلي

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

المرحلة 6 – التحقق الدلالي

التأكد من وجود الحقول الإلزامية للدفع واتساقها داخليًا.

المرحلة 7 – التحقق من المعاملة

التحقق من العملة والمبلغ والحسابات ومعلومات التوجيه ومراجع المعاملة وتعليمات التسوية.

المرحلة 8 – التحقق من الامتثال

ضوابط مكافحة غسل الأموال والعقوبات، وإجراءات KYC/KYB، ومراقبة المعاملات، وغيرها من الضوابط المعمول بها.

المرحلة 9 – التحقق من التسوية

تأكيد على وجود آلية فعلية يمكن من خلالها تسوية القيمة المالية المقابلة.

لا ينبغي المضي في تنفيذ التعليمات إلا بعد استكمال هذه الضوابط، وفقاً للإجراءات المعمول بها لدى المؤسسة المتلقية.

11. الإقرار بالاستلام لا يعني التسوية

قد تُنتج بيئة IP ZIP عدة إقرارات تقنية بالاستلام.

على سبيل المثال:

ACK – تم استلام الملف

ولا يثبت ذلك سوى أن نقطة الاستقبال قد تسلّمت الحزمة.

ACK – تم توثيق الملف

وهذا يثبت أن ضوابط المصادقة قد اكتملت بنجاح.

ACK – تم التحقق من صحة الملف

ويثبت ذلك أن الحزمة استوفت التحقق الهيكلي أو التقني المعمول به.

ACK – تم قبول التعليمات

وقد يثبت ذلك أن تعليمات الدفع قد دخلت في سير عمل المعالجة لدى المؤسسة المستلِمة.

لا تعني أي من هذه الحالات بالضرورة:

تمت التسوية

تتطلب التسوية حدثًا ماليًا مستقلًا.

ويشبه هذا التمييز ما هو معمول به في المراسلات المالية التقليدية، حيث يجب التفريق بين نجاح تسليم رسالة الدفع وقبولها وبين التسوية النهائية للالتزام النقدي الأساسي.

12. تسوية المعاملة الأساسية

بعد توثيق تعليمة الدفع عبر IP ZIP والتحقق منها وقبولها واعتمادها، يجب تسوية القيمة النقدية الكامنة عبر بنية مالية تحتية مناسبة.

بحسب العملات والمؤسسات والاختصاصات القضائية المعنية، قد تتم التسوية عبر:

• الخدمات المصرفية للمراسلين؛
• حسابات نوسترو/فوسترو؛
• حسابات البنك المركزي؛
• بنية التسوية الإجمالية الفورية (RTGS) التحتية؛
• أنظمة المقاصة المعترف بها؛
• أنظمة الدفع المحلية؛
• البنى التحتية للمدفوعات الفورية؛
• مصارف التسوية المراسلة؛ أو
• ترتيب تسوية آخر معترف به قانونياً وتشغيلياً.

14. مبدأ الأمن

يطبّق IFB تمييزًا جوهريًا على جميع منهجيات التحويل البديلة:

يثبت الإرسال الآمن أنه يمكن نقل البيانات بصورة آمنة. ولا يثبت أنه يمكن تسوية الأموال.

• التشفير لا يثبت وجود الأموال.
• التوقيع الرقمي لا يثبت وجود الأموال.
• رصيد الخادم لا يُثبت وجود الأموال.
• ملف المعاملات لا يثبت وجود الأموال.
• نجاح استيعاب الملف لا يثبت وجود الأموال.
• الإقرار التقني لا يثبت التسوية.

ويبقى السؤال المالي الحاسم: هل تحقّقت المؤسسة المنشِئة من توافر سيولة مؤكدة ومسار تسوية تشغيلي قادر على تحويل القيمة النقدية المقابلة عبر البنية التحتية المصرفية المعترف بها.

15. إطار القبول لدى IFB

قد ينظر IFB في عمليات نقل ملفات IP ZIP لأطراف مقابلة مؤسسية معتمدة وعملاء مقبولين فقط، وذلك بعد مراجعة فنية وقانونية ومراجعة للامتثال تُرضي المصرف.

قبل إنشاء الربط في بيئة الإنتاج، قد تطلب IFB التحقق مما يلي:

• المؤسسة المنشئة؛
• السلطة المؤسسية اللازمة لإرسال المعاملة؛
• المالك المستفيد وأطراف المعاملة؛
• مصدر الأموال ومشروعيتها؛
• الغرض الاقتصادي الكامن؛
• البنية التحتية للإرسال والاستقبال؛
• ملكية نقطة النهاية؛
• بنية عناوين IP والشبكات؛
• منهجية المصادقة؛
• الشهادات وبيانات الاعتماد التشفيرية؛
• معايير التشفير؛
• صيغة الملف ومخططه؛
• بنية رسائل الدفع؛
• منهجية تحديد هوية المعاملات؛
• بروتوكول الإشعار بالاستلام؛
• ضوابط منع التكرار وإعادة الإرسال؛
• معالجة الاستثناءات؛
• إجراءات المطابقة؛
• علاقات المراسلة المصرفية؛
• حسابات التسوية؛
• ترتيبات السيولة؛ و
• مسار التسوية النهائية.

التوافق التقني وحده لا يكفي.

لن يعدّ IFB نجاح إرسال حزمة IP ZIP استلامًا للأموال. ولا تكتمل المعاملة ماليًا إلا عندما تتم تسوية القيمة المقابلة بنجاح عبر البنية التحتية المصرفية أو بنية التسوية المتفق عليها، ويمكن مطابقة التسوية بصورة مستقلة.

المبدأ الأساسي

إن IP ZIP هو الإرسال الآمن لتعليمات. أما التسوية فهي انتقال القيمة المالية المقابلة.

قد تشكّل العمليتان جزأين من سير العمل نفسه للمعاملة، لكنهما ليستا الحدث ذاته.

في المصطلحات المصرفية المؤسسية:

إرسال الرسالة ← المصادقة ← التحقق ← القبول ← التنفيذ ← التسوية ← المطابقة

ولا يثبت اكتمال الشق النقدي من المعاملة إلا باستكمال عملية التسوية المعمول بها.

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

أي تحويل، أيًّا كانت التسمية المستخدمة، لا بد أن تتم معالجته ومقاصته وتسويته في نهاية المطاف داخل النظام المالي القائم.

إذا رغبتم في معرفة المزيد عن كيفية تحويل الأموال أو الأصول إلى حساباتكم لدينا، يُرجى التواصل مع Marie Mayer.