> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # التحويلات الدولية: SWIFT والبنوك المراسلة - URL: https://arabroot.io/articles/التحويلات-الدولية-swift-والبنوك-المراسلة-وكم-يستغرق-التحويل/ - Published: 2026-10-27T17:18:36.000Z - Updated: 2026-10-27T18:18:07.000Z - Description: نتبع حوالة دولية عبر سلسلة البنوك المراسلة في نموذج بافتراضات مكتوبة، ونقرأ رسائل MT103 وpacs.008 ومثال تتبع gpi من Swift. - Author: فريق عرب رووت - Tags: الأدلة التقنية, التقنية المالية والمدفوعات لنفرض أن لديك شركة ناشئة تبني تطبيقاً للحجوزات، وتعاقدت مع استوديو تصميم في ماليزيا على واجهات التطبيق بعشرة آلاف دولار. وفي يوم الأحد صباحاً دخل المدير المالي على حساب الشركة في البنك، واختار «حوالة دولية»، وكتب رقم IBAN المستفيد ورمز البنك SWIFT، واختار من قائمة لا يفهمها خياراً اسمه SHA، ثم ضغط إرسال. والتحويل المحلي عبر نظام سريع كان يصل في ثوان، فتوقع أن يصل هذا خلال ساعات. وبعد يومين جاءت رسالة من الاستوديو: «وصلنا 9,967 دولاراً بدل 10,000، فأين الباقي؟ ومتى ستدفعون الفرق؟». وفي الشهر التالي أرسل الحوالة الثانية يوم الخميس بعد الظهر، فلم تصل إلا بعد أربعة أيام، ورد البنك على استفساره بأن «الحوالة في الطريق عند البنك المراسل». والسؤال الذي جلس المدير المالي مع مهندس الشركة ليفهمه: ما هو هذا الطريق؟ ولماذا تمر حوالة واحدة بأربعة بنوك؟ ومن أخذ الدولارات الثلاثة والثلاثين؟ ولماذا يهم يوم الإرسال؟ وهذا موضوع المقال: التحويلات الدولية Cross-Border Payments عبر شبكة SWIFT والبنوك المراسلة Correspondent Banks، والرسائل التي تحملها، وما الذي تغير مع خدمة التتبع gpi وانتقال الشبكة إلى ISO 20022، ولماذا ما زالت الحوالات الصغيرة والتحويلات العائلية Remittances مكلفة. ولن نكتفي بالشرح، وإنما سوف نبني في Python نموذجاً للسلسلة نفسها بافتراضات مكتوبة، ونقرأ رسائل MT103 حقيقية منشورة للاختبار ونحولها إلى pacs.008 ونتحقق منها بالمخطط الرسمي، ثم نقرأ مثال التتبع الذي نشرته Swift في مواصفة واجهتها. وقد شرحنا في [كيف تنتقل الأموال بين البنوك؟](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D9%86%D8%AA%D9%82%D9%84-%D8%A7%D9%84%D8%A7%D9%85%D9%88%D8%A7%D9%84-%D8%A8%D9%8A%D9%86-%D8%A7%D9%84%D8%A8%D9%86%D9%88%D9%83-%D8%A7%D9%84%D9%85%D9%82%D8%A7%D8%B5%D8%A9-%D9%88%D8%A7%D9%84%D8%AA%D8%B3%D9%88%D9%8A%D8%A9/) المقاصة والتسوية داخل بلد واحد، وفي [رسائل البنوك: ISO 8583 وISO 20022](https://arabroot.io/articles/%D8%B1%D8%B3%D8%A7%D8%A6%D9%84-%D8%A7%D9%84%D8%A8%D9%86%D9%88%D9%83-iso-8583-%D9%84%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A7%D8%AA-%D9%88-iso-20022-%D9%84%D9%84%D8%AA%D8%AD%D9%88%D9%8A%D9%84%D8%A7%D8%AA/) بنية رسائل ISO 20022، وهذا المقال يبني عليهما ولا يكررهما. وسوف نناقش ما يلي: - لماذا لا تنتقل الحوالة الدولية مباشرة، وما هي البنوك المراسلة وحسابات Nostro وVostro. - SWIFT نفسها: شبكة رسائل لا تنقل المال، ورموز BIC، والطريقة المتسلسلة وطريقة التغطية. - من يدفع الرسوم: OUR وSHA وBEN، وهامش الصرف، ولماذا الحوالة الصغيرة مكلفة. - مختبر النموذج: الرسوم والوقت عبر السلسلة، ولماذا يهم يوم الإرسال، وماذا يحدث إذا علقت الحوالة في الفحص. - الرسائل: قراءة MT103 منشورة للاختبار، وتحويلها إلى pacs.008 والتحقق منها، وما يضيع في التحويل. - gpi والمعرف UETR، والأرقام الرسمية لسرعة التحويلات وتكلفتها، وأهداف مجموعة العشرين. - ما يطلبه البنك المركزي السعودي في الحوالات والعلاقات المراسلة، وما يعنيه ذلك لمنتجك، وقائمة تحقق. ## لماذا لا تنتقل الحوالة مباشرة؟ داخل المملكة يملك كل بنك حساباً لدى البنك المركزي، فيسوي البنكان بينهما في SARIE أو عبر نظام سريع كما شرحنا في المقال السابق. أما بين بلدين فلا يوجد بنك مركزي واحد يملك فيه الجميع حسابات، والدولار الذي يصل إلى ماليزيا يجب أن يتحرك في النهاية في نظام الدولار، أي في دفاتر بنوك تملك حسابات في الولايات المتحدة. والحل الذي استقر عليه العالم منذ عقود هو العلاقات المراسلة Correspondent Banking: بنك يفتح حساباً لدى بنك آخر في بلد آخر، فيرسل ويستلم المدفوعات بعملة ذلك البلد من خلاله. وتعرف لجنة المدفوعات والبنى التحتية للأسواق CPMI في [تقريرها النهائي عن العلاقات المراسلة](https://www.bis.org/cpmi/publ/d147.htm?ref=arabroot.io) الصادر في 13 يوليو 2016 هذا النشاط وأنواع ترتيباته، وتوصي بإجراءات لتخفيف تكلفته ومخاوفه، منها خدمات معرفة العميل المشتركة KYC Utilities، ومعرف الكيان القانوني LEI، وتبادل المعلومات. وقبلها بسنة نشر مجلس الاستقرار المالي FSB [تقريراً لمجموعة العشرين عن تراجع العلاقات المراسلة](https://www.fsb.org/2015/11/report-to-the-g20-on-actions-taken-to-assess-and-address-the-decline-in-correspondent-banking/?ref=arabroot.io)، وهذا التراجع مهم لك لأن كل علاقة تنقطع تعني أن الحوالة إلى بلد ما تمر عبر بنك إضافي، أي رسوم ووقت إضافيين. ### حسابات Nostro وVostro لنأخذ مثالاً: البنك السعودي في القصة يملك حساباً بالدولار لدى بنك في نيويورك. هذا الحساب يسميه البنك السعودي «حسابنا لديهم» Nostro، ويسميه البنك الأمريكي «حسابكم لدينا» Vostro، وهو نفس الحساب من جهتين. فعندما يرسل البنك السعودي عشرة آلاف دولار، لا يخرج أي دولار من المملكة، وإنما يطلب من البنك الأمريكي أن يخصم من حساب Nostro ويضيف إلى حساب البنك الذي يليه في السلسلة. والصورة التالية تبين السلسلة التي سوف نبنيها في المختبر: ![من اليمين إلى اليسار: الشركة الناشئة تدفع بالريال، ثم بنكها في المملكة يحول إلى دولار ويرسل MT103 أو pacs.008، ثم البنك المراسل حيث حساب الدولار Nostro ويخصم رسوم USD 15، ثم البنك الوسيط حيث حساب دولار للمستفيد ويخصم USD 10، ثم بنك المستفيد يضيف للحساب ويخصم USD 8، ثم المورد يستلم الصافي، وتحتها أن كل بنك يحمل حساباً للبنك الذي قبله Vostro والذي قبله يراه حسابه هناك Nostro، وأن الرسالة تنتقل في دقائق والمال لا يتحرك إلا قيوداً في هذه الحسابات، وأن الرسوم افتراضات المختبر](https://arabroot.io/content/images/2026/10/cross-border-payments-01-chain.webp) أربعة بنوك، وكل منها دفتر وتوقيت ورسوم ولاحظ أن المال لا «ينتقل» بالمعنى الذي يتخيله المدير المالي، فكل ما يحدث قيود في دفاتر: البنك السعودي يخصم من الشركة بالريال، والبنك الأمريكي يخصم من حساب البنك السعودي بالدولار ويضيف لحساب البنك الوسيط، وهكذا حتى يضيف بنك المستفيد للاستوديو. وهذا يشبه تماماً ما شرحناه في [المحفظة الرقمية من الداخل](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%A8%D9%86%D9%8A-%D9%85%D8%AD%D9%81%D8%B8%D8%A9-%D8%B1%D9%82%D9%85%D9%8A%D8%A9-ledger/): كل حركة قيدان، ومجموع كل سلسلة صفر، والفرق الوحيد أن الدفاتر هنا في أربعة بنوك وأربع دول. ## SWIFT: شبكة رسائل لا تنقل المال أكثر خطأ شائع في فهم الحوالات الدولية أن SWIFT «تنقل المال». والصحيح أن SWIFT شبكة رسائل آمنة بين المؤسسات المالية، كل مؤسسة فيها لها رمز تعريف BIC من ثمانية أو أحد عشر حرفاً، مثل الرموز التي سوف تراها في المختبر. والرسالة تقول للبنك التالي: «أضف هذا المبلغ لهذا الحساب، واخصمه من حسابنا لديك»، أما الخصم والإضافة فيحدثان في دفاتر البنوك نفسها. ولهذا يعني «الحوالة عند البنك المراسل» أن الرسالة وصلت إليه، ولكنه لم ينفذها بعد، لأنه خارج ساعات عمله، أو ينتظر فحصاً، أو ينتظر رصيداً. والرسالة التقليدية لحوالة عميل هي MT103، وهي نص بحقول مرقمة مثل `:32A:` للتاريخ والعملة والمبلغ، و`:71A:` لمن يدفع الرسوم، و`:50K:` للمرسل و`:59:` للمستفيد، وحقول للبنوك في الطريق. وفي ISO 20022 تقابلها رسالة pacs.008 لتحويل العميل بين البنوك، وpacs.009 للتحويل بين البنوك أنفسهم. والانتقال من الأولى إلى الثانية يجري على شبكة SWIFT منذ سنوات، ويذكر [تقرير مجلس الاستقرار المالي لسنة 2025](https://www.fsb.org/2025/10/g20-roadmap-for-cross-border-payments-consolidated-progress-report-for-2025/?ref=arabroot.io) أن انتقال المستخدمين إلى ISO 20022 على شبكة Swift مستمر، وأن هناك أدلة على أن سرعة الدفع تتحسن بعد أن يكمل الطرفان الانتقال. ### الطريقة المتسلسلة وطريقة التغطية هناك طريقتان لنقل نفس الحوالة عبر المراسلين، والصورة التالية تبينهما: ![يميناً الطريقة المتسلسلة Serial: بنك المرسل يرسل MT103 للمراسل، والمراسل يرسل MT103 لبنك المستفيد، رسالة واحدة تمر بكل بنك ومعها بيانات العميلين، ويساراً طريقة التغطية Cover: بنك المرسل يرسل MT103 مباشرة لبنك المستفيد، وMT202 COV للمراسل ثم المراسل لبنك المستفيد، رسالة العميل مباشرة والمال يمر برسالة بين البنوك، وتحتهما أن دليل البنك المركزي في قسم الحوالات يذكر المدفوعات المتسلسلة ومدفوعات التغطية بالاسم](https://arabroot.io/content/images/2026/10/cross-border-payments-02-serial-cover.webp) في التغطية يعرف بنك المستفيد بالحوالة قبل أن يصله المال - **المتسلسلة Serial**: رسالة العميل نفسها تمر من بنك إلى بنك، وكل بنك يعيد إرسالها للتالي، فيرى كل بنك في الطريق اسم المرسل والمستفيد. - **التغطية Cover**: بنك المرسل يرسل رسالة العميل مباشرة لبنك المستفيد، ويرسل رسالة منفصلة بين البنوك تمر عبر المراسلين لتغطية المبلغ. وكانت المشكلة التاريخية فيها أن رسالة التغطية القديمة لم تحمل بيانات العميلين، فلم يكن المراسل يعرف من يدفع لمن، ولهذا ظهر النوع COV الذي يحمل بيانات العميل الأصلية معه. ولهذا التفصيل أثر تنظيمي مباشر، فدليل البنك المركزي السعودي لمكافحة غسل الأموال يبدأ قسم الحوالات بأنه ينطبق على الحوالات المحلية والدولية بأي عملة، بما فيها المدفوعات المتسلسلة ومدفوعات التغطية، كما سنرى في فقرة المتطلبات السعودية. ### وأين تتحرك الدولارات فعلاً؟ قد يتساءل المهندس بعد صورة السلسلة: إذا كانت كل خطوة قيداً في دفتر بنك، فمتى تتحرك «نقود حقيقية»؟ والإجابة تعود إلى ما شرحناه في مقال المقاصة والتسوية: داخل كل عملة يوجد نظام تسوية بين البنوك بنقود البنك المركزي لتلك العملة. فإذا كان البنك الوسيط في السلسلة يملك حسابه لدى نفس المراسل الأمريكي الذي يملك فيه البنك السعودي حسابه، فالحركة كلها قيد داخلي في دفاتر ذلك المراسل، يخصم من حساب ويضيف لآخر، دون أن يخرج دولار من مبناه. وإذا كانا في بنكين أمريكيين مختلفين، فالمراسل يسوي مع البنك الآخر في نظام المدفوعات الكبيرة للدولار، مثل Fedwire الذي انتقل بدوره إلى ISO 20022 كما يذكر [مركز تطبيق ISO 20022 لدى الاحتياطي الفيدرالي](https://www.frbservices.org/resources/financial-services/wires/iso-20022-implementation-center?ref=arabroot.io). وهذا يشرح لماذا تمر حوالة بالدولار بين بلدين ليسا الولايات المتحدة ببنك في نيويورك: لأن الدولار نفسه لا يسوى نهائياً إلا في نظام الدولار. ويشرح أيضاً لماذا يهم توقيت نيويورك لحوالة من المملكة إلى ماليزيا، فساعات عمل المراسل ونظام التسوية الأمريكي جزء من الطريق، حتى لو لم يكن أي من الطرفين أمريكياً. ولو كانت الحوالة باليورو، لمرت بمراسل يملك حساباً في نظام اليورو وبمواعيده وعطله، وهكذا لكل عملة. ## من يدفع الرسوم؟ OUR وSHA وBEN الخيار الغامض الذي اختاره المدير المالي في القصة هو حقل `:71A:` في MT103، أو `ChrgBr` في pacs.008، وله ثلاث قيم: - **OUR**: المرسل يدفع كل الرسوم، والمستفيد يستلم المبلغ كاملاً. والبنك المرسل يأخذ رسوماً إضافية مقدماً ليغطي رسوم البنوك التالية، وفي ISO 20022 تقابلها `DEBT`. - **SHA**: كل طرف يدفع رسوم بنكه، فالمرسل يدفع رسوم بنكه، والبنوك التالية تخصم رسومها من المبلغ نفسه، وهذا ما حدث للدولارات الثلاثة والثلاثين. وفي ISO 20022 تقابلها `SHAR`. - **BEN**: المستفيد يدفع كل شيء، حتى رسوم البنك المرسل تخصم من المبلغ، وتقابلها `CRED`. وفوق الرسوم الظاهرة هناك تكلفة لا تظهر كسطر في الكشف: هامش الصرف FX Margin. فالشركة دفعت بالريال، والبنك حولها إلى دولار بسعر أقل قليلاً من السعر الذي يحصل هو عليه، والفرق ربحه. ومع الريال المثبت بالدولار يكون الهامش أوضح، لأن السعر الأساسي معروف، ولكن مع عملات أخرى قد يكون الهامش أكبر من كل الرسوم مجتمعة دون أن يلاحظه أحد. ## المختبر: نموذج للسلسلة بافتراضات مكتوبة لا توجد أسعار أو مواعيد عامة موحدة لبنوك المراسلة، فكل بنك يحددها في عقوده وتعرفته، ولذلك لا يصلح أن نكتب في مقال «رسوم المراسل 15 دولاراً» كأنها حقيقة. والذي يصلح هو نموذج تكتب فيه افتراضاتك صراحة، ثم ترى أثر كل افتراض، ثم تغيره بأرقام بنكك. وهذا ما بنيناه في ملف `chain_model.py`، وكل رقم فيه افتراض للتوضيح: ```python # chain_model.py: a USD payment from a bank in Saudi Arabia to a supplier's bank in Malaysia through two # correspondents, modelled hop by hop. EVERY fee, cut-off and delay below is an ASSUMPTION for illustration, # not a price or rule of any real bank; change them to your bank's numbers. from datetime import datetime, timedelta, timezone from decimal import Decimal as D import sys SAR_PER_USD = D("3.75") # the riyal's fixed rate to the dollar FX_MARGIN = D("0.004") # assumption: 0.4% margin of the sending bank on SAR -> USD # hop: name, UTC offset (hours), weekend days (Mon=0 .. Sun=6), opening hour, cut-off hour, processing minutes, fee in USD HOPS = [ ("sending bank (SA)", 3, {4, 5}, 8, 15, 30, D("0")), # fee charged in SAR at the counter, see below ("USD correspondent (US)", -4, {5, 6}, 9, 17, 20, D("15")), ("intermediary (MY, USD acct)", 8, {5, 6}, 9, 16, 45, D("10")), ("beneficiary bank (MY)", 8, {5, 6}, 9, 16, 60, D("8")), ] SENDER_FEE_SAR = D("75") # assumption: outgoing transfer fee of the sending bank OUR_FEE_USD = D("35") # assumption: flat fee the sending bank charges to guarantee the full amount (OUR) ``` في الإعداد أعلاه لاحظ التالي: - **كل بنك بتوقيته**: فرق التوقيت عن UTC، فالمملكة +3، ونيويورك -4 في أكتوبر، وماليزيا +8، وهذا وحده يجعل الحوالة «تنام» في الطريق كما سنرى. - **كل بنك بعطلته**: عطلة المملكة الجمعة والسبت، وعطلة البنكين الآخرين في النموذج السبت والأحد، فهناك يوم في كل أسبوع يعمل فيه طرف والآخر في عطلة. - **موعد القطع Cut-off**: الساعة التي لا يعالج البنك بعدها حوالات اليوم، فما يصل بعدها ينتظر يوم العمل التالي. والأرقام هنا افتراضية، ومواعيد بنكك الحقيقية في عقدك أو صفحة خدماته. - **المبالغ بالنوع Decimal**: لا كسور عشرية في المال، كما شرحنا في [الأرقام العشرية من الداخل](https://arabroot.io/articles/%D8%A7%D9%84%D8%A3%D8%B1%D9%82%D8%A7%D9%85-%D8%A7%D9%84%D8%B9%D8%B4%D8%B1%D9%8A%D8%A9-floating-point-%D9%85%D9%86-%D8%A7%D9%84%D8%AF%D8%A7%D8%AE%D9%84/). وقلب النموذج دالة تحسب لكل بنك أول لحظة يكون فيها مفتوحاً بعد وصول الرسالة، في توقيته وأيام عمله: ```python def next_open(t, off, weekend, open_h, cut_h): """first moment >= t (UTC) when this hop is open, in its own time zone and working week""" local = t + timedelta(hours=off) while True: day_open = local.replace(hour=open_h, minute=0, second=0, microsecond=0) day_cut = local.replace(hour=0, minute=0, second=0, microsecond=0) + timedelta(hours=cut_h) if local.weekday() not in weekend and local < day_cut: return max(local, day_open) - timedelta(hours=off) local = (local + timedelta(days=1)).replace(hour=0, minute=0, second=0, microsecond=0) ``` وشغلناه في Container من python:3.13.17-slim بالأمر `python chain_model.py`، ولا يحتاج أي مكتبة خارجية. ### النتيجة الأولى: الرسوم بحسب من يدفعها ```text == 1. fees for one invoice, by charge bearer (field 71A / ChrgBr) USD 500 OUR: supplier gets USD 500 | sender pays SAR 2088.75 | total cost 11.40% of the amount USD 500 SHA: supplier gets USD 467 | sender pays SAR 1957.50 | total cost 11.00% of the amount USD 500 BEN: supplier gets USD 447.00 | sender pays SAR 1882.50 | total cost 11.00% of the amount USD 10000 OUR: supplier gets USD 10000 | sender pays SAR 37856.25 | total cost 0.95% of the amount USD 10000 SHA: supplier gets USD 9967 | sender pays SAR 37725.00 | total cost 0.93% of the amount USD 10000 BEN: supplier gets USD 9947.00 | sender pays SAR 37650.00 | total cost 0.93% of the amount ``` ![جدول بأشرطة: USD 500 بطريقة OUR يصل 500 وتكلفته الكلية 11.40%، وSHA يصل 467 بتكلفة 11.00%، وBEN يصل 447 بتكلفة 11.00%، وUSD 10,000 بطريقة OUR يصل 10,000 بتكلفة 0.95%، وSHA يصل 9,967 بتكلفة 0.93%، وBEN يصل 9,947 بتكلفة 0.93%، وتحتها أن الرسوم ثابتة تقريباً فالحوالة الصغيرة تدفع نسبة أكبر بكثير وكل الأرقام افتراضات المختبر](https://arabroot.io/content/images/2026/10/cross-border-payments-03-fees.webp) نفس الرسوم الثابتة: 11% من حوالة صغيرة، وأقل من 1% من حوالة كبيرة في المخرج أعلاه لاحظ التالي: - **9,967 دولاراً**: هذا بالضبط ما وصل للاستوديو في القصة بطريقة SHA، لأن البنوك الثلاثة بعد البنك المرسل خصمت 15 و10 و8 من المبلغ نفسه. فالأرقام في القصة من النموذج، والقصة قصة الافتراضات. - **OUR ليست مجانية**: الاستوديو استلم المبلغ كاملاً، ولكن الشركة دفعت أكثر، والتكلفة الكلية بالنسبة للمبلغ أعلى قليلاً من SHA. ولكنها الطريقة الوحيدة التي تجعل الفاتورة تسدد بالكامل دون فرق يحتاج حوالة ثانية، وهذا ما تطلبه أغلب العقود مع الموردين. - **الحوالة الصغيرة مكلفة**: نفس الرسوم الثابتة تساوي 11% من 500 دولار، وأقل من 1% من عشرة آلاف. وهذا هو جوهر مشكلة التحويلات العائلية، التي يرسل فيها العامل مبلغاً صغيراً كل شهر. ### النتيجة الثانية: لماذا يهم يوم الإرسال؟ ثم تتبعنا حوالة واحدة أرسلت يوم الأحد الساعة العاشرة صباحاً بتوقيت السعودية: ```text == 2. one payment sent Sunday 10:00 Riyadh time, hop by hop sending bank (SA) done Sun 10:30 local | 0.5 h after sending USD correspondent (US) done Mon 09:20 local | 30.3 h after sending intermediary (MY, USD acct) done Tue 09:45 local | 42.8 h after sending beneficiary bank (MY) done Tue 10:45 local | 43.8 h after sending ``` البنك السعودي عالجها في نصف ساعة، لأن الأحد يوم عمل في المملكة. ثم وصلت الرسالة إلى نيويورك وهو يوم الأحد هناك، أي عطلة، فانتظرت حتى الاثنين الساعة التاسعة. ثم وصلت إلى ماليزيا الساعة 09:20 صباح الاثنين بتوقيت نيويورك، أي 21:20 مساء الاثنين في ماليزيا، بعد موعد القطع، فانتظرت حتى صباح الثلاثاء. فالحوالة التي لم تستغرق معالجتها الفعلية في البنوك الأربعة إلا ساعتين وخمس وثلاثين دقيقة، استغرقت 43.8 ساعة، وكل الفرق انتظار. ثم كررنا التجربة لكل نصف ساعة في أسبوع كامل: ```text == 3. sending at every half hour of one week (Sunday 00:00 to Saturday 23:30, Riyadh time) credited within 1 h: 0.0% | within 24 h: 21.4% | median 36.2 h | worst 110.8 h sent on Sun: median 42.2 h, worst 53.8 h sent on Mon: median 27.2 h, worst 38.8 h sent on Tue: median 27.2 h, worst 38.8 h sent on Wed: median 27.2 h, worst 38.8 h sent on Thu: median 27.2 h, worst 110.8 h sent on Fri: median 90.2 h, worst 101.8 h sent on Sat: median 66.2 h, worst 77.8 h ``` ![أعمدة بالساعات بحسب يوم الإرسال بتوقيت السعودية: الأحد وسيط 42.2 وأسوأ 53.8، والاثنين والثلاثاء والأربعاء وسيط 27.2 وأسوأ 38.8، والخميس وسيط 27.2 وأسوأ 110.8، والجمعة وسيط 90.2 وأسوأ 101.8، والسبت وسيط 66.2 وأسوأ 77.8، وتحتها أن عطلة السعودية الجمعة والسبت والبنوك في الولايات المتحدة وماليزيا في النموذج السبت والأحد](https://arabroot.io/content/images/2026/10/cross-border-payments-04-weekdays.webp) الخميس بعد الظهر أسوأ وقت في الأسبوع في هذا النموذج والنتيجة تشرح قصة الحوالة الثانية: الخميس في وسيطه مثل بقية الأسبوع، ولكن أسوأ حالة فيه 110.8 ساعة، أي أكثر من أربعة أيام. والسبب أن ما يرسل بعد موعد قطع البنك السعودي يوم الخميس ينتظر الأحد، لأن الجمعة والسبت عطلة في المملكة، ثم الأحد عطلة في البنكين الآخرين، فلا يتحرك شيء قبل الاثنين. ولاحظ أن النموذج لم يعط أي حوالة خلال ساعة واحدة، لأن كل بنك فيه يعمل ساعات محدودة ويتعاقب على توقيتات متباعدة. ### ماذا لو تغير شيء واحد؟ جربنا ثلاثة تغييرات، كل منها يجيب عن سؤال سأله المدير المالي: ```text == 4. what if the intermediary holds the payment one business day for a screening alert? within 24 h: 0.0% | median 75.2 h | worst 134.8 h == 5. what if the chain is one hop shorter (beneficiary bank holds its own USD account in the US)? within 24 h: 23.8% | median 35.5 h | worst 110.0 h | SHA fees USD 23 instead of 33 == 6. what if every hop works its whole business day (00:00-24:00 local) and processes in 5 minutes? within 1 h: 53.3% | within 24 h: 67.0% | median 0.3 h | worst 79.2 h ``` - **تنبيه فحص في الطريق**: إذا أوقف البنك الوسيط الحوالة يوم عمل واحداً لمراجعة تنبيه في فحص العقوبات، يقفز الوسيط من 36.2 ساعة إلى 75.2\. وهذا يحدث في الواقع عندما يشبه اسم المستفيد أو المرسل اسماً في قائمة، كما شرحنا بالأرقام في [معرفة العميل KYC وفحص العقوبات](https://arabroot.io/articles/%D9%85%D8%B9%D8%B1%D9%81%D8%A9-%D8%A7%D9%84%D8%B9%D9%85%D9%8A%D9%84-kyc-%D9%88%D9%81%D8%AD%D8%B5-%D8%A7%D9%84%D8%B9%D9%82%D9%88%D8%A8%D8%A7%D8%AA-%D8%A8%D8%A7%D9%84%D8%A7%D8%B3%D9%85%D8%A7%D8%A1-%D8%A7%D9%84%D8%B9%D8%B1%D8%A8%D9%8A%D8%A9/)، وكل بنك في السلسلة يفحص بطريقته وعتبته. ولهذا فاسم المستفيد الكامل والصحيح وعنوانه وغرض الحوالة ليست تفاصيل شكلية، فكلما كانت البيانات أوضح قل احتمال التوقف. - **سلسلة أقصر**: إذا كان لبنك المستفيد حساب دولار مباشر في نيويورك، نختصر بنكاً كاملاً، فتنخفض الرسوم من 33 إلى 23 دولاراً، ويتحسن الوقت قليلاً فقط، لأن المشكلة الأكبر في التوقيت والعطل لا في عدد البنوك. - **بنوك تعمل اليوم كله وتعالج في خمس دقائق**: يصل 53.3% خلال ساعة، والوسيط 0.3 ساعة. ولكن 67% فقط خلال 24 ساعة، لأن عطلة نهاية الأسبوع المختلفة ما زالت تحبس ما يرسل من الخميس إلى الأحد. أي أن السرعة داخل البنوك تحل جزءاً، والتقويم يبقى. والرقم 53.3% في السيناريو الأخير قريب من الرقم الرسمي للتحويلات بين البنوك الذي سنراه بعد قليل، وهذه مصادفة لا دليل، فالنموذج مبني على افتراضاتنا وليس معايراً على بيانات حقيقية. والذي يصح أن تأخذه منه هو الآلية: الوقت في الحوالة الدولية انتظار في الغالب، والانتظار سببه مواعيد القطع والعطل والفحص، لا سرعة الرسائل. وإذا أردت أن تستخدم النموذج لشركتك، فابدأ بثلاثة أسطر فقط: مواعيد القطع التي يعلنها بنكك للحوالات الدولية بكل عملة، وعطل بلد المستفيد وبلد العملة، والرسوم التي خصمت فعلاً من آخر عشر حوالات أرسلتها كما ظهرت في تأكيدات الموردين. ثم شغل الأسبوع كله واطبع لكل يوم وسيطه وأسوأ حالة فيه، فتعرف متى ترسل وكم يوماً تضيف لتاريخ استحقاق كل فاتورة، بدل أن تكتشف ذلك من رسائل الموردين. ## الرسائل: قراءة MT103 حقيقية الرسوم والأوقات في النموذج افتراضات، أما الرسائل فلها شكل محدد. ولأن رسائل البنوك الحقيقية لا تنشر، استخدمنا رسائل الاختبار التي تنشرها مكتبة Prowide Core مفتوحة المصدر برخصة Apache-2.0 في [ملف الاختبار MT103-out-ack.rje](https://github.com/prowide/prowide-core/blob/main/src/test/resources/MT103-out-ack.rje?ref=arabroot.io)، وكل بياناتها وهمية بأسماء مثل FOO. وهذا شكل أول رسالة في الملف: ```text {1:F01BICFOOYYAXXX8667486276}{2:O1031610191014BBBBUS3NBXXX63382244921910142210N}{3:{108:FDF1910141142100}{121:8579f4a4-a547-463e-ae63-e7c6620d59b4}}{4: :20:22342343 :23B:CRED :32A:191014USD1814,28 :50K:FOO CAPITAL MARKETS LP 99 WALL ST STE 9999 NEW YORK, NY 10005-3122 :52D:NORTH FOO BANK 999 BROAD FOO RD MELVILLE, NY 11747 :59:/00123456789012345678 MERCADOS Y GESTION DE VALORES SA FOOSTREET 65 MADRID SPAIN 28010701.18 :70:FINDERS FEES-JULY,2007- 10.00, AUG UST,2007- 0.00 SEPTEMBER,2007 1,999.99 BNY CUST RRN - O/B NORTH FORK B :71A:SHA :72:/ACC/ 00940060752415000231 -} ``` الرسالة من أربعة أجزاء Blocks: الأول للمرسل، والثاني للنوع 103 ووقت الإدخال وتاريخه، والثالث فيه الحقل 121 وهو المعرف الفريد للحوالة UETR الذي سنعود إليه، والرابع النص بحقوله. وكتبنا محللاً بسيطاً يقرأ الرسائل الثلاث عشرة في الملف، ويطبع لكل منها ما يصف السلسلة، ويفحص فحصين بسيطين: ```text 13 MT103 messages 20=22342343 32A=2019-10-14 USD 1814.28 71A=SHA agents=52D UETR=yes 20=INGDESMM 32A=2019-10-28 EUR 111222.33 71A=OUR agents=52A,53A,57A UETR=no 20=INGDESMM 32A=2007-10-28 EUR 54321.23 71A=OUR agents=52A,53A,57A UETR=no CHECK: value date 2007-10-28 far from message date 2019-10-28 20=FOODESMM 32A=2006-10-28 EUR 19999 71A=OUR agents=52A,53A,57A UETR=no CHECK: value date 2006-10-28 far from message date 2019-10-28 20=OMF000000724103 32A=2019-10-28 EUR 765432 71A=SHA agents=52A,53A,57A UETR=no 20=530165650050 32A=2019-10-28 EUR 12345.67 71A=OUR agents=52A,53A,57A UETR=no 20=0061350113089906 32A=2001-10-28 EUR 754321 71A=OUR agents=52A,53A,57A UETR=no CHECK: value date 2001-10-28 far from message date 2019-10-28 20=0061350113089908 32A=2006-10-28 EUR 100000 71A=OUR agents=52A,53A,57A UETR=no CHECK: value date 2006-10-28 far from message date 2019-10-28 20=0061350113089907 32A=2019-10-28 EUR 74321 71A=OUR agents=52A,53A,57A UETR=no 20=AMLX985338-D4E5E 32A=2019-10-18 EUR 66969.52 71A=OUR agents=53A,54A UETR=no 20=0061350113089903 32A=2019-10-28 EUR 47000 71A=OUR agents=52A,53A,57A UETR=no 20=0061350113089904 32A=2019-10-28 EUR 10000 71A=OUR agents=52A,53A,57A UETR=no 20=0061350113089905 32A=2019-10-28 EUR 10000 71A=OUR agents=52A,53A,57A UETR=no ``` في المخرج أعلاه لاحظ التالي: - **حقول البنوك هي السلسلة**: الحقل 52 بنك المرسل، و53 مراسل المرسل، و54 مراسل المستفيد، و56 الوسيط، و57 بنك المستفيد. فوجود 52A و53A و57A في أغلب الرسائل يعني أن السلسلة مكتوبة في الرسالة نفسها، وأي نظام يحلل كشوف حساباتك يستطيع أن يعرف منها من مر بالحوالة. - **رسالة واحدة فقط فيها UETR**: الأولى، وهي الأحدث في الملف من حيث الشكل. والمعرف الفريد UETR هو ما يجعل التتبع ممكناً كما سنرى في gpi. - **أخطاء في بيانات الاختبار نفسها**: أربع رسائل تاريخ قيمتها في 2001 أو 2006 أو 2007، والرسالة نفسها مؤرخة 2019\. وهذه بيانات اختبار لمكتبة، لا رسائل حقيقية، ولكنها تذكرك بقاعدة عملية: لا يقرأ نظامك رسالة مالية دون فحوص معقولة على تواريخها ومبالغها، لأن الرسالة الصحيحة الشكل قد تكون خاطئة المعنى. وفي أثناء كتابة المحلل وقعنا في خطأ يستحق الذكر: قرأنا تاريخ الرسالة من الجزء الثاني بمواضع خاطئة، فأخذنا حرفين من رمز البنك مع التاريخ، فرفض Python التحويل برسالة `unconverted data remains: BB`. والسبب أن الجزء الثاني لرسالة صادرة Output يبدأ بـ O ثم النوع 103 ثم وقت الإدخال بأربعة أرقام ثم التاريخ، فالتاريخ في المواضع من 8 إلى 14 لا من 10\. وهذا هو عيب الرسائل بالحقول الثابتة الذي رأيناه في ISO 8583 أيضاً: لا أسماء، والمعنى كله في المواضع. ## من MT103 إلى pacs.008: ماذا يضيع؟ ثم أخذنا الرسالة الأولى وكتبناها من جديد كرسالة pacs.008.001.09، وتحققنا منها بالمخطط XSD الذي ولده محرر معايير ISO 20022 كما يقول رأس الملف، واستخدمنا النسخة المنشورة في [مستودع moov-io/iso20022](https://github.com/moov-io/iso20022/blob/master/docs/specifications/payments%5Fclearing%5Fand%5Fsettlement%5F10/pacs.008.001.09.xsd?ref=arabroot.io) برخصة Apache-2.0، لأن موقع المعيار لم يسمح بالتنزيل الآلي. والمخرج: ```text MT103 block 4: 430 bytes | pacs.008: 2009 bytes | valid: True //p:UETR 8579f4a4-a547-463e-ae63-e7c6620d59b4 //p:IntrBkSttlmAmt 1814.28 {'Ccy': 'USD'} //p:ChrgBr SHAR //p:Dbtr/p:Nm FOO CAPITAL MARKETS LP //p:Cdtr/p:Nm MERCADOS Y GESTION DE VALORES SA //p:Ustrd FINDERS FEES-JULY,2007- 10.00, AUG UST,2007- 0.00 SEPTEMBER,2007 1,999.99 BNY CUST RRN - O/B NORTH FORK B == what the XSD allows agents in a transaction: ['PrvsInstgAgt1', 'PrvsInstgAgt1Acct', 'PrvsInstgAgt2', 'PrvsInstgAgt2Acct', 'PrvsInstgAgt3', 'PrvsInstgAgt3Acct', 'InstgAgt', 'InstdAgt', 'IntrmyAgt1', 'IntrmyAgt1Acct', 'IntrmyAgt2', 'IntrmyAgt2Acct', 'IntrmyAgt3', 'IntrmyAgt3Acct', 'DbtrAgt', 'CdtrAgt', 'InstrForCdtrAgt', 'InstrForNxtAgt'] Max140Text: maxLength 140 Max70Text: maxLength 70 Max35Text: maxLength 35 AdrLine: Max70Text maxOccurs 7 UETR pattern: [a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89ab][a-f0-9]{3}-[a-f0-9]{12} == what if the UETR is written in capitals, as some systems print it? valid: False | Element '{urn:iso:std:iso:20022:tech:xsd:pacs.008.001.09}UETR': [facet 'pattern'] The value '8579F4A4-A547-463 ``` ![ربط حقول MT103 بعناصر pacs.008: الحقل 20 إلى InstrId، والحقل 121 في الجزء الثالث إلى UETR بنمط UUIDv4 بأحرف صغيرة، والحقل 32A إلى IntrBkSttlmAmt وIntrBkSttlmDt والفاصلة العشرية تصبح نقطة، والحقل 71A SHA إلى ChrgBr SHAR، والحقل 50K بأربعة أسطر من 35 حرفاً إلى Dbtr/Nm وAdrLine حتى 7 أسطر من 70 والعنوان بلا بنية، والحقل 70 بأربعة أسطر من 35 إلى RmtInf/Ustrd بحد 140 وكلمة AUG UST قسمها السطر](https://arabroot.io/content/images/2026/10/cross-border-payments-05-mt-mx.webp) الرسالة صحيحة بالمخطط، ولكن بعض المعنى ضاع قبل أن تصل إليه في المخرج أعلاه لاحظ التالي: - **الحجم**: 430 بايتاً في MT صارت 2,009 بايتات في XML، لأن كل قيمة تحمل اسمها، وهذا الثمن الذي رأيناه في مقال الرسائل. - **AUG UST**: في MT103 يكون نص الحوالة أربعة أسطر من 35 حرفاً، والنظام الذي كتبها قسم كلمة AUGUST بين سطرين. فلما جمعنا الأسطر بمسافة صارت كلمتين. وأي تحويل من MT إلى MX يواجه هذا السؤال: هل نجمع الأسطر بمسافة أم دونها؟ ولا توجد إجابة صحيحة دائماً، لأن المعلومة ضاعت يوم كتبت الرسالة الأولى. - **العنوان بلا بنية**: عنوان المرسل في 50K أسطر حرة، فوضعناه في `AdrLine`. والمخطط يسمح بذلك حتى سبعة أسطر من 70 حرفاً، ولكن فائدة ISO 20022 الحقيقية هي العنوان المنظم، اسم الشارع ورقم المبنى والمدينة والدولة في عناصر منفصلة، لأن فحص العقوبات يعمل أفضل عندما يعرف أين المدينة وأين الدولة. وهذا ما لا يمكن استخراجه آلياً بثقة من نص حر. - **حدود السلسلة**: المخطط يسمح بثلاثة بنوك وسيطة `IntrmyAgt1` إلى `IntrmyAgt3`، وثلاثة بنوك سابقة `PrvsInstgAgt1` إلى `PrvsInstgAgt3`، أي أن الرسالة نفسها تعرف أن السلاسل الطويلة موجودة. - **UETR بأحرف كبيرة**: المخطط يفرض نمط UUID الإصدار 4 بأحرف صغيرة، فرفض نفس المعرف بأحرف كبيرة. وهذا خطأ يقع فيه من ينسخ المعرف من شاشة أو تقرير يعرضه بأحرف كبيرة. ## gpi: الحوالة التي تعرف أين هي قبل خدمة gpi كانت الحوالة الدولية مثل طرد بلا رقم تتبع: ترسل، ثم تتصل بالبنك بعد أيام لتسأل. وفكرة gpi بسيطة في جوهرها: كل حوالة تحمل معرفاً فريداً UETR من البداية إلى النهاية، وكل بنك في السلسلة يبلغ متتبعاً مركزياً Tracker بما فعله ومتى وكم خصم، فيستطيع المرسل أن يرى الحوالة في كل محطة. ونشرت Swift مواصفة واجهة المتتبع في [مستودع الأمثلة الرسمي لها على GitHub](https://github.com/swiftinc/api-sample-code/blob/main/java/spring-boot/gpi/src/main/openapi/SWIFT-API-gpi-api-transactions-and-cancellations-6.0.1-swagger.yaml?ref=arabroot.io)، الإصدار 6.0.1، وفيها مثال لرد «تفاصيل حوالة»، فقرأناه كما يقرؤه نظام مالية في شركة: ```text UETR 3e8d2edb-88cb-47e6-9105-1b0d903c28d8 | status ACCC initiated 2024-03-16 13:22 UTC, completed 2024-03-16 18:22 UTC: 5.0 h end to end 13:22:45 CTPT pacs.008.001.08 BANKABICXXX -> BANKBBICXXX status ACSP amount USD 990 charges [('BANKABICXXX', Decimal('10'))] bearer CRED 18:22:45 CTSU 199 BANKBBICXXX -> TRCKCHZ0XXX status ACCC amount USD 940 charges [('BANKBBICXXX', Decimal('50.00'))] instructed USD 1000 -> credited 940 | charges 60.00 (6.0%) | check: True == consistency of the dates inside the example CTPT sender_acknowledgement_receipt_date_time = 2024-11-25T13:22:45.000Z is 254 days from the initiation date CTPT interbank_settlement_date = 2024-11-25 is 254 days from the initiation date CTPT network_reference starts with 20211125 ``` ![مثال المتتبع: المبلغ المطلوب USD 1000 عند 13:22:45 UTC، ثم البنك A يرسل pacs.008 ويخصم USD 10 فالمبلغ بين البنوك 990، ثم البنك B يؤكد الإضافة ويخصم USD 50 فيصل 940 عند 18:22:45، وتحتها خمس ساعات و6% رسوماً والمرسل يرى كل ذلك من رقم واحد UETR، وأن في نفس المثال تواريخ لا تتسق: إشعار استلام بعد 254 يوماً ومرجع شبكة من 2021](https://arabroot.io/content/images/2026/10/cross-border-payments-06-gpi.webp) من 1000 إلى 940 في خمس ساعات، وكل خصم باسم البنك الذي أخذه في المخرج أعلاه لاحظ التالي: - **كل خصم باسم صاحبه**: البنك A أخذ 10 دولارات، والبنك B أخذ 50، والمستفيد استلم 940، والمجموع يطابق بالضبط. وهذا ما كان يحتاجه المدير المالي في القصة: لا «أين ذهبت الدولارات الثلاثة والثلاثين؟»، وإنما سطر لكل بنك. - **الحالة**: `ACSP` تعني أن التسوية بدأت، و`ACCC` أن المبلغ أضيف لحساب المستفيد، وهذه رموز حالات ISO 20022 نفسها، والمرسل يعرف أن الحوالة انتهت فعلاً لا أنها «في الطريق». - **تواريخ لا تتسق في المثال**: إشعار الاستلام وتاريخ التسوية في المثال بعد 254 يوماً من بدء الحوالة، ومرجع الشبكة يبدأ بتاريخ من 2021\. وهذا مثال توضيحي في مواصفة، لا حوالة حقيقية، ولكن فحصنا البسيط أمسكه، وهو نفس الدرس الذي رأيناه في رسائل الاختبار: البيانات المنشورة للأمثلة ليست دائماً متسقة، فلا تجعل اختباراتك تعتمد على أن المثال صحيح. ولاحظ أن gpi خدمة بين البنوك، والشركة الناشئة لا تتصل بالمتتبع مباشرة عادة، وإنما تسأل بنكها. والسؤال الذي يجب أن تسأله لبنكك قبل أن تعتمد عليه: هل تعطيني UETR لكل حوالة صادرة؟ وهل أستطيع أن أرى حالتها والرسوم التي خصمت منها؟ ## ماذا لو أخطأت في رقم الحساب؟ في الحوالة الثالثة للشركة كتب المدير المالي رقم حساب ناقصاً، فوصلت الحوالة إلى بنك المستفيد ولم يجد الحساب. وهنا لا «تفشل» الحوالة كما يفشل طلب في API، فالمال تحرك فعلاً عبر السلسلة، ويجب أن يعود بنفس الطريق برسالة إرجاع، هي pacs.004 في ISO 20022، ومعها رمز سبب. وفي مواصفة متتبع gpi نفسها قائمة بهذه الرموز، منها `AC01` لرقم حساب غير صحيح أو ناقص، و`AC04` لحساب مغلق، و`BE01` لهوية عميل لا تتفق مع رقم الحساب، و`RR03` لنقص اسم المستفيد أو عنوانه المطلوب للمتطلبات النظامية، و`FOCR` للإرجاع بعد طلب إلغاء. وفي نفس المواصفة مثال لحوالة مرتجعة بالرمز `AM06`، أرسلت بألف دولار، وعادت 950 في رسالة pacs.004. والدرس من هذا المثال أن الإرجاع لا يعيد المبلغ كاملاً غالباً، فالرسوم التي خصمت في الطريق لا تعود، وقد يخصم بنك المستفيد رسوماً على الإرجاع نفسه، ثم يحول البنك السعودي الدولارات العائدة إلى ريال بسعر شرائه، فتخسر هامش الصرف مرتين. لذلك فأرخص حوالة هي التي لا تعود: تحقق من رقم IBAN بطريقة mod 97 قبل الإرسال كما شرحنا في مقال الرسائل، واطلب من المورد بيانات بنكه مكتوبة على ورق رسمي، ولا تقبل تغيير بيانات بنك المورد بالبريد الإلكتروني وحده، لأن انتحال البريد لتغيير حساب المستفيد نوع معروف من الاحتيال على الشركات، والمال الذي يصل إلى حساب المحتال لا تعيده أي رسالة pacs.004. أما إذا اكتشفت الخطأ بعد الإرسال مباشرة، فالطريق طلب إلغاء Cancellation Request يرسله بنكك عبر السلسلة، وفي gpi له تتبع خاص، ولكنه طلب لا أمر: إذا كان بنك المستفيد قد أضاف المبلغ، فإعادته تحتاج موافقة المستفيد. ولهذا فالتحقق قبل الضغط على «إرسال» أهم بكثير من أي إجراء بعده. ## الأرقام الرسمية: كم تستغرق الحوالة فعلاً؟ النموذج يشرح الآلية، أما الأرقام الحقيقية فمصدرها تقرير مجلس الاستقرار المالي السنوي عن مؤشرات الأداء لأهداف مجموعة العشرين في التحويلات الدولية، وآخره في [التقرير الموحد لسنة 2025](https://www.fsb.org/2025/10/g20-roadmap-for-cross-border-payments-consolidated-progress-report-for-2025/?ref=arabroot.io) المنشور في 9 أكتوبر 2025، ومنه: | المؤشر | 2023 | 2024 | 2025 | | ----------------------------------------------------------- | ----- | ----- | ----- | | التحويلات بين البنوك Wholesale المضافة خلال ساعة من بدايتها | 53.8% | 50.6% | 54.6% | | التحويلات بين البنوك المضافة خلال يوم عمل | 92.7% | 92% | 93.2% | | الجزء بين البنوك وحده In-flight خلال ساعة | 89.5% | 90.4% | 88.5% | | جزء بنك المستفيد وحده خلال ساعة | 60.2% | 56.3% | 61.7% | والمصدر في جدول التقرير هو Swift. ولاحظ الفرق بين السطرين الأخيرين: الرسائل بين البنوك تصل خلال ساعة في قرابة تسعين بالمئة من الحالات، أما الخطوة الأخيرة، من استلام بنك المستفيد للرسالة إلى إضافة المبلغ لحساب العميل، فهي الأبطأ، ويذكر التقرير أنها تقليدياً أبطأ جزء في الحوالة الدولية، وأن التحسن في 2025 جاء أغلبه منها. وهذا يتفق مع ما رأيناه في النموذج: الوقت يضيع في الانتظار عند البنوك لا في الشبكة. ويذكر التقرير عن الشرق الأوسط أن 32.3% فقط من التحويلات بين البنوك أضيفت خلال ساعة، مقابل 25.7% في 2023، وأن 87.1% أضيفت خلال يوم، فالمنطقة من أبطأ ثلاث مناطق في هذا المؤشر رغم تحسنها. وفي التحويلات العائلية Remittances يذكر التقرير، من قاعدة بيانات البنك الدولي لأسعار التحويلات، أن متوسط تكلفة إرسال 200 دولار عالمياً بقي 6.5% في 2025، و4.3% لإرسال 500 دولار، وأن نسبة خدمات التحويل التي تتيح المال للمستلم خلال ساعة ارتفعت إلى 54.4%. وأهداف مجموعة العشرين التي نشرها المجلس في [تقرير الأهداف في أكتوبر 2021](https://www.fsb.org/2021/10/targets-for-addressing-the-four-challenges-of-cross-border-payments-final-report/?ref=arabroot.io) هي أن تصل 75% من التحويلات بين البنوك خلال ساعة بنهاية 2027، وأن ينخفض متوسط تكلفة إرسال 200 دولار إلى 3% بحلول 2030 دون أي ممر Corridor يتجاوز 5%. أي أن العالم ما زال بعيداً عن هدف التكلفة بأكثر من الضعف، وهذا يفسر لماذا تظهر كل سنة شركات جديدة تعد بتحويلات أرخص. ### والتحويلات العائلية من المنطقة؟ القسم الإقليمي في نفس التقرير يعطي صورة أقرب لنا. ففي الشرق الأوسط وشمال أفريقيا تراوح متوسط تكلفة المدفوعات الدولية للأفراد والشركات المرسلة من المنطقة بين 2.1% و3.4% بحسب نوع الاستخدام، وفي التحويلات من شخص لشخص P2P بلغت نسبة الممرات التي تتجاوز تكلفتها 3% نحو 59%، وهي أعلى من 2024 و2023\. وأكثر من 60% من المدفوعات من الأفراد والشركات للشركات B2B وB2P احتاجت أكثر من يوم عمل حتى يضاف المال. أما التحويلات العائلية المستلمة في المنطقة فتكلفتها وسرعتها قريبة من المتوسط العالمي، ونسبة الخدمات التي تتيح المال خلال ساعة ارتفعت قرابة 5 نقاط إلى 52.3%. ويذكر التقرير على المستوى العالمي أن خدمات التحويل الرقمية بقيت أرخص في المتوسط من الخدمات النقدية. وهذه الأرقام تشرح لماذا تبني شركات التقنية المالية في المنطقة منتجات للتحويلات: الفرق بين 6.5% والهدف 3% على مبالغ صغيرة متكررة كل شهر هو هامش كبير لمن يستطيع أن يختصر السلسلة، بحسابات مباشرة في بلد المستلم، أو بالربط مع أنظمة الدفع الفوري في البلدين. ولكن تذكر أن كل اختصار في السلسلة يبقى خاضعاً لنفس متطلبات معلومات الحوالة وفحص الأسماء، فمعلومات المرسل والمستفيد والغرض وفحص الأسماء ترافق الحوالة مهما صغرت أو قصر طريقها. ## هل يمكن الاستغناء عن السلسلة؟ ربط أنظمة الدفع الفوري من المفيد أن تعرف أن تحسين التحويلات الدولية صار أولوية عالمية بمبادرة من المملكة، فالتقرير الموحد لسنة 2025 يبدأ ملخصه بأن رئاسة المملكة لمجموعة العشرين قبل خمس سنوات جعلت تحسين المدفوعات عبر الحدود أولوية، وطلبت من مجلس الاستقرار المالي وضع خارطة الطريق التي جاءت منها الأهداف أعلاه. ومن الحلول التي يتابعها التقرير ربط أنظمة الدفع الفوري Fast Payment Systems بين البلدين مباشرة، بدل سلسلة المراسلين. والمثال الذي يفصله التقرير ربط نظام PayNow في سنغافورة بنظام PromptPay في تايلاند منذ أبريل 2021: يحول العميل برقم الجوال حتى 1,000 دولار سنغافوري يومياً، وتكتمل الحوالة خلال دقائق، والرسوم مجانية أو بين 1% و2%، بينما كانت الرسوم وهامش الصرف قبل الربط 13% في المتوسط ونزلت إلى أقل من 3%، وفي 2024 مر عبر الربط أكثر من 870 ألف حوالة بزيادة 16% عن السنة التي قبلها. ويذكر التقرير أيضاً منصة بنى Buna الإقليمية للمدفوعات، وأن البنك الدولي دعم باكستان في التحضير للربط بها. والمهم للمهندس أن هذه الحلول لا تلغي الأسئلة التي ناقشناها، وإنما تنقلها: الحوالة ما زالت تحتاج تحويل عملة، وحداً أعلى، وبيانات المرسل والمستفيد، وفحص الأسماء في الطرفين، وطريقة لتسوية الصافي بين النظامين. ولكنها تختصر الانتظار عند المراسلين ومواعيد القطع، وهو بالضبط الجزء الذي رأينا في النموذج أنه يأكل أغلب الوقت. ولهذا فالمنتج الذي يبني تحويلات في ممر فيه ربط مباشر بين نظامين فوريين يستطيع أن يعد عملاءه بدقائق، أما الممر الذي يمر بالمراسلين فالوعد الصادق فيه يحتاج جدول المواعيد والعطل الذي بنيناه. ## ما يطلبه البنك المركزي السعودي الحوالة الدولية في المملكة ليست قراراً تقنياً بين بنكين فقط، فنظام مكافحة غسل الأموال يطلب في [المادة 10](https://rulebook.sama.gov.sa/en/anti-money-laundering-law?ref=arabroot.io) أن تحصل المؤسسة المالية على معلومات المرسل والمستفيد، وأن تبقى هذه المعلومات مع الحوالة أو رسالتها في كل السلسلة، وألا تنفذ الحوالة إذا لم تحصل عليها. وفي المادة 9 يطلب قبل الدخول في علاقة مراسلة عبر الحدود اتخاذ إجراءات لتخفيف المخاطر، والتأكد أن البنك المراسل لا يسمح لبنك صوري Shell Bank باستخدام حسابه. ثم يفصل [دليل مكافحة غسل الأموال وتمويل الإرهاب](https://rulebook.sama.gov.sa/en/guidance-anti-money-laundering-and-combating-terrorist-financing?ref=arabroot.io) ذلك في قسمين: - **القسم 13، علاقات المراسلة**: قبل علاقة المراسلة تجمع المؤسسة معلومات كافية عن المراسل وطبيعة عمله والرقابة عليه ومدى تطبيقه لمتطلبات مكافحة غسل الأموال، وتقيم سياساته باستبيان، وتحتاج موافقة الإدارة العليا، وتراقب حسابات المراسلة باستمرار. - **القسم 14، الحوالات**: الفقرة 14.1 تحدد أقل ما يجب أن تحمله الحوالة: الاسم الكامل للمرسل، ورقم حسابه، وعنوانه أو رقم هويته أو رقم العميل أو مكان وتاريخ ميلاده، والاسم الكامل للمستفيد ورقم حسابه، وغرض الحوالة والعلاقة بين المرسل والمستفيد. والفقرة 14.2 تطلب من العميل إقراراً بأنه يعلم أن أنظمة المملكة تمنع التحويل دون معرفة المستفيد أو دون علاقة مشروعة أو غرض مشروع، والفقرة 14.9 تمنع تنفيذ الحوالة إذا لم تستوف المعلومات. وهذا يفسر الشاشة التي ملأها المدير المالي في القصة: حقل «غرض الحوالة» و«العلاقة بالمستفيد» ليسا فضولاً من البنك، وإنما متطلبات مكتوبة، والإجابة الغامضة مثل «أخرى» قد تكون سبب سؤال إضافي من البنك أو من مراسل في الطريق. والمعلومات نفسها هي ما يفحصه كل بنك في السلسلة مقابل قوائم العقوبات. ## ماذا يعني ذلك لمنتجك؟ بعد المختبر كتب المهندس والمدير المالي قائمة تغييرات صغيرة، وهي ما يحتاجه أي فريق يدفع لموردين في الخارج أو يبني منتجاً فيه تحويلات دولية: 1. **OUR لفواتير الموردين**: الفاتورة تسدد بالكامل دون فرق، والرسوم الإضافية مصروف معروف، بدل حوالة ثانية بثلاثة وثلاثين دولاراً تكلف رسوماً من جديد. 2. **لا إرسال بعد ظهر الخميس**: الحوالات الكبيرة ترسل من الأحد إلى الأربعاء قبل موعد القطع، والمستحقات تحسب بتاريخ يأخذ في الاعتبار عطل الطرفين، لا عطلة المملكة وحدها. 3. **بيانات مستفيد كاملة**: الاسم القانوني كما في حساب المستفيد، والعنوان كاملاً، والغرض واضحاً، ورقم الفاتورة في نص الحوالة، لأن كل نقص سبب محتمل للتوقف في فحص بنك ما. 4. **UETR في سجلاتك**: كل حوالة صادرة يحفظ معها معرفها الفريد ورسوم كل بنك إن أمكن، فتطابقها مع كشف الحساب ومع ما وصل للمورد، كما شرحنا في [المطابقة: كشف البنك مقابل نظامك](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D8%B7%D8%A7%D8%A8%D9%82%D8%A9-reconciliation-%D9%83%D8%B4%D9%81-%D8%A7%D9%84%D8%A8%D9%86%D9%83-%D9%85%D9%82%D8%A7%D8%A8%D9%84-%D9%86%D8%B8%D8%A7%D9%85%D9%83/). 5. **اسأل عن البدائل**: لبعض الممرات والمبالغ قد تكون خدمات تحويل مرخصة أرخص وأسرع من السلسلة التقليدية، ولكن قارنها بالتكلفة الكلية، الرسوم والهامش معاً، لا بالرسوم المعلنة وحدها. وإذا كان منتجك نفسه يقدم تحويلات دولية لعملائه، كمحفظة تتيح للعمال إرسال المال لأهلهم، فهذا نشاط منظم يحتاج ترخيصاً من البنك المركزي، وقد ذكرنا أنواع التراخيص ومصادرها في [المحافظ الرقمية: أنواعها وترخيصها](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D8%AD%D8%A7%D9%81%D8%B8-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A%D8%A9-digital-wallets-%D8%A7%D9%86%D9%88%D8%A7%D8%B9%D9%87%D8%A7-%D9%88%D8%AA%D8%B1%D8%AE%D9%8A%D8%B5%D9%87%D8%A7-%D9%88%D9%83%D9%8A%D9%81-%D8%AA%D8%A8%D9%86%D9%8A%D9%87%D8%A7/)، ومعه كل متطلبات القسمين 13 و14 أعلاه، وفحص الأسماء في كل حوالة. ## أخطاء شائعة | الخطأ | لماذا يضر | البديل | | ------------------------------ | ------------------------------------ | --------------------------------------- | | SHA لفاتورة مورد | المورد يستلم أقل ويطالب بالفرق | OUR، أو اتفاق مكتوب على من يتحمل الرسوم | | الحكم بالرسوم المعلنة وحدها | هامش الصرف قد يكون أكبر من الرسوم | التكلفة الكلية: ما دفعته مقابل ما وصل | | الإرسال بعد ظهر الخميس | أربعة أيام في أسوأ حالة في النموذج | الأحد إلى الأربعاء قبل موعد القطع | | «أخرى» في غرض الحوالة | أسئلة وتوقف في الفحص | غرض واضح ورقم فاتورة | | تجاهل UETR | لا تستطيع أن تسأل عن حوالة بعينها | حفظه مع كل حوالة في نظامك | | UETR بأحرف كبيرة | رفضه المخطط في المختبر | حفظه كما هو بأحرف صغيرة | | الثقة في أي رسالة صحيحة الشكل | تواريخ قيمة من 2001 في رسالة من 2019 | فحوص معقولية على التواريخ والمبالغ | | أرقام سمعتها عن رسوم المراسلين | كل بنك يحدد رسومه وعقوده | تعرفة بنكك وعقده، بتاريخها | ## قائمة تحقق قبل أول حوالة دولية | البند | كيف تتحقق منه | | --------------------------- | ----------------------------------------------------- | | أعرف السلسلة إلى بلد المورد | سألت البنك عن المراسل والوسيط المعتادين | | أعرف الرسوم الكلية | تجربة بمبلغ صغير ومقارنة ما خصم بما وصل | | طريقة الرسوم متفق عليها | OUR أو SHA مكتوبة في العقد مع المورد | | مواعيد القطع والعطل معروفة | جدول بمواعيد بنكك وعطل بلد المستفيد | | بيانات المستفيد كاملة | الاسم والعنوان والحساب والغرض كما في الفقرة 14.1 | | UETR محفوظ | كل حوالة في نظامك لها معرفها | | مطابقة يومية | الحوالة في الكشف مطابقة لما في النظام وما أكده المورد | | ترخيص إن كنت تحول لعملائك | مراجعة متطلبات البنك المركزي مع مستشار | ## الخلاصة وصلنا لنهاية الموضوع، وأهم ما فيه: - الحوالة الدولية قيود في دفاتر سلسلة من البنوك المراسلة بحسابات Nostro وVostro، وSWIFT شبكة الرسائل بينها لا ناقل المال. - OUR وSHA وBEN تحدد من يدفع الرسوم، وفي نموذجنا وصل للمورد 9,967 من 10,000 بطريقة SHA، والرسوم الثابتة تساوي 11% من حوالة 500 دولار وأقل من 1% من عشرة آلاف. - الوقت انتظار في الغالب: حوالة الأحد في النموذج احتاجت 43.8 ساعة منها ساعتان ونصف تقريباً معالجة، وحوالة الخميس بعد الظهر قد تحتاج 110.8 ساعة بسبب اختلاف العطل. - تحويل MT103 إلى pacs.008 أعطى رسالة صحيحة بالمخطط، ولكن نصاً قسمته أسطر MT وعنواناً بلا بنية، والمخطط رفض UETR بأحرف كبيرة. - gpi يجعل كل خصم ومحطة مرئية بمعرف واحد، ومثال Swift يبين 1000 تصل 940 في خمس ساعات. - رسمياً أضيفت 54.6% من التحويلات بين البنوك خلال ساعة في 2025 و32.3% في الشرق الأوسط، ومتوسط تكلفة إرسال 200 دولار 6.5% مقابل هدف 3% في 2030. - في المملكة تحمل كل حوالة بيانات المرسل والمستفيد والغرض والعلاقة، ولا تنفذ دونها، وعلاقات المراسلة تحتاج عناية خاصة بحسب المادتين 9 و10 والقسمين 13 و14 من الدليل. والمقالات المرتبطة: [![](https://arabroot.io/content/images/2026/10/payments-clearing-cover-cover.webp)دليلكيف تنتقل الأموال بين البنوك؟ المقاصة Clearing والتسويةماذا يحدث بين ضغطة «ادفع» ووصول المال: الدفع والمقاصة والتسوية الإجمالية والصافية، مع محاكاة يوم من التسويات بين ستة بنوك.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D9%86%D8%AA%D9%82%D9%84-%D8%A7%D9%84%D8%A7%D9%85%D9%88%D8%A7%D9%84-%D8%A8%D9%8A%D9%86-%D8%A7%D9%84%D8%A8%D9%86%D9%88%D9%83-%D8%A7%D9%84%D9%85%D9%82%D8%A7%D8%B5%D8%A9-%D9%88%D8%A7%D9%84%D8%AA%D8%B3%D9%88%D9%8A%D8%A9/)[![](https://arabroot.io/content/images/2026/10/iso8583-iso20022-cover-cover.webp)دليلرسائل البنوك: ISO 8583 للبطاقات وISO 20022 للتحويلاتنفكك رسالة تفويض بطاقة بايتاً بايتاً، ونبني أمر تحويل بأسماء عربية ونتحقق منه بالمخطط الرسمي، ونرى ما يتعطل في كل معيار.](https://arabroot.io/articles/%D8%B1%D8%B3%D8%A7%D8%A6%D9%84-%D8%A7%D9%84%D8%A8%D9%86%D9%88%D9%83-iso-8583-%D9%84%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A7%D8%AA-%D9%88-iso-20022-%D9%84%D9%84%D8%AA%D8%AD%D9%88%D9%8A%D9%84%D8%A7%D8%AA/)[![](https://arabroot.io/content/images/2026/10/saudi-payments-cover-cover.webp)دليلمنظومة المدفوعات في السعودية: سريع وSARIE ومدى وسدادالأنظمة الوطنية للمدفوعات في المملكة كما تصفها مصادر البنك المركزي، وما يعنيه كل نظام للمطور، مع تحليل تقارير نقاط البيع الأسبوعية.](https://arabroot.io/articles/%D9%85%D9%86%D8%B8%D9%88%D9%85%D8%A9-%D8%A7%D9%84%D9%85%D8%AF%D9%81%D9%88%D8%B9%D8%A7%D8%AA-%D9%81%D9%8A-%D8%A7%D9%84%D8%B3%D8%B9%D9%88%D8%AF%D9%8A%D8%A9-%D8%B3%D8%B1%D9%8A%D8%B9-%D9%88-sarie-%D9%88-%D9%85%D8%AF%D9%89-%D9%88-%D8%B3%D8%AF%D8%A7%D8%AF/)[![](https://arabroot.io/content/images/2026/10/kyc-aml-cover-cover.webp)دليلمعرفة العميل KYC وفحص العقوبات بالأسماء العربيةفحصنا عشرين ألف عميل مولد مقابل قائمة مجلس الأمن، ورأينا كم مدرجاً تفوته المطابقة التامة وكم بريئاً تضيفه كل درجة في العتبة.](https://arabroot.io/articles/%D9%85%D8%B9%D8%B1%D9%81%D8%A9-%D8%A7%D9%84%D8%B9%D9%85%D9%8A%D9%84-kyc-%D9%88%D9%81%D8%AD%D8%B5-%D8%A7%D9%84%D8%B9%D9%82%D9%88%D8%A8%D8%A7%D8%AA-%D8%A8%D8%A7%D9%84%D8%A7%D8%B3%D9%85%D8%A7%D8%A1-%D8%A7%D9%84%D8%B9%D8%B1%D8%A8%D9%8A%D8%A9/)[![](https://arabroot.io/content/images/2026/10/reconciliation-cover-cover.webp)دليلالمطابقة Reconciliation: كشف البنك مقابل نظامككيف تقابل كل حركة في كشف البنك بقيد في دفترك على مراحل، ولماذا قد يتساوى الرصيدان وتحتهما دفع مكرر لا يكشفه إلا المرجع.](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D8%B7%D8%A7%D8%A8%D9%82%D8%A9-reconciliation-%D9%83%D8%B4%D9%81-%D8%A7%D9%84%D8%A8%D9%86%D9%83-%D9%85%D9%82%D8%A7%D8%A8%D9%84-%D9%86%D8%B8%D8%A7%D9%85%D9%83/) ## سجل التحديثات - أكتوبر 2026: كتابة المقال وتشغيل النموذج والتحليل على python:3.13.17-slim (lxml 6.0.2 وPyYAML 6.0.3) على رسائل الاختبار في Prowide Core ومخطط pacs.008.001.09 ومثال المتتبع في مواصفة Swift gpi 6.0.1، ومراجعة تقارير مجلس الاستقرار المالي (2015 و2021 و2025) وتقرير CPMI عن العلاقات المراسلة (2016) ونظام مكافحة غسل الأموال ودليل البنك المركزي كما ظهرت في 27 أكتوبر 2026.