マッチングサイトの本人確認・審査設計｜いつ確認し、どこまで制限するか

本人確認が必要なサービスでも、登録した瞬間に全利用者へ書類提出を求めるとは限りません。掲載する人だけ、問い合わせする人だけ、高額取引へ進む人だけなど、確認するタイミングを分けられます。

最初に決めたいのは『本人確認が終わるまで、何を禁止するか』です。閲覧はできる、保存もできる、ただし問い合わせ前に確認する。あるいは掲載前だけ確認する。この線を決めると、利用者の負担と安全性を両立しやすくなります。

なお、法令上必要な本人確認の範囲は事業内容によって異なるため、対象となる業法や専門家の確認が必要です。ここではサービス設計としての考え方を扱います。

本人であることが確認できても、その人が掲載する商品・物件・案件について必要な権利を持っているとは限りません。無料不動産では、利用者本人の確認と、物件側の確認を分けています。

一つの『確認済み』フラグにまとめると、後から『本人は確認済みだが、この掲載は未確認』を表現できません。確認対象が違うものは、状態も分ける方が管理しやすくなります。

本人確認を早く求めるほど安全に見えますが、登録直後の離脱も増えやすくなります。逆に、最後まで確認しないと不正掲載やスパム対応が増える可能性があります。

閲覧、掲載、問い合わせ、メッセージ、決済、出金。この中でサービス上のリスクが大きくなる操作を選び、その直前で確認する方法があります。Stripe Identityも、高リスクな機能を許可する前などに本人確認を追加する用途を示しています。

実運用では、未提出、確認中、追加資料待ち、承認、否認、期限切れ、再確認などが発生します。外部の本人確認サービスを使っても、サイト側で現在の状態を持たなければ利用者へ適切な案内ができません。

特に差し戻し時は、ただ『失敗しました』ではなく、再申請できるのか、別の書類が必要なのか、運営へ問い合わせるのかを明確にします。

プロフィールへ『確認済み』と表示すると、利用者は広い意味で安全だと受け取る可能性があります。実際には本人確認だけで、資格や所有権までは確認していないこともあります。

表示するなら、『本人確認済み』『事業者確認済み』『掲載内容確認済み』など、何を確認したかを分ける方が誤解を減らせます。内部の審査状態と、ユーザーへ見せるラベルは同じでなくても構いません。

本人確認書類は機密性の高い情報です。必要以上に自社システムへコピーして保持すると、守る対象が増えます。外部の本人確認サービスを利用し、自社側では確認結果や必要最小限の情報だけを持つ構成も候補です。

Stripe Identityでは、確認データの保存やアクセス制限、データ削除などの仕組みを提供しています。どのサービスを使う場合でも、取得する情報、保存期間、閲覧できる担当者を最小化する考え方が重要です。

運営側が必要なのは、承認済みの人数だけではありません。誰が確認待ちで、誰が追加資料待ちで、どの申請を今日処理する必要があるかです。

一覧では状態、申請日時、最終更新、次の操作を見せます。詳細では承認・差し戻し・停止を行い、誰が判断したかを残せると運用しやすくなります。

画面上で『本人確認が必要です』と出しても、API側では問い合わせを送れてしまうなら意味がありません。本人確認状態を、サーバーやデータベース側の権限判定にも使います。

無料不動産でも、確認状態に応じて問い合わせやメッセージの可否を分けています。UIだけで止めず、実際の操作権限と同じ条件にすることが大切です。

一度承認したら永遠に確認済み、とは限りません。重要情報を変更した、長期間利用していない、外部サービス側で再確認が必要になったなど、再確認のきっかけが発生することがあります。

本人確認そのものを自社で判定しない場合でも、再確認が必要になったユーザーをどの権限へ戻すかはサイト側の仕様です。問い合わせだけ止めるのか、掲載も非公開にするのかを決めます。

本人確認を追加すれば安全性は上げられますが、入力・撮影・書類提出が増えるほど離脱する利用者もいます。全員へ同じ確認を求めるのではなく、必要な人へ必要なタイミングで求める設計が重要です。

公開後は、本人確認開始率、完了率、失敗率、再申請率、その後の問い合わせ率などを見ます。安全性だけでなく、利用者がどこで止まっているかも確認しながら改善します。