IP/IPおよびIPZip送金

IP to IP(IPIP)

IPtoIP送金とは、インターネットプロトコル(IP)アドレスを用いて、コルレス銀行口座間または異なる金融機関やシステム間で、通貨、資産、負債および資本、あるいはそれらに関するデータを移転するプロセスの一部を指します。金融取引においてIPアドレスとは、インターネットに接続された各機器に割り当てられる固有の数値識別子であり、異なるシステム間で情報を送受信するために用いられます。銀行業務におけるIPtoIP送金では、2つのシステムがそれぞれのIPアドレスを用いて直接通信し、金融取引を実行します。情報の完全性と安全性を確保するため、これに加えて特別な認証および承認の手法が用いられます。

ただし、IPアドレス間送金(IP to IP)は、セキュリティ、信頼性、コンプライアンス上の懸念など、さまざまな理由から、銀行業界では一般的ではなく、推奨もされていないことにご留意ください。これらの懸念の背景については、以下の点をご参照ください。

1. セキュリティ:IPアドレス間の直接送金は、SWIFTやACHなどの確立された銀行ネットワークと比べて、安全性が劣る場合があります。これらのネットワークでは、多層的なセキュリティ、暗号化および認証が実装されています。2つのIPアドレス間で直接通信を行うと、ハッキング、フィッシング、中間者攻撃などのセキュリティ上の脅威により、機密情報が漏えいするおそれがあります。
2. 信頼性:IP間送金の利用は、取引の信頼性を保証するものではありません。銀行業界には、IPベースの送金について普遍的に認められた標準やプロトコルが存在しないためです。その結果、取引の処理、追跡および照合に問題が生じる可能性があります。
3. コンプライアンス:銀行および金融機関は、マネー・ローンダリング対策(AML)や顧客確認(KYC)の方針をはじめ、数多くの規制および要件の適用を受けます。IPからIPへの送金はこれらの規制要件に適合しない可能性があり、関係当事者が法的および財務上のリスクにさらされるおそれがあります。

金融機関は、IPアドレス間での直接送金ではなく、SWIFT、RTGS、ACH/インスタント決済などの確立されたネットワークや、ISO 20022などのメッセージング標準を用いて、機関間の安全で信頼性が高く、法令に適合した資金移動を行うことを選好します。

銀行における通信サーバーと元帳・口座サーバーの主な相違点

銀行の情報技術において、サーバーは金融取引の円滑な運用と記録管理を確実にするうえで決定的な役割を果たします。銀行が依拠する主なサーバーには、通信サーバーと元帳・口座サーバーの二種類があります。いずれも不可欠ですが、それぞれ目的が異なり、取り扱うデータの種類も異なります。

通信サーバー

通信サーバーは、銀行および金融機関の間における安全なデータ交換の基盤です。通信サーバーの主な機能と特長は次のとおりです。

1. セキュアなデータ交換:これらのサーバーは安全なデータ交換を可能にし、機微な金融情報を、情報を損なうことなく金融機関間で伝送できるようにします。
2. プロトコルおよび標準:銀行間通信にはSWIFT、SEPA、ACHなどの標準プロトコルを使用し、異なるプラットフォーム間での統一性と信頼性を確保しています。
3. 暗号化と認証:セキュリティを維持するため、通信サーバーには高度な暗号化方式と厳格な認証プロトコルが採用されており、伝送中のデータを保護しております。
4. 取引処理:主として、取引の依頼、メッセージおよび指図を取り扱い、取引に必要な情報を伝達する仲介者としての役割を果たします。
5. 資金移動は行いません。重要な点として、これらのサーバーは資金を移動させたり口座残高を直接更新したりすることはなく、そのような処理に必要な通信を仲介するのみです。

元帳・口座サーバー

一方、勘定系サーバーは、銀行の財務記録の保管を担います。その主な特徴は次のとおりです。

1. 金融記録の維持管理:これらのサーバーは、銀行の中核となる金融記録を保管・維持し、すべての取引が正確に記録されるようにしています。
2. 取引の記録:借方・貸方を含むすべての取引を記録し、現行の口座残高の更新および保管を担当します。
3. 総勘定元帳の管理:元帳サーバーは、銀行の総勘定元帳と個々のお客様の口座を管理し、財務状態の全体像を提供します。
4. データの完全性:これらの記録は正確な財務報告およびコンプライアンスに不可欠であるため、データの一貫性と完全性の確保が必要です。
5. 強固なセキュリティ対策:取り扱うデータの機微性に鑑み、元帳サーバーでは通常、暗号化の多層化や厳格なアクセス管理など、より厳重なセキュリティ対策が講じられております。

通信サーバーは取引を開始し、その実行を円滑にしますが、元帳サーバーは、当行の帳簿上で検証が完了した後に、最終的にそれらの取引を記録し、反映します。

現代の銀行システムでは、これらの機能は統合されていることが多く、安全な行内通信プロトコルが元帳管理システムと連動して機能します。この統合により、銀行の金融システム全体でリアルタイムの更新と整合性が確保され、効率性とセキュリティの双方が高まります。多くの銀行は、セキュリティ、コンプライアンス、拡張性の各要件のバランスをとるため、オンプレミスとクラウドベースのサーバーを併用しています。

資産、負債および持分の実際の移転: 証券の移転は、所有権に関する法的記録を管理する証券集中保管機関(CSD)によって記録されます。貸出金、固定資産その他のポジションは、適用法に基づく譲渡または移転契約により移転します。いずれも、通信プロトコルの対象範囲外です。資産および持分の移転は、銀行の財務諸表にも影響を及ぼし、負債、資産および持分の残高を変動させます。関係する監督当局への財務報告および必要なコンプライアンス上の対応は、プロトコルによるデータ伝送機能の範囲外であり、追加的な財務上および規制上の手続を要します。

要するに、IPIP取引において情報を安全かつ効率的に交換するためにはプロトコルが不可欠ですが、取引の全工程には、通貨・資産・負債・持分の実際の移動、決済、法的記録および財務報告のための追加のシステムが関与し、これにより取引全体が規制上の銀行業務基準に従って実行されることが確保されます。

IP ZIP Transfer

金融機関の支払指図の、ファイル形式による安全な伝送

IP ZIP Transferは、認証済みの機関システム間で、インターネットプロトコルネットワークを介し、構造化された支払指図および関連取引データを直接送信する、安全なファイルベースの方式と理解するのが最も適切です。

用語の使用には、特に正確さが求められます。

IP ZIP伝送は、決済・清算システム、決済網(ペイメントレール)、または金銭的価値を移転するための独立した仕組みではありません。ZIPアーカイブは搬送用のコンテナにすぎず、IP接続は通信経路です。アーカイブに含まれる情報が、指図、データセット、または取引メッセージに該当します。

したがって、次のとおりです。

IP ZIPは、支払情報および指図を伝達するものであり、それ自体で資金を決済するものではありません。

概念的には、ISO 20022のpacs.008(金融機関間の顧客送金(FI-to-FI Customer Credit Transfer))メッセージに適用される区別と同様です。pacs.008は高度に構造化された銀行間の振込指図を伝達できますが、当該メッセージそのものを、中央銀行マネー、民間銀行マネー、またはコルレス口座残高の最終的な移動および決済と混同してはなりません。

同じ原則は、IP経由のZIP伝送にも当てはまります。

2. 安全な取引コンテナとしてのZIPファイル

ZIPコンポーネントは、主にコンテナ化およびパッケージ化の仕組みとして機能いたします。

発信元の金融機関は、取引の構成要素を個別に送信するのではなく、関連するファイルを一つの管理されたパッケージにまとめる場合があります。

二者間で合意された仕様に応じて、当該パッケージには次のものが含まれる場合があります。

• 構造化された支払指図、
• XML形式の支払メッセージ、
• ISO 20022に対応したデータセット。
• JSON形式の取引オブジェクト
• CSVまたは固定長形式の取引記録、
• 独自仕様の銀行間決済ファイル;
• 債務者および債権者に関する情報、
• 送金元および受取人の口座情報。
• 取引識別子。
• 通貨および金額に関する情報、
• ご要望の執行日および受渡日(バリュー・デート)、
• コルレス銀行向けの指図事項、
• 仲介銀行に関する情報、
• 送金情報、
• 決済経路に関する情報、
• コンプライアンス関連書類。
• KYCまたはKYB(法人顧客確認)に関する照会先。
• 資金源に関する情報、
• 取引明細(マニフェスト)、
• 電子署名;
• 暗号ハッシュ値、
• 証書類、
• タイムスタンプ、
• 照合用ファイル、および
• コントロール・トータル(照合用合計値)。

したがって、アーカイブには、主たる支払指図と、当該指図の真正性の確認、検証、処理および照合に必要な付随情報の双方が含まれる場合があります。

圧縮は技術的には付随的なものです。主たる目的は、管理されたパッケージングと伝送にあります。

したがって、ZIPアーカイブは、その中に示された資金が存在すること、利用可能であること、担保等の負担がないこと、または決済済みであることの証拠として扱われるべきではありません。

3. 構造化された支払指図

適切に設計されている場合、IP ZIPパッケージに含まれる支払指図は、従来の構造化された金融メッセージングと類似の機能を果たすことがあります。

例えば、金融機関は、ISO 20022のpacs.008メッセージに通常含まれる情報に対応する項目を含むXML指図を送信することができます。具体的には次の項目などです。

• メッセージ識別情報、
• 作成日時、
• 取引件数、
• 決済情報、
• 指図代理人、
• 被指図銀行。
• 債務者。
• 債務者口座、
• 債務者側代理金融機関;
• 債権者側代理銀行、
• 債権者;
• 受取人(クレディター)口座。
• 指図金額、
• 通貨;
• 手数料負担者
• 支払の識別;
• エンド・ツー・エンドでの識別、および
• 送金関連情報。

重要な点は、データ構造が決済メカニズムを決定するものではないということです。

技術的に有効な支払指図は、受信システムにより受信、認証および受理された場合でも、これに対応する資金決済が未了のままであることがあります。

したがって、

指図の受領 ≠ 資金の受領

指図の認証完了 ≠ 資金の決済完了

ファイルの取込みが正常に完了したこと ≠ 受取人に最終的な資金が入金されたこと

サーバーによる受信確認は決済完了の確認ではありません

この区別は、代替的な資金移転手法に対するIFBの取扱いの基本となるものです。

4. 送信プロトコル

金融機関間のIP ZIP送信は、管理され認証された通信環境においてのみ行われるべきです。

二者間の技術的な取決めに応じて、次のような技術を用いて伝送される場合があります。

SFTP

SSH上のセキュアファイル転送プロトコルは、暗号化された通信経路、サーバー認証および管理されたユーザー認証を提供します。

金融機関との接続においては、通常、パスワードのみによる認証よりも公開鍵認証を優先すべきです。

FTPS

従来型のインフラストラクチャで必要とされる場合、適切な証明書の検証、暗号化基準およびアクセス管理が実施されていることを条件として、FTPをTLSにより保護することができます。

HTTPS / REST API

当該パッケージは、TLSおよび適切なアプリケーションレベルの認証を用いた、認証済みのHTTPSエンドポイントまたはAPIアーキテクチャを通じて送信される場合があります。

相互TLS

より高い保証水準が求められる機関間の接続には、双方のエンドポイントがデジタル証明書を用いて相互に認証を行える相互TLS(mTLS)を利用できます。

これにより、サーバー認証のみを一方向で行う場合と比べて、未認可のエンドポイントに対する保護が実質的に強化されます。

VPN

アプリケーション層での送信が行われる前に、サイト間IPSecまたはこれと同等のVPNにより、関係機関の間に暗号化された専用トンネルを確立する場合があります。

専用プライベート接続

取引量、セキュリティ要件または機関としてのリスクプロファイルに照らして必要と認められる場合には、公衆インターネット経由の伝送を補完し、または代替するものとして、専用線または専用ネットワークによる接続を用いることがあります。

具体的なプロトコルは、運用開始前に二者間で合意する必要があります。

5. エンドポイント認証

受信側の金融機関は、当該通信が、その名義を表示する金融機関から発信されたものであることを確認しなければなりません。

関連する統制には、次のようなものが含まれます。

• 機関向けデジタル証明書、
• SSH公開鍵・秘密鍵のペア。
• 相互TLS証明書
• API認証情報。
• IPアドレスの許可リスト登録、
• VPN認証;
• ハードウェアセキュリティモジュール、
• 必要に応じた証明書ピンニング;
• 多要素による管理者認証。
• 管理されたサービス口座。
• 役割に基づくアクセス制御、ならびに
• 本番環境とテスト環境の分離。

IPアドレスだけでは、機関としての同一性を示す十分な証拠とはなりません。

同様に、エンドポイント、サーバーのログイン情報、APIの認証情報、またはZIPファイルのパスワードを保有していることは、その背後にある資金の所有権を証明するものではありません。

6. 暗号化

守秘義務は、通常、複数の段階で確立されるべきものです。

通信経路の暗号化

通信経路は、TLSやSSHなど、適切に設定された現行のプロトコルにより暗号化されている必要があります。

これにより、伝送中の情報が保護されます。

ペイロードの暗号化

必要に応じ、取引パッケージ自体をさらに暗号化することもできます。

これにより、伝送経路とは独立して金融情報が保護され、ファイルが一時的に保管される場合、中継インフラを経由する場合、アーカイブされる場合、または非同期で処理される場合のリスクを大幅に低減できます。

保存データの暗号化

処理待ちのファイルは、適切なアクセス制限および保存時の暗号化を備えた管理された保管環境内で保護する必要があります。

ただし、暗号化によって確保されるのは機密性です。取引の金融上の有効性を証明するものではありません。

7. 暗号学的完全性

受領側の機関は、送信されたパッケージが作成後に改変されたか否かを判定できる能力も備えていなければなりません。

したがって、パッケージまたはそれを構成する各ファイルについて、暗号ハッシュを生成することができます。

例:

元の取引データ一式
→ 暗号ハッシュを生成
→ データ一式を送信
→ 受信側システムが独自にハッシュを算出
→ 算出したハッシュを、送信されたハッシュまたは署名済みのハッシュと照合

不一致は、受領したパッケージが当初に認証されたパッケージと暗号学的に同一ではないことを示します。

完全性の検証には、実装に適した範囲で、SHA-2またはSHA-3ファミリーに属するアルゴリズムなど、現代の暗号学的ハッシュアルゴリズムを用いることがあります。

8. 電子署名

デジタル署名は、暗号化とは本質的に異なる機能を果たします。

暗号化は守秘義務(機密性)を保護します。

ハッシュ化は、完全性の確保に寄与します。

適切に実装されたデジタル署名は、次の事項の立証に資する場合があります。

1. 真正性 - パッケージは、該当する秘密鍵を用いて署名されています。
2. 完全性 - 署名されたデータがその後改変されていないこと。
3. 説明責任 - 署名は、適用されるPKIおよびガバナンスの枠組みに従い、関連する機関の電子証明書と関連付けることができます。

受取側の金融機関は、取引指図が決済処理に入る前に、署名を対応する信頼できる証明書または公開鍵と照合して検証する必要があります。

秘密署名鍵は適切に保護する必要があり、機関レベルの鍵管理基盤により、また必要に応じてハードウェア・セキュリティ・モジュール(HSM)により保護することが望まれます。

9. リプレイおよび重複に対する保護

金融ファイルの伝送においては、同一の有効な指図が繰り返し送信されることを防ぐ統制が必要です。

したがって、適切に設計されたアーキテクチャには、固有の取引識別子のほか、次のような適切な統制を組み込むべきです。

• 一意のメッセージID;
• 固有の取引ID。
• タイムスタンプ、
• シーケンス番号、
• ファイル識別子;
• 重複メッセージの検知。
• 冪等性管理。
• 処理状況の記録簿、および
• 処理済みの過去の指図との照合。

受取側の金融機関は、合意された運用手順に従い、重複した指図を拒否、隔離または調査する必要があります。

10. ファイルの検証

ファイルの受領に成功した場合は、自動的な決済ではなく、検証を開始する必要があります。

安全な処理環境では、書類一式に対して複数の確認が順次行われる場合があります。

第1段階 – 送信の検証

書類一式が正規の経路を通じて到着したことの確認。

ステージ2 – エンドポイント認証

送信システムおよび機関としての資格情報の確認。

ステージ3 – マルウェア対策およびファイルセキュリティ管理

決済インフラに取り込む前に行う、アーカイブおよびそれを構成するファイルの検査。

第4段階 – 暗号技術による検証

ハッシュ、署名および証明書の検証。

第5段階 – 構造面の検証

ファイルが、合意されたスキーマ、命名規則、文字エンコーディング及びデータ仕様に適合していることの確認。

ステージ6 – 意味的検証

必須の支払項目がすべて存在し、相互に整合していることの確認。

第7段階 – 取引の検証

通貨、金額、口座、ルーティング情報、取引参照番号および決済指示の検証。

第8段階 – コンプライアンス検証

AML、制裁、KYC/KYB、取引モニタリングその他の適用される管理態勢。

第9段階 – 決済の検証

対応する金融価値を決済できる実際の仕組みが存在することの確認。

これらの管理手続がすべて完了した後に初めて、指図は、受取機関に適用される手続に従って執行に移されるものとします。

11. 受領確認は決済完了を意味しません

IP ZIP環境では、複数の技術的な受領確認が生成される場合があります。

例:

ACK – ファイル受領済み

これが示すのは、受信側のエンドポイントがパッケージを取得したという事実のみです。

ACK – ファイルの真正性を確認済み

これにより、認証管理が正常に完了したことが確認されます。

ACK – ファイルの検証完了

これにより、当該パッケージが適用される構造上または技術上の検証要件を満たしていることが確認されます。

ACK – 指図受理

これにより、支払指図が受取金融機関の処理フローに入ったことを確認できる場合があります。

これらの状態は、必ずしも次のことを意味するものではありません。

決済済み

決済には、別個の資金上の事象が必要です。

この区別は、従来の金融メッセージングにおいて、支払メッセージの送達および受理の成功と、その基礎となる金銭債務の最終的な決済とを区別しなければならないことと同様です。

12. 原取引の決済

IP ZIPの支払指図が認証、検証、受理および承認された後は、その基礎となる資金価値を、適切な金融インフラを通じて決済しなければなりません。

関係する通貨、機関および法域に応じて、決済は次のいずれかを通じて行われることがあります。

• コルレス銀行業務、
• ノストロ口座・ボストロ口座。
• 中央銀行口座、
• RTGSインフラ;
• 認定された清算システム、
• 国内の決済システム;
• 即時決済インフラ。
• コルレス決済銀行、または
• 法的および運用上認められた別の決済スキーム。

14. セキュリティの原則

IFBは、あらゆる代替的な資金移動手法について、次の根本的な区別を適用しております。

安全な伝送は、データを安全に送信できることを証明するものにすぎません。資金を決済できることまで証明するものではありません。

• 暗号化は資金の存在を証明するものではありません。
• 電子署名は、資金の存在を証明するものではありません。
• サーバー上の残高表示は、資金の存在を証明するものではありません。
• 取引ファイルは、資金の存在を証明するものではありません。
• ファイルの取り込みが成功したことは、資金の存在を証明するものではありません。
• 技術的な受領確認は、決済が完了したことの証明にはなりません。

決定的な金融上の問いは、あくまで、組成元の金融機関が、認められた銀行インフラを通じて対応する金銭的価値を提供し得る、検証済みの流動性と実行可能な決済経路を有しているかどうかという点にあります。

15. IFBの受入れ枠組み

IFBは、IP ZIP形式による送信について、承認された機関取引先および受け入れ済みのお客様に限り、技術面、法務面およびコンプライアンス面での審査が満足のいく形で完了した後に、検討することがあります。

本番接続を確立する前に、IFBは以下の事項の確認を求める場合があります。

• 発信元の金融機関。
• 取引を送信するための組織上の権限
• 実質的支配者および取引当事者、
• 資金の出所および正当性。
• その基礎にある経済的目的。
• 送受信のためのインフラ、
• エンドポイントの所有関係。
• IPおよびネットワーク構成。
• 認証の方法論。
• 証明書および暗号認証情報。
• 暗号化基準、
• ファイル形式およびスキーマ。
• 支払メッセージの構造
• 取引の特定方法;
• 確認応答プロトコル。
• 重複および再送(リプレイ)に対する統制;
• 例外処理
• 照合手続;
• コルレス関係;
• 決済口座、
• 流動性に関する取決め、および
• 最終的な決済経路。

技術面での相互運用性だけでは十分ではありません。

IFBは、IP ZIPパッケージの送信が正常に完了したことをもって、資金を受領したものとは取り扱いません。取引は、対応する価値が合意された銀行または決済インフラを通じて正常に決済され、かつ当該決済を独立して照合できる場合に限り、財務的に完了したものとみなされます。

基本原則

IP ZIPは、指示の安全な伝送です。決済は、これに対応する金銭的価値の移動です。

両プロセスは同一の取引ワークフローの一部を成す場合がありますが、同一の事象ではございません。

機関投資家向けの銀行業務における用語では、次のとおりです。

メッセージ送信 → 認証 → 検証 → 受理 → 執行 → 決済 → 照合

該当する決済手続が完了して初めて、取引の資金面の履行が完了したものとみなされます。

代替的な送金手法や従来型の送金手法に関連する用語は、銀行インフラの文脈の中で解釈されるべきです。こうした用語は、通信経路、内部処理の方法、あるいは過去の慣行を指すことがありますが、規制対象の金融機関、認定された決済システム、正式な決済手続を要するという要件に取って代わるものではありません。

いかなる送金も、その呼称にかかわらず、最終的には既存の金融システムの中で処理、清算および照合されなければなりません。

当行の口座へ資金または資産を移管する方法についてさらにお知りになりたい場合は、Marie Mayerまでご連絡ください。