銀行の継続的顧客管理で顧客から返送された確認書の回答を、登録情報・取引の状況と照らして判定し、追加の確認が要る顧客と理由を担当へ出す

処理の起点を決める

毎朝7時に、前日までに返送された回答のうち点検に回るものを取り出します。 回答は日中に少しずつ届きますが、取引の集計は前日の締めの後のデータで行うので、1日1回にそろえます。

取り出す条件は、今の点検の対象と同じにします。 回答が登録と違うもの、自由記入があるもの、顧客リスク評価が中以上のもの、の3つです。登録から変わりのない低リスクの回答は、これまでどおり機械で完了させます。

点検の期日も、取り出すときに付けます。 金融庁のFAQは、継続的顧客管理において、顧客リスク評価の見直し手続に係る期日管理や期日までに見直しができない顧客の管理が重要であるとしています。回答の受付日から決まった日数で期日を付け、点検画面で期日の近いものを上に並べます。

入力データを集める

質を決めるのは、取引の集計の項目です。 集計の項目が少ないと、回答と照らす数字が無く、ほとんどの回答が「判断できない」になります。 逆に明細をそのまま渡すと、生成AIが数え間違えます。項目を決めて機械で集計することが、この構成の土台です。

取引の集計は、たとえば次の形で渡します。

金額は帯で渡します。 1円単位の金額は判定に要らず、生成AIへ送る情報を減らせます。 帯の区切りはコンプライアンス統括部が決め、すべての顧客で同じにします。

顧客リスク評価が高の顧客には、確認書の項目を足しています。 金融庁のFAQは、高リスク顧客について、通常の確認項目に加えて例えば1年ごとに、資産・収入の状況、資金源、商流等を確認することなどを挙げています。足した項目も同じ形で項目ごとに並べ、高リスクの顧客だけ判定の項目が増えるようにします。

データの取得方法を決める

集計の問い合わせは、コンプライアンス統括部と情報系の担当が一緒に作り、版を付けて管理します。 集計の定義が変わると、同じ回答でも判定が変わります。 どの版の集計で判定したかを、判定の結果と一緒に残します。

前回の点検の結果は、前回の判定の要約だけを渡します。 前回「追加確認の結果、取引の目的は家族からの仕送りと確認」となっていれば、今回も同じ入金元の数を食い違いとして挙げずに済みます。

AIへ渡す前に整形する

1. 記号への置き換え … 氏名を {NAME}、口座番号を {ACCT}、勤務先の名称を {EMP1} に置き換えます
2. 項目の並べ替え … 回答・登録情報・集計を、職業・取引の目的・入金の出どころ・海外送金の4つの項目ごとに並べます
3. 登録との差分の付与 … 回答と登録が違う項目に、機械で「変更あり」の印を付けます
4. 自由記入の分離 … 自由記入は回答の項目と分けて渡し、項目の回答を上書きさせません
5. 集計の欠けの確認 … 集計が取れなかった項目は、空ではなく「集計なし」と明示します
6. 国籍・在留資格の扱い … 回答にあっても、判定の入力からは外します

6番目を軽く見ないでください。 国や地域に係るリスクは、行内の顧客リスク評価の仕組みで、定めた方法で評価済みです。 生成AIに国籍を渡すと、取引と回答に食い違いが無くても、属性だけを理由に追加確認を勧める判定が混ざります。 海外送金の送金先の国は取引の事実なので渡しますが、理由にできるのは回答との食い違いだけにします。

5番目は、「数字が無い」と「数字が0」を分けるためです。 海外送金の集計が取れなかった顧客を0件として渡すと、「海外送金の予定あり」と回答した顧客が食い違いに見えます。

AIに処理させる

させるのは、4つの項目それぞれについて、回答と登録情報と集計を照らし、判定と理由を書くことです。

updated と inconsistent の境目が、この構成でいちばん大事な判断です。 回答が変わったこと自体は理由になりません。変わった回答が集計と合うかどうかで分けます。合うなら更新で済み、合わないなら確認が要ります。

3行目は、金融庁のガイドラインの記述に沿っています。 ガイドラインは、自らが定める適切な顧客管理を実施できないと判断した顧客・取引等について、取引の謝絶を行うこと等を含めリスク遮断を図ることの検討を挙げる一方、マネロン・テロ資金供与対策の名目で合理的な理由なく謝絶等を行わないこととしています。生成AIの判定が謝絶の入口にならないよう、出力の選択肢にそもそも入れません。

指示内容を固定する

あなたは銀行の継続的顧客管理で、顧客から返送された確認書の回答を点検する担当を補助します。
渡すのは、1人の顧客の【回答】【登録情報】【取引の集計】【前回の点検の結果】です。
追加の確認が要るかを決めるのは担当です。あなたは項目ごとの判定と理由を書きます。

【項目】occupation（職業）／purpose（取引の目的）／source（主な入金の出どころ）／
        overseas（海外送金の予定）

【judgment の選び方】
- consistent ..... 回答が登録と同じで、取引の集計とも合う
- updated ........ 回答が登録と違うが、取引の集計と合い、事情の変化として読める
- inconsistent ... 回答と取引の集計が合わない
- insufficient ... 回答が空、または判断に足りない
回答が登録と違うというだけで inconsistent にしないでください。
迷ったときに consistent を選ばないでください。

【厳守事項】
- 理由には、どの回答と、取引の集計のどの数字が合わないのかを、1組ずつ書いてください。
  数字は【取引の集計】に書かれた値をそのまま写してください。計算や推測をしないでください。
- 「集計なし」の項目は、0件として扱わないでください。
- 国籍・氏名・年齢・性別を理由にしないでください。
- 疑わしい取引かどうか、顧客リスク評価を変えるべきか、取引を制限・謝絶すべきかは書かないでください。
- 回答の意図を推測して補わないでください。「生活費」は「生活費」として扱ってください。
- 前回の点検で確認済みの事情があれば、同じ点を inconsistent にせず、その旨を書いてください。
- questions には、営業店が顧客に聞く質問の案を、【質問の一覧】の定型をもとに書いてください。
  顧客を疑っていると受け取られる言い回しは使わないでください。

【回答】{answers}
【登録情報】{profile}
【取引の集計】{aggregates}
【前回の点検の結果】{previous}
【質問の一覧】{question_templates}

「回答が登録と違うというだけで inconsistent にしない」を明記しないと、変更のあった回答がほぼすべて食い違いになります。 第3章の（d）の、更新で済むものまで回る状態がそのまま再現されます。

「迷ったときに consistent を選ばない」は、反対側の失敗を止めるための一文です。 迷うものは insufficient か inconsistent に寄せ、担当の目に入る側に置きます。 見逃しより、担当が読んで戻すほうが安全です。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "customer_ref": "{ID1}",
  "items": [
    {
      "item": "occupation | purpose | source | overseas",
      "judgment": "consistent | updated | inconsistent | insufficient",
      "answer_quote": "",
      "data_points": [ { "field": "", "value": "" } ],
      "reason": ""
    }
  ],
  "previous_context_used": false,
  "questions": [ { "item": "", "text": "" } ]
}

1つ目の理由は、data_points で理由の数字を照合できることです。 field は集計の項目名、value はその値です。中継の処理が集計の実際の値と一致するかを確かめ、合わなければその項目を担当に回します。 生成AIが数字を作った場合、ここで見つかります。

2つ目は、項目ごとの判定を規則で読めることです。 振り分けの規則は、たとえば次のとおりです。

この表はコンプライアンス統括部が決め、版を付けて管理します。 継続的顧客管理の方針が変われば、直すのはこの表だけで、生成AIへの指示は変えません。

3つ目は、questions で営業店に渡す中身がそろうことです。 第3章の（c）の「取引の状況を確認してください」の一言が、項目ごとの具体的な質問に変わります。

構造化出力では、すべてのフィールドを必須にし、additionalProperties: false を設定する必要があります。文字列の pattern などはサポートされないため、data_points の値の形の確認は中継の処理の側で行います。

システムへ連携する

禁じた理由の検出は、中継の処理で機械的に行います。 reason の文に、国籍・在留資格・年齢などの語が含まれていれば、その顧客を担当へ回し、判定には使いません。

人が確認する

追加確認に回すかを決めるのは担当で、読む順番を決めておきます。

1. 照合で引っかかったものを先に見る … 数字が集計と合わないもの、禁じた理由が出たものです。明細を開いて自分で判断します
2. followup の理由を読む … 回答と数字の組に納得できるかを見ます。納得できれば、質問の案を直して営業店へ回します
3. update_only を一覧で確かめる … 更新の内容が回答どおりかを見て、登録情報を更新します
4. 決定を記録する … 回したか、回さなかったか、その理由を一言残します

4番目の「回さなかった理由」が、後から効いてきます。 ガイドラインは、調査の過程での照会や調査結果を適切に管理し、関係する役職員と共有することを求めています。AIが followup としたのに担当が回さなかった記録は、判定の規則を見直す材料になります。

コンプライアンス統括部は、週に1回、no_followup から20件を抜き取ります。 回答と集計を自分で照らし、見逃しが無いかを確かめます。 見逃しが見つかれば、集計の項目か指示のどちらに原因があるかを分けて直します。

例外に対処する

7行目は、金融庁のFAQの考え方に沿っています。 FAQは、1年以上不稼働の口座等の長期不稼働口座について、ほかの顧客とは異なる管理が必要となるものの、定期的な情報更新は不要となるとしています。対象から外す条件は、行内の方針で決めてください。

記録を残す

• 回答・登録情報・取引の集計（記号に置き換えた後のもの）と、集計の版
• 生成AIが返したJSONと、照合の結果
• 振り分けの結果と、そのときの振り分けの規則の版
• 担当の決定（回した／回さなかった）と、その理由
• 営業店へ回した理由と質問、営業店からの確認の結果
• コンプライアンス統括部の抜き取りの結果
• 記号と元の値の対応表（行内にだけ置く）

集計の版と規則の版を残すのは、後から判定を説明するためです。 検査や内部監査で「なぜこの顧客を追加確認に回さなかったのか」と問われたとき、そのときの集計の定義と規則が残っていなければ、説明できません。