ملاحظات ميدانية

ما هو IBAN الافتراضي؟

IBAN الافتراضي (vIBAN) هو رقم حساب مصرفي دولي حقيقي وقابل للاستقبال، يُصدر من نطاق مخصص ويُوجَّه إلى حساب رئيسي واحد. يقبل المدفوعات كأي IBAN آخر، إذ يرسل إليه الدافع حوالة SEPA عادية من مصرفه، لكنه لا يحتفظ برصيد خاص به. وظيفته التعريف: فبما أن كل IBAN افتراضي مخصص لدافع واحد أو لغرض واحد، فإن أي دفعة تصل إليه تدل مسبقاً على مرسلها وسببها. تتجمع الأموال في الحساب الرئيسي تلقائياً، ويكون IBAN الافتراضي بمثابة الوسم على الدفعة، لا مكاناً ثانياً تُحفظ فيه الأموال.

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

المشكلة الحقيقية: مطابقة الأموال بالدافعين

تخيّل شركة تحصّل مدفوعاتها بالحوالات المصرفية في حساب واحد: إيجارات واشتراكات وفواتير. كل إيداع يصل إلى IBAN نفسه، والدليل الوحيد على هوية الدافع هو ما كتبه في خانة المرجع. وهذه المراجع تُكتب بأخطاء، أو تُقتطع في مكان ما من السلسلة، أو تُترك فارغة. حوالة بقيمة €49.00 بمرجع مشوّه لا تُعد بعد إيراداً معترفاً به، بل هي تذكرة عمل. على أحدهم أن يحدد لأي عميل ولأي فاتورة تعود قبل إقفال الدفاتر.

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

IBAN لكل دافع: هوية مضمونة بحكم التصميم

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

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

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

حين يدفع كل دافع إلى IBAN الخاص به، لا يمكن لأي دفعة واردة أن تعني إلا شيئاً واحداً. مشكلة المطابقة لا تُحل، بل تتوقف عن الوجود.
— Protocore · هندسة المدفوعات

أين تستقر الأموال فعلياً

في الأسفل، هناك حساب رئيسي واحد لكل عملة. تُصدر حسابات IBAN الافتراضية من نطاقات مخصصة للبرنامج، وكل إيداع يُرسل إلى أي منها يُسوّى في الحساب الرئيسي. لا أرصدة لكل دافع لتديرها، ولا مهام تحويل نهاية اليوم تنقل الأموال من آلاف الحسابات الصغيرة إلى حساب واحد. التجميع يتم بالتوجيه، لا بتحويلات إضافية تضطر بعدها إلى مطابقتها هي الأخرى.

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

ما ليس IBAN الافتراضي

ليس حساباً فرعياً: فالحساب الفرعي يحتفظ برصيد، ويحتاج إلى تمويل وسحب، ويضاعف دفاتر الأستاذ التي تديرها. وليس رقم مرجع افتراضياً: فتلك الأرقام ما زالت تعتمد على حقل المرجع وعلى نسخ الدافعين للنصوص بدقة. وليس محفظة: فلا شيء يُخزَّن على vIBAN نفسه. إنه عنوان يقف خلفه توجيه، وهو أضيق بنية تجعل الدفعة الواردة تعرّف بنفسها.

المرتجعات تعود ومعها السبب

المدفوعات لا تصل فحسب. فالحسابات تُغلق، والمصارف ترفض الإيداعات، والدافعون يسحبون حوالاتهم. في عالم الحساب الواحد للتحصيل، يتحول المرتجع إلى تحقيق صغير: أي دفعة عادت، ولمن كانت، وهل يلزم عكس قيد دفتر الأستاذ الذي طُوبقت معه؟

في برنامج vIBAN، المرتجع بيانات. فهو يحمل رمز السبب، ويصل كحدث payment.returned على IBAN الافتراضي نفسه الذي استخدمه الإيداع الأصلي، ويحصل على بند خاص به في كشف الحساب. تعرف لمن تعود الدفعة المرتجعة ولماذا، قبل أن يفتح أحد تذكرة. تصبح المرتجعات صفوفاً تُعالج، لا ألغازاً تُلاحق.

طابور استثناءات، لا فريق مطابقة

لا يوجد تصميم يطابق مئة بالمئة من أي شيء. فتصل إيداعات إلى حسابات vIBAN موقوفة، وتحدث تكرارات، ويدفع أحدهم إلى الحساب الرئيسي مباشرة بطريقة ما. الهدف ليس جعل الاستثناءات مستحيلة، بل جعلها نادرة وقابلة للعدّ. في عرض Protocore vIBAN التجريبي، تتم مطابقة 99.6% من الإيداعات تلقائياً، والباقي يدخل طابور المراجعة ومعه السجل الكامل للدافع، فتبدأ معالجة الاستثناء من السياق لا من كشف حساب وجدول بيانات.

هذا الفرق يعيد تشكيل الفريق. فعمليات المطابقة تنمو مع حجم المدفوعات: إيداعات أكثر، فإيداعات غير مطابقة أكثر، فموظفون أكثر. أما عملية الاستثناءات فتنمو مع حجم الاستثناءات، وقد دفعه التصميم أصلاً نحو الصفر. والأشخاص الذين تبقيهم يعالجون حالات شاذة حقيقية، لا مراجع أعيد كتابتها. في منظومتنا يقع هذا الطابور في Protocore Center (/products/center)، وهي لوحة العمليات التي يتطلب فيها كل إجراء مميّز ذكر السبب ويُسجَّل في سجل التدقيق.

الإصدار بالجملة ووسوم الغرض والمنصات

فكرة IBAN لكل دافع لا تنجح إلا إذا كان إصدار الواحد منها بلا كلفة. يستطيع مؤجّر لديه اثنا عشر مستأجراً إصدار حسابات vIBAN يدوياً، أما سوق إلكتروني يضم آلاف البائعين فلا. لذلك فالإصدار عملية جماعية. في عرض vIBAN التجريبي، يخضع ملف CSV يضم 2,400 دافع للتحقق، ويعرض معاينة لـ IBAN في كل صف، ثم يُصدر دفعة واحدة: 2,400 دافع، وعملية واحدة، ومرحلة مراجعة بينهما.

تفصل وسوم الغرض التدفقات عند مستوى العنوان: الإيجارات هنا، والاشتراكات هناك، ومدفوعات البائعين في مسار مستقل. يصبح التقرير بحسب الغرض مجرد عامل تصفية لا مشروعاً، ويحصل كل vIBAN على كشف حساب خاص به، بصيغة CSV أو PDF، بينما يبقى الحساب الرئيسي مصدر الحقيقة الوحيد في الأسفل. وحين يغادر الدافع، يُوقَف vIBAN الخاص به: يبقى السجل، ويتوقف العنوان عن قبول إيداعات جديدة.

موقعه في منظومة الدفع

حسابات IBAN الافتراضية بنية تحتية للتحصيل. فهي تمنح الحوالات المصرفية الواردة ما كانت مدفوعات البطاقات تملكه دائماً: هوية مرتبطة بالدفعة نفسها، لا تُكتب بجانبها. وفي منظومة Protocore، تحمل طلبات الدفع بالحوالة في Gateway مراجع vIBAN، ويعالج Center ما تتركه المطابقة من استثناءات. وتستعرض صفحة المنتج على /products/viban الحلقة كاملة: إصدار، ومشاركة، ومطابقة، واستثناء، وتقرير، على بيانات العرض نفسها المستخدمة هنا.

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

لديك نظام تريد بناءه؟

أخبرنا بالمشكلة، ونعود إليك بهندسة معمارية وخطة.