メインコンテンツへスキップ

概要

住所証明(POA)の検証では、最大15MBのPDFまたは画像(TIFF、JPG、JPEG、PNG、WEBP、ZIP圧縮も可)を1件受け付けます。書類タイプの分類、LLMによる抽出、PDF/EXIFフォレンジックを実行し、以下を返します。
  • 抽出された住所: 未加工の住所と、構造化された住所(street_1、city、region、postal_code、緯度/経度)の両方。
  • 書類メタデータ: ファイルサイズ、コンテンツタイプ、作成日と更新日、EXIFの日付、署名情報、およびPDFフォレンジックで検出されたオーバーレイ改ざんの証拠。
  • 氏名の一致スコア: 検証済みの本人確認書類との比較結果と、セッション作成時に指定された期待値との比較結果。
  • 銀行関連の追加フィールド(口座番号、IBAN、ソートコード、ルーティング番号、SWIFT/BIC、支店): 書類が銀行取引明細書の場合に返されます。
抽出された住所フィールドと書類タイプを示すDiditの住所証明レポートのスクリーンショット
POAの抽出では非構造化テキストの読み取りを行うため、書類1件あたり5〜15秒のレイテンシが発生します。Webhookはワークフローのステップ全体が完了したときにのみ送信されます。この間、判定エンドポイントを5秒より短い間隔でポーリングしないでください。

APIレスポンスでの表示位置

判定エンドポイントは、GET /v3/session/{sessionId}/decision/でPOAを配列poa_verifications[]として返します。各エントリは、ワークフロー内のPOAノードの1回の実行に対応します。複数のPOAステップ(例: 銀行取引明細書と公共料金の請求書)を含むセッションでは、実行ごとに1件のエントリが生成され、それぞれが独自のnode_idを持ちます。
以下の構造は正規スキーマと同じです。データモデルを参照してください。

スキーマ

正式なスキーマについては、データモデルリファレンスの住所証明を参照してください。
warnings[]の各エントリはWarningオブジェクトで、構造は{ feature, risk, additional_data, log_type, short_description, long_description, node_id }です。このレポートでは、featureは常に"PROOF_OF_ADDRESS"です。

ステータス値

statusには機能レベルのステータス列挙型(FeatureStatusChoices)が使用されます。 ワークフローノードで設定したカスタムステータスルールにより、算出されたステータスをさらに調整できます。ルールはDeclined > In Review > Approvedの優先順位で組み合わされます。FUTURE_ISSUE_DATEのワークフロー限定の再試行動作を含め、リスクとアクションの対応関係の全体については住所証明の警告を参照してください。

PDFオーバーレイ改ざんの証拠

提出された書類がPDFの場合、document_metadata.overlay_manipulationには、テキストのオーバーレイが疑われることを示すフォレンジック証拠が含まれる場合があります。
  • detected: チェックで改ざんの証拠が見つかった場合はtrue。
  • analyzed: PDFをそもそも解析できた場合はtrue。
  • signals: 検出されたチェック(duplicate_font_subset、glyph_fragmentation)。
  • manipulated_regions: 編集が疑われるテキストを囲む、ページ座標上の矩形。各矩形はPDFページの座標空間(x、y、width、height、page_width、page_height)を使用するため、レビュアーはPDFプレビューで該当箇所をハイライト表示できます。
書類がPDFでない場合、またはPDFを解析できなかった場合、このフィールドはnullになります。detected=trueの場合、システムはSUSPECTED_DOCUMENT_MANIPULATION警告も発行し、そのadditional_dataには上記のシグナルと矩形が反映されます。ただし、より強いシグナル(電子署名後の改変、is_tampered=true)が優先された場合は、additional_dataには代わりに署名の改ざん内容が記述されます。

QRコードとバーコード

すべてのPOAレポートには、処理されたすべてのページを対象とするdetected_codesが含まれます。各項目には以下が含まれます。 サポートされているコードが見つからない場合、detected_codesは空の配列になります。Diditがペイロードを推測することはありません。損傷したコードや読み取れないコードは、位置とparsed_payload: nullとともに返される場合があります。また、コード検出に失敗してもPOA検証は失敗しません。

例

銀行取引明細書が承認済みになる例

オーバーレイ改ざんと氏名の不一致で却下される例

関連情報

document_fileとextra_files[]は、約4時間で期限切れになる署名付きURLです。URLを更新するには、判定エンドポイントを再度呼び出してください。自社側には検証ステータスと解析済みの住所フィールドのみを保存し、保持する書類データは最小限に抑えてください。
最終更新日 2026年11月1日