KYB は、取引の相手が法人である場合に、その企業が何者で、誰が代表し、どの程度の確認が済んでいるかを把握する作業です。個人の本人確認と似た名前で呼ばれますが、集める材料も、判定の分かれ方も、途中で止まる理由も異なります。この記事では、企業の受け入れ確認を試すときに何を確かめるべきか、差し戻しをどう扱うか、状態をどう持つかを整理します。
KYB のテストが個人の確認と違う点
個人の確認では、対象が一人に定まっているため、材料はその人に紐づきます。企業の確認では、対象が法人であり、その法人を代表して手続きをする人が別にいます。したがって、法人そのものの確認と、手続きをする人の確認という二つの層が同時に走ります。
もう一つの違いは、法人の情報が変わりやすいことです。名称、所在地、代表者、法人形態は、時間とともに動きます。個人の属性が比較的安定しているのに対し、法人の情報は事業の都合で頻繁に更新されます。確認の結果に時点を添えて保つ必要があるのはこのためです。
何を材料として求めるのか？
求める材料は、大きく四つに分かれます。第一に、法人を特定する情報です。登録された名称、所在地、そして登録番号や識別子がこれにあたります。第二に、実在を示す記録です。公の登録簿の写しや、そこから得た情報が使われます。第三に、手続きをする人の立場を示す情報です。代表者であるのか、委任を受けた担当者であるのかで、必要な裏付けが変わります。第四に、事業の内容です。何を扱い、どこで活動しているのかが、受け入れの判断材料になります。
求める材料は、業種や取引の規模によって加減します。すべての相手に同じ一式を求める設計は、負担が大きく、かえって離脱を招きます。
差し戻しはどう扱うべきか？
差し戻しは、単一の結果ではありません。少なくとも三つに分かれます。材料が足りない、材料の内容に食い違いがある、そして判断がまだ下せない、の三つです。これらを一つの「否認」にまとめると、出し直せば通る相手まで拒むことになります。
差し戻しでは、何を直せばよいのかを具体的に伝えます。足りないものが書類なのか、記載の不一致なのかで、相手の次の行動が変わります。判断を保留する場合は、いつまでに何が分かれば進めるのかを添えます。期限を示せない場合でも、保留であること自体は伝えてください。
そして最も大切なのは、状態を記録に残すことです。いつ、どの材料を見て、何を理由に差し戻したのかが後からたどれないと、同じやり取りが繰り返されます。
確認項目の一覧
| 分類 | 確認する内容 | 止まりやすい理由 |
|---|---|---|
| 法人の特定 | 名称、所在地、識別子 | 表記のゆれ、所在地の変更 |
| 実在の裏付け | 登録簿の記録との一致 | 記録の取得失敗、情報の新旧 |
| 代表の確認 | 手続きをする人の立場 | 委任の範囲が読み取れない |
| 事業の内容 | 扱う品目と活動の地域 | 説明が抽象的で判断できない |
| 継続の確認 | 定期的な見直しの要否 | 前回の結果を使い続けている |
各行について、通る例と止まる例を一組ずつ用意すると、分岐の確認が行き届きます。
架空の企業情報で流れを通す
確認の流れを試すには、入力する企業の情報が要ります。この用途に、実在の企業の情報を使う必要はありません。当サイトのテスト用の会社データ生成ツールでは、国と地域を選ぶと、その土地の書き方に沿った社名、法人形態、識別子を含む記録を一件用意できます。
生成される値はテスト専用です。実在の企業に対応せず、公の登録簿にも照会の仕組みにも登録がありません。したがって、実在しないことを前提とした分岐、たとえば裏付けが取れない場合の保留の扱いを、安全に繰り返し確かめられます。
ここで境界をはっきりさせておきます。架空の企業データは、ソフトウェアの試験、画面の演示、検証用の環境、帳票の練習のためだけに使えます。実際の受け入れ確認を通す目的、審査を回避する目的、他人の企業の身元を借りる目的、本物の書類や請求書を作る目的には使えません。実在する企業を装う行為は、試験の都合で正当化できるものではありません。この線引きの全体は架空の会社データを使ってよい範囲で扱っています。
開発者向け: 状態遷移と再試行
受け入れ確認は、状態の移り変わりとして設計してください。未着手、材料の受付中、審査中、保留、受理、否認、といった状態を明示し、どの状態からどの状態へ動けるかを決めます。状態を自由な文字列で持つと、表記のゆれで判定が壊れます。
保留の状態を必ず用意してください。判断できないことを表現できない設計は、判断できない案件を無理にどちらかへ倒します。保留には、待っている理由と、再開の条件を持たせます。
外部の照会を伴う場合は、その応答を状態の根拠として保存し、取得の時点も併せて記録します。照会が失敗したことを否認として扱わないでください。失敗は失敗として扱い、再試行の対象にします。
履歴は追記のみで保ちます。現在の状態を上書きする設計では、なぜその状態になったのかを説明できません。担当者が変わっても経緯をたどれることが、この種の仕組みでは最も効いてきます。
法人の識別子を扱う場合、種類ごとに長さと文字種が違う点に注意してください。照合の手掛かりとして使うものであり、受け入れの可否そのものを決める値ではありません。詳しくはLEI と DUNS の違いで扱っています。
次のステップ
まず、確認の流れに保留の状態があるかを確かめてください。無い場合は、判断できない案件の行き先を先に決めます。次に、差し戻しの理由を三つに分け、それぞれに別の案内を用意します。
確かめ用の企業情報はテスト用の会社データ生成ツールで用意できます。確認の流れの前提となる入力の整理はテスト用の会社データとはを参照してください。
本記事は確認作業の設計を一般的に説明するものであり、特定の法域の規制上の義務や個別案件の判断を示すものではありません。