كانت بياناتنا المالية سجينة البنوك: كيف حررتها واجهات ‘الصيرفة المفتوحة’ (Open Banking)؟

خليني أحكيلكم قصة صارت معي قبل كم سنة. أنا، زي كثير منكم، عندي حسابات في أكثر من بنك، وبطاقات ائتمان، ومحافظ رقمية… إلخ. في يوم من الأيام، قررت أعمل “جردة” مالية لعائلتي. بدي أعرف وين كل قرش بروح وبيجي، وأعمل ميزانية صح ونخطط للمستقبل. قلت لحالي “شغلة بسيطة، أنا مبرمج وأبو عمر قدها وقدود!”.

وهنا بدأت “وجعة الراس” الحقيقية. دخلت على حسابي في البنك الأول، نزّلت كشف حساب بصيغة PDF. دخلت على الثاني، نزّلت كشف بصيغة Excel بس الأعمدة مختلفة والتنسيق “بجلط”. بطاقة الائتمان قصتها قصة، والمحفظة الرقمية عالم آخر. قضيت يومين كاملين وأنا أحاول أجمع هاي البيانات في مكان واحد، أنظفها، وأوحدها. يا زلمة، شعرت وكأن بياناتي المالية، اللي هي ملكي بالأصل، سجينة في قلاع وحصون متفرقة، وكل قلعة الها حارس وقوانين خاصة فيها. وقتها قلت: “لازم يكون في حل أفضل!”.

هذا الحل، يا جماعة الخير، كان اسمه “الصيرفة المفتوحة” أو الـ Open Banking. وهو ليس مجرد مصطلح تقني معقد، بل هو ثورة حقيقية حررت بياناتنا وأعادت لنا مفاتيح مملكتنا المالية. تعالوا معي في هذه الرحلة لنكتشف كيف حدث ذلك.

ما هي الصيرفة المفتوحة (Open Banking)؟ ببساطة شديدة

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

الصيرفة المفتوحة غيرت هذه القاعدة. هي عبارة عن مجموعة من القوانين والتقنيات التي تُجبر البنوك (بعد موافقتك الصريحة طبعًا) على فتح “نوافذ” آمنة تسمى واجهات برمجة التطبيقات (APIs). هذه النوافذ تسمح لتطبيقات وخدمات أخرى (مرخصة وموثوقة) بالوصول إلى أجزاء محددة من بياناتك المالية، دون أن تحصل هذه التطبيقات أبدًا على مفتاحك السري.

باختصار، أنت تمنح إذنًا محددًا ومؤقتًا لتطبيق ما (مثلاً تطبيق ميزانية) ليقرأ سجل معاملاتك، بدلاً من إعطائه كلمة مرور حسابك البنكي بالكامل. أنت المتحكم.

كيف تعمل الصيرفة المفتوحة من الناحية التقنية؟

كمبرمج، هذا هو الجزء الذي يثير حماسي. “السحر” كله يكمن في تقنيتين أساسيتين: واجهات برمجة التطبيقات (APIs) وبروتوكول التفويض الآمن (OAuth 2.0).

واجهات برمجة التطبيقات (APIs): قلب النظام النابض

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

  • واجهات معلومات الحساب (Account Information Service – AIS): تسمح بقراءة البيانات مثل رصيد الحساب، قائمة المعاملات، وتفاصيل الحساب.
  • واجهات خدمات بدء الدفع (Payment Initiation Service – PIS): تسمح ببدء عملية دفع مباشرة من حسابك البنكي إلى حساب تاجر، كل ذلك من داخل تطبيق التاجر نفسه (وداعًا لإدخال تفاصيل البطاقة في كل مرة!).

بروتوكول OAuth 2.0: حارس بوابة الأمان والموافقة

هذا هو الجزء الأهم للمستخدم. كيف نتأكد أن كل هذا يتم بأمان؟ هنا يأتي دور بروتوكول OAuth 2.0، وهو معيار عالمي لإدارة الموافقات. لنرى كيف يعمل خطوة بخطوة:

  1. أنت في تطبيق طرف ثالث (مثلاً، تطبيق “مصروفي”): تضغط على زر “ربط حسابي البنكي”.
  2. إعادة توجيه آمنة: تطبيق “مصروفي” لا يطلب منك كلمة المرور! بدلاً من ذلك، يقوم بإعادة توجيهك إلى صفحة تسجيل الدخول الرسمية والآمنة الخاصة بالبنك الذي تتعامل معه.
  3. تسجيل الدخول في بيئة البنك: أنت تدخل اسم المستخدم وكلمة المرور الخاصة بك مباشرة على موقع البنك. تطبيق “مصروفي” لا يرى هذه المعلومات أبدًا.
  4. شاشة الموافقة: بعد تسجيل الدخول بنجاح، يعرض عليك البنك شاشة واضحة تسألك: “هل تسمح لتطبيق ‘مصروفي’ بالوصول إلى قائمة معاملاتك ورصيدك لمدة 90 يومًا؟”.
  5. منح الموافقة: عند الموافقة، يقوم البنك بإنشاء “رمز وصول” (Access Token) مؤقت وآمن ويرسله إلى تطبيق “مصروفي”. هذا الرمز هو مفتاح مؤقت يعمل فقط للبيانات التي وافقت عليها وللمدة المحددة.
  6. الوصول للبيانات: يستخدم تطبيق “مصروفي” هذا الرمز للتواصل مع API البنك والحصول على البيانات التي سمحت بها.

هذه العملية تضمن أن كلمة مرورك تظل سرية بينك وبين البنك فقط.

مثال كود (مفاهيمي)

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


import requests
import webbrowser

# الخطوة 1 و 2: توجيه المستخدم لصفحة الموافقة في البنك
# (هذه الروابط تكون من وثائق الـ API الخاصة بالبنك)
CLIENT_ID = "my_app_client_id"
REDIRECT_URI = "https://myapp.com/callback"
AUTHORIZATION_URL = f"https://bank-api.com/oauth/authorize?client_id={CLIENT_ID}&redirect_uri={REDIRECT_URI}&scope=read_transactions"

# افتح المتصفح للمستخدم ليقوم بتسجيل الدخول والموافقة
webbrowser.open(AUTHORIZATION_URL)

# ... المستخدم يقوم بتسجيل الدخول والموافقة ...
# ... البنك يعيد توجيه المستخدم إلى REDIRECT_URI مع authorization_code ...

# الخطوة 5: استبدال الـ authorization_code بـ access_token
# (هذه الخطوة تحدث في الخادم الخلفي لتطبيقك)
def get_access_token(authorization_code):
    TOKEN_URL = "https://bank-api.com/oauth/token"
    payload = {
        "grant_type": "authorization_code",
        "code": authorization_code,
        "client_id": CLIENT_ID,
        "client_secret": "my_app_client_secret", # يجب أن يبقى هذا سريًا جدًا
        "redirect_uri": REDIRECT_URI
    }
    response = requests.post(TOKEN_URL, data=payload)
    return response.json()["access_token"]

# الخطوة 6: استخدام الـ access_token لجلب البيانات
def get_transactions(access_token):
    TRANSACTIONS_API_URL = "https://bank-api.com/v1/transactions"
    headers = {
        "Authorization": f"Bearer {access_token}"
    }
    response = requests.get(TRANSACTIONS_API_URL, headers=headers)
    return response.json()

# مثال على سير العمل
# authorization_code = "الكود الذي نحصل عليه بعد موافقة المستخدم"
# access_token = get_access_token(authorization_code)
# transactions = get_transactions(access_token)
# print(transactions)

هذا الكود يوضح الفكرة الأساسية: فصل تام بين مصادقة المستخدم (التي تحدث في البنك) واستخدام التطبيق للبيانات (الذي يحدث عبر الرمز المؤقت).

ما الذي حررته الصيرفة المفتوحة بالضبط؟

الآن بعد أن فهمنا الآلية، ما هي الثمار التي جنيناها من تحرير هذه البيانات؟

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

  • تمكين الشركات الصغيرة والمستقلين: أصحاب المشاريع الصغيرة يمكنهم ربط حساباتهم البنكية التجارية ببرامج المحاسبة (مثل Xero أو QuickBooks) لمزامنة المعاملات تلقائيًا، مما يوفر ساعات لا تحصى من العمل اليدوي ويتيح لهم التركيز على تنمية أعمالهم.

نصائح من أبو عمر: من واقع الخبرة

بعد العمل على عدة مشاريع في هذا المجال، أحب أن أشارككم بعض النصائح العملية “الزبدة”:

  1. للمطورين: لا تعيد اختراع العجلة! التكامل المباشر مع كل بنك على حدة هو كابوس تقني. استخدم منصات تجميع واجهات برمجة التطبيقات (API Aggregators) مثل Plaid، Tink، Lean، أو Tarabut Gateway (ابحث عن الأفضل والأنسب لمنطقتك). هذه المنصات تقوم بالعمل الصعب وتوفر لك واجهة موحدة للتحدث مع عشرات البنوك.
  2. للمستخدمين: كن واعيًا. الصيرفة المفتوحة آمنة جدًا، لكن الأمان يعتمد أيضًا على سلوكك. اقرأ الأذونات التي تمنحها جيدًا. هل يحتاج تطبيق “لعبة” إلى الوصول لسجل معاملاتك؟ بالطبع لا. تعامل فقط مع التطبيقات الموثوقة ذات السمعة الطيبة.
  3. لأصحاب الأعمال: فكر في “المشكلة” وليس “التقنية”. لا تقل “أريد استخدام الصيرفة المفتوحة”. بل اسأل: “ما هي أكبر مشكلة مالية يواجهها عملائي؟” هل هي صعوبة الدفع؟ هل هي عدم فهمهم لوضعهم المالي؟ ثم انظر كيف يمكن للصيرفة المفتوحة أن تكون جزءًا من الحل لهذه المشكلة الحقيقية.

الخلاصة: استعادة السيطرة 🚀

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

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

أبو عمر

سجل دخولك لعمل نقاش تفاعلي

كافة المحادثات خاصة ولا يتم عرضها على الموقع نهائياً

آراء من النقاشات

لا توجد آراء منشورة بعد. كن أول من يشارك رأيه!

آخر المدونات

الحوسبة السحابية

كنا ندفع ثمن الخوادم الخاملة: كيف أنقذتنا ‘الحوسبة بلا خوادم’ (Serverless) من جحيم التكاليف المهدرة؟

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

21 مايو، 2026 قراءة المزيد
التوسع والأداء العالي والأحمال

كانت طلباتنا تتعثر في أوقات الذروة: كيف أنقذتنا ‘طوابير الرسائل’ (Message Queues) من جحيم الاختناقات؟

أشارككم قصة حقيقية من قلب المعركة البرمجية، كيف كاد تطبيقنا أن ينهار تحت ضغط المستخدمين في يوم إطلاق مهم، وكيف كانت "طوابير الرسائل" (Message Queues)...

21 مايو، 2026 قراءة المزيد
البنية التحتية وإدارة السيرفرات

كانت سجلاتنا متناثرة وضائعة: كيف أنقذنا التجميع المركزي (ELK/Loki) من جحيم تتبع الأخطاء؟

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

21 مايو، 2026 قراءة المزيد
ادارة الفرق والتنمية البشرية

كانت ساحة لتبادل الاتهامات: كيف أنقذتنا ‘ثقافة ما بعد الحوادث عديمة اللوم’ من جحيم الخوف؟

من واقع تجربتي كمبرمج، تحولت اجتماعات مراجعة الحوادث التقنية من جلسات لوم واتهامات إلى بيئة آمنة للتعلم والنمو. في هذه المقالة، أشارككم كيف يمكن لـ...

21 مايو، 2026 قراءة المزيد
اختبارات الاداء والجودة

وداعاً لكابوس “هل كسرنا شيئاً؟”: كيف أنقذ اختبار التراجع البصري واجهاتنا الأمامية

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

21 مايو، 2026 قراءة المزيد
البودكاست