حماية الأموال في الممارسة: بنية حسابات النقود الإلكترونية لترخيص EMI

---

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

حماية الأموال هي بنية حسابات، وليست متطلب تقارير يُلحق بالبنية التحتية الموجودة. يجب على دفتر الحسابات أن يمنع هيكليًا الخلط، مزج أموال العملاء مع أموال المؤسسة الخاصة، من خلال أنواع حسابات منفصلة، وعزل مفروض، ورؤية فورية لرصيد الحماية.

المنظمون لا يقبلون "نطابق شهريًا وينجح الأمر دائمًا." يتطلبون أن تمنع البنية الخلط بالتصميم. الفرق مهم أثناء الفحص.

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

دفتر حسابات متوافق مع الحماية يميز أربع فئات حسابات:

المعادلة الأساسية:

Sum(أرصدة نقود إلكترونية للعملاء) ≤ Sum(أرصدة حسابات الحماية) + Sum(أرصدة العائم)

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

عندما يودع عميل 100 يورو:

DEBIT  safeguarding:eur     100.00    (الأصول تزداد، البنك استلم الأموال)
CREDIT customer:alice:eur    100.00    (الالتزامات تزداد، نحن مدينون لأليس بـ 100 يورو)

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

منع الخلط

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

ثلاث آليات معمارية تمنعه:

1. أعلام نوع الحساب في دفتر الحسابات.

كل حساب يحمل نوعًا: customer_emoney، safeguarding، fee_revenue، operating، float. النوع يُضبط عند إنشاء الحساب وهو غير قابل للتغيير. ليس تسمية، بل قيد يؤثر على التحويلات المسموحة.

2. قواعد التحويل المفروضة بطبقة المجال.

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

التسلسل لرسم شهري 2.00 يورو:

Step 1: DEBIT  customer:alice:eur    2.00    (الالتزامات تنقص، أليس مدينة بأقل)
        CREDIT platform:fees:eur     2.00    (الإيرادات تزداد، الرسم مُكتسب)

Step 2: DEBIT  safeguarding:eur      2.00    (الأصول تنقص، الأموال أُفرجت)
        CREDIT operating:eur         2.00    (حقوق الملكية تزداد، أموال المؤسسة الخاصة)

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

3. فحص رصيد الحماية في الوقت الفعلي.

يمكن للنظام إنشاء تقرير حماية في أي لحظة:

Client e-money total:      EUR 1,247,891.23
Safeguarding balance:      EUR 1,198,442.00
Float (pending settlement): EUR   52,100.00
Coverage:                  EUR 1,250,542.00
Surplus:                   EUR     2,650.77   (>0 = متوافق)

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

العائم وتوقيت التسوية

بين بدء الدفع والتسوية، الأموال في العبور. عميل يستقبل خصمًا مباشرًا SEPA: بنك الدائن قدم التحصيل، لكن بنك المدين لم يُسوِّ بعد. الأموال تُضاف لحساب نقود العميل الإلكترونية (الالتزامات تزداد)، لكن الزيادة المقابلة في الأصول تعتمد على دورة التسوية.

خلال هذه النافذة، معادلة الحماية تتضمن العائم:

Client balance:       EUR 100.00    (العميل يرى 100 يورو)
Safeguarding:         EUR   0.00    (البنك لم يستلم الأموال بعد)
Float (SDD pending):  EUR 100.00    (التسوية متوقعة في D+5)
Coverage:             EUR 100.00    (العائم يُحسب ضمن التغطية)

نموذج فترة الاحتفاظ يتتبع هذا بدقة. الأموال في حالة SETTLED_PENDING تُحسب كعائم، مغطاة لأغراض الحماية لكن غير متاحة للعميل بعد. بعد انتهاء فترة الاحتفاظ وانتقال الأموال إلى SETTLED_AVAILABLE، تنتقل من العائم إلى الحماية (البنك يؤكد الاستلام).

إذا حدث إرجاع خلال فترة الاحتفاظ (معاملة R)، يُقلَّص العائم ويُعكس رصيد نقود العميل الإلكترونية. معادلة الحماية تُعاد توازنها تلقائيًا لأن كلا الجانبين يتحركان معًا.

متطلبات التقارير

ترخيص EMI يفرض التزامات تقارير محددة. يجب أن تنتج البنية هذه التقارير من دفتر الحسابات، وليس من قاعدة بيانات تقارير منفصلة، وليس من خط أنابيب ETL، وليس من جدول بيانات.

بيانات كل تقرير تأتي من نفس المصدر: دفتر الحسابات غير القابل للتغيير بالقيد المزدوج. النقود الإلكترونية المستحقة للعملاء هي مجموع جميع أرصدة حسابات customer_emoney (الرصيد الطبيعي دائن). تغطية الحماية هي مجموع جميع أرصدة حسابات safeguarding (الرصيد الطبيعي مدين) زائد أرصدة float. التقرير استعلام، وليس بناء.

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

أعطال الحماية الشائعة

ثلاثة أنماط تنشئ مخاطر حماية:

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

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

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

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

---

اقرأ المزيد: دفتر الحسابات | الأمان والامتثال

---

المصادر:

• EMD2، التوجيه 2009/110/EC، المادة 7 (متطلبات الحماية)، المادة 10 (حماية الأموال)
• PSD3/EMD3، COM/2023/366 (اقتراح دمج PSD2 و EMD2)
• Ley 21/2011 (إسبانيا)، المادة 8-10 (الحماية لمؤسسات EMI الإسبانية)
• BaFin: إرشادات حول متطلبات الحماية لمؤسسات النقود الإلكترونية
• HGB §246، حظر المقاصة (Verrechnungsverbot)، أصول العملاء يجب ألا تُصفَّى مقابل التزامات المؤسسة