身元証明:Diditはどのように身分証明書から国籍を特定するか (JA)
銀行、フィンテック、政府サービスにおいて国籍確認が規制要件となりつつあります。Diditは、パスポート、帰化証明書、出生証明書などから国籍を抽出、認証、検証する方法をご紹介します。.

身分証明は、これまで「この人は誰か」という一つの問いに答えるものでした。名前、生年月日、政府発行の写真付き身分証明書、生体認証の一致。これだけで口座開設、AMLスクリーニングを通過し、進むことができました。
2026年、複数の管轄区域の規制当局は、第二の質問を追加しています。「この人の国籍は何か」。米国財務省は、銀行が顧客から国籍情報を収集することを義務付ける行政命令の草案を作成中です。EUのeIDAS 2.0フレームワークは、国籍をデジタルIDウォレットにおける一次属性として扱っています。有権者登録、ゲームライセンス、クロスボーダー金融サービス、政府給付金、移民に敏感な業界はすべて、国籍確認を「あったら便利」から「必須」へと押し上げています。
この記事では、Diditがどのように国籍証明を処理するか — どの書類がサポートされているか、抽出がどのように機能するか、どのような真正性チェックが実行されるか、そして出力がKYCスタックの残りの部分とどのように統合されるか — を説明します。
国籍証明として認められるもの
国籍は単一のデータポイントではありません。それは文書による証拠から派生し、認められる証拠は国によって異なります。グローバルに共通するパターンはいくつかあります。
- パスポートは最も強力な証明です。パスポートを発行するすべての国は、発行を国民に限定しています(難民旅行書類など、少数の例外を除きます)。この文書自体は、ICAO 9303規格に基づいて発行されており、これは機械可読ゾーン、構造化された視覚ゾーン、そして—最新版では—発行当局によって署名された同じデータを含むNFCチップがあることを意味します。
- 帰化証明書および国籍証明書は、取得した国籍を証明します。これらは通常、連邦または国家当局によって発行される紙の文書です。米国では、関連するフォームはN-550/N-570(帰化証明書)とN-560/N-561(国籍証明書)です。
- 出生証明書は、出生地による国籍が適用される管轄区域での出生による国籍を証明します。形式は大きく異なります—米国だけでも、すべての州、準州、および多くの郡が独自のものを発行しています。
- 海外出生届(米国ではCRBA / FS-240、他の国では同等の文書)は、自国の外で生まれた国民を対象とします。
- 国民IDカードは、国民IDが国民のみに発行される国(EUの大部分、ラテンアメリカの一部、中東の大部分)では、国籍を示します。居住者も国民IDを所持できる国(例: 一部の湾岸諸国、一部のEU長期居住者カード)では、国民IDだけでは国籍は証明されません。
パスポートを持っていない顧客をサポートする検証プロバイダーは、存在しません。米国成人の約52%、そしてラテンアメリカおよび東南アジアの多くの地域では、さらに高い割合の人がパスポートを所持していません。運転免許証のみをサポートするプロバイダーは、国籍確認の要件を一切満たすことができません—運転免許証は、ほとんどの管轄区域での適法な居住を証明するものであり、国籍を証明するものではありません。
Diditの文書ライブラリは、220以上の国と14,000以上の文書タイプを網羅しています。
検証フロー
顧客の視点から見ると、フローはスマートフォンまたはデスクトップで連続したセッションです。裏側では、6つのレイヤーが並行して実行されます。
レイヤー1:文書キャプチャ
顧客に文書の写真を撮るように求められます。キャプチャSDKは、フレーミング、グレア検出、フォーカス、低照度補正を処理します。ぼやけていたり、暗すぎたり、トリミングされたりしたスキャンは拒否します。パスポートの場合、MRZと、デバイスがNFCをサポートし、パスポートにチップが搭載されている場合は、電話にパスポートをタップしてチップを読み取るように促します。
出生証明書および帰化証明書—MRZまたはチップがない場合—キャプチャフローは、顧客にコントラストのある表面で完全な文書を撮影するように指示し、複数ページにわたる文書の場合は複数のページを受け入れることができます。
レイヤー2:文書分類
フィールド抽出の前に、文書が分類されます:タイプ、国、発行当局、発行年範囲。分類は、14,000以上の文書ライブラリでトレーニングされたモデルで実行されます。つまり、テキサス州の出生証明書とジョージア州の出生証明書、1998年代の帰化証明書と最新のもの、米国のパスポートブックと米国のパスポートカードを区別できます。
分類出力は下流の処理を駆動します。異なる文書タイプは、異なるフィールドスキーマ、異なるセキュリティ機能、および異なる真正性シグナルチェックを持っています。
レイヤー3:フィールド抽出
OCRは、識別された文書タイプに対して構造化されたフィールドを抽出します。ICAOパスポートでは、名前、生年月日、国籍、パスポート番号、発行国、有効期限、性別、出生地、MRZチェックディジットです。帰化証明書では、A番号、名前、生年月日、以前の国籍、帰化日、証明書番号です。米国の州の出生証明書では、名前、生年月日、出生地、両親の名前、登録の詳細です。
抽出モデルは、文書タイプごとに調整されています。ミシシッピ州の出生証明書に汎用OCRを実行すると、ごみが生じます—タイポグラフィは異常で、セキュリティ背景はノイズが多く、フィールドレイアウトは発行年によって異なります。文書固有の抽出は、97%と60%の自動化率の違いです。
レイヤー4:真正性チェック
ここで、ほとんどの不正防止が行われます。文書によって、システムは以下を実行します。
- MRZ整合性チェック—機械可読ゾーンには、エンコードされたデータから計算されたチェックディジットが含まれています。偽造または改ざんされたパスポートは、このチェックに失敗します。
- NFCチップ検証—チップが存在する場合、システムは署名されたデータグループを読み取り、発行国の信頼リスト(例: ICAO PKD)に対して発行者の署名を検証し、チップデータを視覚ゾーンと比較します。
- セキュリティ機能検出—ホログラム、UV機能、マイクロ印刷、凹版、ゴーストイメージ。モデルは、発行当局がその文書バージョンに使用する特定の機能を検索します。
- テンプレートマッチング—文書は、同じ年範囲の発行当局の参照テンプレートと比較され、フォントの不一致、レイアウトのずれ、色の不一致が調べられます。
- 改ざん検出—スプライス検出、コピーペーストアーティファクト、写真の置換、フィールドレベルの編集。これは、正当な文書が発行後に変更された場合に検出します。
- 画像フォレンジック—デジタル専用文書、スクリーンショットアーティファクト、既知の偽造ツールのレンダリング署名の検出。
出生証明書やその他の低セキュリティ文書の場合、真正性チェックは、テンプレートマッチングと改ざん検出により大きく依存します。これは、文書クラスの構造的な弱点であり、検証の問題ではありません—正しい緩和策は、出生証明書のみの検証を、追加のシグナル(SSN検証、住所履歴、デバイスリスク)と組み合わせることであり、出生証明書のOCRが強力な証明であると想定することではありません。
レイヤー5:生体認証マッチングとライブネス
文書の写真は、顧客のデバイスからキャプチャされたライブセルフィーと比較されます。ライブネスレイヤーは、セルフィーがライブの人であり、写真の写真、ディープフェイク、3Dマスク、またはリプレイ攻撃ではないことを確認します。顔マッチングレイヤーは生体特徴を比較し、マッチスコアを返します。
写真が含まれていない国籍書類—米国の出生証明書、特定の帰化証明書、一部の古い国民ID—生体認証ステップは、同じセッションで収集された別の写真付きIDに対して実行されます。顧客は両方の文書をアップロードします。生体認証は写真付きIDと照合されます。国籍の証拠は、検証されたIDに関連付けられます。
レイヤー6:出力
APIは構造化された検証レコードを返します。
- 文書タイプ、国籍、抽出されたフィールド
- 真正性スコアとパスまたは失敗した特定のチェック
- 生体認証マッチスコアとライブネス結果
- 全体的な決定(承認、レビュー、拒否)および理由コード
- ハッシュ化された文書画像、タイムスタンプ、システムバージョンを含む、改ざん防止監査証跡
このレコードは、制裁スクリーニング、PEPおよび有害メディアチェック、および継続的な監視—完全なKYCスタック—に同じAPIを介して統合されます。
国籍検出が実際に返すもの
一般的な統合パターンは、検証セッションを作成する単一の呼び出しであり、結果が完了したときにWebhookが構造化された結果を配信することです。国籍部分の結果の簡略化された例:
```json
{
"status": "approved",
"document": {
"type": "certificate_of_naturalization",
"country_of_issue": "US",
"form_number": "N-550",
"extracted_fields": {
"a_number": "A-xxxxxxxxx",
"certificate_number": "xxxxxxxx",
"name": "JANE DOE",
"date_of_birth": "1985-06-12",
"country_of_former_citizenship": "MX",
"date_of_naturalization": "2014-09-18"
}
},
"citizenship": {
"status": "US",
"acquisition": "naturalization",
"evidence_document_type": "certificate_of_naturalization",
"confidence": 0.98
},
"authenticity": {
"overall_score": 0.96,
"checks": {
"template_match": "pass",
"security_features": "pass",
"tampering": "pass",
"image_forensics": "pass"
}
},
"biometric": {
"liveness": "pass",
"face_match_score": 0.93
}
}
```
同じ形状は、すべての文書タイプに適用されます。米国のパスポートの場合、国籍フィールドにはstatus: "US"、acquisition: "birth_or_unspecified"、evidence_document_type: "passport"が含まれ、完全なMRZとNFCの結果が真正性のブロックに含まれます。出生証明書の場合、国籍フィールドには、派生したステータス、発行州、および出生証明書が文書クラスとしてセキュリティプロファイルが弱いことを反映した低い信頼度スコアが含まれます。
下流システム—コアバンキング、コンプライアンスケース管理、データウェアハウス—は構造化されたフィールドを消費し、それに応じてルーティングします。
重要なエッジケース
実際の国籍検証は、カジュアルな実装では見逃される可能性のある多数のケースを処理する必要があります。
二重国籍。 米国市民であり、メキシコ市民でもある人は、メキシコのパスポートを提示します。パスポートは正当にメキシコ国籍を証明します。米国市民権を否定するものではありません。ユースケースで特に米国市民権を確認する必要がある場合、フローは追加の米国発行の証拠を同じセッションで受け入れる必要があります。
国籍を持たない者および難民。 1951年の難民条約または1954年の無国籍者条約に基づいて発行された旅行書類は、パスポートのように見えますが、明示的に国籍を確認するものではありません。Diditはこれらの文書を明確に識別し、発行国としての国籍を扱うのではなく、正しいステータスを提示します。
最近帰化された市民。 60日以内に帰化された顧客は、まだ米国のパスポートを持っていない場合があります。彼らは帰化証明書を持っています。フローは、パスポートを要求するのではなく、証明書を主要な国籍証明として受け入れる必要があります。
海外生まれの市民。 ドイツで米国人の両親のもとに生まれた米国市民は、米国の出生証明書ではなく、海外出生届(CRBA / FS-240)を持っています。フローは、CRBAを国籍証明として認識する必要があります。
名前の変更と文書の不一致。 帰化の際に別の名前で帰化し、その後法的に名前を変更した顧客は、古い名前の帰化証明書と新しい名前の現在のパスポートを提示します。検証は、両方を拒否することなく、それらを結び付ける必要があります。
過去の文書。 1987年に発行された帰化証明書は、2024年に発行されたものとは異なります。テンプレートマッチングと真正性チェックは、現在の形式だけでなく、発行履歴にわたる必要があります。
これらのケースでサイレントに失敗する検証スタックは、実際に国籍の問題を解決しているわけではありません—簡略化されたサブセットを解決し、残りを手動レビューに回しています。Diditのライブラリには、設計により、過去の文書とエッジケースのバリアントが含まれています。
プライバシーとデータ処理
国籍は機密データです。ほとんどのプライバシーフレームワークは、国籍と移民ステータスを、人種、宗教、政治的意見など、保護されたカテゴリとして扱っています。誤って保存すると、最初のコンプライアンスの問題を解決しようとしながら、新しいコンプライアンスの問題が発生します。
Diditの国籍データに関する姿勢:
- データ最小化。 プラットフォームは、顧客が構成した国籍フィールドのみを返します。「この人が米国市民であるかどうか、はい/いいえ」のみが必要な貸し手は、完全な文書データではなく、ブール値を受け取ることができます。
- コントローラー/プロセッサーの境界。 Diditはプロセッサーとして機能します。顧客(銀行、フィンテック、プラットフォーム)がコントローラーです。処理の法的根拠は顧客にあり、DiditのDPAはそれを反映しています。
- 暗号化による保存中および転送中の保護とキーのローテーション。
- 規制上の義務に準拠するために必要な最小限の保持期間で構成可能な保持制御、その後は消去。
- 内部の説明責任と規制当局からの召喚に対応するためのすべてのアクセスの監査ログ記録。
- GDPR、LGPD、CCPA、およびAPPIに準拠したデータ処理および該当する場合は地域固有の居住オプション。
目標は、顧客が規制上の義務を満たすことができるようにすることであり、検証レイヤーから新しい義務を引き継ぐことはありません。
国籍検証の統合
本番環境への最速のパスは、ホストされた検証フローです。1つのAPI呼び出しでセッションを作成し、顧客が携帯電話でアクセスするURL、結果を含むWebhookです。フローは、キャプチャ、OCR、真正性、生体認証マッチング、および結果配信を1つのセッションで処理します。
チームがホワイトラベル化されたUI、カスタムブランチングロジック、特定のドキュメントタイプの制限などのより深いカスタマイズを必要とする場合は、SDKと直接APIが各レイヤーを完全に制御できます。
一般的な統合パターン:
- 銀行および信用組合:口座開設時および新しい米国ルールに基づいて既存の口座の再検証時に、国籍キャプチャがトリガーされます。結果はコアバンキングシステムとAMLケース管理キューにフィードされます。
- フィンテック:規制が必要な場合(例:顧客が月間のボリューム制限を超えた場合)に、口座アップグレード時またはその時点で国籍キャプチャ。
- 暗号通貨取引所:オペレーターが特定の国の市民または居住者のみにサービスを提供するようにライセンスされている管轄区域での国籍キャプチャ。
- ゲームおよびiGamingオペレーター:ライセンスが必要な場合、年齢検証と組み合わせて国籍キャプチャ。
- 政府サービスプロバイダー:定義された証拠基準に基づいて給付金の資格の国籍キャプチャ。
- クロスボーダーサービス:顧客を適切な管轄区域のコンプライアンスパイプラインにルーティングするための国籍キャプチャ。
これにより何が得られるか
適切に行われた国籍検証レイヤーは、チェックボックスではありません。それは、ダウンストリームシステムが利用できる新しい形状の身分データです。銀行は、国籍に基づいて適切なオンボーディングトラックに顧客をルーティングできます。取引所は、IPベースのジオロケーションに依存することなく、管轄区域の制限を施行できます。政府は、紙ベースのプロセスなしに給付金の資格を検証できます。プラットフォームは、KYCスタックを再構築することなく、出現する国籍ゲート付きの規制に準拠できます。
2026年4月に議論されている米国の行政命令は、強制的な機能です。それは最後ではありません。規制の移動の方向性は、より豊富なデータ製品としての身分証明の検証—身分、国籍、制裁状態、リスクプロファイル、継続的な監視—であり、2分以内の携帯電話で機能する単一のフローで提供されます。
Diditの賭けは、当初から、広範な文書のカバレッジ、構造化された出力、1回のチェックあたりの価格設定、そして顧客がすでに実行しているシステムにシームレスに統合されるAPIサーフェスでそれを実現することです。国籍検出はその賭けの自然な延長です。
---
Diditは、銀行、フィンテック、暗号プラットフォーム、および政府サービス向けに国籍、身分、および制裁エクスポージャーを検証します。14,000以上のドキュメントタイプ、220以上の国、48以上の言語、1回の検証あたり0.30ドル、最低限度なし。無料で開始またはチームに相談してください。
