3月に私たちは、Nacha の新しい不正監視ルールと、それが地域銀行や信用組合にとって何を意味するのかを徹底解説する記事を公開しました。そこで、ODFI と RDFI の責任の違い、実務上「合理的なモニタリング」がどのようなものか、そしてこれらのルールがテクノロジーを購入することそのものよりも、意図を持って備えることに重きが置かれている理由について説明しました。
もしまだご覧になっていない場合は、まずそちらから読むことをおすすめします。
当時、多くの地域金融機関はその記事を読んで、こう考えたかもしれません。「これはまだ自分たちには関係ないだろう」
さて、2026年6月22日（ジューンティーンスの祝日により実務上の発効日となる）をもって、それは変わります。
Nacha のリスク管理規則改正のフェーズ 2 では、不正監視要件が、フェーズ 1 の対象外であった残りの非消費者オリジネーター、サードパーティサービスプロバイダー（TPSP）、サードパーティセンダー（TPS）、および RDFI にまで拡大されます。
言い換えると、これまで対象外だったとしても、今は対象になっている可能性が高いということです。
だからといって、慌て始める必要があるというわけではありません。Nacha は依然として、地域銀行や信用組合に本来の姿からかけ離れた存在になることを求めているわけではありません。焦点はこれまでと同じです。リスクベースのプロセスと手順を導入し、不正を特定することを合理的に意図したものとし、そのアプローチを文書化し、定期的に見直すことです。
本ブログでは、これまでの議論を踏まえ、これらの要件がより広範なACHエコシステム全体に適用されるようになった今、フェーズ2が何を意味するのかに焦点を当てて解説します。
フェーズ2では何が違うのか？
Nacha が 2023 年にこれらの変更を提案した際、多くの機関は、新たな不正監視要件によって高額なシステム導入や画一的な対応を求められるのではないかと懸念しました。
最終規則では異なるアプローチが取られました。元の提案から最終規則に至るまでに、いくつかの重要な変更が加えられました。
- この用語「commercially reasonable」は削除されました。
- 「検知システム」は「プロセスおよび手順」に変更されました。
- モニタリングは適用されるのは、「その主体が果たす役割に関連する範囲に限られる。」
- モニタリングは事前処理の段階では必須ではありません。
- 機関は自らの業務プロセスおよび手順を見直さなければなりません。少なくとも年に一度は実施する必要があります。
これらの変更には重要な意味があります。Nacha は、各機関が自らの規模・複雑性・リスクプロファイルに合った管理策を導入できるよう、意図的に柔軟性を持たせました。ここで求められているのは、市場で最先端の高度なテクノロジーを持つことではありません。不正を見抜くことを合理的に意図した、よく考え抜かれたアプローチを取ることが重要なのです。
翻訳： このルールは、システムを購入することよりも、自分たちのプロセスをきちんと説明できることのほうを重視しています。
不正監視：今やすべての人に
フェーズ2では、フェーズ1の対象外となっていた残りすべての非消費者オリジネーター、サードパーティサービスプロバイダー（TPSP）、およびサードパーティセンダー（TPS）にも、不正監視要件が拡大されます。
期待される内容は明確です。
不正に起因して発信されたACHエントリーを特定することを目的として、リスクベースのプロセスおよび手続きを策定し、実施すること。
ルールに書かれていないことに注目してください。
- リアルタイムでの監視は求められていません。
- 事前の処理確認は不要です。
- また、特定の技術やベンダーを指定するものではありません。
その代わりに、Nacha は各機関がさまざまな方法で不正を管理していることを認識し、アップストリームでのデューデリジェンスや第三者モニタリングを含み得る多層的な管理手段を認めています。
多層的な管理手段が認められています
ODFI の不正監視プログラムは、次のような複数層の管理策に依拠する場合があります。
- 送金依頼人のオンボーディングおよびデューデリジェンス
- プロセッサーまたはTPSPの監視業務
- トランザクションのメタデータおよびリスクスコアリング
- 過去の不正取引事例とアラート閾値
- 例外報告および定期的なレビュー
どの単一のレイヤーも、それだけで機能することは想定されていません。複数のレイヤーによるコントロールが連携して、妥当なリスクベースのアプローチを構成し、それらのコントロールへの依存関係が理解され、文書化されていることが期待されています。
これは、サードパーティの送信者や処理業者と連携している金融機関にとって特に重要です。
Nacha は明確に、ODFI が自らのプロセスや手順を設計する際に、起点となる取引プロセスに関与する他の参加者が不正監視のために講じている措置を考慮することを認めています。機関は、すでに支払いフローの他の箇所に存在している管理策を重複して実施することまでは求められていません。
しかし、それらの管理策に依存するためには、その内容を理解している必要があります。文書化のない盲目的な信頼は、リスクベースの監督とは同じではありません。
多層化すればよいというわけではない
多層防御について話すとき、それはツールを増やし、アラートを増やし、ベンダーを増やすことだと考えがちです。しかし、多層化は必ずしも「数を増やすこと」を意味するわけではありません。
既存のソリューションプロバイダーが機関のニーズを満たしていないのに、その上に次々と新しいテクノロジーを積み重ね続けるわけにはいきません。答えは、ただ追加することではなく、すでに持っているレイヤーを厳しく見直すことにある場合もあります。
5年、10年、あるいは20年前に導入したベンダーが、いまの不正対策の状況に追いついていないのであれば、その関係性を見直しても問題ありません。目標はテクノロジーを集めることではなく、貴機関にとって意図的で効果的に機能するプログラムを構築することです。
今日の環境では、現状維持のままでは通用しません。詐欺は進化しており、それに合わせて私たちの管理体制（およびベンダーとのパートナーシップ）も進化させなければなりません。
RDFI ACHクレジット監視：すべての対象者に適用
2023年における年間ACH受領件数が1,000万件を超えるRDFIにのみ、3月のフェーズ1要件が適用されました。
6月22日以降、これらの要件は残りのすべてのRDFIにも適用されるようになりました。
もしあなたがRDFIであれば、最も重要な確認事項の一つは変わっていません：この規則では、ACHクレジットエントリーの事前（ポスティング前）モニタリングは要求されていません。
歴史的に、RDFI は振替記帳前に ACH クレジットを積極的にモニタリングすることは求められていませんでした。クレジットが例外レポートに計上されず、強制記帳や修正もされなかった場合、一般的には責任は ODFI に帰属していました。
その原則は変わっていません。
変わったのは可視性です。
RDFI は、入金取引、口座の特性、および過去の取引履歴を独自の視点から把握しており、資金が入金された後に不正を見抜ける可能性があります。
リスクベースのアプローチでは、次のような要因を考慮する場合があります。
- 取引の頻度
- アカウントの年齢
- 平均残高
- SECコードの異常
- 過去の口座行動
これらの概念に聞き覚えがあると感じるなら、それは当然のことです。多くの機関ではすでに、マネーロンダリング対策（AML）や不審取引監視、不正対策業務などを通じて、同様のモニタリングを日常的に行っています。
この規則は必ずしも新しい機能を生み出しているわけではありません。多くの場合、すでに存在している機能を形式化しているに過ぎません。これは考え方の転換を意味します。
正直に言うと、私はこのルール改定が本当に気に入っています。受信したACHファイルや口座の取引状況をより一貫して可視化できるようになることで、積極的に不正対策に取り組む人たちに有利に働くと思うからです。その可視性によって、リスクをより早期に特定し、資金が消える前に不正を未然に防げる可能性が高まります。
さらに重要なのは、このルール変更が私たちを次のような考え方から脱却させてくれることです。
「私たちに法的責任がないなら、それは私たちの問題ではない。」
COVID禍でPPPローン詐欺が最も横行していた頃、私は異常に大きな入金がないか、受信したACHファイルを確認していたことを覚えています。過去12か月の平均残高が1,000ドル未満のビジネス口座に、突然6桁台のPPP入金が行われているケースがあったのです。
たしかに、私の所属する金融機関はその取引について法的な責任を負わなかったかもしれません。ですが、あれほどまでに口座の履歴とかけ離れた動きを、良心に照らして見て見ぬふりなどできるでしょうか？
BSAチームが不審な取引を監視し、調査し、報告してくれることは分かっていました。でも、事後に不正を報告することは、不正を未然に防ぐこととは違います。
私がこの規則を評価しているのは、そこです。この規則は、金融機関に予言者になることを求めているわけではありません。むしろ、不正対策にあたる人たちがより主体的に動き、「何かおかしい」と気づいたときに、不正行為者が資金を動かす前に適切な対応を取れるようにしてくれるのです。
虚偽の口実：おなじみの問題に対する新たな定義
そして、「何かが筋が通らないとき」といえば、規則へのより注目すべき追加点の一つが、新たに定義された用語の導入です。
虚偽の口実
「(a) 自身の身元、(b) 他の者との関係性またはその者を代理して行動する権限、あるいは (c) 入金されるべき口座の所有権について、ある者が事実と異なる説明をすることによって支払いを誘導する行為。」
この定義には、金融機関などがすでに日常的に直面している多くの詐欺事例が含まれています。例えば、次のようなものがあります。
- ビジネスメール詐欺（BEC）
- ベンダーなりすまし
- 給与詐称
- その他の受取人なりすましの手口
重要な点として、この定義は、詐欺的な、あるいは粗悪な商品やサービスに関わる詐欺には当てはまりません。 私たちは、この点についてさらに詳しく説明したガイドを作成しました。詳しくは、こちらをご覧ください。
多くの点で、Nacha は詐欺対策の専門家たちが長年理解してきたことを明文化しようとしています。つまり、詐欺は必ずしも「不正アクセス」だけを意味するわけではありません。ときには、だまされて行われた「正規の支払い」である場合もあるのです。
しかし、支払いがどのような状況で開始されたのかを知らない場合、RDFI はどのようにして、虚偽の口実のもとで承認された可能性のある取引を特定できるのでしょうか？
Nachaによると、金融機関は次のように、取引エントリーと受取口座の両方の特性を考慮する場合があります。
- 受取口座の種類と一致しない標準エントリー分類（SEC）コード（例：法人向けのCCDエントリーが個人の口座に送金される場合など）
- 口座にとって高額な取引であり、通常とは異なるもの
- 短期間に受け取る類似した入金が繰り返し行われること（複数回の給与振込や給付金の支給など）
- 上記のいずれかが発生している新規口座、休眠口座、またはマネーミュールの可能性がある口座
これらの状況に聞き覚えがあるなら、それもそのはずです。これらは多くの場合、詐欺対策チームが長年監視してきたものと同じ兆候だからです。
現在の違いは、Nacha がこれらの種類のパターンを、合理的でリスクベースの ACH クレジット監視アプローチの一部として明確に認識したことです。
重要なのは、異常値を特定したからといって、その取引を自動的に返却しなければならないという意味ではないということです。
RDFI は、クレジット入金に対する資金利用可能要件の任意の免除を活用し、取引内容や口座の動きを精査するための追加時間を確保することができます。また、各機関は、疑問点が生じた際に ODFI と連絡を取るために、Nacha の Risk Management Portal や ACH Contact Registry を活用することもできます。
また、RDFI がある取引が無権限である、または虚偽の名目で権限が与えられた可能性があると判断した場合、当該金融機関はその取引を次のコードを用いて返却することができます：リターン理由コード R17（「QUESTIONABLE」）、または ODFI の要請により、リターン理由コード R06。
これらすべての例に共通する点は、いたってシンプルです。
不正行為が確実だとはっきり分かる形で現れることはほとんどありません。多くの場合、ただ理屈に合わない行動として姿を見せます。
最大の影響の一つは、社内コミュニケーションかもしれません
これらの規則改定の中には、重要な業務上の現実が隠れています：不正行為は、たいてい一つの部署だけにきれいに収まるものではありません。
ACHモニタリングは、ますます次の領域の交差点に位置するようになっています。
- 不正行為
- オペレーション
- コンプライアンス
- 製品
- 財務管理
- リレーションシップチーム
成功を収めるのに最も有利な立場にある機関が、必ずしも最先端のテクノロジーを持つ機関とは限りません。
明確な責任の所在があり、再現性のあるプロセスを持ち、意思決定が文書化され、チーム間のコミュニケーションが円滑な組織こそが成功するでしょう。
本当に伝えたいこと
フェーズ2は、地域銀行や信用組合の業務内容を根本的に変えるものではありません。むしろ、多くの金融機関がすでに行ってきた取り組みを制度化し、他の機関にもより意図的・計画的に取り組むことを促すものです。
Nachaは、すべての不正取引を見つけるよう金融機関に求めているわけではありません。
彼らは、金融機関に対して自らのリスクを把握し、妥当な管理策を実施し、その取り組みを文書化し、そうしたプロセスを定期的に見直すことを求めています。
多くの機関では、そのための基盤はすでに整っています。
今こそ、それらをつなげることが求められています。
なぜなら、不正が起きたときに問われるのは、あなたの金融機関が完璧なシステムを持っていたかどうかではなく、自分たちのリスクを理解し、適切なプロセスを整え、次に何をすべきかを把握していたかどうかだからです。
