MiCA 2.0 سيُحسَم في مسؤولية التشغيل، لا في قواعد الإصدار

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

في تلك اللحظة، يطرح العميل ثلاثة أسئلة: من يلتقط الهاتف؟ من يستطيع الإرجاع؟ من يتحمّل الخسارة؟

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

عندما قدتُ وحدة أعمال متعددة البلدان في المباني الذكية وأتمتة المنازل، لم تكن حياتي تُدار بمواصفات المنتج وحدها. كانت تُدار بالتصعيدات. فحساس يتعطل في الميدان لا يهتم بمخططنا التنظيمي. العميل يريد مالكاً واضحاً، وجدولاً زمنياً، وحلاً. في المدفوعات والنقود المرمّزة، «عطل الميدان» هو تحويل عالق، أو خصم مكرر، أو دفعة on-chain وُجهت خطأ، أو تعرض لطرف خاضع للعقوبات يُكتشف متأخراً. تختلف الميكانيكا؛ والحقيقة التشغيلية واحدة.

«الوسط الفوضوي» هو المنتج

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

• ضوابط التوزيع: من يحق له الإلحاق، والتمويل، والاسترداد، وتحت أي شروط.
• دعم العملاء والشكاوى: الاستقبال، والفرز، والجداول الزمنية، ومسارات التدقيق.
• التعامل مع الاستثناءات: ماذا يحدث عندما يتأخر تحويل، أو تُجمّد أموال، أو يتم وسم طرف مقابل.
• مسارات النزاع: إرجاعات على نمط chargeback، واستردادات جزئية، ومدفوعات أُرسلت للجهة الخاطئة، وما يعادل double-spend في العالم الواقعي.
• توزيع الخسائر: من يدفع عندما لا يمكن استرداد الخطأ.

العميل لا يهتم إن كانت البنية التحتية Stablecoin، أو وديعة مُرمّزة، أو تحويلًا مصرفيًا. ما يهمه أن يكون رصيده صحيحاً وقابلاً للاستخدام، وأن يحصل على دعم، وأن يكون هناك من يعيد النظام إلى حالة صحيحة عندما تكسر الواقع «المسار المثالي» الذي صممته.

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

لا تصبح اللوائح «حقيقية» إلا عندما تكون SLA صريحة

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

التنظيم المالي هو النمط نفسه، لكن المال بدل العتاد. إذا أردت أن تعرف ما إذا كان مخطط النقود المرمّزة متيناً، فاطلب العقد التشغيلي، لا الـwhitepaper.

بوصفي مشغّلاً وعضو مجلس إدارة، سأدفع باتجاه خمس SLAs صريحة عبر السلسلة:

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

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

ولهذا أيضاً كثيراً ما أقول لفرق fintech: ادرسوا استجابة الحوادث في الصناعة. في مصنع، لا «تنتظر وترى» عندما تخرج الحرارة عن النطاق. توقف الخط، اعزل المشكلة، ولا تعيد التشغيل إلا عندما تستطيع إثبات الاستقرار. حركة الأموال تستحق الانضباط نفسه. كتبت عن هذا النموذج الذهني في AI Value Isn’t in the Org Chart. It’s in the Stop Button. المبدأ واحد: سلطة الإيقاف جزء من governance.

مسؤولية التشغيل: احسمها مبكراً، أو سيُحسم الأمر بالنيابة عنك

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

لتفادي ذلك، تحتاج إلى نموذج مسؤولية مُصمم، لا مُستنتج.

أفضّل تأطيره كـRACI بسيطة مع واقع الميزانية العمومية:

• Responsible: من يدير العملية يومياً (الفريق الذي يحرك الروافع فعلاً).
• Accountable: من يوقّع السياسة ويتحمل تبعات فشلها (جهة واحدة لا لجنة).
• Consulted: من يقدم المدخلات (الالتزام، الشركاء البنكيون، تحليلات السلاسل، مزودو مكافحة الاحتيال).
• Informed: من يحتاج إلى الرؤية (المجلس، المنظمون، شركاء التوزيع الرئيسيون).

ثم أضف السؤالين اللذين تتجنب أغلب الفرق مواجهتهما:

• من يملك سلطة الإرجاع أو التعويض عندما لا تدعم البنية التحتية الإرجاع؟
• أين تُمتص الخسارة عندما يصبح الاسترداد مستحيلاً، وكيف يُموَّل ذلك الاحتياطي؟

إذا كنت تبني توزيع stablecoin أو النقود المرمّزة، فأنت عملياً تبني طبقة حماية للمستهلك. يمكنك إنكار ذلك، لكنك ستقوم بالعمل نفسه عندما تتوسع النزاعات.

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

طبقة التحكم بالنزاعات: ابنِها كنظام حقيقي

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

لذا ابنِ طبقة تحكم للنزاعات بشكل صريح. عملياً، يعني ذلك:

1) نموذج أحداث مشترك بين الأطراف

إذا كان لدى الموزّع والمُصدِر ومزوّد المحفظة معرفات معاملات مختلفة، فلن تتمكن من المطابقة بسرعة. تحتاج إلى نموذج مرجعي مشترك يربط: المستخدم، ومصدر التمويل، ومعاملة on-chain، وقيود دفتر خارج السلسلة، والرسوم، وحالة التسوية.

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

2) مسار تصعيد واضح يعبر حدود الشركات

عندما تعبر الحادثة الولايات القضائية، يجب أن يبقى التصعيد «قفزة واحدة»، لا خمسة رسائل بريد واجتماعاً أسبوعياً. عرّف سلم التصعيد، وهيكل on-call، وصلاحيات القرار. إذا لم يُختبر، فهو غير موجود.

3) أنواع نزاعات محددة مسبقاً وPlaybooks

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

4) آلية «مكافئ الإرجاع»

النهائية on-chain لا تلغي الحاجة إلى الإرجاعات؛ بل تغيّر طريقة تنفيذها. تحتاج إلى سياسة وآلية لتعويض العميل: تعديلات على دفتر داخلي، وائتمانات ممولة من الاحتياطي، وclawback حيثما كان ذلك ممكناً قانونياً وتقنياً، ومعايير أهلية صريحة.

هنا يخلط كثيرون بين الهندسة التقنية والهندسة التشغيلية. الهندسة التشغيلية هي ما سيشعر به المنظمون والعملاء.

5) ميزانية أخطاء قابلة للقياس

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

هذا يرتبط بكيف أفكر في طبقات التحكم في المدفوعات. السكة ليست المنتج. طبقة التحكم هي المنتج. إذا كان هذا ينسجم مع رؤيتك، فمقال A Debit Network Is Not a Network. It Is the Checkout Control Plane. يشرح الفكرة نفسها من زاوية أخرى.

ما الذي سأطلبه في غرفة المجلس هذا الربع

إذا كنت عضواً في مجلس إدارة أو مسؤول تشغيل تشرف على توزيع النقود المرمّزة أو stablecoin إلى أوروبا، فلا تبدأ برخصة الإصدار. ابدأ بقابلية التشغيل.

• أرِني خريطة النزاعات: جميع الأطراف، وجميع نقاط التسليم، وأين يمكن أن تتعطل الأموال.
• أرِني جدول المسؤولية: لكل نمط فشل، من يدفع، ومن يقرر، وما الدليل المطلوب.
• أرِني SLAs: الإقرار، التجميد، المطابقة، الائتمان المؤقت، الحل النهائي.
• أرِني زر الإيقاف: من يستطيع إيقاف الإلحاق، أو تعليق الاستردادات، أو وقف قناة توزيع، وتحت أي معايير.
• أرِني حقيقة المطابقة: دفتر قيود مرجعي واحد، وكيف يرتبط بالحسابات البنكية ومعاملات on-chain.
• أرِني كيف تدرب الشركاء: لأن الحلقة الأضعف ستكون طرفاً ثالثاً لديه نص جاهز ولا يمتلك السياق.

إذا كانت الإجابات عامة، فالاستراتيجية ليست «مبكرة». إنها غير مكتملة.

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

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

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

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