本コラムでは、反社チェックを自動化するシステムをつくるとすれば、どのような要件を最低限満たさなければならないか？ということを米国OFAC規制の違反事例などを参考に考察してみる。

 

OFAC規制とは、米大統領が米国の安全保障・外交政策・経済に異常かつ重大な脅威を及ぼすとして指定した国・個人・団体の在米資産を凍結し、これらの者との取引を禁止する措置を講ずる規制である。

 

米国財務省の外国資産管理室（Office of Foreign Assets Control：OFAC）がこの規制を統括するからOFAC規制とよばれる。指定された者のリストはOFACが管理し公表している。OFAC（米国財務省）のホームページ内で検索できるし、データをダウンロードすることもできる。

 

OFAC 規制を遵守するためには、取引先等（その候補）がこのリスト（OFACリストと呼ぶことにする）に載っていないかどうかをチェックする必要がある。

 

（中身は日々変動するものの）決まりきったリストに対して検索を行うこの作業は、一見すると単純で簡単のように見えるが、実は難点もあり、十分なスクリーニングが出来ていないとして当局に摘発される事例も見受けられる。こうした違反事例などから示唆を受けながら反社チェックの自動化の要件を考えてみる。

 

なお、筆者は自動化など無理であるし、すべきでないと考えている。反社チェックは、OFACリストの検索のように決まりきったリストに対する一発のスクリーニングで済むものではない。

 

百歩譲って決まりきったリスト(それがどんなデータを含むかも重大な問題であるが今回は議論しない)に対する自動的なスクリーニングで済ませようとする土俵に立って、以下、議論する。

 

OFAC規制から示唆される自動化システムが備えるべき最低要件は次のとおりであると考える。

 

■自動化システムの最低要件

①ゆらぎ（誤記・変名など）に対応していること

②地理情報をチェックすること

③顧客の顧客もチェックすること

　④支配構造を明らかにし、親会社等もチェックすること

　

順に見ていこう。

 

①　ゆらぎへの対応

「ゆらぎ」への対応とは、取引の申込者（＝チェック対象）が住所を記入する際に、キューバをCubaではなくKubaと書いたり、スーダンをSudanではなくSoudanと誤記したとしても、それらが制裁対象国（Cuba・Sudan）からの申し込みであると検知できるようにするということだ。

 

例えば制裁対象国の顧客と取引したことにより米当局に民事制裁金を支払うに至った世界的な通販会社A社のスクリーニング・プロセスでは、Krimea（誤記）をクリミア（Crimea）として検知しないようなシステムで運用したことでリスクを見逃した。米当局はこうした「ゆらぎ」に対応しない硬直的なシステムでの運用は制裁コンプライアンスに違反するとした。

 

反社チェック（自動化システム）への示唆としては、例えば齋藤の「齋」を、「斉」と（敢えて）記入するような申込者もいるだろうから、こうした漢字表記の「ゆらぎ」も想定したシステムでないと「自動化」するのは危険だということだ（手動のチェックでは、ゆらぎの生じやすい漢字には個別に注意を払っている方が多いと思われる）。

 

②　地理情報の照合

地理情報の照合とは所在地・住所のチェックである。先の通販会社Ａ社では、申込者の住所が制裁対象国内にあるかの照合は行われず、その結果、商品が制裁対象国に発送されてしまった取引が何件もあったとされる。OFACのリスト情報には制裁対象者（人・組織）の住所・所在地の国名が格納されているから、これらと住所との照合を行っていればリスクを検知できたはずである。それを省く自動化システムではOFACの基準でコンプライアンス違反となりかねない（制裁金の加重要因となりかねない）。

 

反社チェック（自動化システム）への示唆としては、やはり地理情報のチェックは重要であり欠くことができない工程だということだ。手動の反社チェックでは所在地・住所の検索は常識的（必須的）な作業である。ネット検索すれば警察が公表する特殊詐欺のアジトがヒットする場合もあるし、「詐欺会社」などが入居するとして悪評が付着したビルがヒットすることもある。同じ場所の別法人が問題会社であるといった場合もある。このように手動でさえ短時間に簡単に検出できるリスクを自動化によって見逃してはならない。少なくとも、地理情報を、ネット、地図（テナント情報含む）、法人番号検索サイト（休眠会社を含む同所法人のリストアップ）などと照合し、そこで検出された関係先までチェックをかけるような自動化システムでなければ危険だ。

 

③　顧客の顧客もチェックすること

顧客の顧客を知る（KYCC：Know Your Customer’s Customer）、すなわち取引先のその先も調べなければならないという原則は自動化システムでも貫徹すべきである。

 

たとえば決済代行会社Ｂ社は、顧客（加盟店）が商品を販売した先（＝バイヤー）からデジタル通貨で販売代金を受け取り、手数料を差っ引いたうえで、顧客（加盟店）に法定通貨で代金を支払うビジネスを行っているが、昨今、複数の制裁プログラムに明らかに違反しているとして米当局に民事制裁金を支払うに至った。

 

Ｂ社のスクリーニング・プロセスでは、顧客（加盟店）についてはOFACリストとの照合や地理情報のチェックを行っていたが、顧客の販売先（バイヤー）まではチェックしていなかった。バイヤーの名前や住所、メールアドレスや電話番号、IPアドレスなどの情報を得ることはあったが、それらの情報に基づいたチェックをすることはなかった。その結果、バイヤーの中に、クリミア、キューバ、北朝鮮、イラン、スーダン、シリアなど制裁対象国の者が混入するに至った。

 

反社チェックへの示唆としては、合理化・効率化は単なる手抜きであってはならないということだ。特にＢ社のように顧客の顧客まで接するビジネスではKYCだけでは不十分でKYCCまでカバーする自動化システムでないと危険だということだ。甘い審査の会社にはそれに応じた顧客が群がり客層がグレーになるという法則も忘れてはならない。

 

④　支配構造を明らかにし、親会社等もチェックすること

OFAC規制では制裁対象者（個人・団体）が50％以上出資する団体も制裁対象者と同視され資産が凍結される（50％ルール）。従って、取引相手（＝チェック対象会社）へ50％以上出資する者（個人・団体）が誰なのか、そしてその者が制裁対象かどうかをチェックしなければならない。

 

例えば、「最終親会社Ｘ社→Ｙ社→Ｚ社」という形で50％以上の支配が連鎖する場合、Ｚ社を調べる際にはＸ社まで遡ってＸ社がOFACリストの制裁対象者であるかをチェックしなければならないということだ。Ｘ社が制裁対象であるならばＺ社が制裁リスト（OFACリスト）に載っていなくても制裁対象者と見なされるということだ。

 

また、例えば、Ｆ社の株主にＧ社（45％保有）とＨ社（６％保有）がいるとする。Ｇ社・Ｈ社ともに制裁対象者ならば、その株式保有割合の合計が50％以上となるのでＦ社の資産は凍結される（＝取引禁止）。従って、株式の保有割合の合計の組み合わせが50％以上になる株主すべてについて、制裁対象者であるかどうかを調べなければならない。

 

支配構造については、有価証券報告書や欧州の登記情報などの公開情報、信用調査書などの情報をシステマティックに紐づけて（知れている範囲での）相関図（樹形図）のようなものを作ることができるかもしれない。

 

支配構造が多層であれば上流のいずれかの個人・団体が制裁対象に指定された際にそれをタイムリーに把握するのは難しいだろう。下流に位置する直接の取引先がいつの間にか上流における指定の影響で資産凍結対象となっていることもあり得る。そういった変化を自動的かつタイムリーに知らせてくれるシステムがあれば非常に有用だと思われる。

 

ただし、何でもそうだが数値で規制すると必ずそれを逃れようとする輩がいることに留意が必要だ。50％が基準であれば株式の保有割合40％にしておいて他の手段で実質的にコントロールするなど迂回行為も想定されよう。そういった実態ベースでの支配構造の解明は自動化できないだろう。

 

■反社チェックに使える相関図は自動作成できない

上場会社であれば有価証券報告書や大量保有報告者などの株主・出資者の情報、未上場会社であれば信用調査書などに記載されている株主や関係会社を上手く自動的に紐づければ何らかの相関図を描くことは出来よう。そのようなことは出来ないのですか？と聞かれたこともある。しかし、筆者の肌感覚としてそういった情報だけを繋ぎ合わせた相関図は反社チェックにおいてあまり意味がないと思う。反社チェックでは調査会社などの調査を拒否するか、受けたことがないようなペーパーカンパニーや休眠会社（＝データベースにない会社）が関係性を紐解いていくうえで非常に重要な意味を持つことが多い。上場会社の増資割当先が丸きりのペーパーカンパニーであることが往々にしてあるし、それが海外の会社であれば尚更実態がわからないことも多い。しかし、それでも住所情報などを手掛かりに何らかの関係性を見出そうとする作業が反社チェックにおいて重要な意味を持つ。こうした作業は自動化できるとは思えない。有意味な相関図はやはり人の手に頼らざるを得ないというのが私見である。

 

以上、OFAC規制を参考に反社チェックの自動化のあり方を考察してみた。結論、完全な自動化は難しい。出来る範囲での省力化（複数のワードを記事データベースで一括検索できるようにするなど）を地道に図っていくしかないだろう。

 

H.Izumi