図11において「管理企業」側は、「契約企業」（この図のログインは、個人でのログイン）のユーザーID／パスワードを保有していない。「契約企業」側の個人がログインした場合、フェデレーション先（例えば、Facebook）に対し「IPアドレス192.168.1.1というマシンから、xxxxx/yyyyyというログインが来た」ことになる。Facebook側は指定されたIPアドレスかつ、APIに準拠されたCALLに対して、ディレクトリを検索した結果、該当ユーザーID／パスワードが存在したため、「ok」と応答する。すると「管理企業」側は、実在する「契約企業」と判断し、処理をする。
さらに、二要素認証として、実際にクレジットカードで決済をする際、実在するクレジットカードの所有者か、2回目の本人確認をクレジットカード会社側で行う。クレジットカード会社側から「ok」の応答があると、全ての処理が完結する例である。この例は、あくまでSOAを利用したコンシューマーのビジネスでの場合である。これまでの「法人の企業間取引」では、ここまで進んでいない。まだ「法人の企業間取引」では、会社を代表するユーザーID／パスワードを使い回す傾向がある。
第1回記事で「メッシュ型」を説明したが、「（大学間認証連携など）コンシューマーのビジネス」では、メッシュ型の構成が実装されているものの、「法人の企業間取引」では事例が少ない。論理的には、この構成は可能である。しかし、個人所有のユーザーID／パスワードで「法人の企業間取引」をそもそもしてよいのか、議論が煮詰まっていない。このように「法人の企業間取引」でのSOAや「メッシュ型」の構成が普及しない結果、コンシューマーライゼーションITがうまく機能しないのは誠に残念である。それでは、リスク面においても「コンシューマー・ビジネス」と「法人の企業間取引」では、違いがあるのだろうか。
表１ 2017年現在のトランザクションに関する主な事件、出典：サイバー研究所（2017年10月）
表1は、2017年現在でのトランザクションに関する主な事件として、2016年のバングラディシュ中央銀行でのSWIFTネットワーク（日本円で約1000億円の被害）事件と、2015年のマウントゴックス元最高経営責任者（CEO）による内部犯罪、約2兆6630億円の事件を取り上げている。
これまで「コンシューマー・ビジネス」と「法人の企業間取引」において、テクノロジがイノベーションをもたらし、効率的でさらに高速処理を安価な手数料で実現することが「理想的なシステム」とされていた。しかしながら、本稿ではテクノロジの話も重要だが、その前に、現在どのような事件、事故が発生しているのか、リスクと向き合うことも重要である。このリスクの被害額は大きく、約1000億円や約2兆6630億円など、一度事件が起きてしまうと会社が存続できない場合もある。そのため、将来的なテクノロジでは、リスクを極力減らし、仮に有事が発生してもリスクヘッジができるような仕組みが必要とされる。
