من سجون البيانات إلى ثورة التكنولوجيا المالية: قصتي مع الخدمات المصرفية المفتوحة (Open Banking)

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

المشكلة هي إنه عشان تطبيقنا يشتغل، كنا محتاجين بيانات معاملات المستخدمين البنكية. وهون بلشت القصة. البيانات هاي كانت محبوسة جوا بنوكهم، زي كأنها في سجن انفرادي. ما كان فيه طريقة رسمية نوصلها. الحل الوحيد اللي كان قدامنا وقتها هو “كشط الشاشة” (Screen Scraping). يا الله! مجرد ما أتذكر هالكلمة بحس بالقشعريرة.

كنا نطلب من المستخدم يعطينا اسم المستخدم وكلمة السر لحسابه البنكي (إشي مرعب من ناحية أمنية)، وبرنامجنا يدخل “كأنه إنسان” على موقع البنك، يقرأ الأرقام من الشاشة ويخزنها. كان كابوس حقيقي. أي تحديث صغير في واجهة موقع البنك كان يكسر كل إشي عنا. كنا في حرب استنزاف يومية مع البنوك اللي بتغير مواقعها، وكان فريق الدعم الفني عنا بيقضي وقته يحل مشاكل المستخدمين اللي “التطبيق بطل يشتغل عندهم”. حسينا حالنا بنبني قصر من رمل على شط البحر، كل موجة بتهدّ اللي بنيناه. لحد ما في يوم، سمعنا بمصطلح غريب: “PSD2” و “Open Banking”.

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

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

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

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

كيف غيرت الخدمات المصرفية المفتوحة قواعد اللعبة؟

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

من الجزر المنعزلة إلى الشبكة الموحدة

كل بنك كان عبارة عن جزيرة بيانات منعزلة، ولكل جزيرة لغتها وقوانينها الخاصة. مع الـ Open Banking، صار فيه جسور (APIs) بتربط هاي الجزر كلها بشبكة موحدة. صرنا نحكي لغة وحدة مع كل البنوك، وهذا وفّر علينا وقت وجهد خيالي.

الأمان أولاً: وداعاً لكوابيس مشاركة كلمات المرور

أكبر نقلة كانت في الأمان. المستخدم بطل يعطينا كلمة سره. العملية صارت كالتالي:

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

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

بيانات منظمة ونظيفة = قرارات أذكى

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

نظرة تحت الغطاء: كيف تعمل تقنياً؟

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

رحلة طلب البيانات (The Data Request Journey)

العملية بتعتمد بشكل أساسي على بروتوكول OAuth2، وهو معيار عالمي لإدارة الصلاحيات. الرحلة باختصار هي:

• الخطوة 1: المستخدم يطلب ربط الحساب من تطبيقك (Client).
• الخطوة 2: تطبيقك يعيد توجيه المستخدم إلى خادم المصادقة الخاص بالبنك (Authorization Server) مع تحديد الصلاحيات المطلوبة (e.g., `read_transactions`).
• الخطوة 3: المستخدم يسجل دخوله لدى البنك ويوافق على منح الصلاحيات.
• الخطوة 4: البنك يعيد توجيه المستخدم إلى تطبيقك مع رمز مصادقة (Authorization Code).
• الخطوة 5: تطبيقك (من الخادم الخلفي – Backend) يرسل هذا الرمز السري مع بياناته الخاصة إلى البنك، ويستبدله برمز وصول (Access Token).
• الخطوة 6: الآن، تطبيقك يستخدم هذا الـ Access Token لطلب البيانات من خادم الموارد الخاص بالبنك (Resource Server) عبر الـ API.

مثال كود (بسيط): طلب قائمة الحسابات

لنفترض أنك حصلت على `ACCESS_TOKEN` من البنك. لطلب قائمة حسابات المستخدم، كل ما عليك فعله هو إرسال طلب GET إلى نقطة النهاية (endpoint) الخاصة بالحسابات، مع تمرير التوكن في الـ Header.

# مثال باستخدام لغة Python ومكتبة requests

import requests

# هذا التوكن حصلت عليه بعد موافقة المستخدم
ACCESS_TOKEN = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.very_secret_and_temporary_token.abc123def456"

# نقطة النهاية الخاصة بواجهة برمجة تطبيقات البنك
API_ENDPOINT = "https://api.examplebank.com/v1/accounts"

headers = {
    "Authorization": f"Bearer {ACCESS_TOKEN}",
    "Content-Type": "application/json"
}

try:
    response = requests.get(API_ENDPOINT, headers=headers)
    response.raise_for_status()  # يطلق استثناء في حال حدوث خطأ (e.g., 401, 403)

    accounts_data = response.json()
    print("تم جلب الحسابات بنجاح:")
    for account in accounts_data['accounts']:
        print(f"- رقم الحساب: {account['accountId']}, نوع الحساب: {account['accountType']}, الرصيد: {account['balance']['amount']} {account['balance']['currency']}")

except requests.exceptions.HTTPError as err:
    print(f"حدث خطأ في الشبكة: {err}")
except Exception as e:
    print(f"حدث خطأ غير متوقع: {e}")

لاحظوا قديش الكود بسيط ومباشر مقارنة بتعقيدات الـ Screen Scraping. البيانات اللي بترجع بتكون غالباً بصيغة JSON واضحة وسهلة التحليل.

نصائح من “أبو عمر”: دروس من الميدان

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

• لا تبنِ كل شيء بنفسك: في البداية حاولنا نتصل بكل بنك لحال، وكان الموضوع مرهق. اليوم فيه شركات وسيطة (API Aggregators) مثل Plaid, TrueLayer, Yapily بتقدملك API واحد بتتصل من خلاله بمئات البنوك. هم بيعملوا الشغل الصعب، وأنت بتركز على بناء منتجك. اعتبرهم “الجسر” اللي بيوصلك لكل الجزر مرة وحدة.
• افهم التنظيمات والتشريعات: الـ Open Banking مش بس تقنية، هو عالم تحكمه قوانين وتشريعات (مثل PSD2 و GDPR). لازم تفهم هاي القوانين كويس وتعرف شو حقوقك وواجباتك، وخصوصاً فيما يتعلق بخصوصية المستخدم وموافقته.
• تجربة المستخدم هي الملك: عملية طلب الإذن من المستخدم لازم تكون سلسة، واضحة، ومطمئنة. إذا حس المستخدم إنها معقدة أو مخيفة، راح يترك التطبيق فوراً. استثمر في تصميم واجهة مستخدم (UX) ممتازة لهي الرحلة.
• تعامل مع البيانات بمسؤولية: أنت الآن مؤتمن على أثمن بيانات المستخدم. الأمان والخصوصية لازم يكونوا في قمة أولوياتك، مش مجرد بند إضافي.

الخلاصة: المستقبل مفتوح… حرفياً 🚀

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

الانتقال من جحيم الـ Screen Scraping إلى نعيم الـ APIs كان من أهم القرارات اللي أخذناها. إذا كنت بتفكر تبني أي منتج في عالم التكنولوجيا المالية (Fintech)، نصيحتي إلك: ابدأ من حيث انتهى الآخرون. تبنى الـ Open Banking من اليوم الأول، لأنه هو الأساس اللي راح ينبني عليه مستقبل الخدمات المالية كلها. المستقبل مفتوح، والفرص لا حصر لها.