アカウント名:
パスワード:
株式会社モスフードサービスhttps://www.mos.jp/topics/20200110_1/ [www.mos.jp]https://www.mos.co.jp/company/pr_pdf/pr_200110_1.pdf [mos.co.jp]
モスカードの発行に関する委託先と運用に関する委託先にて調査を進め、2020年1月4日(土)に会員カード番号の重なりがあることが発覚いたしました。
委託先による業務フロー管理の誤りにより発生したものであり、弊社の監督管理の不徹底が原因です。
株式会社バリューデザインhttps://www.valuedesign.jp/files/20200110.pdf [valuedesign.jp]
本件は原因として、「委託先による業務フロー管理の誤り」と発表されておりますが、これはカード運用に関する委託先による業務フローの誤りであり、当社が委託を受けておりますカード発行に関する業務フロー、並びに当社が運営するハウスプリペイドカードの残高管理システムには問題がないことを確認致しました。
うーんこの
pr_200110_1.pdfのほうにも「モスカードの発行に関する委託先と運用に関する委託先にて調査を進め、」ってあるから、・委託元のモスフードサービス ← ココ委託元だと思う。・システム提供元 ← ウチのシステムに問題ないって言ってるトコ・そのシステムを使ったサービスを委託されてるトコ。 ← やらかしちゃったトコ
上記3者が存在するのでは?
「モスカードの発行に関する委託先と運用に関する委託先にて調査を進め」なので、三社が絡んでそうですね。
・モスフードサービス(元締め)・カード発行会社(しらんがな)・カード運用会社(やらかした)
発行と運用を分けるのはなんでやろ。この手のプリカはだいたいこういうモデルなのでしょうか。
バリューデザインは、物理的な「カード」を使った決済のシステムを提供してますが、スマホアプリには対応してないようです。プリペイドと言ってますが、チャージもできるので、「電子マネーカード」と言った方が正確かな。採用事例 [valuedesign.jp]を見ると、中規模スーパーの電子マネーカードでの採用が多い感じ。カード自体には残高は持たず、磁気カードやバーコードでカード番号を元にサーバで残高管理するスタイルのもよう。
ってことは、
(物理)カード発行会社: 物理的なカードの発行と決済システムを提供(デジタル)カード運用会社: スマホアプリからの利用サービスを提供
って感じじゃないですかね。
>当社が委託を受けておりますカード発行に関する業務フロー
とあるから、カード発行(発注元:どこよ?)→運用委託→モスフードサービス→2次委託(丸投げ)→カード運用会社(やらかした)#下請けがやった遺憾である。
役割ごとに担当会社を分けるのは、セキュリティのため。発行~運用まで自由自在だと、不正発行して換金するヤツとかが現れるから。
>発行~運用まで自由自在だと、不正発行して換金するヤツとかが現れるから。
なるほど、不正の可能性はあるから効率だけを求めるわけにも行かないんだ。お互いにチェックさせていれば不正される確率は減りますね。
役所絡みで補助や保証を出すので、任されていた担当者がやらかすのもよくありそうだし。
>モスカードには、プラスティック製のカード(物理カード)とスマートフォンのアプリで登録するデジタルカードが存在します。
ここの連携が同期取れてなかったんでしょ。
アプリ側は後付けの外部システムだろうから、発行・管理をしてるシステム単体なら矛盾しないけどアプリと同期が取れてないとアプリで発行済みの番号を発行する、もしくは逆が発生する。
この場合同期のための外部連携仕様でどちらがやらかしてるかはわからない。
もしかして「物理カードは0番からでアプリ発行は何万番から」とか分けておいたら物理カード発行枚数がめでたくアプリ発行分の領域に突入したとかそういうことだろうか
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
公式発表 (スコア:1)
株式会社モスフードサービス
https://www.mos.jp/topics/20200110_1/ [www.mos.jp]
https://www.mos.co.jp/company/pr_pdf/pr_200110_1.pdf [mos.co.jp]
株式会社バリューデザイン
https://www.valuedesign.jp/files/20200110.pdf [valuedesign.jp]
うーんこの
Re: (スコア:0)
pr_200110_1.pdfのほうにも
「モスカードの発行に関する委託先と運用に関する委託先にて調査を進め、」ってあるから、
・委託元のモスフードサービス ← ココ委託元だと思う。
・システム提供元 ← ウチのシステムに問題ないって言ってるトコ
・そのシステムを使ったサービスを委託されてるトコ。 ← やらかしちゃったトコ
上記3者が存在するのでは?
Re:公式発表 (スコア:2)
「モスカードの発行に関する委託先と運用に関する委託先にて調査を進め」
なので、三社が絡んでそうですね。
・モスフードサービス(元締め)
・カード発行会社(しらんがな)
・カード運用会社(やらかした)
発行と運用を分けるのはなんでやろ。
この手のプリカはだいたいこういうモデルなのでしょうか。
Re:公式発表 (スコア:2)
バリューデザインは、物理的な「カード」を使った決済のシステムを提供してますが、スマホアプリには対応してないようです。プリペイドと言ってますが、チャージもできるので、「電子マネーカード」と言った方が正確かな。採用事例 [valuedesign.jp]を見ると、中規模スーパーの電子マネーカードでの採用が多い感じ。カード自体には残高は持たず、磁気カードやバーコードでカード番号を元にサーバで残高管理するスタイルのもよう。
ってことは、
(物理)カード発行会社: 物理的なカードの発行と決済システムを提供
(デジタル)カード運用会社: スマホアプリからの利用サービスを提供
って感じじゃないですかね。
Re: (スコア:0)
>当社が委託を受けておりますカード発行に関する業務フロー
とあるから、
カード発行(発注元:どこよ?)→運用委託→モスフードサービス→2次委託(丸投げ)→カード運用会社(やらかした)
#下請けがやった遺憾である。
Re: (スコア:0)
役割ごとに担当会社を分けるのは、セキュリティのため。
発行~運用まで自由自在だと、不正発行して換金するヤツとかが現れるから。
Re:公式発表 (スコア:1)
>発行~運用まで自由自在だと、不正発行して換金するヤツとかが現れるから。
なるほど、不正の可能性はあるから効率だけを求めるわけにも行かないんだ。
お互いにチェックさせていれば不正される確率は減りますね。
役所絡みで補助や保証を出すので、任されていた担当者がやらかすのもよくありそうだし。
Re: (スコア:0)
>モスカードには、プラスティック製のカード(物理カード)とスマートフォンのアプリで登録するデジタルカードが存在します。
ここの連携が同期取れてなかったんでしょ。
アプリ側は後付けの外部システムだろうから、発行・管理をしてるシステム単体なら矛盾しないけど
アプリと同期が取れてないとアプリで発行済みの番号を発行する、もしくは逆が発生する。
この場合同期のための外部連携仕様でどちらがやらかしてるかはわからない。
Re: (スコア:0)
もしかして「物理カードは0番からでアプリ発行は何万番から」とか分けておいたら
物理カード発行枚数がめでたくアプリ発行分の領域に突入したとかそういうことだろうか