国際銀行間通信協会（SWIFT）決済網アーキテクチャ

SWIFT（Society for Worldwide Interbank Financial Telecommunication）は、世界中の銀行が他国にある銀行と金融取引を行うために使用するメッセージングシステム。ベルギーに本部があり、SWIFTコードと呼ばれる8～11桁の識別子で送金銀行と受取銀行を識別する。

SWIFTコードは1975年ごろに独自形式として開発されたが、1994年に ISO 9362 として国際標準が定義された。その後さらに2回改訂され、現在使われているのは2014年版。具体的な形式は、エストニアのフィンテック企業 Wise（旧 Transferwise）が提供している以下のページで確認できる。

https://wise.com/gb/swift-codes/bic-swift-code-checker

先頭の4文字は銀行、次の2文字は国、次の2文字は地域、そして最後に任意の3文字の支店コードが付く。たとえば SWIFTコードが SMCOGB2LXXX なら、英国（GB）にある SMCO 銀行の 2L 地域 XXX 支店を指す。基本的には銀行に付与されるものだが、最も需要が大きいのが送金であるだけに、国家間で資金をやり取りする機会の多い多国籍大企業が SWIFTコードを発行して利用するケースも多い。逆に言えば、SWIFT決済網から排除されると金融取引に大きな打撃を受ける。イランや北朝鮮は当然ながら SWIFT へアクセスできない。

この記事は、『System Design Interview』の著者アレックス・シュが説明した SWIFT システムの技術的な構造。

1. 資金をやり取りする当事者である Bank、Bank からのリクエストを受けて処理する Regional Processor（RP）、RP からのリクエストを受けて送金関連の記録を保存する Slice Processor（SP）がある。便宜上、A側の Bank/RP/SP と B側の Bank/RP/SP があるとする。
2. Bank(A) は Bank(B) に送る送金リクエストを RP(A) に送る。RP(A) はリクエストの有効性を検証した後、SP(A) にリクエストを転送する。SP(A) はリクエストを保存した後、RP(A) にはリクエストが処理されたという応答を、RP(B) には送金リクエストを送る。
3. 応答を受け取った RP(A) は Bank A に対して、送金リクエストが受理（ACK）または拒否（NAK）されたという応答を返す。SP(A) からのリクエストを受けた RP(B) はメッセージを一時保存した後、メッセージに固有番号（MON）を発行して SP(B) に渡す。
4. SP(B) は MON の有効性を検証し、認可（authorization）処理を行った後、RP(B) に「Bank B に資金を送れ」というメッセージを送る。
5. RP(B) が Bank B にメッセージを伝達する。Bank B はこれを受け取って保存した後、実際に資金を支払い、成功可否（UAK/UNK）を RP(B) に伝える。
6. RP(B) は送金結果レポートを生成して SP(B) に渡す。SP(B) はこれを保存した後、SP(A) にコピーを渡す。SP(A) はそれを再度保存する。

1975年ごろに作られたシステムだが、現代の Event-driven microservice の要素がすべて入っている。SP はメッセージ形式で送金リクエストと結果レポートを保存し、RP は SP を使って Bank のリクエストに対するサービスを提供する。RP は Bank の送金リクエストを受け取るか、自分が担当する区域に入ってきた送金リクエストを、やはり自分が担当する区域の Bank に依頼する役割だけを担う。結果として、すべての送金関連リクエストは送信側の SP と受信側の SP に、それぞれリクエストと処理結果が1件ずつ保存されることになる。Bank からは SP の存在はまったく見えない。