はじめに
連携 / SDK
ユーザー認証
法人確認
トランザクションモニタリング
変更履歴法人登記の照会
Diditは、対応国の法人登記に接続して公式データを取得します。ホスト型フローでは、ユーザーが設立国を選択し、会社名、登記番号、またはその両方を入力します。少なくともいずれか一方の入力が必須です。登記番号は、登記機関が求める場合に正規化されます(たとえば、英国の会社番号は先頭をゼロで埋めて8桁にします)。両方の識別子が入力された場合、法人登記の照会では両者を組み合わせて検索します。expected_detailsで検索項目を事前入力する
対象企業がすでに分かっている場合は、セッションの作成時にexpected_details(company_name、registry_country、registration_number)を渡します。ホスト型フローでは国(US-CAのような州単位の登記機関の場合は州も)が事前に選択されてロックされ、対応する検索フィールドが事前入力されたうえで、指定された内容での検索が自動的に実行されます。ユーザーは自社の検索結果に直接移動します。指定内容が誤っていた場合にユーザーが修正できるよう、両方のフィールドは編集可能なままです。これは事前入力のみを目的とした機能であり、指定された企業とは別の企業を選択しても警告は発生しません。
検索タイプ
法人登記の検索には2つのモードがあります。検索の流れ
法人登記の照会は、次の非同期の流れで進みます。検索
Diditは、選択された国と入力された識別子(会社名、登記番号、またはその両方の組み合わせ)を使って法人登記に照会します。レスポンスの
searched_byフィールドは、結果の照合方法(name、registration_number、またはregistration_number_and_name)を示します。また、ホスト型UIでは、登記番号による検索結果に対して、ワンタップで会社名として検索し直せる「Search as company name instead」オプションが表示されます。検索は非同期で実行されます。結果をポーリング
結果が確定するまで検索ステータスをポーリングします。大規模な登記機関では、結果が返るまでに数秒かかる場合があります。
企業を選択
返された企業を確認し、正しく一致する企業を選択します。Diditは選択された企業をKYBチェックに紐付け、利用可能なすべてのデータを反映します。
確認して続行
企業情報を確認または修正し、次に設定されているステップへ進みます。
登記機関によっては、所有構造レポートの準備が整う前に企業プロフィールを返す場合があります。その場合、申請者が書類のアップロードなど、レポートに依存しないステップを進めている間、レポートの取得はバックグラウンドで継続されます。
法人登記からの事前入力が主要人物フォームの入力を妨げることはありません。申請者は人物を手動で入力でき、レポートが届くと、送信前に法人登記から取得できた人物が表示されます。
レポートに依存するカスタムの判定は、結果を推測することなく、レポートの到着を待ちます。
レポートが届いても、ユーザーが行った修正は保持されます。
保留中のレポートは、完了した法人登記チェックや自動承認としては扱われません。法人登記の請求は、実際に提供されたレベルに基づいて行われます。
手動送信
法人登記で企業が見つからない場合は、企業データを手動で送信します。セッションは入力されたデータで続行され、
is_from_registryはfalseに設定されます。取得されるデータ
会社ステータス
データソースの表示
各企業レコードにはis_from_registryフラグが含まれます。
true: データは公式の法人登記から取得されましたfalse: 企業が法人登記で見つからなかったため、データは手動で提出されました
fetch_statusフィールドは、登記照会が完了したか、失敗したか、まだ処理中かを示します。
データレベルと料金
ホスト型フローでは、申請者が詳細を確認する前や認証を完了する前に離脱した場合でも、企業を選択した時点で登記照会の料金が発生します。 選択時にレポートの準備ができている場合は、提供されたレベルの料金が即時に請求されます。 所有構造がまだ保留中の場合は、選択時にLiteの料金が請求され、より上位のレベルが提供された時点で差額のみが請求されます。 所有構造を取得できない場合、所有構造の追加料金は発生しません。 合計金額には選択時に提示された料金が適用され、リクエストしたレベルの見積額を超えることはありません。 選択とその後の所有構造に関する調整は1件の登記照会として計上されます。購入したレポートの閲覧やその詳細の確認で再度請求されることはありません。 既存の定額契約では、選択時に1件の登記照会が計上され、後から所有構造が提供されても2つ目の契約単位は計上されません。 ホスト型ワークフローでの検索には、別途検索料金はかかりません。 スタンドアロンAPIでの検索では、成功したリクエスト1件あたり$0.50の料金が発生する場合があります。詳しくは検索の請求を参照してください。国別の料金表の全体はKYB登記照会の料金を参照してください。
ホスト型ワークフローでは、Workflows → KYB Registry Check → Countriesで国ごとにレベルを選択します。登記にその企業の所有構造の記録がない場合、株主またはUBOのリクエストは、その国の登記が提供できる最上位のレベル（通常はLite）で提供され、そのレベルで請求されます。
見つからずに手動で入力された企業（
is_from_registry: false）には、一律$0.75が請求されます。登記レコードが返されなかった場合でも、検索自体は実行されているためです。
例：Liteレベルのレスポンス
例：Liteレベルのレスポンス
登記データとユーザー提供データ
Diditは、登記から返されたデータとユーザーが確認したデータを別々の監査レコードとして保持し、後続のチェックではそれらを統合した正規ビューを使用します。各企業には、相互に関連する3つのブロックがあります。confirmed_by_user_atタイムスタンプは、エンドユーザーが登記データを確認または編集した日時を示します。このタイムスタンプがまだnullで、is_editableがtrueの間は、エンドユーザーはホスト型フロー内でフィールドを引き続き変更できます。
手動入力された企業（is_from_registry: false）の場合、user_provided_dataが唯一のソースとなり、ユーザーが送信した後はis_editableがfalseになります。
アナリストはBusiness Consoleのセッションレビューで2つのソースを並べて表示し、登記の内容とユーザーが確認した内容の差分を比較できます。
設定可能な登記フォームのフィールド
ホスト型検証フローの登記確認ステップで、どの企業データのフィールドを入力させるかを制御できます。設定はBusiness Consoleで行います。ワークフローエディターを開き、KYB Registry checkノードを選択して、Fieldsタブに切り替えてください。 各フィールドは、次の3つの状態のいずれかを取ります。
次の3つのフィールドは常に表示され、常に必須です。これらは企業を特定するためのもので、設定を変更することはできません。対象は
company_name、country_code、region(登記が地域単位で管理されている場合の州・地域)です。
設定可能な16個のフィールドは次のとおりです。
registration_number, incorporation_date, legal_address, vat_number, alternative_names, tax_number, company_type, legal_entity_identifier, location_of_registration, nature_of_business, registered_capital_amount, registered_capital_currency, website, email, phone, control_scheme
デフォルトでは(既存のすべてのワークフローを含め)、必須はincorporation_dateのみで、その他の設定可能なフィールドはすべて任意です。そのため、フォームはこの設定が導入される前とまったく同じように動作します。
必須かどうかはサーバー側で強制されます。必須フィールドが空のまま登記フォームを送信すると、フィールドごとのエラーメッセージとともに400が返されます。また、ホスト型UIには有効化されたフィールドのみが表示されます。ワークフローAPIでは、この設定はKYB Registryノードのkyb_registry_fields_configオブジェクトです。構造については機能設定を参照してください。
必須に設定した
vat_numberは、EUのVAT対象国(後述)で設立された企業に対してのみ強制されます。それ以外の国では、収集すべきEU VAT番号が存在しないため、必須に設定していても任意として扱われます。なお、それらの国の企業のtax_numberは、入力された場合は引き続き検証されます。VATおよび納税者番号の検証
登記ステップが送信されると、Didit は企業のvat_number を、その国の公式ソースと照合して検証します。
vat_number がない企業の場合は、代わりに tax_number を検証します。
番号は国プレフィックスの有無や区切り文字の種類を問わず送信できます（ドイツ企業の場合、DE 123 456 789、DE123456789、123456789 はいずれも同じ番号として扱われます）。
公式登記簿。 以下の国では、番号を政府または公式の商業登記簿とリアルタイムで照合します。登記簿からは登録名称（多くの国では住所も）が返されます。
VAT番号として送信されたフランスのSIRENまたはSIRET、オランダのRSIN、ハンガリーの完全な納税者番号は、照合前に対応するVAT番号に変換されます。
ギリシャのVAT番号は、自動的に
ELプレフィックスで照合されます。
チェックディジットルール。 以下の国では照会できる登記簿がないため、番号はその国の公式な形式とチェックディジットのルールに基づいて検証されます。対象国はアルバニア、アンドラ、アルゼンチン、オーストラリア、アゼルバイジャン、ベラルーシ、カナダ、チリ、中国、ドミニカ共和国、エジプト、エルサルバドル、ガーナ、グアテマラ、アイスランド、インド、インドネシア、イスラエル、日本、ケニア、リヒテンシュタイン、メキシコ、モルドバ、モナコ、モンテネグロ、モロッコ、モザンビーク、ニュージーランド、北マケドニア、ペルー、ロシア、サンマリノ、セルビア、シンガポール、南アフリカ、韓国、台湾、タイ、チュニジア、トルコ、ウクライナ、英国、米国、ウルグアイ、ベネズエラ、ベトナムです。
EU域内でも、tax_numberが照合すべきVAT番号を持たない国内の納税者番号（ドイツのSteuernummerなど）である場合は、これらのルールが適用されます。
tax_numberは納税者番号であることを示すだけで、VAT登録を示すものではありません。そのため、VIESに掲載されていない場合、結果はinvalidではなくこれらのルールによる検証にフォールバックします。
上記以外の国の企業にはvat_validation_status: "not_applicable"が返されます。
サンドボックスのセッションも同様で、税務登記簿に照会することはありません。
結果は企業に保存され、KYB判定ペイロードで公開されます。
vat_validation_sourceはeu_vies、pl_vat_white_list、no_brreg、ch_uid_register、br_receita_federal、co_rues、cr_hacienda、ec_sri、py_dnit、format_rulesのいずれかです。
番号がvalid、invalid、format_valid、invalid_formatのいずれかになると、その結果はセッションの終了まで保持され、番号が変更されない限り登記簿への再照会は行われません。
名称のクロスチェック。 番号がvalidで、ソースが登録名称を開示している場合、Didit はその名称を送信された企業名とあいまい比較します。
大きな相違がある場合はKYB_COMPANY_VAT_NAME_MISMATCH警告が発生しますが、セッションのステータスは変わりません。これはレビュアー向けのソフトシグナルです。
そのadditional_dataにはregistry_name、registry_source、submitted_nameが含まれ、ソースがVIESの場合はvies_nameも含まれます。
EU加盟国の中には名称や住所を開示しない国もあり、その場合はフィールドが空で返され、比較は実行されません。
設定可能なアクション。 KYB登記チェックノードの2つの設定で、照合が成功しなかった場合にセッションへ与える影響を制御します（値はREVIEW、DECLINE、NO_ACTION）。
invalid_formatとなったtax_numberは、ペイロードで報告されますがアクションはトリガーされません。自由記述の税フィールドには、別の企業識別子が入力されていることが多いためです。
各結果では、登記チェックに対応する警告（KYB_COMPANY_VAT_INVALID、KYB_COMPANY_VAT_COULD_NOT_VALIDATE）も発生します。詳しくは法人確認の警告を参照してください。
データの照合
Diditは、ユーザーが入力したデータまたは基準データを、法人登記から返されたデータおよびアップロードされた書類からOCRで抽出したデータと自動的に照合します。- 会社名：略称や表記の違いを考慮したあいまい一致
- 登記番号：完全一致による検証
- 国：入力された国と法人登記上の国の整合性チェック
- 住所：比較のためのジオコーディングと正規化
財務概要
取得可能な場合、Diditは法人登記から財務データの概要を取得します。- 売上高
- 従業員数
- SIC/NACE業種コード
- 提出日とコンプライアンス状況
その他の法人登記フィールド
法域ごとの対応範囲によっては、法人登記のレスポンスに以下が含まれる場合もあります。alternative_names：商号、DBA(屋号)、旧法人名legal_entity_identifier(LEI)：金融機関および上場企業向けwebsite、email、phone：法人登記に登録されている連絡先情報nature_of_business：事業内容の簡単な説明(法人登記の言語で記載)registered_capital：授権資本/発行済資本を表す{amount, currency}オブジェクト
businessブロックに格納されます。
信頼度と検証ステータス
法人登記の各レスポンスにはverification_statusが含まれます。
is_from_registryと組み合わせて、後続の独自ロジックを制御できます。
照合結果
各照合はフィールドごとに実行され、次のいずれかを返します。MATCH:入力されたデータが法人登記と一致しています。MISMATCH:重要な不一致があります。警告としてフラグが付けられます。NO_DATA:一方が空のため、比較できません。
判定結果を左右する要素
企業のステータス、設立国、AMLの結果、申告データとの一致状況は、法人登記チェックとAMLスクリーニングの警告タグとして判定に反映されます。 各警告に対して承認、レビュー、却下のいずれとするかは、ワークフローで決まります。 シグナルとそれを制御するワークフローのキーについては、リスク評価を参照してください。対応国
対応範囲は国によって異なります。地域ごとのレベル別の内訳は対応国を参照してください。次のステップ
所有構造
UBOの特定と所有構造の連鎖。
レスポンススキーマ
各フィールドがペイロードのどこに含まれるか。
対応国
地域別の対応範囲。