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

يا جماعة الخير، السلام عليكم ورحمة الله.

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

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

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

ما هي “الخدمات المصرفية المفتوحة” (Open Banking)؟

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

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

الجميل في الأمر أنك لا تشارك كلمة المرور الخاصة بحسابك البنكي أبدًا. العملية كلها تتم عبر بروتوكولات آمنة مثل OAuth 2.0، حيث يتم توجيهك إلى صفحة تسجيل الدخول الخاصة بالبنك نفسه لتأكيد هويتك وإعطاء الموافقة. أنت دائمًا في موقع السيطرة.

كيف أنقذتني واجهات Open Banking من بناء كل شيء من الصفر؟

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

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

لو لم تكن هذه التقنية موجودة، كانت خياراتنا محدودة ومؤلمة:

• الكشط الشبكي (Web Scraping): كتابة “بوتات” تقوم بتسجيل الدخول إلى موقع البنك نيابة عن المستخدم و”تكشط” البيانات من صفحات الويب. هذه الطريقة هشة جدًا (أي تغيير في تصميم الموقع يكسرها)، وبطيئة، وتثير كوابيس أمنية وقانونية.
• التحميل اليدوي (Manual Upload): كما ذكرت في القصة، الاعتماد على المستخدم لتحميل ملفات CSV أو Excel. هذه تجربة مستخدم سيئة للغاية وتؤدي إلى هجر المستخدمين للتطبيق بسرعة.
• التكامل المباشر مع كل بنك: محاولة عقد شراكات فردية مع كل بنك لبناء تكامل مخصص. هذه العملية تستغرق شهورًا أو حتى سنوات لكل بنك، وتتطلب تكاليف باهظة وموافقات لا تنتهي. تخيل أن عليك فعل هذا مع 10 أو 20 بنكًا! مستحيل لشركة ناشئة.

السيناريو الحلم: مع الخدمات المصرفية المفتوحة

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

هؤلاء المزودون (مثل Plaid, TrueLayer, Tarabut Gateway وغيرهم) قاموا بالفعل بالعمل الشاق: لقد بنوا الجسور مع مئات البنوك حول العالم. مهمتي كمطور أصبحت أبسط بكثير:

1. الربط مع واجهة برمجية (API) واحدة فقط، وهي واجهة المجمّع.
2. المجمّع يتولى التعامل مع تعقيدات كل بنك على حدة.
3. أحصل على البيانات بتنسيق موحد وجميل (عادةً JSON)، بغض النظر عن البنك الذي أتت منه.

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

نظرة تقنية: كيف تعمل واجهات Open Banking؟

دعونا نغوص في التفاصيل التقنية قليلًا. العملية عادةً ما تتبع تدفقًا قياسيًا وآمنًا.

خطوات الربط الأساسية (The Flow)

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

مثال كود (بايثون): جلب بيانات الحساب

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

import requests
import json

# هذا التوكن تحصل عليه بعد أن يوافق المستخدم على الربط
ACCESS_TOKEN = "user_access_token_from_provider" 
# هذا المعرف تحصل عليه بعد جلب قائمة حسابات المستخدم
ACCOUNT_ID = "account_id_for_a_specific_user_account"

# عنوان الـ API الخاص بمزود الخدمة (يختلف من مزود لآخر)
API_ENDPOINT = f"https://api.provider.com/v1/accounts/{ACCOUNT_ID}/transactions"

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

# إرسال طلب GET لجلب المعاملات
response = requests.get(API_ENDPOINT, headers=headers)

if response.status_code == 200:
    # إذا كان الطلب ناجحًا، قم بطباعة البيانات
    transactions = response.json()
    print(json.dumps(transactions, indent=2, ensure_ascii=False))
else:
    # إذا فشل الطلب، اظهر رسالة خطأ
    print(f"Error: {response.status_code}")
    print(response.text)

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

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

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

• بدء المدفوعات (Payment Initiation – PISP): تخيل أن تطبيقك يمكنه مساعدة المستخدم على دفع فاتورة مباشرة من حسابه البنكي بنقرة زر، دون الحاجة لفتح تطبيق البنك أو إدخال تفاصيل بطاقة.
• التحقق من الهوية (KYC): استخدام بيانات الحساب البنكي الموثوقة لتأكيد هوية المستخدم وعنوانه، مما يسرّع عمليات التسجيل في الخدمات المالية.
• تقييم الجدارة الائتمانية: بناء نماذج ائتمان أكثر دقة وعدالة من خلال تحليل الدخل الحقيقي والإنفاق، بدلًا من الاعتماد فقط على التاريخ الائتماني التقليدي.
• منتجات مالية مخصصة: تقديم عروض قروض أو استثمارات أو تأمين مصممة خصيصًا لتناسب الوضع المالي الحقيقي للمستخدم.

نصائح من خبرتي (من أبو عمر إلكم)

إذا كنت تفكر في بناء منتج يعتمد على هذه التقنية، اسمح لي أن أقدم لك بعض النصائح العملية من تجربتي:

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

الخلاصة: البيانات لم تعد سجينة 🗝️

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

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