要約

  • 2026年10月2日付の draft-skyfire-oauth-aml-methods-01 は、aml クレームに値が入ることを、対応するAMLメソッドの利用が成功した印とする。候補にはOFAC対応、制裁、ウォッチリスト、PEP、ネガティブニュースが並ぶ。
  • 成功したのはメソッドの実行であって、顧客の潔白や取引の許可ではない。提案された値には、ヒットの処分、リストの版、根拠資料、管轄、審査者、最終判断が含まれない。

自動化の完了表示は、判断の完了表示に似ている。両者が同じ画面で緑色になれば、違いはさらに見えにくくなる。

個人提出のInternet-Draft「Anti-Money Laundering Methods Values」改訂01は、その境界を設計者に突きつける。提案はJWTに aml という配列を置き、大文字と小文字を区別する文字列で用いた方法を表す。初期値は ofac、sanc、watch、pep、adv。それぞれOFACコンプライアンス、制裁、ウォッチリスト、重要な公的地位を有する者、ネガティブニュースの確認を指す。

共通語彙には実務上の利点がある。受信側はベンダーごとの不透明なフラグから、どの種類の確認が行われたかを推測しなくてよい。監査ログを同じ言葉で検索でき、取引前に必要な確認群が呼び出されたかを機械的に検査しやすくなる。異なる発行者の機能を比較する入口にもなる。

ただし、改訂01がいう「成功」は慎重に読む必要がある。ソフトウェアの成功は、通常、呼び出しが失敗せず所定の結果を返したことを意味する。コンプライアンス部門が必要とするのは、候補が見つかったか、その候補をどう解決したか、どの法令の下で何を許可したかである。草案は前者の方法表示を提案するが、後者を格納する処分語彙は提案していない。

sanc がJWTにある場面を考える。この四文字だけでは、どの国・地域・国際機関の制度を対象にしたか分からない。リスト発行者、制裁プログラム、取得日時、版、適用法も不明である。照合した氏名、別名、表記揺れ、音訳、識別番号、実質的支配者、相手方も残らない。閾値、候補、誤検知の理由、未解決事項、人手による判断もない。そして、進行、保留、調査、報告、拒絶のどれを選んだかも表さない。

これは語彙提案を全面的なケース管理仕様だと非難する話ではない。むしろ、役割が限定されているからこそ、その限界を受信側の契約と画面に明示する必要がある。方法のラベルを、顧客の評価証明書として再利用してはならない。

OFACの「Framework for Compliance Commitments」は、制裁コンプライアンスを単一の検索結果ではなく、経営陣の関与、リスク評価、内部統制、テストと監査、研修からなるプログラムとして示す。内部統制には、対象の特定、取引の阻止、エスカレーション、報告、記録保存が含まれる。付録が挙げる問題原因には、スクリーニングソフトの欠陥、古いリスト、識別子不足、綴りの差、デューデリジェンス不足、弱いエスカレーションがある。

したがって、メソッドは仕様どおり動作しても、判断は誤り得る。更新前のリストを正しく検索することはできる。音訳候補が入力されなければ、エンジンはエラーなくゼロ件を返す。ベンダーが出した候補を閾値が落とすこともある。技術的な成功は、データと制度の妥当性を保証しない。

時点も不可欠だ。OFAC FAQ 65は、保険契約の発行、更新、変更、請求、支払い、制裁プログラムやリストの変更など、複数の節目で確認する考え方を示し、リストが頻繁に変わると説明する。契約開始時に真だった結果は、後日の支払い時点の答えではない。

FinCENの顧客デューデリジェンスも継続的な関係管理として構成される。柱は、顧客の特定・本人確認、対象法人の実質的支配者の特定・確認、関係の性質と目的を理解したリスクプロファイル、疑わしい取引の継続監視とリスクに応じた情報更新である。統合FAQは、更新を一律の周期ではなく、出来事とリスクに結びつけている。

管轄による役割分担も、一つの値では運べない。欧州委員会の説明では、EUレベルで措置を採択・公表する一方、調査、実施、執行、罰則は加盟国が担い、委員会が監視と指針提供を行う。sanc だけを見ても、どの法令、ライセンス、例外、当局実務を前提にした判断かは分からない。

提案されたIANA登録の審査は、語彙の管理であって合規性の認証ではない。改訂01は aml JWTクレームとAMLメソッド値レジストリを求め、新規値にExpert Review、3週間のメーリングリスト審査、重複回避、一般性、実利用、明確な説明といった基準を置く。これは命名の品質を高めるが、ベンダーを認定せず、データを検査せず、閾値を承認せず、法的判断を代行しない。

提案と現行割当ても区別しなければならない。本稿の資料固定時点では、IANA JWT Claimsレジストリに aml はなく、稼働中のAnti-Money Laundering Methodsレジストリもない。草案中の表は提案された初期内容である。Datatrackerにはstream、intended standards level、standards levelの記載がなく、OAuthの議論の場があることも、作業部会採択やIETFコンセンサスを意味しない。

署名付きJWTであっても、意味の空白は埋まらない。検証により発行者と改ざんの有無は確認できる。しかし、発行者が入れなかったリスト、照合入力、候補、審査、法的理由は復元できない。暗号は記述された主張の完全性を守るのであって、主張の射程を広げるものではない。

利用組織には、メソッド表示とは別のスクリーニング受領書が要る。トークンと語彙の版、発行者、顧客・取引との結合、方法値、ベンダーとポリシーの版、管轄と法的根拠、データセットの版と取得時刻、識別子・別名、閾値・候補、証拠参照、審査者とエスカレーション、誤検知処分、リスク分類、例外、再確認期限、訂正・取消、最終的な自社アクションを残すべきだ。

これは草案や規制当局が指定した必須書式ではなく、BTWによる編集上の統治提案である。目的は、共通メソッドを共通の承認に変質させないことだ。リスト変更、誤検知の異議申立て、実質的支配者の交代、ベンダー移行が起きても、組織が自分の判断を再構成できるようにする。

Heng LuのMinimum Initial Specificationは、最小限の共通語彙とローカルな将来判断を分離する。Running-Code Primacyは、名前ではなく実際に動いたリスト、ルール、識別子、審査経路を見るよう求める。Reality Layersは、登録語、発行者の主張、候補ヒット、審査処分、法的結論、アプリケーション動作を一つの状態に潰さないための枠組みになる。

相互運用に必要なのは、責任の移転ではなく意味の節度である。aml は方法が動いたことを伝えればよい。顧客を通すか、止めるか、報告するかは、根拠と所有者を伴う別の命題として扱うべきだ。

情報源