في مارس 2026، أغلق بنك Fi الهندي الرقمي، بهدوء، قسم الخدمات المصرفية في تطبيقه. وتلقى العملاء الذين فتحوا حسابات توفير عبر واجهة Fi الأنيقة رسالة بريد إلكتروني تُفيد بأن الحساب سليم وآمن وممول بالكامل، لكن سيتعين عليهم الآن إدارته عبر تطبيق FedMobile التابع لبنك Federal Bank، وهو البنك المرخص الذي كان يحتفظ بتلك الحسابات طوال الوقت. ووصف بنك Federal Bank هذا الإجراء بأنه "إعادة هيكلة للأعمال". وأعلن بنك Fi، الذي خدم أكثر من 3.5 مليون عميل وأجرى أكثر من مليار معاملة منذ عام 2021، أنه يُعيد تركيز جهوده على التقنيات المتقدمة والذكاء الاصطناعي.
إنها قصة صغيرة، لكنها تكشف الكثير عن آلية عمل التكنولوجيا المالية الحديثة. لم تكن "فاي" بنكًا قط، بل كانت تطبيقًا مصممًا ببراعة يعمل ضمن بنية تحتية مصرفية، وعندما انتهى هذا الترتيب، اختفى التطبيق، وليس المال أو الحساب الأساسي. ينطبق هذا على جميع تطبيقات البنوك الرقمية والاستثمار التي تستخدمها تقريبًا، وفهم السبب سيغير نظرتك إلى تطبيقات التكنولوجيا المالية على هاتفك.
البنك الرقمي ليس بنكًا، بل هو واجهة
البنك الرقمي هو علامة تجارية مالية رقمية بالكامل، لا تملك فروعًا، وعادةً ما يتمحور حول تطبيق أكثر سلاسة وتجربة مستخدم أفضل من تلك التي تقدمها البنوك التقليدية. لكن ما يندر وجود ترخيص مصرفي رسمي لديه هو حصوله على ترخيص. في الهند، لا يعترف بنك الاحتياطي الهندي بـ"البنك الرقمي" كفئة مرخصة على الإطلاق. قامت شركات مثل جوبيتر وفاي بتطوير حسابات التوفير وبطاقات الخصم المباشر وميزات نظام المدفوعات الموحد (UPI) بالتعاون مع بنك فيدرال، بينما تعتمد شركات أخرى على شركاء مثل بنك أكسيس أو بنك دي سي بي. يتولى التطبيق تصميم التطبيق، ونظام المكافآت، وتجربة المستخدم. أما البنك الخاضع للتنظيم فيحتفظ بالودائع، ويحمل الترخيص، ويلتزم بمتطلبات الامتثال.
هذا ليس حكرًا على الهند. فشركة Chime، إحدى أكبر البنوك الرقمية في الولايات المتحدة، لا تحمل ترخيصًا مصرفيًا أيضًا، بل تعمل من خلال بنوك شريكة. أما N26 وRevolut فتختلفان في كونهما تحملان تراخيص مصرفية خاصة بهما في أجزاء من أوروبا، وهذا أحد أسباب اختلاف نطاقهما التنظيمي عن Chime أو Jupiter. والنمط المهم هو التالي: مصطلح "بنك رقمي" يصف طبقة المنتج، وليس بالضرورة الطبقة القانونية، وقد يكون التطبيق الذي تثق به لإدارة راتبك على بُعد خطوة واحدة من تغيير ملكيته، تمامًا كما حدث لعملاء Fi مؤخرًا.
تعتمد تطبيقات الاستثمار على نفس المنطق
استبدل كلمة "بنك" بكلمة "وسيط" وستجد نفس السيناريو في عالم الاستثمار. فنادرًا ما تمتلك تطبيقات خطط الاستثمار المنتظمة (SIP) أو تطبيقات تداول الأسهم المتطورة بنية تحتية خاصة بها للمقاصة أو تعمل كجهة إيداع مستقلة. في الهند، يتعين على كل وسيط مسجل لدى هيئة الأوراق المالية والبورصات في الهند (SEBI)، سواء كان تطبيقًا لصناديق الاستثمار المشتركة، أو وسيطًا بخصم، أو منصة لإدارة الثروات، توجيه عملية "اعرف عميلك" (KYC) من خلال وكالة تسجيل "اعرف عميلك" (KYC) مسجلة لدى هيئة الأوراق المالية والبورصات في الهند، وهو نظام تم تقديمه بموجب لوائح وكالات تسجيل "اعرف عميلك" (KRA) الصادرة عن هيئة الأوراق المالية والبورصات في الهند لعام 2011. أكمل عملية "اعرف عميلك" مرة واحدة مع أي وكالة تسجيل "اعرف عميلك"، مثل وكالة تسجيل "اعرف عميلك" التابعة لشركة CAMS أو ذراع "اعرف عميلك" التابعة لبورصة NSE، وبذلك تستطيع أي منصة أخرى مسجلة لدى هيئة الأوراق المالية والبورصات في الهند سحب نفس السجل الموثق دون الحاجة إلى إعادة العملية. إنها النسخة الاستثمارية لما يوفره نظام "اعرف عميلك الإلكتروني" (eKYC) القائم على نظام "آدهار" للحسابات المصرفية، وهوية واحدة موثقة قابلة لإعادة الاستخدام في كل مكان.
على الصعيد العالمي، يتشابه الشكل العام حتى وإن اختلفت البنية التحتية. تعتمد تطبيقات مثل Robinhood وWealthfront ومعظم تطبيقات الاستثمار للأفراد على شركات المقاصة والحفظ التي تتولى فعلياً حفظ وتسوية الأوراق المالية. يمثل التطبيق واجهة المستخدم، بينما البنية التحتية الأساسية منظمة وموحدة، وغير مرئية في الغالب للمستخدم النهائي، إلى أن يحدث تغيير ما، فيلاحظ حينها أنها كانت موجودة طوال الوقت.
عملية الإعداد هي المدخل الرئيسي، وهي الآن مشكلة تتعلق بواجهة برمجة التطبيقات (API).
سواء كنت تفتح حسابًا مصرفيًا رقميًا أو خطة استثمار منتظمة (SIP)، فإن أول خطوة هي التحقق من الهوية، وهنا تبرز أهمية طبقة واجهة برمجة التطبيقات (API). تقوم بنية الإعداد المتكاملة بسحب بيانات التحقق من الهوية (مثل Aadhaar أو PAN)، والتحقق من سجل اعرف عميلك المركزي (KYC) للتأكد من وجود سجل، وبالنسبة لحسابات الشركات أو الشركات الصغيرة والمتوسطة، تتحقق من إقرارات ضريبة السلع والخدمات (GST)، كل ذلك من خلال بضع استدعاءات لواجهة برمجة التطبيقات بدلاً من زيارة الفرع وطباعة العديد من النسخ. هذا هو بالضبط نوع البنية التحتية التي توفرها شركة Decentro. واجهات برمجة تطبيقات اعرف عميلك تم تصميمها من أجل دمج عمليات التحقق من Aadhaar و PAN و CKYC و GST في عملية تكامل واحدة بحيث لا يضطر البنك الرقمي أو تطبيق الاستثمار إلى بناء علاقة منفصلة مع كل سجل حكومي على حدة.
هذا الأمر أكثر أهمية مما يبدو. عادةً ما تكون عملية التسجيل هي السبب الرئيسي لتخلي المستخدمين عن أي منتج من منتجات التكنولوجيا المالية. فكل مستند إضافي، وكل خطوة مراجعة يدوية، تُشكل فرصة للعميل الحقيقي للتخلي عن المنتج في منتصف الطريق. أما التطبيقات التي تبدو سريعة الاستجابة في واجهة المستخدم، فهي في الواقع، وبشكل شبه دائم، تعمل بنظام تحقق آلي سريع في الخلفية.
الجزء الذي لا يفكر فيه أحد: المدفوعات المتكررة
هذا هو الجزء من بنية تطبيقات البنوك الرقمية والاستثمارية الذي يحظى بأقل قدر من الاهتمام رغم أهميته البالغة. لا يعمل نظام الاستثمار المنتظم (SIP) إلا إذا تم الخصم الشهري بانتظام لسنوات، دون الحاجة إلى موافقة المستثمر يدويًا على كل دفعة. في الهند، تتم هذه العملية عبر نظام الدفع التلقائي UPI AutoPay، وهو نظام تفويض أطلقته المؤسسة الوطنية للمدفوعات في الهند (NPCI) عام 2020، والذي يسمح للمستخدم بتفويض عملية خصم متكررة مرة واحدة باستخدام رقم التعريف الشخصي (PIN) الخاص به، ثم تتم معالجة المدفوعات اللاحقة تلقائيًا حتى حد معين، وهو 15,000 روبية هندية للمدفوعات المتكررة العامة، وحتى 1 روبية هندية لفئات مثل خطط الاستثمار المنتظم لصناديق الاستثمار المشتركة، وأقساط التأمين، وأقساط القروض الشهرية، قبل إعادة المصادقة. لا تزال الأنظمة القديمة مثل تفويضات NACH الإلكترونية تتولى جزءًا كبيرًا من هذه العمليات، خاصةً بالنسبة لعمليات الخصم المتكررة ذات القيمة العالية أو المرتبطة بحسابات بنكية.
تعتمد البنوك الرقمية على نفس البنية التحتية لسبب مختلف: فميزات الادخار التلقائي، والتحويلات المتكررة إلى حسابات التوفير، وفواتير الاشتراكات للفئات المميزة، والتعليمات الدائمة، كلها تعتمد على بنية تحتية موثوقة للدفع المتكرر ذات احتمالية فشل منخفضة. إن أي خطأ في هذه البنية لا يُكلف الإيرادات فحسب، بل يعني أيضًا توقف خطة الاستثمار المنتظم (SIP) عن الاستثمار دون أن يلاحظ المستخدم، أو تعثر تحقيق هدف الادخار، وغالبًا لا يلاحظ المستخدم ذلك إلا بعد أشهر. وهذا تحديدًا هو نوع البنية التحتية التي تعتمد عليها منصة Decentro. واجهات برمجة تطبيقات المدفوعات المتكررة تم تصميمها للتعامل مع عمليات الدفع التلقائي UPI و NACH وإدارتها بحيث يمكن لمنتج التكنولوجيا المالية إعداد عمليات الخصم المتكررة وتتبعها وإعادة محاولة تنفيذها دون الحاجة إلى دمج العديد من عمليات التكامل المصرفية و NPCI بنفسه.
ما تُعلّمه قصة Fi في الواقع
لنعد إلى تطبيق Fi Money للحظة. السبب وراء عدم خسارة عملائه أي مبلغ عند إغلاق التطبيق هو تحديدًا أن البنية التحتية الأساسية، أي الحساب المصرفي الفعلي، لم تكن تابعة لـ Fi أصلًا. بل كانت ملكًا للبنك الفيدرالي، وهو كيان خاضع للرقابة، طوال الوقت. اختفى التطبيق فجأة لأنه لم يكن أبدًا المكان الذي تُدار فيه العلاقة المالية الحقيقية.
ليس هذا عيبًا في نموذج البنوك الرقمية، بل هو النموذج نفسه يعمل كما هو مصمم. والدرس المستفاد لكل من يبني أو يستخدم منتجات التكنولوجيا المالية هو أن واجهة المستخدم قابلة للاستبدال، أما البنية التحتية الأساسية فليست كذلك، أو على الأقل لا ينبغي أن تكون كذلك. ولهذا السبب تحديدًا، انتقل جزء كبير من الابتكار الفعلي في صناعة التكنولوجيا المالية من تصميم التطبيقات إلى طبقة واجهة برمجة التطبيقات (API): التحقق من الهوية، وإدارة السجلات، ومعالجة التفويضات، والامتثال، وهي الأمور غير الجذابة التي تحدد ما إذا كانت أموالك آمنة بالفعل، وما إذا كان نظام الدفع المنتظم (SIP) الخاص بك يعمل في الموعد المحدد، بغض النظر عن التطبيق المستخدم حاليًا.