المحافظ الرقمية Digital Wallets: الأنواع والترخيص والبناء

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

المحفظة الرقمية Digital Wallet من أكثر المنتجات المالية التي يطلبها المؤسسون، ومن أكثرها سوء فهم، لأن كلمة «محفظة» تطلق على أشياء مختلفة تماماً: رصيد هدايا داخل متجر واحد، ومحفظة نقود إلكترونية مرخصة، ومحفظة بطاقات مثل Apple Pay، وحساب بنكي بواجهة محفظة. وفي مقال المحفظة الرقمية من الداخل شرحنا القلب التقني لأي محفظة، وهو دفتر القيد المزدوج، وبنيناه على PostgreSQL، فلن نكرره هنا. وهذا المقال عن كل ما حوله: أنواع المحافظ وأيها يحتاج ترخيصاً، وأنواع التراخيص في المملكة ورسومها ورؤوس أموالها من اللائحة التنفيذية لنظام المدفوعات وخدماتها، وحدود الرصيد والمدفوعات لكل مستخدم، وقواعد المحافظ الإلكترونية، وحماية أموال العملاء في حساب منفصل، ثم مختبر يطبق الحدود والمطابقة اليومية، ويبين خطأ صغيراً في الرسوم تكشفه المطابقة من اليوم الأول.

وسوف نناقش في هذا المقال ما يلي:

• أربعة أنواع يسميها الناس «محفظة»، ومن يحتفظ بالمال في كل منها.
• متى تصبح الفكرة نقوداً إلكترونية، ولماذا التكييف القانوني أول خطوة.
• أنواع التراخيص في المملكة ورسومها ورؤوس أموالها وشكلها القانوني من دليل قواعد البنك المركزي.
• حدود الرصيد والمدفوعات لكل مستخدم في المؤسسة الصغرى والكبرى.
• قواعد المحافظ الإلكترونية: الفتح والتحقق والمحافظ الخاملة ومحافظ القاصرين.
• حماية أموال العملاء في الباب السابع من اللائحة.
• كيف تبني المحفظة: المكونات، والشحن والسحب، والمخاطر، ومختبر للحدود والمطابقة.
• الترخيص أم الشريك المرخص، والأخطاء الشائعة، وقائمة تحقق.

ما الذي يسميه الناس «محفظة»؟

قبل أي حديث عن الترخيص أو التقنية، يجب أن يعرف الفريق أي محفظة يقصد، لأن الأنواع الأربعة في الصورة التالية تختلف في السؤال الأهم: من يحتفظ بالمال؟

الرصيد المغلق Closed Loop

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

محفظة النقود الإلكترونية E-money

رصيد مستقل يشحنه العميل بماله، ويدفع منه لتجار مختلفين، ويحول منه لأفراد آخرين، ويسحبه إلى حسابه البنكي. والجهة التي تصدر هذا الرصيد تحتفظ بأموال العملاء، ولذلك تحتاج في المملكة ترخيص مؤسسة نقود إلكترونية Electronic Money Institution من البنك المركزي، كما سنرى. وهذا ما تقصده أغلب الشركات عندما تقول «نريد محفظة»، وهو ما ينطبق عليه أغلب هذا المقال.

محفظة البطاقات Pass-through

محافظ مثل Apple Pay وGoogle Pay وSamsung Pay وmada Pay لا تحتفظ برصيد، وإنما تحفظ نسخة مرمزة Tokenized من بطاقة العميل، وكل دفعة منها عملية بطاقة عادية تمر بالمسار الذي شرحناه في مقال عملية الدفع بالبطاقة، وتذكر صفحة مدى لدى البنك المركزي إضافة بطاقات مدى إلى هذه المحافظ مع الترميز الذي يحفظ سرية بيانات البطاقة. فهذه محفظة لوسائل الدفع، لا للمال نفسه.

الحساب البنكي بواجهة محفظة

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

متى تصبح فكرتك نقوداً إلكترونية؟

عاد المؤسس إلى فكرته بالأسئلة التي يطرحها أي مستشار، وهي ما يجب أن تكتبه قبل أي كود:

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

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

ثلاث صيغ لفكرة الأندية

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

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

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

أنواع التراخيص في المملكة

في صفحة أنواع التراخيص في دليل قواعد البنك المركزي أربعة تراخيص لمقدمي خدمات الدفع: مؤسسة دفع متناهية الصغر Micro Payment Institution، ومؤسسة دفع كبرى Major Payment Institution، ومؤسسة نقود إلكترونية متناهية الصغر Micro Electronic Money Institution للمحافظ الإلكترونية، ومؤسسة نقود إلكترونية كبرى Major Electronic Money Institution للمحافظ الإلكترونية. وفي اللائحة التنفيذية لنظام المدفوعات وخدماتها تفاصيل كل منها، والصورة التالية تجمع الرسوم ورأس المال:

• رسوم الترخيص (المادة 23): 20,000 ريال لمؤسسة الدفع متناهية الصغر، و50,000 ريال لمؤسسة الدفع الكبرى، و20,000 ريال لمؤسسة النقود الإلكترونية متناهية الصغر، و50,000 ريال للكبرى.
• رأس المال المبدئي (المادة 44): مليونا ريال لمؤسسة النقود الإلكترونية متناهية الصغر، وعشرة ملايين ريال للكبرى، وتنص المادة 45 على أن تحتفظ المؤسسة الكبرى بالأعلى بين رأس المال المبدئي و2% من متوسط النقود الإلكترونية القائمة.
• الشكل القانوني (المادة 14): شركة مساهمة لمؤسسة الدفع الكبرى ولمؤسستي النقود الإلكترونية، بينما تسمح لمؤسسة الدفع متناهية الصغر أن تكون شركة مساهمة أو مساهمة مبسطة أو ذات مسؤولية محدودة.
• الاستمرارية (المادة 8): المتقدم لمؤسسة دفع كبرى أو نقود إلكترونية كبرى يقدم خطط استمرارية الأعمال وخطة تصفية منظمة Wind-down.

وهذه الأرقام من النص الإنجليزي للائحة في دليل القواعد بتاريخ اطلاعنا (27 أكتوبر 2026)، والدليل نفسه ينبه إلى أن بعض الوثائق المترجمة قيد المراجعة وأن النص الرسمي هو المعتمد، فارجع إليه وإلى البنك المركزي قبل أي قرار مالي. ولحجم القطاع: ذكر التقرير السنوي الستون أن عدد شركات الدفع المرخصة بنهاية 2023 كان 25، منها 10 تقدم خدمات المحافظ الإلكترونية، وفي إعلان 29 مارس 2026 أصبح عدد الشركات المرخصة لخدمات الدفع 31.

حدود الرصيد والمدفوعات لكل مستخدم

الفرق العملي الأكبر بين مؤسسة النقود الإلكترونية الصغرى والكبرى في الحدود، والمادة 43 من اللائحة تفصلها كما في الصورة التالية:

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

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

ماذا تعني الحدود بالأرقام؟

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

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

قواعد المحافظ الإلكترونية

إلى جانب اللائحة أصدر البنك المركزي قواعد المحافظ الإلكترونية Rules for Electronic Wallets برقم 46025374 بتاريخ 29 أكتوبر 2024، وحالتها في الدليل سارية، وتنص المادة 15 على أن تعمل بها بعد تسعين يوماً تقويمياً من نشرها على موقع البنك المركزي، وأعلنها البنك المركزي في 13 نوفمبر 2024 بعد أن نشر مسودتها لأخذ الآراء. ويذكر الإعلان أنها تضع المتطلبات التنظيمية التي يجب أن تلتزم بها مؤسسات النقود الإلكترونية المرخصة لحماية المشاركين في السوق، وتشمل متطلبات فتح المحافظ، والتحقق من هوية العملاء، وتصنيف المحافظ الخاملة وإدارتها. ومن نصوصها التي تهم المطور:

• الحدود الشهرية (المادة 4(2)): على الشركة أن تتأكد أن العميل لا يتجاوز الحدود المالية التي يضعها البنك المركزي خلال الشهر التقويمي، والأرقام نفسها في اللائحة التنفيذية كما رأينا.
• محافظ القاصرين (المادة 6(2)(د)): البنك المركزي يحدد أحكام تمويلها والحد الأعلى للمدفوعات الشهرية وحدود الرصيد الكلية، فإذا كان منتجك يستهدف الأسر والأبناء فهذا باب مستقل بشروطه.
• المحافظ الخاملة: القواعد تصنفها وتنظم إدارتها، وهذا يعني في النظام حالة للمحفظة وقواعد زمنية تنقلها إليها وإجراءات للتواصل مع العميل، لا مجرد محفظة رصيدها لا يتحرك.

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

المحفظة الخاملة في النظام

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

حماية أموال العملاء: الباب السابع

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

• الحماية فور الاستلام (المادة 93(1)): الأموال المحمية تحمى فور استلامها، في حساب منفصل لدى بنك مرخص أو بطريقة أخرى يقبلها البنك المركزي.
• إذا بقيت بعد يوم العمل التالي (المادة 93(2)): إما أن توضع في حساب منفصل لدى بنك مرخص باسم «إيداع وحماية أموال عملاء مقدم خدمات الدفع» مع اسم المقدم، وإما أن تستثمر في أصول آمنة وسائلة لدى أمين حفظ مصرح له بعد موافقة البنك المركزي.
• شروط الحساب (المادة 93(3)): يستخدم للحماية فقط، ولا توضع فيه الرسوم ولا أموال التشغيل، ويخضع لمطابقة يومية، ولا يفتح ولا يغلق ولا يستبدل ولا يدمج دون خطاب عدم ممانعة من البنك المركزي.
• الملكية عند الإفلاس (المادة 94): لا يكون لأي طرف غير المقدم مصلحة في هذه الأموال، وتعاد إلى المستخدمين إذا أفلس المقدم أو صفي.
• الاستخدام (المادة 69): لا تستخدم مؤسسة النقود الإلكترونية الأموال المحمية لأغراض غير ما تسمح به اللائحة، ومن ذلك الإقراض.

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

المطابقة اليومية في الواقع

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

• فروق التوقيت: العميل شحن ببطاقته الساعة 11 مساء بتوقيت السعودية، فظهر الرصيد في محفظته فوراً، ولكن المبلغ يصل إلى حساب الحماية من مزود الدفع في التسوية اللاحقة، كما شرحنا التسوية في مقال المقاصة والتسوية. وكذلك الدفع للتاجر، قد يقيد في الدفتر اليوم ويخرج من الحساب غداً في دفعة مجمعة. وهذه فروق معروفة، لكل منها سجل يفسره، وتختفي في يوم محدد.
• الفروق غير المفسرة: كل ما بقي بعد طرح فروق التوقيت. وهذا هو الرقم الذي يجب أن يكون صفراً، وأي قيمة غيره تفتح تحقيقاً في نفس اليوم.

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

كيف تبني المحفظة؟ المكونات

بعد التكييف والترخيص، أو بعد اختيار شريك مرخص، تأتي المكونات التقنية، والصورة التالية تجمعها:

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

التحويل بين الأفراد

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

السحب والإغلاق

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

الشحن بالبطاقة ومخاطره

الشحن بالبطاقة أسهل طريق للعميل، ولكنه يحمل خطراً خاصاً بالمحافظ: العميل يشحن ببطاقة، ثم يدفع الرصيد أو يحوله، ثم يعترض صاحب البطاقة الحقيقي على العملية لأنها تمت ببطاقة مسروقة، فيسترد البنك المصدر المبلغ من التاجر، والتاجر هنا هو المحفظة، بعد أن خرج المال منها. وهذا هو الاعتراض Chargeback الذي شرحنا مساره ومهله في مقال عملية الدفع بالبطاقة. ولذلك تضع المحافظ عادة قيوداً داخلية على الشحن الأول من بطاقة جديدة، وتطلب التحقق ثلاثي الأبعاد 3-D Secure، وقد تؤخر السحب من رصيد مصدره شحن حديث. وهذه قيود من سياسة المخاطر لا من اللائحة، فتضعها الشركة أو الشريك المرخص بحسب تجربته، والمهم أن يكون في الدفتر ما يربط كل جزء من الرصيد بمصدره حتى تعرف أي رصيد يمكن سحبه. وفي بيئة الاختبار لا تستخدم إلا بطاقات الاختبار التي ينشرها مزود الدفع، ولا تضع بيانات بطاقة حقيقية في أي ملف أو سجل.

المختبر: الحدود والمطابقة اليومية

المختبر برنامج Python يحاكي شهراً من نشاط محفظة لمؤسسة نقود إلكترونية متناهية الصغر: ثلاثمئة مستخدم، وأربعمئة عملية يومياً بين شحن ودفع، بمبالغ مولدة عشوائياً ببذرة ثابتة لا تمثل أي منتج حقيقي. ويطبق البرنامج حدي المادة 43(1): عشرين ألف ريال رصيداً لكل مستخدم، وعشرين ألف ريال مدفوعات في الشهر، ويحفظ رصيد حساب الحماية بجانب أرصدة المحافظ، ثم يطابق بينهما في نهاية الشهر. والخيار --fee-left-in-safeguard يحاكي خطأ شائعاً: الرسوم تخصم من محفظة العميل، ولكنها لا تنقل من حساب الحماية إلى حساب الشركة. والمبالغ بالهللة:

# wallet.py: per-user limits of a micro e-money institution and the daily safeguarding reconciliation
import sys, random
from collections import defaultdict

HOLD_LIMIT = 20_000_00        # halalas: Art. 43(1)(c), Micro EMI, per user across all accounts
MONTH_LIMIT = 20_000_00       # halalas: Art. 43(1)(d), per user per calendar month, incl. cash-out

balance = defaultdict(int)          # e-money held by each user
month_volume = defaultdict(int)     # payment transactions this month per user
safeguard = 0                       # the separate bank account that must equal all e-money
rejected = defaultdict(int)

def top_up(user, amt):
    global safeguard
    if balance[user] + amt > HOLD_LIMIT:
        rejected["top-up over holding limit"] += 1
        return False
    balance[user] += amt
    safeguard += amt                # money received is protected immediately (Art. 93(1))
    return True

def pay(user, amt, fee=0):
    global safeguard
    if month_volume[user] + amt > MONTH_LIMIT:
        rejected["payment over monthly limit"] += 1
        return False
    if balance[user] < amt + fee:
        rejected["insufficient balance"] += 1
        return False
    balance[user] -= amt + fee
    month_volume[user] += amt
    safeguard -= amt                # paid out to the merchant from the safeguarded account
    if "--fee-left-in-safeguard" in sys.argv:
        pass                        # the bug: the fee stays in the safeguarding account
    else:
        safeguard -= fee            # fees move to the company's own account (Art. 93(3): no fees in it)
    return True

rnd = random.Random(11)
users = [f"u{i:03}" for i in range(300)]
for day in range(1, 31):
    for _ in range(400):
        u = rnd.choice(users)
        if rnd.random() < 0.4:
            top_up(u, rnd.choice([100_00, 500_00, 1_000_00, 5_000_00]))
        else:
            pay(u, rnd.choice([25_00, 99_00, 300_00, 1_200_00, 4_000_00]), fee=rnd.choice([0, 0, 50]))
    if "--daily" in sys.argv and day <= 3:   # the daily reconciliation run after each business day
        diff = safeguard - sum(balance.values())
        print(f"day {day:2}  difference {diff/100:,.2f} SAR", "ok" if diff == 0 else "INVESTIGATE")

held = sum(balance.values())
print(f"users {len(users)}  e-money held {held/100:,.2f} SAR  safeguarding account {safeguard/100:,.2f} SAR")
print("reconciled:" , "yes" if held == safeguard else f"NO, difference {(safeguard-held)/100:,.2f} SAR")
print("max balance:", f"{max(balance.values())/100:,.2f}", " max monthly volume:", f"{max(month_volume.values())/100:,.2f}")
for reason, n in sorted(rejected.items()):
    print(f"rejected: {reason:28} {n}")

وعند تشغيله بالأمر python wallet.py على Python 3.13 سوف يكون المخرج كما يلي:

users 300  e-money held 3,106,893.00 SAR  safeguarding account 3,106,893.00 SAR
reconciled: yes
max balance: 19,925.50  max monthly volume: 19,998.00
rejected: insufficient balance         1303
rejected: payment over monthly limit   278
rejected: top-up over holding limit    177

في الكود والمخرج أعلاه لاحظ التالي:

• مجموع أرصدة المحافظ 3,106,893 ريالاً يساوي رصيد حساب الحماية بالضبط، والمطابقة تقول yes، لأن كل شحن زاد الطرفين معاً، وكل دفع للتاجر نقصهما معاً، والرسوم خرجت من الحساب مع خروجها من المحفظة.
• أعلى رصيد عند أي مستخدم 19,925.50 ريالاً، وأعلى مدفوعات شهرية 19,998 ريالاً، وكلاهما تحت حد العشرين ألفاً، لأن الفحص يحدث قبل تنفيذ العملية لا بعدها.
• رفض النظام 177 شحناً لأنها كانت ستتجاوز حد الرصيد، و278 دفعة لأنها كانت ستتجاوز الحد الشهري، و1,303 دفعة لعدم كفاية الرصيد. وكل رفض من النوعين الأولين يحتاج رسالة واضحة للعميل في التطبيق، لأن «رفضت العملية» دون سبب تجعل العميل يظن أن المحفظة معطلة.
• الحد الشهري يقاس على المدفوعات لا على الشحن، وهذا ما يفعله الكود بزيادة month_volume في pay فقط.

ماذا لو بقيت الرسوم في حساب الحماية؟

الآن نشغل نفس الشهر بالخيار --fee-left-in-safeguard، فتخصم الرسوم من محفظة العميل، ولكنها تبقى في حساب الحماية بدلاً من نقلها إلى حساب الشركة:

users 300  e-money held 3,106,893.00 SAR  safeguarding account 3,107,840.00 SAR
reconciled: NO, difference 947.00 SAR
max balance: 19,925.50  max monthly volume: 19,998.00
rejected: insufficient balance         1303
rejected: payment over monthly limit   278
rejected: top-up over holding limit    177

كل شيء في المخرج مطابق للتشغيل الأول، إلا سطر المطابقة: حساب الحماية أكبر من مجموع الأرصدة بـ 947 ريالاً، وهي الرسوم التي لم تنقل. وقد يبدو الفرق في الاتجاه «الآمن»، فالحساب فيه مال أكثر لا أقل، ولكن المادة 93(3) تنص على ألا توضع الرسوم في حساب الحماية، والفرق يعني أن الدفتر وحساب البنك لم يعودا يصفان الحقيقة نفسها، وأن أي خطأ حقيقي في الاتجاه المعاكس سيختبئ داخل هذا الفرق. وهذا ما يجعل المطابقة اليومية بالقيمة الصفرية للفرق، لا بالعلامة، هي القاعدة: الفرق صفر كل يوم، وإلا فتحقيق. ولاحظ أن هذا الخطأ لا يظهر في أي اختبار للعميل، فرصيد كل عميل صحيح، والتطبيق يعمل، والخطأ كله في المال الذي لا يراه إلا من يطابق.

ماذا يرى العضو عند الرفض؟

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

المطابقة يوماً بيوم

قلنا إن المطابقة تكشف الخطأ من اليوم الأول، فلنتحقق من ذلك بدلاً من افتراضه. الخيار --daily في البرنامج يطابق بعد كل يوم عمل من الأيام الثلاثة الأولى، وشغلناه مع خطأ الرسوم بالأمر python wallet.py --daily --fee-left-in-safeguard، وهذه أول ثلاثة أسطر من المخرج:

day  1  difference 5.00 SAR INVESTIGATE
day  2  difference 13.50 SAR INVESTIGATE
day  3  difference 34.50 SAR INVESTIGATE

الفرق في اليوم الأول خمسة ريالات فقط، أي عشر رسوم بخمسين هللة لكل منها، وهو مبلغ صغير قد يتجاهله أي شخص يقرأ تقريراً لا يطابق إلا بالنسبة المئوية أو يقرب إلى أقرب ألف. ولكن الفرق ينمو كل يوم: 13.50 في اليوم الثاني و34.50 في الثالث، حتى يصل إلى 947 ريالاً في نهاية الشهر. وبدون الخطأ يطبع نفس الخيار difference 0.00 SAR ok في كل يوم. والدرس أن الحد المقبول للفرق غير المفسر صفر هللة، لا «مبلغ صغير»، لأن الخطأ المنهجي يبدأ صغيراً دائماً.

مشكلة ظهرت: عمليتان في نفس اللحظة

عندما راجعنا نتيجة المختبر الأول لاحظنا أن احترام الحدود فيه مضمون لسبب لا يوجد في الواقع: البرنامج ينفذ عملية واحدة في كل لحظة، فلا يمكن أن تمر عمليتان معاً. أما الخادم الحقيقي فيستقبل طلبات متزامنة، والعضو الذي يضغط زر الدفع مرتين، أو يدفع من جواله وساعته في نفس الثانية، يرسل طلبين يقرأ كل منهما الحجم الشهري قبل أن يكتب الآخر. فكتبنا برنامجاً ثانياً صغيراً يحاكي ذلك بخيطين Threads، لعضو دفع هذا الشهر 15,000 ريال، ويرسل دفعتين متزامنتين بأربعة آلاف ريال لكل منهما، والحد عشرون ألفاً:

# race.py: two payments from the same user arrive at the same moment; is the monthly limit still respected?
import sys, threading, time

MONTH_LIMIT = 20_000_00              # halalas, Art. 43(1)(d)
month_volume = {"u001": 15_000_00}   # this user has already paid 15,000 SAR this month
lock = threading.Lock()
accepted = []

def pay(user, amt):
    def check_and_write():
        if month_volume[user] + amt > MONTH_LIMIT:
            return
        time.sleep(0.05)             # the gap between reading and writing: a network call, a slow query
        month_volume[user] += amt
        accepted.append(amt)
    if "--locked" in sys.argv:
        with lock:                   # like SELECT ... FOR UPDATE on the user's row inside one transaction
            check_and_write()
    else:
        check_and_write()

threads = [threading.Thread(target=pay, args=("u001", 4_000_00)) for _ in range(2)]
for t in threads: t.start()
for t in threads: t.join()
print("accepted payments:", len(accepted), " month volume:", f"{month_volume['u001']/100:,.2f}",
      "OVER LIMIT" if month_volume["u001"] > MONTH_LIMIT else "within limit")

تشغيله بالأمر python race.py دون قفل يعطي:

accepted payments: 2  month volume: 23,000.00 OVER LIMIT

وتشغيله بالأمر python race.py --locked يعطي:

accepted payments: 1  month volume: 19,000.00 within limit

في الكود والمخرجين أعلاه لاحظ التالي:

• دون قفل قبل النظام الدفعتين، لأن كل خيط قرأ الحجم 15,000 ورأى أن 19,000 تحت الحد، ثم كتب كل منهما، فأصبح الحجم الشهري 23,000 ريال، فوق الحد التنظيمي بثلاثة آلاف ريال، مع أن الفحص موجود في الكود ويعمل في كل اختبار متسلسل.
• السطر time.sleep(0.05) يمثل الفجوة بين القراءة والكتابة، وهي في النظام الحقيقي استعلام بطيء أو اتصال بخدمة مخاطر، ووجودها هنا يجعل السباق يظهر في كل تشغيل بدلاً من مرة نادرة، ولكنه لا يصنعه.
• مع القفل قبل النظام دفعة واحدة، ورفض الثانية، وبقي الحجم 19,000. والقفل هنا يمثل في قاعدة البيانات قراءة صف العميل بـ SELECT ... FOR UPDATE داخل نفس المعاملة التي تكتب القيد، كما فعلنا مع الرصيد في مقال المحفظة الرقمية من الداخل. والحد مجمع لكل المستخدم، فالقفل يجب أن يكون على صف العميل، لا على صف المحفظة.

ترخيص خاص أم شريك مرخص؟

بعد كل ذلك عاد المؤسس إلى قراره الحقيقي، وأمامه ثلاثة طرق:

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

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

ماذا تطلب من الشريك المرخص؟

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

أخطاء شائعة

قائمة تحقق قبل إطلاق محفظة

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

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• «المحفظة» أربعة منتجات مختلفة، والسؤال الذي يفرق بينها: من يحتفظ بالمال؟ ومحفظة النقود الإلكترونية تحتاج في المملكة ترخيص مؤسسة نقود إلكترونية.
• التراخيص أربعة في دليل القواعد، ورسوم المؤسسة الصغرى والكبرى للنقود الإلكترونية 20,000 و50,000 ريال، ورأس مالها المبدئي مليونان وعشرة ملايين ريال.
• حدود المستخدم في المادة 43: عشرون ألف ريال رصيداً ومدفوعات شهرية في الصغرى، ومئة ألف في الكبرى، وتفحص قبل التنفيذ داخل معاملة القيد.
• قواعد المحافظ الإلكترونية (أكتوبر 2024) تنظم الفتح والتحقق والخمول ومحافظ القاصرين.
• أموال العملاء تحمى فور الاستلام في حساب منفصل، بلا رسوم ولا أموال تشغيل، وبمطابقة يومية، وتعاد للعملاء عند التعثر.
• في المختبر طبقت الحدود 455 رفضاً، وكشفت المطابقة 947 ريالاً من الرسوم بقيت في حساب الحماية، وهو خطأ لا يراه أي عميل.
• وفحص الحد وحده لا يكفي: دفعتان متزامنتان تجاوزتا الحد الشهري إلى 23,000 ريال، والقفل على صف العميل داخل المعاملة أبقاه 19,000.

وبقية مقالات قسم التقنية المالية والمدفوعات:

دليلالمحفظة الرقمية من الداخل: دفتر القيد المزدوج Ledgerكيف تبني محفظة رقمية لا يضيع فيها ريال ولا يخصم مرتين، بالقيد المزدوج والمعاملات والمطابقة مع مزود الدفع.دليلبوابات الدفع Payment Gateways في السعودية والبدائل المفتوحةكيف تختار مزود الدفع في المملكة بما تنشره صفحاتهم الرسمية، وأين يقف Stripe والبرمجيات المفتوحة، مع مختبر التحويل بين مزودين.دليلمنظومة المدفوعات في السعودية: سريع وSARIE ومدى وسدادالأنظمة الوطنية للمدفوعات في المملكة كما تصفها مصادر البنك المركزي، وما يعنيه كل نظام للمطور، مع تحليل تقارير نقاط البيع الأسبوعية.دليلالنظام المصرفي الأساسي Core Banking: البنك من الداخلما الذي يحفظه النظام المصرفي الأساسي وكيف تمر فيه الحركة، ولماذا يعمل بتاريخ عمل ودورة ليلية، مع مختبر لاستحقاق العائد على ألف حساب.دليلالمصرفية المفتوحة Open Banking: إطار البنك المركزي والواجهاتما تتيحه المصرفية المفتوحة في المملكة وما تفرضه لائحتها، والموافقة من الطلب إلى الحذف، مع مختبر لتطبيق يقرأ بموافقة العميل فقط.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، وتشغيل مختبر الحدود والمطابقة اليومية وتجربة الدفعات المتزامنة على Python 3.13.3 ببيانات مولدة، والتحقق من اللائحة التنفيذية لنظام المدفوعات وخدماتها وقواعد المحافظ الإلكترونية في دليل القواعد، وإعلانات البنك المركزي والتقرير السنوي الستين بتاريخ 27 أكتوبر 2026.