詳細不明なところもありますのでなんとも言えないんだけど、外部から見える範囲でわかる問題点について解説してみます。詳細を調べたら問題なかったり、中の人だけが知っている仕様によってクリアされている問題もあるかもしれません。
事実誤認があれば訂正しますのでよろしく。
そもそもドコモ口座って？
ドコモユーザーならおなじみ、それ以外でも使えるアカウントサービスである「dアカウント」に紐づけてキャッシュレス決済などで使用できる電子マネー（だよね）のことです。
dアカウントは元々はドコモ契約者向けのアカウントサービスだったんですが、スマホを起点としたサービスを提供するに当たり、汎用的なアカウントサービス（ID提供サービスとも言えます）にするためにドコモの回線契約とのつながりを限定的にしたものです。GoogleアカウントやFacebookアカウントでのログインと同様、dアカウントでのログインができるようになり、dポイントも使えるようになるので便利ですね。
ドコモの回線契約をしていると本人確認レベルが格段に上がります。でも、契約してないとそもそもGoogleアカウントで登録ができたりとか、誰だかわからないアカウントになります。
ドコモ口座はいわゆる出金できないポイントサービスから出金も可能になる資金移動業に移行するに当たり、本人確認レベルを上げているはずなんですが、本人確認を「銀行口座を登録」することに依存しています。画面の項目とかを見る限り、「dアカウント側で本人確認していない」口座名義人（カナ）くらいしか銀行へのサイト移動時の連携項目がありません（遷移時のリクエストの中身までは見ていないのでもっと何かあるかもしれないけど、何を連携する、というのが出ないのも不自然なので業務的なデータはないかも）。だから、連携する先の口座の名義を適当に（すでに知り得ている口座名義で）dアカウントに登録していれば、第1段階はクリアしていると思われます。この時点で結構やばいね。
で、本人確認という名前の銀行登録が完了すると、チャージができるようになりますが、そのときに「銀行側での認証」は不要です（何故不要なのかは後で説明）。
また、出金は、登録した口座への出金も可能ですが、どうやら（やったことないのでアレだが）「セブン銀行ATMからの直接の出金」が可能です。これがちょっとヤバい気のするポイント…
銀行で登録するのは一体何なの？問題点は？
銀行口座の登録っていうのはそもそも何なんでしょうか。登録って何よ。これはですね、他のなんとかPayとかでもやっていることなんですが、ようは、「資金移動業者からの依頼でユーザーの口座からお金を資金移動業者に移動する」許可を与えているものになりますね。え、そんなことしてんのって思うかもしれませんが、みなさんこれは普通に色んなものでやっていますね。すなわち「口座振替契約」をしています。口座振替ってのは収納機関と呼ばれるサービス提供先（例えば、クレジットカード会社やスマホのキャリア、公共料金などいわゆる「口座引落」で支払いを登録するもの）が申し出た金額で口座からお金を自動で引き落とすサービスのことですね。引落先口座として登録するときに口振契約をしていることになります。これは、収納機関、金融機関、口座保有者の3者間の契約になりますので、例えばドコモで携帯を契約するときに申し込んだ情報はその時に記載した銀行に回っていて口振契約がされます（ということに同意します、みたいな文言が書いてあるはずです）。
で、この紙ベース（紙ですよ）の手続きのリアルタイム性がないことやめんどくさいことを特になんとかPayとかだとやってらんないので、デビットカードのインターフェースなど（悪名高きCAFISとかです）を使って銀行側と連携して最初の確認オッケーとかにするのは紙ベースでもやってるんですがそれもめんどくさいからもう直接銀行のサイトから申し込ませちゃおうぜってのがWeb口振受付。これが何年か前に一斉に流行ってほぼすべての銀行が対応してます（例外あり）。今回も、ことの性質上、これを使っているはずです。つまり、今回問題になっている銀行については他のなんとかPayでも勝手に登録、チャージの脆弱性がある可能性があります。ただし、連携元の本人確認レベルがこんなに低いのはそんなにないかも。
で、Web口振受付をするにあたって、銀行サイト側で本人確認をする必要がありますが、これは報道されているように、「口座番号＋キャッシュカード暗証番号＋α」という、わりと弱めの認証になっている銀行があります（特に+αの部分が生年月日みたいな公開情報に近いものを使っているところ。最悪、+α自体がない）。これ、収納機関側の言い値の決済をできるようにする仕組みなんだからそんなんでよいの？という話なんですが、一般的に銀行と口振受付契約をする収納機関は「本人確認がなされている人が連携されてくる」ことが信頼ベースで担保されていることが前提になっているはずなので、まさかこのWeb口振受付そのものが本人確認の手段になっているって思って作ってないと思いますよ。
とはいえ、資金移動する取引の登録として例えばインターネットバンキングの第2認証やワンタイムパスワードなどが不要というのはいまどきちょっと弱めです。もっとも、先に述べたとおり、普通の収納機関は例えば免許証とかで既にに本人確認していないとこんなところまでやってこないんじゃないでしょうか。なんとかPayとかは違うのかな？とか思うけど。
ってここまで言うとなんとなくわかってきたと思いますが、これは銀行側の認証が甘い、という問題は2次的なものであり、ドコモから連携するときの信頼レベルが低い、ということに問題の本質があると思います（じゃないと、その銀行においてはWeb口振受付の仕組みそのものが全部アウト…の可能性もありますけど…）。銀行の一番の落ち度は「信頼できない収納機関からの受付を許容している」というところが最大でしょう（とはいえ、ドコモがそんなアホな連携してくるとは銀行も思いませんよね？）。
ドコモ側に問題はあるの？
ありますよね。随分他人事みたいなアナウンス・報道がなされていますが、オメーのサービスの本人確認といういちばん大事なところを外部に依存してんじゃねーよってことで。しかも、追跡の難しくなるATMでの直接出金サービスを提供していますよね。こんなの狙ってくれって言っているようなもんじゃないですか…資金移動業者としての適格性あるシステムなのこれ？
dアカウントというサービス自体は便利で良いし、回線契約をしていると本人確認のレベルが上げられるので、認証サービスとして「回線契約をしている人に限って」であれば色々保証される部分もあるので、認証サービスを利用するシステム側も使い勝手がよいとは思うんですが、キャリアをまたがったサービスとして手を広げようとしているところでの勇み足ですよねこれ。
まあ、報道によるとドコモ側も本人確認が甘いってのを認め始めているようなところもありますので、はよなんとかしてくれって感じですね（だって当該の銀行口座持ってるだけでドコモと関係ない人もリスクあるわけでさ…）
ブクマ受けて少々追記
収納機関は悪くないのでは？
口振受付のI/Fは広くインターネットに公開されているとはいえ（ブラウザで連携する仕様なので）、収納機関と金融機関の契約がなされていることをベースに受付けるわけですので、なんでも改ざんで通っちゃうわけでもないし、それなりの契約をしているはずです。
なので、それをもって収納機関に責任がないというのは間違い（もっとも、ドコモと各行の契約がどうなっているかは知りませんよ）。
犯収法の規定では口座の確認で代替できるはず
これは勉強中なのでなんとも言えないけど、
ただし、取引の相手方が当該各号に規定する取引時確認若しくは相当する確認に係る顧客等若しくは代表者等になりすましている疑いがある取引、当該取引時確認若しくは相当する確認が行われた際に当該取引時確認若しくは相当する確認に係る事項を偽っていた疑いがある顧客等若しくは代表者等（その代表者等が当該事項を偽っていた疑いがある顧客等又は代表者等を含む。）との間における取引、疑わしい取引又は同種の取引の態様と著しく異なる態様で行われる取引を行う場合は、この限りでない。
https://elaws.e-gov.go.jp/search/elawsSearch/elaws_search/lsg0500/detail?lawId=420M60000f5a001#121
とありますので、やっぱり言えないかな。
あと、この条項が「決済」について述べているのですが、今回のスキームでは決済における認証はドコモ側ですよね（あくまで口振受付時だけ、銀行側で認証する）。ちょっとどう解釈していいのかすぐ判断できない。
この辺の解釈はさすがに銀行の法務レベルじゃないとぱぱっと答えは出ないと思います。多分、このスキームの実施に際して個別に契約する時点でこの辺の解釈は詰めているはずです。
ATMでの払い出しはドコモの回線契約しているアカウントだけらしい
そうなんだ。であればちょっとだけ問題のリスクが減りますね。捨て回線とかなければ…
→やっぱ誰でもできるようです。狙われる必然性がここに
ちなみに
銀行側の認証が甘々なのを擁護しているわけではないので念の為。
もうちょい追記～銀行側の問題について
これは既にいろいろなところで言われているけれども、「キャッシュカード暗証番号」というのは物理的なカードとのセットで使われるからセキュリティー的に成立しているところがあるわけですね。
ところが、ここ最近、Fintech絡みの話でWeb系の認証についてもちょくちょく使われることが増えてきています。僕の知る限り、LINEで残高照会のやつでそうなっててビビった。
それだけじゃなくて、某ASPで提供しているインターネットバンキングが口座と暗証番号でログインできたりとか、なぜかこの件で好感度が上がった？らしい三井住友銀行のSMBCダイレクトとかも利用開始手続きしていない人は～のところでキャッシュカード暗証番号入れさせようとしているよね。
なので、キャッシュカード暗証番号を「最後の砦」にするのはWebではダメだし、それ以外の情報で本人しか知り得ない情報ってのは結構少ないのです。まあまああるパターンでかつ他人が知りづらいものは現在残高（それぱっと見れるなら残高照会サービスに登録しようと思わんわ）、通帳最終記帳残高（これはわかる）、通帳発行番号（これもわかる）、生年月日（テメーはダメだ）、等々ですね。OTPはそもそも銀行側になんらかの登録をしているのが前提ですよね。だから、Web口振受付自体をもっとハードル上げて、インターネットバンキング登録しているユーザーだけに限定するとか、そういう風にしないとセキュリティー強度は上げづらいんですよね。それやれって話ですけど。
銀行も、口座の開設の方の本人確認は犯罪収益移転防止法のおかげでレベルアップを図っているんですが、少なくとも今回のパターンがザルでは意味がありません。そういう点では、銀行側の問題も相当なものではあります。かといって、利便性を考えると限界もありますね。利便性クソくらえな事象な気もしますが。
更に追記してみる～銀行ごとに認証の仕様が違うのはなぜか
これは単純な話で、ドコモから銀行のサイトに遷移してそちらで認証をするから、銀行の好きな仕様にできますってこと。インターネットバンキングのログインをさせても良いし、口座番号＋αの簡易認証をしてもよい。重要なのは、確実に本人だと言える（確実、は100点は無理なので99.9点のイメージね）認証を行っているかどうか。繰り返しになりますが、キャッシュカードの物理カードと暗証番号のセットとは違い、口座番号と暗証番号は知っていれば入力可能なので、それをもって本人とするのはかなり甘い。
で、地銀はたいてい
www.chigin-cns.co.jp
これを使っていると思うんですが、（ここからは推測ですが）入力項目については銀行が任意で設定できるはずです。で、それを銀行ホストに連携してくる。設定については項目数の制限があるかもしれない。だから、銀行ごとにまちまちなのは、銀行としてホスト（勘定系か、専用システムかはしらん）側で使う項目が違うからでしょう。ぶっちゃけ、ここについては各銀行がこのシステムを作ったときの事情が大きく反映されていると思います。意識の問題もあるかもしれない。でもせめて生年月日はまずくね？ってのは思ってほしかった。まあ、地銀CNSのシステムもしょっぱいよね。
続き
今回の問題の背景みたいなものを書きました
novtan.hatenablog.com
