チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
フィンテックの新規登録で本人確認用の住所情報を検証する
デジタルバンクで口座を開設するには、書類の確認、制裁リストの照合、住所証明といった一連の本人確認が必要です。これらは順番に実行されます。どれも時間の面で、場合によっては金銭の面でも実際のコストがかかるため、安く速いチェックを先に実行して明らかに不備のある申し込みを除外してから、高価なチェックに労力を費やすのが理にかなっているからです。
住所の妥当性は、デジタルバンクが実行できるチェックの中でも、最も安く、最も早い段階で行えるものの1つであることがわかりました。申し込みが書類のアップロードと本人確認に進む前に、新規顧客が登録フォームに入力した住所に対して2つの簡単なチェックを行いました。/v1/forwardは住所の照合を試み、どの程度の確信度で解決できたかを報告します。これにより、通り名が存在しない、住所が不完全である、あるいは形式が実在するどの場所にも対応しない、といったケースを捕捉しました。/v1/postcodeは、入力された郵便番号を、同じく入力された市区町村や地域と照合します。これにより、別の場所からコピーされた郵便番号や単なる入力ミスという、特有でよくある間違いを捕捉しました。
どちらのチェックも、それだけで本人が名乗っているとおりの人物かどうかを判断するものではありません。銀行は社内で、このステップがその後に続く本人確認や顧客確認(KYC)のプロセスに代わるものではないと明確にしていました。このステップが果たしたのは、放っておけば後工程のより高価なステップの時間を無駄にしてしまう種類の申し込みを、安く捕捉することでした。実在するはずのない住所は書類審査に進む必要がありません。それを住所のステップで数秒のうちにフラグ付けすることで、どのみち失敗する申し込みに対してより本格的な確認を実行するコストを節約できました。
問題のない正しい形式の住所を持つ申し込みは、そのまま通常の本人確認キューに進みました。住所が解決されなかった申し込みや、郵便番号と市区町村が明らかに食い違っていた申し込みには、申込者に簡単な修正を促すメッセージを返すか、パターンが偶然というより意図的に見える場合は、通常のキューではなく直接不正の手動審査に回すフラグが付きました。
銀行は、このステップの目的について社内で明確な線引きをしていました。住所の妥当性はデータ品質と不正の初期シグナルであり、それ自体がコンプライアンス上の統制になるわけではありません。また、申込者が入力した住所がどれほど問題なく見えても、規制を受ける金融機関が実施しなければならない実際の住所証明書類や、制裁リストの照合および本人確認に代わるものでもありません。ここでの価値はすべて絞り込みと振り分けにあり、明らかに不備のある申し込みをパイプラインの高価な部分からより早く外すことであって、実際のコンプライアンスプロセスのいずれかの部分を置き換えることではありませんでした。
リクエスト量は登録数に比例し、新規申し込み1件につきチェック1組でした。中程度の登録数のデジタルバンクであれば1日あたりの無料枠に収まる負荷であり、成長期や、新規申し込みが急増するマーケティング施策の期間には、プリペイドクレジットが自然な次のステップになりました。
規制を受ける事業者にとって、このようなチェックの魅力は、不正をその場で見つけることよりも、最初から見込みのない申し込みに高価な確認ステップを浪費しないことにあります。両方のエンドポイントのドキュメントは/docs/forward-geocoding/と/docs/postal-code-lookup/にあります。