فروشنده گفت حساب عوض شده؛ اولین اقدام چیست؟
پرداخت به حساب تازه را تا بررسی مستقل متوقف کنید. دریافت پیام از ایمیل آشنا، وجود مهر در PDF یا تأکید بر فوریت، به‌تنهایی اصالت درخواست و مالکیت حساب را اثبات نمی‌کند.
ممکن است تغییر حساب کاملاً واقعی باشد؛ هدف بررسی، متهم‌کردن فروشنده نیست. مسئله این است که یک درخواست جعلی هم می‌تواند شبیه مکاتبهٔ عادی دیده شود. در کلاهبرداری با سوءاستفاده از ایمیل کسب‌وکار، مهاجم می‌تواند درخواست پرداخت یا مقصد آن را تغییر دهد. راهنمای FBI دربارهٔ جعل مکاتبات تجاری توصیه می‌کند تغییر اطلاعات پرداخت را با تماس مستقل بررسی کنید و شمارهٔ تماس را از خود پیام مشکوک برندارید. این توصیهٔ عمومی امنیتی است، نه قانون یا دستورالعمل بانکی ایران.
مثال: همان فاکتور، یک مقصد تازه
- فاکتور
- DEMO-8721 برای «شرکت مثالِ الف»
- مبلغ
- ۴۸۰ میلیون ریال، معادل ۴۸ میلیون تومان
- مقصد قبلی
- شناسهٔ ساختگی DEMO-ACCOUNT-A
- درخواست جدید
- «امروز فوری به DEMO-ACCOUNT-B واریز کنید.»
- تصمیم اولیه
- توقف تأیید مقصد تازه و ارجاع به بررسی؛ نه اعلام قطعی تقلب
حتی اگر مبلغ و نام شرکت در فاکتور درست باشند، مقصد جدید هنوز باید بررسی شود. برای این مثال، نسخهٔ قبلی فاکتور را نگه می‌داریم، درخواست تغییر را جدا ثبت می‌کنیم و با فرد مجاز فروشنده از راه ارتباطی ازپیش‌تأییدشده تماس می‌گیریم. واحد مبلغ هم باید صریح باشد؛ جزئیات را در راهنمای تفاوت ریال و تومان بخوانید.
چهار کنترل متفاوت؛ هیچ‌کدام جای همه را نمی‌گیرد
جدول زیر یک الگوی پیشنهادی برای تیم مالی است. در موبایل، جدول را افقی جابه‌جا کنید تا ستون محدودیت دیده شود.
| کنترل | پرسش اصلی | محدودیت |
|---|---|---|
| اصالت درخواست | آیا فرد مجاز فروشنده تغییر را از مسیر مستقل تأیید کرده؟ | تماس معتبر به‌تنهایی مالکیت حساب بانکی را ثابت نمی‌کند. |
| ذی‌نفع و مقصد | آیا مقصد با شخص یا شرکت مجاز در قرارداد سازگار است؟ | درست‌بودن قالب شمارهٔ شبا، اثبات مالکیت یا اختیار دریافت نیست. |
| سابقه و نسخه | چه کسی، چه زمانی و چرا مقصد را نسبت به نسخهٔ قبلی تغییر داده؟ | سابقهٔ پرداخت قبلی، تغییر جدید را خودکار مجاز نمی‌کند. |
| تکراری‌نبودن | آیا همین تعهد قبلاً پرداخت شده یا در حال پرداخت است؟ | شمارهٔ فاکتور به‌تنهایی کافی نیست؛ فروشنده، مبلغ، واحد و وضعیت هم بررسی شوند. |
اگر بررسی مالکیت به سرویس بانکی وابسته است، فقط از مسیر مجاز و با مجوز لازم استفاده کنید. نام متفاوت می‌تواند توضیح قراردادی داشته باشد؛ با حدس، تطبیق ظاهری یا جست‌وجوی اینترنتی آن را رفع‌شده ثبت نکنید. استعلام معتبر هم فقط همان موضوع و زمان پاسخ را پوشش می‌دهد و تضمین سلامت کل معامله نیست.
تأیید دوم باید مربوط به همان نسخهٔ فاکتور باشد
پیشنهاد ما برای طراحی گردش کار سازمانی این است: ثبت‌کنندهٔ تغییر و تأییدکنندهٔ نهایی دو شخص مجاز و مستقل باشند. نفر دوم باید مبلغ، واحد، فروشنده، مقصد و دلیل تغییر را ببیند؛ فقط کلیک روی «تأیید» بدون دیدن اطلاعات، بررسی مستقل نیست.
- درخواست تغییر را با شناسهٔ فاکتور و نسخهٔ فعلی ثبت کنید؛ مقصد قبلی را پاک نکنید.
- نتیجهٔ تماس مستقل و مدارک لازم را در محل با دسترسی محدود ثبت کنید.
- نفر دوم همان نسخه و نتیجهٔ بررسی را بازبینی کند؛ در صورت اختلاف، پرونده به بررسی برگردد.
- اگر مبلغ، فروشنده یا مقصد تغییر کرد، تأیید قبلی را برای نسخهٔ تازه معتبر ندانید.
- پیش از اجرای واقعی، نسخهٔ تأییدشده را دوباره کنترل کنید؛ ثبت بررسی جای مجوز اجرای بانکی نیست.
این طراحی با اصل مجوزدهی تراکنش در OWASP هم‌راستاست: اطلاعات مهم مانند مقصد و مبلغ باید برای تأیید روشن باشند، کنترل در سمت سرور اعمال شود و تغییر داده‌ها اعتبار تأیید قبلی را از بین ببرد یا فرایند را از نو آغاز کند. جزئیات دو نقش و نسخه‌بندی در این مقاله، پیشنهاد طراحی ماست؛ جزئیات هر اتصال باید طبق راهنمای همان خدمت بررسی شود.
اگر پاسخ بانکی نرسید یا بررسی نامشخص ماند، چه کنیم؟
نبودن پاسخ، پاسخ مثبت نیست. پرونده را «نیازمند بررسی» نگه دارید و دلیل توقف را روشن بنویسید؛ خطا یا timeout را به تأیید خودکار تبدیل نکنید.
بررسی پیش از پرداخت را با نتیجهٔ خود پرداخت مخلوط نکنید. اگر اجرای پرداخت آغاز شده ولی پاسخ آن قطع شده است، ابتدا وضعیت همان تلاش را از مسیر رسمی بانک یا ارائه‌دهنده پیگیری کنید؛ فوراً پرداخت دوم نسازید. نمایش یک پیام موفقیت یا تصویر رسید هم جای نتیجهٔ معتبر را نمی‌گیرد. راهنمای بازگشت و تأیید پرداخت این تفاوت را توضیح می‌دهد.
اگر احتمال می‌دهید پول به مقصد نادرست رفته، سریع با بانک یا ارائه‌دهندهٔ پرداخت از کانال رسمی تماس بگیرید و شواهد را نگه دارید. امکان توقف یا بازیابی به وضعیت تراکنش و رویهٔ همان مرجع وابسته است؛ این راهنما وعدهٔ بازگشت پول نمی‌دهد.
چک‌لیست قابل استفاده برای تیم مالی
- هویت فروشنده و فرد مجاز درخواست‌کننده با پروندهٔ قراردادی تطبیق داده شده است.
- تغییر از کانال مستقل و ازپیش‌معتبر بررسی شده؛ اطلاعات تماس پیام جدید تنها مرجع نبوده است.
- مبلغ، ریال یا تومان، شناسهٔ فاکتور و مقصد در نسخهٔ مورد بررسی روشن هستند.
- وضعیت پرداخت‌های قبلی و تلاش‌های در جریان برای همان تعهد بررسی شده است.
- علت تغییر، نتیجهٔ بررسی، مسئول و زمان آن با دسترسی محدود ثبت شده‌اند.
- نفر دوم مستقل همان نسخه را بررسی کرده و تغییر بعدی نیازمند بررسی تازه است.
- پروندهٔ نامشخص مسیر ارجاع و مسئول پیگیری دارد؛ صرف فوریت، کنترل‌ها را حذف نمی‌کند.
این الگو را با قرارداد، سطح ریسک و سیاست داخلی سازمان خود تطبیق دهید. رمز، OTP و کلید API را برای بررسی فاکتور درخواست نکنید. مشخصات حساب و مدارک هویتی را در گروه عمومی، گزارش تبلیغاتی یا اسکرین‌شات قابل انتشار قرار ندهید؛ فقط دادهٔ لازم را با دسترسی مجاز نگه دارید.
این منطق را در سایا سپر تمرین کنید
در دموی سایا سپر می‌توانید سناریوهای ساختگیِ تغییر حساب، اختلاف ذی‌نفع، فاکتور تکراری و عدم دسترسی بانکی را ببینید و مسیر بررسی و تأیید نمایشی را دنبال کنید. هدف، نشان‌دادن ایدهٔ کنترل پیش از پرداخت است، نه صدور تأییدیه برای یک فروشندهٔ واقعی.
سایا سپر فعلی نمایشی است: استعلام بانکی واقعی ندارد، پول واقعی جابه‌جا نمی‌کند و حساب یا فاکتور واقعی دریافت نمی‌کند. تغییر دو نقش در این دمو را یک بازدیدکننده انجام می‌دهد و به معنی احراز هویت دو شخص مستقل نیست. گزارش نمایشی، رسید بانکی یا تضمین جلوگیری از تقلب نیست.
برای آزمون دمو از همان داده‌های ساختگی استفاده کنید. بررسی واقعی به دسترسی بانکی مجاز، کنترل سمت سرور، هویت مستقل افراد و بازبینی امنیتی نیاز دارد.
منابع و حدود این راهنما
منابع اصلی این مقاله، راهنمای FBI دربارهٔ جعل مکاتبات تجاری و راهنمای OWASP برای مجوزدهی تراکنش هستند. این منابع برای اصول عمومی امنیت استفاده شده‌اند، نه بیان مقررات ایران، تأیید مجوز سایاپی یا معرفی شریک بانکی آن. جدول، مثال و چک‌لیست، الگوی آموزشی پیشنهادی سایاپی هستند.
این مقاله با کمک هوش مصنوعی تدوین شده است و جایگزین قرارداد بانکی، مشاورهٔ حقوقی یا بازبینی امنیتی نیست. خطای محتوا را از تماس با سایاپی گزارش کنید.