عمار حیدری، رئیس هیئتمدیره شرکت آراد رایانه لیان / در جدول تعرفه خدمات بانکی الکترونیکی سال ۱۴۰۵، هزینه اطلاعرسانی تراکنش حساب مشتری «۵۰ تومان بهاضافه هزینه پیامک» تعیین شده است. جملهای کوتاه و در ظاهر روشن. اما اگر قرار باشد همین عبارت در مقیاس یک بانک بزرگ اجرا شود، بخش دشوار ماجرا نه آن ۵۰ تومان، بلکه همان «هزینه پیامک» است.
هزینه کدام پیامک؟ پیامی که بهدلیل طول متن در دو بخش ارسال شده یا همان یک پیامی که مشتری روی تلفن همراهش دیده است؟ اگر شمارهای سالها پیش با یک اپراتور صادر شده و امروز به اپراتور دیگری ترابرد شده باشد، تعرفه کدام اپراتور باید اعمال شود؟ و اگر ارسال اول بهدلیل یک خطای فنی تکرار شود، آیا قرار است مشتری دوباره هزینه بدهد؟
این پرسشها در مقیاس چند هزار پیام شاید بیش از حد مهندسی به نظر برسند. در مقیاس بانکی، مستقیماً با پول سروکار دارند.
یک مثال کاملاً فرضی را در نظر بگیریم. اگر بانکی روزانه پنج میلیون پیام ارسال کند و فقط دو تومان در ارزشگذاری هر پیام اختلاف وجود داشته باشد، حاصل آن روزانه ۱۰ میلیون تومان و در یک ماه ۳۰ روزه حدود ۳۰۰ میلیون تومان خواهد بود؛ فقط دو تومان اختلاف!
قرار نیست از این مثال نتیجه بگیریم که بانکها الزاماً چنین خطایی دارند. مسئله چیز دیگری است: در مقیاس میلیونها پیام، عددی که در سطح یک پیام ناچیز به نظر میرسد، میتواند در پایان ماه به یک رقم جدی مالی تبدیل شود.
تناقض از همینجا آغاز میشود. بانک درباره پول تقریباً هیچ چیز را تقریبی نمیپذیرد. تراکنش شناسه دارد، کارمزد قاعده دارد، برگشت پول باید قابل ردیابی باشد و مغایرت حتی اگر کوچک باشد، باید علت مشخصی داشته باشد. اما اطلاعرسانی، با وجود حجم و هزینهای که پیدا کرده، هنوز در بسیاری از معماریها بیشتر به چشم یک مسئله فنی دیده میشود: پیام تولید میشود، به gateway تحویل داده میشود، وضعیت ارسال ثبت میشود و در پایان دوره نیز صورتحساب تأمینکننده میرسد.
این مدل زمانی قابل تحمل بود که پیامرسانی یک سرویس جانبی محسوب میشد. امروز دیگر چنین نیست.
وقتی میلیونها پیام در روز از زیرساخت بانک عبور میکند، سؤال مهم فقط این نیست که «چقدر به شرکت پیامکی بدهکاریم؟» سؤال مهمتر این است که یک notification مشخص چرا این مقدار ارزشگذاری شده و هزینه آن اساساً بر عهده چه کسی بوده است.
همین تفاوت، مرز میان «هزینه پیامک» و «مدیریت مالی اطلاعرسانی» است.
صورتحساب یک provider میتواند بگوید بانک در پایان ماه چه مبلغی بابت سرویس خریداریشده بدهکار است، اما این الزاماً همان مبلغی نیست که باید از مشتری دریافت شود. همانطور که قیمت تمامشده بسیاری از خدمات بانکی با کارمزدی که از مشتری گرفته میشود یکی نیست، هزینه خرید SMS نیز لزوماً نباید مستقیماً به مشتری منتقل شود.
ممکن است بانک هزینه OTP را خودش تقبل کند. اطلاعرسانی یک تراکنش ممکن است طبق تعرفه از مشتری دریافت شود. هزینه یک پیام تبلیغاتی میتواند بر عهده کمپین بازاریابی باشد. برای گروهی از مشتریان نیز ممکن است بانک تصمیم بگیرد بخشی از خدمات اطلاعرسانی رایگان باشد. در مدلی دیگر، مشتری شاید از قبل بسته یا اعتباری برای این خدمات خریداری کرده باشد.
بخوانید: OTP دیگر امن نیست
مسیر فنی ارسال در تمام این سناریوها میتواند یکسان باشد، اما منطق مالی آنها یکی نیست.
در چنین مدلی فقط قیمت مهم نیست؛ اینکه چه کسی پرداختکننده است، بخشی از ماهیت همان تراکنش است.
ماجرا وقتی جدیتر میشود که خود SMS را هم دقیقتر ببینیم. یک پیام فارسی از نگاه کاربر یک پیام است، اما از نگاه شبکه ممکن است در چند بخش ارسال شود. اضافهشدن چند کلمه میتواند پیام را از یک بخش به دو بخش ببرد و هزینه را تغییر دهد. واحد کسبوکار شاید فقط متن را کمی روانتر کرده باشد، اما همان تغییر کوچک، وقتی در چند میلیون پیام تکرار شود، اثر مالی قابل توجهی خواهد داشت.
اپراتور مقصد هم همیشه از روی پیششماره قابل تشخیص نیست. با وجود ترابردپذیری شماره، یک شماره ممکن است زمانی متعلق به یک اپراتور بوده و امروز روی شبکه دیگری فعال باشد. اگر نرخ ارسال میان اپراتورها یکسان نباشد، تشخیص مقصد از روی چند رقم اول شماره برای یک سامانه مالی کافی نیست.
در یک سامانه صرفاً آماری، چنین خطایی شاید فقط چند ستون گزارش را جابهجا کند. در سامانهای که قرار است بر اساس همان محاسبه از اعتبار مشتری کم کند، موضوع کاملاً متفاوت است.
وقتی پول مشتری در میان است، «تقریباً درست» کافی نیست.
قیمت امروز، هزینه فردا
در این بحث یک ظرافت مهم وجود دارد. وقتی میگوییم اقتصاد notification باید پیش از ارسال روشن باشد، منظور این نیست که بانک همان لحظه هزینه نهایی تأمینکننده را با قطعیت میداند.
آنچه باید پیش از ارسال مشخص شود، قیمتی است که بر اساس سیاست و تعرفه بانک برای همان notification قابل اعمال است. این همان مرحلهای است که در سامانههای Billing معمولاً با مفاهیمی مثل Rating یا Quote شناخته میشود.
فرض کنیم بانک تعیین کرده یک نوع مشخص از اطلاعرسانی، برای یک مشتری مشخص، روی یک اپراتور مشخص و با تعداد بخش مشخص، مبلغ معینی دارد. این مبلغ باید پیش از آغاز ارسال تثبیت شود تا رفتارهای بعدی سیستم، مثل retry یا تغییر مسیر، بدون دلیل آن را تغییر ندهند.
اما در سوی دیگر ماجرا، هزینه واقعی تأمین سرویس ممکن است بعداً و بر اساس delivery report، اطلاعات اپراتور یا صورتحساب provider روشن شود.
این دو عدد لزوماً یکی نیستند و اصولاً قرار هم نیست همیشه یکی باشند. یکی قیمتگذاری بانک برای مصرفکننده یا پرداختکننده سرویس است؛ دیگری هزینهای که بانک به زنجیره تأمین میپردازد.
در پایان دوره، این دو حوزه باید بتوانند در فرایند Reconciliation کنار هم قرار بگیرند تا بانک بداند چه میزان سرویس ارائه کرده، چه بخشی از هزینه را خودش تقبل کرده و برای تأمین آن واقعاً چه مبلغی پرداخته است.
اختلاف میان این اعداد، اگر بر اساس یک سیاست مشخص شکل گرفته باشد، الزاماً مغایرت نیست؛ بخشی از اقتصاد سرویس است.
مشکل زمانی آغاز میشود که این مفاهیم از همان ابتدا از یکدیگر تفکیک نشده باشند. فرض کنیم notification تولید شده، قیمت آن مشخص است و پیام برای ارسال تحویل داده میشود. gateway پاسخ نمیدهد و worker چند ثانیه بعد همان عملیات را دوباره امتحان میکند.
از دید فنی، یک retry اتفاق افتاده است؛ اما از دید مشتری اتفاق اقتصادی تازهای رخ نداده. هنوز همان پیام، برای همان رویداد، در حال ارسال است.
اگر سامانه نتواند میان «notification جدید» و «تلاش مجدد برای تحویل notification قبلی» تفاوت بگذارد، یک مسئله فنی خیلی سریع به یک خطای مالی تبدیل میشود.
همین موضوع در معماری چندکاناله اهمیت بیشتری پیدا میکند. بانک ممکن است ابتدا پیام را از طریق push ارسال کند و اگر در مهلت مشخصی به مقصد نرسید، SMS را بهعنوان مسیر جایگزین فعال کند. از نگاه زیرساخت، دو کانال درگیر شدهاند؛ اما از نگاه کسبوکار هنوز یک اتفاق وجود دارد: بانک میخواهد مشتری را از یک رویداد مشخص مطلع کند.
بنابراین یک notification باید هویت اقتصادی خودش را داشته باشد؛ هویتی که مستقل از تعداد تلاشها، تغییر provider یا تغییر کانال حفظ شود.
بانکها این منطق را در سیستمهای مالی بهخوبی میشناسند. یک عملیات ابتدا شناخته و ارزشگذاری میشود، در صورت نیاز اعتبار برای آن کنار گذاشته میشود و وقتی عملیات به نقطه قابل شارژ رسید، مبلغ ثبت نهایی میشود. اگر هم فرایند پیش از آن متوقف شد، اعتبار رزروشده آزاد میشود.
وقتی اطلاعرسانی وارد قلمرو پول شده، دلیلی ندارد از همین انضباط برخوردار نباشد.
جای خالی یک لایه مالی
Arad Notification Wallet یا ANW دقیقاً برای همین فاصله طراحی شده است؛ نه بهعنوان جایگزین SMSC، نه بهعنوان gateway جدید و نه بهعنوان رقیب پلتفرمهای push.
ارسال همچنان وظیفه زیرساخت Delivery است. ANW در کنار این زیرساخت، یک لایه مالی اضافه میکند؛ لایهای که قبل از ارسال مشخص میکند این notification با چه تعرفهای ارزشگذاری میشود، پرداختکننده آن کیست و اگر قرار است اعتباری مصرف شود، چگونه این اتفاق باید ثبت شود.
وقتی یک notification ایجاد میشود، ANW نوع رویداد، پرداختکننده، تعرفه معتبر در همان زمان، اپراتور مقصد، Encoding و تعداد بخشهای پیام را در محاسبه در نظر میگیرد و برای همان عملیات یک Quote میسازد.
این Quote به همان notification تعلق دارد، نه به هر بار تلاش برای ارسال آن.
بنابراین اگر زیرساخت مجبور شود پیام را دوباره ارسال کند، provider را تغییر دهد یا در ادامه از کانال دیگری استفاده کند، ANW همچنان میداند که با همان رخداد مالی قبلی روبهرو است.
اگر سیاست بانک به کنترل اعتبار نیاز داشته باشد، مبلغ میتواند پیش از ارسال رزرو شود. وقتی عملیات به نقطهای رسید که طبق سیاست بانک قابل شارژ است، همان مبلغ تثبیت میشود؛ و اگر فرایند پیش از آن متوقف شد، اعتبار آزاد خواهد شد. به این ترتیب یک retry فنی، بهخودیخود پول تازهای از مشتری کم نمیکند.
این تفاوت در ظاهر کوچک، همان چیزی است که یک Wallet واقعی برای notification را از یک شمارنده ساده پیام جدا میکند.
Wallet است، اما فقط Wallet نیست
نام Arad Notification Wallet ممکن است در نگاه اول این تصور را ایجاد کند که با یک کیف پول پیشپرداختی برای خرید پیام روبهرو هستیم. بخشی از ماجرا همین است، اما تمام آن نیست.
Wallet مشخص میکند اعتبار یا هزینه از کجا تأمین میشود. مشتری ممکن است موجودی داشته باشد، بسته خریداری کرده باشد یا بانک هزینه را از طرف او تقبل کند. در سناریویی دیگر، یک کمپین میتواند پرداختکننده باشد.
اما همین عملیات مالی باید جایی ثبت شود و قابل توضیح باقی بماند. اینجاست که رفتار Ledger-like اهمیت پیدا میکند. هر حرکت مالی باید سابقه داشته باشد؛ باید مشخص باشد چه مبلغی Quote شده، چه چیزی رزرو شده، چه مقداری مصرف شده یا آزاد شده و کدام نسخه تعرفه در آن لحظه معتبر بوده است.
به بیان ساده، Wallet میگوید اعتبار از کجا میآید؛ Ledger نشان میدهد چه بر سر آن اعتبار آمده است. این دو مفهوم مقابل هم نیستند. برای یک سامانه مالی قابل اتکا، مکمل هماند.
همین منطق درباره مالیات هم صادق است. ممکن است بانکی مالیات را هنگام خرید بسته دریافت کند و بانک دیگری هنگام مصرف واقعی سرویس. آنچه اهمیت دارد این است که سیستم بداند مالیات در کدام مرحله محاسبه شده تا یک مبلغ دوبار مشمول آن نشود.
تعرفه نیز باید تاریخ داشته باشد. اگر قیمتها در مهرماه تغییر کنند، notification ارسالشده در شهریور باید همچنان با قواعد معتبر همان زمان قابل توضیح باشد.
این جزئیات شاید روی کاغذ بیش از حد فنی به نظر برسند، اما کافی است یک مشتری بابت مبلغی که از اعتبارش کم شده اعتراض کند تا همین جزئیات به مهمترین بخش ماجرا تبدیل شوند.
آزمون واقعی، مشتری معترض است
فرض کنیم سه ماه از ارسال یک پیام گذشته و مشتری درباره مبلغی که بابت اطلاعرسانی از حساب یا اعتبارش کسر شده اعتراض میکند.
بانک چقدر زمان نیاز دارد تا پاسخ بدهد؟
آیا میتواند در یک مسیر روشن ببیند این notification مربوط به کدام رویداد بوده، چه زمانی ایجاد شده، کدام نسخه تعرفه بر آن اعمال شده، اپراتور مقصد چه بوده، پیام چند بخش داشته، چه کسی پرداختکننده بوده، چه مبلغی برای آن در نظر گرفته شده و آیا در مسیر ارسال retry یا تغییر کانال رخ داده است؟
یا باید تیم فناوری سراغ log چند سامانه برود، اطلاعات gateway را پیدا کند، فایل provider را بررسی کند و در نهایت چند جدول را در Excel کنار هم بگذارد تا بتواند توضیحی برای آن مبلغ پیدا کند؟
تفاوت این دو وضعیت فقط در کیفیت گزارشگیری نیست. مسئله این است که بانک برای اطلاعرسانی یک لایه مالی مستقل دارد یا ندارد.
بانکها سالهاست برای حرکت پول Ledger ساختهاند. برای حساب، کارت، کارمزد، پرداخت و تسویه سامانههای تخصصی دارند، چون پذیرفتهاند پول بدون هویت، سابقه و قابلیت Audit قابل مدیریت نیست.
اطلاعرسانی بانکی هم امروز به نقطهای رسیده که دیگر نمیتوان آن را فقط خروجی یک gateway دانست. حجم پیامها بالا رفته، کانالها متنوع شدهاند، مدلهای تعرفهای پیچیدهتر شدهاند و اینکه هزینه هر ارتباط بر عهده چه کسی است، خودش به یک تصمیم مالی تبدیل شده است.
تا چند سال پیش مهمترین سؤال این بود که چند پیام ارسال شده و چند پیام رسیده است. امروز یک سؤال دیگر هم باید کنار آن قرار بگیرد:
هر notification چه ارزشی داشته و حساب آن با چه کسی بوده است؟
بانک برای هر ریال Ledger دارد. وقت آن رسیده است که برای میلیونها پیامش هم همان میزان دقت داشته باشد.
