عندما ينصحك البنك بحماية بياناتك، بينما ينتظر العميل إجابة عن بياناتٍ يقول إنها خرجت من تحت مظلته
هناك منشورات مصرفية تمرّ على القارئ مرور الكرام.
وهناك منشورات تجعلك تتوقف قليلًا، وتقرأها مرة ثانية، ثم تبتسم ابتسامة لا علاقة لها بالمحتوى الذي أراد كاتب المنشور أن يوصله.
ومن بين هذه المنشورات، ظهر حديث بنك الرياض تحت وسم:
#ثمّن_بياناتك 🔐
وجاءت الرسالة واضحة:
لا تمنح المحتالين فرصة للوصول إلى بياناتك، وحمّل تطبيقاتك من مصادرها الموثوقة فقط.
نصيحة لا يختلف عليها عاقل.
بل هي من أبجديات الأمن السيبراني وحماية البيانات: لا تشارك بياناتك، لا تمنح أحدًا رموز التحقق، لا تستخدم مصادر غير موثوقة، وانتبه لمحاولات الاحتيال.
لكن اسمحوا لي أن أطرح سؤالًا صغيرًا، بحجم منشور البنك نفسه:
ماذا لو أن العميل فعل كل ما طُلب منه؟
ماذا لو لم يمنح المحتال بياناته؟
ماذا لو لم يضغط على رابط مشبوه؟
ماذا لو لم يسلّم كلمة المرور لأحد؟
ماذا لو كانت المشكلة التي يواجهها العميل ليست في هاتفه أصلًا، وإنما في البيانات التي يفترض أنها محفوظة داخل الأنظمة المصرفية؟
هنا تبدأ الحكاية الحقيقية.
«دود الخلّ منو فيه»
يقول المثل الفلسطيني:
«دود الخلّ منو فيه».
وهو مثل شعبي لا يحتاج إلى كثير من الشرح.
فأحيانًا لا تكون المشكلة في الخارج، ولا يكون الخطر قادمًا من المحتال الذي يختبئ خلف شاشة مجهولة.
أحيانًا يكون السؤال الأصعب:
هل كل البيانات التي دخلت إلى النظام بقيت صحيحة داخله؟
وهذا سؤال مختلف تمامًا عن السؤال الذي يوجهه البنك إلى العميل:
هل أعطيت بياناتك لأحد؟
لأن العميل يستطيع أن يحمي هاتفه.
لكنه لا يستطيع أن يحرس خوادم البنك.
ولا يستطيع أن يراقب قواعد بياناته.
ولا يستطيع أن يفتش سجلات العمليات.
ولا يستطيع أن يعرف ماذا حدث للبيانات بعد أن أصبحت داخل النظام المصرفي.
تلك مسؤولية أخرى.
مسؤولية الجهة التي ائتمنها العميل على بياناته.
والمفارقة تبدأ من هنا
في مايو 2025، تلقيت رسائل نصية مصرفية مرتبطة بمعاملات على بطاقاتي الائتمانية لدى Amazon.com (US).
الرسائل موجودة.
والواقعة ليست حكاية أرويها من الذاكرة.
لكن عند الانتقال من الرسائل إلى البيان المصرفي الرسمي، ظهرت مشكلة جوهرية في البيانات التي يفترض أن تمثل المعاملات ذاتها؛ ومن بينها غياب التواريخ التي كانت ظاهرة في الإشعارات.
وهنا، بالنسبة لي، لم يعد السؤال:
كيف أحمي بطاقتي من المحتال؟
فهذا السؤال يأتي في مرحلة سابقة.
السؤال أصبح:
كيف ظهرت هذه المعلومة في النظام المصرفي أصلًا؟
ثم:
لماذا تظهر في قناة مصرفية وتغيب أو تختلف في قناة مصرفية أخرى؟
ثم السؤال الأكثر أهمية:
أي السجلات هو السجل الذي يمكن الوثوق به؟
وهذه ليست أسئلة فلسفية.
إنها أسئلة تقنية ومصرفية بامتياز.
الرسالة النصية ليست تغريدة
هناك فارق كبير بين منشور على وسائل التواصل الاجتماعي وبين إشعار مصرفي يصدر عن نظام مصرفي.
التغريدة يمكن تعديلها.
يمكن حذفها.
يمكن إعادة صياغتها.
أما السجل المالي، فالمفترض أن يكون جزءًا من منظومة محاسبية ورقمية قابلة للتتبع.
فعندما يرسل نظام مصرفي إشعارًا للعميل بعملية معينة، فإن ذلك يفترض وجود سلسلة تقنية وراء هذا الإشعار:
- عملية.
- سجل.
- وقت.
- معرف.
- نظام مصدر.
- معالجة.
- إرسال.
- ثم أثر رقمي يمكن الرجوع إليه.
ومن هنا تصبح المسألة أكثر عمقًا من مجرد:
«وصلتني رسالة».
لأن السؤال الحقيقي هو:
ما المصدر الذي أنتج الرسالة؟
وما البيانات التي اعتمد عليها؟
وماذا كان موجودًا في السجل في اللحظة نفسها؟
وهل بقيت هذه البيانات متسقة عندما جرى استخراج البيان الرسمي؟
ثم تأتي العبارة الجميلة: «ثمّن بياناتك»
لا أختلف مع البنك.
بل أتفق معه تمامًا.
البيانات ثمينة.
ثمينة جدًا.
لكن إذا كانت البيانات ثمينة إلى هذه الدرجة، فإن السؤال المنطقي التالي يصبح:
من المسؤول عن حمايتها بعد أن يسلّمها العميل للبنك؟
لأن العلاقة لا تنتهي عند باب التطبيق.
العميل ليس مسؤولًا عن كل شيء.
هو مسؤول عن حماية ما يقع تحت سيطرته.
لكن البنك مسؤول عن حماية ما يقع تحت سيطرته هو.
والخلط بين المسؤوليتين يخلق مشكلة خطيرة:
أن يتحول خطاب الأمن السيبراني من منظومة حماية مشتركة إلى رسالة تُحمّل العميل مسؤولية كل شيء، حتى الأشياء التي لا يستطيع الوصول إليها أصلًا.
العميل يستطيع حماية كلمة المرور… لكنه لا يستطيع حماية قاعدة البيانات
هذه الحقيقة وحدها تكفي لإعادة قراءة كثير من الحملات التوعوية.
قل للعميل:
لا تعطِ كلمة المرور لأحد.
سأفعل.
لا تشارك رمز التحقق.
سأفعل.
لا تدخل بيانات بطاقتك في مواقع مجهولة.
سأفعل.
لا تضغط على الروابط المشبوهة.
لن أفعل.
لكن عندما أضع بياناتي لدى البنك، لا أستطيع أن أقول:
«سأجلس الليلة لأراقب سجلات الخادم وأتأكد من سلامة قاعدة البيانات».
لأنني ببساطة لا أملك الخادم.
ولا أملك قاعدة البيانات.
ولا أملك سجلات النظام.
ولا أملك أدوات التدقيق الداخلية.
ولا أملك القدرة على إعادة بناء سلسلة العملية من المصدر.
وهنا تحديدًا تظهر أهمية الثقة.
الثقة المصرفية ليست شعارًا
الثقة في المؤسسة المالية لا تُبنى بكثرة المنشورات.
ولا بعدد الهاشتاقات.
ولا بجمال تصميم حملة توعوية.
ولا بعدد الجوائز.
الثقة تُبنى عندما يستطيع العميل، عند حدوث خلاف، أن يطرح سؤالًا صعبًا ويحصل على إجابة يمكن التحقق منها.
أين حدثت العملية؟
متى حدثت؟
متى سُجلت؟
ما النظام الذي أنشأها؟
ما السجل الأصلي؟
ما رقمها المرجعي؟
ما الذي أُرسل إلى العميل؟
وما الذي ظهر في البيان الرسمي؟
وإذا اختلفت البيانات، فأين وقع الاختلاف؟
هذه الأسئلة لا تحتاج إلى حملة إعلانية.
تحتاج إلى سجل تقني سليم.
لا أطلب من البنك أن يصدقني
وهنا أقولها بوضوح:
أنا لا أطلب من بنك الرياض أن يأخذ كلامي على أنه حقيقة لمجرد أنني قلتها.
على العكس.
أنا أطلب شيئًا أكثر صعوبة وأكثر عدلًا:
لا تصدقني.
افحص السجلات.
لا تعتمد على روايتي.
راجع الأنظمة.
لا تدخل في جدل طويل معي.
أظهر الأثر الرقمي للعملية.
فإذا كان البنك يملك السجل الذي يحسم المسألة، فليكن السجل هو الحكم.
وهذه، في رأيي، هي الطريقة المهنية الوحيدة للتعامل مع مثل هذه الوقائع.
لأن البيانات لا تحتاج إلى محامٍ
البيانات الصحيحة لا تحتاج إلى خطبة دفاعية.
إذا كانت العملية حدثت في تاريخ محدد، فالسجل يعرف.
إذا أُرسلت الرسالة في وقت محدد، فالنظام يعرف.
إذا أُنشئت العملية عبر قناة معينة، فالنظام يعرف.
إذا انتقلت البيانات بين نظامين، فالأثر التقني يفترض أن يعرف.
وإذا حدث اختلاف بين مصدرين، فالمفترض أن تكون هناك طريقة لتحديد مكان الاختلاف.
لهذا لا أبحث عن رواية أجمل.
أبحث عن السجل.
وهنا تعود كرة «ثمّن بياناتك» إلى ملعب البنك
عندما يقول بنك الرياض:
#ثمّن_بياناتك
أقول:
نعم.
ثمّن بياناتك.
واحفظها.
ولا تسمح للمحتالين بالوصول إليها.
لكن أضيف، بكل احترام:
وثمّن أنت أيضًا البيانات التي ائتمنك العميل عليها.
احفظها.
راقب سلامتها.
اضبط الوصول إليها.
احتفظ بسجلاتها.
واجعلها قابلة للتتبع.
وعندما يقول العميل إن هناك اختلافًا بين معلومة وصلته من نظامك ومعلومة ظهرت في مستند رسمي صادر منك، فلا تجعل أول رد فعل هو إعادة نشر نصائح الاحتيال.
افتح السجل.
فربما تكون الإجابة هناك.
السؤال الذي لا تجيب عنه الحملات التوعوية
هناك فرق بين حماية البيانات وإثبات سلامة البيانات.
الأولى تتعلق بمنع الوصول غير المصرح به.
أما الثانية فتتعلق بقدرة المؤسسة على إثبات أن البيانات التي تحتفظ بها لم تتعرض للعبث أو الفقد أو التغيير، وأن السجل الذي تقدمه اليوم يعكس السجل الذي أنشأته الأنظمة وقت حدوث الواقعة.
وهنا تظهر أهمية ما يسمى في عالم التقنية بـ سلامة البيانات.
فليس كافيًا أن تقول المؤسسة:
«لدينا البيانات».
السؤال الأهم:
هل تستطيع إثبات أن هذه هي البيانات الأصلية، وأنها ظلت متسقة وقابلة للتتبع؟
وفي النزاعات المالية، هذه ليست رفاهية تقنية.
إنها جوهر المسألة.
ماذا نريد إذن؟
لا نريد معجزة.
ولا نريد اعتذارًا إنشائيًا.
ولا نريد منشورًا آخر يحذر العملاء من المحتالين.
نريد إجابات محددة.
نريد معرفة مصدر البيانات.
نريد معرفة تاريخ ووقت إنشاء العملية.
نريد معرفة النظام الذي أنشأ السجل.
نريد معرفة العلاقة بين السجل والرسالة النصية.
نريد معرفة سبب الاختلاف، إن كان هناك اختلاف.
ونريد معرفة ما إذا كانت السجلات التقنية الأصلية لا تزال محفوظة وقابلة للفحص.
بمعنى آخر:
نريد أن ننتقل من الرواية إلى الدليل.
ومن هنا تبدأ المسؤولية الحقيقية
حين يكون العميل وحده أمام المؤسسة، يمكن أن يتحول النزاع بسهولة إلى:
البنك يقول شيئًا، والعميل يقول شيئًا آخر.
وهذه معادلة عقيمة.
لأن الحقيقة لا ينبغي أن تكون مسابقة في البلاغة.
ولا مسابقة في قوة النفوذ.
ولا مسابقة في قدرة أحد الطرفين على كتابة رد أطول.
الحقيقة يجب أن تكون قابلة للاستخراج من السجلات.
ولهذا فإن السؤال الذي ينبغي أن يفرض نفسه في أي نزاع يتعلق بالبيانات المصرفية هو:
أين الدليل التقني؟
فإذا كان موجودًا، فليتحدث.
وإذا لم يكن موجودًا، فهذه بحد ذاتها مسألة تستحق أن تُطرح.
لا أحد فوق السؤال
قد يقول قائل:
«لماذا كل هذا التدقيق؟ إنها مجرد معاملات وبضع رسائل نصية.»
وهنا تحديدًا تكمن المشكلة.
لأن البيانات المصرفية ليست «مجرد بيانات».
وراء كل رقم أثر مالي.
وراء كل تاريخ تسلسل زمني.
وراء كل إشعار نظام أرسل المعلومة.
وراء كل كشف رسمي نظام آخر يعرضها.
وعندما يحدث اختلاف بين هذه الطبقات، فإن السؤال لا ينبغي أن يكون:
لماذا يصر العميل؟
بل:
لماذا اختلفت البيانات؟
ثم:
هل يمكن إثبات سبب الاختلاف؟
وربما يكون أجمل رد على «ثمّن بياناتك» هو سؤال آخر
أقول لبنك الرياض:
شكرًا على النصيحة.
سأثمّن بياناتي.
لكن اسمح لي أن أسألك:
هل تستطيع أن تثبت لي أنك ثمّنت بياناتي أيضًا؟
لأن حماية البيانات ليست مجرد منع المحتال من سرقتها.
إنها كذلك حماية سلامتها.
وحماية سريتها.
وحماية دقتها.
وحماية سجلاتها.
والقدرة على تتبع ما حدث لها.
الخلاصة: البيانات ثمينة على الجانبين
أوافق بنك الرياض تمامًا:
ثمّن بياناتك.
لكنني أضيف:
وثمّن البنك بيانات عملائه.
فالعميل عندما يضع بياناته لدى مؤسسة مالية، لا يضعها في فراغ.
إنه يضعها في نظام يفترض أن يكون أكثر قدرة منه على حمايتها وحفظها وتتبعها.
وعندما تظهر مشكلة، لا ينبغي أن يتحول العميل فجأة إلى مسؤول أمن سيبراني مطالب بإثبات ما حدث داخل أنظمة لا يملكها ولا يستطيع الوصول إليها.
هو يملك ما يملكه:
إشعارًا، ومستندًا، وتاريخًا، وواقعة.
أما المؤسسة، فمن المفترض أن تملك ما هو أكثر:
السجلات الأصلية، والأثر التقني، وسجل العمليات، وأنظمة التدقيق، والقدرة على تفسير ما حدث.
ولهذا فإنني لا أطالب بنك الرياض بأن يصدق روايتي.
بل أطلب منه العكس تمامًا:
لا تصدقني.
افحص السجلات.
إذا أثبتت السجلات أنني مخطئ، فليكن.
وسأقبل النتيجة.
أما إذا أثبتت السجلات أن هناك خللًا أو اختلافًا أو فجوة في البيانات، فحينها لا ينبغي أن يكون السؤال:
«لماذا لم تحمِ بياناتك؟»
بل:
«كيف حدث ذلك، وكيف نضمن ألا يتكرر؟»
وأخيرًا…
ربما كان اختيار بنك الرياض لعبارة:
#ثمّن_بياناتك 🔐
اختيارًا موفقًا جدًا.
لكنني أعتقد أن للعبارة نصفًا آخر لا يقل أهمية:
ثمّن بياناتك… وثمّن الأمانة التي وضعها العميل بين يديك.
فالعميل يعرف أن بياناته ثمينة.
ولهذا سلّمها إلى مؤسسة مالية.
والثقة التي منحها لها ليست رقمًا في كشف حساب.
إنها أمانة.
وعندما يقع خلاف حول تلك الأمانة، لا نحتاج إلى المزيد من الشعارات.
نحتاج إلى السجلات.
ولا نحتاج إلى مزيد من التحذيرات من المحتالين.
نحتاج إلى معرفة ما حدث داخل الأنظمة.
ولا نحتاج إلى روايتين متعارضتين.
نحتاج إلى حقيقة واحدة يمكن إثباتها.
أما المثل الفلسطيني، فليظل حاضرًا في الهامش:
«دود الخلّ منو فيه.»
ولا أحد يقول إن البنك هو «الدود»؛ فذلك اتهام لا أحتاج إليه.
أنا أقول شيئًا أبسط وأقوى:
إذا كانت البيانات قد دخلت إلى النظام، فدعونا نسأل النظام: ماذا حدث لها؟
ففي النهاية…
البيانات لا تتحدث، لكن السجلات تتحدث عنها.