من دفتر الذكريات: ليلة إطلاق “مصروفي”
أذكرها وكأنها البارحة، تلك الليلة في شتاء 2018. كنت قد أمضيت شهوراً طويلة في بناء تطبيقي الأول لإدارة المصاريف الشخصية، والذي أطلقت عليه اسم “مصروفي”. الفكرة كانت بسيطة: أداة تساعد الناس على تتبع نفقاتهم وفهم أين يذهب “الراتب آخر الشهر”. كنت متحمساً جداً، يا جماعة، شعور المبرمج وهو يرى فكرته تتحول إلى كود ثم إلى تطبيق حي على الهاتف لا يضاهيه شعور.
أطلقت التطبيق، وبدأ الأصدقاء والعائلة في تحميله. جاءتني أولى ردود الفعل: “حلو التطبيق يا أبو عمر، بس والله وجعة راس أدخل كل عملية شراء بعملها!”، “فكرة ممتازة، بس لو يسحب البيانات من البنك لحاله بكون إشي خرافي!”.
كانوا على حق تماماً. تطبيقي كان عبارة عن جزيرة جميلة، لكنها معزولة تماماً عن محيطها المالي. كان يعتمد كلياً على المستخدم لإدخال كل صغيرة وكبيرة يدوياً. وهذه، كما تعلمون، وصفة مؤكدة لفشل أي تطبيق مالي. من لديه الوقت أو الصبر ليفعل ذلك يومياً؟ بدأت أبحث عن حلول. الحل الأول الذي قفز إلى ذهني كان الكشط (Screen Scraping)، وهو أن أطلب من المستخدم اسم المستخدم وكلمة المرور الخاصة بحسابه البنكي، ثم يقوم “بوت” في الخلفية بتسجيل الدخول إلى موقع البنك وكشط البيانات من صفحة الويب. مجرد التفكير في هذا الحل أصابني بالقشعريرة. إنه كابوس أمني، غير موثوق إطلاقاً (فأي تغيير بسيط في تصميم موقع البنك سيكسر كل شيء)، وبصراحة، “شغلة مش نظيفة” وغير أخلاقية.
شعرت بالإحباط الشديد وكدت أن أتخلى عن المشروع بأكمله. إلى أن صادفت في إحدى المدونات التقنية مصطلحاً غير حياتي المهنية: “Open Banking”.
ما هي حكاية “الخدمات المصرفية المفتوحة” (Open Banking)؟
القصة وما فيها، يا جماعة، أن المنظمين الماليين حول العالم (وبدأ الأمر بشكل كبير مع تشريع PSD2 في أوروبا) أدركوا أن البنوك تحتكر بيانات العملاء. فقرروا إلزام البنوك بتوفير طريقة آمنة وموحدة تسمح للعملاء بمشاركة بياناتهم المالية مع أطراف ثالثة (مثل تطبيقي “مصروفي”)، ولكن بشرط أساسي ومهم جداً: بموافقة العميل الصريحة والواعية.
تخيلها هكذا: بدلاً من إعطاء مفتاح بيتك بالكامل (اسم المستخدم وكلمة المرور) لشركة تنظيف، أنت تعطيها بطاقة دخول ذكية تسمح لها فقط بدخول غرفة المعيشة (بيانات الحساب)، في أوقات محددة (صلاحية مؤقتة)، ويمكنك إلغاء هذه البطاقة في أي وقت. هذا بالضبط هو جوهر الخدمات المصرفية المفتوحة. إنها لا تعني أن بياناتك أصبحت “مفتوحة” للجميع، بل تعني أنك أنت، كصاحب للبيانات، أصبحت تملك “مفاتيح” بياناتك ويمكنك منح وصول آمن ومقنن لمن تشاء.
الواجهات البرمجية (APIs): الجسر الذي يربط الجزر
كيف يتم كل هذا السحر؟ عبر ما نسميه نحن المبرمجين واجهات برمجة التطبيقات (APIs). البنك يقوم ببناء “جسر” برمجي (API) آمن. وعندما يوافق المستخدم في تطبيقي على ربط حسابه البنكي، يقوم تطبيقي باستخدام هذا الجسر لطلب البيانات بشكل منظم وآمن، دون الحاجة أبداً للاطلاع على معلومات الدخول السرية للمستخدم.
هذا الأمر حول تطبيقي من جزيرة معزولة إلى مركز متصل وحيوي. فجأة، أصبح بإمكان المستخدمين ربط حساباتهم البنكية بنقرة زر، ليروا جميع معاملاتهم مصنفة ومرتبة تلقائياً. لقد كانت نقلة نوعية حقيقية.
من جحيم الكشط اليدوي إلى نعيم الـ APIs
دعوني أضع لكم مقارنة بسيطة لتتضح الصورة أكثر بين الطريقة القديمة (الكشط) والطريقة الحديثة (APIs).
كابوس الكشط (Screen Scraping)
- غير آمن: يتطلب تخزين بيانات الدخول الحساسة للمستخدم، وهذا يجعلك هدفاً كبيراً للمخترقين ومسؤولية قانونية ضخمة.
- غير موثوق: أي تحديث لواجهة موقع البنك الإلكتروني يؤدي إلى توقف الكود عن العمل. ستقضي وقتك في إصلاحات لا تنتهي.
- بطيء: عملية محاكاة المستخدم وتسجيل الدخول وتحميل صفحات الويب بطيئة جداً.
- تجربة مستخدم سيئة: يطلب من المستخدم بيانات حساسة جداً، مما يفقده الثقة بتطبيقك.
نعيم واجهات برمجة التطبيقات (Open Banking APIs)
- آمن جداً: يستخدم بروتوكولات عالمية مثل OAuth 2.0. تطبيقك لا يرى ولا يخزن كلمة مرور المستخدم أبداً. كل ما يحصل عليه هو “رمز وصول” مؤقت وصلاحياته محدودة.
- موثوق ومستقر: الواجهات البرمجية لها هيكل وعقد واضح (API Contract). طالما أنك تلتزم به، فالأمور ستعمل بسلاسة.
- سريع وفوري: طلب البيانات يتم بشكل مباشر وبرمجي، مما يوفر بيانات شبه لحظية.
- تجربة مستخدم ممتازة: المستخدم يشعر بالأمان لأنه يتم توجيهه إلى صفحة الدخول الرسمية للبنك الخاص به ليوافق على الربط، ثم يعود إلى تطبيقك. شفافية وثقة عالية.
لنغُص في التفاصيل التقنية قليلاً
حتى لا يكون كلامنا نظرياً فقط، دعونا نرى كيف تبدو العملية من منظور المبرمج. طبعاً، هذا مثال مبسط جداً، فالعملية الحقيقية تتضمن شهادات أمان وتفاصيل أكثر، ولكن الفكرة الأساسية واحدة.
خطوات الربط والمصادقة (Authentication Flow)
العملية تتبع بروتوكول OAuth 2.0 القياسي:
- الخطوة 1: المستخدم يضغط على “ربط حسابي البنكي” في تطبيقك.
- الخطوة 2: تطبيقك يقوم بإعادة توجيه المستخدم إلى رابط خاص بالبنك (Authorization URL) مع إرسال معرف التطبيق (Client ID) ونطاقات الصلاحية المطلوبة (e.g., `read_transactions`, `read_balance`).
- الخطوة 3: المستخدم يرى صفحة من البنك تطلب منه تسجيل الدخول والموافقة على منح تطبيقك الصلاحيات المطلوبة.
- الخطوة 4: بعد موافقة المستخدم، يقوم البنك بإعادة توجيهه إلى تطبيقك مرة أخرى، مع إرسال “كود تفويض” (Authorization Code) مؤقت.
- الخطوة 5: الخادم الخاص بتطبيقك (Backend) يأخذ هذا الكود، ويتواصل مع خادم البنك مباشرةً (بعيداً عن المستخدم) ويستبدل هذا الكود بـ “رمز وصول” (Access Token) و “رمز تحديث” (Refresh Token).
الآن، أصبح لدى تطبيقك رمز الوصول (Access Token) الذي يمكنه استخدامه لطلب البيانات.
مثال كود لجلب المعاملات (Fetching Transactions)
بمجرد حصولك على الـ `access_token`، يصبح جلب البيانات سهلاً. إليك مثال بسيط باستخدام JavaScript (Fetch API) كيف يمكن لخادمك طلب آخر 100 معاملة من حساب المستخدم:
// هذا الكود يعمل على الخادم (Server-side)
// افترض أننا حصلنا على accessToken بعد عملية المصادقة
async function getTransactions(accessToken) {
const accountId = 'user-account-id-from-previous-api-call'; // عادةً ما تجلب قائمة الحسابات أولاً
const bankApiUrl = `https://api.bank.com/v1/accounts/${accountId}/transactions?limit=100`;
try {
const response = await fetch(bankApiUrl, {
method: 'GET',
headers: {
'Content-Type': 'application/json',
// هنا نستخدم رمز الوصول لتأكيد هويتنا وصلاحيتنا
'Authorization': `Bearer ${accessToken}`
}
});
if (!response.ok) {
throw new Error(`HTTP error! status: ${response.status}`);
}
const data = await response.json();
console.log('Transactions:', data);
return data;
} catch (error) {
console.error('Failed to fetch transactions:', error);
}
}
// لاستدعاء الدالة
// getTransactions('your_super_secret_access_token');
الرد الذي ستحصل عليه سيكون عبارة عن ملف JSON منظم ومرتب، شيء من هذا القبيل:
{
"transactions": [
{
"transactionId": "txn_12345",
"date": "2023-10-26",
"description": "سوبرماركت الخير",
"amount": -75.50,
"currency": "JOD",
"category": "Groceries"
},
{
"transactionId": "txn_12346",
"date": "2023-10-25",
"description": "تحويل من محمد علي",
"amount": 200.00,
"currency": "JOD",
"category": "Transfers"
}
]
}
لاحظوا جمال البيانات! منظمة، نظيفة، وجاهزة للاستخدام مباشرة في تطبيقك لتصنيفها وتحليلها وعرضها للمستخدم بطريقة مفيدة. هذا هو الفرق بين الحفر في الصخر وتناول الطعام من طبق من ذهب.
نصائح من خبرة أبو عمر
بعد هذه الرحلة، تعلمت بعض الدروس التي أود مشاركتها معكم:
1. لا تعيد اختراع العجلة: استخدم المجمّعين (Aggregators)
التواصل مع كل بنك على حدة وبناء التكامل معه أمر معقد ومكلف جداً. كل بنك له تفاصيله التقنية ومتطلباته. الحل الأذكى هو استخدام خدمات طرف ثالث تسمى “مجمّعي واجهات برمجة التطبيقات” (API Aggregators) مثل Plaid, TrueLayer, Tink وغيرها. هذه الشركات قامت بالعمل الشاق مسبقاً وربطت مع مئات البنوك حول العالم، وتوفر لك واجهة برمجية واحدة (API) للتحدث معهم جميعاً. هذا يوفر عليك شهوراً، إن لم يكن سنوات، من العمل.
2. الأمان أولاً، ثانياً، وأخيراً
أكررها: لا تطلب أو تخزن بيانات دخول المستخدم البنكية أبداً. هذا خط أحمر. اعتمد كلياً على بروتوكول OAuth 2.0 الذي يوفره البنك أو المجمّع. كن شفافاً مع المستخدم حول البيانات التي تطلبها ولماذا تحتاجها. بيانات الناس أمانة في عنقك.
3. ابدأ بالقراءة فقط (Read-Only)
تنقسم الخدمات المصرفية المفتوحة إلى قسمين رئيسيين: خدمات معلومات الحساب (AISP) التي تسمح بقراءة البيانات، وخدمات بدء الدفع (PISP) التي تسمح بإنشاء الحوالات المالية. ابدأ بالنوع الأول (AISP) فهو أسهل من ناحية التنظيم والتقنية. عندما ينجح تطبيقك وتكتسب ثقة المستخدمين، يمكنك التفكير في إضافة ميزات الدفع.
4. تجربة المستخدم هي الملك
اجعل عملية ربط الحساب سلسة وسهلة قدر الإمكان. اشرح للمستخدم الفوائد التي سيحصل عليها، وطمئنه بشأن أمان بياناته. بضع شاشات تعليمية بسيطة يمكن أن تحدث فرقاً كبيراً في كسب ثقة المستخدم.
الخلاصة: من جزيرة إلى قارة 🚀
الخدمات المصرفية المفتوحة لم تنقذ تطبيقي “مصروفي” فحسب، بل فتحت أمامي وأمام آلاف المطورين حول العالم أبواباً هائلة للابتكار في عالم التكنولوجيا المالية (Fintech). لقد حولت البيانات المالية من صوامع مغلقة داخل البنوك إلى مورد يمكن الاستفادة منه لبناء خدمات أفضل وأكثر ذكاءً للجميع.
إذا كنت مطوراً وتفكر في بناء منتج في هذا المجال، فاعلم أن العصر الذهبي للتكنولوجيا المالية قد بدأ للتو. لم يعد بناء تطبيق مالي قوياً ومفيداً حلماً بعيد المنال. بفضل هذه الواجهات البرمجية، أصبح الملعب مفتوحاً، والفرص لا حصر لها. توكل على الله، وابدأ رحلتك!
