ISO 20022アドレスコンプライアンス：銀行が2026年11月に向けて実際に計画していること

ISO 20022のアドレス管理に関する前2回の記事では、2026年11月の期限に向けた変更内容と、あるグローバル企業がISO 20022移行から得た実践的な教訓についてお伝えしました。そこから浮かび上がったのは明確な現実でした。データの欠陥は実在し、スケジュールはタイトで、組織的な複雑さは常に過小評価されているということです。

しかし、その議論に欠けていた声がありました。銀行自身の声です。

非構造化アドレスや不完全なアドレスを含む支払いが届いた場合、銀行は実際にどう対応するつもりなのでしょうか。拒否するのか、修正するのか、それとも通過させるのでしょうか。MT101やAFB320などのレガシーフォーマットはどのように扱われるのでしょうか。そして、ルールはどこでも同じなのか、それとも銀行や決済コリドーによって異なるのでしょうか。

こうした疑問を解明するため、当社が緊密に連携している銀行グループ*に対してアンケートを実施しました。回答結果は全体的な方向性を確認するものでしたが、同時に、2026年11月を前にすべての財務チームが理解しておくべき重大な運用上の相違点も明らかになりました。

主要な知見：貴社のデータ、貴社の責任

最も重要な知見から始めましょう。

銀行は、無効なアドレスを含む支払いは拒否されるという点で広く一致しています。基本原則は明確です。支払いメッセージにアドレスが含まれている場合、そのアドレスは有効でなければなりません。新しい構造要件を満たさないアドレスの包含は、ほとんどの銀行の解釈において、処理をブロックする問題です。

この知見が重要な理由は、財務チームの間に広く存在する思い込みにあります。銀行がセーフティネットとして機能し、問題が発生する前に不正確なデータを検出・修正してくれるという思い込みです。特定のシナリオではこの前提にある程度の根拠があります。しかし、一般的な運用原則としては危険です。

詳細の中に鍵があり、その詳細は大きく異なります。

非コンプライアンスの水準は依然として深刻に高い

非準拠アドレスへの銀行の対応を分析する前に、現状を整理しておく必要があります。

調査対象の銀行2行は、現在受信しているアドレスの約60%が無効または非準拠であると報告しています。1行はより広範な市場データに言及しており、SWIFTネットワーク上で観測されたISO 20022アドレスのほぼ半数が依然として非構造化状態であることを示しています。2026年春時点で、一部市場における債務者アドレスは約46%、債権者アドレスは約**48%が非構造化です。これは当社独自データとも一致しており、当社が処理するISO 20022 XMLトランザクションの79%**に少なくとも1つの無効なアドレスが含まれています。

銀行はこの状況を認識しています。コミュニケーションも行っています。しかし、認識が期限の要請するスケールの対応策に結びついていません。ある銀行が際立った問題を指摘しました。銀行はすべて、顧客からのフィードバックの少なさを懸念しているのです。ほとんどの企業財務チームはまだ準備完了を確認しておらず、多くは連絡に対して返答すらしていません。

2026年11月の期限についての銀行からの連絡を受け取りながら、まだ行動していない場合、あなたは多数派の側にいます。それは安心できることではありません。

銀行はコミュニケーションを取っているが、一様ではない

調査したすべての銀行が、新しいアドレス要件についての顧客向けコミュニケーションを開始したことを確認しています。使用されているチャネルは概ね共通しています。ニュースレター、案内書簡、専用ウェブページ、実用ガイド、ウェビナー、主要顧客への個別アウトリーチなどです。

しかし、その強度は異なります。すべての顧客に資料を提供するが差別化されたエンゲージメントは行わない、というアプローチをとる銀行もあります。高取引量のクライアントや戦略的に重要なクライアントに向けたより具体的な対応を計画している銀行もあります。期限が近づくにつれ、2026年後半に直接コンタクトやリマインダーを通じてコミュニケーションを強化する予定の銀行も複数あります。

しかし、こうした一般的なコミュニケーションはシグナルであり、行動計画ではありません。自社の特定のコリドーや支払いフォーマットについて十分に具体的な行動指針を銀行から主体的に受け取れないことも十分あり得ます。 貴行が自社の特定のコリドーや支払いフォーマットで何を受け入れ、何を受け入れないかについて、自ら直接対話を始める必要があります。

支払い拒否について：原則は共有されているが、範囲は異なる

銀行は、無効なアドレスが支払い拒否につながるという点で一致しています。意見が分かれるのは、どのアドレスが、どの当事者について、どのような状況で対象となるかという点です。

比較的限定的なアプローチをとる銀行もあります。拒否は主として、債権者、最終債権者、最終債務者のアドレスに適用されます。債務者については、通常は銀行自身の顧客であるため、内部の顧客参照データベースから準拠したアドレスデータを補完できる場合があります。

より広い立場をとる銀行もあります。支払いメッセージ内のいかなる当事者のアドレスも、準拠していなければならない。銀行が保有していないサードパーティデータの補完メカニズムは存在しない、という立場です。

この違いは実務上きわめて重要です。債務者アドレスが非準拠であっても、銀行が貴社のデータを保有して補完できれば、その要素での拒否を回避できる可能性があります。しかし、債権者アドレスに都市名が欠けている場合、どの銀行もそれを補完することはできません。受取人のデータは銀行には存在しないのです。

最も安全な前提は、すべての支払いメッセージのすべてのアドレスを、支払いがシステムを出る前に正確にする責任が貴社にあるとみなすことです。

国のみのエージェントアドレスについて：見過ごされがちな特定のリスク

アンケートのある設問が、多くの財務チームが深く考えてこなかった相違点を明らかにしました。

代理銀行（エージェント）の郵便アドレスに都市名がなく、Country（国）タグのみが含まれている支払いメッセージを考えてみてください。このパターンはレガシーデータでよく見られます。

調査した銀行のうち3行は、このシナリオを拒否ケースと見なしています。 その解釈によれば、アドレスが提供されていて都市名を含む構造要件を満たしていない場合、そのアドレスが任意項目であるかどうかにかかわらず、検証を通過しません。

より文脈的な見方をする銀行もあります。エージェントがBICによって識別される場合、国のみのアドレスは支払いをブロックしない可能性があります。しかし、エージェントがBICではなくルーティングコードやクリアリングコードで識別される場合は、少なくとも都市名と国を含む名称とアドレスが必要となり、国のみの記載では不十分です。

これは微妙ですが重要な区別です。 同じフィールドの同じデータが、エージェントの識別方法によって、ある銀行では受け入れられ、別の銀行では拒否されることがあり得るということです。支払いテンプレートでBICなしのエージェントアドレスを使用している場合、このポイントをチェックリストに明示的に加えてください。

レガシーフォーマットについて：その存続に関する엇갈리는 混在したシグナル

MT101またはAFB/CFONB 320フォーマットで依然として業務を行っている財務チームにとって、2026年11月以降に何が起こるかという問いは重大です。この点に関する銀行の回答は、調査全体で最も分かれたものとなっています。

SWIFT MT101については、全体的な方向性は継続受け入れに対して慎重ながらも好意的ですが、提供されるアドレスが必要な要素、特に都市名と国を曖昧さなく抽出できるよう構造化されていることが条件です。複数の銀行は、アドレスをレガシーの自由入力フィールドではなく、フォーマットF（構造化タグ形式）で提供する必要があると明記しています。

フランスのAFB/CFONB 320については、状況はあまり楽観的ではありません。期待されるルールに従ってアドレスが事前にフォーマットされていれば、このフォーマットを引き続き受け入れる予定の銀行もあります。一方で、AFB320のアドレス対応バージョンは実際にはほとんど実装されていないとして、11月より前にXMLへの移行を積極的に推進している銀行もあります。つまり、フォーマットは理論上存在するが、構造化アドレス機能は運用上確立されていないということです。

次回の記事では、各支払いフォーマットへの構造化アドレス移行の影響を詳しく取り上げます。

すべてのコントロールが同等ではない

技術的なコンプライアンス業務を担う財務チームのために、もう1つの相違点を強調しておきます。

ほとんどの銀行は、コントロールが必要なタグの存在に主眼を置くことを確認しています。TownNameとCountryがメッセージに存在していれば、その値が地理的に意味をなすかどうかにかかわらず、検証は通過します。

一方、存在とコンテンツの両方を検証する予定の銀行は少数です。銀行のシステムは、都市名が実在する地名かどうか、国コードが有効かどうか、組み合わせが一貫しているかどうかをチェックします。

これは些細な技術的区別のように聞こえますが、実際には大きな意味を持ちます。同じタグを持つ支払いでも、存在チェックは通過するがコンテンツチェックには失敗するケースがあり得ます。都市名フィールドに郵便番号が入力されている支払いが、ある銀行では通過し、別の銀行では拒否されることもあります。

移行戦略において、必須フィールドにプレースホルダー値を入力することに依存している場合は、このアプローチが普遍的に機能しない可能性があることを認識してください。コンテンツ検証を実施する銀行は、技術的には存在するが意味のないデータでは満足しません。

普遍的な標準は存在しない

最後に、そしておそらくグローバルな財務業務にとって最も重要な点として、銀行が実装するコントロールが常に均一に適用されるわけではないことを強調します。

コントロールは汎用的であり、すべての支払いタイプとコリドーに一貫したルールが適用されると確認した銀行もあります。一方、要件が国、通貨、支払いタイプ、または送受信国の組み合わせによって異なると示した銀行もあります。

顧客インタビューから得た教訓に関する前回の記事で、この相違の具体的な例を確認しました。複数のアジア諸国では、ISO標準のTownNameは地区に対応し、市区名自体はCountrySubDivisionに格納されます。そのため、グローバル最低要件を超えて、これらのコリドーでは両フィールドが必須となります。

コリドー固有のルールを適用する銀行には、同様の地域的差異が存在します。欧州コリドーで貴行のコントロールを通過する支払いが、アジアやラテンアメリカのコリドーでは通過しない可能性があります。グローバル展開前に低リスクのコリドー1つでテストすることは、単に良い実践であるにとどまらず、本番稼働時の支払い障害を引き起こす前にこうした差異を洗い出す唯一の方法です。

このことが行動計画に意味すること

調査の知見は2026年11月の期限を変えるものではありません。しかし、「準拠」が実際に何を意味するかをより明確にします。

全体像は、自社の顧客基盤全体で観察している内容と一致しています。方向性は明確で、期限は確固として変わらず、業界全体の準備水準はまだ必要なレベルに達していません。

銀行は、構造化アドレスが不可欠な運用要件になりつつあるという点で一致しています。積極的にコミュニケーションを行い、拒否コントロールを計画しています。しかし、その実装は企業にとって重要な点で異なります。

以下に重要な結論をまとめます。

1. アドレスの補完を銀行に依存しないでください。 銀行は特定のシナリオで自行顧客のデータを代替できますが、受取人データを修正することはできません。それは貴社のデータであり、貴社の責任です。

2. 関連する各コリドーで各銀行パートナーとテストを行ってください。 銀行がコリドー固有のルールを適用したり、存在だけでなくコンテンツを検証する場合、汎用的なコンプライアンスでは不十分です。

3. レガシーフォーマットの受け入れについて、銀行に直接確認してください。 MT101やAFB320がそのまま機能し続けると仮定しないでください。何が受け入れ可能か、どのアドレス構造レベルで、いつまでかについて書面での確認を取得してください。

4. プレースホルダー値を避けてください。 データ品質の修正において都市名フィールドを「N/A」などで埋める場合、このアプローチが各銀行のコントロールを通過するかどうかを確認してください。受け入れる銀行もあれば、受け入れない銀行もあります。

5. 存在コントロールが時間とともに厳格化されるという前提で行動してください。 今日すでにコンテンツ検証を実施している銀行は先を進んでいます。他の銀行も追随するでしょう。今クリーンなデータを構築することで、後に再び対応する必要を回避できます。

今後の予定

EDI 820、MT101、AFB320、DATZVやCBIなどの国内標準を含む支払いフォーマットへの構造化アドレス移行の影響についての質問を、最近多くいただいています。次回の記事では、各フォーマットで何が変わり、何が変わらないか、そしてKyribaのフォーマットパラメータがどのように変換を処理するかについて詳しく解説します。

特定の移行についてご質問がある場合は、ご連絡ください。差異を発見するのは11月より前であるべきです。事後では遅すぎます。私たちはお客様をサポートするためにここにいます。

*本記事は、2026年11月のISO 20022アドレス義務化に備えて、銀行パネルに送付したアンケートへの回答に基づいています。個々の銀行の立場は集計・匿名化されています。