← ホームへ戻る

ISO 8583規格カード決済メッセージフォーマットの仕組みと構造

🗓 2026年8月13日

クレジットカードやデビットカードを利用した決済が行われる際、POS端末やATMからカード発行会社(イシュア)へ、瞬時に複雑なデータがやり取りされています。この金融取引における世界標準の通信プロトコルがISO 8583です。本記事では、決済データの構造からメッセージの種類、そしてデータの有無を制御するビットマップの仕組みまでを詳しく解説します。

Key Facts

  • ISO 8583は、カード決済におけるメッセージ交換の国際標準規格である。
  • メッセージは主に「MTI(メッセージタイプ指示子)」と「データ要素」で構成される。
  • MTIの4桁の数字で、規格バージョン、メッセージクラス、機能、送信元を識別する。
  • ビットマップを用いて、どのデータフィールドがメッセージに含まれているかを効率的に管理している。
  • 1987年版、1993年版、2003年版などのバージョンが存在し、時代と共にデータ構造が進化している。

決済メッセージの全体フロー

一般的なカード取引は、POS端末などのアクワイアリングデバイスから開始されます。データはネットワークを経由してカード発行システムへ送られ、口座残高や有効性の確認(オーソリゼーション)が行われます。発行システムは承認または拒否の回答を生成し、あらかじめ決められた制限時間内に端末へ返信します。

送信されるデータには、カード番号や保持者情報、端末番号、加盟店番号、取引金額などが含まれます。また、中継システムによって動的に追加される情報も存在します。

MTI(メッセージタイプ指示子)の構造

MTIとは、メッセージの全体的な役割を定義する4桁の数値フィールドです。各桁が特定の意味を持っており、これによりネットワーク上のルーティングや処理内容が決定されます。

MTIの桁別定義

  • 1桁目(バージョン): 使用されているISO 8583の版を示します(例:0=1987年版、1=1993年版、2=2003年版)。
  • 2桁目(クラス): メッセージのカテゴリーを分類します。承認(1)、財務取引(2)、ファイル操作(3)、リバーサル(4)、照合(5)、管理(6)、手数料(7)、ネットワーク管理(8)などがあります。
  • 3桁目(機能): リクエスト(0)、レスポンス(1)、アドバイス(2)、通知(4)といった通信の目的を示します。
  • 4桁目(送信元): アクワイアラ(0)、イシュア(2)など、誰が通信を開始したかを識別します。

例えば、「0110」というMTIは、1987年版の規格に基づいた、アクワイアラからの承認リクエストに対する「承認レスポンス」であることを意味します。

ビットマップによるデータ管理

ISO 8583では、メッセージ内にどのデータ要素が含まれているかを効率的に示すためにビットマップを使用します。これは、各ビットが特定のデータフィールドに対応しており、「1」であればそのフィールドが存在し、「0」であれば存在しないことを示します。

基本となる「プライマリビットマップ」は1〜64番目の要素を管理します。さらに、プライマリビットマップの最初のビットが「1」の場合、65〜128番目の要素を管理する「セカンダリビットマップ」が存在することを示します。稀に129〜192番目を管理するターシャリビットマップが使用されることもあります。

データ要素の定義と形式

データ要素は、実際の取引情報を運ぶ個別のフィールドです。1987年版では最大128個、後の版では最大192個の要素が定義されています。

データ型の表記法

各フィールドは、そのデータ形式と長さによって以下のように定義されます。

  • 固定長: 例として「n 6」は6桁の数値固定長を意味します。
  • 可変長(LLVAR): 最初の2桁で後続データの長さを指定します(例:a..11)。
  • 可変長(LLLVAR): 最初の3桁で長さを指定します(例:b...999)。

主要なデータ要素(1987年版例)

主要データ要素一覧
フィールド番号 名称 形式 内容
2 PAN n..19 プライマリ口座番号
3 処理コード n 6 取引の種類を識別
4 取引金額 n 12 決済金額
7 伝送日時 n 10 メッセージ送信時刻
11 STAN n 6 システム追跡監査番号
39 レスポンスコード an 2 承認・拒否の結果コード
41 端末ID ans 8 カード受付端末の識別子

レスポンスコードと処理コード

取引の結果は「レスポンスコード」で返されます。1987年版では2桁、1993年版以降では3〜4桁のコードが使用されます。例えば、コード「00」は成功(承認)を意味し、「51」は残高不足(Not sufficient funds)を意味します。

また、「処理コード」によって、その取引が「販売(Sale)」なのか「現金引き出し(Cash)」なのか、あるいは「残高照会(Balance inquiry)」なのかが区別されます。

Frequently Asked Questions

ISO 8583の異なるバージョンで何が変わりましたか?

主にデータ要素の定義や配置が変更されています。例えば、1987年版や1993年版では独立していた通貨要素が、2003年版では金額要素のサブ要素として統合されるなどの変更が行われました。

ビットマップの役割は何ですか?

メッセージに含まれるデータ要素の有無をバイナリ形式で示すインデックスのような役割を果たします。これにより、不要な空フィールドを送信せずに済むため、通信量を削減し効率的なデータ転送が可能になります。

MTIの「0200」と「0210」の違いは何ですか?

「0200」はアクワイアラからイシュアへ送られる財務取引のリクエスト(例:ATMでの出金要求)であり、「0210」はそのリクエストに対するイシュアからの回答(レスポンス)です。

POSエントリーモード(フィールド22)とは何ですか?

カードがどのように読み取られたか(磁気ストライプ、ICチップ、手入力など)や、PIN入力の可否などの端末環境を示す情報です。バージョンによって定義される桁数や詳細度が異なります。

リバーサル(Reversal)メッセージとは何ですか?

以前に行われた承認処理を取り消すためのメッセージです。通信エラーなどで取引が不完全に終わった場合などに、元の状態に戻すために使用されます。

References