পরিচিত supplier-এর email thread-এ নতুন invoice এল: “আগের bank account বন্ধ, আজই এই account-এ payment করুন।” Logo, signature এবং invoice number সব চেনা। তবু bank details বদলানো একটি গুরুত্বপূর্ণ verification point। Attacker নকল domain ব্যবহার করতে পারে, আবার আসল mailbox compromise করেও পুরোনো conversation-এ ঢুকতে পারে। তাই পরিচিত দেখালেই payment release করবেন না। এই guide accounts team ও ছোট business owner-কে beneficiary change যাচাই, approval record এবং ভুল transfer হলে দ্রুত response গুছিয়ে নিতে সাহায্য করবে।

Payment instruction বদলালে pause দিন

নতুন account number, beneficiary name, payment method বা অন্য company-র account ব্যবহার করতে বলা হলে routine invoice processing থামান। “আজ না দিলে service বন্ধ” ধরনের urgency verification বাদ দেওয়ার কারণ নয়। Pending invoice legitimate হতে পারে, কিন্তু নতুন payment destination আলাদা করে approve করতে হবে। Staff-কে এমন rule দিন যাতে সন্দেহজনক request pause করার জন্য শাস্তি না হয়। Genuine supplier verification delay বুঝতে পারবেন; অচেনা contact-এর চাপের কাছে control ছেড়ে দেবেন না।

আলাদা trusted channel-এ callback করুন

FBI-এর Business Email Compromise guidance payment procedure বা account number বদলালে independently verify করতে বলে। নতুন email-এ দেওয়া phone number নয়, আগে থেকে approved vendor master বা contract-এর number ব্যবহার করুন। পরিচিত supplier contact unavailable হলে request pending রাখুন। Suspicious message-এর Reply দিয়ে confirmation চাওয়া একই compromised channel-এ ফিরে যাওয়া। Video call বা voice চেনা লাগলেও প্রয়োজনীয় independent record check বাদ দেবেন না।

Invoice ও vendor master আলাদা মিলান

Order reference, goods/service, amount এবং invoice number নিজের purchase record-এর সঙ্গে মিলান। এরপর beneficiary name, account details ও bank change request approved master-এর সঙ্গে compare করুন। Display name দেখেই sender চিনবেন না; full email address এবং reply-to দেখুন। তবে address ঠিক থাকলেই নিরাপদ নয়—আসল account-ও compromise হতে পারে। PDF-এর সুন্দর layout বা logo ownership প্রমাণ নয়। Bank letter attached থাকলে সেটিকেও একই request-এর evidence হিসেবে ধরুন, independent verification-এর বিকল্প হিসেবে নয়।

Change approval-এ দ্বিতীয় reviewer রাখুন

একই ব্যক্তি email পড়ে bank master বদলে payment release করলে একটি ভুলেই টাকা বেরিয়ে যেতে পারে। ছোট team হলেও beneficiary change এবং payment approval-এ দুইজনের review রাখুন, যেখানে সম্ভব। Verification note-এ old detail, requested new detail, independently contacted person, time ও approver লিখুন। Full account number সাধারণ chat বা public task board-এ ছড়াবেন না; restricted record রাখুন। Genuine change approve হলে effective date এবং কোন invoices-এ নতুন account প্রযোজ্য তা পরিষ্কার করুন।

একটি supplier request-এর practical example

ধরুন printing supplier-এর মাসিক invoice এসেছে, কিন্তু নতুন account beneficiary অন্য ব্যক্তির নামে। Accounts operator payment hold করলেন এবং vendor master-এর number-এ ফোন করলেন। Supplier জানালেন তাঁদের bank বদলায়নি। Team original message ও attachment রেখে supplier-এর known contact-কে সতর্ক করল; security team mailbox access review করল। এখানে invoice amount সত্যি ছিল, শুধু destination বদলানো হয়েছিল। তাই “আমাদের সত্যিই টাকা বাকি আছে” যুক্তি account change বৈধ করে না। এটি illustrative scenario, কোনো বাস্তব supplier-এর বিরুদ্ধে অভিযোগ নয়।

ছোট test transfer-কে পরিচয়ের proof ভাববেন না

এক টাকা বা ছোট amount পাঠিয়ে receiver টাকা পেয়েছেন বললে শুধু account কাজ করছে বোঝা যায়। Scammer-ও receipt confirm করতে পারে। Beneficiary name display bank বা payment service অনুযায়ী ভিন্নভাবে দেখা যেতে পারে; mismatch উপেক্ষা করবেন না। নিজের bank-এর supported verification feature ব্যবহার করুন, কিন্তু callback ও approval rule বজায় রাখুন। Payment reference-এ sensitive invoice detail অপ্রয়োজনে লিখবেন না। সন্দেহ মেটেনি এমন account-এ test payment-ও release না করাই নিরাপদ operational choice।

Highlighted payment-change checklist

  • Pause: নতুন beneficiary বা payment procedure routine flow থেকে আলাদা করা হয়েছে।
  • Source: sender, reply-to, invoice ও purchase reference মিলিয়ে দেখা হয়েছে।
  • Callback: আগে থেকে জানা contact দিয়ে independent confirmation নেওয়া হয়েছে।
  • Identity: requested account-এর beneficiary ও business relationship ব্যাখ্যা করা হয়েছে।
  • Approval: দ্বিতীয় authorised reviewer master change ও payment দেখেছেন।
  • Record: verification evidence restricted location-এ রাখা হয়েছে।
  • Release: সন্দেহ মেটার পরেই approved destination-এ payment করা হয়েছে।

ভুল transfer হলে bank-কে আগে জানান

অবিলম্বে নিজের bank-এর official fraud বা support channel-এ যোগাযোগ করুন। Transaction reference, সময়, amount এবং beneficiary detail দিন; recall বা hold সম্ভব কি না জিজ্ঞাসা করুন। টাকা ফেরত আসবেই এমন guarantee নেই, তাই দেরি করবেন না। Email thread, original attachment ও payment record সংরক্ষণ করুন। ভারতে cyber financial fraud reporting-এর জন্য government portal বা official helpline-এর current instruction অনুসরণ করুন। অপরিচিত recovery agent টাকা ফেরানোর নামে advance চাইলে দেবেন না।

Incident-এর পরে শুধু invoice বদলাবেন না

নিজের বা supplier-এর mailbox compromise সন্দেহ হলে security team দিয়ে sessions, forwarding rules, delegated access ও authentication review করান। অন্য pending payment-এ একই instruction গেছে কি না খুঁজুন। Beneficiary master-এর recent changes review করুন এবং staff-কে incident থেকে পাওয়া নির্দিষ্ট warning জানান। প্রতিটি email-কে scam বলা কাজের নয়; destination change-এ consistent verification দরকার। Routine callback ও approval record থাকলে genuine supplier change-ও দ্রুত এবং traceableভাবে করা যায়।