من كشط الشاشة إلى الخدمات المصرفية المفتوحة: كيف أنقذت واجهات الـ API تطبيقاتنا المالية؟

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

ماذا كان السبب؟ أحد أكبر البنوك التي نتعامل معها قرر، في منتصف الليل وبدون سابق إنذار، أن يغير تصميم صفحة تسجيل الدخول في موقعه الإلكتروني. تغيير بسيط، ربما مجرد تحديث لـ “id” حقل اسم المستخدم من user_name إلى login_username. هذا التغيير الطفيف كان كفيلاً بنسف نظامنا بالكامل. لماذا؟ لأن تطبيقنا كان يعتمد على تقنية بدائية وخطيرة تُعرف بـ “كشط الشاشة” (Screen Scraping).

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

“كشط الشاشة” (Screen Scraping): بناء قلاع من رمل

قبل أن نغوص في الحل، دعونا نفهم أصل المشكلة. في الأيام الخوالي للتكنولوجيا المالية (Fintech)، لم تكن البنوك مستعدة لمشاركة بيانات عملائها مع أطراف ثالثة مثلنا، حتى لو كان ذلك بطلب العميل نفسه. لم تكن هناك واجهات برمجية (APIs) رسمية. فماذا فعلنا نحن المبتكرون؟ لجأنا إلى الحيلة الوحيدة المتاحة: “كشط الشاشة”.

ببساطة، “كشط الشاشة” هو عملية بناء “بوت” أو برنامج آلي يقوم بالتالي:

1. يأخذ اسم المستخدم وكلمة المرور من عميلك.
2. يذهب إلى موقع البنك الإلكتروني ويتظاهر بأنه إنسان.
3. يُدخل بيانات الاعتماد في حقول تسجيل الدخول.
4. بعد الدخول، يتصفح صفحات الموقع، ويقرأ شيفرة الـ HTML ليبحث عن معلومات مثل الرصيد، قائمة الحركات المالية، إلخ.
5. يستخرج هذه البيانات ويعيدها إلى تطبيقك.

كانت هذه التقنية ضرورة لا بطل، لكنها كانت كابوساً متعدد الأوجه.

الهشاشة القاتلة (The Fatal Fragility)

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

# مثال توضيحي لكود هش يعتمد على بنية HTML
from bs4 import BeautifulSoup

html_doc = ... # محتوى صفحة البنك بعد تسجيل الدخول
soup = BeautifulSoup(html_doc, 'html.parser')

# هذا الكود سينكسر إذا غير البنك الـ id أو الـ class
balance_span = soup.find('span', {'id': 'account-balance-value-1a2b3c'})
balance = balance_span.text

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

الكابوس الأمني (The Security Nightmare)

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

عبء الصيانة وتجربة المستخدم السيئة

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

الفجر الجديد: ظهور واجهات الخدمات المصرفية المفتوحة (Open Banking APIs)

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

هذه القنوات هي واجهات برمجة التطبيقات (APIs). تخيلها كنادل في مطعم. أنت (المستخدم) لا تحتاج للدخول إلى المطبخ (قاعدة بيانات البنك) لتحصل على طعامك. كل ما عليك هو أن تطلب من النادل (الـ API) ما تريده، وهو سيحضره لك بطريقة منظمة وآمنة.

كيف غيرت اللعبة؟

التحول من “كشط الشاشة” إلى واجهات برمجة التطبيقات كان نقلة نوعية حلت كل المشاكل السابقة دفعة واحدة:

• الأمان أولاً: لم نعد بحاجة لتخزين بيانات اعتماد المستخدمين. إطلاقاً. عملية الربط تتم عبر بروتوكول آمن مثل OAuth2، حيث يقوم تطبيقنا بإعادة توجيه المستخدم إلى صفحة تسجيل الدخول الرسمية للبنك. المستخدم يدخل بياناته في بيئة البنك الموثوقة، ثم يمنح تطبيقنا إذناً محدداً (مثلاً: “السماح بقراءة سجل المعاملات فقط”). بعدها، يعود المستخدم إلى تطبيقنا ومعه “مفتاح” أو “رمز” (Token) مؤقت وآمن نستخدمه لجلب البيانات المسموح بها فقط.
• الموثوقية والاستقرار: وداعاً للهشاشة! البيانات تأتي بصيغة منظمة وموحدة (غالباً JSON)، مصممة ليقرأها الحاسوب وليس الإنسان. لا يهم إذا غير البنك لون زر أو مكان شعار. طالما أن بنية الـ API لم تتغير (وهي لا تتغير إلا بشكل مدروس ومعلن)، فكل شيء يعمل بسلاسة.
• بيانات أغنى وتجربة أفضل: واجهات الـ API لا توفر فقط البيانات التي كنا “نكشطها” بصعوبة، بل تقدم بيانات أكثر تفصيلاً ودقة، مثل تصنيف المعاملات، وبيانات التاجر، وغيرها. هذا يسمح لنا ببناء ميزات أكثر ذكاءً وقوة. كما أن العملية أسرع وأكثر سلاسة للمستخدم.

من النظرية إلى التطبيق: مقارنة بالكود

لنرى الفرق عملياً. بعد التحول إلى Open Banking، أصبح الكود الخاص بنا لجلب البيانات يبدو هكذا:

# مثال توضيحي لكود نظيف ومستقر يستخدم API
import requests

# الـ access_token نحصل عليه بعد موافقة المستخدم عبر OAuth2
headers = {
    'Authorization': 'Bearer [ACCESS_TOKEN_FROM_BANK]',
    'Content-Type': 'application/json'
}

response = requests.get('https://api.somebank.com/v1/accounts/ACC12345/transactions', headers=headers)

if response.status_code == 200:
    transactions = response.json()
    # بيانات نظيفة، منظمة، وموثوقة بصيغة JSON
    # { "transactions": [ { "id": "TXN987", "date": "2023-10-27", ... } ] }
else:
    # التعامل مع الأخطاء بشكل واضح (مثلاً: الرمز منتهي الصلاحية)
    print("Error fetching data:", response.text)

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

نصائح من “أبو عمر” للمطورين وفرق العمل

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

1. لا تخترع العجلة: الربط المباشر مع كل بنك على حدة لا يزال مهمة شاقة. استخدم “مجمّعي الـ API” (API Aggregators) مثل Plaid, TrueLayer, Lean, Tarabut Gateway وغيرهم. هذه الشركات تقوم بالعمل الشاق نيابة عنك، وتوفر لك واجهة برمجة تطبيقات واحدة تتحدث مع مئات البنوك.
2. ركز على تجربة منح الإذن (Consent Journey): اللحظة التي تطلب فيها من المستخدم ربط حسابه البنكي هي لحظة حاسمة. يجب أن تكون الواجهة واضحة، شفافة، وتشرح للمستخدم بدقة ما هي البيانات التي تطلبها ولماذا. الثقة هي عملتك الأغلى.
3. استعد للابتكار الحقيقي: الآن بعد أن تحررت من جحيم صيانة “الكاشطات”، يمكنك أنت وفريقك التركيز على ما يهم حقاً: بناء قيمة حقيقية للمستخدم. فكر في خدمات الدفع المباشر (Payment Initiation)، التحليل المالي الذكي، التوفير الآلي، وغيرها من الخدمات التي أصبحت ممكنة بفضل هذه البنية التحتية الجديدة.
4. الأمان مسؤولية مشتركة: حتى مع Open Banking، أنت لا تزال تتعامل مع بيانات مالية حساسة. تأكد من أن تطبيقاتك وخوادمك آمنة، وقم بتشفير البيانات أثناء النقل والتخزين، واتبع دائماً مبدأ “الحد الأدنى من الامتيازات” (Principle of Least Privilege).

الخلاصة: من جحيم الهشاشة إلى نعيم الموثوقية 😌

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

اليوم، عندما أرى تطبيقنا يعمل بسلاسة، ويربط حسابات المستخدمين في ثوانٍ معدودة وبشكل آمن، أتذكر تلك الليلة الباردة وأبتسم. لقد خرجنا من الظلام إلى النور، ومن بناء قلاع الرمل إلى تشييد جسور من الفولاذ. المستقبل المالي مفتوح، ونحن كمطورين ومبتكرين نقف في قلبه. يلا يا جماعة، الكود بستنّانا!