2024年12月19日 21時00分ソフトウェア

クレジットカードを使う時にアクワイアラーとイシュアーの間で通信されるメッセージの標準規格「ISO 8583」の仕組みとは？

by frankieleon

お店でクレジットカードを使って買い物をする場合、その店舗の決済端末からの情報はまず加盟店契約会社(アクワイアラー)に送られ、そこからカードのネットワークを通じてカード発行会社(イシュアー)に転送され、承認・否認の判断が行われます。ISO 8583は、主要なカードネットワークにおいて、アクワイアラーとイシュアーの間で交換されるリアルタイムメッセージの標準規格です。

ISO 8583: The language of credit cards — Increase
https://increase.com/articles/iso-8583-the-language-of-credit-cards

私たちが日常的に行うカード取引、例えば店頭でのタッチ決済やオンラインショッピングでの「購入」ボタンのクリックは、加盟店のアクワイアリングプロセッサー、カードネットワーク、そして利用者の取引銀行のイシュアープロセッサーの間で「メッセージ」としてやり取りされます。このメッセージは、共有された仕様を持つ当事者間でのみ送受信が可能です。

ISO 8583では、メッセージは基本的に「メッセージタイプインジケータ(MTI)」「ビットマップ」「データエレメント」という3つの要素で構成されています。

MTIは、メッセージがどのような種類のものかを示す4桁の数値で、受信者がメッセージ内にどのフィールドが存在するか、あるいは存在しないかを予測するために使用されます。

ビットマップは、メッセージ内のどのフィールドが存在し、どのフィールドが省略されているかを示すマップです。各ビットが1であればそのフィールドが存在し、0であれば存在しないことを示します。このビットマップにより、受信者は可変長のメッセージを正確に解析することができます。

データエレメントは、フィールド2にカード番号、フィールド3にプロセシングコード、フィールド4に取引金額というように、実際のフィールド値が順番に並びます。各フィールドは固定長または可変長で、ビットマップで示された順序で配置されます。

このメッセージに含まれるフィールドや、フィールドを構成するサブフィールドの表現方法は「テーブル形式」「ネストビットマップメッセージ形式」「TLV(Tag-length Value)形式」の3つが存在します。

テーブル形式は最もシンプルな形式です。例えば、以下はカード利用店舗名や住所を示すフィールド43の図で、40バイトで構成されます。40バイトのうち最初の25バイトがカードを利用した場所の位置情報、13バイトが都市名、2バイトが国名といったサブフィールドで構成されます。

以下は追加金額を示すフィールド54の構造を示した図。フィールド54には20バイトの固定長サブフィールドを最大3つまで含むことができ、それぞれのサブフィールドは口座タイプ(紺)・金額タイプ(青)・通貨コード(緑)・金額符号(黄)・金額(ピンク)に分かれています。この追加金額のフィールド54には、1つの取引に関連する複数の金額を格納できます。

テーブル方式は各フィールドが固定長で、値がない場合はデフォルト値やプレースホルダーで埋められます。そのため、フィールドが空であっても固定長分のスペースが必要となり、非効率的です。そこで、必要な要素だけを含めてフィールドを可変長とする「テレスコーピング」が採用されました。

フィールド43をテレスコーピングで記述した場合の図が以下。一番上は位置情報のみで25バイト長、2番目は位置情報と都市名のみで38バイト長、3番目は位置情報と都市名と国名で40バイト長となっています。また、フィールドの先頭には長さを示すインジケータ(緑)が配置されています。

ただし、テレスコーピングは後続の要素をすべて省略する仕組みとなっており、要素の順番が固定となっているほか、中間の要素だけを省略することができません。そのため、データを効率的に送信することは可能ですが、構造としては柔軟ではありません。

ISO 8583では、固定長のフィールドと可変長のフィールドを組み合わせることもできます。例えば、以下の図はメッセージの長さを表わしており、フィールド1・フィールド2が固定長で、フィールド3が可変長になっています。また、メッセージの先頭にはインジケーターがついています。

さらに、データの効率化に使われる形式として「ニブルテーブル」があります。ニブルとは半バイト＝4ビットのことで、1バイトには2つのニブルが含まれます。

通常、数値は1バイト＝8ビットを使って格納されます。しかし、多くの項目が1桁の数値で表せる場合、1バイト丸々を使うのは非効率的です。ニブルテーブルでは、各項目の値を1ニブルずつに格納していきます。つまり、1バイトの前半4ビットに1つの項目、後半4ビットにもう1つの項目を格納していくというわけです。ニブルテーブルを使うことで、メッセージのデータサイズを半分に抑えることができますが、その分、データのパースが複雑になるというデメリットもあります。

テーブル形式は柔軟さに乏しいものの、シンプルさと効率性のバランスを取れる表現方法といえます。実際に、American Expressのネットワークはテーブル形式を多用しています。

ネストビットマップメッセージ形式は、フィールドの前にもう1つのビットマップを置きます。このビットマップは、どのサブフィールドが存在するかを示す役割を果たします。つまり、メッセージ全体のビットマップがフィールドの存在を示すのと同じように、ネストビットマップメッセージ形式のビットマップは、サブフィールドの存在を示すわけです。

ネストビットマップメッセージ形式の利点は、存在しないサブフィールドを格納する必要がなくなるため、データサイズを節約できることです。また、サブフィールドの有無が明確になるため、空の値と欠けている値の区別がつきやすくなります。さらに、新しいサブフィールドを追加しても、パーサーは無視して処理を続けられるため、下位互換性が保たれます。

ただし、ネストビットマップメッセージ形式の実装は複雑になります。また、ネットワーク間での実装方式の違いも大きく、新しいフィールドの追加は慎重に行われる必要があります。それでも、メッセージの柔軟性と拡張性が格段と向上するため、VISAや中国銀聯(ユニオンペイ)のネットワークではネストビットマップメッセージ形式が採用されています。

TLV形式は、各サブフィールドが「タグ」「長さ」「値」の3つの要素で表現されます。タグはそのサブフィールドの識別子で、通常は数値が使われます。長さはそのサブフィールドの値のバイト数を示します。そして値は、実際のデータが格納されている部分です。

TLV形式の大きな特徴は、フィールドの順序が自由なことです。先頭にあるデータセットタグを見れば、各フィールドが何を表しているかがわかるため、順番通りに並んでいる必要がありません。また、新しいサブフィールドを追加する際、既存のサブフィールドを変更する必要がなく、新しいタグを割り当てるだけで済むため、拡張性に優れているといえます。

TLV形式はMastercardのネットワークで主に使用されています。また、他のカードネットワークも徐々にTLV形式に移行しつつあり、将来のISO 8583はTLV形式が主流になると考えられます。

ISO 8583では複数のメッセージを連続して送信する場合は、メッセージとメッセージの境界を示す「フレーミング」と呼ばれる仕組みが使われています。

ISO 8583メッセージは通常、長期間接続されたTCPソケット上でやりとりされます。そのため、受信側は、TCPのデータストリームの中から、個々のISO 8583メッセージを正しく切り出す必要があります。そこで、「メッセージ長インジケーター」と呼ばれる4バイトの値をメッセージの先頭に配置します。また、VISAなどの一部のカードネットワークでは、メッセージの送信元や配信先などのメタ情報がメッセージ長インジケーターとメッセージ本体の間に挟まれます。

ISO 8583でメッセージのパーサーを実装する際、エラー処理は非常に重要な考慮事項です。特に、加盟店側となるアクワイアラーのプロセッサーにとっては、様々なイシュアーからのメッセージを適切に処理できなければなりません。メッセージのフォーマットが完全に準拠していなくても、可能な限りエラーを適切に処理し、処理を継続することが求められます。

例えば、TLV形式で未実装のタグが現れた場合、それを記録してメッセージ全体の処理を続行します。また、サブフィールドで未知の値やエラーが発生しても、その部分を部分的なエラーとして扱い、次のフィールドの解析に進むことで、他のデータ処理への影響を最小限に抑えます。エラー部分のデータは、再構成時にスペースやゼロで補完し、メッセージの一貫性を保ちます。