発行日：2024年9月
ISO 20022の採用拡大とAPIへの需要増加は、金融業界における多くのイノベーションにつながっている。しかし、ISO 20022の豊富なデータ標準は、APIで事実上のデータ形式として使用されているJSONが推奨するシンプルさとミニマリズムと衝突する可能性がある。この問題は、業界がISO 20022がもたらすメリットを実現する上で、障害となる可能性を秘めている。
この記事では、JSONの柔軟性とシンプルさをISO 20022のデータ豊富さと両立させようとする際に、開発者や業界が直面する課題を探ります。また、この重要な問題に対処するために現在行われている取り組みについても見ていきます。
ISO 20022は、金融機関間のデータ交換に関する国際標準であり、決済、外国為替、カード、貿易金融、証券といった分野を網羅している。この規格は、内容が豊富で構造化されており、柔軟性にも優れているため、従来の国際標準であるISO 15022（SWIFTのMTフォーマット）やISO 8583（カード決済や口座間決済に使用される）から大きく進歩している。
ISO 20022の普及を推進するために、業界全体で協調的な取り組みが行われてきました。なぜなら、全員がISO 20022を使用することで、そのメリットが最も明確になるからです。この変化のペースは、より多くの取り組みが切り替えを行ったことで加速しており、世界中の多くの自動決済機関（ACH）が、高額および低額の支払い、そしてSWIFTの国際送金システムにおいて、新しいフォーマットを使用するようになっている。ISO 20022の使用はまだ広く普及しておらず、特に大量決済においては、一部のシステムが従来型のフォーマットをサポートしている。しかし、ローカルのリアルタイム決済システムでは、ISO 20022の使用は広く普及している。
ISO 20022 の適用範囲は情報の交換に焦点を当てていますが、主な利点は、組織がデータ ディクショナリ (新しいタブで開きます)を使用して内部データ モデルをサポートすること、つまり共通言語を採用することにあります。これは例えば、当事者が国境を越えた取引における債務者である場合でも、口座切り替え申請における口座所有者である場合でも、当事者を構成する属性（氏名、住所、生年月日、出生地など）が一貫していることを意味します。
ISO 20022 は標準としてフォーマットに依存しませんが、特定のメッセージ スキーマは公式には XSD (XML スキーマ定義) としてのみ公開され、メッセージのカタログ (新しいタブで開きます) から入手できます。このため、XML は ISO 20022 メッセージの交換に最も広く使用されているフォーマットとなっています。
ISO 20022の利用が増加するにつれて、新たなユースケースやデータ交換の新たな方法に対する需要も高まっており、その代表的な例として、金融機関が口座情報へのAccess、支払いの開始、オープンバンキング、内部システム統合など、数多くのアプリケーションで利用しているAPIが挙げられる。
API開発者、特にREST APIを設計する際には、効率性を優先し、特定の要求と応答に必要な基本的なデータのみを送信するという、ミニマリスト的なアプローチを取ることが多い。APIを介してやり取りされる情報は通常、JSON（JavaScript Object Notation）形式で送信されます。JSONはXMLに似ていますが、若干の互換性の相違があります。
ISO 20022ではJSONスキーマが公開されておらず、この形式でどのように表現するかについての共通のルールも現在存在しないため、この標準を使用しようとするAPI開発者にとって課題となる可能性があります。
ISO 20022は、金融メッセージングのグローバルなユースケースをサポートしており、各メッセージには多くの要素が含まれることを意味します。例えば、クレジット送金のような特定のビジネスメッセージのやり取りを実行するために必要な主要要素（債務者名、債権者名、金額、通貨など）はほぼ一貫しているものの、これらの要素の使用方法にはばらつきがある。例えば、ドイツの現地決済機関では、債務者代理人（債務者の銀行）はBIC（ビジネス識別コード）またはBankleitzahl（BLZ - IBANから派生）を使用して定義されますが、オーストラリアではBSB番号（銀行州支店番号）を使用して識別されます。
これに対応するため、ISO 20022メッセージはどちらか一方を提供できるような構造になっていますが、この柔軟性によって、特定のユースケースで厳密に必要とされるよりも大きなメッセージになってしまうという問題があります。
開発者がAPIを設計する際、ミニマリズムを重視し、多くの場合、使用事例に特有の要素のみを含めます。たとえば、英国の場合、すべてのエージェントはソートコードで識別されるため、BSB番号を含める理由はほとんどありません。同様に、エージェントがソートコードでしか識別できない場合、要素名を変更できるのに、なぜISO 20022メッセージの構造の一部を含める必要があるのでしょうか。次の例はこの点を明確に示しています。
XMLベースのISO 20022インスタンスでは、英国のソートコードと口座番号は次のように表示されます。
</CdtrAcct>
<CdtrAgt>
<FinInstnId>
<ClrSysMmbId>
<ClrSysId>
<Cd>GBDSC</Cd>
</ClrSysId>
<MmbId>080800</MmbId>
</ClrSysMmbId>
</FinInstnId>
</CdtrAgt>
<CdtrAcct>
<Id>
<Othr>
<Id>21325698</Id>
</Othr>
</Id>
</CdtrAcct>
コード「GBDSC」は、メンバーIDが「英国国内ソートコード」であることを定義し、Id/Other/Idには口座番号が含まれます。
比較すると、同じデータが英国のオープンバンキングAPIを介して送信される場合、次のようになります。これは「利用可能な場合はISO 20022メッセージ要素とコンポーネントを使用して設計されています」3。サイズが小さいだけでなく、要素名、コード、構造も変更されていることに注意してください。
「債権者アカウント」：{
"スキーム名": "UK.OBIE.ソートコードアカウント番号",
「識別番号」: 「08080021325698」
}
この問題は英国のオープンバンキングに限ったことではなく、業界全体で発生しており、ISO 20022に基づいたAPIが、ベストプラクティスに関する明確なガイドラインや公式のJSONスキーマが公開されないまま実装されている。アプローチが断片化するリスクは高く、実装間の互換性の問題が生じ、標準化が意図していたメリットの一部が実現されない可能性がある。業界はこのリスクを認識しており、ISO 20022はそれを軽減するためのいくつかの措置を講じている。
金融業界が進化を続ける中で、継続的な標準化と相互運用性は極めて重要である。JSONベースのメッセージングの採用はイノベーションを促進する重要な要素であるが、同時に業界が認識しておくべき潜在的な落とし穴も存在する。さもなければ、これまで積み重ねてきた多くの困難な取り組みを無駄にしてしまう危険性がある。
Mastercardはこれらの取り組みに積極的に関与しており、今後も業界と協力して、将来のイノベーションに不可欠な標準化と相互運用性を維持しながら、新しいフォーマットの導入を可能にする枠組みの構築を推進していきます。
