Backbaseの対話型バンキング——顧客の確認を実行に結び付ける設計

銀行の窓口がチャットや音声になり、「なくしたカードを止めて、再発行して」と伝えるだけで手続きが進む。

その途中で「この内容で実行してよろしいですか」と確認が入るとき、その応答から何が分かり、銀行側では何を別に判断する必要があるのでしょうか。

2026年10月8日、オランダの Backbase が銀行向けの対話型バンキング製品「Conversational Banking」の一般提供開始を発表しました。

同社は、銀行が定める権限・方針・承認、顧客による明示的な確認、判断の記録といった複数の統制を組み合わせる設計を説明しています。

本稿ではそのうち顧客の確認を取り上げ、同種の仕組みを金融機関が導入・設計する際に、確認を実際の取引や銀行側の判断とどう結び付けるか、確かめておきたい条件を整理します。

公式発表で確認できること

Backbase の発表によれば、顧客や行員が音声やテキストで依頼を伝えると、AIエージェントが、銀行の定める権限・方針・承認の範囲内で銀行業務の操作へつなげます。

例として挙げられているのは、紛失したカードの停止と再発行、支払いの確認、サービスに関する依頼の処理です。

調査や人の判断が必要な依頼では、行員に関連情報と、エージェントがそこまでに行った作業の概要が渡されると説明されています。

統制については、発表に次のような説明があります。

• 銀行が、エージェントの使える情報・知識・ツール、実行できる操作、人の承認が必要な場面を決める
• 影響の大きい依頼（原文は consequential request）には、顧客の明示的な確認を求める
• 依頼に関する情報・判断・結果を記録し、監査や事後の検証に役立てる

同社の製品ページも、操作の実行前にアクセス・方針・承認のチェックを適用し、例外を権限のある行員へ回すこと、判断の根拠と確定した結果を保持することを説明しています。

以上は、Backbase が公表している製品の説明です。

MIF が実際の動作や統制の有効性を検証したものではありません。

以下では、この説明を手がかりに、導入前に確かめたい設計上の条件を整理します。

顧客の確認が担えること、担えないこと

顧客が内容を確認して応答する仕組みは、具体的な操作内容への意思表示を得るための、統制の一つになり得ます。

担えるのは、たとえば次の点です。

• 提示した操作内容に対して、顧客が応答したという記録を得る
• 会話の中で曖昧に伝わった依頼を、実行前に具体的な内容へ絞り込む
• 後から「何に対して応答したのか」を確かめる手掛かりにする

一方で、確認への応答だけでは、次の点まで確かめられるわけではありません。

• 応答したのが本人かどうか（本人性は認証の設計で確かめる）
• その操作がその利用者に許されているかどうか（操作権限は認可の設計で確かめる）
• 不正の有無（本人が第三者にだまされたまま送金などを承認する場合もあり、本人の承認だけでは不正を排除できない）
• 顧客が内容を十分に理解したかどうか

ここで、顧客と銀行側の担当者を同じ「人による確認」として一括りにしないことが大切だと私たちは考えます。

顧客は、自分が求める操作内容を確認する立場です。

一方、銀行側では、操作権限や不正の兆候、実行条件をシステムや担当者が確認し、人の判断が必要な例外を行員が扱います。

MIF は、顧客に何を確認してもらうかと、銀行側で何を検査・判断するかを分け、その結果を実際の操作に結び付ける設計を重視しています。

顧客が確認済みでも、銀行側の実行条件を満たしているかは、別に確かめます。

確認を実際の操作に結び付ける条件

以下は、同種の仕組みを導入・設計する際の確認事項として、MIF が提案するものです。

提示する内容を、検証済みの操作データから作る

「実行してよろしいですか」という文言だけでは、何を実行するのかが十分に伝わらない場合があります。

対象のカード、操作内容（一時ロックか、紛失による停止と再発行か）、解除の可否、費用、所要日数などを、実行前に具体的に示します。

会話の要約だけから確認文を作ると、対象や金額などの重要な内容が抜けたり、元の依頼とずれたりするおそれがあります。

そのため MIF は、銀行側で検証した操作データに基づいて、表示・読み上げ内容を組み立てることを勧めます。

顧客の応答を、その操作内容と結び付ける

確認時に正しい内容が提示されることと、その内容どおりの操作だけが実行されることは、別の問題です。

顧客の応答を提示した操作内容と結び付け、実行時には、顧客が実行を認めていることと、実行内容が確認時の内容に一致していることを確かめます。

対象カード、届け先、金額などの重要な内容が変わった場合は、以前の確認をそのまま使わず、改めて確認します。

確認対象に含まれていない操作へ応答を流用できないことや、再試行で同じ処理が二重に実行されないことも確認します。

操作の影響と不正リスクに応じて、確認方法を決める

どの操作にどの確認方法を求めるかは、取り消しやすさだけでは決まりません。

操作の影響、扱う情報、不正の可能性、訂正のしやすさを踏まえて決める必要があります。

たとえば、カードを一時的にロックする操作と、紛失届に伴う停止・再発行とは区別して扱います。

解除できるか、旧カードがどう扱われるかは、対象となるサービスの仕様で確かめます。

確認の回数を減らすこと自体を目的にせず、必要な確認を残しながら、重複した確認や分かりにくい表示を整理します。

同じ確認が繰り返されると、内容を十分に読まずに進められる可能性もあるため、実際の利用状況を見て確かめる項目にしておくとよいと考えます。

応答に応じて、実行・再確認・引き継ぎを分ける

顧客が「はい」と言わない場面にも、いくつかの種類があります。

明確な拒否があれば、実行しません。

内容の訂正であれば、操作案を更新して改めて確認します。

応答が曖昧な場合は実行を保留し、内容を聞き直します。

会話だけでは解消できない場合や、銀行の定める例外条件に該当する場合は、行員へ引き継ぎます。

発表は、人の判断が必要な依頼で、関連情報と作業の概要が行員に渡されると説明しています。

引き継ぎを発動する具体的な判定条件は、導入前に確かめる点です。

また、通常の利用状況から外れる依頼が、すべて拒否すべき依頼とは限りません。

異常の兆候がある場合は、追加の確認、保留、行員への引き継ぎなど、銀行が定めた対応へつなげます。

記録は何を、どう残すか

発表は、依頼に関する情報・判断・結果を記録し、監査や事後の検証に役立てると説明しています。

一方、どの項目を、どの粒度で、どれだけの期間残すかは、確認した範囲の発表本文には書かれていません。

顧客への提示内容、応答、銀行側の判断、実行結果を、同じ依頼の記録として対応づけます。

表示・読み上げた内容、確認文のテンプレートの版、操作データなど、顧客が何に対して応答したかを後から確認できる情報を管理します。

ただし、会話や画面を無条件にすべて保存する方針にはしません。

パスワードや再利用できる認証情報はログに含めず、個人情報は事後の検証に必要な範囲に限定します。

詳細な情報を証跡として保存する場合は、適用される法令・規制と各行の方針を踏まえ、保存先、閲覧権限、保持期間、改変防止、削除方法を決めます。

記録を残すことだけで、統制が有効であることが示されるわけではありません。

拒否された操作が実行されていないか、内容が変わった後に古い確認が使われていないか、再試行で二重に実行されていないかを、記録と実際の動作の両方で確かめます。

操作ごとの設計例

次の表は、カード関連の手続きなどを例に、顧客に提示する内容と銀行側で確認する事項を整理した MIF の設計例です。

Backbase の設定項目や、各国共通の認証要件を示すものではありません。

すべての行で必要な認証と権限確認を前提とし、追加認証や行員確認の条件は、対象取引と各行の要件に合わせて具体化してください。

操作の例	顧客に提示する内容	銀行側であわせて確認すること	設定・運用先の例
カードの一時ロック（提供される場合）	対象カード、停止の範囲、解除の可否と方法	依頼者が対象カードを操作する権限を持つか、現在のカードの状態、誤って停止した場合の影響	対話画面、認証・認可、カード管理機能
紛失カードの停止・再発行	対象カード、届け先、旧カードの扱い、費用・所要期間	再発行の条件、届け先変更の有無、不正の兆候、必要な追加確認	承認フロー、カード管理機能、行員対応
登録住所・連絡先の変更	変更する項目と内容、変更後の通知・認証への影響	現在の認証状態、既存の確認経路、銀行の定める変更条件	顧客情報管理、認証基盤、変更管理の手順
送金	出金口座、金額、受取先、手数料、実行時期	操作権限、限度額、不正の兆候、必要な追加認証・承認	取引の認可、送金機能、不正検知、例外対応

最後の列は、各条件を、対話製品、認証・認可の基盤、接続先のシステム、社内の手順のどこで実現するかを対応づけるためのものです。

一つの条件を複数の仕組みで実現する場合も、誰が設定し、どこで検査されるかを明確にしておきます。

表を埋めるときは、どこで検査されるのか答えられない欄が、導入前に確かめるべき点を示してくれることがあります。

導入前に追加で確認すること

次の点は、導入前に確かめておきたい事項です。

• 影響の大きい依頼の定義と、確認が求められる操作の一覧
• 確認内容の提示方法（表示・読み上げの文言、再確認の要否）
• 記録の詳細項目、保持期間、閲覧権限
• 行員への引き継ぎを発動する具体的な判定条件と設定方法

これらの詳細は、今回参照した発表と製品ページでは確認できませんでした。

機能がないという意味ではなく、導入前に製品資料や契約上の仕様で確認する事項です。

まとめ

顧客の明示確認は、提示した操作内容への意思表示を得るための統制として活用できます。

ただし、利用者の認証、操作権限、不正の兆候、銀行側の承認条件を確認する仕組みの代わりにはなりません。

MIF は、顧客に提示した内容、確認への応答、銀行側の判断、実際に実行した操作を対応づけることを重視しています。

重要な内容が変わった場合は改めて確認し、拒否や曖昧な応答を、そのまま実行の許可として扱わないようにします。

記録は後から対応関係を検証できる形で残し、個人情報や認証情報の保護もあわせて設計します。

導入前に、操作ごとに必要な確認と銀行側の検査を整理し、その条件が実際の設定・処理・記録に反映されているかを確かめます。

情報確認について

本記事は2026年10月30日確認時点で、次の情報源に基づいて作成しています。

• Backbase 社のプレスリリース「Backbase launches Conversational Banking to turn customer conversations into governed banking action」（2026年10月8日付）
• Backbase 社の製品ページ「Conversational Banking」

記事中の製品の機能・統制の説明は、同社の公表資料に記載された説明であり、MIF が独自に検証したものではありません。

操作ごとの設計例、確認と実行の対応づけ、記録・検証の方法は、公表資料を踏まえた MIF の設計上の提案です。

製品の提供状況・仕様は変更される可能性があります。

導入を検討する場合は、提供元の最新の公式情報と契約上の仕様をご確認ください。