銀行口座確認：銀行ログイン不要で口座名義を照合

この口座チェックは、エンドユーザーが入力した口座情報をもとに、ワークフローですでに検証済みの本人がその銀行口座の名義人であることを確認します。銀行へのサインインも同意画面もありません。エンドユーザーは自国の表記方法で口座情報を入力し、銀行は口座の名義を、前のステップで検証された氏名と照合します。これは、銀行サインインと並ぶ2つの銀行認証の方法のうちの1つです。methodの値はaccount_lookupです。明細書のアップロードと少額入金は、この2つの後に続くフォールバックとして残り、エンドユーザーはいつでも銀行を使わずに続行できます。支払いの前など、セッションを使わずにバックエンドから口座を確認するには、口座チェックAPIを使用してください。

銀行認証は、本番環境ではまだ有効になっていません。有効になるまでは、本番環境でもサンドボックスでも、このステップをワークフローに追加することも、このAPIを呼び出すこともできません。このページでは、今後の動作について説明しています。

銀行認証では、別のステップで確立された本人情報と照らし合わせて口座の名義人を確認するため、単独で身元を証明するものではありません。このステップの前に、本人確認、データベース検証、アンケート、またはexpected_detailsを配置してください。エンドユーザーがこのチェックのために氏名を入力することはありません。Didit は常に、セッションですでに検証された氏名を照合します。

仕組み

エンドユーザーが国を選択する

銀行認証ステップで、エンドユーザーはステップが提供する国を選択します。その国で口座チェックが最初の方法になっている場合、ステップはその国の口座形式に合わせた簡単なフォームを開きます。銀行サインインが最初の方法になっている場合、エンドユーザーは口座情報を入力を選んでフォームに進みます。

エンドユーザーが口座情報を入力する

たとえば、IBAN、ソートコードと口座番号、またはCLABEなどです。検証フローは、その国についてAPIが返す内容からフォームを生成するため、Didit が後から国を追加しても、お客様側で変更する必要はありません。

Didit がまず形式を確認する

課金が発生する前に、Didit は各値の長さ、文字、チェックディジットを確認し、IBANの場合は選択された国のものであることも確認します。確認に失敗した値は、修正すべきフィールドを示したうえで拒否されます。エンドユーザーはその場で修正でき、試行回数は消費されません。

銀行が口座の名義を確認する

Didit は、セッションで検証された氏名に対して1回のチェックを実行します。クライアントが送信するそれ以外の情報は無視されます。

ステップが判定する

レスポンスは口座の所有者確認結果となり、銀行サインインの場合とまったく同じように、ステップのアクションがそれを判定に変換します。

チェックの提供範囲

対応範囲は国ごとに決まります。Didit は、料金設定済みのルートを用意できた国から順にチェックを有効にしており、ルートがない国ではチェックは提供されません。対応国は順次追加され、ステップは常に最新のリストを読み込むため、国が追加されても連携を変更する必要はありません。対応国の中では、ステップの方法設定によって、エンドユーザーにチェックが表示されるかどうかが決まります。

ステップの順序。 bank_method_orderは、すべての国で提供する方法と、最初に提示する方法を設定します。デフォルトの["open_banking", "account_lookup"]では、銀行サインインから始まり、口座チェックがそのバックアップとして提供されます。
国ごとの順序。 bank_countries内の国に設定したmethodsは、その国でステップの順序を上書きします。たとえば、口座チェックのみにする場合は["account_lookup"]、口座チェックから始める場合は["account_lookup", "open_banking"]とします。
銀行が停止している場合。 口座チェックを提供している国では、銀行サインインの稼働状況が低下または停止している銀行の代替手段にもなります。エンドユーザーに口座チェックの残り回数がある限り、ステップは同意を求める前に口座フォームへ移ります。
チェックは Didit 独自のルートで実行されます。 お客様独自のマーケットプレイスプロバイダー(provider_key)で動作するステップでは、fallback_to_nativeが有効な場合にのみ提供されます。
法人口座。 法人確認セッションでは、Didit が法人口座を確認している国において、法人口座を検証済みの企業と照合します。

保存時に適用されるルールについては、国ごとに方法を選択するを参照してください。

エンドユーザーが入力する内容

以下は、フォームが対応している口座形式です。これは対応国のリストではありません。ある国でチェックが実行されるかどうかは提供範囲によって決まり、ステップは常にその国に必要なフィールドを正確に表示します。

口座形式	国	エンドユーザーが入力する内容
IBAN	IBANを使用する国	IBAN全体。選択された国のものである必要があります
ソートコードと口座番号	イギリス	6桁のソートコードと8桁の口座番号
ルーティング番号と口座番号	アメリカ	9桁のABAルーティング番号と口座番号
支店番号と金融機関番号	カナダ	8桁の支店番号と金融機関番号(5桁の支店番号に続けて3桁の金融機関番号)と口座番号
BSBと口座番号	オーストラリア	6桁のBSBと口座番号
CLABE	メキシコ	18桁のCLABE。銀行もこれで特定されます
CBUまたはCVU	アルゼンチン	22桁のCBUまたはCVU。銀行もこれで特定されます
IFSCと口座番号	インド	11文字のIFSCと口座番号
NUBANと銀行コード	ナイジェリア	10桁のNUBANと、銀行のコードまたはBIC
口座番号	その他の国	口座番号と、国によって必要な場合は銀行コードまたはBIC

一部の国では、フォームで登記番号の入力も求められます。法人口座の場合に加え、いくつかの国ではすべての口座で求められます。値を確認する前に、スペース、ハイフン、ピリオドは削除され、英字は大文字に変換されます。そのため、エンドユーザーは銀行の表記どおりに口座情報を入力できます。

有効にする方法

新しいステップでは、銀行サインインの代替手段として口座確認がデフォルトで提供されます。口座確認から開始する場合、または口座確認のみを提供する場合は、順序の先頭にaccount_lookupを置きます。

{
  "bank_method_order": ["account_lookup", "open_banking"]
}

口座確認の動作は、次の設定で決まります。

設定	口座確認への影響
`bank_method_order`、`bank_countries.<ISO3>.methods`	その国で口座確認を提供するかどうか、および銀行サインインの前後どちらに配置するか。
`bank_countries`	口座確認は、ステップが提供する国でのみ実行されます。
`bank_reference_identity`	口座の照合に使う確認済みの氏名を持つステップ。
`bank_account_check_max_attempts`	本人が受けられる口座確認の回数で、`1`から`5`まで(デフォルトは`3`)。銀行サインインの`bank_max_attempts`とは別にカウントされます。
`bank_account_check_accept_close_match`	オン(デフォルト):近似一致は、近似一致の確認画面または`bank_partial_match_action`に進みます。オフ:近似一致はすべて不一致となります。
`bank_name_match_threshold`、`bank_partial_match_floor`	銀行サインインと同じ氏名スコアの区分です。しきい値(デフォルトは85)以上は一致、下限(デフォルトは70)以上かつしきい値未満の部分一致の範囲は近似一致となります。
`bank_use_provider_score`	オン(デフォルト):口座確認自体の氏名スコアがDiditのスコアより高い場合、または口座確認がスコアを返したものの名義人名を返さない場合は、そのスコアで判定され、`ownership.method`は`provider_only`となります。オフ:名義人名のない回答は`not_verifiable`となります。
`bank_suggest_holder_name`	オン(デフォルト):名義人名が示された近似一致の場合、本人にその氏名が表示され、本人は自分の氏名であることを確認するか、別の口座を試します。

結果

回答が返る口座確認

これらはいずれも1回分課金され、本人の口座確認の回数(bank_account_check_max_attempts)を1回消費します。ステップが完了するまでは、確認回数が残っていれば、本人は別の口座で再試行できます。結果はownership.resultに格納されます。ただし、口座が存在しない場合はconnection.reason_codeに格納されます。

口座確認の回答	結果	判定を決めるもの
口座が確認済みの本人のものである	`match`	ステップの他の確認で別の結果にならない限り、ステップは承認されます。
名義人名が示された近似一致	`partial_match`	`bank_suggest_holder_name`がオンの場合、本人は氏名を確認するか、別の口座を試します。確認すると、ステップは`bank_partial_match_action`(デフォルトは`REVIEW`)で終了します。
スコアはあるが名義人名のない近似一致	`partial_match`	`bank_partial_match_action`(デフォルトは`REVIEW`)。`ownership.method`は`provider_only`となります。これには`bank_use_provider_score`がオン(デフォルト)である必要があり、オフの場合、回答は`not_verifiable`となります。
口座が他人のものである	`no_match`	`bank_no_match_action`(デフォルトは`DECLINE`)。
氏名を照合しなかった回答	`not_verifiable`	`bank_not_verifiable_action`(デフォルトは`REVIEW`)。
入力された情報に該当する口座が存在しない	`ACCOUNT_NOT_FOUND`	確認回数が残っていれば、本人は別の口座を試せます。

bank_account_check_accept_close_matchがオフの場合、どちらの近似一致も代わりにno_matchとなり、理由コードはOWNER_NAME_MISMATCHです。本人に氏名の確認を求めることはなく、bank_no_match_actionで判定されます。銀行サインインでは、どちらの設定でも近似一致はそのまま扱われます。本人が、接続に成功しないまま、すべての口座確認と、その国で銀行サインインも提供されている場合はすべての銀行サインインの試行を使い切ったとき、試行回数の残った明細書アップロードをまだ提供していれば、ステップは開いたままとなります。詳しくは明細書のアップロードを参照してください。利用できる方法が残っていない場合、ステップはbank_attempts_exhausted_action(デフォルトはDECLINE)で終了します。ただし、氏名の不一致など、それ以前の試行ですでに判定が出ている場合は除きます。その場合は、その判定が維持されます。

課金されない結果

これらはいずれも確認回数を消費しません。それぞれconnection.reason_codeに表示されます。

発生する事象	理由コード	その後の流れ
入力された口座が、Diditの形式チェックまたは銀行によって拒否される	`INVALID_ACCOUNT_INPUT`(試行は開いたまま)	修正すべきフィールドが本人に示され、本人が修正します。
口座確認が現在利用できない	`PROVIDER_UNAVAILABLE`	本人は再試行できます。
セッションに照合用の確認済み氏名がない	`REFERENCE_IDENTITY_MISSING`	口座確認は実行されません。ステップは`bank_reference_identity_missing_action`(デフォルトは`REVIEW`)で終了します。

判定での表示

セッションの判定では、ステップがbank_verifications[]の下に記載されます。口座が評価されると、methodはaccount_lookupとなります。口座が評価されていない間は、methodとownershipはnullとなり、connection.reason_codeにその理由が示されます。たとえばACCOUNT_NOT_FOUND、PROVIDER_UNAVAILABLE、REFERENCE_IDENTITY_MISSINGなどです。口座確認では銀行が選択されないため、connection.institution_id、connection.institution_name、connection.oauthはnullとなり、connection.institution_countryは本人が選択した国となります。ステップの完了後、Diditは口座へのアクセスを保持しないため、一致で終了した口座確認はconnection.status: revoked、reason_code: VERIFICATION_COMPLETEDとなります。結果自体はセッションに残ります。口座確認では、残高、取引、収入は読み取りません。ステップでこれらが求められている場合は、financial_data.not_collectedに記載されます。財務データには銀行サインインが必要を参照してください。

{
  "bank_verifications": [
    {
      "status": "Approved",
      "method": "account_lookup",
      "connection": {
        "status": "revoked",
        "institution_id": null,
        "institution_name": null,
        "institution_country": "ESP",
        "oauth": null,
        "attempts": 1,
        "reason_code": "VERIFICATION_COMPLETED"
      },
      "ownership": {
        "result": "match",
        "method": "exact"
      },
      "financial_data": {
        "balances": null,
        "transactions": null,
        "income": null,
        "categorization": null,
        "not_collected": []
      },
      "billing": {
        "route": "native",
        "billed": true,
        "marketplace_fee": null,
        "usage_type": "bank_verification"
      }
    }
  ]
}

この例では、このページで説明するフィールドのみを示しています。口座が評価された後、口座確認と銀行サインインを区別するにはmethodを確認してください。この区別のために用意された唯一のフィールドです。

ワークフロールールとレポートでの表示

分岐とステータスルール:bank.methodはaccount_lookup(ルールビルダーでは口座確認)となり、bank.reason_codeはACCOUNT_NOT_FOUNDとなる場合があります。
セッションPDFレポート: 確認方法の行には口座確認と表示されます。

料金

回答を返したチェックは、1件ごとに銀行口座認証1回分として課金されます。一致、近似一致、不一致、照合できなかった口座、見つからなかった口座はいずれも課金対象です。チェック前に拒否された値、利用できなかったチェック、比較対象となる認証済みの氏名がないセッションが課金されることはありません。料金は国ごとに設定されています。銀行口座認証の料金を参照してください。口座チェックはそれ自体が独立した有料の方式であり、フォールバックとして扱われることはありません。そのため、bank_fallback_used_actionはこのチェックでは発動しません。課金されたチェックの後は、ステップで有効化されていて、その国で提供されている場合、同じセッション内で少額入金と明細書のアップロードを追加料金なしで利用できます。

サンドボックスでテストする

サンドボックスアプリケーションでは、チェックはシミュレートされたサービス上で実行され、課金は一切発生しません。サンドボックスでは、すべての国で両方の方式が、ステップで設定された順序で提供されます。デフォルトの順序では、口座情報を入力を選ぶとチェックが実行されます。bank_method_orderを["account_lookup", "open_banking"]に設定すると、最初からこの方式で開始することもできます。ユーザーが入力した口座情報(IBAN、IBANがない場合は口座番号)の末尾4文字によって回答が決まります。それ以外の末尾の場合は、認証済みの氏名と一致する回答になります。

末尾	回答
`0001`	名義人の氏名を示す近似一致。ユーザーに氏名の確認が求められます。`bank_account_check_accept_close_match`がオフの場合は不一致になります。
`0002`	名義人の氏名を含まない近似一致。`bank_partial_match_action`によって処理が決まります。`bank_use_provider_score`がオフの場合、回答は`not_verifiable`になります。`bank_account_check_accept_close_match`がオフの場合は不一致になります。
`0003`	不一致。口座は別人のものです。チェックを1回消費します。
`0004`	回答はあるものの、氏名は比較されていません(`not_verifiable`)。チェックを1回消費します。
`0005`	チェックを利用できません(`PROVIDER_UNAVAILABLE`)。無料で再試行できます。
`0006`	この情報に該当する口座がありません(`ACCOUNT_NOT_FOUND`)。チェックを1回消費します。
`0009`	入力された値が拒否されます。ユーザーにフィールドの修正が求められます。試行は継続中のままです。

サンドボックスでは、回答のあった各チェックが無料の利用として記録されるため、本番環境のセッションであればどのチェックが課金されるかを確認できます。 IBAN、CLABE、CBUにはチェックディジットが含まれるため、末尾4文字を単純に変更することはできません。すべての形式チェックを通過する次の値を使用してください。

回答	IBAN
一致	`DE43123456789012345678`
`0001`	`DE62123456789012340001`
`0002`	`DE35123456789012340002`
`0003`	`DE08123456789012340003`
`0004`	`DE78123456789012340004`
`0005`	`DE51123456789012340005`
`0006`	`DE24123456789012340006`
`0009`	`DE40123456789012340009`

ソートコード123456と組み合わせて使用します。

回答	口座番号
一致	`12345678`
`0001`	`12340001`
`0002`	`12340002`
`0003`	`12340003`
`0004`	`12340004`
`0005`	`12340005`
`0006`	`12340006`
`0009`	`12340009`

ルーティング番号021000021と組み合わせて使用します。

回答	口座番号
一致	`000123456789`
`0001`	`000123450001`
`0002`	`000123450002`
`0003`	`000123450003`
`0004`	`000123450004`
`0005`	`000123450005`
`0006`	`000123450006`
`0009`	`000123450009`

回答	CLABE
一致	`002010077777777771`
`0001`	`002010077777780001`
`0002`	`002010077777750002`
`0003`	`002010077777720003`
`0004`	`002010077777790004`
`0005`	`002010077777760005`
`0006`	`002010077777730006`
`0009`	`002010077777740009`

回答	CBU
一致	`2850590940090418135201`
`0001`	`2850590940090418160001`
`0002`	`2850590940090418170002`
`0003`	`2850590940090418180003`
`0004`	`2850590940090418190004`
`0005`	`2850590940090418100005`
`0006`	`2850590940090418110006`
`0009`	`2850590940090418140009`

IFSCALLA0211480と組み合わせて使用します。

回答	口座番号
一致	`123456789007`
`0001`	`123456780001`
`0002`	`123456780002`
`0003`	`123456780003`
`0004`	`123456780004`
`0005`	`123456780005`
`0006`	`123456780006`
`0009`	`123456780009`

口座チェックAPIは、サンドボックスキーでのリクエストに対し、セッションなしで同じ末尾のルールに従って回答します。サンドボックスアプリケーションの一般的な仕組みについては、サンドボックスでのテストを参照してください。

認証

検証

モニタリング

プラットフォーム

銀行口座確認：銀行ログイン不要で口座名義を照合

仕組み

チェックの提供範囲

エンドユーザーが入力する内容

有効にする方法

結果

回答が返る口座確認

課金されない結果

判定での表示

ワークフロールールとレポートでの表示

料金

サンドボックスでテストする

​仕組み

​チェックの提供範囲

​エンドユーザーが入力する内容

​有効にする方法

​結果

​回答が返る口座確認

​課金されない結果

​判定での表示

​ワークフロールールとレポートでの表示

​料金

​サンドボックスでテストする

仕組み

チェックの提供範囲

エンドユーザーが入力する内容

有効にする方法

結果

回答が返る口座確認

課金されない結果

判定での表示

ワークフロールールとレポートでの表示

料金

サンドボックスでテストする