依頼者と実行する変更を確認する

経理担当に、取引先が普段使うアドレスから口座変更書類が届いたとします。ただし、同じアドレスでもアカウントが侵害されている場合があります。社内の承認アカウントが有効でも、承認者が見たのが変更前の口座なのか、最終版なのかを確認します。米FBIのインターネット犯罪苦情センター（IC3）は、正規の業務用アカウントから不正送金を誘うビジネスメール詐欺（BEC）を説明し、口座情報の変更は別経路などで確認するよう勧めています。 FBI IC3 — Business Email Compromise[1]

同機関は2024年12月、生成AIによる文章、音声、動画を金融詐欺に使う手口を警告しました。声や文体の違和感は確認を始めるきっかけになります。確認を適用するかは新規口座、緊急送金、連絡先変更のような処理の影響で決めます。合成された内容か判明していなくても、未確認の変更は保留できます。 FBI IC3 — Criminals Use Generative Artificial Intelligence to Facilitate Financial Fraud[2]

別の連絡手段でも、番号やリンクが最初の依頼に由来すれば独立性は下がります。添付書類の電話番号、返信で案内されたチャット、依頼ページのボタンは同じ発信元に依存する場合があります。取引先の登録時に確認した代表番号、既存の担当窓口、社内名簿や管理された承認システムを使います。着信した電話は切って、確認済みの番号へかけ直します。着信表示のみで変更を承認しません。

振込先と確認用の連絡先は一度に変えない

取引先のマスターデータには、法人の識別情報、承認済みの口座、確認に使う連絡先などがあります。口座と連絡先を同時に変え、新しい連絡先で新口座を確認すると、依頼そのものが証拠になります。まず登録済み経路を使い、連絡がつかなければ定められた再確認手順に切り替えます。確認済みの代表番号から担当につないでもらうなど、取引先管理方針に沿った手段を使います。

表は支払いとアカウントに影響する処理の例です。金額の基準は組織の決裁ルールに合わせます。新規口座、取引先マスターや本人確認手段の変更は、その後の業務にも影響するため少額でも区分します。

依頼依頼と独立した確認経路承認・確認者最低限の記録
新規の振込先・口座変更確認済みの担当または代表番号取引先マスター管理者と別の経理承認者取引先と変更ID、新旧口座の参照、経路と時刻
担当者の連絡先・メールの変更変更前の連絡先または所定の再確認データ管理者と取引先の業務責任者既存の確認根拠、新たな確認結果、適用時刻
経営者による緊急支払い社内名簿や承認システム支払い承認権限者と実行担当の確認者目的、金額、口座、承認版、支払い結果
登録済み口座への通常の支払い購買、検収、請求と登録口座を照合通常の支払い承認者契約、請求、支払い依頼のID、確認時刻
経理用アカウントの復旧・認証手段の再登録確認済みの社内サポート手順身元確認担当とアカウント管理者変更者、承認の参照、認証手段とセッションの処理
既存の窓口につながらない新規振込先承認済みの再確認または新規登録指定の経理・購買責任者と取引先登録担当旧経路の結果、代替手段、例外範囲、未確認事項

同じ人が二つの役を兼ねても、独立した確認は一回です。確認者と承認者を分け、同じアカウントが両方を実行できるか確認します。小規模な組織では実際に応答できる代理者と連絡順を用意します。二人目にも対象、変更前後の値、目的、確認資料を見せます。

承認後に重要な取引情報が変わったら、その版を新しい承認に回します。支払いシステムの取引IDと変更版を、承認者が見た画面の情報と照合します。実行値への結びつけと直前の確認は、OWASP — Transaction Authorization Cheat Sheet[3]を参照できます。

サービスの仕組み

要件から承認までつながる根拠 — 要件、テスト、不具合対応、承認記録をつなぎ、共通の基準で品質を判断します。

同じ取引に関係する二つの依頼で訓練する

架空の製造会社に「ハンドゥル部品」の新口座を伝えるメールが届き、続けて経営者に似た声から支払いを急ぐよう電話が入ります。メールには添付の新しい番号だけが使えるとあります。架空の資料で承認経路を試します。

  1. 受付と実行を分けます。 口座変更の案件を登録し、旧口座と支払いの現在状態を見ます。未処理の支払いなら確認中にします。
  2. 取引先と社内の承認依頼をそれぞれ確認します。 口座は取引先名簿、経営者からの依頼は社内の名簿や決裁手順から確認します。
  3. 確認した取引を承認画面に示します。 目的、金額、取引先、口座、適用文書を一つの版にまとめます。承認後の変更は履歴と経路を確認します。
  4. 正規業務に生じる待ち時間を測ります。 既存窓口に応答がなければ購買と経理に共有し、正当な変更を再開する条件を決めます。
  5. 不一致や疑いを経理・セキュリティに引き継ぎます。 取引やアカウント、他の支払い指示を確認し、不審なスレッドで承認手続きを続けません。

見慣れた電話番号やメール、書類を組み合わせて試せます。実際の経営者からの依頼と正規の口座変更を組み合わせるケースも用意し、必要な確認にかかった時間と再開できるかを確認します。誤承認と正規取引の未解決をそれぞれ失敗条件にします。

緊急時は承認経路を速める

通常業務が遅れ続けると、緊急依頼で確認が省かれやすくなります。連絡できる担当、承認範囲、独立した確認先、短縮できる待ち時間を決めます。夜間に新規の振込先を確認できなければ、保留して日程を調整するか、契約条件に照らして確認済み口座への支払いを検討します。例外が今後のマスターデータに反映されないようにします。

依頼受付、確認完了、支払い反映の時刻を分けて記録します。担当者の不在、取引先の無応答、書類の不一致を記録すると待ち時間の理由が分かります。取引先の名簿が繰り返し使えない場合は、登録情報の責任者と更新周期を決めます。

訓練・運用点検期待する結果失敗時の改善
新口座と連絡先が同時に届く既存経路で確認し、変更を別々に記録提案された連絡先を証拠へ自動入力する経路を直す
発信者が確認を拒み期限を迫る代理承認者への連絡、または保留と独立した確認緊急窓口と応答できる時間を見直す
承認後に金額や口座が変更される旧承認を拒否し、変更した版を再承認承認のひもづけと編集権限を直す
正規の取引だと確認できる保留を解除して所定の処理へ戻す保留キュー、責任者、交代時の引き継ぎを点検

実行済み、または結果が分からない場合

未処理なら対象の変更を保留し、どのアカウントが何を変更したか調べます。実行済みの疑いがあるか結果が不明なら、既存の取引IDを経理担当者と金融機関の公式窓口で照合します。状態が分からないまま同じ金額を送らないようにします。台帳と金融機関の状態が違えば、突合の担当と次の確認時刻を決めます。取消・返金の可否は金融機関と社内手順で確認します。

原本のメッセージ、必要なヘッダー、時刻、変更と承認の記録、取引IDはアクセスを制限した場所に保存します。金融情報の転送を絞り、アカウント侵害の疑いはセキュリティと運用に引き継いで履歴、セッション、認証手段を確認します。別の資格情報が漏れた場合は、シークレット流出への対応の失効と使用先の確認も参照します。

通常の支払い条件と調査の証拠に従って保留を解除します。振込先の復元と、誤った設定時に支払いが発生していないかの確認を別々に記録します。NISTのインシデント対応ガイド[4]とインシデント対応ランブックは、初動、対処、復旧確認、後続の担当を明確にする参考になります。