ISO 8583 Messaging Standard – Complete Guide for Fintech, POS & ATM Systems

by

🧩 What is ISO 8583?

ISO 8583 is the international messaging standard for financial transaction card-originated messages. It is used in ATMs, POS terminals, mobile wallets, and banking switches to securely exchange payment messages.

It defines the format for request/response messages used between:

  • Acquirer ↔ Issuer
  • Terminal ↔ Switch
  • Gateway ↔ Bank

📦 Structure of an ISO 8583 Packet

Each ISO 8583 message consists of the following components:

PartDescription
MTIMessage Type Indicator (e.g., 0200, 0420)
Bitmap64-bit or 128-bit bitmap indicating present fields
Data ElementsFields like PAN, Amount, STAN, etc. (DE1–DE128)

🧾 Message Type Indicator (MTI)

MTI is a 4-digit numeric field that classifies the message.

MTIMeaning
0100Authorization Request
0110Authorization Response
0200Financial Transaction Request
0210Financial Transaction Response
0420Reversal Advice
0430Reversal Response
0800Network Management Request
0810Network Management Response

🔢 ISO 8583 Data Elements (Important Fields)

Here are key fields commonly used in transaction packets:

DE #Field NameFormatExample/Use Case
2Primary Account Number (PAN)LLVAR N16-digit card number
3Processing CodeN 6000000 (Purchase), 200000 (Refund)
4AmountN 12000000010000 = ₹100.00
7Transmission Date & TimeN 10MMDDhhmmss
11STANN 6Unique transaction ID
12Local TimeN 6hhmmss
13Local DateN 4MMDD
14Expiry DateN 4YYMM (e.g., 2608)
17Capture DateN 4MMDD (used for settlement)
24Network International IDN 3000 = Visa, 001 = MC, 024 = RuPay
35Track 2 DataLLVAR ZEncrypted card track info
37Retrieval Ref. NumberAN 12Unique txn reference
38Authorization CodeAN 6Issuer-approved code
39Response CodeAN 200 = Approved, 51 = Insufficient funds
41Terminal IDAN 8POS or ATM ID
42Merchant IDAN 15Merchant account number
49Currency CodeN 3356 = INR
55EMV DataLLLVAR BICC tags (chip transactions)
60–63National/Private Use FieldsLLLVAROften used in RuPay, UPI, BharatQR

🧮 DE39 – Response Codes (Success or Failure)

CodeDescription
00Approved/Completed
01Refer to card issuer
05Do not honor
12Invalid transaction
13Invalid amount
14Invalid card number
33Expired card
51Insufficient funds
54Expired card
55Incorrect PIN
57Transaction not permitted
91Issuer or switch inoperative
96System malfunction

🔄 How to Convert (Parse) ISO 8583 Messages

✅ 1. Extract MTI

E.g., 0200 = Purchase transaction request.

✅ 2. Read the Bitmap (HEX → Binary)

Bitmap F23C048188E08000 = bits that indicate which DEs are present.

✅ 3. Parse Fields

Using known formats (fixed or variable), extract fields like DE2, DE3, DE4, etc.

Example:

makefileCopyEditMTI: 0200
Bitmap: F23C...
DE2 = 6221234567890123
DE3 = 000000
DE4 = 000000005000
DE14 = 2608 (Card expiry: Aug 2026)
DE17 = 0701 (Capture Date: July 1st)
DE24 = 024 (Network: RuPay)
DE39 = 00 (Approved)
DE41 = POS12345
DE42 = MERCHANT123456

🛠 Tools to Build or Validate ISO 8583

ToolUse CaseLink / Info
jPOSJava-based ISO 8583 enginejpos.org
Python iso8583ISO parsing & decodingPyPi: iso8583
Hex to Binary ConvertersDecode bitmapAny online HEX-to-BIN tool
KaNest, FIME, ParagonPaid simulators for UATIndustry standard fintech labs

🔐 Why No Public ISO 8583 Validation URL?

ISO 8583 packets often contain sensitive card/payment data, hence:

  • Not exposed to public validators
  • Must comply with PCI-DSS
  • Validation is done using secure test simulators or switch environments

💡 Common Use Cases

ScenarioMTINotes
POS Purchase0200DE3 = 000000, DE4 = Amount
ATM Withdrawal0200DE3 = 010000
UPI/QR Transaction0200DE62 contains QR reference
Reversal after timeout0420DE90 = Original DE3, DE11, DE7, etc.
Authorization only0100Pre-auth or hotel booking

📚 Sample Python Decoder (Basic)

pythonCopyEditfrom iso8583 import iso8583
msg = b'0200F23C048188E08000...'
parsed, _ = iso8583.decode(msg)
print(parsed)

🔁 What is “Host Receive” & “Response from Host” in ISO 8583?

🔹 1. Host Receive

This means the host (e.g., issuing bank or switch) receives a message from the acquirer (POS/ATM) such as:

  • MTI: 0200 (Financial transaction request)
  • Along with fields like DE2 (Card Number), DE4 (Amount), DE3 (Processing Code), DE11 (STAN), etc.

✅ Common field values seen at host receive:

FieldField NameExample ValueMeaning
2PAN6221234567890123Card number from POS/ATM
3Processing Code000000Purchase
4Transaction Amount000000010000₹100.00
7Transmission Date/Time0701123045MMDDhhmmss
11STAN123456Unique ID from terminal
14Expiry Date2608YYMM = Aug 2026
24Network ID024RuPay
41Terminal IDPOS12345From where transaction originated
42Merchant IDMERCH1234567Unique merchant
55ICC DataTLV encoded EMV dataRequired for chip transactions

🔹 2. Response from Host

The host processes the transaction and returns a response message — usually with MTI = 0210 (response to 0200) or 0110 (for 0100).

✅ Fields returned in “response from host”:

FieldNameExamplePurpose
39Response Code0000 = Approved, 05 = Declined, etc.
38Authorization Code123456Issuer-provided approval code
37Retrieval Ref. NumberXYZ789456123Unique transaction reference
48/63Additional Private Data…Can include loyalty, surcharge info, etc.
55EMV Response DataTLVARQC/ARPC returned by chip

🛠 Example Flow: POS to Host and Back

🔹 POS → Host (MTI: 0200)

yamlCopyEditDE2: 6221234567890123
DE3: 000000
DE4: 000000005000
DE7: 0701123456
DE11: 654321
DE14: 2608
DE24: 024
DE41: POS12345
DE42: MERCH123456

🔹 Host → POS (MTI: 0210)

makefileCopyEditDE11: 654321  (same STAN)
DE37: XYZ789456123
DE38: 123456
DE39: 00  (Approved)
DE55: EMV response

🧩 Summary of Key Field Values for Host Communication

FieldDirectionPurpose
2ReceivePAN/card number
3ReceiveTransaction type
4ReceiveAmount
11BothTransaction identifier
14ReceiveCard expiration
24ReceiveNetwork ID
38ResponseApproval code from issuer
39ResponseFinal transaction result
55Both (EMV)ICC data (tag-length-value)

🔄 ISO 8583: Reversal & Void Sale Packet (Settlement & Processing Code)

✅ 1. Void Sale Transaction

📌 What is a Void Sale?

  • Used to cancel a financial transaction before it is settled.
  • Typically performed same day by merchant or terminal.
  • It does not reverse a settled transaction, only prevents it from being settled.

🔧 ISO 8583 MTI:

  • 0200 → Financial Transaction Request (Void)
  • 0210 → Response from Host

🔧 Processing Code (DE3):

ValueMeaning
200000Void Sale
220000Void Refund

🧾 Important Fields in Void Sale Packet:

FieldMeaningNotes
DE3Processing Code200000
DE4AmountSame as original transaction
DE11STAN (New)Unique for void txn
DE37Original Retrieval Ref No.From sale
DE38Original Auth CodeRequired
DE41Terminal IDFrom POS
DE90Original Data ElementsMTI+STAN+Date+RRN+Acquirer ID

🔁 2. Reversal Transaction

📌 What is a Reversal?

  • Used when a transaction failed at the terminal but the issuer may have already approved it.
  • Done to reverse or cancel a financially approved transaction that wasn’t completed (e.g., timeout, GPRS error, crash).
  • Can also be auto-triggered after timeout or failure.

🔧 ISO 8583 MTI:

  • 0420 → Reversal Advice
  • 0430 → Response

🔧 Processing Code (DE3):

  • Same as original transaction (e.g., 000000 for purchase)

🧾 Important Fields in Reversal Packet:

FieldMeaningNotes
DE3Processing CodeSame as sale
DE4AmountSame as original txn
DE7New date/timeFor reversal
DE11New STANNew trace number
DE37Original RRNMatches sale
DE38Original Auth CodeMust match
DE39Response Code00 = Success, 12 = Invalid txn
DE90Original Data ElementsReferred MTI, STAN, Date, RRN

📑 Field DE90 (Original Data Elements) Format

DE90 is critical in reversal and void. It identifies the original transaction.

SubfieldLengthExample
Original MTI40200
Original STAN6123456
Original DateTime100630123456
Acquirer ID (DE32)1112345678901
RRN12XYZ789123456

🔄 Difference: Void vs. Reversal

FeatureVoid SaleReversal
MTI02000420
Use CaseCancel a sale before settlementUndo txn due to failure/timeouts
Triggered ByMerchant/manualAuto/system/manual
DE3200000Same as sale (e.g., 000000)
DE90YesYes
DE38RequiredRequired
DE37Original RRNOriginal RRN

✅ Sample: Void Sale Packet

yamlCopyEditMTI: 0200
DE3: 200000
DE4: 000000005000
DE11: 987654
DE37: 123456789012
DE38: 789456
DE41: POS12345
DE42: MERCHANT456
DE90: 02001234560630123045ABC1234567890

✅ Sample: Reversal Packet

yamlCopyEditMTI: 0420
DE3: 000000
DE4: 000000005000
DE7: 0701131515
DE11: 654321
DE37: 123456789012
DE38: 123456
DE90: 02001234560630123456ABC1234567890

✅ Final Thoughts

Understanding ISO 8583 messaging is critical in designing and testing POS, ATM, and eCommerce financial systems. This includes:

  • Correct use of processing codes
  • Building and interpreting reversal and void packets
  • Mapping host behavior via MTI and DEs

Use secure simulators or environments to test and never expose live packets on the internet.

Leave a Comment