CREグループの衛藤です。今回で2回目の投稿となります。
前回の投稿では犯罪収益移転防止法（犯収法と呼んだりしています）改定に伴いeKYCを導入したという内容でした。
eKYC*1を導入して1年ほど運用したところいくつか気づきがあり、結果的に別のeKYCに入れ替えることをしました。今回はその点について記載していこうと思います。
運用中に出てきた課題
eKYCを導入してからしばらくすると、特定部分で不備が多く出ることが分かってきました。
第６条第１項第１号ホ（平成30年11月30日施行）の対応にて、『本人確認書類の厚み』を確認する必要があります。
* 顧客等から、特定事業者が提供するソフトウェアを使用して、本人確認用画像情報の送信を受ける方法
* 本人の容貌の画像の送信
* 写真付き本人確認書類の画像の送信
* 氏名、住居及び生年月日、写真並びに厚みその他の特徴を確認できるもの
上記の赤文字にした部分にあるように、お客様に本人確認書類の"厚み"を撮影してもらうのですが、撮影していただいた画像が不鮮明になってしまうことがあり非承認となることが多く発生しました。
非承認となるTop3については下記のようになり、その中でも圧倒的に厚みの不鮮明が多かったのです。
- 厚み不鮮明
- 住所不備
- 氏名不備
厚みを動画で撮影する仕組みになっていたのですが、対応するお客様には難易度が高くうまく動画が撮影できない状態が多くありました。
厚み以外でもeKYCによる撮影も、例えば首振り動画といったものも厳密にチェックされているのでうまく撮るにはコツがみたいなものがいるため、そもそもうまく撮影できないといったこともありました。
また、新規開設申請数がeKYC導入当初の想定より上振れていたためコストが膨らんでしまいコスト試算の見直しについても検討する必要が出てきました。
他にも細かいところはあるのですが、大まかには上記のことにより他のeKYCソリューションを検討するようになりました。
eKYCを変更するに当たり考慮したこと
変更するに当たり、下記の内容を考慮しました。
- 費用
- 1件あたりの単価が抑えられる
- 顧客機能
- 厚み機能が改善される
- 住所不備が改善される
- システム
- モバイルアプリが利用するSDKの容量
- 管理画面を改善
費用面については詳細は記載できないのですが、1件あたりの単価が抑えられるものを採用基準としました。
顧客機能についてはeKYC撮影の厚み撮影が改善されることが必須となります。あと、本人確認書類を読み込むOCR機能があると住所不備も改善されやすいと考えました。
システムについてはお客様がeKYCを行うのは本人確認が終わるまでなので、それ以降はeKYCを行わないためモバイルアプリが使用するSDKの容量が小さいか、SDKを使わずブラウザでeKYCが可能なもので考えました。
eKYCを変更するタイミングで、管理画面も改善していくことになりました。OCRで読み込めれば認証作業もスムーズになると考えたからです。
そんな中何社かeKYCソリューションを提供している製品のデモを見せていただいたのですが、LIQUID eKYCを利用するようになりました。
プレスリリースについては下記のものとなります。
プロジェクト計画書の作成
開発を進める前にプロジェクト計画書を作ったらどうだみたいな話が出ていたので作成することにしました。
プロジェクト計画書には下記のようなアウトラインで記載しています。
- プロジェクトの目的
- 課題
- 乗り換えで想定している4つの効果
- プロジェクトのゴール
- プロジェクト概要
- 今回のプロジェクトのスコープ
- 前提条件と制約条件
- タスクの構造化
- リリースまでのタスク
- リリース後のタスク
- スコープ外としたタスク
- コスト
- 開発工数見込み
- 運用工数見込み
- 運用費用
- スケジュール
- 体制
- 品質
- リリースまでのテストについて
- 品質目標
- リリースまでの品質目標
- リリース後の品質目標
- コミュニケーション
- リスク
結構書くのは大変だったので色々な部署の方を巻き込んで記載していきましたが、これがあったからそんなに迷子にならずに進められていったのではないかと思います。
プロジェクトは生き物なので途中で道筋が変わることもありますが、そこも許容範囲としてプロジェクト内で合意して進めることが出来たと思います。
開発してみてどうだったか
開発を進めるまでに、契約周りの書類のやり取りとか先方側の検証環境を構築して頂いたりとかで時間が掛かってたり、差し込み案件対応があったりでなかなか開発着手することが出来ず、開発着手まで4ヶ月くらい掛かってしまいました・・。
開発が始まってからは主に下記の開発を進めていきました。
- モバイルアプリの開発
- LIQUID eKYCとのAPI連携
- 管理者画面の開発（NuxtJS）
- 管理者画面用のAPI開発
モバイルアプリの開発についてはeKYC用のSDKを無くしたり、それに伴う本人確認機能の導線変更を行いました。かんたん本人確認の手順については下記ページにまとまっています。
変更ポイントとしては途中からLIQUID eKYCに遷移するところでしょうか。本人確認用のSDKが無くなりアプリのサイズが3分の2くらいになったようです。
LIQUID eKYCとのAPI連携については検証環境への接続は比較的容易に行えたのですが、本番環境で動作確認が取りにくいので段階リリースで本番環境から疎通確認しつつリリースするようにしました。本番環境についても先方の構築するタイミングもあるので、安全な方に倒していきました。安全第一ですね。
管理者画面の開発については、管理画面のデザインから丁寧に進めて行きました。既存画面がだいぶ悩ましいものだったのでデザイナー主導で現場メンバーの声を聞いたりFigmaで画面を作ったりユーザーテストを行ったりしていました。1秒でも早く認証作業が終わるようにというこだわりがあり、とても良い画面になっていったのではないかと感じています。
一方開発側としては、画面がFixしないと開発が進められないというもどかしさもあったり、画面がFixしたと思ったら途中から別案が出てきたりという良くある事案を許容しつつAPI開発を進めていきました。APIをある程度作りつつ、画面周りを開発も始めて行きました。
画面周りをがっつりNuxtJSで作るのは私のグループとしては初めてだったのですが、開発実績があるメンバーがいたため開発方針を提案してもらったり結構な画面数を作ってもらえたので助かりました。
作成した画面は検証環境に反映して実際に使ってもらうことでフィードバックを頂けるので更にそこから画面周りをより良くしていきました。
検証環境でシナリオテストを行い、API側や管理画面側のリリースを先行で行った後は本番環境でLIQUID eKYCの疎通確認を実施。問題が無さそうだったのでモバイルアプリもリリースしてお客様に利用して頂ける状態になりました。
リリースに至るまでだいぶ長い工程でしたが、個人的には良いものが出来ていると思っているので楽しい開発期間でした。
リリースしてどれくらい効果があったのか
2022年3月までの本人確認の不備率ですが、3月平均で27.14%ありました。
2022年4月のリリース後にプロジェクト振り返りを行ったのですが、不備率が18.01%に下がっているようでした。今回のリプレイスにおいて、「厚み」の不備は20％台から3％と大幅に削減出来ました。
非承認となる割合も厚みが順位を下げて下記のような状態になりました。
- 住所不備：10％ 番地抜け、部屋番号抜け
- 厚み不備：3％ 白飛びしていて書類の角が見えない
- 氏名不備：3％ ローマ字入力
- 本人確認書類：2％ 光が入って情報の一部が見えない、ブレ、ボケはなし
住所不備が目立つようになってきたので、これはこれで対応中です。
リプレイスして驚いたのは、eKYCを利用する比率が変わったことでした。
リリース前まではeKYCによる提出の比率が75.03%だったのですが、リプレイス版をリリースしてからは90.3%まで上がりました。リプレイス前ではeKYCをしている最中にうまく出来ず途中で諦めてしまった方が多かったのではないかと思われます。
eKYCによる申請率が上がり、管理画面も作り直したので承認作業の効率化も出来たように思えます。
振り返りはKPTで行ったのですが、プロジェクトは最後まで良い雰囲気のまま終われたので良かったなと思っています。
最後に
今回はeKYCをリプレイスした話ですが、他にもまだやりたいことが多くあるので採用を頑張っていこうと思います。ありがたいことに7月に3名入社して頂いたので、オンボーディングが終わった頃に徐々に採用を頑張ろうと思います。
カジュアル面談は気兼ねなくご連絡頂けたらと思います。
特にオチもなく長文となってしまい恐縮ですが、以上となります。
*1:eKYCとは口座開設に必要な本人確認手続き(Know Your Customer)を全て電子的(electronic)に行うこと
