Part IVa - Member Bank Interface v5.3 - HIGHLIGHTED

SPAN RULES AND STANDARDS
TECHNICAL BOOK
PART IV - MEMBER BANK

INTERFACE
VERSION 5.3
ISSUE: AUGUST 2008

Table of Contents
TABLE OF CONTENTS................................................................................................................................ I
TABLE OF FIGURES ................................................................................................................................. X
TABLE OF TABLES .................................................................................................................................. XI
SECTION 1 INTRODUCTION ................................................................................................................ 13
1.1 Purpose of the Document ................................................................................................................ 13
1.2 References ........................................................................................................................................ 13
1.3 Document Structure ........................................................................................................................ 14
SECTION 2 MESSAGE FORMATS ....................................................................................................... 16
2.1 Introduction ..................................................................................................................................... 16
2.2 Supported Messages ........................................................................................................................ 16

2.2.1 Message Classification Method ................................................................................................... 16
2.2.2 Supported Messages Matrix ........................................................................................................ 16
2.2.3 Repeat Messages.......................................................................................................................... 18
2.2.4 Data Element Representation ...................................................................................................... 18
2.3 Network Management Messages .................................................................................................... 20

2.3.1 Network Management Request/Response ................................................................................... 21
2.3.2 Network Management Advice/ Advice Repeat / Response ......................................................... 22
2.4 ATM – Financial Messages............................................................................................................. 23

2.4.1 Financial Request/Response (ATM)............................................................................................ 24
2.4.2 Financial Transaction Advice / Advice Repeat/Response (ATM)............................................... 26
2.5 ATM – Reversals & Chargebacks.................................................................................................. 28

2.5.1 Reversal Advice / Advice Repeat / Response (ATM) ................................................................. 29
2.5.2 Chargeback (Advice/Reversal)/(Advice/Reversal) Repeat / Response (ATM) .......................... 31
2.6 ATM – Reconciliation ..................................................................................................................... 33

2.6.1 Acquirer Reconciliation Advice / Advice Repeat / Response (ATM) ........................................ 34
2.6.2 Card Issuer Reconciliation Advice / Advice Repeat / Response (ATM) .................................... 36
SPAN Rules And Standards Technical Book
Part IV - Member Bank Interface
Introduction
2.7 ATM – Administrative Message..................................................................................................... 38

2.7.1 Administrative Advice / Response (ATM) .................................................................................. 39
2.7.2 Administrative Notification (ATM)............................................................................................. 40
2.7.3 Fraud Advice / Response (Visa SMS) ......................................................................................... 41
2.8 POS – Authorisation Transactions ................................................................................................ 43

2.8.1 Authorisation Request/Response (POS) ...................................................................................... 44
2.8.2 Authorisation Advice / Advice Repeat / Response (POS) ........................................................... 46
2.9 POS – Financial Transactions ........................................................................................................ 48

2.9.1 Financial Request/Response (POS) ............................................................................................. 49
2.9.2 Financial Transaction Advice / Advice Repeat / Response (POS) .............................................. 51
2.10 POS – Reversals & Chargebacks ................................................................................................... 53

2.10.1 Reversal Advice / Advice Repeat / Response (POS) ................................................................... 54
2.10.2 Chargeback (Advice/Reversal)/(Advice/Reversal) Repeat / Response (POS) ........................... 56
2.11 POS – Reconciliation ....................................................................................................................... 58

2.11.1 Acquirer Reconciliation Advice / Advice Repeat / Response (POS) .......................................... 59
2.11.2 Card Issuer Reconciliation Advice / Advice Repeat / Response (POS) ...................................... 61
2.11.3 Terminal Reconciliation Advice (POS) ....................................................................................... 63
2.12 POS – Administrative Message ...................................................................................................... 64

2.12.1 Administrative Notification (POS) .............................................................................................. 65
SECTION 3 FIELD DESCRIPTIONS ..................................................................................................... 66
3.1 SPAN External Message ................................................................................................................. 66
3.2 Message Structure ........................................................................................................................... 66
3.3 Message Components ...................................................................................................................... 66

3.3.1 SPAN Header .............................................................................................................................. 66
3.3.2 Message Type Identifier .............................................................................................................. 67
3.3.3 Primary and Secondary Bit Maps ................................................................................................ 69
3.3.4 Data Elements .............................................................................................................................. 69
3.3.5 Format for the Data Elements ...................................................................................................... 70
3.3.6 Data Element Structures .............................................................................................................. 70
3.3.7 Fixed-Length Data Elements ....................................................................................................... 71
3.3.8 Variable-Length Data Elements .................................................................................................. 71
3.4 Data Elements (DE) ......................................................................................................................... 72

3.4.1 DE 1 – Secondary Bit Map .......................................................................................................... 72
3.4.2 DE 2 – Primary Account Number................................................................................................ 73
3.4.3 DE 3 – Processing Code .............................................................................................................. 74
3.4.4 DE 4 – Transaction Amount ........................................................................................................ 76
3.4.5 DE 5 – Reconciliation Amount.................................................................................................... 78
3.4.6 DE 7 – Transmission Date & Time ............................................................................................. 79
3.4.7 DE 9 – Reconciliation Conversion Rate ...................................................................................... 80
3.4.8 DE 11 – Systems Trace Audit Number ....................................................................................... 81
3.4.9 DE 12 – Local Transaction Date & Time .................................................................................... 83
3.4.10 DE 14 – Expiration Date ............................................................................................................. 84
3.4.11 DE 16 – Conversion Date ............................................................................................................ 85
3.4.12 DE 17 – Capture Date .................................................................................................................. 86
3.4.13 DE 22 – Point of Service Data Code ........................................................................................... 87
3.4.14 DE 23 – Card Sequence Number ................................................................................................. 91
Version: 5.3 ; Issue: August 2008 Page ii

Introduction
3.4.15 DE 24 – Function Code ............................................................................................................... 92

3.4.16 DE 25 – Message Reason Code ................................................................................................... 94
3.4.17 DE 26 – Card Acceptor Business Code ....................................................................................... 99
3.4.18 DE 28 – Reconciliation Date ..................................................................................................... 100
3.4.19 DE 30 – Original Amounts ........................................................................................................ 101
3.4.20 DE 32 – Acquirer Institution Identification Code...................................................................... 102
3.4.21 DE 35 – Track 2 Data ................................................................................................................ 103
3.4.22 DE 37 – Retrieval Reference Number ....................................................................................... 104
3.4.23 DE 38 – Approval Code ............................................................................................................ 105
3.4.24 DE 39 – Action Code................................................................................................................. 106
3.4.25 DE 41 – Card Acceptor Terminal Identification........................................................................ 110
3.4.26 DE 42 – Card Acceptor Identification Code .............................................................................. 111
3.4.27 DE 43 – Card Acceptor Name/Location .................................................................................... 112
3.4.28 DE 46 – Fee Amounts ............................................................................................................... 114
3.4.29 DE 47 – National Additional Data – Card Acceptor Name (Arabic)......................................... 115
3.4.30 DE 48 – Private Additional Data ............................................................................................... 116
3.4.31 DE 49 – Transaction Currency Code ......................................................................................... 121
3.4.32 DE 50 – Reconciliation Currency Code .................................................................................... 122
3.4.33 DE 52 – Personal Identification Number (PIN) Data ................................................................ 123
3.4.34 DE 53 – Security Related Control Information ......................................................................... 124
3.4.35 DE 54 – Additional Amounts .................................................................................................... 125
3.4.36 DE 55 – Integrated Circuit Card System Related Data .............................................................. 127
3.4.37 DE 56 – Original Data Elements ............................................................................................... 131
3.4.38 DE 59 – Transport Data ............................................................................................................. 133
3.4.39 DE 60 – POS Terminal Data ..................................................................................................... 134
3.4.40 DE 62 – Private Field – Terminal Status ................................................................................... 135
3.4.41 DE 72 – Data Record ................................................................................................................. 137
3.4.42 DE 74 – Number Credits ........................................................................................................... 138
3.4.43 DE 75 – Reversal Number Credits ............................................................................................ 139
3.4.44 DE 76 – Number Debits ............................................................................................................ 140
3.4.45 DE 77 – Reversal Number Debits.............................................................................................. 141
3.4.46 DE 80 – Number Inquiries ......................................................................................................... 142
3.4.47 DE 81 – Number Authorisations ............................................................................................... 143
3.4.48 DE 86 – Amount Credits ........................................................................................................... 144
3.4.49 DE 87 – Reversal Amount Credits ............................................................................................ 145
3.4.50 DE 88 – Amount Debits ............................................................................................................ 146
3.4.51 DE 89 – Reversal Amount Debits.............................................................................................. 147
3.4.52 DE 93 – Transaction Destination Institution Identification Code.............................................. 148
3.4.53 DE 94 – Transaction Originator Institution Identification Code ............................................... 149
3.4.54 DE 96 – Key Management Data ................................................................................................ 150
3.4.55 DE 97 – Net Reconciliation Amount ......................................................................................... 152
3.4.56 DE 100 – Receiving Institution Identification Code.................................................................. 154
3.4.57 DE 105 – Chargeback Amount Credits ..................................................................................... 155
3.4.58 DE 106 – Chargeback Amount Debits ...................................................................................... 156
3.4.59 DE 107 – Chargeback Number Credits ..................................................................................... 157
3.4.60 DE 108 – Chargeback Number Debits ...................................................................................... 158
3.4.61 DE 122 – Card Scheme Sponsor ID/Card Scheme ID ............................................................... 159
3.4.62 DE 123 – Card Scheme Information.......................................................................................... 160
3.4.63 DE 124 – SPAN POS Terminal Reconcile Total....................................................................... 163
3.4.64 DE 126 – Bank Card Scheme Totals Information ..................................................................... 165
3.4.65 DE 127 – SPAN POS SPAN Reconcile Total ........................................................................... 166
3.4.66 DE 128 – Message Authentication Code Field .......................................................................... 168
SECTION 4 TRANSACTION FLOWS .................................................................................................. 169
4.1 Introduction ................................................................................................................................... 169
Version: 5.3 ; Issue: August 2008 Page iii

Introduction
4.2 Additional Reference..................................................................................................................... 169

4.2.1 Reversals 170
4.3 Administrative Messages .............................................................................................................. 174

4.3.1 Administrative Notification – International Bank Card Scheme Administrative Request
(VISA) 174
(MasterCard).............................................................................................................................. 175
4.3.3 Administrative Notification – International Bank Card Scheme Card Capture Notice
(VISA) 176
4.3.4 Fraud Advice – International Bank Card Scheme Fraud Advice messages (VISA SMS
only) 177
4.4 Rejected Message........................................................................................................................... 178

4.4.1 Rejected Message – Exceptions to Normal Request or Advice Message Flow ......................... 179
4.4.2 Rejected Message – Exceptions to Normal Response Message Flow ....................................... 180
4.4.3 Rejected Message – Exceptions to Normal Response Message Flow (Incorrect MAC) ........... 181
4.5 Network Management Messages .................................................................................................. 182

4.5.1 Logon Requests – SPAN Logon Request .................................................................................. 183
4.5.2 Logon Requests – Bank Logon Request .................................................................................... 185
4.5.3 Echotest – Echotest Sent By SPAN ........................................................................................... 187
4.5.4 Echotest – Echotest Sent By Bank............................................................................................. 188
4.5.5 Logoff Requests – SPAN Logoff Processing ............................................................................ 189
4.5.6 Logoff Requests – Bank Logoff Processing .............................................................................. 190
4.5.7 Interactive Cutover Process – SPAN Interactive Cutover Process ............................................ 191
4.5.8 Non-Interactive Cutover Process – SPAN Non-Interactive Cutover Process ............................ 192
4.5.9 Interactive Cutover Process – Bank Interactive Cutover Process .............................................. 193
4.5.10 Non-Interactive Cutover Process – Bank Non-Interactive Cutover Process.............................. 194
4.5.11 Key Management Exchange – SPAN Key Management Exchange .......................................... 195
4.5.12 Retrieving MasterCard SAF Records ........................................................................................ 197
4.5.13 Retrieving VISA SMS SAF Records ......................................................................................... 200
4.6 ATM Financial Messages.............................................................................................................. 202

4.6.1 Financial Request – Normal Transaction (KSA Acquirer ATM) .............................................. 203
4.6.2 Financial Request – Normal Transaction (SAMA ATM) .......................................................... 207
4.6.3 Timeout Processing – Timer set by SPAN expires (KSA Acquirer ATM) ............................... 211
4.6.4 Timeout Processing – Timer set by SPAN expires (SAMA ATM) ........................................... 215
4.6.5 Timeout Processing – Timer set by Acquirer expires (KSA Acquirer ATM) ........................... 218
4.6.6 Reversal – Reversal due to ATM problem (KSA Acquirer ATM) ............................................ 222
4.6.7 Reversal – Reversal due to ATM problem (SAMA ATM) ....................................................... 226
4.6.8 Communications Failure – Link Down between SPAN and Card Issuer (KSA Acquirer
ATM) 229
4.7 ATM Reconciliation Messages ..................................................................................................... 231

4.7.1 Acquirer Reconciliation Processing........................................................................................... 233
4.7.2 Card Issuer Reconciliation Processing ...................................................................................... 235
4.7.3 Acquirer Reconciliation Store-and-Forward.............................................................................. 237
4.7.4 Card Issuer Reconciliation Store-and-Forward ......................................................................... 239
4.8 POS Financial Transaction Messages.......................................................................................... 241

4.8.1 Financial Transaction – Normal Transaction (Magnetic Stripe)................................................ 242
4.8.2 Financial Transaction – Normal Transaction (Chip Card)......................................................... 246
4.8.3 Financial Transaction – AMEX Normal Transaction (Magnetic Stripe) ................................... 250
4.8.4 Financial Transaction – AMEX Normal Transaction (Chip Card) ............................................ 252
4.8.5 Financial Authorisation – AMEX Pre-Authorisation (Magnetic Stripe / Chip) ........................ 254
4.8.6 Financial Transaction – AMEX Pre-Authorisation Completion (Magnetic Stripe / Chip) ........ 256
Version: 5.3 ; Issue: August 2008 Page iv
Introduction
4.8.7 Financial Transaction – IBCS Normal Magnetic Stripe Transaction Authorisation

(Approved/Declined), where the Retailer Bank is not the Card Scheme Acquirer .................... 258
4.8.8 Financial Transaction – IBCS Normal Chip Card Transaction Authorisation
(Approved/Declined), where the Retailer Bank is not the Card Scheme Acquirer .................... 260
4.8.9 Financial Transaction – IBCS Normal Magnetic Stripe Transaction (Approved/Declined),
where the Retailer Bank is the Card Scheme Acquirer .............................................................. 262
4.8.10 Financial Transaction – IBCS Normal Chip Transaction (Approved/Declined), where the
Retailer Bank is the Card Scheme Acquirer .............................................................................. 264
4.8.11 Timeout Processing – No Response Received from IBCS switch (Magnetic Stripe card) ........ 266
4.8.12 Timeout Processing – No Response Received from IBCS switch (Chip card) ......................... 268
4.8.13 Communications Failure – Link is down between SPAN and the Retailer Bank/Bank Card
Scheme Bank, (IBCS Magnetic Stripe) .................................................................................... 270
4.8.14 Communications Failure – Link is down between SPAN and the Retailer Bank/Bank Card
Scheme Bank, (IBCS Chip Card) ............................................................................................. 272
4.8.15 Timeout Processing – No Response Received from the Card Issuer Bank (Magnetic Stripe) .. 274
4.8.16 Timeout Processing – No Response Received from the Card Issuer Bank and SPAN (Chip
Card) 276
4.8.17 Communications Failure – Link is Down between SPAN and Card Issuer............................... 278
4.8.18 Communications Failure – Link is down between the Retailer Bank and SPAN (Magnetic
Stripe) 280
4.8.19 Timeout Processing – Link is down between the Retailer Bank and SPAN (Chip Card).......... 283
4.8.20 IBCS Financial Authorisation – Normal Transaction (Magnetic Stripe) ................................... 285
4.8.21 IBCS Financial Authorisation – Normal Transaction (Chip Card) ............................................ 287
4.8.22 IBCS Advice Messages - Pre-Authorisation Completion .......................................................... 289
4.8.23 IBCS Advice Messages – Retailer receives voice authorisation for the purchase from the
transaction authoriser, where the Retailer Bank is not the Card Scheme Acquirer ................... 291
4.8.24 IBCS Advice Messages – Retailer receives voice authorisation for the purchase from the
transaction authoriser, where the Retailer Bank is the Card Scheme Acquirer ......................... 293
4.8.25 IBCS Refund – Retailer performs a refund transaction, where the Retailer Bank is not the
Card Scheme Acquirer............................................................................................................... 294
4.8.26 IBCS Refund – Retailer performs a refund transaction, where the Retailer Bank is the Card
Scheme Acquirer. ...................................................................................................................... 296
4.8.27 Chip Card Off-line Purchase Transaction .................................................................................. 297
4.8.28 IBCS Chip Card Off-line Purchase Transaction ........................................................................ 298
4.8.29 Reversal – Reversal because of SPAN POS Terminal communication problem (Magnetic
Stripe) 299
4.8.30 Reversal – SPAN POS Terminal Communication Problem (Chip Card) .................................. 303
4.8.31 Reversal – SPAN POS Terminal/Retailer reverses the transaction (Magnetic Stripe) .............. 306
4.8.32 Reversal – SPAN POS Terminal or Retailer Reverses the Transaction (Chip Card) ................ 310
4.8.33 Timeout Processing – SPAN timer expires waiting for an Authorisation Request Response 313
4.8.34 Reversal – Reversal because of SPAN POS terminal/communication problem ........................ 315
4.8.35 Reversal - SPAN POS terminal reverses the IBCS transaction ................................................. 318
4.9 POS Reconciliation Messages ....................................................................................................... 321

4.9.1 Reconciliation – Acquirer reconciliation processing ................................................................. 323
4.9.2 Reconciliation - Acquirer reconciliation Store-and-Forward (SAF) processing........................ 325
4.9.3 Reconciliation – Card Issuer reconciliation processing ............................................................. 327
4.9.4 Reconciliation – Card Issuer reconciliation Store-and-Forward (SAF) processing ................... 329
4.9.5 Reconciliation – Terminal reconciliation processing................................................................. 331
4.9.6 Reconciliation – Terminal reconciliation Store-and-Forward (SAF) processing ...................... 333
4.9.7 Reconciliation – POS terminal reconciliation was completed by SPAN but the response
message from SPAN was not received by the POS terminal (repeat reconciliation)................. 335
4.9.8 Reconciliation – Retailer Bank and the Bank Card Scheme Bank are the same institution ...... 336
4.9.9 Reconciliation - Retailer Bank and the Bank Card Scheme Bank are not the same
institutions and the Bank Card Scheme Bank services both Visa and MasterCard ................... 338
4.9.10 Reconciliation – Retailer Bank and the Bank Card Scheme Banks are not the same
institutions, different Bank Card Scheme Banks service Visa and MasterCard ........................ 341
Version: 5.3 ; Issue: August 2008 Page v

Introduction
4.9.11 Reconciliation – Store-and-Forward (SAF) processing, where Retailer Bank and the Bank
Card Scheme Bank are the same institution .............................................................................. 344
4.9.12 Reconciliation – Retailer Bank and the Bank Card Scheme Bank are not the same
institutions and the Bank Card Scheme Bank services both Visa and MasterCard ................... 346
institutions, different Bank Card Scheme Banks service Visa and MasterCard ........................ 349
4.10 International Bank Scheme Related Messages (ATM & POS) ................................................. 352
4.10.1 Financial Request – IBCS Card Issuer Bank participates in SPAN (ATM/POS) ...................... 353
4.10.2 IBCS Reversal Processing (ATM/POS) .................................................................................... 356
4.10.3 Reversal – Foreign withdrawal is partially dispensed; the Switch notifies SPAN, which
sends a partial reversal to the IBCS Card Issuer Bank participant (ATM) ................................ 358
4.10.4 Chargeback – IBCS Acquirer Chargeback Processing .............................................................. 361
4.10.5 Chargeback – IBCS Issuer Chargeback Processing................................................................... 362
4.10.6 Re-presentment – IBCS Acquirer Re-presentment Processing .................................................. 363
4.10.7 Re-presentment – IBCS Issuer Re-presentment Processing ...................................................... 364
4.10.8 Communications Failure - Link Down between SPAN and IBCS Card Issuer Bank (SPAN
Member) - (ATM/POS) ............................................................................................................ 365
4.10.9 Timeout Processing – No Response Received from IBCS Card Issuer Bank, (SPAN
Member Bank) - (ATM/POS) ................................................................................................... 366
4.10.10 Communications Failure – Link down between SPAN and IBCS Switch (ATM/POS) ........ 368
4.10.11 Timeout Processing – Timer set by Switch expires, thus the Switch sends response to the
transaction acquirer and then receives a late response from SPAN (ATM/POS) ................... 371
4.10.12 Timeout Processing – SPAN receives Late Response from IBCS Card Issuer (SPAN
Member) - (ATM/POS) .......................................................................................................... 374
4.10.13 Visa SMS Generated Acquirer Bound Reversal Advice Processing ...................................... 377
4.10.14 Acquirer Generated Visa SMS Misdispense Advice Processing ............................................ 379
4.10.15 Acquirer Generated VISA SMS Reconciliation Adjustment Advice Processing ................... 380
4.10.16 Acquirer Generated VISA SMS Fee Collection Processing ................................................... 381
4.10.17 Acquirer Generated VISA SMS Fee Payment Advice Processing ......................................... 382
4.10.18 Issuer Generated VISA SMS Fee Collection Advice Processing ........................................... 383
4.10.19 Issuer Generated VISA SMS Funds Disbursement Advice Processing .................................. 384
4.10.20 VISA SMS Generated Funds Transfer Totals Advice Response ............................................ 385
4.11 Claims Processing .......................................................................................................................... 386

4.11.1 CPS Adjustment Transaction ..................................................................................................... 387
SECTION 5 RECONCILIATION PROCESSING ....................................................................................... 389
5.1 Definitions ...................................................................................................................................... 389
5.2 Cutover Process ............................................................................................................................. 391

5.2.1 Bank Cutovers ........................................................................................................................... 391
5.2.2 SPAN Cutovers ......................................................................................................................... 392
5.2.3 Date Processing ......................................................................................................................... 392
5.2.4 POS Connected to SAMA (Retailer Bank and Issuer Bank are the same) ................................ 393
5.2.5 POS Connected To SAMA (Retailer Bank and Issuer Bank are different) ............................... 393
5.3 Date Processing Examples ............................................................................................................ 394

5.3.1 POS Transactions (POS Terminals Connected to SAMA) ........................................................ 395
5.3.2 ATM Transactions ..................................................................................................................... 400
5.4 Exception Conditions During Cutover ........................................................................................ 404
5.5 Online Reconciliation .................................................................................................................... 405

5.5.1 Introduction ............................................................................................................................... 405
Version: 5.3 ; Issue: August 2008 Page vi

Introduction
5.5.2 Reconciliation Messages ........................................................................................................... 405

5.5.3 Reconciliation Calculation Rules .............................................................................................. 406
5.5.4 Reconciliation Calculations ....................................................................................................... 413
5.5.5 ATM Net Reconciliation Calculation ........................................................................................ 414
5.5.6 POS Net Reconciliation Calculation.......................................................................................... 415
5.5.7 POS Terminal Force Reconciliation and Request Reconciliation ............................................. 419
5.6 Reconciliation Examples ............................................................................................................... 420

5.6.1 POS Online Reconciliation Totals Accumulation Example ...................................................... 420
5.6.2 ATM Online Reconciliation Totals Accumulation Example ..................................................... 426
5.7 Calculation of Bank Net Reconciliation Position with SPAN .................................................... 430
5.7.1 Bank Net Reconciliation Position Example............................................................................... 430
5.8 Offline Reconciliation ................................................................................................................... 431

5.8.1 POS Reports/Extracts ................................................................................................................ 431
5.8.2 ATM Reports/Extracts ............................................................................................................... 431
5.8.3 SPAN Reconciliation Reporting ................................................................................................ 431
5.8.4 EFT Funds Transfer ................................................................................................................... 431
5.8.5 Fee Accounting .......................................................................................................................... 432
5.9 Bank Card Scheme Reconciliation/Settlement ........................................................................... 432
SECTION 6 PROTOCOL AND COMMUNICATIONS ............................................................................... 435
6.1 Introduction ................................................................................................................................... 435
6.2 TCP/IP ............................................................................................................................................ 435

6.2.1 General Overview ...................................................................................................................... 435
6.2.2 Related Documentation ............................................................................................................. 436
6.3 Use of TCP on Member Bank Interface ...................................................................................... 436

6.3.1 Connection Establishment ......................................................................................................... 436
6.3.2 Connection Usage ...................................................................................................................... 436
6.3.3 Normal Connection Termination ............................................................................................... 437
6.3.4 Connection Failure .................................................................................................................... 437
6.3.5 Connection Re-Establishment ................................................................................................... 437
6.3.6 Configuration Parameters .......................................................................................................... 438
SECTION 7 NETWORK SECURITY ......................................................................................................... 439
7.1 Introduction ................................................................................................................................... 439
7.2 Key Management........................................................................................................................... 439

7.2.1 Introduction ............................................................................................................................... 439
7.2.2 Key Hierarchy ........................................................................................................................... 439
7.2.3 Key Generation .......................................................................................................................... 440
7.2.4 Key Length ................................................................................................................................ 441
7.2.5 Key Exchange ............................................................................................................................ 441
7.3 Communication Authentication ................................................................................................... 448

7.3.1 Functionality Overview ............................................................................................................. 448
7.3.2 Network Messages Flow ........................................................................................................... 449
7.4 Data Authentication ...................................................................................................................... 450

7.4.1 Introduction ............................................................................................................................... 450
Version: 5.3 ; Issue: August 2008 Page vii
Introduction
7.4.2 Message Fields to be MAC’ed .................................................................................................. 450

7.4.3 Message Authentication Block (MAB) Generation ................................................................... 452
7.5 PIN Processing ............................................................................................................................... 453
SECTION 8 INTERNATIONAL BANK CARD SCHEME PROCESSING ................................................. 454
8.1 Introduction ................................................................................................................................... 454
8.2 International Bank Card Scheme Cards ..................................................................................... 454
8.3 International Bank Card Scheme Sponsor Banks ...................................................................... 454
8.4 Transaction Routing ..................................................................................................................... 454
8.5 International Bank Card Scheme ATM Transaction Processing ............................................. 455
8.5.1 IBCS ATM Transactions Acquired in Saudi Arabia Routed by SPAN (Acquirer) ................... 455
8.5.2 IBCS ATM Transactions Acquired Abroad Routed to SPAN (Issuer)...................................... 457
8.6 International Bank Card Scheme POS Transaction Processing ............................................... 459
8.6.1 IBCS POS Transactions Acquired in Saudi Arabia Routed by SPAN (Acquirer) ..................... 459
8.6.2 IBCS POS Transactions Acquired Abroad Routed to SPAN (Issuer) ....................................... 462
8.7 SPAN ATM Reconciliation ........................................................................................................... 464
8.8 SPAN POS Terminal Reconciliation ........................................................................................... 464
8.9 International Bank Card Scheme Settlement ............................................................................. 465

8.9.1 POS 465
8.9.2 ATM 465
8.9.3 Mapping SPAN Interface Fields To Visa Settlement Fields ..................................................... 465
8.9.4 Mapping ISO Interface Fields To MasterCard Settlement Fields .............................................. 466
8.9.5 Bank Interface Modifications .................................................................................................... 466
8.10 International Bank Card Scheme Certification .......................................................................... 467
SECTION 9 TRANSACTION LOG FILE EXTRACT ................................................................................. 468
9.1 Introduction ................................................................................................................................... 468
9.2 ATM & POS Extracts ................................................................................................................... 468
9.3 Extract Records ............................................................................................................................. 469

9.3.1 General 469
9.3.2 Primary Extract Files ................................................................................................................. 470
9.3.3 Secondary Extract Files ............................................................................................................. 475
Version: 5.3 ; Issue: August 2008 Page viii

Introduction
SECTION 10 FIELD VALUES UNIQUE TO SPAN ................................................................................ 478
APPENDIX A POS DE 24–FUNCTION CODE & DE 25-MESSAGE REASON CODE USAGE ........... 486
APPENDIX B DE39 IN FINANCIAL ADVICE TRANSACTIONS ........................................................... 488
APPENDIX C DE4 & DE30 IN FINANCIAL REQUEST/ADVICE TRANSACTIONS ............................. 489
APPENDIX D USAGE OF DATA ELEMENTS DURING EMV MIGRATION ......................................... 491
APPENDIX E DE 123 – CARD SCHEME INFORMATION USAGE DETAILED DESCRIPTION .......... 497
APPENDIX F DE 39 ACTION CODE ...................................................................................................... 543
APPENDIX G SPAN2 MAPPING OF DE 24 FUNCTION CODES & DE 25 MESSAGE REASON

CODES TO VISA SMS CODES ....................................................................................... 546
Appendix G.1 Adjustment Message Reason Code Table 546

Appendix G.1.1 Fee Collection / Funds Disbursement Message Reason Code Mapping Table 547
Appendix G.2 Message Reason Code Table 548

Appendix G.2.1 Function Codes 548
Appendix G.3 SPAN2 Support for Visa SMS Point-Of-Service Condition Code 548
Version: 5.3 ; Issue: August 2008 Page ix

Introduction
Table of Figures
FIGURE 5-1 INFORMATION FLOW FOR SETTLEMENTS AND INTERNATIONAL BANK
CARD SCHEME TRANSACTIONS ............................................................................ 433
FIGURE 7-1 ZMK UPDATE ............................................................................................................... 442
FIGURE 7-2 ZPK AND ZAK EXCHANGE FLOW ........................................................................... 444
FIGURE 7-3 KEY SYNCHRONISATION PROCESS FOR ACQUIRERS ....................................... 446
FIGURE 7-4 KEY SYNCHRONISATION PROCESS FOR ISSUERS .............................................. 447
FIGURE 7-5 GENERATION AND DISTRIBUTION OF RSA KEYS FOR NETWORK
MESSAGES AUTHENTICATION ............................................................................... 448
FIGURE 7-6 MEMBER BANK INTERFACE - LOGON PROCESS ................................................. 449
FIGURE 7-7 MESSAGE AUTHENTICATION BLOCK GENERATION ......................................... 453
FIGURE 8-1 INFORMATION FLOW FOR SETTLEMENT ACQUIRED INTERNATIONAL
BANK CARD SCHEME TRANSACTIONS ................................................................ 456
Version: 5.3 ; Issue: August 2008 Page x

Introduction
Table of Tables
TABLE 3-1 SPAN HEADER....................................................................................................................... 67
TABLE 3-2 NETWORK PRODUCT INDICATOR USE IN NETWORK MANAGEMENT
MESSAGES ............................................................................................................................. 67
TABLE 3-3 VALID NETWORK PRODUCT INDICATORS BY MESSAGE TYPE ............................... 67
TABLE 5-1 RECONCILIATION AMOUNT FIELDS USED IN ISO 8583:1993 STANDARD ............. 407
TABLE 5-2 RECONCILIATION COUNT FIELDS USED IN ISO 8583:1993 STANDARD ................. 407
TABLE 5-3 RECONCILIATION AMOUNT FIELDS USED FOR SPAN CARD TRANSACTIONS ... 408
TABLE 5-4 RECONCILIATION COUNT FIELDS USED FOR SPAN CARD TRANSACTIONS ....... 409
TABLE 5-5 RECONCILIATION AMOUNT FIELDS USED FOR IBCS TRANSACTIONS ................ 409
TABLE 5-6 RECONCILIATION COUNT FIELDS USED FOR IBCS TRANSACTIONS .................... 410
TABLE 5-7 RECONCILIATION AMOUNT FIELDS USED BY POS TERMINAL .............................. 411
TABLE 5-8 RECONCILIATION COUNT FIELDS USED BY POS TERMINAL.................................. 412
TABLE 5-9 ATM AND POS TRANSACTION IMPACT ON BANK TOTALS ..................................... 413
TABLE 5-10 ATM TRANSACTION IMPACT ON CARD ISSUER BANK AND ACQUIRER
BANK TOTALS .................................................................................................................. 415
TABLE 5-11 ATM TRANSACTION IMPACT ON RECONCILIATION ADVICE FIELDS ................ 415
TABLE 5-12 POS TRANSACTION IMPACT ON CARD ISSUER BANK AND RETAILER
BANK TOTALS .................................................................................................................. 416
TABLE 5-13 POS TRANSACTION IMPACT ON RECONCILIATION ADVICE FIELDS –
CARD ISSUER BANK........................................................................................................ 418
TABLE 5-14 POS TRANSACTION IMPACT ON RECONCILIATION ADVICE FIELDS –
RETAILER BANK .............................................................................................................. 419
TABLE 5-15 BANK A ACCUMULATING 1520 ACQUIRER RECONCILIATION ADVICE POS
TOTALS (PART 1).............................................................................................................. 422
TABLE 5-16 BANK A ACCUMULATING 1520 ACQUIRER RECONCILIATION ADVICE
TOTALS (PART 2).............................................................................................................. 422
TABLE 5-17 BANK A ACCUMULATING 1522 ISSUER RECONCILIATION ADVICE TOTALS
(PART 1) .............................................................................................................................. 423
TABLE 5-18 BANK A ACCUMULATING 1522 ISSUER RECONCILIATION ADVICE TOTALS
(PART 2) .............................................................................................................................. 424
TABLE 5-19 BANK B ACCUMULATING 1520 ACQUIRER RECONCILIATION ADVICE
TOTALS (PART 1).............................................................................................................. 424
TABLE 5-20 BANK B ACCUMULATING 1520 ACQUIRER RECONCILIATION ADVICE POS
TOTALS (PART 2).............................................................................................................. 425
TABLE 5-21 BANK B ACCUMULATING 1522 ISSUER RECONCILIATION ADVICE POS
TOTALS (PART 1).............................................................................................................. 426
TABLE 5-22 BANK B ACCUMULATING 1522 ISSUER RECONCILIATION ADVICE POS
TOTALS (PART 2).............................................................................................................. 426
TABLE 5-23 BANK A ACCUMULATING 1520 ACQUIRER RECONCILIATION ADVICE ATM
TOTALS .............................................................................................................................. 427
TABLE 5-24 BANK A ACCUMULATING 1522 ISSUER RECONCILIATION ADVICE ATM
TOTALS .............................................................................................................................. 428
TABLE 5-25 BANK B ACCUMULATING 1520 ACQUIRER RECONCILIATION ADVICE ATM
TOTALS .............................................................................................................................. 429
TABLE 5-26 BANK B ACCUMULATING 1522 ISSUER RECONCILIATION ADVICE ATM
TOTALS .............................................................................................................................. 429
TABLE 5-27 NET RECONCILIATION POSITION FOR BANK A ........................................................ 430
TABLE 5-28 NET RECONCILIATION POSITION FOR BANK B ........................................................ 430
Version: 5.3 ; Issue: August 2008 Page xi

Introduction
TABLE 6-1 PORT SPECIFIC TCP CONFIGURATION PARAMETERS......................................... 438

TABLE 7-1 ZMK UPDATE STEPS .................................................................................................... 442
Version: 5.3 ; Issue: August 2008 Page xii

Introduction
Section 1 Introduction
1.1 Purpose of the Document

This document is part of a broader set of technical documents that together provide a coherent end-to-
end technical specification of the electronic payments process for which the SPAN switch is the hub.
These technical documents have been upgraded to support the new SPAN switching software
(sometimes referred to as SPAN2), technical innovations in the card payments industry and the need to
deal with a wider range of card schemes. In particular, this document should be read in conjunction
with the following SPAN technical books:
• the Terminal Specification;
• the Terminal Interface Specification;
• the EMV Card Design; and
• the Security Framework
in order to acquire a detailed understanding of the underlying technical infrastructure.
The Member Bank Interface covers the transaction flows and message content of those messages
passing between the member banks and the SPAN switch. Messages originate from ATM and POS,
other participating banks and the card schemes.
In the future, SAMA plan to enhance the system to receive transactions from other origins such as e-
payments via the internet.
The scope of this document does not include:
• the translation of messages into and out of formats required for communication with devices such
as ATMs and POS terminals;
• specifications for Payments and other external settlement systems, though the messages do include
data to support such systems;
• detailed security management;
These subjects are covered elsewhere in the technical portfolio.
The message formats and field definitions for this interface are kept in line, as much as possible, with
the ISO 8583 standard (1993 Edition). Hence, in this document some of the non-standard items
(deviations) in the previous version (SPAN 3.7) of the member bank interface are revised to use the
definition provided by the ISO standard.
Card acceptor devices in the Kingdom will accept chip cards compliant with the EMV 2000 standards.
This includes the international card schemes implementation of the EMV standards (i.e. Visa-VSDC
(VIS), MasterCard-M/CHIP and AMEX-AEIPS). The switch system will provide switching functions
to support these chip card based transactions as described in Book 4 of the EMV 2000 standards.
The application of the TCP/IP protocol to the data communications level of the interface to SPAN is
also specified.
The Claims Processing Document has not yet been approved, and any changes to that document may
impact the detail in the MBI.
1.2 References
Document Version Issuer
ISO 8583 Financial transaction card originated messages – International Standards
1993
Interchange message specifications Organisation
Version: 5.3 ; Issue: August 2008 Page 13

Introduction
Document Version Issuer

SPAN Rules and Standards Business book Part IIa –
0.7 (Sep. 2004) SAMA
Settlement and Reconciliation Procedures
SPAN Technical book – Part IIa - Terminal Specification -
5.0 (Oct. 2004) SAMA
POS
SPAN Technical book – Part IIb – EFTPOS Terminal
5.0 (Oct. 2004) SAMA
Interface
SPAN Technical book – Part IIc - Terminal Specification
5.0 (Oct. 2004) SAMA
– ATM
SPAN Technical book – Part III - Security Framework 5.0 (Oct. 2004) SAMA
3.0
GCC Net Interchange, ATM Standards GCC Net
(10 Jan. 2003)
MDS Online Specification June 2003 MasterCard
MasterCard Authorisation System April 2003 MasterCard
VIP System, Base 1 Processing Specifications 1 July 2002 Visa International
VIP System, SMS ATM Technical Specifications 1 August 2002 Visa International
Detailed Design Document – Project SAMA, Module CPS
August 2004 E.Funds
version 1.12
1.3 Document Structure

The SPAN Interface Manual is divided into a number of sections as follows:
Section 1 – Introduction, provides the purpose and scope of the manual including a summary of the
manual content.
Section 2 – Message Formats, describes the message formats to be used within SPAN. This section
details the format and usage of all fields within the supported ISO message set for both ATM and POS,
which includes Network Management Messages (NMM). Although the same message types are used
for both ATM and POS, the actual data characteristics vary. Data characteristics are defined in Sections
3 and 4.
Section 3 – Field Descriptions, provides a listing of fields within the SPAN messages including a
description of their contents. Subsection 4 contains the data element descriptions that incorporate both
ATM and POS transaction processing needs.
Section 4 – Transaction Flows, gives details of how the messages that constitute transactions
supported by the SPAN network are exchanged between various parties. Brief descriptions of the
processing requirements, error and exception conditions are also included.
Section 5 – Reconciliation Processing, describes how accounts are reconciled among the Banks and
the SPAN switch. The term "reconciliation" refers to the accounting process which ends the current
posting day and begins the next posting day.
Section 6 – Protocol and Communications, defines the data communications level of the interface to
SPAN. Section 7 – Network Security, describes the requirements for encrypting and translating the
cardholder Personal Identification Number (PIN) and for managing the acquirer and issuer working
keys. Section 8 has been expanded to highlight the additional security measures being implemented as
part of SPAN. Details on SPAN POS terminal security are contained in the SPAN Terminal Standards
Manual.
Section 8 – International Bank Card Scheme Processing, describes in brief the International Bank
Card Scheme processing, including transaction processing, message fields, reconciliation, and
settlement requirements.
Introduction
Section 9 – Transaction Log File Extract, defines the extract data file structure for Banks acting as
Card Issuer and Acquirer.
Section 10 – Field Values Unique to SPAN lists some of the fields and their unique values as assigned
by SPAN.

Message Formats
Section 2 Message Formats
2.1 Introduction
The International Standard ISO 8583:1993 is designed as an interface specification to facilitate the
exchange of financial transaction messages between financial institution systems adopting different
application specifications. The Standard specifies message structure, format and content, data elements
and values for data elements.
The 1993 edition of the standard cancels and replaces the first edition (ISO 8583:1987). The 1993
standard introduces the concept of a message version number to distinguish between messages that
comply with the older 1987 edition. This concept will be supported in future editions of the Standard.
The message itself is based on a mixture of fixed and variable length fields. At least one and sometimes
two bit maps precede the field data. These are used as an index of the data elements contained within
the message, the presence or absence of a field being determined by the relevant bit setting. This
technique allows for a message structure that does not preclude the use of additional data elements
required for national interchanges or private use.
The SPAN network interface specifications have been devised with a “variable message” approach
rather than a “fixed message” one. This will ensure the greatest future flexibility in communicating
with the network and provide participating financial institutions with a flexible implementation of the
standard.
This section describes each message that is used in the SPAN network. The general message processing
requirements are described as well as the mandatory field requirements for each message. A detailed
definition of each field type can be found in the following section.
2.2 Supported Messages

2.2.1 Message Classification Method
Each message shall be constructed with a number of key components, Message Type Identifier (MTI),
one or two bit maps and a series of data elements (fields) in the order specified in the bit map
representation.
The SPAN network supports the message types shown in the table below for both inbound and
outbound messages. Separate messages are included to support those messages relating to transactions
originating at ATM’s and POS terminals, with the exception of Network Management Messages
(NMM) as these do not relate to specific payment transactions.
2.2.2 Supported Messages Matrix

SPAN Acquirers and Issuers must support all transactions listed in this technical book (for applicable
interfaces) and in both Arabic and English.
SPAN Cards
The Language Indicator field on Track 2 indicates the language that the customer will use at an ATM
or POS device.
If a language is not indicated in this field, the ATM will display a language selection screen, and the
POS device will display the default merchant language that can be toggled at will whilst offering the
cardholder a language selection for the PIN PAD.
Cards issued by banks in SPAN must contain a language indicator that specifies the language selected
by the customer to be used in transactions processed by the SPAN network. This language indicator
must specify either Arabic or English, unless the customer has explicitly indicated that he prefers to
choose his language during each transaction.
Non-SPAN Cards

Message Formats
The ATM will display a language selection screen, and the POS device will display the default
merchant language that can be toggled at will whilst offering the cardholder a language selection for
the PIN PAD.
2.2.2.1 Message Class: Network Management

MTI Type Description ATM POS NMM
1804 ISO Network Management Request ×
1814 ISO Network Management Request Response ×
1824 ISO Network Management Advice ×
1825 ISO Network Management Advice Repeat ×
1834 ISO Network Management Advice Response ×
2.2.2.2 Message Class: Authorisation

1100 ISO Authorisation Request ×
1110 ISO Authorisation Request Response ×
1120 ISO Authorisation Advice ×
1121 ISO Authorisation Advice Repeat ×
1130 ISO Authorisation Advice Response ×
2.2.2.3 Message Class: Financial

1200 ISO Financial Request × ×
1210 ISO Financial Request Response × ×
1220 ISO Financial Advice × ×
1221 ISO Financial Advice Repeat × ×
1230 ISO Financial Advice Response × ×
2.2.2.4 Message Class: Reversal

1420 ISO Reversal Advice × ×
1421 ISO Reversal Advice Repeat × ×
1430 ISO Reversal Advice Response × ×
2.2.2.5 Message Class: Chargeback

1422 ISO Chargeback Advice × ×
1423 ISO Chargeback Advice Repeat × ×

Message Formats

1432 ISO Chargeback Advice Response × ×
2.2.2.6 Message Class: Reconciliation

1520 ISO Acquirer Reconciliation Advice × ×
1521 ISO Acquirer Reconciliation Advice Repeat × ×
1522 ISO Card Issuer Reconciliation Advice × ×
1523 ISO Card Issuer Reconciliation Advice Repeat × ×
1524 SPAN Terminal Reconciliation Advice ×
1525 SPAN Terminal Reconciliation Advice Repeat ×
1530 ISO Acquirer Reconciliation Advice Response × ×
1532 ISO Card Issuer Reconciliation Advice Response × ×
1534 SPAN Terminal Reconciliation Advice Response ×
2.2.2.7 Message Class: Administrative

1624 ISO Administrative Advice ×
1634 ISO Administrative Advice Response ×
1644 ISO Administrative Notification × ×
2.2.2.8 Message Class: Private

9620 SPAN Fraud Advice ×
9630 SPAN Fraud Advice Response ×
2.2.3 Repeat Messages

Repeat messages are exactly the same as the original message except:
• Message Type Identifier (fourth position – Transaction Originator is one more than the original
transaction)
• MAC (Message Type change)
All other fields are taken from the original including date and time, transmission (DE 7).
2.2.4 Data Element Representation

The following abbreviations are extracted from ISO8583:1993 and are used in the tables below.
Abbr. Description
a alphabetic characters (A-Z, a-z)
b binary representation of data

Message Formats
Abbr. Description
n numeric digits (0-9)
an alphabetic and numeric characters
anp alphabetic, numeric and space (pad) characters
ans alphabetic, numeric and special characters
z Tracks 2 and 3 code set as defined in ISO 4909 and ISO 7813
..99 variable length up to a maximum of 99.
See section 3.3.5 for more details of the data element formats referred to in the following tables.
Further abbreviations used in the tables below:
C – Conditional
CE – Conditional echo
M – Mandatory
ME – Mandatory echo
An Asterisk (*) after an entry indicates there is a note on this data element. These notes are usually
located at the end of the sub-section, except for the SPAN Message Header. Details of the layout and
content of the SPAN Message Header are to be found in section 3.3.1.

Message Formats
2.3 Network Management Messages

The network management messages supported by SPAN network shall be used to control the system
security and operating condition and may be initiated by any interchanging party.
The types of network management messages are:
• System condition messages
• System security messages
• System accounting messages
• System audit control messages

Message Formats
2.3.1 Network Management Request/Response

Message Type: 1804 1814
Name: Network Management Request Network Management Request Response
Routing: Member Bank to SPAN SPAN to Member Bank
SPAN to Member Bank Member Bank to SPAN
Description: A Network Management Request (1804) A Network Management Request

shall be used to perform the following Response (1814) message is to be sent
system condition and control functions in response to Network Management
 Echo-tests Request (1804) message.
 Logon This response message shall carry the
 Logoff answer to the 1804 request message and it
is expected that all banks will respond
Additionally, this message will be used by
with this message as will SPAN.
SPAN to perform the following system
security and accounting functions
 Notify banks of the SPAN business
day cutover (at two different times,
one for ATM and one for POS)
 Handle security aspects of the network
i.e. key management, more
specifically the ZWK key exchanges
The message is also used by member banks
for:
• Notify SPAN of member bank cutover
(two different times one for ATM and
one for POS)
Data Elements:
Pos’n Data Element Attr Req Resp Value
* Message Header an12 * * Dynamic
ISO Message Type Identifier n4 1804 1814
ISO Primary Bitmap an16 M M Dynamic
1 Secondary Bitmap an16 M M Dynamic
7 Transmission Date & Time n10 M M Dynamic
11 Systems Trace Audit Number n6 M ME Dynamic
12 Local Transaction Date & Time n12 M ME Dynamic
24 Function Code n3 M - Dynamic
28 Reconciliation Date n6 C CE Dynamic
39 Action Code n3 - M Dynamic
93 Transaction Destination Institution ID Code n..11 M ME Dynamic
94 Transaction Originator Institution ID Code n..11 M ME Dynamic
96 Key Management Data b…999 C C Dynamic

Message Formats
2.3.2 Network Management Advice/ Advice Repeat / Response

Message Type: 1824/1825 1834
Name: Network Management Advice/Network Network Management Advice Response
Management Advice Repeat
Routing: Member Bank to SPAN SPAN to Member Bank
SPAN to Member Bank Member Bank to SPAN
Description: A Network Management Advice (1824) A Network Management Advice

should be used to inform banks that SPAN Response (1834) message carries the
has cutover to another business day. This answer to network management advice
message will only be sent if the Network messages.
Management Request (1804) was not
This message is to be sent in response to
responded to by the bank with a Network
either a Network Management Advice
Management Request Response (1814).
(1824) or Network Management Advice
A Network Management Advice Repeat Repeat (1825).
(1825) shall only be sent if the Network
Management Advice (1824) was not
responded to by the bank.
The bank should only receive this message
for cutover indication. A cutover is
indicated by the value “821” for the
Function Code (DE24) in the Network
Management Request (1804) message.
Action Code (DE39) in the Advice is set to
800.
Data Elements:
ISO Message Type Identifier n4 1824/5 1834
24 Function Code n3 M - 821
28 Reconciliation Date n6 M ME Dynamic
39 Action Code n3 M M Dynamic

Message Formats
2.4 ATM – Financial Messages

This section details messages related to ATM originated financial transactions that are supported by the
SPAN network. This message class permits the application of the approved transaction amount to the
cardholder’s account for billing or posting.

Message Formats
2.4.1 Financial Request/Response (ATM)

Name: Financial Request Financial Request Response
Routing: Acquirer Bank to SPAN SPAN to Acquirer Bank
SPAN to Card Issuer Bank Card Issuer Bank to SPAN
Description: A Financial Request (1200) is used by the A Financial Request Response (1210)
Acquirer Bank to seek approval for a shall be sent in response to a Financial
financial transaction from the Card Issuer Request (1200) and is used to indicate
Bank, which if approved, is immediately either approval or guarantee of funds or
applied to the cardholder’s account for the action to be taken as specified in the
billing and statement purposes. action code data element.
Data Elements:
2 Primary Account Number n..19 M ME Dynamic
3 Processing Code n6 M ME Dynamic
4 Transaction Amount n12 M M Dynamic
5 Reconciliation Amount n12 C C Dynamic
9 Reconciliation Conversion Rate n8 C CE Dynamic
16 Conversion Date n4 C CE MMDD
17 Capture Date n4 M ME MMDD
22 Point of Service Data Code an12 M ME Dynamic
23 Card Sequence Number n3 C - Dynamic
25 Message Reason Code n4 C - Dynamic
26 Card Acceptor Business Code n4 M - Dynamic
28 Reconciliation Date n6 M M Dynamic
30 Original Amounts n24 - C Dynamic
32 Acquirer Institution Identification Code n..11 M ME Dynamic
35 Track 2 Data z..37 M ME Dynamic
37 Retrieval Reference Number anp12 M ME Dynamic
38 Approval Code anp6 - C Dynamic
41 Card Acceptor Terminal Identification ans16 M ME Dynamic
43 Card Acceptor Name/Location ans..99 M ME Dynamic
48 Private Additional Data ans…999 C C Dynamic
49 Transaction Currency Code n3 M ME Dynamic
50 Reconciliation Currency Code n3 C CE Dynamic

Message Formats
Data Elements:
52 Personal Identification Number (PIN) Data b8 M - Dynamic
53 Security Related Control Information b..48 M M Dynamic
54 Additional Amounts ans…120 - C Dynamic
55 Integrated Circuit Card System Related Data b…255 C C Dynamic
59 Transport Data ans…999 C CE Dynamic
100 Receiving Institution Identification Code n..11 - M Dynamic
123 Card Scheme Information an…255 M M Dynamic
128 Message Authentication Code Field b8 M M Dynamic

Message Formats
2.4.2 Financial Transaction Advice / Advice Repeat/Response (ATM)

Message Type: 1220/1221 1230
Name: Financial Transaction Advice / Advice Financial Transaction Advice Response
Repeat
Routing: Acquirer Bank to SPAN Card Issuer Bank to SPAN
SPAN to Card Issuer Bank SPAN to Acquirer Bank
Description: A Financial Transaction Advice (1220) is A Financial Transaction Advice Response
used for : (1230) is required in response to each
Financial Transaction Advice (1220) or
• The Acquirer Bank to indicate funds to Financial Transaction Advice Repeat
be recovered from the Card Issuer (1221) message generated by SPAN.
Bank (re-presentment) for a previous
chargeback message. The original
amounts field is used by the Acquirer
Bank to indicate the original
chargeback amount (VISA SMS and
MDS).
• For adjustments and Stand-in
processing to a Card Issuer from Visa
SMS.
• For adjustments from the CPS (Claims
Processing) system.
A Financial Transaction Advice Repeat
(1221) is sent when the Bank does not reply
to the Financial Transaction Advice (1220)
in the time frames required with a Financial
Transaction Advice Response (1230).
Data Elements:

5 Reconciliation Amount n12 C CE Dynamic

Message Formats
Data Elements:
26 Card Acceptor Business Code n4 M - 6011
30 Original Amounts n24 C - Dynamic
35 Track 2 Data z..37 C CE Dynamic
38 Approval Code anp6 C CE Dynamic
46 Fee Amounts ans..204 C C Dynamic
48 Private Additional Data ans..999 C C Dynamic
55 Integrated Circuit Card System Related Data b…255 C - Dynamic
56 Original Data Elements n..35 C - Dynamic
123 Card Scheme Information an…255 C C Dynamic
Note: If the message is used for CPS adjustment messages only mandatory fields in the above format
are used, i.e. no conditional fields will be present.

Message Formats
2.5 ATM – Reversals & Chargebacks

This section details reversals and chargebacks related to ATM originated financial transactions that are
supported by the SPAN network. It is the responsibility of the Acquirer Bank to ensure a successful
completion of the transaction. If the transaction is not completed successfully, a reversal message
should be prepared and sent to SPAN to inform the network of the unsuccessful transaction and to have
the original transaction reversed.
The transaction Acquirer Bank is obliged to always send an accurate reversal message to SPAN to
avoid lost or false reversals; otherwise, the transaction Acquirer Bank will not balance with SPAN’s
Net Reconciliation Amount (field 97), which is sent as part of the online reconciliation message.
Chargebacks shall only be initiated by a card issuer when the card issuer determines that a customer
dispute exists, or that an error or a violation of rules has been committed. The message reason code
field should be utilised to indicate the reason for the chargeback.

Message Formats
2.5.1 Reversal Advice / Advice Repeat / Response (ATM)

Message Type: 1420/1421 1430
Name: Reversal Advice/Reversal Advice Repeat Reversal Advice Response
Routing: Acquirer Bank to SPAN Card Issuer Bank to SPAN
SPAN to Card Issuer Bank SPAN to Acquirer Bank
SPAN to Acquirer Bank (Visa SMS) Acquirer Bank to SPAN (Visa SMS)
Description: A Reversal Advice (1420) is used to A Reversal Advice Response (1430) is
partially or completely nullify the effects of used to acknowledge receipt of a Reversal
a previous financial or authorisation Advice (1420) or a Reversal Advice
transaction. Repeat (1421) message.
A Reversal Advice (1420) may be sent SPAN expects a Reversal Advice
from SPAN to the Acquirer Bank for Response (1430) to be returned from the
timeout cases where the Financial Request Issuer Bank carrying the answer to a
was approved. Reversal Advice (1420) or a Reversal
Advice Repeat (1421) message.
SPAN expects to receive a Reversal Advice
(1420) from the Acquirer Bank when a A Reversal Advice (1430) is expected by
transaction does not complete successfully. SPAN from the Acquirer Bank in
It is the Acquirer Bank’s responsibility to response to a Reversal Advice for timeout
inform the network of all transactions that cases where the Financial Request was
did not complete either partially or wholly. approved.
A Reversal Advice Repeat (1421) is almost SPAN will likewise return a Reversal
identical to a Reversal Advice (1420) Advice Response (1430) in response to a
message. It indicates to the receiving bank Reversal Advice (1420) or a Reversal
that it is a possible duplicate message. Advice Repeat (1421) message.
SPAN treats a Reversal Advice Repeat
(1421) message in the same way as a
Reversal Advice (1420) message and shall
be used to partially or completely nullify
the effects of a previous financial or
authorisation transaction.
Data Elements:
2 Primary Account Number n..19 M ME Echo from 1210
3 Processing Code n6 M ME Echo from 1210
4 Transaction Amount n12 M ME Dynamic
12 Local Transaction Date & Time n12 M ME Echo from 1210
16 Conversion Date n4 C CE Dynamic
17 Capture Date n4 M ME Dynamic
Message Formats
Data Elements:
23 Card Sequence Number n3 C - Echo from 1200
25 Message Reason Code n4 M - Dynamic
32 Acquirer Institution Identification Code n..11 M ME Echo from 1210
35 Track 2 Data z..37 C CE Echo from 1210
37 Retrieval Reference Number anp12 M ME Echo from 1210
38 Approval Code anp6 C - Echo from 1210
41 Card Acceptor Terminal Identification ans16 M ME Echo from 1210
43 Card Acceptor Name/Location ans..99 M ME Echo from 1210
49 Transaction Currency Code n3 M ME Echo from 1210
50 Reconciliation Currency Code n3 C CE Echo from 1210
56 Original Data Elements n..35 M - Dynamic
59 Transport Data ans…999 C CE Echo from 1210

Message Formats
2.5.2 Chargeback (Advice/Reversal)/(Advice/Reversal) Repeat / Response (ATM)

Message Type: 1422/1423 1432
Name: Chargeback Advice or Chargeback Chargeback Advice Response
Reversal/Chargeback Advice Repeat
Routing: Card Issuer Bank to SPAN Acquirer Bank to SPAN
SPAN to Acquirer Bank SPAN to Card Issuer Bank
Description: These message types relate only to Visa These message types relate only to Visa
SMS and MDS. SMS and MDS.
A Chargeback Advice (1422) message shall A Chargeback Advice Response (1432)
be used to partially or completely nullify shall be used to acknowledge receipt of a
the effects of a previous financial Chargeback Advice (1422) or a
transaction. Chargeback Advice Repeat (1423)
message.
This chargeback message shall be an advice
or notification as the activity has already SPAN expects a Chargeback Advice
occurred and should be initiated by the Response (1432) to be returned from the
Card Issuer Bank. Issuer Bank carrying the answer to a
Chargeback Advice (1422) or a
A Chargeback Advice Repeat (1423) is
Chargeback Advice Repeat (1423)
identical to a Chargeback Advice (1422)
message.
message, except that the message indicates
to the receiving bank that it is a possible SPAN will likewise return a Chargeback
duplicate message. Advice Response (1432) in response to a
SPAN treats a Chargeback Advice Repeat
message.
Chargeback Advice (1422) message and
shall be used to partially or completely
nullify the effects of a previous financial
transaction.
A Chargeback Reversal is same as
Chargeback Advice, only the function code
will be specific (value ‘490’) to show that
message is Chargeback reversal
Data Elements:

Message Formats
Data Elements:
24 Function Code n3 M - Dynamic. ‘490’ if
Charge back reversal
38 Approval Code anp6 C CE Echo from 1210
46 Fee Amounts ans..204 C C Dynamic
48 Private Additional Data ans..999 C C Dynamic

Message Formats
2.6 ATM – Reconciliation

This section contains the reconciliation advice messages that are supported by SPAN. The message
contents of the ISO based SPAN reconciliation advices are covered in the following descriptions. A
reconciliation message is used to assist settlement between financial institutions and SPAN – See also
section 2.11 on POS Reconciliation and Section 5 on Reconciliation Processing.

Message Formats
2.6.1 Acquirer Reconciliation Advice / Advice Repeat / Response (ATM)

Message Type: 1520/1521 1530
Name: Acquirer Reconciliation Advice/Acquirer Acquirer Reconciliation Advice Response
Reconciliation Advice Repeat
Routing: SPAN to Card Issuer Bank Card Issuer Bank to SPAN
Description: In order to perform a valid reconciliation, This response provides confirmation of
confirmation of acquirer totals (number and SPAN's acquirer totals for SPAN’s
value) corresponding to SPAN’s acquirer previous business day. The Card Issuer
relationship for its previous business day Bank must always send an Acquirer
are required. Reconciliation Advice Response (1530)
to SPAN upon receipt of an Acquirer
An Acquirer Reconciliation Advice (1520)
Reconciliation Advice (1520). Failure to
message shall be utilised by SPAN to
do so will result in the continued
provide totals that reflect the bank’s current
forwarding of the Acquirer Reconciliation
position for the previous business day as
Advice Repeat (1521) message from
determined by the last network
SPAN.
management cutover message (Network
Management Request (1804), Network When formatted by the Card Issuer Bank,
Management Advice (1824) or Network the Acquirer Reconciliation Advice
Management Advice Repeat (1825)) from Response (1530) message contains the
SPAN to the Card Issuer Bank. response code indicating agreement of
SPAN and Card Issuer Bank's settlement
An Acquirer Reconciliation Advice Repeat
totals for the previous business day. The
(1521) message shall be used in the event
Card Issuer Bank must log the totals sent
that an Acquirer Reconciliation Advice
from SPAN and any variance that might
Response (1530) response was not received
be included in the Acquirer
from the Issuer Bank within the pre-defined
Reconciliation Advice Response (1530)
time interval allowed for the Issuer Bank to
message for reconciliation purposes.
process the original an Acquirer
Reconciliation Advice (1520) message. The message should contain totals from
the Card Issuer Bank indicating the
This Acquirer Reconciliation Advice
settlement amounts that the Card Issuer
Repeat (1521) message contains the totals
Bank calculated to be correct whenever a
that reflect the bank’s current position (as
discrepancy in the totals provided from
seen by SPAN) for the previous business
SPAN in the Acquirer Reconciliation
day as determined by the last cutover
Advice (1520) or Acquirer Reconciliation
message.
Advice Repeat (1521) message is
identified.
Data Elements:

Message Formats
Data Elements:
32 Acquirer Institution Identification Code n..11 M ME 123456789 (SAMA)
50 Reconciliation Currency Code n3 M ME Dynamic
74 Number Credits n10 M C Computed
75 Reversal Number Credits n10 M C Computed
76 Number Debits n10 M C Computed
77 Reversal Number Debits n10 M C Computed
80 Number Inquiries n10 M C Computed
86 Amount Credits n16 M C Computed
87 Reversal Amount Credits n16 M C Computed
88 Amount Debits n16 M C Computed
89 Reversal Amount Debits n16 M C Computed
97 Net Reconciliation Amount x+n16 M M Computed
105 Chargeback Amount Credits n16 M C Computed
106 Chargeback Amount Debits n16 M C Computed
107 Chargeback Number Credits n10 M C Computed
108 Chargeback Number Debits n10 M C Computed
126 Bank Card Scheme Totals Information n…999 M C Computed

Message Formats
2.6.2 Card Issuer Reconciliation Advice / Advice Repeat / Response (ATM)

Message Type: 1522/1523 1532
Name: Card Issuer Reconciliation Advice/Card Card Issuer Reconciliation Advice
Issuer Reconciliation Advice Repeat Response
Routing: SPAN to Acquirer Bank Acquirer Bank to SPAN
Description: In order to perform a valid reconciliation, This response provides confirmation of
confirmation of issuer totals (number and SPAN's issuer totals for SPAN’s previous
value) corresponding to SPAN’s issuer business day. The Acquirer Bank must
relationship for its previous business day always send a Card Issuer Reconciliation
are required. Advice Response (1532) to SPAN upon
receipt of a Card Issuer Reconciliation
A Card Issuer Reconciliation Advice (1522)
Advice (1522). Failure to do so will result
in the continued forwarding of the Card
Issuer Reconciliation Advice Repeat
position (as seen by SPAN) for the previous
(1523) message from SPAN.
business day as determined by the last
network management cutover message When formatted by the Acquirer Bank,
(Network Management Request (1804), the Card Issuer Reconciliation Advice
Network Management Advice (1824) or Response (1532) message contains the
Network Management Advice Repeat response code indicating agreement of
(1825)) from SPAN to the Acquirer Bank. SPAN and Acquirer Bank's settlement
A Card Issuer Reconciliation Advice
Acquirer Bank must log the totals sent
Repeat (1523) message shall be used in the
from SPAN and any variance that might
event that a Card Issuer Reconciliation
be included in the Card Issuer
Advice Response (1532) response was not
received from the Issuer Bank within the
pre-defined time interval allowed for the
Acquirer Bank to process the original a The message should contain totals from
Card Issuer Reconciliation Advice (1522) the Acquirer Bank indicating the
message. settlement amounts that the Acquirer
Bank calculated to be correct whenever a
This Card Issuer Reconciliation Advice
discrepancy in the totals provided from
Repeat (1523) message contains the totals
SPAN in the Card Issuer Reconciliation
that reflect the bank’s current position (as
Advice (1522) or Card Issuer
seen by SPAN) for the previous business
Reconciliation Advice Repeat (1523)
day as determined by the last cutover
message is identified.
message.
Data Elements:
Message Formats
Data Elements:
50 Reconciliation Currency Code n3 M ME Dynamic

Message Formats
2.7 ATM – Administrative Message

This section contains the Administrative messages that are supported by SPAN system. The message
contents are covered in the following descriptions.

Message Formats
2.7.1 Administrative Advice / Response (ATM)

Name: Administrative Advice Administrative Advice Response
Description: An Administrative Advice (1624) is used to An Administrative Advice Response
provide information regarding a card (1634) is used to respond to an
capture to the Visa SMS Switch. Administrative Advice (1624).
Data Elements:
72 Data Record ans…999 M - Dynamic
As an exception to ISO8583:1993 this field can also accept binary data.

Message Formats
2.7.2 Administrative Notification (ATM)

Message Type: 1644
Name: Administrative Notification
Routing: Member Bank to SPAN
SPAN to Member Bank
Description: An Administrative Notification (1644) is used to notify the message
originator that the message sent has been rejected.
Response: None.
Data Elements:
Pos’n Data Element Attr Req Value
* Message Header an12 * Dynamic
ISO Message Type Identifier n4 1644
ISO Primary Bitmap an16 M Dynamic
1 Secondary Bitmap an16 M Dynamic
7 Transmission Date & Time n10 M MMDDhhmmss
11 Systems Trace Audit Number n6 M Dynamic
12 Local Transaction Date & Time n12 M Dynamic
24 Function Code n3 M Dynamic
39 Action Code n3 M Dynamic
1
72 Data Record ans …999 M Dynamic
93 Transaction Destination Institution ID Code n..11 M Dynamic
94 Transaction Originator Institution ID Code n..11 M Dynamic
1
As an exception to ISO 8583:1993, this field can also accept binary data.
Message Formats
2.7.3 Fraud Advice / Response (Visa SMS)

Name: Fraud Advice Fraud Advice Response
Card Issuer Bank to SPAN SPAN to Card issuer Bank
Description: The Fraud Advice (9620) message is part of A Fraud Advice Response (9630) is used
the VISA SMS Online Fraud Reporting to respond to a Fraud Advice (9620)
capability and is required to be supported message.
by acquirers and issuers. This mechanism
allows certified members to report fraud
transactions to the Fraud Reporting System
(FRS) using online messages. Online Fraud
Reporting is not available for Plus
messages.
VISA SMS passes the fraud advices to
FRS. The fraud transactions are reported to
members on the FRS reports. Failure to
comply with the fraud reporting rules as
defined in the Visa Operating Regulations
can result in the loss of chargeback rights
and in potential fines and penalties.
This is included for completeness. It is
believed that this is not currently
operational.
DE22 and DE38 are conditionally present
in the message because they are optional
fields in the message to Visa SMS, so can
be supplied if available.
Data Elements:
2 Primary Account Number n..19 M M Dynamic
4 Transaction Amount n12 C - Dynamic
14 Expiration Date n4 C - Dynamic
22 Point of Service Data Code an12 C - Dynamic
26 Card Acceptor Business Code n4 C - 6011

Message Formats
Data Elements:
32 Acquirer Institution Identification Code n..11 M CE Dynamic
37 Retrieval Reference Number anp12 C CE Dynamic
38 Approval Code anp6 C - Dynamic
41 Card Acceptor Terminal Identification ans16 C - Dynamic
43 Card Acceptor Name/Location ans..99 C - Dynamic
49 Transaction Currency Code n3 M - Dynamic
72 Data Record ans…999 M - Dynamic

Message Formats
2.8 POS – Authorisation Transactions

This section contains messages related to POS originated authorisation transactions that are supported
by the SPAN network. Authorisation transactions are used within the network to request authorisation
for financial requests. These messages are also used when an EMV chip card requires on-line
authorisation. In these cases the Authorisation transaction, if approved, is likely to be followed by a
Financial Advice.
The following descriptions pertain to the message content of the ISO authorisation transactions.

Message Formats
2.8.1 Authorisation Request/Response (POS)

Name: Authorisation Request Authorisation Request Response
Description: An Authorisation Request (1100) message An Authorisation Request Response
is sent to seek approval or guarantee of (1110) shall be sent by the Card Issuer
funds from the Card Issuer Bank. They are Bank in response to an Authorisation
used for: Request (1100). The message should
indicate the approval (guarantee of funds)
• Pre-authorisation on credit cards or the action to be taken as specified in
(magnetic stripe or chip) the action code data element.
• On-line authorisation for chip cards This response does not permit the
(SPAN or IBCS cards). application of the approved transaction
Authorisation messages are not intended to amount to the cardholder’s account for
permit the application of the approved billing or posting.
transaction amount to the cardholder’s
account for billing or posting.
When used for pre-authorisation, the pre-
authorised amount can optionally be held
against the account until a pre-authorization
completion (purchase Advice) occurs or the
pre-authorisation retention period expires.
Data Elements:
14 Expiration Date n4 C CE Dynamic

Message Formats
Data Elements:
42 Card Acceptor Identification Code ans15 M ME Dynamic
47 Nat. Addn Data – Card Accpt Name (Arabic) ans…999 C CE Dynamic
48 Private Additional Data ans..999 - C Dynamic
52 Personal Identification Number (PIN) Data b8 C - Dynamic
54 Additional Amounts ans…120 C - Dynamic
56 Original Data Elements n..35 C CE Dynamic
60 POS Terminal Data ans…999 M ME Dynamic
122 Card Scheme Sponsor ID/Card Scheme ID an…999 M ME Dynamic

Message Formats
2.8.2 Authorisation Advice / Advice Repeat / Response (POS)

Message Type: 1120/1121 1130
Name: Authorisation Advice / Advice Repeat Authorisation Advice Response
Routing: SPAN to Retailer/Acquirer Bank Retailer/Acquirer Bank to SPAN
Description: An Authorisation Advice (1120) is used to An Authorisation Advice Response

inform: (1130) is required in response to each
Authorisation Advice (1120) or
 Retailer Bank of the result of all
Authorisation Advice Repeat (1121)
Authorisation transactions (online chip
message generated by SPAN.
card) occurring at SPAN POS’s at the
Retailers sponsored by the Retailer
Bank..
An Authorisation Advice Repeat (1121) is
sent when the Bank does not reply to the
Authorisation Advice (1120) in the time
frames required by an Authorisation
Advice Response (1130).
Data Elements:
14 Expiration Date n4 C CE YYMM

Message Formats
Data Elements:
38 Approval Code anp6 C CE Dynamic
47 Nat. Addn Data – Card Accpt Name (Arabic) ans..999 C CE Dynamic
54 Additional Amounts ans…120 C - Dynamic*
100 Receiving Institution Identification Code n..11 M ME Dynamic
123 Card Scheme Information an…255 C - Dynamic

Message Formats
2.9 POS – Financial Transactions

This section contains messages related to POS originated financial transactions that are supported by
SPAN network. Financial transactions are used within the network to request authorisation and
approval for financial requests. The following descriptions pertain to the message content of the ISO
financial transactions.

Message Formats
2.9.1 Financial Request/Response (POS)

Name: Financial Request Financial Request Response
Description: A Financial Request (1200) is used to seek A Financial Request Response (1210)
approval for a financial transaction from the shall be send by the Card issuer in
Card Issuer Bank, which if approved, is response to a Financial Request (1200).
immediately applied to the Cardholder’s The message should indicate approval
account for billing and statement purposes. (guarantee of funds) or the action to be
taken as specified in the Action Code.
Data Elements:
48 Private Additional Data ans..999 - C Dynamic

Message Formats
Data Elements:
52 Personal Identification Number (PIN) Data b8 C - Dynamic
54 Additional Amounts ans…120 C CE Dynamic

Message Formats
2.9.2 Financial Transaction Advice / Advice Repeat / Response (POS)

Message Type: 1220/1221 1230
Name: Financial Transaction Advice / Advice Financial Transaction Advice Response
Repeat
SPAN to Retailer Bank Retailer Bank to SPAN
SPAN to International Card Scheme International Card Scheme Acquirer Bank
Acquirer Bank to SPAN
Acquirer Bank to SPAN SPAN to Acquirer Bank
Description: A Financial Transaction Advice (1220) is A Financial Transaction Advice Response
used to inform: (1230) is required in response to each
Financial Transaction Advice (1220) or
 Card Issuer Bank of the result of a
Financial Transaction Advice Repeat
cardholder transaction authorised by
(1221) message generated by SPAN.
SPAN POS terminal in offline mode.
 Retailer Bank of the result of all
financial transactions (online and
offline) occurring at SPAN POS’s at
the Retailers sponsored by the Retailer
Bank.
 Retailer Bank and Card Issuer Bank
the completion of a previously
authorised transaction.
 Card Issuer Bank and Retailer Bank of
a CPS (Claims Processing System)
adjustment.
 Card Issuer Bank of funds to be
recovered (re-presentment) for a
previous chargeback message. The
original amounts field is used by the
Acquirer Bank to indicate the original
chargeback amount (MDS).
A Financial Transaction Advice Repeat
(1221) is sent when the Bank does not reply
to the Financial Transaction Advice (1220)
in the time frames required with a Financial
Transaction Advice Response (1230).
Data Elements:
2 Primary Account Number n..19 M ME Dynamic*
3 Processing Code n6 M ME Dynamic*
4 Transaction Amount n12 M M Dynamic*

Message Formats
Data Elements:
5 Reconciliation Amount n12 C CE Dynamic*
12 Local Transaction Date & Time n12 M ME Dynamic*
14 Expiration Date n4 C CE YYMM
22 Point of Service Data Code an12 M ME Dynamic*
26 Card Acceptor Business Code n4 M - Dynamic*
30 Original Amounts n24 C C Dynamic
32 Acquirer Institution Identification Code n..11 M ME Dynamic*
35 Track 2 Data z..37 C CE Dynamic*
37 Retrieval Reference Number anp12 M ME Dynamic*
38 Approval Code anp6 C CE Dynamic*
49 Transaction Currency Code n3 M ME Dynamic*
50 Reconciliation Currency Code n3 C CE Dynamic*
54 Additional Amounts ans…120 C CE Dynamic*
59 Transport Data ans…999 C CE Dynamic*
60 POS Terminal Data ans…999 M ME Dynamic*
122 Card Scheme Sponsor ID/Card Scheme ID an…999 M ME Dynamic*
123 Card Scheme Information an…255 C - Dynamic*
Note: The uses of the above message dictate the value of the fields marked with an asterisk.
• If the message is used for debit transactions as completion for a previously approved authorisation
request or for online transactions to either retailer or card scheme acquirer banks then the values
are echoed from the 1210.
• If the message is used for offline transactions the values are dynamic.
Note: If the message is used for CPS adjustment messages only mandatory fields in the above
format are used, i.e. no conditional fields will be present.
Note: The contents of DE 55 are issuer defined.

Message Formats
2.10 POS – Reversals & Chargebacks

This section contains reversal messages that are related to POS originated financial and authorisation
messages supported by SPAN network.
Reversals at SPAN POS terminals can occur for a number of reasons:
• When a System Error occurs
• When SPAN is unable to deliver the transaction response to the terminal and the transaction
does not complete, such as a time out due to a communications problem
• Customer cancellation
• Failure to generate second cryptogram .
In the cases above, the SPAN POS terminal sends the reversal to SPAN, and then SPAN sends a
reversal to both the Card Issuer Bank and the Retailer Bank (See the SPAN Terminal Interface
specification for details of terminal reversal scenarios).
SPAN can also generate reversals in timeout and late response exceptions to card issuers and card
scheme networks depending on their operating rules. See section 4.2.1 for more information about
reversals.

Message Formats
2.10.1 Reversal Advice / Advice Repeat / Response (POS)

Message Type: 1420/1421 1430
Name: Reversal Advice/Reversal Advice Repeat Reversal Advice Response
SPAN to Retailer Bank Retailer Bank to SPAN
SPAN to International Card Scheme International Card Scheme Acquirer Bank
Acquirer Bank to SPAN
Description: A Reversal Advice (1420) shall be used to A Reversal Advice Response (1430) shall
nullify the effects of a previous financial or be sent in response to the original
authorisation transaction. Reversal Advice (1420) or Reversal
Advice Repeat (1421) message request.
SPAN expects to receive a Reversal Advice
(1420) from the POS terminal when a The Member Bank needs to respond to
transaction does not complete successfully. the advice message from SPAN by
It is then SPAN’s responsibility to inform sending a Reversal Advice Response
the banks involved that the transaction did (1430) message. If such a response is not
not complete. received, SPAN will repeatedly send a
Reversal Advice Repeat (1421) message.
The Member Bank needs to respond to the
advice message from SPAN by sending a
Reversal Advice Response (1430) message.
If such a response is not received, SPAN
will repeatedly send a Reversal Advice
Repeat (1421) message.
Data Elements:
2 Primary Account Number n..19 M ME Echo from 1210
3 Processing Code n6 M ME Echo from 1210
4 Transaction Amount n12 M ME Echo from 1210
5 Reconciliation Amount n12 C CE Echo from 1210
9 Reconciliation Conversion Rate n8 C CE Echo from 1210
12 Local Transaction Date & Time n12 M ME Echo from 1210
14 Expiration Date n4 C CE Echo from 1210
16 Conversion Date n4 C CE Echo from 1210
22 Point of Service Data Code an12 M ME Echo from 1210
26 Card Acceptor Business Code n4 M - Echo from 1200
28 Reconciliation Date n6 M ME Echo from 1210

Message Formats
Data Elements:
32 Acquirer Institution Identification Code n..11 M ME Echo from 1210
35 Track 2 Data z..37 C CE Echo from 1210
38 Approval Code anp6 C - Echo from 1210
42 Card Acceptor Identification Code ans15 M ME Echo from 1210
47 Nat. Addn Data – Card Accpt Name (Arabic) ans…999 C CE Echo from 1210
54 Additional Amounts ans..120 C CE Echo from 1210
56 Original Data Elements n..35 M ME Dynamic
60 POS Terminal Data ans…999 M ME Echo from 1210
122 Card Scheme Sponsor ID/Card Scheme ID an…999 M ME Echo from 1210
123 Card Scheme Information an…255 C - Dynamic

Message Formats
2.10.2 Chargeback (Advice/Reversal)/(Advice/Reversal) Repeat / Response (POS)

Message Type: 1422/1423 1432
Name: Chargeback Advice or Chargeback Chargeback Advice Response
Reversal/Chargeback Advice Repeat
Routing: Card Issuer Bank to SPAN Acquirer Bank to SPAN
SPAN to Acquirer Bank SPAN to Card Issuer Bank
Description: These message types relate only to MDS. These message types relate only to MDS.
A Chargeback Advice (1422) message shall A Chargeback Advice Response (1432)
be used to partially or completely nullify shall be used to acknowledge receipt of a
the effects of a previous financial Chargeback Advice (1422) or a
transaction. Chargeback Advice Repeat (1423)
message.
This chargeback message shall be an advice
or notification as the activity has already SPAN expects a Chargeback Advice
occurred and should be initiated by the Response (1432) to be returned from the
Card Issuer Bank. Issuer Bank carrying the answer to a
A Chargeback Advice Repeat (1423) is
identical to a Chargeback Advice (1422)
message.
message, except that the message indicates
to the receiving bank that it is a possible SPAN will likewise return a Chargeback
duplicate message. Advice Response (1432) in response to a
SPAN treats a Chargeback Advice Repeat
message.
Chargeback Advice (1422) message and
shall be used to partially or completely
nullify the effects of a previous financial
transaction.
A Chargeback Reversal is same as
Chargeback Advice, only the function code
will be specific (value ‘490’) to show that
message is Chargeback reversal
Data Elements:
Message Formats
Data Elements:
24 Function Code n3 M - Dynamic. ‘490’ if
Charge back reversal
38 Approval Code anp6 C CE Echo from 1210
42 Card Acceptor Identification Code ans15 M ME Echo from 1210
60 POS Terminal Data ans…999 M ME Echo from 1210
122 Card Scheme Sponsor ID/Card Scheme ID an…999 M ME Echo from 1210

Message Formats
2.11 POS – Reconciliation

This section contains the messages relating to POS originated reconciliation advice messages that are
supported by the SPAN network. The message contents of the SPAN POS reconciliation advices are
covered in the following descriptions. A reconciliation message is used to compare financial totals
accumulated by SPAN with those accumulated by acquirers.

Message Formats
2.11.1 Acquirer Reconciliation Advice / Advice Repeat / Response (POS)

Message Type: 1520/1521 1530
Name: Acquirer Reconciliation Advice/Acquirer Acquirer Reconciliation Advice Response
Reconciliation Advice Repeat
Description: In order to perform a valid reconciliation, An Acquirer Reconciliation Advice
confirmation of acquirer totals (number and Response (1530) provides confirmation of
value) corresponding to SPAN’s acquirer SPAN's acquirer totals for the SPAN's
relationship for its previous business day previous business day. This message is
are required. forwarded after the Card Issuer Bank
receives a Card Acquirer Reconciliation
An Acquirer Reconciliation Advice (1520)
Advice (1520) or Card Acquirer
Reconciliation Advice Repeat (1521)
message from SPAN.
position for the previous business day as
determined by the last network When formatted by the Card Issuer Bank,
management cutover message (Network the Acquirer Reconciliation Advice
Management Request (1804), Network Response (1530) message contains the
Management Advice (1824) or Network response code indicating agreement of
Management Advice Repeat (1825)) from SPAN and Card Issuer Bank settlement
SPAN to the Card Issuer Bank. totals for the previous business day. The
bank should also maintain a record of the
An Acquirer Reconciliation Advice Repeat
totals sent from SPAN and any variance
(1521) message shall be used in the event
that might be included in the Acquirer
that an Acquirer Reconciliation Advice
Response (1530) response was not received
from the Issuer Bank within the pre-defined
time interval allowed for the Issuer Bank to In the event that a discrepancy in the
process the original an Acquirer totals provided from SPAN in the Card
Reconciliation Advice (1520) message. Acquirer Reconciliation Advice (1520) or
Card Acquirer Reconciliation Advice
Repeat (1521) message is identified, the
Acquirer Reconciliation Advice Response
(1530) message should contain totals
from the Card Issuer Bank indicating that
the settlement amounts that the Bank
calculated to be correct
Data Elements:
28 Reconciliation Date n6 M ME YYMMDD
32 Acquirer Institution Identification Code n..11 M ME 123456789 (SAMA)

Message Formats
Data Elements:
50 Reconciliation Currency Code n3 M ME 682
81 Number Authorisations n10 M C Computed

Message Formats
2.11.2 Card Issuer Reconciliation Advice / Advice Repeat / Response (POS)

Message Type: 1522/1523 1532
Name: Card Issuer Reconciliation Advice/ Card Card Issuer Reconciliation Advice
Issuer Reconciliation Advice Repeat Response
Routing: SPAN to Retailer Bank Retailer Bank to SPAN
Description: A Card Issuer Reconciliation Advice (1522) A Card Issuer Reconciliation Advice
provides confirmation of SPAN issuer Response (1532) message shall be
totals (number and value) corresponding to formatted by the Retailer Bank to include
SPAN's issuer relationship for its previous the response code indicating agreement of
business day. the SPAN and Issuer Bank settlement
When formatted by SPAN, the Card Issuer
Bank should maintain their own log of the
Reconciliation Advice (1522) message
totals sent from SPAN and any variance
contains totals that reflect the previous
that might be included in the Card Issuer
business day's bank position (as seen by
SPAN) as determined by the last Network
Management Cutover message (Network
Management Request (1804), Network A Card Issuer Reconciliation Advice
Management Advice (1824) or Network Response (1532) message shall be sent by
Management Advice Repeat (1825) the Retailer Bank in response to either a
message) from SPAN to the Retailer Bank. Card Issuer Reconciliation Advice (1522)
or Card Issuer Reconciliation Advice
A Card Issuer Reconciliation Advice
Repeat (1523) message from SPAN. The
Repeat (1523) is identical to a Card Issuer
Retailer Bank must always send a Card
Reconciliation Advice (1522) message
Issuer Reconciliation Advice Response
except that the message type indicates that
(1532) message even if a discrepancy in
is a repeat message. This message will be
the totals exists. In such cases the
sent in the event that no response is
message should also contain the totals
received once Card Issuer Reconciliation
from the Retailer Bank indicating the
Advice (1522) message.
settlement amounts that the Bank
calculated to be correct.
Data Elements:
ISO Primary Bitmap an16 M ME Dynamic
1 Secondary Bitmap an16 M ME Dynamic

Message Formats
Data Elements:
81 Number Authorisations n10 M C Computed

Message Formats
2.11.3 Terminal Reconciliation Advice (POS)

Message Type: 1524/1525 1534
Name: Terminal Reconciliation Advice/ Terminal Terminal Reconciliation Advice
Reconciliation Advice Repeat Response
Routing: SPAN to Retailer Bank Retailer Bank to SPAN
Description: A Terminal Reconciliation Advice (1524) is A Terminal Reconciliation Advice
used to inform the Retailer Bank of the Response (1534) is required in response
result of a terminal reconciliation by SPAN to each Terminal Reconciliation Advice
POS terminals where the POS device is (1524) or Terminal Reconciliation Advice
directly connected to SPAN. Repeat (1525) message generated by
SPAN.
This message is normally triggered by the
receipt of a Terminal 1524 Reconciliation
Advice from the POS. Alternatively, it can
be triggered manually by the Retailer Bank
(see section 5.5.7).
A Terminal Reconciliation Advice Repeat
(1525) is sent when the Retailer Bank does
not reply to the Terminal Reconciliation
Advice (1524) in the time frames required.
Data Elements:
62 Private Field – Terminal Status ans..99 C - Dynamic
124 SPAN POS Terminal Reconcile Total an…999 C CE Dynamic

127 SPAN POS SPAN Reconcile Total an…999 C CE Dynamic

Message Formats
2.12 POS – Administrative Message

This section contains the Administrative messages that are supported by the SPAN system.
An administrative message is used to convey information from the following,
• SPAN to Member Banks relating to rejected messages.
• Member Banks to SPAN relating to rejected messages.
Administrative messages are also used in relation to fraud advices.

Message Formats
2.12.1 Administrative Notification (POS)

Message Type: 1644
Name: Administrative Notification
Routing: SPAN to Member Bank
Member Bank to SPAN
Description: An Administrative Notification (1644) is used to convey warnings and
other information to SPAN participants. This message consists of free-
form text.
An Administrative Notification (1644) is used to notify the message
originator that the transaction sent has been rejected.
Response: None.
Data Elements:
Pos’n Data Element Attr Req Value
* Message Header an12 * Dynamic
ISO Message Type Identifier n4 1644
ISO Primary Bitmap an16 M Dynamic
1 Secondary Bitmap an16 M Dynamic
7 Transmission Date & Time n10 M Dynamic
11 Systems Trace Audit Number n6 M Dynamic
12 Local Transaction Date & Time n12 M Dynamic
24 Function Code n3 M Dynamic
28 Reconciliation Date n6 M Dynamic
39 Action Code n3 M Dynamic
72 Data Record ans 2…999 M Dynamic
93 Transaction Destination Institution ID Code n..11 M Dynamic
94 Transaction Originator Institution ID Code n..11 M Dynamic
2
As an exception to ISO8583:1993 this field can also accept binary data.
Field Descriptions
Section 3 Field Descriptions
This section provides a list of fields used in SPAN messages and a description of their definition.
3.1 SPAN External Message

The SPAN external messages are based on the standard message format ISO8583:1993 produced by
the International Standards Organisation (ISO). It is a variable-length, variable-content message that is
based upon the type of message being sent.
The SPAN interface creates and interprets external messages according to the specifications in this
document. Throughout this section, "incoming" refers to messages being received by SPAN, and
"outgoing" refers to messages being sent by SPAN.
3.2 Message Structure

The SPAN external message is made up of the following elements
• Message Type Identifier
• Primary and Secondary Bit Maps
• Data Elements
Some of the components of the data elements are mandatory, others are conditional.
3.3 Message Components

3.3.1 SPAN Header
The SPAN message header is provided to enhance the routing and error determination requirements of
the SPAN network messages. Various message versions are supported that provide a means for future
enhancements to the SPAN network. The SPAN message header consists of two separate headers:
SPAN ATM message header and SPAN POS message header. A field in the front of the header
indicates that the message is an "ISO" format. A version number is provided to allow for the definition
and interpretation of varied message requirements as may be necessary in the future expansion of the
network. This feature in particular will allow the SPAN network to handle multiple message formats
during future migration efforts to implement new services and processing requirements as needed.
The SPAN message header provides a mechanism for identifying and handling message format errors
that the ISO standard does not address.
An additional field in the header provides error information that can be passed back to the forwarding
system in the event that a field in the message cannot be interpreted. The status field will provide the
ISO 8583 element number that was in error so that network managers can identify what processing in
their system is causing the error.
The following fields are represented in the SPAN ATM and SPAN POS message headers:
Position Data Element Length Values
01-03 Start of Message Indicator 3 ISO
00 – Base
04-05 Network Product Indicator 2 00 – ATM
04 – POS
06-07 Network Release Number 2 40
08-10 Message Status 3 Dynamic

Field Descriptions
11 Transaction Originator Institution ID Code 1 0

12 Transaction Responder Institution ID Code 1 0
Table 3-1 SPAN Header
The following table represents the usage of the SPAN Header Network Product Indicator and its
relationship to the Network Management Messages:
Message Type Network Product Indicator Function Code
801 Logon
802 Logoff
1804 00 – Base
811 Key update
831 Echotest
1804 00 – ATM 821 Cutover
1804 04 – POS 821 Cutover
1814 Echoes 1804 Echoes 1804
1824, 1825 00 – ATM 821 Cutover
1824, 1825 04 – POS 821 Cutover
1834 Echoes 1824 or 1825 Echoes 1824 or 1825
Table 3-2 Network Product Indicator use in Network Management messages
The Bank must provide a mechanism to receive and format each field in the SPAN header.
Message Type Network Product Indicator
1100, 1110 04 – POS
1120,1121,1131 04 – POS
1200, 1210 00 – ATM, 04 – POS
1220, 1221, 1230 00 – ATM, 04 – POS
1420, 1421, 1430 00 – ATM, 04 – POS
1422, 1423, 1432 00 – ATM
1520, 1521, 1530 00 – ATM, 04 – POS
1522, 1523, 1532 00 – ATM, 04 – POS
1524, 1525, 1534 04 – POS
1624, 1634, 1644 00 – ATM, 04 – POS, 99 – Unspecified
9620, 9630 00-ATM
Table 3-3 Valid Network Product Indicators by Message Type
3.3.2 Message Type Identifier

The Message Type Identifier (MTI) is a four-digit code identifying the general function of the message.
It is required in all messages.
The MTI field is a four digit numerical element used to identify the following,

Field Descriptions
• Position 1 – Version number

o 0 – ISO 8583:1987
o 1 – ISO 8583:1993
o 2-7 – Reserved for ISO use
o 8 – Reserved for national use
o 9 – Reserved for private use
• Position 2 – Message class
o 0 – Reserved for ISO use
o 1 – Authorisation
o 2 – Financial
o 3 – File action
o 4 – Reversal/Chargeback
o 5 – Reconciliation
o 6 – Administration
o 7 – Fee collection
o 8 – Network management
o 9 – Reserved for ISO use
• Position 3 – Message function
o 0 – Request
o 1 – Request response
o 2 – Advice
o 3 – Advice response
o 4 – Notification
• Position 4 – Transaction originator
o 0 – Acquirer
o 1 – Acquirer repeat
o 2 – Card issuer
o 3 – Card issuer repeat
o 4 – Other
o 5 – Other repeat
See section 2.2.2 for a list of supported message types.

Field Descriptions
3.3.3 Primary and Secondary Bit Maps

The Primary Bit Map is a 16 byte hexadecimal field required in all messages, representing 64 bits of
data which identify the presence (denoted by 1 or "bit on") or absence (denoted by 0 or "bit off") of the
first 64 data elements in the message.
The Secondary Bit Map is also a 16 byte hexadecimal field conditional in all messages. It is similar to
the Primary Bit Map except it denotes the presence or absence of the second 64 data elements in the
message.
The following illustrates how 64 bits are converted to 16 byte hexadecimal field for placement in the
SPAN External Message. Bits are numbered from left to right, starting with 1.
0010001000011010010000110000000000000101001000110110111110111101
2 2 1 A 4 3 0 0 0 5 2 3 6 F B D
In the above example, the bit map field would contain the characters 22lA430005236FBD.
The SPAN External Message uses two bit maps: the Primary Bit Map and the Secondary Bit Map. The
Primary Bit Map controls the presence or absence of data elements 1 through 64. The Secondary Bit
Map controls the presence or absence of data elements 65 through 128. The Primary Bit Map precedes
the data elements in a message. The Secondary Bit Map is itself a data element and its existence is
controlled by BIT 01 in the Primary Bit Map. When present, it immediately follows the Primary Bit
Map.
3.3.4 Data Elements

The SPAN External Message is designed to allow for the transmission of all 128 data elements that are
a part of the ISO 8583 standard. However, not all of these data elements are used for processing by
SPAN. Typically only a subset of the total data elements are required.
A primary advantage of the SPAN External Message is that a data element need not be included in the
message if it is not needed for processing.
SPAN has a standard set of bit maps that it uses for determining which of the 128 data elements are to
be included in each message. These defaults are established to provide SPAN with the standard data
elements it needs for processing transactions.

Field Descriptions
3.3.5 Format for the Data Elements

The data elements used in the SPAN External Message are described in detail in the following pages. A
following standard format has been used for describing these data elements.
Position – States the position of the data element in the message.
Name – States the name of the data element.
Representation - States the attributes for the data element. The values used to represent the attributes
are based on the following ISO 8583 standards:
A Alphabetic characters, A through to Z and a through to z.
B Binary representation of data
N Numeric characters, 0 through to 9
S Special characters
AN Alphabetic and numeric characters
AS Alphabetic and special characters
NS Numeric and special characters
ANS Alphabetic, numeric and special characters
Z Tracks 2 and 3 code set as defined in ISO 4909 and ISO 7813, but expanded to ASCII
characters with ‘=’ used for the field separator.
All character data is US-ASCII unless otherwise noted.
For fixed-length fields, the above characters are followed by the number of characters in the field (i.e.,
N 20 indicates that the field is a fixed-length numeric field that is 20 numeric characters long).
In the case of variable-length fields, the above characters are followed by two or three periods and the
maximum number of characters that can be carried in the field (i.e., AN..10 indicates that the field is a
variable-length and can consist of alphabetic and numeric characters up to a maximum length of 10
characters). See section 3.3.8 for a definition of variable length data elements.
"X+" is used with some amounts to indicate they must be preceded by a capital "C" if the amount is a
credit, or a capital "D" if the amount is a debit. Note that this adds one to the given length of the field.
Date and time formats are shown using the following values:
YY Year, 00 through to 99
MM Month, 01 through to 12
DD Day, 01 through to 31
hh Hour, 00 through to 23
mm Minute, 00 through 59
ss Second, 00 through 59
Used by – Specifies the SPAN messages that utilises the data element.
Description – Describes how the data element is used. General information concerning the data
element, which is the same for all SPAN functions.
3.3.6 Data Element Structures

The following paragraphs describe how data elements in the SPAN External Message must be
structured. These guidelines are followed by SPAN and must be adhered to by banks sending
messages to SPAN.
All data elements are counted from left to right, i.e., the leftmost position is number 1.

Field Descriptions
3.3.7 Fixed-Length Data Elements

All fixed length numeric data elements must be right justified, with leading zeros. Data placed in all
other fixed-length data elements must be left justified, with trailing blanks. In all “B” data, blocks of 8
bits are assumed to be left justified with trailing zeroes.
3.3.8 Variable-Length Data Elements

Data placed in variable-length data elements can vary in length from zero positions up to the individual
maximum length stated for the data element. The actual length of the data placed in a variable-length
data element must always be specified in a fixed-length prefix immediately preceding the data.
For variable-length data elements with an ISO 8583 defined maximum length of less than 100
characters, a two-byte prefix containing the length of the data in the field must precede the data
element. For variable-length data elements with an ISO 8583 defined maximum length greater than 99
and less than 1,000 characters, a three byte prefix containing the length of the data in the field must
precede the data element.
These prefixes must be right justified character data and zero filled. For example, if a variable-length
data element can be up to 200 characters, but only seven characters are to be loaded into the element,
the required fixed-length prefix is 007. If the seven characters wereA1C2E3G, the entire data element
to be included in the external message would be 0071234567 (a total of ten positions). If the data
element is limited to a maximum of less than 100 characters, the fixed-length prefix is 07, and the
entire data element is 07A1C2E3G (a total of nine bytes).

Field Descriptions
3.4 Data Elements (DE)

The following pages contain descriptions of the data elements of the SPAN external message format,
sequenced by their bit map positions.
3.4.1 DE 1 – Secondary Bit Map

Position: 1
Name: Secondary Bit Map
Representation: AN 16
Used By: The following provides a list of the messages that contain this data
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1430, 1422, 1423, 1432, 1520,
1521, 1522, 1523, 1530, 1532, 1624, 1534, 1644, 1804, 1814, 1824, 1825,
1834, 9620, 9630
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432, 1520, 1521, 1522, 1523, 1524, 1525, 1530, 1532,
1534, 1644, 1804, 1814, 1824, 1825, 1834
Description: The Secondary Bit Map identifies the presence or absence of the data
elements 65 through to 128 in the SPAN message format. It functions the
same as the Primary Bit Map, except that the Primary Bit Map identifies
the presence or absence of data elements 1 through 64 and is compulsory
in all messages.
The Secondary Bit Map is only required if any of data elements 65 through
128 are included in the message.
Note: The presence or absence of the Secondary Bit Map is identified by
Bit Position 1 in the Primary Bit Map. Absence of the Secondary Bit Map
implies that data elements 65 through 128 are not present.

Field Descriptions
3.4.2 DE 2 – Primary Account Number

Position: 2
Name: Primary Account Number
Representation: N..19
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1430, 1422, 1423, 1432, 1520,
1521, 1522, 1523, 1530, 1532, 9620, 9630
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432, 1520, 1521, 1522, 1523, 1524, 1525, 1532, 1530,
1534
Description: The Primary Account Number data element consists of a series of digits
used to identify a customer account or relationship i.e., the primary account
number of the Cardholder's account involved in the transaction or update
request being processed.
This data element is mandatory for all authorisation, financial, reversal,
chargeback and reconciliation messages.
In the event, where this field is entered manually i.e. POS transactions
where the PAN may be typed by the merchant, the Point of Service Data
Code (DE 22), position 7 value of “1” or “6” will indicate as such.
In reconciliation messages (15xx), the following definition will apply:
Message Type Value
1520, 1521, 1522, 1523 Bank Institution BIN
1524, 1525 Terminal ID

Field Descriptions
3.4.3 DE 3 – Processing Code

Position: 3
Name: Processing Code
Representation: N6
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1430, 1422, 1423, 1432
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432
Description: The Processing Code data element is a series of digits used to describe the
effect of a transaction on the Cardholder's account and the accounts
affected.
This element is mandatory for all Authorisation, Financial, Reversal and
Chargeback messages.
Usage: SPAN ATM (SPAN Card)
000000 Purchase (pre-pay token) from Default Account*
010000 Withdrawal from Default Account*
310000 Inquiry from Default Account*
380000 Mini Statement from Default Account*
Note: Purchase (pre-pay token) and Mini Statement are not permitted for
magnetic stripe cards or EMV fallback processing.
Usage: SPAN ATM (Non-SPAN Card)
011000 Withdrawal from Savings Account
012000 Withdrawal from Cheque Account
013000 Cash Advance from Credit Card Account
311000 Inquiry from Savings Account
312000 Inquiry from Current Account
313000 Inquiry from Credit Card Account
Usage: SPAN ATM (VISA Card)
020000 Debit from Default Account*
190000 Fee Collection from Default Account*
220000 Credit to Default Account*
290000 Fee Payment to Default Account*
Usage: SPAN ATM (GCCNet Card)
010000 Withdrawal from Default Account*
Usage: SPAN POS (SPAN Card)

Field Descriptions
000000 Purchase from Default Account

090000 Purchase with Cashback from Default Account
200000 Refund to Default Account
Note: Purchase with Cash Back is not permitted for magnetic stripe cards
or EMV fallback processing.
Usage: SPAN POS (Non-SPAN Card)
000000 Purchase from Default Account*
001000 Purchase from Savings Account
002000 Purchase from Current Account
003000 Purchase from Credit Card Account
013000 Cash Advance from Credit Card Account
200000 Refund to Default Account*
203000 Refund to Credit Card Account
900000 Authorisation only from Default Account
903000 Authorisation only from Credit Card Account
Usage: SPAN CPS (Claims Processing System)
Form CLAIMS table (pcode)
020000 Debit Adjustment
220000 Credit Adjustment
The same Processing Code will be sent to the issuer and acquirer.
* Default Account may be any valid primary account.
Transactions originating from Visa SMS may have the following account
types (to):
Code Account Type (to)
00 Not applicable
10 Savings Account
20 Cheque Account
30 Credit card Account
40 Universal Account
60 Electronic Purse (reloadable Visa Cash)
67 Disposable Visa Cash
It is assumed that 60 and 67 will not be received from Visa SMS.
Processing Codes not included here are not supported.

Field Descriptions
3.4.4 DE 4 – Transaction Amount

Position: 4
Name: Transaction Amount
Representation: N 12
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1430, 1422, 1423, 1432, 9620
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432
Description The Transaction Amount is the amount of funds requested by the
cardholder in the local currency of the acquirer or source location of the
transaction (exclusive of fees).
For CPS adjustment transactions this data element will contain the claim
amount.
Decimalisation of the amount is implied by the Transaction Currency Code
(DE 49). For example, if the currency code indicates Saudi Riyals (SR), a
field value of 000000010000 means SR 100.00.
Transaction Amount is mandatory for all authorisation, financial, reversal
and chargeback messages. Although a transaction amount does not apply
to some transaction types (i.e., balance inquiries), the element must be
present in the message, populated with zeroes when not applicable.
The Transaction Amount data element now contains the actual transaction
amount in authorisation and financial messages and the amount to be
reversed or charged back in reversal/chargeback messages. The original
transaction amount is provided in the Transaction Original Amounts
segment of the Original Amounts (DE 30) data element and the
Reconciliation Original Amounts in the second segment.
In a Purchase with Cash Back transaction, this field contains the total
amount and DE 54 Additional Amounts contains the cash back portion of
the amount.
In the event an authorisation/financial transaction is declined/rejected this
field is set to zero in the response message.
The following table summarises the use of DE 4 with DE 30 Original
Amounts and DE 24 Function Code in Request and Advice messages:
Authorisation Original
Function Transaction
/Financial Amounts
Code DE 24 Amount DE 4
Type DE 30
100, 101, 180,
Transaction
Original 181, 182, 200, -
amount
281, 286

Field Descriptions
Originally
authorised
amount
Previously
201, 202, 280 New amount Note: if
authorised
amount not
available, set
to zero
Transaction Amount of
Representment 205, 206, 207
amount chargeback
The relationship in response messages is as follows:
Authorisation Transaction Original Amounts
/Financial Type Amount DE 4 DE 30
Transaction
Full approval -
amount
Originally requested
Partial approval Approved amount
amount
Decline/reject Zero
amount
Note that Partial Approvals are not supported by SPAN. They are only
included in this table (from ISO8583:1993) for completeness.

Field Descriptions
3.4.5 DE 5 – Reconciliation Amount

Position: 5
Name: Reconciliation Amount
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1422, 1423, 1430, 1432
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432
Description: This data element contains the funds that are to be transferred between the
acquirer and card issuer, which is equal to the transaction amount data
element in the currency of reconciliation.
Decimalisation of the amount is implied by the Reconciliation Currency
Code (DE 50). For example, if the currency code indicates Saudi Riyals
(SR), a field value of 000000010000 means SR 100.00.
Reconciliation Amount is required in all financial, reversal and chargeback
messages when the Transaction Currency Code (DE 49) is not 682 i.e. not
Saudi Riyals (SR).
This field is related to DE 9, DE 16 and DE 50.
The relationship in response messages is as follows:
Authorisation Transaction Original Amounts
/Financial Type Amount DE 5 DE 30
Transaction
Full approval -
amount
Partial approval Approved amount
amount
Decline/reject Zero
amount
Note that Partial Approvals are not supported by SPAN. They are only
included in this table (from ISO8583:1993) for completeness.

Field Descriptions
3.4.6 DE 7 – Transmission Date & Time

Position: 7
Name: Transmission Date & Time
Representation: N 10 (MMDDhhmmss)
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1430, 1422, 1423, 1432, 1520,
1521, 1522, 1523, 1530, 1532, 1624, 1634, 1644, 1804, 1814, 1824, 1825,
1834, 9620, 9630
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432, 1520, 1521, 1522, 1523, 1524, 1525, 1530, 1532,
1534, 1644, 1804, 1814, 1824, 1825, 1834
Description: The Transmission Date and Time is generated and sent by the message
initiator. It is set for each outgoing message where the date to be used is
the current calendar day that the transaction occurred (not business day)
and the time the message was sent, which is expressed in Coordinated
Universal Time (UTC); (see ISO 8601) formerly known as Greenwich
Mean Time (GMT).
This field is mandatory for all message types and the Acquirer or Retailer
Bank must generate this field for each message sent to SPAN.
This is one of the elements used by SPAN to uniquely identify a network
message. The Banks must ensure that this field's integrity is maintained
and that it is logged with each transaction within the network.
Furthermore for messages, which are routed from Bank to Bank, the value
this data element passed between the message originating Bank and SPAN
may differ from the value as passed from SPAN to the message destination
Bank.

Field Descriptions
3.4.7 DE 9 – Reconciliation Conversion Rate

Position: 9
Name: Reconciliation Conversion Rate
Representation: N8
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1422, 1423, 1430, 1432
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432
Description: This data element holds the factor to be used in the conversion from the
transaction amount (acquirer currency) to reconciliation amount
(reconciliation currency). The transaction amount is multiplied by the
reconciliation conversion rate to determine the reconciliation amount.
The leftmost digit denotes the number of positions the decimal separator
shall be moved from the right. The rest of the positions is the rate. For
example a conversion rate value of 91234567 would equate to
0.001234567.
The maximum number of digits to the right of the decimal separator is 9,
provided the first two digits to the right of the decimal separator are zeroes.

Field Descriptions
3.4.8 DE 11 – Systems Trace Audit Number

Position: 11
Name: Systems Trace Audit Number
Representation: N6
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1430, 1422, 1423, 1432, 1520,
1521, 1522, 1523, 1530, 1532, 1624, 1634, 1644, 1804, 1814, 1824, 1825,
1834, 9620, 9630
POS 1100, 1110, 1120, 1121, 1130,1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432, 1520, 1521, 1522, 1523, 1524, 1525, 1530, 1532,
1534, 1644, 1804, 1814, 1824, 1825, 1834
Description: Systems Trace Audit Number is a number that must be assigned by the
message sender to assist in identifying a transaction uniquely. The trace
number remains unchanged for all messages within the transaction.
A transaction being defined as one or more related messages within the
same message class designed to complete the intention of the sender of the
original message (i.e., a chargeback should not have the same number as
the original financial message).
The trace number remains unchanged for messages within a transaction
between two parties e.g. between acquirer and SPAN or between SPAN
and issuer). For requests which are routed from Bank to Bank via SPAN,
the value of this data element in the message as passed between the request
originating bank and SPAN may differ from the value in the message as
passed from SPAN to the request destination Bank.
The purpose of the Systems Trace Audit Number is to provide an audit
trail for every message sent by an acquirer for a given posting date. It is not
to be used for uniqueness of financial transactions and is mandatory for all
messages to and from SPAN. The number may not be zero and must be
incremented for every request and advice message.
In reconciliation and network management messages, the Systems Trace
Audit Number is used to match the request with its response. For financial
messages, the Systems Trace Audit Number is also stored so that if a
reversal must be sent later, it can be included in the Original Data
Element’s (DE 56) Original System Trace Audit Number.

Field Descriptions
All requests and advices sent to SPAN must format this field ensuring that
it follows an uninterrupted serialised sequence. The Systems Trace Audit
Number is incremented by SPAN or the processor each time a message
request is sent. The number must wrap around from a value of 999999 to
000001. It is extremely unlikely that this number be duplicated in one
given day for a given institution. It is incremented by SPAN or the
acquiring processor each time a message request is sent.
This field combined with the Acquirer Institution Identification Code (DE
32) assigned by SPAN becomes the full trace reference. The STAN should
not be used for uniqueness except when combined with the Acquirer
Institution Identification Code.
As there are timeout periods for request and response messages established
by SPAN, responses that are not received in the allowed time period will
be timed out. The Systems Trace Audit Number is used to match
responses to outstanding requests. A response message containing this data
element, which does not map to any pending request can be assumed to
have been timed out.
It is also worth pointing out that the Systems Trace Audit Number is not
valuable for long-term identification of transactions as the numbers are
reused. The data elements Local Transaction Date & Time and Card
Acceptor Terminal Identification provide such long-term identification.

Field Descriptions
3.4.9 DE 12 – Local Transaction Date & Time

Position: 12
Name: Local Transaction Date & Time
Representation: N 12 (YYMMDDhhmmss)
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1430, 1422, 1423, 1432, 1520,
1521, 1522, 1523, 1530, 1532, 1624, 1634, 1644, 1804, 1814, 1824, 1825,
1834, 9620, 9630
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432, 1520, 1521, 1522, 1523, 1524, 1525, 1530, 1532,
1534, 1644, 1804, 1814, 1824, 1825, 1834
Description: The Local Transaction Date & Time is the local year, month, day and time
the transaction takes places at the card acceptor location for authorisation
and financial messages.
In the case of reversal, chargeback, reconciliation, administrative, fee
collection and network management messages, it is the year, month, day
and time set by the initiator of the first message in the transaction.
This field is mandatory in all messages and must not change for all
messages throughout the life of a transaction. Additionally, this field will
be helpful in tracking down the response time during a transaction's transit
through the network.
SPAN sets the SPAN POS terminal date/time at initialisation and controls
its accuracy when the POS terminal is connected to SPAN.
The original transmission date & time and original forwarding institution
identification code is no longer required for transaction matching as stated
in the revised ISO standard. However, the Original Local Transaction Date
and Time segment of the Original Data Elements (DE 56) should be used
for transaction matching.

Field Descriptions
3.4.10 DE 14 – Expiration Date

Position: 14
Name: Expiration Date
Representation: N 4 (YYMM)
element.
ATM 9620
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432
Description: The Expiration Date is the year and month after which the card expires.
This data element is only utilised when the card data is manually entered at
a POS terminal.
In that case, the value of “1” or "6" placed in position 7 of the Point of
Service Data Code (DE 22) represents a manually entered card number at
the point of sale.
Otherwise, the Expiration Date is not used as the card's expiration date is
read from Track 2 of the Card and placed in the Track 2 Data (DE 35).
The Expiration Date is not present in a CPS transaction.

Field Descriptions
3.4.11 DE 16 – Conversion Date

Position: 16
Name: Conversion Date
Representation: N 4 (MMDD)
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1422, 1423, 1430, 1432
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432
Description: The Conversion Date represents the month and day the conversion rate is
effective to convert the transaction amount from the original to the
reconciliation currency.

Field Descriptions
3.4.12 DE 17 – Capture Date

Position: 17
Name: Capture Date
Representation: N 4 (MMDD)
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1422, 1423, 1430, 1432
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432
Description: This data element contains the month and day when the transaction data
was processed (acquired) by the acquirer.
ATM
Transactions acquired at member bank ATMs will contain the member
bank’s business date. The transaction acquired by SAMA’s ATMs will
contain SAMA’s ATM business date (SPAN ATM business date).
POS
Since all POS terminals are directly connected to SAMA, all transactions
acquired by POS terminals will contain SAMA’s POS business date
(SPAN POS business date).

Field Descriptions
3.4.13 DE 22 – Point of Service Data Code

Position: 22
Name: Point of Service Data Code
element.
ATM 1200, 1210, 1220, 1230, 1221, 1420, 1421, 1422, 1423, 1430, 1432, 9620
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432
Description: The Point of Service Data Code is a series of codes that are intended to
identify terminal capability, terminal environment and presentation
security data. It shall be used to indicate specific conditions that are (or
were) present at the time a transaction took place at the point of service
and/or when the transaction has been initiated.
For CPS set to 100101100010
The exact breakdown of the Point of Service Data Code and the allowable
values are given below.
• Position 1 – Card data input capability
(Indicates the primary means of getting the information on the card into the
terminal)
Code Description
0 Unknown
1 Manual, no terminal
2 Magnetic stripe read
3 Bar code
4 OCR
5 ICC (see Note 1)
6 Key entered
For SPAN, it is expected that 5 (ICC) would be the norm, though 2

(magnetic stripe read) may be used in transition.
• Position 2 – Cardholder authentication capability
(Indicates the primary means of verifying the cardholder at this terminal.
When no order of priorities can be made, valued “6” shall be used)
Code Description
0 No electronic authentication
1 PIN
2 Electronic signature analysis
3 Biometrics

Field Descriptions
4 Biographic
5 Electronic authentication inoperative
6 other
For SPAN, 1 (PIN) is used.
• Position 3 – Card capture capability
(Indicates whether or not the terminal has the ability to capture a card)
Code Description
0 None
1 Capture
For SPAN, 0 (None) is used.
• Position 4 – Operating environment (See note 2 below)
(Indicates if the terminal is attended to by the card acceptor at its location)
Code Description
0 No terminal used
1 On premises of card acceptor, attended
2 On premises of card acceptor, unattended
3 Off premises of card acceptor, attended
4 Off premises of card acceptor, unattended
5 On premises of cardholder, unattended
For SPAN, 1 to 5 are used as appropriate.
• Position 5 – Cardholder present
(Indicates if the cardholder is present at the point of service or not and if
not why not)
Code Description
0 Cardholder present
1 Cardholder not present, unspecified
2 Cardholder not present, mail order
3 Cardholder not present, telephone
4 Cardholder not present, stand-in authorisation
For SPAN, 0 or 1 are used as appropriate.
• Position 6 – Card present
(Indicates if the card is present at the point of service or not)
Code Description
0 Card not present
1 Card present
For SPAN, 0 or 1 are used as appropriate.
• Position 7 – Card data input mode
(Indicates method used to input the information from the card to the
Field Descriptions
terminal)
Code Description
0 Unspecified
1 Manual, no terminal
2 Magnetic stripe read
3 Bar code
4 OCR
5 ICC (see note 1 below)
6 Key entered
For SPAN, 1, 2, 5 or 6 are used as appropriate.
• Position 8 – Cardholder authentication method
(Indicates the method for verifying the cardholder identity)
Code Description
0 Not authenticated
1 PIN
2 Electronic signature analysis
3 Biometrics
4 Biographic
5 Manual signature analysis
6 Other manual verification (e.g., drivers license)
For SPAN, 1 or 5 are used as appropriate. For transactions from the Claims
Processing system (CPS), 0 is used.
• Position 9 – Cardholder authentication entry
(Indicates the entity verifying the cardholder identity.)
Code Description
0 Not authenticated
2 CAD (see note 1 below)
3 Authorising agent (identified in authorising agent
institution identification code)
4 By merchant
5 Other
For SPAN, 1, 3 and 4 are used as appropriate. For transactions from the
Claims Processing system (CPS), 0 is used.
• Position 10 – Card data output capability
(Indicates the ability of the terminal to update the card)
Code Description
0 Unknown

Field Descriptions
1 None
2 Magnetic strip write
For SPAN, it is expected that 3 is used, though 1 may be used in transition
(and for CPS).
• Position 11 – Terminal output capability
(Indicates the ability of the terminal to print/display messages)
Code Description
0 Unknown
1 None
2 Printing
3 Display
4 Printing and display
For SPAN, 1 to 4 are used as appropriate.
• Position 12 – PIN capture capability
(Indicates the length of PIN which the terminal is capable of capturing)
Code Description
0 No PIN capture capability
1 Device PIN capture capability unknown
4 Four characters
5 Five characters
6 Six characters
7 Seven characters
8 Eight characters
9 Nine characters
A Ten characters
B Eleven characters
C Twelve characters
For SPAN, 4 to C are used as appropriate.
Notes
1 CAD, ICC, ADF and CDF are terms defined in ISO 10202. For the
purposes of this interface document, CAD shall be synonymous
with terminal.
2 If both values 4 and 5 apply in Position 4, 5 shall be used.

Field Descriptions
3.4.14 DE 23 – Card Sequence Number

Position: 23
Name: Card Sequence Number
Representation: N3
element.
ATM 1200, 1220, 1221, 1420, 1421, 1422, 1423, 9620
POS 1100, 1120, 1121, 1200, 1220, 1221, 1420, 1421, 1422, 1423
Description: The Card Sequence Number is a number distinguishing between separate
cards with the same primary account number or primary account number
extended (see ISO 4909).
The field is only present for chip read transactions if the information was
read from the chip.

Field Descriptions
3.4.15 DE 24 – Function Code

Position: 24
Name: Function Code
Representation: N3
element.
ATM 1200, 1220, 1221, 1420, 1421, 1422, 1423, 1520, 1521, 1522, 1523, 1624,
1644, 1804, 1824, 1825, 9620
POS 1100, 1120, 1121, 1200, 1220, 1221, 1420, 1421, 1422, 1423,1520, 1521,
1522, 1523, 1524, 1525, 1644, 1804, 1824, 1825,
Description: The Function Code indicates the specific purpose of the message within
the message class.
The Function Code is mandatory in all request, advice and notification
messages. The list below identifies the supported codes within the SPAN
network.
Code Description
Used in 1100, 1120, 1121 messages
100 Original authorisation – amount accurate
101 Original authorisation – amount estimated
181 Notification of an authorisation or pre-authorisation
182 Notification of a pre-authorisation initial completion
Used in 1200, messages
200 Original financial request/advice
Used in 1220, 1221 messages
200 Original financial request/advice
201 Previously approved authorisation – amount same
202 Previously approved authorisation – amount differs
205 First re-presentment
206 Second re-presentment
207 Third or subsequent re-presentment
280 Notification of a previously approved financial transaction
281 Notification of an original financial transaction
282 Representment
283 Misdispense Adjustment
284 Back Office Adjustment

Field Descriptions
285 Acquirer-Originated Fee-Related Transaction

286 Claims Processing System (CPS) generated
400 Full reversal, transaction did not complete as approved
401 Partial reversal, transaction did not complete for full amount
450 First chargeback, full
451 Second chargeback, full
452 Third or subsequent chargeback, full
453 First chargeback, partial
454 Second chargeback, partial
455 Third or subsequent chargeback, partial
490 Chargeback Reversal
491 Chargeback
492 Issuer-Generated Fee-Related Transaction
Used in 1520, 1521, 1522, 1523, 1524, 1525 messages
500 Final reconciliation
570 Terminal reconciliation
571 Forced reconciliation
572 Requested reconciliation
Used in 1644 messages
650 Unable to parse message
691 MAC Error
689 Card capture (Visa only)
Used in 1804 messages
801 System condition/sign-on
802 System condition/sign-off
811 System security/key change
821 System accounting/cutover
831 System audit control/echotest
821 System accounting/cutover
Used in 9620 message
970 Fraud advice

Field Descriptions
3.4.16 DE 25 – Message Reason Code

Position: 25
Name: Message Reason Code
Representation: N4
element.
ATM 1200, 1220, 1420, 1421, 1422, 1423,
POS 1100, 1120, 1121, 1200, 1220, 1221, 1420, 1421, 1422, 1423
Description: The Message Reason Code provides the receiver of a request, advice or
notification message with a reason or purpose for that message.
This element serves a different purpose depending upon the message class.
For original authorisations and financial transactions this data element
identifies why the type of message was sent (e.g., why an advice was sent
rather than a request); for other messages, this element states why this
action was taken.
The Message Reason Code is mandatory in reversal and chargeback
messages. This field should also be used in financial request messages
when a re-presentment is generated. The full list of SPAN acceptable codes
are provided below.
This field is not present in the following;
i. 1220 Financial Advice transactions from CPS,
ii. Any transactions (ATM/POS) acquired abroad (Visa,
MasterCard & GCC),
iii. 1200 Financial Request (ATM) transactions where the chip data is
included in the message,
iv. 1200 Financial Request (ATM/POS) transactions where a
magnetic stripe card is used.
v. 1220/1221 Financial Transaction Advice/Advice Repeat (POS)
transactions where a magnetic stripe card is used.
Code Description
Reason for an advice/notification message rather than a request message.
Advice transactions generated by the Claims Processing system (CPS) will not contain a Message
Reason Code.
These codes will be used as follows in SPAN:
1004 Terminal processed
Used by SPAN for:
Pre-authorisation Completion
Voice Authorised Credit Card Advice

Field Descriptions
Code Description
1005 ICC processed
Used by SPAN for:
Off-line chip card Advice (approved or declined by the card)
On-line chip card Completion
1006 Under floor limit
Not currently used by SPAN
1378 Visa Adjustment
Reason for a request message rather than an advice/notification message
The following codes are all possible for 1100 Authorisation Request transactions and 1200 Financial
Request transactions generated for a chip card.
These codes will also be used in SPAN for advice/notification messages to Retailer and Card Scheme
Acquirer Banks.
1502 ICC random selection
1503 Terminal random selection
1505 On line forced by ICC (CDF or ADF)
1506 On line forced by card acceptor
1508 On line forced by terminal
1509 On line forced by card issuer
1511 Merchant suspicious
Reason for a 1200 Financial Transaction Request for a chip card rather than an 1100 Authorisation
Message.
Reason for no chip data in a 1200 Financial Transaction Request (ATM) for a chip card based
transaction.
These codes will also be used in SPAN for advice/notification messages to Retailer and Card Scheme
Acquirer Banks.
1776 Fallback from Chip to Magnetic Stripe/Manual Entry
Reason for a re-presentment
2000 Representment
2001 Invalid acquirer reference number on chargeback
2002 Non-receipt of required documentation to support chargeback
2003 Correct transaction date provided
2004 Correct merchant description provided (DBA)
2005 Correct merchant location provided
2006 Incorrect transaction date provided on chargeback
2007 Transaction did not exceed merchant floor limit

Field Descriptions
Code Description
2008 Transaction authorised by issuer
2009 No error in addition of sale – amount correct in original transaction
2010 No proof of altered amount (customer stated in chargeback that amount had been
altered)
2011 Credit previously issued
2012 Original transaction was valid
Reason for a reversal
4000 Customer cancellation
4001 Unspecified, no action taken
4002 Suspected malfunction
4003 Format error, no action taken
4004 Completed partially (not used for SPAN member banks acquired transactions)
4005 Original amount incorrect
4006 Response received too late
4007 Card acceptor device unable to complete transaction
4013 Unable to deliver message to point of service
4014 Suspected malfunction/card retained
4015 Suspected malfunction/card returned
4017 Suspected malfunction/no cash dispensed
4018 Timed-out at taking money/no cash dispensed
4019 Timed-out at taking card/card retained and no cash dispensed
4020 Invalid response, no action taken
4021 Timeout waiting for response
4351 MAC failure
4352 Reversal
Reason for a chargeback
4500 Invalid merchant
4501 Invalid transaction
4502 Customer dispute
4503 Expired card
4504 Transaction not permitted to terminal
4505 Security violation
4506 System malfunction
4507 Disputed transaction amount
4508 Authorised amount exceeded
4509 Authorised time limit exceeded

Field Descriptions
Code Description
4510 Credit submitted as a debit
4511 Debit submitted as a credit
4512 Duplicate processing of transaction
4513 Credit not received
4514 Fraudulent transaction
4515 Cardholder denies transaction was finalised
4516 Non-fulfilment of request for information
4517 Non-fulfilment of request, illegible copy
4518 Cardholder does not recognise merchant description
4519 Stand-in processing not allowed
4520 Stand-in processing criteria not fulfilled
4521 Transaction exceeds floor limit
4522 Declined authorisation
4523 Non-matching account number
4524 Error in addition
4525 Altered amount
4526 Missing signature
4527 Missing card imprint
4528 Cancelled preauthorised transaction
4529 Delinquent reconciliation
4530 Currency conversion errors
4531 Claim or defence on receipt of goods
4532 Defective merchandise
4533 Fraudulent transaction prior to embossed valid date
4534 Imprint of multiple slips
4535 Warning bulletin/exception file
4536 Late presentment
4537 No show disputed
4538 Advance lodging deposit
4539 Cardholder disputes transaction date
4540 Card not yet effective
4541 Illegible data
4542 Transaction not received
4543 Duplicate processing by multiple institutions
4544 Cancelling recurring transaction

Field Descriptions
Code Description
4545 Currency conversion not allowed
4546 Mail/telephone order transaction unauthorised purchaser
4547 Card listed on warning bulletin
4548 Cardholder dispute – transaction under merchant floor limit
4549 Incorrect account number
4550 Cardholder disputes card activated telephone transaction
4551 Original transaction currency not provided
4552 Mail/telephone order on expired card
4553 Transaction not as described
4554 Non-receipt of merchandise
4555 Services not rendered
4556 Merchandise not as described
4750 Invalid ICC data
4751 Chargeback
4752 Chargeback Reversal
Reason for Fee Collection / Funds Disbursement
7600 Acquirer-Generated Fee Collection
7601 Acquirer-Generated Fee Payment
7602 Issuer-Generated Fee Collection
7603 Issuer-Generated Fee Payment

Field Descriptions
3.4.17 DE 26 – Card Acceptor Business Code

Position: 26
Name: Card Acceptor Business Code
Representation: N4
element.
ATM 1200, 1220, 1221, 1230, 9620
POS 1100, 1120, 1121, 1200, 1220, 1221, 1420, 1421, 1422, 1423, 1524, 1525
Description: Card Acceptor Business Code describes the category of industry (e.g.
Transport-Railroads, Service Stations) within which the acceptors business
falls. The ISO8583 Standard document provides a list of the valid codes.
All transactions originating from an ATM have a Card Acceptor Business
Code of 6011 (Financial institutions – Automated cash disbursements).
Advice transactions originating from CPS have a Card Acceptor Business
Code of 6011 for ATM Adjustments and 0000 for POS adjustments.

Field Descriptions
3.4.18 DE 28 – Reconciliation Date

Position: 28
Name: Reconciliation Date
Representation: N 6 (YYMMDD)
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1422, 1423, 1430, 1432, 1520,
1521, 1522, 1523, 1530, 1532, 1804, 1814, 1824, 1825, 1834
POS 1100, 1110, 1121, 1120, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432, 1520, 1521, 1522, 1523, 1524, 1525, 1530, 1532,
1534, 1644, 1804, 1814, 1824, 1825, 1834
Description: The Reconciliation Date is the year, month and day for which financial
totals are reconciled between the acquirer and card issuer. All SPAN
transactions require this field to contain SPAN’s business date.
The final reconciliation amount shall be the sum of all financial amounts
from the individual transactions identified with the same reconciliation
date. Similarly, the final reconciliation counts shall be the number of
transactions identified with the same reconciliation date.
This field is conditional in the network management messages and should
be present for network cutover. It should contain the date of the new
business day.
For reversals generated on timeout, the message originator shall populate
this data element with the current SPAN Business date. However, in some
circumstances i.e. cutover, SPAN may return an updated business date.
This is the actual date that must be used.

Field Descriptions
3.4.19 DE 30 – Original Amounts

Position: 30
Name: Original Amounts
element.
ATM 1210, 1220, 1221, 1420, 1421, 1422, 1423
POS 1110, 1120, 1121, 1210, 1220, 1221, 1230, 1420, 1421, 1422, 1423
Description: The amount data elements from the original transaction, mandatory
inclusion for declined/rejected transactions.
The Original Amounts data element shall consist of two data elements in
fixed length format totalling 24 digits.
• Transaction Original Amount – N, 12
• Reconciliation Original Amount – N, 12
In the event that these fields are not required the omission shall be
indicated by zeroes. The above data elements shall be used when
attempting to partially reverse or partially chargeback a previous
transaction and shall contain the original amounts.
For a re-presentment advice, this field is used by the Acquirer Bank to
indicate the original chargeback amount. For CPS adjustment messages
this data element is not present.
In an authorisation/financial request response (1110/1210), this field is
used when the request is declined or rejected by the card issuer. It contains
the requested amount.
See section 3.4.4 for a description of the relationship between DE30 and
DE 4 Transaction Amount.

Field Descriptions
3.4.20 DE 32 – Acquirer Institution Identification Code

Position: 32
Name: Acquirer Institution Identification Code
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1430, 1422, 1423, 1432, 1520,
1521, 1522, 1523, 1530, 1532, 9620, 9630
POS 1100, 1110, 1120, 1121, 1130,1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432, 1520, 1521, 1522, 1523, 1524, 1525, 1530, 1532,
1534,
Description: The Acquiring Institution Identification Code identifies the Acquirer Bank
for ATM transactions or in the case of POS transactions the Retailer Bank.
This element is mandatory for all financial transaction and reversal
messages. This is a unique identifier for each financial institution in the
SPAN network.
In Reconciliation transactions, this field contains:.
Transaction Type (POS and Contents Acquiring Institution
ATM) Identification Code
1520/1521 SAMA Institution Id
1522/1523 KSA Acquirer Bank
1524/1525 KSA Retailer Bank
SPAN assigned values are documented in Section 10 of this manual.

All transactions acquired via Visa, MasterCard and GCCNet interchanges
will populate this field as is currently done for SPAN (See Section 10 for
further details).

Field Descriptions
3.4.21 DE 35 – Track 2 Data

Position: 35
Name: Track 2 Data
Representation: Z..37
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1430, 1422, 1423, 1432
POS 1100, 1110, 1120, 1121, 1130,1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432,
Description: This data element holds the information that is encoded on track 2 of the
magnetic stripe (or from the chip) as defined in ISO 7813, excluding
beginning and ending sentinels and longitudinal redundancy check (LRC)
characters.
This element is mandatory for all ATM financial transaction messages and
conditional for POS financial transaction messages and reversals, and must
not change for a complete transaction.
Acquirers must pass on all the track 2 information captured by the ATM or
POS terminal and must not perform any validation or modification to the
data the Card Issuer has encoded on Track 2 of the magnetic stripe. For
CPS adjustment messages this data element is not present.
When card information is manually entered at a POS terminal, this field is
not present. This field is only present for POS transactions, when Point of
Service Data Code (DE 22) has a “2” or “5” in position 7. This indicates
that the card data input method was a magnetic stripe read or an ICC based
transaction.
Card Scheme Transactions
For card scheme transactions (Visa/Mastercard) where Track 2 is not
available but is mandatory in the SPAN Member Bank Interface, it will be
constructed from available data elements, e.g. DE2 PAN, DE14 Expiry
Date etc. In the case where only the DE2 PAN exists the constructed DE35
Track 2 will contain the DE2 PAN plus the Field Separator “=”. The length
of DE35 will always be dictated by the last available sub-field of DE35
Track 2. Any sub-fields not present between two populated sub-fields will
be populated by spaces otherwise they shall be omitted i.e. no spaces at the
end of the data element DE35 Track 2.
Note: As a result of constructing DE35 this way, it may not be identical to
the original authorisation/financial transaction and this is a deviation from
the ISO standard.

Field Descriptions
3.4.22 DE 37 – Retrieval Reference Number

Position: 37
Name: Retrieval Reference Number
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1430, 1422, 1423, 1432, 9620,
9630
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432
Description: The Retrieval Reference Number is a number assigned by the message
initiator to uniquely identify a transaction. In the event the original source
information or a copy of it is required this reference number is used in the
locating process. The Retrieval Reference Number must remain unchanged
for all messages throughout a complete transaction.
This element is mandatory for all financial transaction and reversal
messages.
It is a requirement that the Acquirer format this field to contain at least six
numbers (left justified), padding any remaining positions with blank
characters.
For CPS adjustments this is taken from the original.

Field Descriptions
3.4.23 DE 38 – Approval Code

Position: 38
Name: Approval Code
element.
ATM 1210, 1220, 1221, 1230,1420, 1421, 1422, 1423, 9620
POS 1110, 1120, 1121, 1130, 1210, 1220, 1221, 1230, 1420, 1421, 1422, 1423
Description: The Approval Code is assigned by the authorising institution to indicate
approval (formerly known as Authorisation Identification Response).
This is not included in Reversal Advice messages when it is generated
upon to time-out.
In 1120, 1121, 1210, 1220, 1221, and 1230 messages, this field is not
present when:
• The transaction type is a Balance Inquiry / Mini Statement, or
• The transaction was declined, or
• CPS advices, or
• Representment (VISA SMS).
Card Issuer Banks must assure the uniqueness of this number within the
given business date.

Field Descriptions
3.4.24 DE 39 – Action Code

Position: 39
Name: Action Code
Representation: N3
element.
ATM 1210, 1220, 1221, 1230, 1430, 1432, 1530, 1532, 1624, 1634, 1644, 1814,
1824, 1825, 1834, 9630
POS 1110, 1120, 1121, 1130,1210, 1220, 1221, 1230, 1430, 1432, 1524, 1525,
1530, 1532, 1534, 1644, 1814, 1824, 1825, 1834
Description: The Action Code data element replaces the Response Code from the
ISO8583:1987 standard. The code placed in this element defines the action
taken or to be taken and the reason for taking this action.
For CPS set to 000.
The following pages are valid values for the Action Code data element for
the SPAN network.
Code Description Action ATM POS

Used in 1110, 1210, 1220 and 1221 messages to indicate that the transaction has
been approved.
000 Approved Approve × ×
001 Honour with identification Approve ×
002 Approved for partial amount Approve × -
003 Approved (VIP) Approve × ×
007 Approved, update ICC. Approve × ×
To be used for SPAN only when a
response includes an issuer script.
087 Offline Approved (Chip only) Approve ×
089 Unable to go On-line. Off-line approved Approve ×
(Chip only)
Used in 1110, 1210, 1220, 1221 messages to indicate that the authorisation by or on
behalf of the card issuer and has been denied (not requiring a card pick-up).
100 Do not honour Decline × ×
101 Expired card Decline × ×
102 Suspected fraud (To be used when ARQC Decline × ×
validation fails)
103 Card acceptor contact acquirer Decline - ×
104 Restricted card Decline × ×
105 Card acceptor call acquirer’s security Decline - ×
department

Field Descriptions

106 Allowable PIN tries exceeded Decline × ×
107 Refer to card issuer Decline × ×
108 Refer to card issuer’s special conditions Decline × ×
109 Invalid merchant Decline - ×
110 Invalid amount Decline × ×
111 Invalid card number Decline × ×
112 PIN data required Decline × ×
114 No account of type requested Decline × ×
115 Requested function not supported Decline × ×
116 Not sufficient funds Decline × ×
117 Incorrect PIN Decline × ×
118 No card record Decline × ×
119 Transaction not permitted to cardholder Decline × ×
120 Transaction not permitted to terminal Decline - ×
121 Exceeds withdrawal amount limit Decline × ×
122 Security violation Decline × ×
123 Exceeds withdrawal frequency limit Decline × ×
125 Card not effective Decline × ×
126 Invalid PIN block Decline × ×
127 PIN length error Decline × ×
128 PIN key synch error Decline × ×
129 Suspected counterfeit card Decline × ×
180 Unable to locate previous message (Visa Decline × ×
76)
181 Previous message located for a repeat or Decline × ×
reversal, but message data is inconsistent
with original message (Visa 77)
182 Invalid date (Visa 80) Decline × ×
183 Cryptographic error found in PIN or CVV Decline × ×
(Visa 81)
184 Incorrect CVV (Visa 82) Decline × ×
185 Unable to verify PIN (Visa 83) Decline × ×
186 No reason to decline a request for account Decline × ×
verification or address verification (Visa
85)
Action codes 188 through to 190 are for chip cards only.
188 Offline declined Decline ×

Field Descriptions

190 Unable to go online – Offline declined Decline ×
The action codes below indicate that the transaction has been processed for
authorisation by or on behalf of the card issuer and has been denied, requiring an
ATM to retain the card (pick up), and a merchant will employ standard security
measures at POS terminal.
200 Do not honour Decline × ×
201 Expired card Decline × ×
202 Suspected fraud (To be used when ARQC Decline × ×
validation fails)
203 Card acceptor contact acquirer Decline - ×
204 Restricted card Decline × ×
205 Card acceptor call acquirer’s security Decline - ×
department
206 Allowable PIN tries exceeded Decline × ×
207 Special conditions Decline × ×
208 Lost card Decline × ×
209 Stolen card Decline × ×
210 Suspected counterfeit card Decline × ×
Used in 1430 and 1432 messages to indicate the result of the reversal or chargeback
400 Accepted Approve × ×
480 Original transaction not found Decline × ×
481 Original transaction was found but Decline × ×
declined
Used in 1524, 1525, 1530, 1532 and 1534 messages to indicate the result of a
reconciliation.
500 Reconciled, in balance Approve × ×
501 Reconciled, out of balance Decline × ×
504 Not reconciled, totals provided Decline - ×
(Used in a 1524 when a Retailer Bank
issues a Request Reconciliation for a POS
terminal.)
Used in 1624, 1634,
600 Accepted Approve x
Used in 1644
690 Unable to parse message Decline x x
Used in 1814, 1824, 1825, and 1834 messages.
800 Accepted Approve × ×
The Action Codes below are not part of the ISO standard. These codes are only valid
for bank Network Management messages.

Field Descriptions

884 Problem in signature verification Decline × ×
886 Problem with keys format Decline × ×
888 Unknown error Decline × ×
(Default value for all other 18xx
responses where no appropriate 8xx or
9xx Action Code exists.)
892 Transmission Date and Time Identical to Decline × ×
Earlier Request
Used in reject notification (where identified), request response and advice response
messages to indicate transaction could not be processed.
902 Invalid transaction Decline × ×
903 Re-enter transaction Decline × ×
904 Format error Decline × ×
906 Cutover in process Decline × ×
907 Card issuer or switch inoperative Decline × ×
908 Transaction destination cannot be found Decline × ×
for routing
909 System malfunction Decline × ×
910 Card issuer signed off Decline × ×
911 Card issuer timed out Decline × ×
912 Card issuer unavailable Decline × ×
913 Duplicate transmission Decline × ×
914 Not able to trace back to original Decline × ×
transaction
915 Reconciliation cutover or checkpoint Decline × ×
error
916 MAC incorrect (permissible in 1644) Decline × ×
917 MAC key sync Decline × ×
918 No communication keys available for use Decline × ×
919 Encryption key sync error Decline × ×
920 Security software/hardware error – try Decline × ×
again
921 Security software/hardware error – no Decline × ×
action
922 Message number out of sequence Decline × ×
923 Request in progress Decline × ×
941 Destination Unavailable Decline × ×
942 Invalid Capture/Reconciliation/Cutover Decline × ×
Date

Field Descriptions
3.4.25 DE 41 – Card Acceptor Terminal Identification

Position: 41
Name: Card Acceptor Terminal Identification
Representation: ANS 16
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1430, 1422, 1423, 1432, 1624,
1634, 9620
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432, 1524, 1525, 1534
Description: Card Acceptor Terminal Identification is a unique code identifying the
terminals at the acquirer location.
This field is mandatory for all financial transaction messages and must not
change for all messages throughout the life of a transaction.
For POS transactions this value must be ‘N’ (numeric) even though the
definition allows for ‘ANS’ (alphabetic, numeric and special characters)
The purpose of this field is to provide a unique identification code for all
ATM/POS device positions in the SPAN network. The field is structured
as follows:
ATM
Position Length Description
01-06 6 A unique mnemonic code reflecting the location
of the ATM.
07-08 2 ATM type code
09-10 2 PTT area code
11-12 2 Bank clearing code
13-16 4 Physical ATM ID within bank
POS
01-08 8 Unique terminal ID (Vendor Assigned)
09-10 2 PTT area code
11-12 2 Bank Clearing Code
13-16 4 Unique Device ID Within Bank (Bank Assigned)

Field Descriptions
3.4.26 DE 42 – Card Acceptor Identification Code

Position: 42
Name: Card Acceptor Identification Code
Representation: ANS 15
element.
ATM Not applicable.
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432, 1524, 1525, 1534
Description: This field holds the code identifying the card acceptor for Retailers
registered with SPAN by Retailer Banks. This value is unique and is
assigned by SPAN as a part of the Retailer registration process.
This data element is left justified and blank filled on the right with the
following structure:
01-02 2 Bank Clearing Code
03-04 2 Agent Value - For bank use to identify
banks branches, multi-location Retailer
05-12 8 Unique Retailer identification assigned by
the Retailer Bank
13-15 3 Spaces
For POS adjustment advices originating from CPS this (mandatory) field is
set to zeroes.
For ATM adjustment advices originating from CPS this (conditional) field
is not present.

Field Descriptions
3.4.27 DE 43 – Card Acceptor Name/Location

Position: 43
Name: Card Acceptor Name/Location
Representation: ANS..99
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1430, 1422, 1423, 1432, 1624,
1634, 9620
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432, 1524, 1525, 1534

Field Descriptions
Description: The Card Acceptor Name/Location data element shall be used to hold the
name and location of the card acceptor as known to the cardholder.
This data element shall consist of six data elements totalling up to 99
characters. The first three elements are of variable length, separated from
the remaining data elements and each other by a back slash (\). The
variable length component of this field can be up to 83 characters in length.
The remaining three data elements are fixed format as shown below.
• For adjustment advices originating in CPS this field is set to
‘CLAIMS PROCESSING’.
ATM & POS
01-Var ..83 Terminal Owner – The name of the
institution that operates the ATM or for
POS, the retailer name plus backslash.
Terminal Street – The name of the street
where the terminal resides plus backslash.
Terminal City – The name of the city
where the terminal resides plus backslash.
Var-Var 10 Postal Code – The postal code of the card
acceptor (ANS, 10).
Var-Var 3 Region – The region where the card
acceptor is located (ANS, 3)
See Section 10 for a list of valid values.
Var-Var 3 Country Code – The ISO 3166 country
code (A, 3) where the terminal resides.
VISA SMS ATM & POS

• For Acquirer-Generated Fee Collection set this field to
‘ACQUIRER FEE COLLECTION’.
• For Acquirer-Generated Funds Disbursement set this field to
‘ACQUIRER FUNDS DISBURSEMENT’.
• For Issuer-Generated Fee Collection set this field to ‘ISSUER
FEE COLLECTION’.
• For Issuer-Generated Funds Disbursement set this field to
‘ISSUER FUNDS DISBURSEMENT’.

Field Descriptions
3.4.28 DE 46 – Fee Amounts

Position: 46
Name: Fee Amounts
element.
ATM 1220, 1221, 1230, 1422, 1423, 1432
POS Not applicable.
Description: Fees associated with this transaction.
The Fees Amount data element consists of up to six sets of values.
Each set of values consists of six data elements of fixed length format
totalling 34 characters as follows.
Subfield Type Description
46.1 N2 Fee Type Code.
See reference [ISO8583-93]
appendix A.5 for a list of valid ISO
codes, plus private code:
70 Other Fee
46.2 N3 Fee Currency Code.
46.3 X+N 8 Fee Amount.
46.4 N8 Fee Conversion Rate.
46.5 X+N 8 Reconciliation Fee Amount.
46.6 N3 Reconciliation Fee Currency Code.
This field must be present in Financial Transaction Advice and Advice

Response messages for fee-related transactions (where DE 3 is 190000
or 290000).
Subfield DE 46 subfield 46.3 Fee Amount copied to/from F4. DE 46
subfield 46.1 set to Fee Type Code corresponding to Visa Message
Reason Code in DE 123 subfield 123.9. If no Fee Type Code
corresponds to the Visa Message Reason Code, set 46.1 to (new
private) Fee Type Code 70 (Other Fee).
Using the ISO 8583:1993 definition, “A debit (‘D’) is a fee due to the
acquirer. A credit (‘C’) is a fee due from the acquirer”. Therefore the
following values will apply to set the ‘X’ in DE 46 subfield 46.3 and
46.5.
Fee Collection / Funds Disbursement Credit (C) / Debit (D)
Issuer Generated Fee Collection C
Issuer Generated Funds Disbursement D
Acquirer Generated Fee Collection D
Acquirer Generated Funds Disbursement C

Field Descriptions
3.4.29 DE 47 – National Additional Data – Card Acceptor Name (Arabic)

Position: 47
Name: National Additional Data – Card Acceptor Name (Arabic)
element.
ATM Not applicable.
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1430, 1524, 1525, 1534
Description: The Card Acceptor Name (Arabic) data element shall be used to hold the
name and location of the card acceptor as known to the cardholder.
This data element should only be present for SPAN acquired POS
transactions.
POS
01-32 32 Retailer Name (Arabic) – ISO8859-6
Arabic Character Set Standard.
If the Arabic retailer name is not available,
the default value is either “Arabic Retailer
Name Unavailable” in English or the
equivalent in Arabic.

Field Descriptions
3.4.30 DE 48 – Private Additional Data

Position: 48
Name: Private Additional Data
element.
ATM 1200, 1210, 1220, 1221, 1420, 1421, 1422, 1423, 1430, 1432
POS 1110, 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1422, 1423, 1430, 1432
Description: Card Issuer Reference Data (EFTPOS only)
01 99 Data supplied by a card issuer in an
authorisation or financial response
message, that may be used between Issuers
and EFTPOS Terminals for the transport of
Issuer specific data for Valued Added
Services. This would require an
appropriate application resident on the
EFTPOS Terminal to extract data from
Authorisation/Financial Request Response
(1110/1210) messages.
Note: Reserved for future use.
Mini Statement Details (ATM only)

For a Mini Statement Request, this field should be sent in the message to
indicate the language that is to be used to provide the mini statement data
in the response message, i.e. position 01 should be present only.
In response messages to an approved mini statement request this field will
contain the appropriate transaction details. This approach would allow a
cardholder of a particular bank to see mini statements as per the issuing
banks standard regardless of the terminal acquirer.
This field contains mini statement details and its structure is as follows:
01 1 Language indicator to specify the language
of the mini statement data. Valid values
are:
A or E.
02 1 Item count, i.e. number of mini statement
items. Valid values are:
0 to 6 inclusive.
03-38 35 Mini Statement Header (free format)
39-73 35 Mini Statement item 1 (free format)

Field Descriptions

The number mini statement details constructed should equal the item
count. For example, if item count is 0, then only item count is sent. If item
count is 1, then this field consists of the item count and mini statement
header and item 1. If item count is 2, then this field consists of the item
count, mini statement header, item 1 and item 2. etc.
Note: All Arabic fields should be in Arabic 3 (Designator 7) format (as
supported by NCR and Diebold) to ensure that no conversion from English
to Arabic is required at the ATM printer level.
Visa SMS Acquirer/Issuer Fee Collection/Disbursement Data (ATM only)
This data element is used in Acquirer and Issuer Fee related messages to
explain the reason for the message. The length of the text is not to exceed
255.
001-Var …255 Explanatory Text – This is unformatted
text that explains the purpose of the fee
collection or payment message and
expands on the reason code.
For additional information refer to [SMSATS1], Field 48, Usage 5—Visa

Fee Collections/Funds Disbursements.
Visa SMS, Adjustments, Chargeback, Chargeback Reversal &
Representment Data (ATM only)
This data element contains descriptors for the processing of Adjustments,
Chargebacks, and Representments. There are five subfields in this data
element.
001 1 Field Identifier – This is a 1 character code.
Valid values are:
V
002 1 Usage Code – This is a 1 digit code that
distinguishes between an adjustment,
chargeback and representment. Valid
values are:
0 = adjustment
1 = chargeback
2 = representment
Note: The usage code and documentation
indicator in a chargeback reversal is that
from the chargeback being reversed.

Field Descriptions
003 1 Documentation Indicator – This is a 1

position code identifying the status of the
supporting documentation. Valid values
are:
Space = No supporting documentation
required
0 = No supporting documentation provided
1 = Supporting documentation to follow
2 = Invalid acquirer reference number, and
supporting documentation was required or
received
3 = Invalid acquirer reference number, and
supporting documentation was received
4 = No supporting documentation received
004 6 Chargeback Reference Number – This is a
6 digit control number assigned by issuers
to Chargebacks in compliance with the
Operating Regulations. Acquirers that
submit Visa Representments must include
the number in the Representment message.
For Adjustments, this subfield is not
applicable and must be zero-filled.
010 50 Message Text – This is a text subfield,
which is required in all Chargebacks,
Chargeback Reversals and Representments.
Positions 10–24: Contact Name – This
alphanumeric subfield contains the name of
the person who submits the exception item
transaction at the originating institution.
Positions 25-34: Contact Phone Number –
This alphanumeric subfield contains the
phone number used to contact the person
named in the Contact Name.
Positions 35–59: Message text – This
alphanumeric subfield includes additional
information about the transaction.
For additional information and up-to-date valid values refer to

[SMSATS1], Field 48, Usage 7a — Adjustments, Chargebacks and
Representments
MasterCard MDS (Incoming request and associated responses only)
This data element is used in MasterCard MDS messages and when present,
it must be returned unchanged in the response message. It contains
Network-generated private-use information corresponding to the MDS data
element Switch Private Data (DE 126). This data is composed of a specific
MDS settlement service identifier and network symbolic information used
by the MDS for internal system routing. DE 126 also contains the Cross-
Border Transaction and Currency Indicators.

Field Descriptions
There are seven subfields in this data element.

001 3 Settlement Service Data – This is a 3 digit
numeric settlement service indicator.
Valid values are:
000 Default cutoff/non-Debit
MasterCard/non-Brazil intracurrency
001 Brazil intracurrency transactions
002 Debit MasterCard transactions
Note: The MDS may add settlement
service values at any time.
Processors/Members must be prepared to
receive any numeric three-digit value in
this field.
004 …10 MDS Private Data-1
Reserved for future use.
The length of MDS Private Data-1 may
vary by transaction. Processors must be
prepared to receive any combination of
valid alpha, numeric or special characters
in this field.
014 1 Cross Border Transaction Indicator – This
is a 1 digit (alpha, numeric or special
character) value.
Valid value are:
Y Qualifies as a Cross-Border transaction.
N Does not qualify as a Cross-Border
transaction.
015 1 Currency Indicator ans-1 – This is a 1 digit
(alpha, numeric or special character) value.
Valid value are:
X Transaction does not qualify as a Cross-
Border transaction
Y Transaction was submitted in the
currency of the merchant’s country.
N Transaction was not submitted in the
currency of the merchant’s country.
016 3 Fraud Score – This is a 3 digit (alpha,
numeric or special character) value.
Valid value are:
000 to 999
XXX
ZZZ

Field Descriptions
019 6 Fraud Risk Indicator – This is a 6 digit

(alpha, numeric or special character) value
indicating the Fraud Scoring Risk
contributing factor.
025 …26 MDS Private Data-2
Reserved for future use.
The length of MDS Private Data-2 may
vary by transaction. Processors must be
prepared to receive any combination of
valid alpha, numeric or special characters
in this field.
For additional information and up-to-date valid values refer to

[MCMDSOS], Section 4 Data Element Definitions, DE 126—Switch
Private Data.

Field Descriptions
3.4.31 DE 49 – Transaction Currency Code

Position: 49
Name: Transaction Currency Code
Representation: N3
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1430, 1422, 1423, 1432, 9620
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432
Description: The Transaction Currency Code is a code that indicates the local currency
of the acquirer or source location of the transaction. Therefore, this defines
the currency that applies to the Transaction Amount (DE 4).
Transaction Currency Code is mandatory for all financial transaction and
reversal messages.
For transactions expressed in Saudi Riyal the currency code is set to ‘682’

Field Descriptions
3.4.32 DE 50 – Reconciliation Currency Code

Position: 50
Name: Reconciliation Currency Code
Representation: N3
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1430, 1422, 1423, 1432, 1520,
1521, 1522, 1523, 1530, 1532
POS 1100, 1110, 1120, 1121, 1130,1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432, 1520, 1521, 1522, 1523, 1524, 1525, 1530, 1532,
1534
Description: The Reconciliation Currency Code is a code that defines the currency in
which reconciliation figures are expressed. This field defines the currency
that applies to the Reconciliation Amount (DE 5).
This data element is mandatory in all reconciliation messages and is
required in all financial transaction messages where the Transaction
Currency Code (DE 49) is not 682, Saudi Riyals.

Field Descriptions
3.4.33 DE 52 – Personal Identification Number (PIN) Data

Position: 52
Name: Personal Identification Number (PIN) Data
Representation: B8
element.
ATM 1200
POS 1100, 1200
Description: The Personal Identification Number (PIN) is a number assigned to a
Cardholder to uniquely identify that Cardholder at the point of service.
This element must contain the PIN in an encrypted form.
The Personal Identification Number (PIN) Data is mandatory for all ATM
transaction financial messages (both SPAN and International Bank Card
Scheme) and all SPAN Card POS transaction financial messages for
magnetic stripe cards. For SPAN chip cards at POS, the PIN is conditional
depending on whether the PIN is verified by the chip card or by the card
issuer’s systems. If successfully verified by the chip card, DE 52 is not
present. DE 52 is conditional for International Bank Card Scheme POS
financial transaction messages. The Service Code or the chip CVM list
indicates if an online PIN is required.
The Transaction Acquirer must translate the ATM encrypted PIN to a
PIN/PAN block encrypted under the acquirer Zone PIN Key (ZPK), and
load this into this field.
SPAN will translate the encrypted PIN/PAN block to the issuer Zone PIN
Key and place it in this field for delivery to the issuer.
It is the responsibility of the Card Issuer Bank to verify the PIN from the
encrypted PIN/PAN block contained in this field in its card level
processing checks. All of these functions are performed through a
Hardware Security Module (HSM).

Field Descriptions
3.4.34 DE 53 – Security Related Control Information

Position: 53
Name: Security Related Control Information
Representation: B..48
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1422, 1423, 1430, 1432, 1520,
1521, 1522, 1523, 1530, 1532
POS 1100, 1110, 1120, 1121, 1130,1200, 1210, 1220, 1230, 1420, 1421, 1422,
1423, 1430, 1432, 1520, 1521, 1522, 1523, 1524, 1525, 1530, 1532, 1534
Description: This data element contains security management information used in the
current transaction.
The value of this field (1 byte) dictates the ZPK & ZAK to be utilised in
translating the encrypted PIN block and calculation/verification of the
MAC respectively. Every financial message containing PIN Data (DE 52)
and Message Authentication Code (DE 128) must also contain this field.
Position (bits)
1-4 5-8
ZPK ZAK
Byte 1
Where the valid values are as follows.
Value (4 bits) Description
0000 Key A
0001 Key B
The possible combinations, for byte 1, are,
• 00000000 – ZPK Key A, ZAK Key A
• 00000001 – ZPK Key A, ZAK Key B
• 00010000 – ZPK Key B, ZAK Key A
• 00010001 – ZPK Key B, ZAK Key B
See SPAN Security Framework document for details.
For adjustment advices originating from the Claims Processing System
(CPS) this field contains an index used and maintained by IST.

Field Descriptions
3.4.35 DE 54 – Additional Amounts

Position: 54
Name: Additional Amounts
element.
ATM 1210
POS 1100, 1120, 1200, 1210, 1220, 1230, 1420, 1421, 1430
Description: The Additional Amounts data element holds information on up to six
amounts and related account data. Each set of values shall consist of four
parts in the following order.
Position Attrib Description
01-02 N2 Account type
Valid values are as follows.
00 Default (for Cash back)
10 Savings
20 Cheque
30 Credit
03-04 N2 Amount type
Valid values are as follows.
01 Account ledger balance
02 Account available balance
03 Account available credit
40 Amount cash (Cashback)
Only 40 (Amount cash) is currently used
for POS.
05-07 N3 Currency code
Valid values are according to ISO standard
numeric codes for currencies (always 682
for SPAN originated transactions)..
08-20 X+N12 Amount
Valid values are C+N12 or D+N12.
For Cash back only D is valid.
This field is conditional in POS financial request and advice messages and
must be present for purchase with cash-back transaction. The cash-back
amount must be populated. Where this field is present in the financial
request or advice, it must be conditional echoed in the response (to enable
correct accumulation of the cash amounts for reconciliation).
This field is also conditional in ATM financial request response messages

Field Descriptions
and must be present for approved transactions. It contains the different

balances of the account used for the transaction.
The account type subfield code of every data set in this field must be the
same as the account type code in DE3 of the response.

Field Descriptions
3.4.36 DE 55 – Integrated Circuit Card System Related Data

Position: 55
Name: Integrated Circuit Card System Related Data
Representation: B..255
Used By: The following provides a list of the messages that contain this data element.
ATM 1200, 1210, 1220,1221, 1420, 1421, 1422, 1423
POS 1100, 1110, 1120, 1121, 1130,1200, 1210, 1220, 1221, 1420, 1421, 1422,
1423
Description: This field is conditional for request/response messages and should be
present for ICC read transactions.
For SPAN or Card Scheme system generated messages and reversal
messages i.e. declined/timed out responses and reversal advices the ICC
data is conditional and will be present when available.
Note: All DE55 subfields are mandatory for SPAN transactions except
‘Issuer Script Results’ in Request/Advice Messages and ‘Issuer Script 1’
and ‘Issuer Script 2’ in Response Messages.
This data element contains data related to integrated circuit card systems, for
further details of how this field is constructed please refer to EMV Book 3 –
Application Specification, Annex B – Rules for BER-TLV Data Objects.
Note: The purpose of this field is to carry ICC related data as supplied by
the acquirer to the issuer. Hence, the fields described in this section are for
indicative purposes only and the order of the fields is not fixed.
Note: Chip data can be included but it is not required for Chargeback and
Representment messages. However, it should be noted that chip data is
required to obtain chip incentive in 1422 chargebacks and chargeback
reversals and 1220 representments for some card schemes.
Request/Advice Messages
Field Type Bytes Values Tag
Specifies the application
AIP b 16 2 functions that are 82
supported by the card.
ATC b 16 2 Retrieved from the card. 9F36
Authorisation Request
Cryptogram (ARQC) for
online transactions,
Cryptogram b 64 8 9F26
Transaction Certificate
(TC) for offline
transactions.
Cryptogram
Used to approve offline
Information b8 1 9F27
transactions.
Data
Indicates the results of the
CVM Results b 24 3 9F34
last CVM performed.

Field Descriptions
Interface Device Serial

IFD Serial # an8 8 9F1E
Number
Issuer Application Data.
LLVAR format, first byte
IAD var b ..33 9F10
indicates length, up to 32
bytes of data.

Indicates the card data
Terminal input, CVM and security
b 24 3 9F33
Capabilities capabilities of the
terminal
Terminal Specifies the type of
n2 1 9F35
Type terminal.
Status of the different
functions as seen by the
TVR b 40 5 terminal during the 95
processing of a
transaction.
Value to provide
Unpredictable variability and uniqueness
b 32 4 9F37
Number to the generation of the
application cryptogram.
Total transaction amount,
Cryptogram
including the cashback
Amount n12 6 9F02
amount in a sale with cash
Authorised
transaction.
Cryptogram
Used for a cashback
Amount n12 6 9F03
amount.
Other
Numeric country code for
Terminal the merchant terminal
n3 2 9F1A
Country Code location as specified by
ISO3166.
Transaction Numeric code for the
Currency n3 2 transaction currency as 5F2A
Code specified by ISO4217.
Transaction Local date in YYMMDD
n6 3 9A
Date format.
Indicates the type of
financial transaction,
represented by the first
two digits of
Transaction ISO 8583:1987
n2 1 9C
Type Processing Code. Note
that this is not necessarily
the same as the value in
position 1 and 2 of DE 3
Processing Code.

Field Descriptions

Indicates results of
terminal script processing.
Issuer Script LLVAR format, first byte DF01
var b ..51 indicates length, up to 20
Results
bytes of data.
See note 1
Response Messages
Authorisation This field contains the
Response an 2 2 Authorisation Response 8A
Code Code.
From the issuer
authentication data, the
first 8 bytes of this field
contain the cryptogram.
Authorisation Optional additional 1 to 8
Response bytes are proprietary.
var b 8..16 91
Cryptogram This field contains the
and Code Authorisation Response
Cryptogram (ARPC) and
may additionally contain
the ARPC Response
Code.
Commands to be
transmitted to the ICC.
LLLVAR format, first
two bytes indicate length,
up to 231 bytes of data
depending on length of
Issuer Script 2.
An Issuer Script is a
..233 constructed data object
minus containing an optional
Issuer Script
var b (length Script Identifier (tag 71
1
of 9F18) and a sequence of
Script 2) Issuer Script Commands
(each with tag 86) to be
delivered serially to the
ICC. Issuer Scripts with
tag ‘71’ are processed
prior to issuing the final
GENERATE AC
command.
See note 2.

Field Descriptions

Commands to be
transmitted to the ICC.
LLLVAR format, first
two bytes indicate length;
up to 231 bytes of data,
depending on length of
Issuer Script 1.
An Issuer Script is a
..233 constructed data object
minus containing an optional
Issuer
var b (length Script Identifier (tag 72
Script 2
of 9F18) and a sequence of
Script 1) Issuer Script Commands
(each with tag 86) to be
delivered serially to the
ICC. Issuer Scripts with
tag ‘72’ are processed
after issuing the final
GENERATE AC
command.
See note 2.
Notes:
1. No standard tag exists for Issuer Script Results. Tag DF01 indicates
Private Class Private Data Object Tag 01.
The number of Issuer Script Results currently supported by SPAN
is based on the MasterCard specifications where a maximum of 10
Issuer Scripts are supported.
2. Note: Since more than one Issuer Script Command may be present
in an Issuer Script Template, the total length of the Issuer Script
Template is variable with no theoretical upper limit. In practice the
length is restricted by network and terminal limitations, and it
should be noted that, currently, Issuer Script Templates longer than
128 bytes are not guaranteed to be processed correctly. Issuers may
send more than 128 bytes only when the Issuer knows that longer
Issuer Scripts are supported by the entire transaction path.
3. The combined lengths of Issuer Script 1 and Issuer Script 2 must
not exceed 233 bytes so DE 55 does not exceed its maximum. For
example, if Issuer Script 1 is 100 bytes in length, Issuer Script 2
cannot exceed 133 bytes.

Field Descriptions
3.4.37 DE 56 – Original Data Elements

Position: 56
Name: Original Data Elements
Representation: ANP..58
element.
ATM 1220, 1221, 1420, 1421, 1422, 1423
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430
Description: Original Data Elements is a group of six or two data elements, which are in
variable length format totalling a maximum of 58 characters including the
length of the attributes of both the Original Acquiring Institution
Identification Code and Original Forwarding institution Identification
Code.
Original Data Elements is not present in CPS adjustment transactions,
however the Primary Account Number and Retrieval Reference Number
can be used to identify the original transactions.
Note: For EFTPOS transactions where Original DE 11 Systems Trace
Audit Number and Original DE 12 Date and Time Local Transaction are
not available (i.e. Voice Authorisation Advice), these sub-fields may be
populated with default values consisting of all ‘9’s
There are uses of this field are given below.
Adjustments, Fee Collections/Disbursements, Reversals, Completions,
Representments and Chargebacks
The six data elements are as follows.
• Original message type identifier – N, 4
Default depends on the message type, the transaction source and type:
Message Type Transaction Source / Type

ATM POS
Reversal 1200 1100 (Chip)
1200 (Magnetic Stripe)
Chargeback 1200 1200
Completion N/a 1100 (Chip)
1200 (Magnetic Stripe)
Representment 1200 1200
• Original system trace audit number – N, 6

Default “000000”.
• Original transmission date and time – N, 10
Default “0000000000”.
• Original local transaction date and time – N, 12

Field Descriptions
Default “000000000000”.
• Original acquiring institution identification code – N..11
Default “00”.
• Original forwarding institution identification code – N..11
Default “00”.
Original Data Elements is mandatory for reversal and chargeback
messages. The values of these fields are to be taken from the original
response message. This is present for adjustments or representments if the
data is available.
Note: For transactions where Original DE 7 Transmission Date and Time,
Original DE 11 Systems Trace Audit Number, Original DE 12 Date and
Time Local Transaction and Original DE 37 Retrieval reference number
are not available (e.g. Voice Authorisation Advice), these sub-fields may
be populated with default values consisting of all zeros. If Original DE 32
Acquirer Institution Identification Code or Original DE 33 Forwarding
Institution Identification Code are not available, the length of these sub-
fields is set to zero.
Note: this format (both sub-elements and representation) is a deviation
from the ISO standard to cater for the Visa and Mastercard formats.
Refunds
The structure below is used for POS Authorisation Request / Advice
(1100/1120) or POS Financial Request / Financial Transaction Advice
(1200/1220) messages when the Processing Code (DE 3) contains the
value "20XXXX" (Refund).
01-04 4 Original message type – the message type
identifying the original transaction. Must be set to
1200.
05-16 12 Retrieval Reference Number (DE 37) of the
original purchase transaction as keyed by the
Retailer.

Field Descriptions
3.4.38 DE 59 – Transport Data

Position: 59
Name: Transport Data
Representation: ANS...999
element.
ATM 1200, 1210, 1420, 1421, 1422, 1423, 1430, 1432
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432
Description: Contains data from the originator of the message that shall be returned
unaltered in a response message.
This field will be utilised for bill payment transactions and will have the
following content
POS Length Description
1-5 5 Biller Code (e.g. STC)
6-20 15 Bill Reference (i.e. Bill Number)
For Pre-pay Token, the content of this field is as follows.

POS Length Description
1-20 20 Text description of the token

Field Descriptions
3.4.39 DE 60 – POS Terminal Data

Position: 60
Name: POS Terminal Data
Representation: ANS…999
element.
ATM Not applicable.
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432
Description: Additional POS Terminal Data is used to route Retailer Advice
transactions.
01-04 4 Terminal Owner ID - The ID of the Retailer
Bank owning the terminal (as for FIID). See
Section 10.
05-08 4 Pseudo Terminal ID - Value used by Bank
Card Scheme interchanges to identify
terminals (Reserved for future use) (Zero
filled).
For the CPS system set first four characters
to the terminal owner id from the CLAIMS
table (term_owner_id), set the next four
characters to 0. Three digits containing
length should be set before this field.

Field Descriptions
3.4.40 DE 62 – Private Field – Terminal Status

Position: 62
Name: POS Terminal Status
Representation: ANS…999
element.
ATM Not applicable.
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1304, 1305,
1314, 1420, 1421, 1430, 1524, 1525, 1534, 1814
Description: Defined for Terminal Monitoring Statistics.
For request messages, this field contains:
Tag ID Sub-Field
01 Terminal Dial Indicator
02 Printer Status
03 Idle Time
04 Magnetic Reader Status
05 Chip Card Reader Status
This field is present in the Terminal Reconciliation Advice/Repeat sent to

the Retailer Bank only (not Card Scheme Acquirer Bank) and is not
present for SPAN-generated Terminal Reconciliation Advice/Repeat
messages (Request Reconciliation) i.e. present in 1524 and 1525 only.
The tags are used for the interface are described below:
Terminal Dial Indicator

Description: Indicates how many times the terminal tried to establish a connection.
Subfield Type Values
Tag Id AN 2 ‘01’
Terminal Dial AN 1 '1' - '9', 'A' - 'F' (i.e. total range
Indicator is '1'-'F').

Field Descriptions
Printer Status
Description: Indicates the health of the receipt printer.
Printer Status AN 1 '0' = No printer.
'1' = Out of paper.
'2' = Plain paper receipt.
Idle Time
Description: Contains the idle time of the EFTPOS terminal. The time since the
terminal last contacted SPAN to send a message.
Idle Time hhmmss Not to exceed the first 24 hours.
Magnetic Reader Status

Description: Indicates the health of the magnetic stripe reader.
Magnetic Reader AN 1 '0' = Okay.
Status '1' = Out of order.
Chip Card Reader Status

Description: Indicates the health of the chip card reader.
Chip Card Reader AN 1 '0' = Okay.
Status '1' = Out of order.

Field Descriptions
3.4.41 DE 72 – Data Record
Position: 72
Name: Data Record
Representation: ANS...999
element.
ATM 1644, 9620
POS 1644
Description: Other data required to be passed to support an administrative or file action
message.
Note: as an exception to ISO8583:1993 this field can also accept binary
data.
Card Capture
This field is required for 1624 Administrative Advice messages and is used
to provide details of the card and its capture.
Fraud Advice (VISA SMS Only)
Member banks must supply additional fraud related information in this
field for Visa SMS Fraud Advice (9620) messages as described in the SMS
ATM Technical Specifications – DE 125 Supporting Information, Usage
7:Additional Fraud Information.
Rejected Messages
The field is also used for rejected messages. In such case it will contain the
contents of the rejected message.
Free Format Text
This field is free format text where not used to hold a rejected message. As
an exception to ISO8583:1993 this field can also accept binary data.

Field Descriptions
3.4.42 DE 74 – Number Credits

Position: 74
Name: Number Credits
element.
ATM 1520, 1521, 1522, 1523, 1530, 1532
POS 1520, 1521, 1522, 1523, 1530, 1532
Description: The Number Credits element is the sum number of all financial
transactions (ISO8583 Financial Message Class) where positions 1-2 of the
processing code in the financial transaction indicated a credit (20-29) and
the transaction is approved/accepted.
This element is mandatory in all reconciliation advice messages (1520,
1521, 1522, and 1523).
This field is conditional in response messages (1530 and 1532). It is not
included if action code is ‘500’.

Field Descriptions
3.4.43 DE 75 – Reversal Number Credits

Position: 75
Name: Reversal Number Credits
element.
ATM 1520, 1521, 1522, 1523, 1530, 1532
POS 1520, 1521, 1522, 1523, 1530, 1532
Description: The Reversal Number Credits element is the sum number of all reversal
transactions (of ISO8583 Financial Message Class transactions) where
positions 1-2 of the processing code in the reversal transaction indicated a
debit (00-19) and the transaction was accepted
1521, 1522, and 1523).

Field Descriptions
3.4.44 DE 76 – Number Debits

Position: 76
Name: Number Debits
element.
ATM 1520, 1521, 1522, 1523, 1530, 1532
POS 1520, 1521, 1522, 1523, 1530, 1532
Description: The Number Debits element is the sum number of all financial transactions
(ISO8583 Financial Message Class where positions 1-2 of the processing
code in the financial transaction indicated a debit (00-19) and the
transaction is approved/accepted.
1521, 1522, and 1523).

Field Descriptions
3.4.45 DE 77 – Reversal Number Debits

Position: 77
Name: Reversal Number Debits
element.
ATM 1520, 1521, 1522, 1523, 1530, 1532
POS 1520, 1521, 1522, 1523, 1530, 1532
Description: The Reversal Number Debits element is the sum number of all reversal
transactions (of ISO8583 Financial Message Class transactions) where
positions 1-2 of the processing code in the reversal transaction indicated a
credit (20-29) and the transaction was accepted.
1521, 1522, and 1523).

Field Descriptions
3.4.46 DE 80 – Number Inquiries

Position: 80
Name: Number Inquiries
element.
ATM 1520, 1521, 1522, 1523, 1530, 1532
POS 1520, 1521, 1522, 1523, 1530, 1532
Description: The Number Inquiries element is the sum number of all authorisation
transactions where positions 1-2 of the processing code in the authorisation
transaction indicated an inquiry (30-39) and the transaction is
approved/accepted.
1521, 1522, and 1523).

Field Descriptions
3.4.47 DE 81 – Number Authorisations

Position: 81
Name: Number Authorisations

element.
ATM Not applicable.
POS 1520, 1521, 1522, 1523, 1530, 1532
Description: The Number Authorisations element is the count of all authorisation
transactions (of ISO8583 Authorisation Message Class transactions) and
indicated by a processing code 00-29 or 90 and the transaction is
approved/accepted.

Field Descriptions
3.4.48 DE 86 – Amount Credits

Position: 86
Name: Amount Credits
element.
ATM 1520, 1521, 1522, 1523, 1530, 1532
POS 1520, 1521, 1522, 1523, 1530, 1532
Description: The Amount Credits element is the sum of Transaction Amount (DE 4) in
all financial transactions (ISO8583 Financial Message Class) exclusive of
fees where positions 1-2 of the processing code in the financial transaction
indicated a credit (20-29) and the transaction is approved/accepted.
1521, 1522, and 1523).

Field Descriptions
3.4.49 DE 87 – Reversal Amount Credits

Position: 87
Name: Reversal Amount Credits
element.
ATM 1520, 1521, 1522, 1523, 1530, 1532
POS 1520, 1521, 1522, 1523, 1530, 1532
Description: The Reversal Amount Credits element is the sum of Transaction Amount
(DE 4) in all financial transactions reversals (of ISO8583 Financial
Message Class transactions)exclusive of fees where positions 1-2 of the
processing code in the financial transaction indicated a debit (00-19) and
the transaction is accepted.
1521, 1522, and 1523).

Field Descriptions
3.4.50 DE 88 – Amount Debits

Position: 88
Name: Amount Debits
element.
ATM 1520, 1521, 1522, 1523, 1530, 1532
POS 1520, 1521, 1522, 1523, 1530, 1532
Description: The Amount Debits element is the sum of Transaction Amount (DE 4) in
all financial transactions (ISO8583 Financial Message Class) exclusive of
fees where positions 1-2 of the processing code in the financial transaction
indicated a debit (00-19) and the transaction is approved/accepted..
1521, 1522, and 1523).

Field Descriptions
3.4.51 DE 89 – Reversal Amount Debits

Position: 89
Name: Reversal Amount Debits
element.
ATM 1520, 1521, 1522, 1523, 1530, 1532
POS 1520, 1521, 1522, 1523, 1530, 1532
Description: The Reversal Amount Debits element is the sum of Transaction Amount
(DE 4) in all financial transactions reversals (of ISO8583 Financial
Message Class transactions) exclusive of fees where positions 1-2 of the
processing code in the financial transaction indicated a credit (20-29) and
the transaction is accepted..
1521, 1522, and 1523).

Field Descriptions
3.4.52 DE 93 – Transaction Destination Institution Identification Code

Position: 93
Name: Transaction Destination Institution Identification Code
element.
ATM 1624, 1634, 1644, 1804, 1814, 1824, 1825, 1834
POS 1644, 1804, 1814, 1824, 1825, 1834
Description: The Transaction Destination Institution Identification Code is a code
identifying the institution that is the transaction destination (see Section
10).
The Transaction Destination Institution ID Code remains unchanged
throughout the transaction.

Field Descriptions
3.4.53 DE 94 – Transaction Originator Institution Identification Code

Position: 94
Name: Transaction Originator Institution Identification Code
element.
ATM 1624, 1634, 1644, 1804, 1814, 1824, 1825, 1834
POS 1644, 1804, 1814, 1824, 1825, 1834
Description: The Transaction Originator Institution Identification Code is a code
identifying the institution that is the transaction originator (see Section 10).
The Transaction Originator Institution ID Code remains unchanged
throughout the transaction.

Field Descriptions
3.4.54 DE 96 – Key Management Data

Position: 96
Name: Key Management Data
Representation: B…999
Used By: The following provides a list of the messages that contain this data element.
ATM 1804, 1814
POS 1804, 1814
Description: Contains data related to key management.
The information in this element is used for Network Management Messages.
This data element is conditional for 1804 and 1814 messages. This field must
be sent only for key management request or logon.
ZWK Key Update
This field is required in Key Update Response messages and is echoed back
to SPAN.
The structure of this field for Key Update request messages is detailed as
follows. Key Update Request messages are type 1804 Network Management
Messages where the Function Code field = "811". The values indicated are
those required for Key Update Requests from SPAN to the Bank.
The length sub-fields contain 16 bit binary values.
Subf Position Length Description
ield
96.1 01 B1 Key change indicator. Valid values in
binary are:
00000001 – PIN Key (ZPK) exchange
00000010– MAC Key (ZAK) exchange
96.2 02 B1 Indicates the key, which the Bank should
update and use for all new transaction
requests with a PIN or a MAC. Valid
values in binary are:
00000001 – Key A
00000010 – Key B
96.3 03 B1 Working key length indicator. This field
defines the number of bytes in the
working key. Valid values in binary are:
00010000 – Indicates a double length
key (ie: 16 byte / 128 bit key)
96.4 Variable Var Encryption key – the new working key
(based on encrypted under the ZMK. Currently, the
binary key length (as indicated by 96.3) is B 16
length in (ie: 128 bits).
96.3)
96.5 Variable B2 Check digits – a value generated by the
key function used to check
synchronisation of the ZWK. The 16
least significant bits of the generated
check value.
Logon

Field Descriptions
This field is required in Logon Response messages and is not echoed but
calculated as detailed in Section 7.3.2.1.
This field must have the following format in a logon request message which
is a Network Management Message type 1804 where Function Code field is
"801". The values indicated are those required for logon requests from the
Bank to SPAN, and from SPAN to the Bank.
The length sub-fields contain 16 bit binary values.
Subfi Position Length Description

eld
96.1 01-02 B2 Digital signature length indicator.
Value is binary.
96.2 Variable Var Digital signature calculated by
(based Bank or SPAN switch based on
on binary the Random string sequence and
length in additional fields, as per the
96.1) signature fields table in Section 7.
Value is in binary.
96.3 Variable B2 Random string sequence length
indicator.
The value of this random string is
a double length DES key, hence
current valid values in binary are:
00000000 00010000 – Indicates a
double length string (ie: 16 byte / 128
bit)
96.4 Variable Var Random string sequence. (i.e. a
(based double length DES key). Currently,
on binary the sequence length (as indicated by
length in 96.3) is B 16 (ie: 128 bits).
96.3)
See Section 7 - Network Security for more information.

Field Descriptions
3.4.55 DE 97 – Net Reconciliation Amount

Position: 97
Name: Net Reconciliation Amount
Representation: X+N 16
element.
ATM 1520, 1521, 1522, 1523, 1530, 1532
POS 1520, 1521, 1522, 1523, 1530, 1532
Description: The Net Reconciliation Amount shall be calculated by netting the debit and
credit amounts in the reconciliation message. Reconciliation in multiple
currencies shall use a separate reconciliation transaction for each currency.
All amounts in the reconciliation messages are in the currency of
reconciliation.
The Net Reconciliation Amount is calculated by summing the Fee
Amounts Credits, Amount Credits, Reversal Amount Credits and the
Chargeback Amount Credits and subtracting the sum of the Fee Amounts
Debits, Amount Debits, Reversal Amount Debits and Chargeback Amount
Debits.
Net Reconciliation Amount = Credit Totals – Debit Totals
Where,
Credit Totals = Amount Credits +
Reversal Amount Credits +
Chargeback Amount Credits
Debit Totals = Amount Debits +
Reversal Amount Debits +
Chargeback Amount Debits
The Amount Credits element is the sum of Transaction Amount (DE 4) in
all financial transactions exclusive of fees where positions 1-2 of the
processing code in the financial transaction indicated a credit (20-29).
The Reversal Amount Credits element is the sum of Transaction Amount
(DE 4) in all financial transactions exclusive of fees where positions 1-2 of
the processing code in the financial transaction indicated a debit (00-19).
The Amount Debits element is the sum of Transaction Amount (DE 4) in
all financial transactions exclusive of fees where positions 1-2 of the
processing code in the financial transaction indicated a debit (00-19).
The Reversal Amount Debits element is the sum of Transaction Amount
(DE 4) in all financial transactions exclusive of fees where positions 1-2 of
the processing code in the financial transaction indicated a credit (20-29).
The Chargeback Amount Credits element is the sum of Transaction
Amount (DE 4) in all chargeback transactions exclusive of fees where
positions 1-2 of the processing code in the chargeback transaction
indicated a debit (00-19).
The Chargeback Amount Debits element is the sum of Transaction
positions 1-2 of the processing code in the chargeback transaction

Field Descriptions
indicated a credit (20-29).

The net reconciliation position for a Bank is calculated by subtracting its
position as a Card Issuer Bank from its position as an Retailer / Acquirer
Bank, i.e.:
Net Reconciliation Position
= Position as an Retailer / Acquirer Bank
– Position as a Card Issuer Bank
A positive amount signifies that the Bank has a net credit position. A
negative amount represents a net debit position. See section 5.7.

Field Descriptions
3.4.56 DE 100 – Receiving Institution Identification Code

Position: 100
Name: Receiving Institution Identification Code
element.
ATM 1210, 1230, 1430, 1432, 9630
POS 1110, 1120, 1121, 1130, 1210, 1220, 1221, 1230, 1420, 1421, 1430, 1432
Description: Receiving Institution Identification Code identifies the intended recipient
institution of the request message.
This data element is a unique identifier for the financial institution
assigned by SPAN. It provides a reference to the institution that authorised
the acquired transaction. For SPAN Card and Saudi Bank Non-SPAN
Card transactions, this field is a unique identifier for each financial
institution in the SPAN network. SPAN-assigned values are documented
in Section 10 of this manual. For Foreign Bank transactions, the
International Bank Card Scheme Interface puts its identifier in this field.

Field Descriptions
3.4.57 DE 105 – Chargeback Amount Credits

Position: 105
Name: Chargeback Amount Credits
element.
ATM 1520, 1521, 1522, 1523, 1530, 1532
POS 1520, 1521, 1522, 1523, 1530, 1532
Description: The Chargeback Amount Credits element is the sum of Transaction
positions 1-2 of the processing code in the financial transaction indicated a
debit (00-19).
1521, 1522, and 1523).

Field Descriptions
3.4.58 DE 106 – Chargeback Amount Debits

Position: 106
Name: Chargeback Amount Debits
element.
ATM 1520, 1521, 1522, 1523, 1530, 1532
POS 1520, 1521, 1522, 1523, 1530, 1532
Description: The Chargeback Amount Debits element is the sum of Transaction
positions 1-2 of the processing code in the financial transaction indicated a
credit (20-29).
1521, 1522, and 1523).

Field Descriptions
3.4.59 DE 107 – Chargeback Number Credits

Position: 107
Name: Chargeback Number Credits
element.
ATM 1520, 1521, 1522, 1523, 1530, 1532
POS 1520, 1521, 1522, 1523, 1530, 1532
Description: The Chargeback Number Credits element is the sum of all chargeback
transactions exclusive of fees where positions 1-2 of the processing code in
the financial transaction indicated a debit (00-19).
1521, 1522, and 1523).

Field Descriptions
3.4.60 DE 108 – Chargeback Number Debits

Position: 108
Name: Chargeback Number Debits
element.
ATM 1520, 1521, 1522, 1523, 1530, 1532
POS 1520, 1521, 1522, 1523, 1530, 1532
Description: The Chargeback Number Debits element is the sum of all chargeback
transactions exclusive of fees where positions 1-2 of the processing code in
the financial transaction indicated a credit (20-29).
1521, 1522, and 1523).

Field Descriptions
3.4.61 DE 122 – Card Scheme Sponsor ID/Card Scheme ID

Position: 122
Name: Card Scheme Sponsor ID/Card Scheme ID
Representation: AN...999
element.
ATM Not applicable.
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432
Description: The Card Scheme Sponsor Identifier, assigned by SPAN, is a unique
identifier for the financial institution. It contains the identifier of the Card
Scheme Acquirer Bank, which agrees to settle a Bank Card Scheme's
transactions. Each Retail location must have an exclusive commercial
relationship with the Bank for each Card Scheme. The Card Scheme
Acquirer Bank will receive an online advice from SPAN when it is not the
SPAN Retailer Bank.
The Card Scheme ID, assigned by SPAN, is an identifier of the card
scheme or card type for this transaction.
SPAN-assigned values are documented in Section 10 of this manual.
The structure of this data element is as follows.
01-04 4 Card Scheme Sponsor ID
05-06 2 Card Scheme ID
Where a transaction is routed to SPAN from outside the Kingdom (from
International Bank Card Schemes or GCC), the Card Scheme Sponsor Id
should remain blank and the Card Scheme Id should identify the Card
Type. For example, if IST/Switch receives an incoming Maestro card
(NCB dual branded card), then this field would be defined as
Card Scheme Sponsor ID = 4 blanks
Card Scheme ID = DM
For POS CPS this field is mandatory and positions 05-06 must be set to P1
(see Section 10). This field is not present for ATM CPS.

Field Descriptions
3.4.62 DE 123 – Card Scheme Information

Position: 123
Name: Card Scheme Information
Representation: AN..255
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1422, 1423, 1430, 1432, 1624,
1634, 9620, 9630
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1430
Description: The Card Scheme Information field is used by SPAN to provide the Card
Scheme Acquirer Bank with transaction information necessary to perform
settlement with International Bank Card Schemes. The Card Scheme
Acquirer Bank is responsible for the financial settlement for International
Bank Card Scheme transactions. Settlement is performed completely
outside the SPAN network. However, SPAN supplies all available
transaction information to the Card Scheme Acquirer Bank via the Card
Scheme Information field (DE 123).
POS
This is a conditional field for POS transactions and is only present for Visa
& MasterCard transactions.
The Card Scheme Information field is sent to the Retailer Bank/Card
Scheme Acquirer Bank but not both.
• The Retailer Bank receives DE 123 when it is also the Card Scheme
Acquirer Bank.
• When the Retailer Bank is not the same institution as the Card Scheme
Acquirer Bank, the Card Scheme Acquirer Bank receives the advice
message with DE 123 present. The Retailer Bank receives the same
advice message but without DE 123.
The following table explains the options for the various POS message
types:
Retailer Bank IS NOT
Retailer Bank IS
Card Scheme Acquirer Bank
Card Scheme
Acquirer Bank Card Scheme
Retailer Bank
Acquirer Bank
1120/1 with DE123 1120/1 without DE123 1120/1 with DE123
ATM
This is a mandatory field for ATM transactions and is present for all card
schemes including SPAN, GCC-Net, MasterCard and Visa transactions
(for detailed descriptions of each sub field refer to the appropriate card
Field Descriptions
scheme specification).
DATA ELEMENT STRUCTURE (ATM & POS)

The field structure is documented below. Appendix E provides detailed
usage requirements for each card scheme based on the point-of-service.
Position Len Description
DE 123 Bitmap
8 byte hexadecimal field (AN 8) required
in all messages, representing 32 bits of
123.0 8 data which identify the presence (denoted
by 1 or "bit on") or absence (denoted by 0
or "bit off") of the sub-elements in this
data element. The first bit represents the
sub-element 123.1 and not the bitmap
123.1 6 Trace Audit Number
123.2 12 Retrieval Reference Number
123.3 11 Acquiring Institution Identification Code
Original Response Code
123.4 2 [Authorization Response Code changed to
just Original Response Code]
Response Source/Reason Code
123.5 1 [Authorisation Source Code changed to
match Visa data element name]
Reserved for future use
123.6 1 [POS Terminal Capability superseded by
DE 22, position 1]
Authorization Characteristics Indicator
[Payment Service Indicator changed to
123.7 1 match Visa data element name
Authorization Characteristics Indicator;
also removal of default value]
123.8 15 Transaction Identifier
Message Reason Code
123.9 4 [Reserved for future use – utilised for

Message Reason Code as part of earlier
Visa SMS Exception Messages update]
123.10 1 CVV/iCVV Results Code
Network Identification Code – 4N 4-bit
123.11 2
BCD
STIP/Switch Reason Code – 4N 4-bit
123.12 2
BCD

Field Descriptions

[Plus Proprietary Member Centre ID – 6N
123.13 3 4-bit BCD no longer used in Visa SMS as
of April 2008 VisaNet Business
Enhancements]
123.14 14 Fraud Data
123.15 1 Reimbursement Attribute
Decimal Positions Indicator – 6N 4-bit
123.16 3
BCD
123.17 9 [Settlement Amount, Acquirer Currency

Conversion Fee Allocation no longer used
in Visa SMS]
123.18 2 Settlement Date – 4N 4-bit BCD
123.19 3 PAN extended, country code – 3N
123.20 1 [Chargeback/Re-presentment document

indicator – 1N superseded by new DE 48
definition for Visa SMS]
123.21 6 [Chargeback reference number – 6N

superseded by new DE 48 definition for
Visa SMS]
123.22 9 [Plus – Timestamp. 9 digit assigned by the

Plus network (hhmmssnnn) no longer
used in Visa SMS]
Multiple clearing sequence number. 2N
123.23 1
4-bit BCD
123.24 11 Forwarding Institution Identification Code
Card Scheme Acquirer Banks should log DE 123 on their internal log file
in order to settle with the International Bank Card Schemes.
Information on how to map ISO interface fields to Visa and MasterCard
reconciliation fields can be found in Section 8 - International Bank Card
Scheme Processing.

Field Descriptions
3.4.63 DE 124 – SPAN POS Terminal Reconcile Total

Position: 124
Name: SPAN POS Terminal Reconcile Total
element.
ATM Not applicable.
POS 1524, 1525
Description: The SPAN POS Reconciliation Totals is used to carry terminal transaction
activity. The transaction details are calculated by the terminal for each
card scheme accepted at that terminal.
The SPAN POS Reconciliation Totals are conditional for 1524 and 1525
messages. The Terminal Totals are present both when the terminal totals
and SPAN totals agree, and when they do not agree. Terminal Totals are
not present when a 1524 or 1525 is sent (with a Function Code of 572)
because a Retailer Bank has issued a Request reconciliation for the POS
terminal (DE 39 is set to "504"). In this situation, only SPAN totals (DE
127) are present.
The structure of the SPAN POS Reconciliation Totals is given below.
Included for the record is the length, each field position in the element, and
a description of the contents. The number of Card Scheme Totals
contained in this message is variable, and is determined by the Number of
Card Schemes (positions 01-02).
The structure of DE 124 is as follows:
01-02 2 Number of Card Schemes
(values from 01 to 10)
03-98 96 Card Scheme Totals – 01
The 96 characters making up each of the Card Scheme Total fields are
made up of the following data:
Subfield Length Description
124.1 2 Card Scheme ID
124.2 4 Card Scheme Acquirer ID
124.3 10 Debit Count
124.4 15 Debit Amount
124.5 10 Credit Count
124.6 15 Credit Amount
124.7 15 Cashback Amount
124.8 15 Cash Advance Amount
Field Descriptions
124.9 10 Authorisation Count
Note: Card Scheme ID is assigned by SPAN for each bank card scheme
registered with SPAN.
See section 5.5 for details of how transactions are accumulated against
these subfields.
SPAN-assigned values are documented in Section 10 of this manual.

Field Descriptions
3.4.64 DE 126 – Bank Card Scheme Totals Information

Position: 126
Name: Bank Card Scheme Totals Information
element.
ATM 1520, 1521, 1522, 1523, 1530, 1532
POS 1520, 1521, 1522, 1523, 1530, 1532
Description: The Bank Card Scheme Totals Information is used to carry additional
detailed settlement information. This field contains the combined totals of
all bank card scheme transactions. This field is for statistical use only, and
is not used for financial settlement.
The Bank Card Scheme Totals Information is mandatory for 1520, 1521,
1522 and 1523 messages. The message can be from SPAN to either the
Card Issuer Bank (1520, 1521) or Acquirer/Retailer Bank (1522, 1523), or
from the Card Issuer Bank (1530) or Acquirer/Retailer Bank (1532) to
SPAN.
The structure of the Bank Card Scheme Totals Information is given below.
Included for each record is the length, each field position in the element,
and a description of the contents.
Subfield Position Length Description
126.1 01-10 10 Number Credits
126.2 11-20 10 Number Reversal Credits
126.3 21-30 10 Number Debits
126.4 31-40 10 Number Reversal Debits
126.5 41-50 10 Number Inquiries
126.6 51-65 15 Amount Credits
126.7 66-80 15 Amount Reversal Credits
126.8 81-95 15 Amount Debits
126.9 96-110 15 Amount Reversal Debits
126.10 111-120 10 Number Authorisations
these subfields.

Field Descriptions
3.4.65 DE 127 – SPAN POS SPAN Reconcile Total

Position: 127
Name: SPAN POS SPAN Reconcile Total
element.
ATM Not applicable.
POS 1524, 1525
Description: The SPAN POS SPAN Reconciliation Totals is used to carry terminal
transaction activity. The transaction details are calculated by SPAN for
each card scheme accepted at that terminal.
The SPAN POS SPAN Terminal Reconciliation Totals are conditional for
1524 and 1525 terminal reconciliation messages. The SPAN POS SPAN
Terminal Reconciliation Totals are present when the terminal and SPAN
terminal totals do not agree on the totals calculated by the terminal, and
when the Retailer Bank requests a force reconciliation of the Retailer's
POS terminal (Function Code of '571'), or when the Retailer Bank requests
reconciliation data for a Retailer’s POS terminal that is unable to send its
totals (Function Code of ‘572’).
The structure of the SPAN POS Reconciliation Totals is given below.
Included for each record is the length, each field position in the element,
and a description of the contents. The number of Card Scheme Totals
contained in this message is variable, and is determined by the Number of
Card Schemes (positions 01-02).
01-02 2 Number of Card Schemes
(values from 01 to 10)
The 96 characters making up each of the Card Scheme Total fields are
made up of the following data:
Subfield Length Description
127.1 2 Card Scheme ID
127.2 4 Card Scheme Acquirer ID
127.3 10 Debit Count
127.4 15 Debit Amount
127.5 10 Credit Count
127.6 15 Credit Amount

Field Descriptions
127.7 15 Cashback Amount

127.8 15 Cash Advance Amount
127.9 10 Authorisation Count
Note: Card Scheme ID is assigned by SPAN for each bank card scheme
registered with SPAN.
these subfields.

Field Descriptions
3.4.66 DE 128 – Message Authentication Code Field

Position: 128
Name: Message Authentication Code Field
Representation: B8
element.
ATM 1200, 1210, 1220, 1221, 1230, 1420, 1421, 1430, 1422, 1423, 1432, 1520,
1521, 1522, 1523, 1530, 1532
POS 1100, 1110, 1120, 1121, 1130, 1200, 1210, 1220, 1221, 1230, 1420, 1421,
1422, 1423, 1430, 1432, 1520, 1521, 1522, 1523, 1524, 1525, 1530, 1532,
1534
Description: This data element is used to validate the source and the text of the message
between the sender and the receiver.
The field length used in the SPAN network is 4 Bytes in length (8 Hex). As
the field definition is capable of accommodating 8 Bytes only the left 4
bytes will be used for the MAC and the right 4 bytes will be padded with
F’s.

Transaction Flows
Section 4 Transaction Flows
4.1 Introduction
This section is included to provide a complete picture of the ISO 8583:1993 based message flows. The
message flows are included for the following message classes,
• Network Management
• Messages related to ATM originated transactions that are exchanged between SPAN, the ATM
Acquirer Bank, and the Card Issuer Bank.
• Messages related to POS originated transactions that are exchanged between SPAN, the Retailer
Bank, and the Card Issuer Bank.
Normal processing steps are highlighted for each transaction with special emphasis on the processing
required from the Bank's standpoint. Exception processing is also detailed with expected Response
Codes and Bank processing requirements.
Occasionally, where applicable, SPAN processing is included to provide a clearer definition of the total
transaction processing for each EFT request.
Not all messages involve both an Acquirer Bank (or Retailer Bank) and Card Issuer Bank relationship
with SPAN. Network Management messages and Reconciliation messages require only a single Bank
to SPAN relationship.
For Network Management, Administrative and Financial messages, the Function Code is provided to
further clarify the message content. Network Management messages also contain one Product
Indicator in the SPAN Header. (See Section 3 - Field Descriptions for details on the SPAN Header.)
In some instances, where a message does not arrive at SPAN or the Bank, the message flow indicator is
partially drawn (in the direction of flow) and a "•" head is used to indicate the message did not
complete.
Each message is numbered. Be sure to match the number with the text. Do not assume that each
message sequence starts at the top and continues down sequentially. The numbers indicate the actual
order of the messages as described in the text.
4.2 Additional Reference

The message flows are not designed to provide a complete specification for developing processing
systems. They do, however, provide significant emphasis on the functional processing requirements of
each message. In order to gain a complete definition of all processing required, this section must be
reviewed along with Section 2 - Message Formats, and Section 3 - Field Descriptions. Functions
related to Network Management messages and Reconciliation Messages are further described and
explained in the respective sections. Mandatory, Conditional, and Optional fields for each message
type are fully described in these sections and should be referenced throughout the review and use of
this section.
This section illustrates the following message flows through SPAN:
• Network Management Messages
• Administrative Messages
• Rejected Messages
• Financial Transaction Messages
• Exception Messages
• Reconciliation Messages

Transaction Flows
4.2.1 Reversals
The purpose of this section is to explain the principles governing reversal processing in the MBI.
When SPAN is operating as an acquirer it receives transactions from the following sources:
• Directly connected POS terminals
• Directly connected ATMs
• KSA Bank Acquirers (ATMs)
These transactions can be routed to any one of the following for authorisation:
• KSA Bank Card Issuers
• GCC-Net
• Visa Base 1 (POS)
• Visa SMS (ATM)
• MasterCard Debit (MDS)
• MasterCard Credit
• AMEX (ATM/POS) via SAIB
A Reversal can be generated in the MBI for a number of reasons:
• Cancellation at device
• Timeout of the Response by the Acquirer or SPAN
SPAN member banks are not permitted to send a partial reversal through SPAN. There are no partial
reversals from:
• SPAN POS terminals
• Directly connected SPAN ATMs
• KSA acquirers
However partial reversals can be received from those IBCS interfaces where SPAN receives
transactions on behalf of a KSA card issuer. These are routed to the card issuer.
Cancellation at the Device
A transaction can fail to take place for a number of different reasons at the device. For example:
• Customer cancellation
• Retailer cancellation (POS)
• Device exception
• Message corruption
In the case of an ATM, these conditions are usually signalled from the device to KSA Card Acquirer or
SPAN by use of a Completion or Exception Message. A Reversal is then generated from the KSA
Acquirer Bank or SPAN for onward processing. If a completion message is lost, the next transaction
indicates the status of the previous transaction.
POS devices indicate a cancellation of a current transaction by sending an explicit Reversal transaction
to SPAN. This Reversal is forwarded by SPAN to the appropriate authoriser. See the Terminal
Interface Specification for more information about POS operation.
Timeouts

Transaction Flows
At each stage of a transaction (at the device, at the KSA Acquirer, at SPAN) a transaction timer is set.
The device has the longest timer, the other timers must be set so that SPAN times out before the
acquirer or the device.
As a general principle, if a timeout on the Response to Financial Transaction is detected, a Reversal
should be generated by the system that registers the time out. However the timing of the transmission
of this Reversal can be dictated by the rules of the particular card scheme involved.
The following table gives an overview of some of the Response time-out conditions that apply:
Timeout Transaction Process at KSA
Process at SPAN Process at Device
Condition Origin Card Acquirer
Time-out
Decline Response
SPAN times out Generate and send a
Directly received within
Authoriser (no decline Response to the
connected None time out period.
or late response origin.
ATM No special
at SPAN)
Reverse to the processing.
Authoriser*
Time-out
Decline Response
SPAN times out
Generate a decline received within
Authoriser (no KSA Card
Response to the origin. time out period.
or late response Acquirer
No special
at SPAN) Reverse to the
processing.
Authoriser*
Time-out
Decline Response
SPAN times out Generate and send a
Directly received within
Authoriser (no decline Response to the
connected None time out period.
or late response origin.
POS No special
at SPAN)
Reverse to the processing.
Authoriser*
Received Response in
time Time-out
ATM times out Response sent to Decline to the
Directly
SPAN (no or device Customer.
connected None
late Response
ATM Reversal generated on Completion from
from SPAN)
decline completion ATM to SPAN
forwarded to indicates decline.
Authoriser*

Transaction Flows
Timeout Transaction Process at KSA

Process at SPAN Process at Device
Condition Origin Card Acquirer
Time-out
Either
1) No Action,
allows device to
Received Response in Time-out
time out
Card Acquirer time
Decline to the
times out SPAN Reversal
KSA Card Response sent to Customer.
(no or late generated on
Acquirer acquirer
Response from receipt of decline Completion from
SPAN) Reversal forwarded to completion ATM to SPAN
Authoriser* indicates decline.
2) Decline to
device. Reverse
to SPAN
immediately on
timeout
Received Response in Time-out
Device times Received
time
out Card Response in time Decline to the
Acquirer (no or KSA Card Response sent to Customer.
Response sent to
late Response Acquirer acquirer
Device Completion from
from Card
Reversal forwarded to ATM to SPAN
Acquirer)
Authoriser* indicates decline
Received Response in
Time-out
time
POS times out
Directly Decline to the
SPAN (no or Response sent to
connected None Customer.
late Response device
POS
from SPAN) Generate Reversal
Reversal forwarded to
to SPAN
Authoriser*
*This table shows general principles and takes no account of the requirements for conversion between
protocols. Different card schemes have different operating rules for the generation of reversal on
timeout, see the table below for more details.
Card Authoriser Time-out Rules
The following rules are specified by the various card schemes for SPAN to reverse to the Authoriser on
a late response. However it is a responsibility of the individual IBCS interfaces to time the reversals to
their switches in accordance with the IBCS operating regulations. This information is only included in
the MBI interface for completeness (see section 1.2 for references to the documents used).
Card Scheme Requirements

SPAN generates the Reversal on time out.
Any late response is discarded (SPAN having already responded to the
KSA Card Issuer device or Authoriser).
If the Reversal cannot be delivered it is retained in a Store and Forward
(SAF) file on SPAN until it can be successfully delivered.

Transaction Flows

Visa SMS device or Authoriser).
SPAN generates the Reversal only when a late approved response is
received because Visa require data from the Response to be included in the
Reversal. By this point SPAN has already sent a decline response to the
Visa Base 1 device or acquirer.
MasterCard MDS device or Authoriser).
MasterCard MasterCard does not support Acquirer Reversals.

Credit No reversal is generated by SPAN to MasterCard Credit.
SPAN generates the Reversal only when a late approved response is
GCC-net
received.
Note. This table summarises the position of the IBCS switches on late response as can be ascertained
at this time (Release 4.3a). Please consult the appropriate IBCS operating documentation for
definitive detail.
Card Issuer Reversals
SPAN receives transactions from a limited number of IBCS switches where a KSA Bank is the Card
Issuer. In this case SPAN receives reversals from the IBCS switch as specified in their operating
regulations. In this case SPAN forwards the reversal to the appropriate Card Issuer.

Transaction Flows
4.3 Administrative Messages

(VISA)
ISO Message Types: 0600 – Administrative Request
0610 – Administrative Response
0620 – Administrative Advice
0630 – Administrative Advice Response
Diagram:
VISA-BASE I
1
0600/0620 3 KSA Bank Card
SPAN Email/Fax/Report
0610/0630 Scheme Bank
2
VISA-SMS
Purpose: The purpose of this message is to allow the International Bank Card
Scheme Switch (VISA) to send information and warnings to SPAN.
Used For: Transmitting information and warning messages to SPAN.
Normal Processing: The following steps correspond to the numbers in the transaction flow
diagram above.
Point 1 The International Bank Card Scheme (VISA) sends information or issues a
warning message to SPAN using a 0600 Administrative Request/0620
Administrative Advice message.
The 0600 Administrative Request/0620 Administrative Advice message
contains a free format text message from VISA, which is logged by the
SPAN system. This information is available to the SPAN monitoring
system or further analysis.
Point 2 SPAN responds with a 0610 Administrative Response/0630 Administrative
Advice Response to the International Bank Card Scheme Switch (VISA)
indicating successful receipt of the request message.
Note: SPAN response (0610) does not apply to Visa BASE 1
Point 3 Depending upon the content of the message SPAN will manually forward
this information to the relevant International Bank Card Scheme Bank
within the Kingdom via a suitable format, i.e. email, fax or report.

Transaction Flows

(MasterCard)
ISO Message Types: 0620 – Administrative Advice
Diagram: MasterCard
Credit
1
0620 3 KSA Bank Card
SPAN Email/Fax/Report
0630 Scheme Bank
2
MasterCard-MDS
Purpose: The purpose of this message is to allow the International Bank Card
Scheme Switch (MasterCard) to send information and warnings to SPAN.
Used For: Transmitting information and warning messages to SPAN.
diagram above.
Point 1 The International Bank Card Scheme (MasterCard) sends information or
issues a warning message to SPAN with a 0620 Administrative Advice
message.
The 0620 Administrative Advice message contains a free format text
message from MasterCard, which is logged by the SPAN system.
This message is available to the SPAN monitoring system for further
analysis.
Point 2 SPAN responds with a 0630 Administrative Advice Response to the
International Bank Card Scheme Switch (MasterCard) indicating
successful receipt of the advice message.
Point 3 Depending upon the content of the message SPAN will manually forward
this information to the relevant International Bank Card Scheme Banks
within the Kingdom via a suitable format, i.e. email, report etc.

Transaction Flows
4.3.3 Administrative Notification – International Bank Card Scheme Card Capture Notice
(VISA)
ISO Message Types: 0620 – Administrative Advice
Diagram: 0620
3 1
1624 KSA Bank Card
VISA 4 SPAN 2
0630 1634 Scheme Bank
Purpose: The purpose of this message is to allow the KSA Bank Card Scheme Bank
to inform Visa about a card and its capture.
Used For: Transmitting information about a card and its capture to VISA.
diagram above.
Point 1 The KSA Bank Card Scheme Bank formats a 1624 Administrative Advice
with details of the card capture and sends it to SPAN.
SPAN formats a 1634 Administrative Advice Response to the Card
Scheme Bank.
Point 2
This message is available to the SPAN monitoring system for further
analysis.
Point 3 SPAN formats a 0620 Administrative Advice message from the received
1624 Administrative Advice message and routes it to the International
Bank Card Scheme Switch (VISA).
Point 4 International Bank Card Scheme (VISA) responds with a 0630
Administrative Advice Response.

Transaction Flows
4.3.4 Fraud Advice – International Bank Card Scheme Fraud Advice messages (VISA SMS
only)
ISO Message Types: 9620 – Fraud Advice
9630 – Fraud Advice Response
Diagram:
2 1
VISA-SMS SPAN
3 4 Scheme Bank
9630 9630
Purpose: The purpose of this message is to allow the KSA Bank Card Scheme Bank
to inform the VISA SMS Switch about a fraudulent transaction.
Used For: Transmitting information about a fraudulent transaction to VISA SMS.
diagram above.
Point 1 The KSA Bank Card Scheme Bank formats a 9620 Fraud Advice with
details of the fraud and sends it to SPAN.
Point 2 SPAN formats a 9620 Fraud Advice message (VISA format) from the
received 9620 Fraud Advice message and routes it to the International
Bank Card Scheme switch (VISA SMS).
Point 3 International Bank Card Scheme switch (VISA SMS) responds with a 9630
Fraud Advice Response.
Point 4 SPAN formats a 9630 Fraud Advice Response message from the received
9630 Fraud Advice message (VISA format) and routes it to the KSA Bank
Card Scheme Bank.
Note.. This is added for completeness. It is understood that this facility is
not available as yet.
Exception Processing Action Code 941 is returned to the Card Scheme Bank if the 9620 advice
cannot be sent or the 9630 response is timed out.
The Card Scheme Bank should then resend the 9620.

Transaction Flows
4.4 Rejected Message

SPAN or a Member Bank may reject any message received by notifying the message originator
through the use of the Administrative Notification message. If a message cannot be identified (e.g., the
message type identifier cannot be determined) the receiver may send a 1644 administrative notification
message with a function code of “650” indicating inability to parse the original message. Also a 1644 is
also used with a Function Code of 691 to indicate a MAC error in a response.
For transactions received from acquirer interface, if bitmap is consistent with content but fails against
required message structure for the acquirer interface the transaction will be rejected. For example, if a
mandatory or expected conditional data element is missing, the transaction will be rejected.
For transactions received from acquirer interface, if bitmap is consistent with content and passes
against required message structure for the acquirer interface, but fails against message format for the
issuer interface the transaction will be declined. For example, if a message received from an acquirer
appears to be correct, but when it is about to be routed to an issuer, a mandatory or expected
conditional data element is found to be missing, the transaction will be declined.
If a request or advice message is received with an incorrect MAC, a corresponding response must be
sent back with an Action Code of 916 indicating MAC incorrect, i.e. an incorrect MAC in a request or
advice is processed as a normal decline.
However, if a response message is received with an incorrect MAC, a 1644 administrative notification
message must be sent with Function Code 691 indicating MAC error and an Action Code of 916
indicating MAC incorrect.

Transaction Flows
4.4.1 Rejected Message – Exceptions to Normal Request or Advice Message Flow

ISO Message Types: 1200 – Financial Request (this is an example. It can apply to any request or
advice message).
1644 – Administration Notification
Diagram:
1
1200
SPAN Bank
1644
2
Purpose: This flow diagram highlights a rejected request or advice message

scenario.
Note. The example shows SPAN rejecting a request or advice message
from a Bank. Similarly if the Bank has a problem with a request or advice
message from SPAN it also sends a 1644 Administrative Notification
message to SPAN.
Used For: Processing invalid request or advice messages.
Normal Processing: When a request or advice message is received that cannot be accepted
(e.g., the message type identifier cannot be determined etc), the receiver
should send a 1644 Administrative Notification message to the originator
indicating inability to parse the original request or advice message.
• Function Code – set to 650 (unable to parse message)
• Action Code – set to 690 (unable to parse message).
• Data Record – this data element will contain the rejected message (if
the rejected message is larger than the maximum size of the data
element it will be truncated).
Note that this action is taken on any request or advice message type. These
messages are logged and are available to the SPAN monitoring system for
further investigation.
The following steps correspond to the numbers in the transaction flow
diagram above.
Point 1 A Bank sends, for example, a 1200 Financial Request message to SPAN.
SPAN receives the 1200 Financial Request message that it cannot process
or reformat for internal use. SPAN does not send a response to the invalid
message.
Point 2 SPAN produces a 1644 Administration Notification message with the
appropriate information in the Data Record element and sends the message
to the originator of the invalid message.

Transaction Flows
4.4.2 Rejected Message – Exceptions to Normal Response Message Flow

advice message)
1210 – Financial Request Response (this is an example. It can apply to any
response message)
Diagram: 1
1200
SPAN Bank
1644
2
Purpose: This flow diagram highlights a rejected response message scenario.

Note. The example shows SPAN rejecting a response message from a
Bank. Similarly if the Bank has a problem with a response message from
SPAN it also sends a 1644 Administrative Notification message to SPAN.
Used For: Processing invalid response messages.
Normal Processing: When a response message is received that cannot be accepted (e.g., the
message type identifier cannot be determined etc) the receiver should send
a 1644 Administrative Notification message to the originator indicating
inability to parse the original response message.
• Function Code – set to 650 (unable to parse message).
• Action Code – set to 690 (unable to parse message).
Note that this action is taken on any response message type. These
diagram above.
Point 1 SPAN sends, for example, a 1200 Financial Request message to the Bank.
Point 2 The Bank receives the 1200 Financial Request and sends back a 1210
Financial Request Response message that SPAN cannot process or
reformat for internal use.
back to the Bank.
Normal time-out processing then applies. If no valid response is received
within the predefined time limit for the request type, SPAN takes the
appropriate recovery action for the request or advice type: this may involve
sending a reversal or resending the advice.

Transaction Flows
4.4.3 Rejected Message – Exceptions to Normal Response Message Flow (Incorrect MAC)
advice message)
1210 – Financial Request Response (this is an example. It can apply to any
response message)
Diagram: 1
1200
SPAN 1210 Bank

2
3
1644
Purpose: This flow diagram highlights a response message rejected due to an
incorrect MAC.
Note. The example shows SPAN rejecting a response message from a
Bank. Similarly if the Bank has a problem with a response message from
SPAN it also sends a 1644 Administrative Notification message to SPAN.
Used For: Processing response messages with incorrect MACs.
Normal Processing: When a response message is received with an incorrect MAC, the receiver
should send a 1644 Administrative Notification message to the originator
indicating an icorrect MAC in the original response message.
• Function Code – set to 691 (MAC error).
• Action Code – set to 916 (incorrect MAC).
Note that this action is taken on any response message type. These
diagram above.
Point 1 SPAN sends, for example, a 1200 Financial Request message to the Bank.
Point 2 The Bank receives the 1200 Financial Request and sends back a 1210
Financial Request Response message that SPAN detects contains an
incorrect MAC.
back to the Bank.
Normal time-out processing then applies. If no valid response is received
within the predefined time limit for the request type, SPAN takes the
appropriate recovery action for the request or advice type. For a request
message, this may involve sending a reversal. For an advice message, no
retry shall be attempted.

Transaction Flows
4.5 Network Management Messages

SPAN or a Member Bank may initiate a Network Management message to logon/logoff or to check the
status of the link between the two systems. Additionally, SPAN can also use this message class to
initiate a cryptographic key exchange request and initiate a session key cutover.

Transaction Flows
4.5.1 Logon Requests – SPAN Logon Request

ISO Message Types: 1804 – Network Management Request
1814 – Network Management Request Response
Diagram: 1
1804
SPAN 2 Bank
1814
Purpose: The purpose of the logon message is to determine the availability of the
SPAN system after either a,
• Controlled shutdown (logoff), or
• Sudden failure in communications.
It is a requirement that SPAN send a logon message to the Bank after each
SPAN down condition.
Used For: Establishing application to application connectivity for POS and ATM.
diagram above.
Point 1 After the SPAN system has become operational and has initialised its
application processing system, a 1804 Network Management Request
message should be sent to the Bank with the following field values,
• SPAN Header Network Product Indicator – set to "00", and
• Function Code – set to “801”.
This message indicates that SPAN is ready to receive and process
transactions.
Point 2 The Bank responds with a 1814 Network Management Request Response
message. In order to distinguish it as a logon response, the following field
values should be incorporated,
• Action Code – set to “800”.
This message indicates that the application is active.
Note: SPAN only attempts to initiate the logon sequence when it has
been taken down for maintenance and is being brought back into service.
Exception Processing: The points below describe some of the potential exception processing
scenarios and the procedure that is to be followed.

Transaction Flows
(A) The Action Code (field 39) indicates the action to be taken and the reason
for taking the action. A couple of scenarios and the Action Code values
that are to be used are given below,
The Bank is unable to process any transactions for SPAN, an Action Code
of "907" should be inserted in the response message.
The Bank is in cutover processing, an Action Code of "906" should be
inserted in the response message.
The digital signature verification failed, an Action code ‘884’ should be
inserted in the response message
The Random string sequence verification failed, an Action code ‘883’
should be inserted in the response message
(B) To check the current status of the Bank link to SPAN, SPAN may initiate
an echotest message.
• SPAN formats a 1804 Network Management Request with the
Function Code set to "831" signifying that this message is an echotest.
• The Bank should insert an Action Code of “800” the response message
to SPAN to verify application connectivity.
(C) Using arbitrary labels A and B for two parties, the procedure to follow for
a logon operation is as follows,
• A 1804 Network Management Request message (logon request) from
either party, for example from A, to the other side, B, indicates that A
is now available to accept and would like to be able to send 1200,
1420 and 1421 messages to B.
A 1814 Network Management Request Response (logon response) from B
to A with a Action Code of 800 indicates that B is now able to send and is
available to accept 1200, 1420, and 1421 requests from A.
(D) The procedure to follow for a logoff operation is as follows,
• A 1804 Network Management Request (logoff request) from A to B
indicates A is no longer able to send or accept 1200, 1420, and 1421
messages from B.
• A 1814 Network Management Request Response (logoff response)
from B to A indicates that B will no longer send and does not expect
to receive 1200, 1420, and 1421 messages from A.

Transaction Flows
4.5.2 Logon Requests – Bank Logon Request

Diagram: 1
1804
SPAN 2 Bank
1814
Purpose: The purpose of the logon message is to determine the availability of the
Bank system after either a controlled shutdown (logoff) or a sudden failure
in communications. It is a requirement that the Bank send a logon message
to SPAN after each Bank down condition.
Used For: Establishing application to application connectivity for POS and ATM.
diagram above.
Point 1 After the Bank system has become operational and has initialised its
application processing system, a 1804 Network Management Request
message should be sent to SPAN with the following field values,
This message indicates that Bank is ready to receive and process
transactions.
Point 2 SPAN responds with a 1814 Network Management Request Response
message with the following field values indicating that the application is
now active,
• Action Code – set to “800”
This message indicates that the application is active.
Note: Only one of the parties (either the Bank or SPAN) need perform a
logon request since the 1814 Network Management Request Response
with an Action Code of “800” means that both parties have agreed to send
and accept 1200, 1420, and 1421 messages.
However, the Bank assumes primary responsibility for performing the
logon sequence as soon as it is prepared to process financial transactions.
SPAN is capable of handling logon requests from a Bank, which it believes
is already logged on. SPAN will respond with an Action Code value of
“800” and thus such requests will not cause an error.

Transaction Flows
(A) The Action Code field 39 indicates the action to be taken and the reason
for taking the action. A couple of scenarios and the Action Code field 39
values that are to be used are given below,
• SPAN is unable to process any transactions for the requesting
institution, therefore an Action Code of "907" should be inserted in
the response message.
• SPAN is in cutover processing, an Action Code of "906" should be
inserted in the response message.
• Action Code 892 is used in response to a logon request with an
identical ‘Transmission Date and Time’ of an earlier request. For more
details refer to Security Framework, Section 4.2.3, final paragraph.
(B) To check the current status of the Bank link to SPAN, the Bank may
initiate an echotest message.
• The Bank should format a 1804 Network Management Request with
the Function Code set to "831" signifying that this message is an
echotest.
• SPAN should insert an Action Code of “800” the response message to
the Bank confirming application connectivity.

Transaction Flows
4.5.3 Echotest – Echotest Sent By SPAN

Diagram: 1
1804
SPAN 2 Bank
1814
Purpose: The purpose of this echotest message is to verify the availability of the
Bank system. Echotest messages are sent only during extended
(configurable time) periods of no traffic, or in the event of temporary loss
of communications.
Used For: Verifying application to application connectivity for POS and ATM.
diagram above.
Point 1 SPAN generates a 1804 Network Management Request and sends it to the
Bank with the following field values,
• SPAN Header Network Product Indicator set to "00", and
• Function Code value of "831".
This tells the Bank that SPAN is available over that link.
message with the following field values to indicate that the application is
active.
There is no need to log the echotest message at the Bank.
Note: When SPAN sends an echotest message, a timer is set to wait for a
response. If the timer expires before SPAN receives the response, SPAN
changes the status of the corresponding Bank to unavailable. SPAN will
not send any messages except for logoff and echotest messages until the
Bank initiates activity on the line. Therefore, it is imperative that the Bank
respond to an echotest message in a timely and accurate manner. This
avoids excessive Network Management activity across the line.
(A) When the Bank's application is unable to process any transactions for the
requesting institution, an Action Code of "907" should be included in the
message.
Note: When the application is available it must return an Action Code
value of “800”. If the application is not going to be available for
processing, a logoff message should be sent to SPAN indicating the down
status of the application.
(B) When the Bank is performing cutover processing, an Action Code value of
“906” should be placed in field 39 of the response message.

Transaction Flows
4.5.4 Echotest – Echotest Sent By Bank

Diagram: 1
1804
SPAN 2 Bank
1814
Purpose: The purpose of this echotest message is to verify the availability of the
SPAN system. It is a requirement that the Bank send an echotest message
to SPAN after suspicion that a down condition exists, existed, or that no
traffic has been detected over a configured time window.
Used For: Verifying application-to-application connectivity for POS and ATM.
diagram above.
Point 1 The Bank generates a 1804 Network Management Request and sends it to
SPAN with the following field values,
• SPAN Header Network Product Indicator set to "00", and
• Function Code value of "831".
This tells SPAN that the Bank is available over that link.
message with the following field values to indicate that the application is
active.
Note: Echotest messages can be sent before logon messages are
exchanged. The echotest messages confirm that communications lines are
present between the Bank and SPAN before logon messages are sent. It is
equally acceptable for echotest messages to be sent immediately after
logon messages have been exchanged.

Transaction Flows
4.5.5 Logoff Requests – SPAN Logoff Processing

Diagram: 1
1804
SPAN 2 Bank
1814
Purpose: Occasionally, it may be necessary for SPAN to cut off communications

with a Bank. The logoff message feature is a method of indicating to the
Bank that SPAN will not be processing any transactions.
Used For: Normal shutdown of system for POS and ATM.
diagram above.
Point 1 In order to perform a SPAN system shutdown, SPAN sends a 1804
Network Management Request message to the Bank indicating that a
logoff operation is being performed. The following fields values should be
provided,
This message indicates that SPAN is not available to process transaction
requests.
message with the following field values to indicate that it acknowledges
that the SPAN system is unavailable.
• Action Code – set to "800".
Exception Processing: There is no exception processing for this message. The Bank must respond
with an Action Code value of “800” as a logoff request cannot be denied.

Transaction Flows
4.5.6 Logoff Requests – Bank Logoff Processing

Diagram: 1
1804
SPAN 2 Bank
1814
Purpose: Occasionally, it may be necessary for the Bank to cut off communications
with SPAN. The logoff message feature is a method of indicating to
SPAN that the Bank will not be processing any more transactions.
Used For: Normal shutdown of system for POS and ATM.
diagram above.
Point 1 In order to perform a Bank system shutdown, the Bank sends a 1804
Network Management Request message to SPAN indicating that a logoff
operation is being performed. The following fields values should be
provided,
This message indicates that the Bank is not available to process transaction
requests.
message with the following field values to indicate that it acknowledges
that the Bank system is unavailable.
• Action Code – set to "800".
Note: When the Bank's system comes up after an unscheduled down time,
it may still be logically logged on. This is because SPAN has not received
a logoff request. As soon as echotest messages are exchanged, financial
transactions are sent to the Bank by SPAN when any transactions are
outstanding
When a Bank wants to stop receiving financial transactions after its system
comes up following an unscheduled down time, the first message sent to
SPAN must be a logoff request. The Bank can then send a logon request at
a later time when it is prepared to handle financial transactions.
Exception Processing: There is no exception processing for this message. SPAN must respond
with an Action Code value of “800” as a logoff request cannot be denied.

Transaction Flows
4.5.7 Interactive Cutover Process – SPAN Interactive Cutover Process

Diagram: 1
1804
SPAN 2 Bank
1814
Purpose: The cutover message is used to indicate that the SPAN business day has
changed. It provides a mechanism for SPAN to inform all Banks that the
transactions that they receive from this point on will be applied to a new
business day, and SPAN is no longer accepting requests for the old
business day.
Used For: Business day change notification for POS and ATM.
diagram above.
Point 1 Upon change of the SPAN business day, SPAN formats a 1804 Network
Management Request message with the following field values and sends it
to the Bank.
• SPAN Header Network Product Indicator – set to "00" for ATM
cutover, or "04" for POS cutover, and
• Function Code – set to "821".
The new SPAN business day is carried in the Reconciliation Date (field
28). At this point, all new transactions to and from the Bank should be for
the new SPAN business day. After the cutover message has been sent by
SPAN, a five minute window is initiated to allow for any transactions and
reversals that are still processing to complete.
When the window expires, the settlement totals are frozen for the SPAN
business day. SPAN then formats the Acquirer and Card Issuer Bank
reconciliation messages.
Point 2 The Bank, upon receipt of the cutover message, should save and re-
initialise the transaction accumulators for SPAN. Additionally, logging the
receipt of the message is recommended. A 1814 Network Management
Request Response should be formatted and sent to SPAN indicating receipt
and acknowledgement of the change of business day.
Exception Processing: In the event of line failures or timeouts, SPAN resends the cutover
message using the 1824 Network Management Advice or 1825 Network
Management Advice Repeat messages.

Transaction Flows
4.5.8 Non-Interactive Cutover Process – SPAN Non-Interactive Cutover Process

ISO Message Types: 1824 – Network Management Advice
1834 – Network Management Advice Response
Diagram: 1
1824
SPAN 2 Bank
1834
Purpose: The cutover message is used to indicate that the SPAN business day has
changed. It provides a mechanism for SPAN to inform all Banks that the
transactions that they receive from this point on will be applied to a new
business day, and SPAN is not accepting requests for the old business day.
diagram above.
Point 1 Upon change of the SPAN business day and in the event the Bank is not
available to receive the 1804 Network Management Request interactive
cutover message, SPAN formats a 1824 Network Management Advice
Message with the following field values to the Bank.
The new SPAN business day is provided in the Reconciliation Date (field
28). All request and advice messages that SPAN sends to the Card Issuer
Bank and receives from the Acquirer will contain the new SPAN business
day in the Reconciliation Date (field 28).
Point 2 The Bank, upon receipt of the cutover message, must save and change the
transaction accumulators for SPAN. Additionally, logging the receipt of
the message is recommended. A 1834 Network Management Advice
Response must be formatted and sent to SPAN indicating receipt of the
change of business day is acknowledged.
SPAN then forwards the Acquirer and Card Issuer Bank reconciliation
messages, which will have been stored in SAF when the original 1804
Network Management Request was unsuccessful.
Exception Processing: There is no exception processing for this message.

Transaction Flows
4.5.9 Interactive Cutover Process – Bank Interactive Cutover Process

Diagram: 1
1804
SPAN 2 Bank
1814
Purpose: The cutover message is used to indicate that the Bank's business day has
changed. It provides a mechanism for the Bank to inform SPAN that the
transactions that they receive from this point will be applied to a new Bank
business day.
diagram above.
Point 1 Upon change of the Bank business day the Bank formats a 1804 Network
Management Request message with the following field values and sends it
to SPAN.
The new Bank business day is carried in the Reconciliation Date (field 28).
At this point, all new transactions acquired by the bank should contain its
new business day in the Capture Date (field 17).
Point 2 Upon receipt of the cutover message, SPAN logs the receipt of the
message on the system. A 1814 Network Management Request Response
is formatted and sent by SPAN indicating the change of business day is
acknowledged.
Exception Processing: In the event of line failures or time-outs occurring, the Bank resends the
cutover message using the 1824 Network Management Advice or 1825
Network Management Advice Repeat messages.
Action Code 942 is returned to the Member Bank if the new Bank business
day in the Reconciliation Date (DE 28) is not advanced correctly.

Transaction Flows
4.5.10 Non-Interactive Cutover Process – Bank Non-Interactive Cutover Process

ISO Message Types: 1824 – Network Management Advice
1834 – Network Management Advice Response
Diagram: 1
1824
SPAN 2 Bank
1834
Purpose: The cutover message is used to indicate that the Bank's business day has
changed. It provides a mechanism for the Bank to inform SPAN that the
transactions that are received from this point will be applied to a new
business day and the Bank is not accepting requests for the old business
day.
diagram above.
Point 1 Upon change of the Bank business day, the Bank formats a 1824 Network
Management Advice Message with the following field values and sends it
to SPAN.
• SPAN Header Network Product Indicator set to "00" for ATM
The new Bank business day is provided in the Reconciliation Date (field
28). All requests and advice messages that the Bank sends will contain the
new Bank business day in the Capture Date (field 17).
Point 2 Upon receipt of the cutover message, SPAN logs the Bank cutover. A
1834 Network Management Advice Response is formatted and sent to the
Bank indicating receipt of the change of business day is acknowledged.
Exception Processing: There is no exception processing for this message.

Transaction Flows
4.5.11 Key Management Exchange – SPAN Key Management Exchange

Diagram: 1
1804
SPAN 2 Bank
1814
Purpose: Periodically, SPAN sends key updates for Zone Working Keys (ZWK)
classified as either a Zone PIN Key (ZPK) or a Zone Authentication Key
(ZAK). There is no separate Acquirer ZWK or Issuer ZWK. The Bank
must update these keys immediately and keep them until SPAN sends a
new ZWK. The Network Security Section (Section 7) of this manual
contains more details about these keys. The same message type is used
regardless of the ZWK type.
Used For: Ensuring the integrity of cardholder PIN data for POS and ATM.
diagram above.
Point 1 SPAN determines that a key change is required for a Bank based on a timer
that will expire. SPAN formats a 1804 Network Management Request
message to the Bank with the following field values.
• SPAN Header Network Product Indicator – set to "00",
• Function Code – set to "811", and
• Key Management Data (field 96) – formatted with the new key
information.
This information contains the new key, key type, and check digits to insure
correct transfer of the key to the Bank. SPAN obtained the new key by
requesting a Zone PIN Key (ZPK) or Zone Authentication Key (ZAK)
generation from the Host Security Module (HSM) connected to SPAN.
The Bank receives the 1804 Network Management Request Message and
determines that it is a key change request. After verifying that the
remainder of the fields in the message are present and contain valid data,
the Bank processing system must format a request to the Bank Host
Security Module requesting check digits be computed for the new key.
The Bank compares the check digits contained in the message (field 96)
Check Digit component with the one computed by the Bank HSM. When
equal, the Bank processing software prepares to change the contents of the
Zone PIN Key (ZPK) or Zone Authentication Key (ZAK) and stores it in a
protected location. A good return from the HSM causes the Bank
processing software to format a 1814 Network Management Request
Response to SPAN.
Point 2 SPAN receives the 1814 Network Management Request Response from
the Bank and determines that an Action Code value “800” was received
indicating successful completion of the request. The Zone Working Key is
saved on disk so as to preclude the possibility of loss due to a power failure
or re-initialisation of the operating software process.

Transaction Flows
Exception Processing: The points describe some of the potential exception processing scenarios
and the procedure that is to be followed.
(A) When a key change request is already in progress at the time the current
request is received, the Bank must place the following field value in the
message.
• Action Code – set to “923”.
(B) When the check digits computed by the Bank HSM do not agree with the
check digits in the Key Management Data (field 96), the Bank should
return the following field values in the message.
SPAN, when receiving this code, will not change the Zone Working Key
between the Bank and SPAN. However, an operator notification is
created. The Bank must also generate a notice to the operational personnel
indicating that automatic key change did not take place.
Note: When SPAN sends the key management message, it sets a timer to
wait for a response. When the timer expires before SPAN receives the
response or if the original message fails, SPAN regenerates the key updates
and sends a new 1804 message. For the message to be successful, a Bank
must respond within the period of time set by SPAN. After the keys have
been successfully stored, they are immediately used for MAC’ing (ZAK)
and encrypting/translating the PIN’s (ZPK) in any new transaction
messages.

Transaction Flows
4.5.12 Retrieving MasterCard SAF Records

0820 – Network Management Advice
Diagram: 0800
1
2
0810
MasterCard 3
ADVICE
Credit 4
RESPONSE
5
0820 6
ADVICE KSA Card Issuer
SPAN 7
1 RESPONSE Bank
0800
2
0810
3
MasterCard-MDS ADVICE
4
RESPONSE
5
0820
Purpose: SPAN obtains store-and-forward records from MasterCard Credit and

MasterCard-MDS (Debit Service) to update balances and velocity files for
transactions processed during the Card Issuer's or SPAN's down time.
Used For: Store-and-Forward Record Processing for POS and ATM.
diagram above.
Point 1 At a time when communications have been re-established between SPAN
and the Switch, SPAN initiates a Store-and-Forward session with
MasterCard Credit by sending a 0800 Network Management Message.
The MasterCard Network Management Code (P-70) is set to '060' for a
SAF session request.
MasterCard-MDS, however, initiates the 0800 message with the Network
Management Code (P-70) set to '270' for an echotest.
Point 2 Upon receipt of the 0800 message, a 0810 Network Management Response
is returned.
Point 3 The Switch sends one Store-and-Forward advice message at a time to
SPAN.

Transaction Flows
Point 4 For each Store-and-Forward message SPAN receives, an appropriate

response message is returned to the Switch. When the SAF process
receives an advice response, it sends the next advice. When MasterCard
Credit does not receive a response message, it assumes SPAN did not
receive the previous advice and ceases the SAF session. When
MasterCard-MDS does not receive a response message, it initiates another
echotest to establish communications and then continues sending advices.
In the case of MasterCard and SPAN the following combinations of
advice/response messages are possible.
MasterCard Request SPAN Response Message
Message
0120 Authorisation Advice 0130 Authorisation Advice
Response
0420 Acquirer Reversal 0430 Acquirer Reversal Advice
Advice Response
In the case of MasterCard-MDS and SPAN the following combinations of
advice/response messages are possible.
MasterCard-MDS Request SPAN Response Message
Message
0220 Financial Transaction 0230 Financial Transaction Advice
Advice Response
0420 Acquirer Reversal 0430 Acquirer Reversal Advice
Advice Response
0422 Issuer Reversal Advice 0432 Issuer Reversal Advice
Response
0520 Acquirer Reconciliation 0530 Acquirer Reconciliation
Advice Advice Response
0522 Issuer Reconciliation 0532 Acquirer Reconciliation
Advice Advice Response
0620 Administrative Advice 0630 Administrative Advice
Response
Point 5 The SAF process responds to the last advice response with a 0820 SAF
EOF message. The Network Management Information Code (P-70) is set
to '363' - Store and Forward EOF.
Point 6 SPAN routes the advice message to the Card Issuer Bank.
Note: Although both approved and declined transactions are stored in the
SAF file, SPAN only routes advices with an approved response code to the
Card Issuer Bank.
Point 7 The Card Issuer Bank returns a response message to SPAN. The following
combinations of advice/response messages are possible:
SPAN Request Message Card Issuer Bank Response
Message
1220 Financial Advice 1230 Financial Advice Response
1420 Reversal Advice 1430 Reversal Advice Response

Transaction Flows

Transaction Flows
4.5.13 Retrieving VISA SMS SAF Records

1
Diagram: 0800
2
0810
3 5
Visa SMS ADVICE ADVICE KSA Card Issuer
4 SPAN 6
RESPONSE Bank
RESPONSE
7
0800
8
0810
Purpose: SPAN obtains store-and-forward records from Visa SMS to update

balances and velocity files for transactions processed during the Card
Issuer's or SPAN's down time.
Used For: To start transmission of Store-and-Forward File records held at Visa SMS
during an interruption in service (for incoming Visa SMS ATM
transactions only). This process must be preceded by a sign-on process.
diagram above.
Point 1 At a time when communications have been re-established between SPAN
and the Switch, SPAN initiates a Recovery Sign-on with Visa SMS by
sending an 0800 Network Management Message. The Visa Network
Management Code (P-70) is set to '078' to indicate start transmission of
advices.
SPAN must be signed on to Visa SMS during this process.
Point 2 Upon receipt of the 0800 message, an 0810 Network Management
Response is returned by Visa SMS.
Point 3 Visa SMS sends one Store-and-Forward advice message at a time to
SPAN.
Point 4 For each Store-and-Forward message SPAN receives, an appropriate
response message is returned to Visa SMS. When the SAF process
receives an advice response, it sends the next advice.
In the case of Visa SMS the following combinations of advice/response
messages are possible.
Visa SMS SPAN Response Message
0520 Reconciliation Advice 0530 Reconciliation Advice
Response
0620 Administrative Advice 0630 Administrative Advice
Response
Point 5 SPAN routes the advice message to the Card Issuer Bank, except for the
0620 Administration Advice, which is sent via email, fax or report as
shown in Section 4.3.2.
Note: SPAN only routes advices with an approved response code to the
Card Issuer Bank.

Transaction Flows
Point 6 The Card Issuer Bank returns a response message to SPAN. The following
combinations of advice/response messages are possible:
SPAN Request Message Card Issuer Bank Response
Message
Point 7 After the last advice is received, SPAN has the option to sign-off from
advice recovery, by sending another 0800 Network Management message
(the Network Management Information Code (P-70) is set to 079).
Typically however SPAN would remain signed on to advice recovery
mode so that any transactions processed by stand-in processing are
obtained as soon as possible. A system can be logged into Visa SMS for
normal processing and advice recovery simultaneously.
Point 8 Visa SMS responds with an 0810 Network Management Response.

Transaction Flows
4.6 ATM Financial Messages

This subsection describes the flow of ATM financial transaction messages through SPAN for both
transaction Acquirer Banks and Card Issuer Banks.
The following message types are used in the transaction flows in this section:
Financial:
1200 Financial Request
1210 Financial Request Response
1220 Financial Advice
1221 Financial Advice Repeat
1230 Financial Advice Response
Reversal:
1420 Reversal Advice
1421 Reversal Advice Repeat
1430 Reversal Advice Response
Chargeback:
1422 Chargeback Advice
1423 Chargeback Advice Repeat
1432 Chargeback Advice Response
Reconciliation:
1520 Acquirer Reconciliation Advice
1521 Acquirer Reconciliation Advice Repeat
1522 Card Issuer Reconciliation Advice
1523 Card Issuer Reconciliation Advice Repeat
1530 Acquirer Reconciliation Advice Response
1532 Card Issuer Reconciliation Advice Response
To guarantee delivery, all advice messages (1420, 1421, 1422, 1423, 1520, 1521, 1522, and 1523)
should be stored for later forwarding to SPAN via the Store-And-Forward (SAF) mechanism.

Transaction Flows
4.6.1 Financial Request – Normal Transaction (KSA Acquirer ATM)

ISO Message Types: 0100 – Authorisation Request
0110 – Authorisation Request Response
0200 – Financial Request
0210 – Financial Request Response
Diagram: 2
0100
3 VISA-BASE I
0110
2
0200
3 VISA-SMS
0210
1 2
1200 1200
KSA Acquirer KSA Card Issuer
4 SPAN 3
Bank Bank
1210 1210
2
0200
3 GCC-Net
0210
2
0200
3 MasterCard-MDS
0210
Purpose: To request and receive approval for a financial transaction.

Used For: Cash Withdrawal
Balance Inquiry
Mini Statement
Pre-paid tokens
Note.. Not all of the above uses are available on all cards.
diagram above.
Point 1 The Acquirer Bank receives a transaction request from its own ATM.
The Bank's ATM processing system determines that the Cardholder is not
a member of its Bank by looking at the first 6 bytes of the PAN number
(stored on Track 2 data ISO field 35 encoded on the ATM card).
A 1200 Financial Request message is formatted by the Bank’s ATM
processing system and sent to SPAN.

Transaction Flows
Point 2 SPAN receives the 1200 request message and uses the Track 2 data to
determine the Cardholder's Bank.
SPAN verifies the following.
• The contents of all message fields are valid.
• The requested transaction is allowed
• The Card Issuer is supported by SPAN and is currently available.
SPAN then formulates and routes a 0100 Authorisation Request, an 0200
Financial Request or 1200 Financial Request to the Card Issuer Bank or
Network, as applicable, for authorisation.
Point 3 The Card Issuer Bank/Network receives the 0100/0200/1200 request
message and verifies that it issued the card, then uses the Primary Account
Number (PAN) in the first position of Track 2 to determine the
Cardholder's account. It is used to cross-reference the card account to the
Cardholder's current account number set up for ATM processing.
The Card Issuer Bank authorises tasks including:
• Verify the Personal Identification Number (PIN) field 52, as a
PIN/PAN block using the Host Security Module (refer to Section 7 -
Network Security)
• Validate the Card Verification Value (CVV)/Card Validation Code
(CVC) encoded in Track 2, if present.
• Check that the card is active
• Check that the account is active.
• Determine the balance of the Cardholder's account, and verify that the
requested transaction amount is allowed. If approved, the transaction
updates the Cardholder's account.
The Card Issuer Bank/Network begins building a 0110 Authorisation
Request Response or a 0210/1210 Financial Transaction/Request Response
message, as applicable.
When the transaction requested is a Balance Inquiry, the Cardholder's
account balance information is transmitted in the 1210 Financial Request
Response message as follows.
• Additional Amounts Amount field of the Additional Amounts data
element (field 54) stores the Cardholder’s balances.
The available balance is computed at the Issuer exclusively using cleared
funds. This information is to be transferred to SPAN as follows.
• Additional Amounts Amount field of the Additional Amount data
element (field 54) stores the Cardholder’s available balance.
• Action Code (field 39) is set to “000” indicating a successful
transaction.
The appropriate reconciliation totals are updated for the transaction
amount, indicating a successful transaction.
The 0110 Authorisation Request Response or 0210/1210 Financial
Transaction/Request Response, as applicable, is then formatted and sent to
SPAN for processing.

Transaction Flows
Point 4 SPAN receives the 0110/0210/1210 response message from the Card
Issuer and does the following.
Logs the transaction to the Transaction Log File (TLF)
Formulates and routes a 0110 Authorisation Request Response, an 0210
Financial Request Response or 1210 Financial Request Response, as
required to the Transaction Acquirer.
The Transaction Acquirer should then log the transaction response
message and complete the transaction with the Cardholder at the ATM.
Note The Capture Date (DE 17) in the request from the Acquirer Bank must be
equal to, or one day greater than, the SPAN business day – see
section 5.2.1). If it is not, Action Code 942 is returned to the Acquirer
Bank.
SPAN Exception The following points outline the checks carried out by SPAN.
Processing:
(A) Verify contents of significant fields sent and perform pre-authorisation
denial checks on the 1200 Financial Request for validity.
SPAN receives the 1200 Financial Request message and uses the Track 2
data to determine the Cardholder's Bank. SPAN checks the contents of
significant message fields, determines whether the requested transaction is
allowed, and verifies that the Card Issuer is supported by SPAN and is
currently available. When the transaction fails on any of these checks,
SPAN denies the transaction, logs the message, and returns a 1210
response message to the transaction acquirer with the appropriate value in
the Action Code field (see 3.4.24).
(B) Verify Card Issuer institution is supported by the network.
When it is not, the Invalid Destination for Routing (Action Code 908) is
returned to the Acquiring Institution in field 39.
(C) Determine the availability of the Card Issuer Bank.
When the Bank is unavailable return a Temporary Service Interruption
(Action Code 907) in field 39 to the acquiring institution.
(D) Code 942 is returned to the Acquiring Institution if either the Capture or
Reconciliation Date (DE 17 and DE 28 respectively) is incorrect.
(E) The Reconciliation Date (DE 28) in the request from the Acquirer Bank is
checked by SPAN. If the date is not equal to the SPAN business day then
SPAN will decline with Action Code ‘942’. The Reconciliation Date in the
response from the Card Issuer Bank must be equal to the Reconciliation
Date inserted in the request by SPAN. If it is not, the response is rejected
with a 1644 containing Action Code 942.
In such circumstances, the Member Bank should correct the value of the
current SPAN business day on their system or if required, call SPAN
Operations Help Desk to request a manual cutover to be sent to update
their system.
Card Issuer Exception The following points are some of the basic controls that are to be followed
Processing: by the Card Issuer Bank.
(A) Verify transaction selected is valid for the Cardholder at the acquiring
institution.
If not, return Invalid Transaction (Action Code 902) in field 39.

Transaction Flows
(B) Verify PIN entered by the Cardholder is correct.

If not, and the maximum number of pin retries (3) has not been reached,
send SPAN the Incorrect Personal Identification Number (Action Code
117) in field 39.
When the maximum number of PIN tries has been exceeded, send the
Allowable Number of PIN Tries Exceeded (Action Code 106) to SPAN in
field 39. The issuer must inhibit further access for that card. The
inhibition should remain in effect until it is lifted through an administrative
procedure upon Cardholder request.
(C) Verify transaction amount selected is correct.
When the amount requested is not greater than the minimum, return an
Invalid Amount (Action Code 110) to SPAN in the P-39 field.
When the amount requested is greater than the maximum, return an
Exceeds Withdrawal Amount Limit (Action Code 121) to SPAN.
(D) Verify the account status of the Cardholder's card and current account.
When incorrect, send the appropriate Action Code as defined in 3.4.24.

(E) Compare the expiration date of the card (Track 2) to the current date.
When the card is expired, send the Expired Card (Action Code 101) to SPAN
in field 39.
(F) Verify that the account the Cardholder is requesting is a valid account.
If not, send the No Cheque Account (Action Code 114) to SPAN in field 39.
(G) Verify that the Cardholder’s current account has sufficient funds to perform
the requested transaction.
If note, send Not sufficient funds (Action Code 116) to SPAN in field 39.
(H) Verify that the Cardholder has not exceeded the daily transaction amount
limit.
When the limit is exceeded, send the Exceed Daily Amount Limit (Action
Code 121) to SPAN in field 39.
(I) Verify the CVV/CVC encoded on Track 2, if present.
When the CVV/CVC is invalid, send the Suspected Fraud (Action Code 202)
to SPAN in field 39.
(J) Verify the Cardholder's daily maximum usage limit has not been exceeded for
the day.
When it has, send the Exceeds Withdrawal Frequency Limit (Action Code
123) to SPAN in field 39.
(K) Verify system availability and ensure that no technical problems exist.
When the Card Issuer has a problem processing the transaction request due to
a technical malfunction or unavailability of resources, send an Issuer or SPAN
Inoperative (Action Code 907) to SPAN in field 39.

Transaction Flows
4.6.2 Financial Request – Normal Transaction (SAMA ATM)

ISO Message Types: 1200 – Financial Request
Diagram: Request
1 2
1200
ATM KSA Card Issuer
4 SPAN 3
Response Bank
1210
Completion 5
Purpose: To request and receive approval for a financial transaction.

Used For: Cash Withdrawal
Balance Inquiry
Mini Statement
diagram above.
Point 1 SPAN receives a transaction request from its own ATM.
Point 2 SPAN receives the Request message and uses the Track 2 data to
SPAN then formulates and routes a 1200 Financial Request to the Card
Issuer Bank for authorisation.
Point 3 The Card Issuer Bank receives the 1200 Financial Request message and
verifies that it issued the card. It uses the Primary Account Number (PAN)
in the first position of Track 2 to determine the Cardholder's account. It is
used to cross-reference the card account to the Cardholder's current
account number set up for ATM processing.
The Card Issuer Bank authorises the transaction. The authorisation process
may include some or all of the following functions:
• Verify the Personal Identification Number (PIN) contained in DE 52,
as a PIN/PAN block using the Host Security Module (refer to Section
7 - Network Security)
The Card Issuer Bank begins building a 1210 Financial Request Response
message, as applicable.
When the transaction requested is a Balance Inquiry, the Cardholder's

Transaction Flows
account balance information is transmitted in the 1210 Financial Request

Response message as follows.
• Additional Amounts Amount field of the Additional Amounts data
element (DE 54) stores the Cardholder’s balances.
The available balance is computed at the Issuer exclusively using cleared
funds. This information is to be transferred to SPAN as follows.
• Additional Amounts Amount field of the Additional Amount data
element (DE 54) stores the Cardholder’s available balance.
• Action Code (DE 39) is set to “000” indicating a successful
transaction.
The 1210 Financial Request Response, is then formatted and sent to SPAN
for processing.
Point 4 SPAN receives the 1210 Financial Request response message from the
Card Issuer and does the following.
• Logs the transaction to the Transaction Log File (TLF)
• Formulates and routes a Response to the ATM.
Point 5 The transaction is then completed with the Cardholder at the ATM. A
Completion message is sent to SPAN.
SPAN Exception The following points outline the checks carried out by SPAN.
Processing:
(A) SPAN checks the contents of significant message fields, determines
whether the requested transaction is allowed, and verifies that the Card
Issuer is supported by SPAN and is currently available. When the
transaction fails on any of these checks, SPAN denies the transaction, logs
the message, and returns a response message to the ATM with the
appropriate value in the Action Code field (see 3.4.24).
(B) Verify the network supports Card Issuer institution.
When it does not, the Invalid Destination for Routing (Action Code 908) is
returned to the Acquiring Institution in DE 39.
(Action Code 907 Card Issuer or Switch inoperative) in DE 39 to the
acquiring institution.
(D) The Reconciliation Date in the response from the SPAN Card Issuer Bank
must be equal to the Reconciliation Date inserted in the request by SPAN.
If it is not, the response is rejected with a 1644 containing Action Code
942.
their system.

Transaction Flows
institution.
If not, return Invalid Transaction (Action Code 902) in DE 39.
117) in DE 39.
DE 39. The issuer must inhibit further access for that card. The inhibition
should remain in effect until it is lifted through an administrative procedure
upon Cardholder request.
Invalid Amount (Action Code 110) to SPAN in the DE 39 field.

in DE 39.
If not, send the No Cheque Account (Action Code 114) to SPAN in DE 39.
(G) Verify that the Cardholder’s current account has sufficient funds to perform
the requested transaction.
If note, send Not sufficient funds (Action Code 116) to SPAN in DE 39.
(H) Verify that the Cardholder has not exceeded the daily transaction amount
limit.
Code 121) to SPAN in DE 39.
to SPAN in DE 39.
(J) Verify the Cardholder's daily maximum usage limit has not been exceeded for
the day.
123) to SPAN in DE 39.

Transaction Flows
Inoperative (Action Code 907) to SPAN in DE 39.

Transaction Flows
4.6.3 Timeout Processing – Timer set by SPAN expires (KSA Acquirer ATM)
0400 –Reversal Request
0410 –Reversal Request Response
0420 –Reversal Advice
0430 –Reversal Advice Response
1420 – Reversal Advice
1430 – Reversal Advice Response
Diagram: 2
0100
4
0110
5 VISA-BASE I
0400
6
0410
2
0200
4
0210
5 VISA-SMS
0420
6
0430
2
1 1200
1200 4
KSA Acquirer 1210 KSA Card Issuer
3 SPAN 5
Bank 1420 Bank
1210
6
1430
2
0200
4
0210
5 GCC-Net
0420
6
0430
2
0200
4
0210
5 MasterCard-MDS
0420
6
0430
Purpose: The purpose of the timeout setting is to provide a mechanism to handle

events such as a communications failure or Card Issuer Bank processing
error within the SPAN network.
This mechanism provides improved network performance by assuring that
transaction queuing levels are maintained at a predefined level by
eliminating single transaction failures.
Used For: SPAN Request Transaction Timeouts
diagram above.

Transaction Flows
SPAN verifies the transaction as described in Section 2 and Section 3 and
then routes an 0100 Authorisation Request, a 0200 Financial Request or a
1200 Financial Request to the Card Issuer Bank or Network, as applicable,
for authorisation and sets a timer to wait for a response.
Point 3 The SPAN timer expires waiting for the 0110 Authorisation Request
Response or the 0210/1210 Financial Transaction Request Response from
the Card Issuer authorising the transaction.
SPAN then formats a transaction rejection (1210 Financial Transaction
Request response) to the Acquirer Bank with the following field values.
• Action Code field 39 set to "911" indicating the Card Issuer Timed
Out.
SPAN logs the transaction in the system.
Point 4 As SPAN’s timer expired (timed out) waiting for a response from the Card
Issuer, SPAN will have already sent out a decline response to the Acquirer.
If the Issuer is a KSA Card Issuer bank, SPAN then sends a 1420 Reversal
Advice immediately on timeout. A late approved response is ignored.
For some IBCS switches, SPAN sends a 0420 Reversal Advice
immediately on timeout. A late approved response is ignored.
For other IBCS switches it is only when the approved 0110 Authorisation
Request Response or 0210 Financial Request Response is received (after
the timeout), that the reversal is sent.
See International Card Scheme operating regulations for more details
(summarised in section 4.2.1).
In all cases, .a Reversal is only sent if the transaction involved funds being
transferred or cash dispensed. On a balance inquiry or "non-financial"
transaction, SPAN ignores the authorisation and considers the transaction
interchange to be completed in order to reduce line traffic and improve
performance.
Point 5 An 0400 Reversal Request or 0420/1420 Reversal Advice message, as
required, is formatted by SPAN with the following field values to indicate
to the Card Issuer that the transaction response timed out and was therefore
declined by SPAN to the acquirer.
• Transaction Amount set to the total amount to be reversed – this value
should be equal to the original (requested or authorised) amount
(depending on the timing of the reversal).
• Message Reason Code set to either 4006 (Response was received too
late) or 4021 (Timeout waiting for response), depending on the
particular condition that has caused the reversal.

Transaction Flows
• Processing Code set to value in request message – this value indicates

the value in the original message.
• The Original Data element (field 56) is included in the message to
provide details of the original transaction, including the Original
Transaction message type (1200), the Original Sequence Number for
the transaction, and the Date and Time of the original message.
• The Transmission Date and Time (field 7) is set to the current date and
time expressed in Coordinated Universal Time (UTC).
• The Local Transaction Date and Time (field 12) is set to the date and
time set by the initiator of the first message in the transaction.
SPAN immediately logs the reversal. After successfully logging the
reversal information, SPAN adjusts the reconciliation totals of the Card
Issuer to reflect the reversed amount.
The 0400/0420/1420 message is placed in the Store-and-Forward File in
SPAN to maintain the reversal transaction until a successful
acknowledgement is received indicating the Card Issuer is aware of the
reversal. SPAN continues to send the reversal (configurable parameters) in
the form of the 0401 Reversal Request Repeat or a 0421/1421 Reversal
Advice Repeat message, until the 0410 Reversal Request Response or the
0430/1430 Reversal Advice Response, as required, is received from the
Card Issuer/Network.
Point 6 SPAN receives the 0410 Reversal Request Response or 0430/1430
Reversal Advice Response message from the Card Issuer/Network. SPAN
then removes the message from the Store-and-Forward File.
Note: Card Issuers must always send a 0110 or 0210/1210 response, as
applicable, even when it is late. However, in the unlikely event that an
approved withdrawal is lost, it will be handled by the Issuer at
reconciliation time. To this purpose, Card Issuers will be requested to
perform a daily ATM process to automatically reconcile any transaction
that was not reflected in SPAN reconciliation detail information.
(A) Reversal transactions cannot be denied when the system is operational.
Exception scenarios include the card issuer switch inoperative; card issuer
in signed off state; card issuer timed out; or card issuer unavailable.
Additionally, the following responses are acceptable and require SPAN to
retain and continue sending the reversal information (Store-and-Forward)
until a 0410/0430/1430 response is received from the Card Issuer (though
not indefinitely).
Action Code Description
(field 39)
916 MAC Incorrect
917 MAC Key Sync

Transaction Flows
(B) The reversal recipient could have a problem processing the reversal due to
a minor field format error or other processing error. In these instances, the
issuer must log the response and return the appropriate Action Code (DE
39), however no financial update to the Cardholder's account is anticipated
and the reversal initiator logs the transaction and removes it from the
Store-and-Forward queue. However a major format or other error will
cause a 1644 Administration Notification to the SPAN.
Additionally, reconciliation totals should not be adjusted since the
Cardholders' accounts have not been adjusted at this time. This leaves the
responsibility for reconciliation of the Cardholder's account with the issuer
(as an administrative procedure) rather than automatically affecting the
balance. The Acquirer is also required to provide reports of the reversal to
SPAN for reconciliation purposes.
SPAN provides the reversal information to the Card Issuer in its daily
reporting.
(C) For the full list of supported Action Codes (DE 39) for reversals refer to
3.4.24.
(D) The Reconciliation Date (DE 28) in the request from the Acquirer Bank is
with a 1644 containing Action Code 942. If the date is not equal to the
SPAN business day then SPAN will decline with Action Code ‘942’.
their system.

Transaction Flows
4.6.4 Timeout Processing – Timer set by SPAN expires (SAMA ATM)

Diagram: 1
2
1200
Request 5
1210 KSA Card Issuer
ATM 3 SPAN 6
Response 1420 Bank
4 7
Completion 1430
Purpose: The purpose of the timeout setting is to provide a mechanism to handle

events such as a communications failure or Card Issuer Bank processing
error within the SPAN network.
This mechanism provides improved network performance by assuring that
transaction queuing levels are maintained at a predefined level by
eliminating single transaction failures.
Used For: SPAN Request Transaction Timeouts
diagram above.
Point 2 SPAN receives the ATM request message and uses the Track 2 data to
then routes a 1200 Financial Request to the Card Issuer Bank for
authorisation and sets a timer to wait for a response.
Point 3 The SPAN timer expires waiting for the 1210 Financial Request Response
from the Card Issuer authorising the transaction.
SPAN then formats a transaction rejection Response to the ATM indicating
that the Card Issuer timed out.
SPAN logs the transaction in the system.
Point 4 The transaction is then completed with the Cardholder at the ATM. A
completion message is sent to SPAN.
Point 5 As SPAN’s timer expired (timed out) waiting for a response from the Card
Issuer, SPAN will have already sent out a decline response to the ATM.
SPAN then sends a 1420 Reversal Advice immediately on timeout. A late
approved response is ignored.
A Reversal is only sent if the transaction involved funds being transferred
or cash dispensed. On a balance inquiry or "non-financial" transaction,
SPAN ignores the authorisation and considers the transaction interchange
to be completed in order to reduce line traffic and improve performance.
Point 5 A1420 Reversal Advice message is formatted by SPAN.
the 1420 Reversal Advice sent to a KSA Card Issuer, the following field
values indicate to the Card Issuer that the transaction response timed out
and was therefore declined by SPAN to the ATM.

Transaction Flows

should be equal to the original (requested or authorised) amount
(depending on the timing of the reversal).
• The Original Data element (DE 56) is included in the message to
• The Transmission Date and Time (DE 7) is set to the current date and
• The Local Transaction Date and Time (DE12) is set to the date and
SPAN immediately logs the reversal. After successfully logging the
reversal information, SPAN adjusts the reconciliation totals of the Card
Issuer to reflect the reversed amount.
The 1420 message is placed in the Store-and-Forward File in SPAN to
maintain the reversal transaction until a successful acknowledgement is
received indicating the Card Issuer is aware of the reversal. SPAN
continues to send the reversal (configurable parameters) in the form of a
/1421 Reversal Advice Repeat message, until the 1430 Reversal Advice
Response, as required, is received from the Card Issuer/Network.
Point 6 SPAN receives the 1430 Reversal Advice Response message from the
Card Issuer/Network. SPAN then removes the message from the Store-
and-Forward File.
Note: Card Issuers must always send a 1210 response, as applicable, even
when it is late. However, in the unlikely event that an approved
withdrawal is lost, the Issuer will handle it at reconciliation time. To this
purpose, Card Issuers will be requested to perform a daily ATM process to
automatically reconcile any transaction that was not reflected in SPAN
reconciliation detail information.

Transaction Flows

Exception scenarios include the card issuer switch inoperative; card issuer
in signed off state; card issuer timed out; or card issuer unavailable.
Additionally, the following responses are acceptable and require SPAN to
retain and continue sending the reversal information (Store-and-Forward)
until a 1430 response is received from the Card Issuer (though not
indefinitely).
(DE 39)
916 MAC Incorrect
917 MAC Key Sync
cause a 1644 Administration Notification to the SPAN (rather than a 1420
Reversal Advice Response).
balance.
reporting.
section 3.4.24.

Transaction Flows
4.6.5 Timeout Processing – Timer set by Acquirer expires (KSA Acquirer ATM)
Diagram: 2
0200
3
0210
7 VISA-SMS
0420
8
0430
2
0100
3
0110
7 VISA/Plus
0400
8
0410
1 2
1200 1200
4 3
KSA Acquirer 1210 1210 KSA Card Issuer
5 SPAN 7
Bank 1420 1420 Bank
6 8
1430 1430
2
0200
3
0210
7 GCC-Net
0420
8
0430
2
0200
3
0210
7 MasterCard-MDS
0420
8
0430
Purpose: The purpose of the Acquirer Bank timeout processing is to provide a

mechanism to handle the rare event of a communications failure or SPAN
processing error that does not provide a 1210 response to the Acquirer for
an authorised transaction.
This mechanism is designed eliminate out-of-balance situations from
occurring due to communications failures.
Used For: SPAN Response Transaction Timeouts
diagram above.

Transaction Flows
processing system and sent to SPAN, and sets a timer to wait for a
response.
for authorisation.
Point 3 A timer set by the Acquirer Bank expires before it receives a response, so
the Acquirer denies the transaction.
The Card Issuer Bank sends a late response approving the transaction to
SPAN, after the Acquirer has timed-out.
The late 0110 Authorisation Request Response or 0210/1210 Financial
Transaction Request Response, as applicable, is sent to SPAN from the
Card Issuer/Network authorising the transaction.
Point 4 SPAN ATM logs the transaction and forwards the late response to the
Acquirer Bank as a 1210 Financial Transaction Request Response.
Point 5 When the Acquirer bank’s timer expires the Acquirer Bank formats a 1420
Reversal Advice irrespective of whether the response has been received.
Thereafter a late approved response is ignored
The 1420 Reversal Advice sent to SPAN includes the following
information.
should be equal to the original requested amount.
The 1420 message should be placed in a Store-and-Forward queue in the
Acquirer's processing system to maintain the reversal transaction until a
successful acknowledgement from SPAN is received indicating SPAN is
aware of the reversal. The Acquirer must continue to send the reversal in
the form of the 1421 Reversal Advice Repeat message, on a periodic basis,

Transaction Flows
until the 1430 Reversal Advice Response is received from SPAN.

Note: When the transaction is a Balance Inquiry Request or the response is
a denial, the Transaction Acquirer Bank can drop the message.
Point 6 SPAN receives the 1420 Reversal Advice message from the Acquirer, logs
the transaction, and formats a 1430 Reversal Advice Response to the
Acquiring Bank.
Point 7 SPAN identifies the Card Issuer Bank/Network that processed the
transaction from information in the message. The 0400 Reversal Request
or 0420/1420 Acquirer Reversal Advice message, as applicable, is then
routed to the Card Issuer/Network.
Point 8 Upon receipt of the 0400 Reversal Request or 0420/1420 Reversal Advice,
from SPAN, the Card Issuer system is expected to log the transaction and
adjust the balances of the Cardholder's account, reconciliation totals, and
the number and amount of withdrawals from the Cardholder's account
based on the Transaction Amount (field 4) in the 0400/0420/1420 message.
The Issuer/Network must then format a 0410 Reversal Request Response
or 0430/1430 Acquirer Reversal Advice Response, as applicable, to SPAN
acknowledging the receipt of the reversal from SPAN.
SPAN removes the reversal from the queue, adjusts the reconciliation
totals, and maintains a log of the reversal transaction for reconciliation and
reporting purposes. The Issuer processing system must adjust the totals
used in online reconciliation to reflect the reversed amount.
Note: When an acquirer processor times out while waiting for a response
from SPAN, the processor must deny the transaction as a timeout. This
time period is established by SPAN.
Exception scenarios include the SPAN switch inoperative; SPAN in signed
off state; SPAN timed out; or SPAN unavailable. Additionally, the
following responses are acceptable and require the Acquirer Bank to retain
the reversal information (Store-and-Forward) until a 1430 response is
received from SPAN. SPAN also retains reversal information (Store-and-
Forward) in the event that the Card Issuer does not acknowledge receipt of
the reversal with the 1430 response.
Reversal transactions cannot be denied when the system is operational.
The following exceptions are acceptable and require SPAN to retain and
continue sending the reversal information (Store-and-Forward) until a
0410/0430/1430 response is received from the Card Issuer (though not
indefinitely).
(field 39)
916 MAC Incorrect
917 MAC Key Sync

Transaction Flows
issuer must log the response and return the appropriate Action Code,
however no financial update to the Cardholder's account is anticipated and
the reversal initiator logs the transaction and removes it from the Store-
and-Forward queue. However a major format or other error will cause a
1644 Administration Notification to the originator.
reporting.
(C) For the full list of supported Action Codes (DE 39) for reversals refer
to section 3.4.24.
(D) The Reconciliation Date (DE 28) in the request from the SPAN Acquirer
Bank is checked by SPAN. If the date is not equal to the SPAN business
day then SPAN will decline with Action Code 942. The Reconciliation
Date in the response from the SPAN Card Issuer Bank must be equal to the
Reconciliation Date inserted in the request by SPAN. If it is not, the
response is rejected with a 1644 containing Action Code 942.
their system.
No advice retry shall be attempted (only when advices are coming from the
SPAN Bank).

Transaction Flows
4.6.6 Reversal – Reversal due to ATM problem (KSA Acquirer ATM)

Diagram: 2
0200
3
0210
7 VISA-SMS
0420
8
0430
2
0100
3
0110
7 VISA/Plus
0400
8
0410
1 2
1200 1200
4 3
KSA Acquirer 1210 1210 KSA Card Issuer
5 SPAN 7
Bank 1420 1420 Bank
6 8
1430 1430
2
0200
3
0210
7 GCC-Net
0420
8
0430
2
0200
3
0210
7 MasterCard-MDS
0420
8
0430
Purpose: The purpose of SPAN reversal processing is to handle an ATM failure.

It is the responsibility of the Transaction Acquirer to inform the network of
any errors that occur during the processing of a previously authorised
transaction. Reversal processing is handled as an interaction between each
Bank and SPAN. The Acquirer Bank informs SPAN of the reversal and
SPAN acknowledges receipt. SPAN then informs the Issuing Bank of the
reversal and expects acknowledgement from the Bank. In each reversal,
SPAN logs the reversal and each Bank must also do so.
A reversal need only be generated when there is a request of funds
involved. For a Balance Inquiry transaction the Acquirer does not need to
generate a reversal when the transaction does not complete normally.
Used For: SPAN Reversal Due to ATM Problem

Transaction Flows
diagram above.
processing system and sent to SPAN, and sets a timer to wait for a
response.
for authorisation:
Point 3 The Card Issuer Bank or Network sends a 0110 Authorisation Request
Response or a 0210/1210 Financial Transaction Request Response
message approving the transaction to SPAN.
Point 4 SPAN logs the transaction and formulates a 1210 from the 0110 if
required, and forwards the response to the Transaction Acquirer.

Transaction Flows
Point 5 The Transaction Acquirer attempts to complete the transaction with the
Cardholder at the ATM, but is unable to do so because of an ATM
problem. This problem could be due to various malfunctions, such as a
device error or because the ATM did not correctly dispense the money (see
4.6.7 for a partial dispense). Because the Acquirer Bank determined a
dispense error at the ATM or some other problem that did not allow the
Acquirer to complete the dispense of cash at the ATM device, it is the
Acquirer's responsibility to inform the network that the transaction did not
complete successfully.
A 1420 Reversal Advice message must be sent to SPAN with the following
information.
• Transaction Amount (field 4) set to the total amount to be reversed –
this value should be equal to the original requested amount.
• Message Reason Code (field 25) set to an appropriate value to indicate
to SPAN that a processing error has occurred. See section 3.4.16
(Reason for a Reversal) for valid message reason codes.
• Processing Code (field 3) set to value in request message – this value
indicates the value in the original message.
The 1420 message should be placed in a Store-and-Forward queue in the
Acquirer's processing system to maintain the reversal transaction until a
successful acknowledgement from SPAN is received indicating SPAN is
aware of the reversal. The Acquirer must continue to send the reversal in
the form of the 1421 Reversal Advice Repeat message, on a periodic basis,
until the 1430 Acquirer Reversal Advice Response is received from SPAN.
Point 6 SPAN formats a 1430 Reversal Advice Response acknowledgement
message and sends it to the transaction Acquirer.
Point 7 SPAN logs the 1420 Reversal Advice message, formulates a 0400 Visa
Reversal Request if required, and routes the 0400/0420/1420, as
applicable, to the Card Issuer/Network.
Point 8 Upon receipt of the 0400/0420/1420 Reversal Advice from SPAN, the
Card Issuer system is expected to log the transaction and adjust the
balances of the Cardholder's account, reconciliation totals, and the number
and amount of withdrawals from the Cardholder's account based on the
Transaction Amount field (field 4) in the 1420 message. The issuer is then
expected to format a 0410 Reversal Request Response or 0430/1430
Reversal Advice Response, as applicable, to SPAN acknowledging the
receipt of the reversal from SPAN.
SPAN removes the reversal from the queue, adjusts the reconciliation
reporting purposes. The issuer processing system must adjust the totals

Transaction Flows
following responses are acceptable and require the Acquirer to retain the
reversal information (Store-and-Forward) until a 1430 response is received
from SPAN. SPAN also retains reversal information (Store-and-Forward)
in the event that the Card Issuer does not acknowledge the receipt of the
reversal with the 1430 response.
(field 39)
916 MAC Incorrect
917 MAC Key Sync
issuer must log the response and return the appropriate Action Code (field
cause a 1644 Administration Notification to the originator
reporting.
section to 3.4.24.
(D) The Reconciliation Date (DE 28) in the request from the SPAN Acquirer
Bank is checked by SPAN. If the date is not equal to the SPAN business
day then SPAN will decline with Action Code 942. The Reconciliation
Date in the response from the SPAN Card Issuer Bank must be equal to the
Reconciliation Date inserted in the request by SPAN. If it is not, the
response is rejected with a 1644 containing Action Code 942.
their system.
No advice retry shall be attempted (only when advices are coming from the
SPAN Bank).

Transaction Flows
4.6.7 Reversal – Reversal due to ATM problem (SAMA ATM)

1 2
Diagram: Request 1200
4 3
ATM Response 1210 KSA Card Issuer
5 SPAN 6
Exception 1420 Bank
7
1430
Purpose: The purpose of SPAN reversal processing is to handle an ATM failure.

In this case, where the directly connected ATM indicates a problem in the
completion. SPAN would then need to initiate a Reversal to the appropriate
Card Issuer.
A reversal need only be generated when there is a request of funds
involved and the request is approved. For a Balance Inquiry transaction
SPAN does not need to generate a reversal when the transaction does not
complete normally.
Used For: SPAN Reversal due to an ATM Problem.
diagram above.
Point 2 SPAN uses the Track 2 data to determine the Cardholder's Bank.
SPAN verifies the transaction and then routes a 1200 Financial Request to
the Card Issuer Bank indicated by Track 2, for authorisation.
Point 3 The Card Issuer Bank sends a 1210 Financial Request Response message
approving the transaction to SPAN.
Point 4 SPAN logs the transaction and formulates a Response and forwards the
Response to the ATM.
Point 5 The ATM attempts to complete the transaction with the Cardholder, but is
unable to do so because of an ATM problem. This problem could be due to
various malfunctions, such as a device error.
The ATM advises SPAN of the problem in an Exception message.
SPAN must interpret the information in the Exception message and, if the
preceding transaction was an approved Financial Request, generate a
Reversal for the same amount as the approved transaction to the Card
Issuer or Network.
Point 6 SPAN formulates a 1420 Reversal Advice routes it to the Card Issuer.

Transaction Flows
Point 7 The Card Issuer receives the 1420 Reversal Advice from SPAN.
The KSA Card Issuer is expected to log the transaction and adjust the
balances of the Cardholder's account, reconciliation totals, and the number
and amount of withdrawals from the Cardholder's account based on the
Transaction Amount field (DE 4) in the 1420 Reversal Advice message.
The Card Issuer then formats a 1430 Reversal Advice Response to SPAN
acknowledging the receipt of the reversal from SPAN.
SPAN removes the reversal from the SAF queue, adjusts the reconciliation
reporting purposes. The issuer processing system must adjust the totals
following responses are acceptable and require the Acquirer to retain the
reversal information (Store-and-Forward) until a 1430 response is received
from SPAN. SPAN also retains reversal information (Store-and-Forward)
in the event that the Card Issuer does not acknowledge the receipt of the
reversal with the 1430 response.
(field 39)
916 MAC Incorrect
917 MAC Key Sync
cause a 1644 Administration Notification to the originator (rather than a
1430 Reversal Response).
balance.
reporting.
section 3.4.24.

Transaction Flows
(D) The Reconciliation Date in the response from the SPAN Card Issuer Bank
must be equal to the Reconciliation Date inserted in the request by SPAN.
If it is not, the response is rejected with a 1644 containing Action Code
942.
their system.

Transaction Flows
4.6.8 Communications Failure – Link Down between SPAN and Card Issuer (KSA Acquirer
ATM)
1804 Network Management Request
1814 Network Management Request Response
3
Diagram: 1
1804
3
1200 1804
KSA Acquirer KSA Card Issuer
2 SPAN 3
Bank 1804 Bank
1210 4
1814
Purpose: The purpose of the process is to provide a mechanism to handle events

such as a communications failure or Card Issuer Bank processing error
within the SPAN network.
Used For: SPAN Card Issuer Link Down
diagram above.
(stored on Track 2 data of a magnetic stripe card, stored in DE35).
Normally, SPAN verifies the transaction as described in Section 2 and
Section 3 and then routes a 1200 Financial Request to the Card Issuer Bank
If the Card Issuer is marked as unavailable SPAN does not send a
transaction to the Card Issuer but responds immediately to the Acquirer
with a declined 1210 Financial Response indicating the Card Issuer is
unavailable (DE 39 Action Code 907).
Point 3 SPAN will start to send ‘echotest’ transactions to determine when the link
becomes available again.
An 1804 Network Management (DE 24 Function Code 831) message is
sent to the KSA Card Issuer to determine availability. This is sent
periodically until a response is received.
In this example 1804 Network Management message is sent three times
before a valid response is received.
Point 4 When a successful 1814 Network Management Request Response is
received to the echotest, SPAN will then recognise the link as being
available again and start to route financial transactions to the link.

Transaction Flows
Exception Processing: The Reconciliation Date (DE 28) in the request from the Acquirer Bank is
their system.

Transaction Flows
4.7 ATM Reconciliation Messages
This subsection describes the flow of reconciliation messages between SPAN and either an Acquirer
Bank or a Card Issuer Bank. The reconciliation transaction provides financial totals between one
acquirer and one card issuer. SPAN sends reconciliation advices by processing an online balancing
algorithm and determining whether accumulated totals at the Bank are in agreement with those sent by
SPAN. The Member Banks must always acknowledge reconciliation advices sent by SPAN and log
them for resolving disputes at a later time. After SPAN completes its cutover, and after the
reconciliation time window period expires, SPAN will follow up with both Acquirer and Card Issuer
totals for the posted SPAN business date.
Reconciliation advice messages request the confirmation of totals (number and value). The totals
contained in a reconciliation advice message indicates an originating institution’s position as either an
acquirer or card issuer (but not both) as defined by the message type identifier. In all reconciliation
messages from SPAN, the Net Reconciliation Amount (field 97) is the basis for determining whether
the Bank and SPAN agree on the settlement amount. The net reconciliation amount is calculated using
the following formulas, based on the debit and credit as posted from SPAN’s perspective. All amounts
in the reconciliation messages are in the currency of reconciliation. If the net reconciliation amount
after completing computation of the results above is a negative value the character “D” shall be inserted
into the “X” portion of the net reconciliation amount otherwise the character “C” shall be inserted in
the “X” position.
1. 1522 Card Issuer Reconciliation Advice
2. 1520 Acquirer Reconciliation Advice
Where,
Credit Totals = Amount Credits + Reversal Amount Credits
Debit Totals = Amount Debits + Reversal Amount Debits
The Amount Credits element is the sum of Transaction Amount (field 4) in all financial
transactions exclusive of fees where positions 1-2 of the processing code in the financial
transaction indicated a credit (20-29).
The Reversal Amount Credits element is the sum of Transaction Amount (field 4) in all
financial transactions exclusive of fees where positions 1-2 of the processing code in the
financial transaction indicated a debit (00-19).
The Amount Debits element is the sum of Transaction Amount (field 4) in all financial
transaction indicated a Debit (00-19).
The Reversal Amount Debits element is the sum of Transaction Amount (field 4) in all
financial transaction indicated a credit (20-29).
3. The net reconciliation position for the Bank is calculated using the following formula.
Net Reconciliation Acquirer Net Card Issuer Net
= +
Amount Reconciliation Amount Reconciliation Amount
A positive amount signifies that the Bank has a net credit position, so SPAN will post this
amount as a credit to the Bank at settlement time. A negative amount represents a net debit
position for the Bank, so SPAN will post this amount as a debit at settlement time.

Transaction Flows
The Bank Card Scheme Totals Information (Field 126) is used to carry additional detailed
settlement information. This field contains the combined totals of all bankcard scheme
transactions. This field is for statistical use only, and is not used for financial settlement.

Transaction Flows
4.7.1 Acquirer Reconciliation Processing

ISO Message Types: 1520 – Acquirer Reconciliation Advice
1530 – Acquirer Reconciliation Advice Response
Diagram: 1
1520
SPAN 2 Bank
1530
Purpose: The purpose of SPAN Acquirer reconciliation processing is to provide an

automated mechanism within the network to allow for reconcilement error
notification. The totals reflected within these messages are computed
based on the SPAN business day for the period being reported. These
totals reflect the total activity that has occurred between SPAN and the
Card Issuer Bank for the period between the last two cutover messages
(ISO Message Type 1804 with a Function Code of 821) from SPAN. The
Card Issuer Bank should maintain totals of all transactions that have been
exchanged between the Bank processing system and SPAN for that cutover
period.
Used For: Verification of the Cutover Totals between the Card Issuer Bank and
SPAN.
diagram above.
Point 1 SPAN generates the 1520 Acquirer Reconciliation Request using totals
that have been accumulated and saved for the period between the last two
1804 Network Management Request (Cutover) messages sent from SPAN.
The period between the previous two cutover messages sent from SPAN to
the Bank defines the previous business day. The totals in this message
reflect all approved financial and reversal transactions that were authorised
or processed by the Card Issuer.
Upon receipt of the 1520 Acquirer Reconciliation Advice, the Bank must
verify the message content (See exception processing below). The
reconciliation position, as reflected in the totals in the message, should be
equal to the net reconciliation position for SPAN’s business day as
computed by the Bank. The algorithm used to perform this balancing is
fully described in Section 5 of this manual. Each total that is provided in
the message is defined in Section 3 - Field Descriptions, of this manual.
Consult these two sections to further define the processing requirements
for online reconciliation.
In computing this position, the Bank should keep in mind the totals
provided in the message should agree with the totals calculated by the
Bank. Due to reversal processing, and the Store-and-Forward nature of
these messages, it is possible for the reversal totals to be unequal at the
point of cutover. In automating the reconcilement process, be sure to allow
for manual processing of the reversals as some may not be included in the
daily total from SPAN and may be included in the reversal counts of the
Bank, depending on the Bank’s systems processing characteristics.

Transaction Flows
Point 2 When the reconciliation position is stated correctly in the message, the
Bank must format the 1530 Acquirer Reconciliation Advice Response with
a value of “500” in the Action Code field 39. The conditional total fields of
the message (all of the totals) should not be sent as they are in agreement
with SPAN’s totals. The Bank processing system must log the totals
received from SPAN and use them on a report to be used by Bank
personnel for verification of reconcilement totals.
SPAN receives the 1530 Acquirer Reconciliation Advice Response and
verifies the receipt of reconcilement totals by the Bank. SPAN logs the
acknowledgement of reconciliation totals for the previous business day and
clears those totals from the system memory.
Verify the Reconciliation Date (field 28) contains the previous SPAN
business day. When it does not, set the value of “915” – Error, in the
Action Code (field 39).
When the amounts present in the message do not correspond to the total
computed by the Bank, the Action Code (field 39) must be set to a value of
“501” Out-of-Balance Condition. The Banks computed totals must be
placed in the Conditional Total fields of the 1530 message for the out-of-
balance totals that the issuer has identified.

Transaction Flows
4.7.2 Card Issuer Reconciliation Processing

ISO Message Types: 1522 – Card Issuer Reconciliation Advice
1532 – Card Issuer Reconciliation Advice Response
Diagram: 1
1522
SPAN 2 Bank
1532
Purpose: The purpose of SPAN ATM Issuer reconciliation processing is to provide

an automated mechanism within the network to allow for reconciliation
error notification. The totals reflected within these messages are computed
based on SPAN business day for the period being reported. These totals
reflect the total activity that occurred between SPAN and the Acquirer
Bank for the period between the last two cutover messages (ISO Message
Type 1804 with a Function Code of 821) from SPAN. The Acquirer Bank
should maintain totals of all transactions that have been forwarded from
the Bank processing system to SPAN for that cutover period.
Used For: Verification of the Cutover Totals between the Acquirer Bank and SPAN
diagram above.
Point 1 SPAN generates the 1522 Card Issuer Reconciliation Request using totals
The period between the previous two cutover messages sent by SPAN
defines the previous SPAN business day. The totals in this message reflect
all approved financial and reversal transactions that originated in the
Acquirer Bank.
Upon receipt of the 1522 Card Issuer Reconciliation Request, the Bank
must verify the message content (See exception processing below). The
equal to the net reconciliation position for SPAN’s business day as
computed by the Bank.
In computing this position, the Bank should keep in mind that the totals
point of cutover. In automating the reconciliation process, be sure to allow
for manual processing of the reversals, as some may not be included in the
Bank, depending on the Bank’s system processing characteristics.

Transaction Flows
Point 2 When the net reconciliation position is stated correctly in the message, the
Bank must format the 1532 Card Issuer Reconciliation Advice Response
with a 500 in the Action Code (field 39). The conditional total fields of the
message (all of the totals) must not be sent as they are in agreement with
SPAN’s totals. The Bank processing system must log the totals received
from SPAN and use them on a report to be used by Bank personnel for
verification of reconcilement totals.
SPAN receives the 1532 Issuer Reconciliation Advice Response verifying
the receipt of reconcilement totals by the Bank. SPAN logs the
(A) Verify the Reconciliation Date (field 28) contains the previous SPAN
business day. When it does not, log the message and send and set the
Action Code (field 39) to a value of “915” – Error.
(B) When the amounts present in the message do not correspond to the total
“501” – Out of Balance in the 1532 Card Issuer Reconciliation Response
message. The Bank’s computed totals must be placed in the Conditional
Total fields of the 1532 message for the out-of-balance totals that the
Acquirer Bank has identified.

Transaction Flows
4.7.3 Acquirer Reconciliation Store-and-Forward

ISO Message Types: 1520 – Acquirer Reconciliation Request
1521 – Acquirer Reconciliation Request Repeat
1530 – Acquirer Reconciliation Request Response
Diagram: 1
1520
2
SPAN 1521 Bank
3
1530
Purpose: The purpose of SPAN ATM Acquirer reconciliation processing is to

provide an automated mechanism within the network to allow for
reconciliation error notification. The totals reflected within these messages
are computed based on the SPAN business day for the reporting period.
These totals reflect the total activity that has occurred between SPAN and
the Card Issuer for the period between the last two cutover messages (ISO
Message Type 1804 with a Function Code of 821) from SPAN. The
issuing Bank must maintain totals of all transactions that have been
period.
In the event that the 1530 response message is not received by SPAN upon
issuing a 1520 Acquirer Reconciliation Request, SPAN ATM generates a
repeat message (1521) to verify that reconciliation totals are received by
the Bank. This message is sent by SPAN every two minutes until the 1530
response is received by SPAN from the Bank.
SPAN.
diagram above.
Point 1 SPAN generates the 1520 Acquirer Reversal Advice to the Card Issuer
Bank and times out.

Transaction Flows
Point 2 SPAN then generates the 1521 Acquirer Reconciliation Advice Repeat.
The totals in this message reflect all transactions that were received from
the Acquirer Bank in a period between the previous two cutover messages
that were sent from SPAN to the Bank.
Upon receipt of the 1521 Acquirer Reconciliation Request Repeat, the
Bank must verify the message content (See Exception Processing below).
The reconciliation position, as reflected in the totals in the message, should
be equal to the reconciliation position for SPAN’s business day as
fully described in Section 5 of this manual. Each total provided in the
message is defined in Section 3 - Field Descriptions, of this manual.
Consult these two sections to further define the processing requirements
for online reconciliation.
In computing this position, the Bank should keep in mind that all totals
provided in the message may not match. Due to reversal processing, and
the Store-and-Forward nature of these messages, it is possible for the
reversal totals to be unequal at the point of cutover. In automating the
reconciliation process, be sure to allow for manual processing of the
reversals as some may not be included in the daily total from SPAN and
may be included in the reversal counts of the Bank, depending on the
Bank’s systems processing characteristics.
Point 3 When the reconciliation position is stated correctly in the message, the
Bank must format the 1530 Acquirer Reconciliation Advice Response with
a value of “500” in the Action Code (field 39). The conditional total fields
of the message (all of the totals) must not be sent as they are in agreement
with SPAN totals. The Bank processing system must log the totals received
verification of reconciliation totals.
verifies the receipt of reconciliation totals by the Bank. SPAN logs the
Verify the Reconciliation Date (field 28) contains the previous SPAN
business day. When it does not, log the message with the value of “915” –
Error, in the Action Code (field 39).
When the amounts present in the message do not correspond to the total
“501” indicating the Out-of-balance Condition. The Banks computed totals
must be placed in the conditional total fields of the 1530 message for the
out-of-balance totals that the Acquirer Bank has identified.

Transaction Flows
4.7.4 Card Issuer Reconciliation Store-and-Forward

ISO Message Types: 1522 – Issuer Reconciliation Request
1523 – Issuer Reconciliation Request Repeat
1532 – Issuer Reconciliation Request Response
Diagram: 1
1522
2
SPAN 1523 Bank
3
1532
Purpose: The purpose of SPAN ATM Issuer reconciliation processing is to provide

an automated mechanism within the network to allow for reconciliation
error notification. The totals reflected within these messages are computed
based on the SPAN business day for the period being reported. These totals
reflect the total activity that has occurred between SPAN and the Acquirer
for the period between the last two cutover messages (ISO Message Type
1804 with a Function Code of 821) from SPAN. The Acquirer Bank must
maintain totals of all transactions that have been forwarded from the Bank
processing system to SPAN for that cutover period.
In the event that the 1532 response message is not received by SPAN upon
issuing a 1522 Issuer Reconciliation Request, SPAN ATM generates the
repeat message to verify that reconciliation totals are received by the Bank.
This message is sent by SPAN every two minutes until the 1532 response
is received by SPAN from the Bank.
Used For: Verification of the Cutover Totals between the Acquirer Bank and SPAN
diagram above.
Point 1 SPAN generates the 1522 Issuer Reconciliation Request to the Acquirer
Bank and times out.

Transaction Flows
Point 2 SPAN generates the 1523 Issuer Reconciliation Request Repeat. The
totals in this message reflect all transactions that were sent to the Acquirer
Bank in a period between the previous two cutover messages that were sent
from SPAN to the Bank.
Upon receipt of the 1523 Issuer Reconciliation Request Repeat, the Bank
must verify the message content (See Exception Processing below). The
equal to the settlement position for SPAN’s business day as computed by
the Bank. The algorithm used to perform this balancing is fully described
Section 5of this manual. Each total that is provided in the message is
defined in Section 3 - Field Descriptions, of this manual. Consult these two
sections to further define the processing requirements for online
reconciliation.
In computing this position, the Bank should keep in mind that all totals
Bank’s systems processing characteristics.
Point 3 When the settlement position is stated correctly in the message, the Bank
must format the 1532 Issuer Reconciliation Advice Response with a value
of “500” in the Action Code (field 39). The conditional total fields of the
message (all of the totals) must not be sent as they are in agreement with
SPAN totals. The Bank processing system must log the totals received
verification of reconciliation totals.
SPAN receives the 1532 Issuer Reconciliation Advice Response and
(A) Verify the Reconciliation Date (field 28) contains the previous SPAN
business day. When it does not, log the message and set the Action Code
(field 39) to a value of “915”.
(B) When the amounts present in the message do not correspond to the total
“501” indicating Out of Balance. The Banks computed totals must be
placed in the conditional total fields of the 1532 message for the out-of-
balance totals that the Acquirer Bank has identified.

Transaction Flows
4.8 POS Financial Transaction Messages
This subsection describes the flow of POS financial transaction messages through SPAN for both
Retailer Banks and Card Issuer Banks.
The following message types are used in the transaction flows in this section:
Authorisation.
1100 Authorisation Request
1110 Authorisation Request Response
1120 Authorisation Advice
1121 Authorisation Advice Repeat
1130 Authorisation Advice Response
Financial:
1200 Financial Request
1210 Financial Request Response
1220 Financial Advice
1221 Financial Advice Repeat
1230 Financial Advice Response
Reversal:
1420 Acquirer Reversal Advice
1421 Acquirer Reversal Advice Repeat
1430 Acquirer Reversal Advice Response
Reconciliation:
1520 Acquirer Reconciliation Advice
1521 Acquirer Reconciliation Advice Repeat
1522 Card Issuer Reconciliation Advice
1523 Card Issuer Reconciliation Advice Repeat
1524 Terminal Reconciliation Advice
1525 Terminal Reconciliation Advice Repeat
1530 Acquirer Reconciliation Advice Response
1532 Card Issuer Reconciliation Advice Response
1534 Terminal Reconciliation Advice Repeat Response

Transaction Flows
4.8.1 Financial Transaction – Normal Transaction (Magnetic Stripe)

ISO Message Types: 1200 – Financial Transaction Request
1210 – Financial Transaction Request Response
1220 – Financial Transaction Advice
1221 – Financial Transaction Advice Repeat
1230 – Financial Transaction Advice Response
Diagram: 2 4B
KSA Card Issuer 1200 1220 KSA Retailer
3 SPAN 5
Bank 1210 1230 Bank
4A
1200
1210
1
POS
Terminal
Purpose: To request and receive authorisation for a financial transaction.

This is also used for chip card fallback.
Cash back is not supported for magnetic stripe cards.
Used For: Purchase
Refund
diagram above.
Point 1 SPAN (the Transaction Acquirer) receives a 1200 Financial Request
transaction from a SPAN POS Terminal.
Point 2 SPAN formats the 1200 Financial Request and uses the Track 2 data
(DE35) encoded on the card, for a card swipe, or DE2 when manually
entered, to determine the Cardholder's Bank.
The Card Issuer is supported by SPAN and is currently available.
SPAN then routes the 1200 Financial Request to the Card Issuer Bank for
authorisation.

Transaction Flows
Point 3 The Card Issuer Bank receives the 1200 Financial Request and verifies that
it issued the card.
• Verify the Personal Identification Number (PIN) DE52, as a PIN/PAN
block using the Host Security Module (Refer to Section 7 - Network
Security).
In this instance, the Financial Transaction Request is approved. The Card
Issuer Bank then begins building a 1210 Financial Request Response.
The 1210 Financial Request Response is then formatted and sent to SPAN
for processing.
• Action Code (DE39) is set to “000” indicating a successful
transaction.
When the transaction requested is a Purchase or Refund the appropriate
reconciliation totals for the transaction amount are updated. Reversals
impact the daily purchase limit, but refunds do not affect the limit. Refer to
Section 3 - Field Descriptions, for a complete description of any field
referred to in this manual.
In all 1210 Financial Request Responses sent to SPAN, the Card Issuer
Bank must send all mandatory fields described in Section 2 - Message
Formats, as well as any conditional fields when the specified conditions are
met.
Point 4 (4A) SPAN returns a 1210 Financial Request Response message to the
SPAN POS Terminal.
(4B) If the Card Issuer and Retailer Bank’s are not the same then a 1220
Financial Advice message is sent to the Retailer Bank at the same time as
the response (4A) is returned to the SPAN POS Terminal. The 1220
message contains detailed information allowing the Retailer Bank to post
the transaction to the Retailer's Account.
Point 5 The Retailer Bank must acknowledge the 1220 Financial Advice with the
1230 Financial Advice Response returned to SPAN, which is used to
acknowledge the delivery of the 1220. When a 1230 is not received by
SPAN in response to a 1220, then the 1221 message is sent until the 1230
is received.
SPAN Exception The points describe some of the potential exception processing scenarios
Processing: and the procedure that is to be followed.

Transaction Flows

SPAN formulates the 1200 Financial Request message and uses the Track
2 data to determine the Cardholder's Bank. SPAN checks the contents of
all message fields, determines whether the requested transaction is
Financial Request Response message to the POS terminal with the
returned to the POS terminal in DE39.
(Action Code 907) in DE 39 to the POS terminal.
their system.
(A) Verify transaction selected is valid for the Cardholder at the SPAN
terminal.
If not, return Invalid Transaction (Action Code 902) in DE 39.
117) in DE39.
DE39. The issuer must inhibit further access for that card. The inhibition
should remain in effect until it is lifted through an administrative procedure
upon Cardholder request.
Exceeds Purchase Amount Limit (Action Code 121) to SPAN.

Transaction Flows

in DE39.
If not, send the No Cheque Account (Action Code 114) to SPAN in DE 39.
(G) Verify that the Cardholder’s current account has sufficient funds to
perform the requested transaction.
If note, send Not sufficient funds (Action Code 116) to SPAN in DE39.
(H) Verify that the Cardholder has not exceeded the daily transaction
purchase amount limit.
Code 121) to SPAN in DE39.
to SPAN in DE39.
(J) Verify the Cardholder's daily maximum usage limit has not been
exceeded for the day.
When it has, send the Exceeds Purchase Frequency Limit (Action Code 123)
to SPAN in DE39.
Inoperative (Action Code 907) to SPAN in DE39.

Transaction Flows
4.8.2 Financial Transaction – Normal Transaction (Chip Card)

1120 – Authorisation Advice
1121 – Authorisation Advice Repeat
1130 – Authorisation Advice Response
1220 – Financial Advice
1221 – Financial Advice Repeat
1230 – Financial Advice Response
Diagram: 1100
2 5
1120
3
KSA Card Issuer KSA Retailer
1110 SPAN 1130 6
Bank 9 11 Bank
1220 1220
10
1230 4 8 1230 12
1220
1230
1100
1110
1 7
POS
Terminal
Purpose: To request and receive authorisation for an on-line chip card transaction.
Used For: Purchase
Refund
Cash Back
diagram above.
Point 1 SPAN (the Transaction Acquirer) receives a 1100 Authorisation Request
from a SPAN POS Terminal.
Point 2 SPAN formats the 1100 Authorisation Request and uses chip card data, to
SPAN then routes the 1100 Authorisation Request to the Card Issuer Bank
for authorisation.

Transaction Flows
Point 3 The Card Issuer Bank receives the 1100 Authorisation Request and verifies
that it issued the card.
The Card Issuer Bank processes the transaction as appropriate
The 1110 Authorisation Request Response is then formatted and sent to
SPAN for processing.
Refer to Section 3 - Field Descriptions, for a complete description of any
field referred to in this manual. DE54 is conditional in 1110 Authorisation
Request Responses for purchase and refund authorisations.
In all 1110 Authorisation Request Responses sent to SPAN, the Card
Issuer Bank must send all mandatory fields described in Section 2 -
Message Formats, as well as any conditional fields when the specified
conditions are met.
Point 4 SPAN 1110 Authorisation Request Response message is returned to the
SPAN POS Terminal.
Point 5 If the Card Issuer and Retailer Bank’s are not the same then a 1120
Authorisation Advice message is sent to the Retailer Bank at the same time
as the response (4) is returned to the SPAN POS Terminal.
The 1120 Authorisation Advice is sent whether the transaction is approved
or declined.
Point 6 The Retailer Bank must acknowledge the 1120 Authorisation Advice with
the 1130 Authorisation Advice Response returned to SPAN. When an 1130
is not received by SPAN in response to a 1120, then the 1121 message is
sent until the 1130 is received.
Point 7 When the POS has completed the transaction it formats a 1220 Financial
Advice to SPAN.
Point 8 SPAN responds with a 1230 Financial Advice Response to the POS.
Point 9 SPAN formats and sends 1220 Financial Advice to advise the Card Issuer
what happened at the POS.
Point 10 The Card Issuer responds with a 1230 Financial Advice Response.
Point 11 If the Card Issuer and Retailer Bank’s are not the same then a 1220
the response (8) is returned to the SPAN POS Terminal and the advice (9)
to the Card Issuer bank. The 1220 message contains detailed information
allowing the Retailer Bank to post the transaction to the Retailer's Account.
The 1220 Authorisation Advice is sent whether the Authorisation was
approved or a declined.
Point 12 The Retailer Bank must acknowledge the 1220 Financial Transaction
Advice with the 1230 Financial Transaction Advice Response returned to
SPAN, which is used to acknowledge the delivery of the 1220. When a
1230 is not received by SPAN in response to a 1220, then the 1221
message is sent until the 1230 is received.

Transaction Flows

SPAN formulates the 1100 Authorisation Request message and uses the
Track 2 data to determine the Cardholder's Bank. SPAN checks the
contents of all message fields, determines whether the requested
transaction is allowed, and verifies that the Card Issuer is supported by
SPAN and is currently available. When the transaction fails on any of
these checks, SPAN denies the transaction, logs the message, and returns a
1110 response message to the POS terminal with the appropriate value in
returned to the POS terminal in DE39.
(Action Code 907) in DE39 to the POS terminal.
their system.
(A) Verify transaction selected is valid for the Cardholder at the SPAN
terminal.
If not, return Invalid Transaction (Action Code 902) in DE39.
(B) Verify transaction amount selected is correct.
Exceeds Purchase Amount Limit (Action Code 121) to SPAN.
(C) Verify the account status of the Cardholder's card and current account.

(D) Compare the expiration date of the card (Track 2) to the current date.
in DE39.
(E) Verify that the account the Cardholder is requesting is a valid account.
If not, send the No Cheque Account (Action Code 114) to SPAN in DE39.

Transaction Flows
(F) Verify that the Cardholder’s current account has sufficient funds to
If note, send Not sufficient funds (Action Code 116) to SPAN in DE39.
(G) Verify that the Cardholder has not exceeded the daily transaction
purchase amount limit.
Code 121) to SPAN in DE39.
(H) Verify the Chip Data
A description of this processing is outside the scope of this document.
(I) Verify the Cardholder's daily maximum usage limit has not been
When it has, send the Exceeds Purchase Frequency Limit (Action Code 123)
to SPAN in DE39.
(J) Verify system availability and ensure that no technical problems exist.
Inoperative (Action Code 907) to SPAN in DE39.

Transaction Flows
4.8.3 Financial Transaction – AMEX Normal Transaction (Magnetic Stripe)

1221 – Financial Transaction Advice Repeat
Diagram: AMEX 1200
2 4B
1220 KSA Retailer
Saudi Investment 3 SPAN 5
1210 1230 Bank
Bank (SAIB)
4A
1200
1210
1
POS
Terminal
Purpose: To request and receive authorisation for an AMEX financial transaction.

Cash back is not supported for magnetic stripe cards.
Used For: Purchase
Refund
diagram above.
Point 2 SPAN formats the 1200 Financial Request and uses the Track 2 data
(DE 35) encoded on the card, for a card swipe, or DE 2 when manually
SPAN verifies the transaction as described in Section 4.8.1 and then routes
a 1200 Financial Request to the Card Issuer Bank (SAIB) for authorisation.
Point 3 Saudi Investment Bank (SAIB) receives the 1200 request message and
verifies that AMEX has issued the card and does the necessary processing.
Saudi Investment Bank (SAIB) builds a 1210 Financial Request Response
message as required and sends it to SPAN.
Point 4 (4A) SPAN returns a 1210 Financial Request Response message to the
SPAN POS Terminal.
(4B) If the Card Issuer Bank (SAIB) and Retailer Bank are not the same
then a 1220 Financial Advice message is sent to the Retailer Bank at the
same time as the response (4A) is returned to the SPAN POS Terminal.
The 1220 message contains detailed information allowing the Retailer
Bank to post the transaction to the Retailer's Account.

Transaction Flows
1230 Financial Advice Response returned to SPAN, which is used to
acknowledge the delivery of the 1220. When a 1230 is not received by
SPAN in response to a 1220, then the 1221 message is sent until the 1230
is received.
SPAN formulates the 1200 Financial Request message and uses the Track
2 data to determine the Cardholder's Bank. SPAN checks the contents of
all message fields, determines whether the requested transaction is
Financial Request Response message to the POS terminal with the
(B) Verify Card Issuer institution (i.e. AMEX) is supported by the
network.
returned to the POS terminal in DE 39.
(C) Determine the availability of the Card Issuer Bank (i.e. SAIB).

Transaction Flows
4.8.4 Financial Transaction – AMEX Normal Transaction (Chip Card)

2 5
Diagram: 3 1100 1120
AMEX
KSA Retailer
Saudi Investment 1110 SPAN 1130 6
9 11 Bank
Bank (SAIB)
1220 1220
10
1230 4 8 1230 12
1220
1230
1100
1110
1 7
POS
Terminal
Purpose: To request and receive authorisation for an AMEX on-line chip card
transaction.
Used For: Purchase
Cash Advance
Refund
diagram above.
Point 2 SPAN formats the 1100 Authorisation Request and uses chip card data, to
SPAN verifies the transaction as described in section 4.8.2 and then routes
the 1100 Authorisation Request to the Card Issuer Bank (SAIB) for
authorisation.
Point 3 Saudi Investment Bank (SAIB) receives the 1100 Authorisation Request
and verifies that AMEX has issued the card and does the necessary
processing.
Saudi Investment Bank (SAIB) builds an 1110 Authorisation Request
Response as required an and sends it to SPAN.
Point 4 SPAN 1110 Authorisation Request Response message is returned to the
SPAN POS Terminal.

Transaction Flows
Point 5 If the Card Issuer Bank (SAIB) and Retailer Bank are not the same then a
1120 Authorisation Advice message is sent to the Retailer Bank at the
same time as the response (4) is returned to the SPAN POS Terminal.
The 1120 Authorisation Advice is sent whether the transaction is approved
or declined.
the 1130 Authorisation Advice Response returned to SPAN. When an 1130
is not received by SPAN in response to a 1120, then the 1121 message is
Advice to SPAN.
Point 9 SPAN formats and sends 1220 Financial Advice to advise the Card Issuer
(SAIB) what happened at the POS.
Point 10 The Card Issuer (SAIB) responds with a 1230 Financial Advice Response.
Point 11 If the Card Issuer and Retailer Banks are not the same then a 1220
the response (8) is returned to the SPAN POS Terminal and the advice (9)
to the Card Issuer bank. The 1220 message contains detailed information
allowing the Retailer Bank to post the transaction to the Retailer's Account.
The 1220 Authorisation Advice is sent whether the Authorisation was
approved or a declined.
SPAN, which is used to acknowledge the delivery of the 1220. When a
1230 is not received by SPAN in response to a 1220, then the 1221
message is sent until the 1230 is received.
SPAN formulates the 1100 Authorisation Request message and uses the
Track 2 data to determine the Cardholder's Bank. SPAN checks the
contents of all message fields, determines whether the requested
transaction is allowed, and verifies that the Card Issuer is supported by
SPAN and is currently available. When the transaction fails on any of
these checks, SPAN denies the transaction, logs the message, and returns a
1110 response message to the POS terminal with the appropriate value in
(B) Verify Card Issuer institution (i.e. AMEX) is supported by the
network.
returned to the POS terminal in DE 39.
(C) Determine the availability of the Card Issuer Bank (i.e. SAIB).

Transaction Flows
4.8.5 Financial Authorisation – AMEX Pre-Authorisation (Magnetic Stripe / Chip)

1100 – Authorisation Request
Diagram:
2 4B
1100 1120
3 5
AMEX 1110 1130 KSA Retailer
Saudi Investment 8C SPAN 8B
1120 Bank
Bank (SAIB) 1120
10 9
1130 1130
4A 8A
1100
1110
1130
1120
1 7
POS
Terminal
Purpose: To request and receive pre-authorisation for an AMEX financial

transaction.
Used For: Pre-Authorisation for AMEX magnetic stripe and chip cards
diagram above.
Point 1 SPAN (the Transaction Acquirer) receives an 1100 Authorisation Request
Point 2 SPAN uses the magnetic stripe, manually-entered PAN or chip data to
SPAN verifies the transaction as described in 4.8.3 or 4.8.4 and then routes
an 1100 Authorisation Request to the Card Issuer Bank (SAIB) for
authorisation.
Point 3 Saudi Investment Bank (SAIB) receives the 1100 Authorisation Request
and verifies that AMEX has issued the card and does the necessary
processing.
Saudi Investment Bank (SAIB) builds an 1110 Authorisation Request
Response as required an and sends it to SPAN.
Point 4 (4A) SPAN returns an 1110 Authorisation Request Response message to
the SPAN POS Terminal.
then SPAN sends an 1120 Authorisation Advice message to the Retailer
Bank at the same time as the response (4A) is returned to the SPAN POS
Terminal. This message has a Function Code (DE 24) indicating that this
advice is related to a pre-authorisation (181).

Transaction Flows
an 1130 Authorisation Advice Response returned to SPAN. When a 1130
is not received by SPAN in response to an 1120, then an 1121 message is
sent until an 1130 is received.
This is the end of the flow for magnetic stripe cards. Chip card
processing continues at point 7.
Point 7 When the POS terminal has completed the initial pre-authorisation stage of
the transaction, it sends an 1120 Authorisation Advice to SPAN containing
an Authorisation Only Processing Code and the EMV Transaction
Certificate for the Authorisation Only transaction.
Point 8 (8A) SPAN returns an 1130 Authorisation Advice Response message to
(8B) An 1120 Authorisation Advice message is sent by SPAN to the
Retailer Bank at the same time as the response (8A) is returned to the
SPAN POS Terminal. This message has a Function Code (DE 24)
indicating that this advice is related to a previous pre-authorisation (182).
(8C) As the transaction is on a AMEX Card, an 1120 Authorisation Advice
is sent to the Bank Card Scheme Bank (SAIB) at the same time as the
response (8A) is returned to the SPAN POS terminal. This message has a
Function Code (DE 24) indicating that this advice is related to a previous
pre-authorisation (182).
an 1130 Authorisation Advice Response returned to SPAN. When an 1130
is not received by SPAN in response to an 1120, then an 1121 message is
sent until an 1130 is received.
Point 10 The Bank Card Scheme Bank (SAIB) must acknowledge the 1120
Authorisation Advice with an 1130 Authorisation Advice Response
returned to SPAN. When an 1130 is not received by SPAN in response to
an 1120, then an 1121 message is sent until an 1130 is received.

Transaction Flows
4.8.6 Financial Transaction – AMEX Pre-Authorisation Completion (Magnetic Stripe / Chip)

ISO Message Types: 1220 – Financial Transaction Advice
Diagram:
2B
1220 KSA Retailer
SPAN 3
1230 Bank
2C
2A
12
20
12
30
AMEX
1220
1230
4 Saudi Investment
Bank (SAIB)
POS
Terminal
Purpose: To notify the Retailer Bank and the Bank Card Scheme Bank (SAIB) when
a AMEX pre-authorisation is completed.
Used For: Purchase Advice – Pre-authorised Purchase Completion AMEX magnetic
stripe and chip cards
diagram above.
Point 1 At the completion of a pre-authorisation process the SPAN POS Terminal
generates a Purchase Advice.
• The authorisation code received in the pre-authorisation transaction is
inserted in the Advice
• The Amount can be less or the same as the associated pre-
authorisation.
SPAN receives the 1220 Financial Advice from the SPAN POS Terminal.
SPAN uses the Track 2 data (DE 35) encoded on the Bank Card for a card
swipe, or (DE 2) when manually entered for a magnetic stripe card or data
from the chip (DE 35) to determine whether the card belongs to a card
scheme that supports non-electronic authorisation. In this example, the
card scheme does support non-electronic authorisation.

Transaction Flows
Point 2 (2A) SPAN formats and sends the 1230 Financial Advice Response
message to the SPAN POS Terminal.
then SPAN formats and sends a 1220 Financial Advice to the Retailer
Bank. The 1220 message contains detailed information allowing the
Retailer Bank to assist the Retailer with reconciliation.
(2C) SPAN formats and sends 1220 Financial Advice to the Bank Card
Scheme Bank (SAIB). The 1220 message contains detailed information
allowing the Bank Card Scheme Bank to reconcile with the Retailer Bank.
Also, the 1220 message contains the Card Scheme Information (DE 123)
allowing the Bank to settle the transaction later through the offline
settlement system.
1230 Financial Transaction Advice Response returned to SPAN.
Point 4 The Bank Card Scheme Bank (SAIB) must acknowledge the 1220
Financial Advice with the 1230 Financial Advice Response returned to
SPAN.

Transaction Flows
4.8.7 Financial Transaction – IBCS Normal Magnetic Stripe Transaction Authorisation

(Approved/Declined), where the Retailer Bank is not the Card Scheme Acquirer
0200 – Financial Transaction Request
Diagram: 0100
2
VISA/ MasterCard 3
0110
4B
1220 KSA Retailer
SPAN 5
1230 Bank
4C
2
0200 4A
MasterCard- MDS 3
0210 12
20
12
30
KSA Bank Card
1200 6 Scheme Bank
1210
POS
Terminal
Purpose: To request and receive authorisation for a Bank Card transaction for
magnetic stripe debit and credit cards issued abroad and credit card issued
by banks within the Kingdom.
Used For: Purchase request
Refund – If the Service Code on the card indicates that an on-line PIN is
required for a refund and the Card Scheme supports on-line Refunds.
diagram above.
transaction request from a SPAN POS Terminal.
Point 2 SPAN uses the Track 2 data (field 35) encoded on the Bank Card, for a
card swipe, or field 2 when manually entered, to determine the Bank Card
Scheme authoriser. SPAN formats a transaction request into the
Authorisation Request format.
then routes an 0100 Authorisation Request, or a 0200 Financial Request to
the appropriate Network, for authorisation.
Point 3 The International Bank Card Scheme Switch then performs authorisation
according to its agreement with the Bank Card Issuer. The International
Bank Card Scheme Switch responds to the request with a 0110
Authorisation Request Response or a 0210 Financial Transaction Request
Response.

Transaction Flows
Point 4 (4A) SPAN 1210 Financial Request response message is returned to the
SPAN POS Terminal.
(4B) A 1220 Financial Transaction Advice is sent to the Retailer Bank at
the same time as the response (4A) is returned to the SPAN POS Terminal.
Bank to assist the Retailer with reconciliation.
(4C) A 1220 Financial Transaction Advice is sent to the Bank Card
Scheme Bank at the same time as the response (4A) is returned to the
SPAN POS Terminal. The 1220 message contains detailed information that
will assist the Bank Card Scheme Bank to reconcile with the Retailer
Bank. Also, the 1220 message contains the Card Scheme Information (field
123) allowing the Bank to settle the transaction later through the offline
settlement system.
SPAN.
Point 6 The Bank Card Scheme Bank must acknowledge the 1220 Financial
Transaction Advice with the 1230 Financial Transaction Advice Response
returned to SPAN.

Transaction Flows
4.8.8 Financial Transaction – IBCS Normal Chip Card Transaction Authorisation

(Approved/Declined), where the Retailer Bank is not the Card Scheme Acquirer
Diagram: 0100
2
VISA/ MasterCard 3 4B 1120
0110
1130 5
KSA Retailer
8 1220 Bank
SPAN
1230 9
2 4C
0200
MasterCard- MDS 3 4A 7
0210 8 11
20
11
30
12
20
12 5 KSA Bank Card
30
Scheme Bank
1220
1230
1100
1110
1 6
POS
Terminal
Purpose: To request and receive authorisation for a Bank Card transaction for chip
debit and credit cards issued abroad and chip credit cards issued by banks
within the Kingdom.
Refund – If the Chip CVM indicates that an on-line PIN is required for a
refund and the Card Scheme supports on-line Refunds.
diagram above.
Point 2 SPAN uses the chip data contained on the Bank Card to determine the
Bank Card Scheme authoriser. SPAN formats a transaction request into
the Authorisation Request format.

Transaction Flows
Point 3 The International Bank Card Scheme Switch performs authorisation

Response.
Point 4 (4A) SPAN 1110 Authorisation Request Response message is returned to
(4B) An 1120 Financial Transaction Advice is sent to the Retailer Bank at
Bank to assist the Retailer with reconciliation.
(4C) An 1120 Authorisation Advice is sent to the Bank Card Scheme Bank
at the same time as the response (4A) is returned to the SPAN POS
Terminal. The 1120 message contains detailed information that will assist
the Bank Card Scheme Bank to reconcile with the Retailer Bank.
The 1120 Authorisation Advices are sent whether the Authorisation was
approved or declined.
Point 5 The Bank Card Scheme Bank and Retailer Bank must acknowledge the
1120 Authorisation Advice with the 1130 Authorisation Advice Response
returned to SPAN.
Advice to SPAN.
Point 8 If the Bank Card Scheme Bank and Retailer Bank are not the same then a
1220 Financial Advice message is sent to both at the same time as the 1230
Financial Advice Response (7) is returned to the SPAN POS Terminal.
Bank to post the transaction to the Retailer's Account.
The 1220 message contains detailed information that will assist the Bank
Card Scheme Bank to reconcile with the Retailer Bank.
Point 9 The Bank Card Scheme Bank and the Retailer Bank must acknowledge the
1220 Financial Transaction Advice with the 1230 Financial Transaction
Advice Response returned to SPAN.

Transaction Flows
4.8.9 Financial Transaction – IBCS Normal Magnetic Stripe Transaction

(Approved/Declined), where the Retailer Bank is the Card Scheme Acquirer
Diagram: 0100
2
VISA/ MasterCard 3
0110
KSA Retailer
4B Bank
1220
SPAN 5
1230 KSA Bank Card
2 Scheme Bank
0200 4A
MasterCard- MDS 3
0210
12 00
1 2 10
POS
Terminal
Purpose: To request and receive authorisation for a Bank Card transaction for
magnetic stripe debit and credit cards issued abroad and credit card issued
by banks within the Kingdom.
Refund – If the Service Code on the card indicates that an on-line PIN is
required for a refund and the Card Scheme supports on-line Refunds.
diagram above.
Point 1 SPAN (the Transaction Acquirer) receives a 1200 Financial Request from
a SPAN POS Terminal.
Scheme authoriser. SPAN formats a transaction request into a 0100
Authorisation Request or 0200 Financial Transaction Request, as
applicable.
Response.

Transaction Flows
Point 4 (4A) SPAN 1210 Financial Request Response message is returned to the
SPAN POS Terminal.
(4B) A 1220 Financial Advice is sent to the Retailer Bank/Bank Card
SPAN POS Terminal. The 1220 message contains detailed information
allowing the Retailer Bank/Bank Card Scheme Bank to assist the Retailer
with reconciliation. Also, the 1220 message contains the Card Scheme
Information (field 123) allowing the Bank to settle the transaction later
through the offline settlement system.
Point 5 The Retailer Bank/Bank Card Scheme Bank must acknowledge the 1220
SPAN.

Transaction Flows
4.8.10 Financial Transaction – IBCS Normal Chip Transaction (Approved/Declined), where the
Retailer Bank is the Card Scheme Acquirer
Diagram: 0100
2
VISA/ MasterCard 3
0110
4B
1120 KSA Retailer
5 Bank
SPAN 1130
8 KSA Bank Card
1220
2 9 Scheme Bank
0200 4A 7 1230
MasterCard- MDS 3
0210
11 00
12 20
1 1 10
1 2 30
1 6
POS
Terminal
Purpose: To request and receive authorisation for a Bank Card transaction for chip
debit and credit cards issued abroad and credit card issued by banks within
the Kingdom.
Refund – If the chip CVM indicates that an on-line PIN is required for a
refund and the Card Scheme supports on-line Refunds.
diagram above.
Point 2 SPAN uses the chip data on the Bank Card, to determine the Bank Card
Scheme authoriser. SPAN formats a transaction request into a 0100
Authorisation Request or 0200 Financial Transaction Request, as
applicable.
Response.

Transaction Flows

(4B) An 1120 Authorisation Advice is sent to the Retailer Bank/Bank Card
SPAN POS Terminal.
Authorisation Advice with the 1130 Authorisation Advice Response
returned to SPAN.
Advice to SPAN.
Point 8 A 1220 Financial Advice is sent to the Retailer Bank/Bank Card Scheme
Bank at the same time as the 1230 Financial Advice Response (7) is
returned to the SPAN POS Terminal. The 1220 message contains detailed
information allowing the Retailer Bank/Bank Card Scheme Bank to assist
the Retailer with reconciliation. Also, the 1220 message contains the Card
Scheme Information (field 123) allowing the Bank to settle the transaction
later through the offline settlement system.
SPAN.

Transaction Flows
4.8.11 Timeout Processing – No Response Received from IBCS switch (Magnetic Stripe card)
0420 - Reversal Advice
0430 - Reversal Advice Response
Diagram:
VISA /MasterCard
2
0100
3B
0200 2 1220 KSA Retailer
SPAN 4
5 1230 Bank
0420
MasterCard - MDS 6
0430
3A
1200
1 2 10
POS
Terminal
Purpose: To request and receive authorisation for a Bank Card transaction (magnetic
stripe) when no response is received from the International Bank Card
Scheme and the transaction is declined by SPAN.
On-line Refund
diagram above.
In this example SPAN does not receive a response from the International
Bank Card Scheme Switch. The diagram shows the request being lost
before the IBCS switch receives it. It could equally be where the request is
processed by the IBCS and the response is lost before it arrives at SPAN.

Transaction Flows
Point 3 (3A) SPAN declines the transaction with a Action Code (DE39) of "907"
and sends the 1210 Financial Request Response message to the SPAN POS
Terminal.
the same time as the response (3A) is returned to the SPAN POS Terminal
indicating the decline.
SPAN.
Point 5 Because the transaction timed out on SPAN, SPAN initiates the reversal
processing appropriate to the particular Network (see 4.2.1 for more
information).
In this case an 0420 Reversal Advice is generated to the MDS Network
with the total amount to be reversed. The advice is maintained in SAF (and
sent periodically as a repeat) until a 0430 Reversal Advice Response is
received from the Network.
Point 6 SPAN receives an 0430 Reversal Advice Response from the Network.
SPAN then removes the message from SAF.

Transaction Flows
4.8.12 Timeout Processing – No Response Received from IBCS switch (Chip card)
Diagram: 2
0100
VISA / MasterCard
3B
2 1120
0200 4 KSA Retailer
5 SPAN 1130
0420 Bank
9
6 1220
0430 10
MasterCard - MDS 1230
3A 8
11 0 0
12 2 0
1 1 10
1 2 30
1 7
POS
Terminal
Purpose: To request and receive authorisation for a Bank Card transaction (Chip
card) when no response is received from the International Bank Card
Scheme and the transaction is declined by SPAN.
On-line refund
diagram above.
Point 2 SPAN uses the data on the Bank Card chip, for a card swipe, to determine
the Bank Card Scheme authoriser. SPAN formats a transaction request
into the Authorisation Request format.
However in this example SPAN does not receive a response from the
International Bank Card Scheme Switch. The diagram shows the request
being lost before the IBCS switch receives it. It could equally be where the
request is processed by the IBCS and the response is lost before it arrives
at SPAN.

Transaction Flows
Point 3 (3A) SPAN declines the transaction with a Action Code (DE39) of "907"
and sends the 1110 Authorisation Request Response message to the SPAN
POS Terminal.
(3B) An 1120 Authorisation Advice is sent to the Retailer Bank at the
same time as the response (3A) is returned to the SPAN POS Terminal
indicating the decline.
the 1130 Authorisation Advice Response returned to SPAN.
Point 5 Because the transaction timed out on SPAN, SPAN initiates the reversal
processing appropriate to the particular Network (see 4.2.1 for more
information).
In this case an 0420 Reversal Advice is generated to the MDS Network
with the total amount to be reversed. The advice is maintained in SAF (and
sent periodically as a repeat) until a 0430 Reversal Advice Response is
received from the Network.
Point 6 SPAN receives an 0430 Reversal Advice Response from the Network.
SPAN then removes the message from SAF.
Point 7 If the Chip Card decides to authorise the transaction off-line it will then
format a 1220 Financial Advice and send it to SPAN. This is linked to the
original declined authorisation using the original data elements field (DE
56).
Point 9 SPAN sends a 1220 Financial Advice to the Retailer Bank to advise it of
the chip’s off-line transaction, at the same time as the 1230 Advice
Response (6) is sent to the POS.
SPAN.

Transaction Flows
4.8.13 Communications Failure – Link is down between SPAN and the Retailer Bank/Bank
Card Scheme Bank, (IBCS Magnetic Stripe)
Diagram: 0100
2
VISA/ MasterCard 3
0110
4B KSA Retailer
1220
6 Bank
SPAN 1221
7 KSA Bank Card
1230 Scheme Bank
2
0200 4A 5
- MDS 3
MasterCard
0210
12 00
12 10
SAF
1220
POS
Terminal
Purpose: To request and receive authorisation for a magnetic stripe Bank Card
transaction.
On-line refund
diagram above.
Response.

Transaction Flows
SPAN POS Terminal.
(4B) A 1220 Financial Advice is sent to the Retailer Bank at the same time
as the response (4A) is returned to the SPAN POS Terminal. SPAN is
unable to deliver the 1220 because the link is down to the Retailer Bank.
Point 5 SPAN stores the 1220 Financial Advice on the Store-and-forward File until
the link to the Retailer Bank is available.
Point 6 When the link to the Retailer Bank is restored, the transactions stored in
the SAF file (1220 Financial Advices) are then sent to the Retailer Bank in
turn, advising the Retailer Bank of the transaction completion. Where the
transaction has failed in a previous transmission (4B) it is converted to a
repeat (1221 Financial Advice Repeat). The next transaction is not sent
until a response is received to the previous transmission.
Point 7 The Retailer Bank must acknowledge the 1220/1221 Financial Advice
(Repeat) with the 1230 Financial Advice Response.

Transaction Flows
4.8.14 Communications Failure – Link is down between SPAN and the Retailer Bank/Bank
Card Scheme Bank, (IBCS Chip Card)
Diagram: 0100
2
VISA /MasterCard 3
0110 4B
1120/1121
7B KSA Retailer
1220/1221 Bank
SPAN 9
1121/1221
KSA Bank Card
10
1130/1230 Scheme Bank
2
0200
MasterCard - MDS 3 4A 7A 5/8
0210
1100
1110
1200
1210
SAF
1120 /
1220
1 6
POS
Terminal
Purpose: To request and receive authorisation for a Bank Chip Card transaction.
On-line refund
diagram above.
Point 2 SPAN uses the Track 2 data (field 35) from the Chip on the Bank Card, to
determine the Bank Card Scheme authoriser. SPAN formats a transaction
request into the Authorisation Request format.
then routes a 0100 Authorisation Request, or a 0200 Financial Request to
Response.

Transaction Flows

same time as the response (4A) is returned to the SPAN POS Terminal. If
SPAN is unable to deliver the 1120 because the link is down to the Retailer
Bank, SPAN attempts to send an 1121 Authorisation Advice Repeat. If this
also fails SPAN stores the transaction for delivery when the destination is
available (5).
Point 5 SPAN stores the 1120 Authorisation Advice on the Store-and-forward
(SAF) File until the link to the Retailer Bank is available.
Advice to SPAN.
SPAN POS Terminal.
as the response (7A) is returned to the SPAN POS Terminal. If SPAN is
unable to deliver the 1220 because the link is down to the Retailer Bank,
SPAN attempts to send an 1221 Financial Advice Repeat. If this also fails
SPAN stores the transaction for delivery when the destination is available
(8).
Point 8 SPAN stores the 1220 Financial Advice on the Store-and-forward (SAF)
File until the link to the Retailer Bank is available.
the SAF file (1120 Authorisation Advices and the 1220 Financial Advices)
are then sent to the Retailer Bank in turn, advising the Retailer Bank of the
authorisation and the transaction completion. Where the transaction has
failed in a previous transmission (4B or 7B) it is converted to a repeat
(1121 Authorisation Advice Repeat or 1221 Financial Advice Repeat). The
next transaction is not sent until a response is received to the previous
transmission.
Point 10 The Retailer Bank must acknowledge each transaction with either an 1130
Authorisation Advice Response or 1230 Financial Advice Response as
appropriate (the next SAF transaction is not sent until the previous
response is received).

Transaction Flows
4.8.15 Timeout Processing – No Response Received from the Card Issuer Bank (Magnetic
Stripe)
2
Diagram: 1200
5B 1220
1420 3 SPAN 1230 6
Bank Bank
4 1430
5A
1 2 10
12 0 0
1
POS
Terminal
Purpose: To request and receive authorisation for a financial transaction on a

magnetic stripe card when there is no response from the Card Issuer Bank
and the transaction is declined by SPAN.
Used For: Purchase
Refund
diagram above.
Point 2 SPAN formats the 1200 Financial Request and uses the Track 2 data (field
35) encoded on the card, for a card swipe, or field 2 when manually
then routes an 1200 Financial Request to the Card Issuer Bank for
authorisation.
Point 3 SPAN’s timer expires awaiting the 1210 Financial Request Response from
the Card Issuer Bank. If it is not clear what has happened at the Card Issuer
(i.e. if SPAN is not aware the link is down and sent the 1200 Financial
Request), SPAN formats a 1420 Reversal Advice to the Card issuer.
Note. If the 1420 Reversal Advice also times out SPAN uses store and
forward (1421 Reversal Repeats) to ensure delivery.
Point 4 If the Card Issuer Bank receives a 1420 Reversal Advice it must
acknowledge it with a 1430 Reversal Advice Response returned to SPAN.

Transaction Flows
Point 5 (5A) SPAN declines the transaction with an Action Code (field 39) value
of 911 indicating a card issuer timeout (or 907 indicating card issuer
inoperative if SPAN knows that the 1200 could not be sent) and sends the
1210 Financial Request Response message to the SPAN POS Terminal.
as the response (5A) is returned to the SPAN POS Terminal. The 1220
messages contain detailed information allowing the Retailer Bank to assist
the Retailer if questions arise regarding this transaction.
Note: The 1220 Financial Advice messages must be retrievable by the
Retailer Help Desk.
1230 Financial Advice Response returned to SPAN.
Note: Declined transactions have no financial impact, and therefore are not
sent to the Card Issuer Bank The 1420 Reversal Advice (3) is used to
negate any potential financial impact at the Card Issuer.

Transaction Flows
4.8.16 Timeout Processing – No Response Received from the Card Issuer Bank and SPAN
(Chip Card)
2
Diagram: 1100
5B 1120
1420 3 SPAN 1130 6
Bank Bank
4 1430
5A
1 1 10
11 0 0
POS
Terminal
Purpose: To request and receive authorisation for a financial transaction on a chip

card when no response is received from the Card Issuer Bank. The
transaction is declined by SPAN.
Used For: Purchase
Refund
diagram above.
Point 2 SPAN formats the 1100 Authorisation Request and uses the Track 2 data
(field 35) from the chip on the card to determine the Cardholder's Bank.
then routes an 1100 Authorisation Request, to the Card Issuer Bank, for
authorisation, but SPAN does not receive a response. The diagram shows
the request being lost before the card issuer receives it. It could equally be
where the request is processed by the card issuer and the response is lost
before it arrives at SPAN.
Point 3 SPAN’s timer expires awaiting the 1110 Authorisation Request Response
from the Card Issuer Bank. If it is not clear what has happened at the Card
Issuer (i.e. if SPAN is not aware the link is down when it sent the 1100
Authorisation Request), SPAN formats a 1420 Reversal Advice to the Card
issuer.

Transaction Flows
Point 5 (5A) SPAN declines the 1100 Authorisation Request transaction with a
Action Code (field 39) value of "907” and sends the 1110 Authorisation
Request Response message to the SPAN POS Terminal.
The 1120 messages contain detailed information allowing the Retailer
Bank to assist the Retailer if questions arise regarding this transaction.
Note: The 1120 Authorisation Advice messages must be retrievable by the
Retailer Help Desk.
Note: If the chip subsequently decides to authorise the transaction off-line
it will send a 1220 Financial Advice to SPAN, which SPAN will route on
to the Retailer bank via SAF (see section 4.8.12 for details of this flow).
the 1130 Authorisation Advice Response returned to SPAN.
Note: Declined transactions have no financial impact, and therefore are not
sent to the Card Issuer Bank. The 1420 Reversal Advice (3) is used to
negate any potential financial impact at the Card Issuer.

Transaction Flows
4.8.17 Communications Failure – Link is Down between SPAN and Card Issuer
1804 – Network Management Request
1814 – Network Management Response
Diagram: 1804
5
3
5 1220
KSA Card Issuer 1804 KSA Retailer
5 SPAN 4
Bank 1804 1230 Bank
6 1814
2
1 2 10
12 0 0
1
POS
Terminal
Purpose: To request and receive authorisation for a financial transaction when the
link is down between SPAN and the Card Issuer.
Though a 1200 Financial Request message is used in the diagram, it
equally well applies to 1100 Authorisation Request messages (the process
is independent of whether the card is magnetic stripe or chip).
Used For: Authorisation of transactions when link to a Card Issuer is down.
diagram above.
Point 2 SPAN formats the 1200 Financial Request and uses the Track 2 data (DE
35) encoded on the card, for a card swipe, or DE 2 when manually entered,
to determine the Cardholder's Bank.
Normally SPAN verifies the transaction as described in Section 2 and
Section 3 and then routes a 1200 Financial Request to the Card Issuer Bank
If the Card Issuer is marked as unavailable SPAN does not send a
transaction to the Card Issuer but responds immediately to the POS with a
declined 1210 Financial Response indicating the Card Issuer is unavailable
(DE 39 Action Code 907).
Point 3 As normal, a 1220 Financial Advice with the result of the authorisation is
sent to the Retailer Bank at the same time as the response (2) is returned to
Note: The 1220 Financial Advice messages must be retrievable by the
Retailer Help Desk.

Transaction Flows
Point 5 SPAN will start to send ‘echotest’ transactions to determine when the link
becomes available again.
An 1804 Network Management (DE 24 Function Code 831) message is
sent to the KSA Card Issuer to determine availability. This is sent
periodically until a response is received.
In this example 1804 Network Management message is sent three times
before a valid response is received.
Point 6 When a successful 1814 Network Management Request Response is
received to the echotest, SPAN will then recognise the link as being
available again and start to route financial transactions to the link.

Transaction Flows
4.8.18 Communications Failure – Link is down between the Retailer Bank and SPAN
(Magnetic Stripe)
1221 - Financial Advice Repeat
4B
Diagram: 2 1220
KSA Card 0200 6 KSA Retailer
- 3 SPAN 1221
Issuer Bank 0210 7 Bank
1230
4A 5
12 00
12 10
SAF
1220
POS
Terminal
Purpose: To store Retailer advice transactions when the link to the Retailer Bank
goes down in the middle of a transmission for a magnetic stripe card.
Used For: Purchase
Refund
diagram above.
Point 1 SPAN (the Terminal Acquirer) receives a 1200 Financial Request from a
SPAN POS Terminal.
then routes a 1200 Financial Request, to the Card Issuer Bank, for
authorisation,

Transaction Flows
it issued the card.
Security).
for processing.
• Action Code (DE39) is set to 000 indicating a successful transaction.
met.
SPAN POS Terminal.
The 1220 messages contains detailed information allowing the Retailer
Bank to post the transaction to the Retailer's Account, but SPAN is unable
to deliver the 1220 because the link is down to the Retailer Bank.
Point 5 SPAN stores the 1220 Financial Transaction Advice on the Store-and-
Forward File until the link to the Retailer Bank is available.

Transaction Flows
the SAF file (1220 Financial Advices) are then sent to the Retailer Bank in
turn, advising the Retailer Bank of the transaction completion. Where the
transaction has failed in a previous transmission (4B) it is converted to a
repeat (1221 Financial Advice Repeat). The next transaction is not sent
until a response is received to the previous transmission.
Note: The 1220 Financial Transaction Advice (or Retailer Advice)
messages must be retrievable by the Retailer Help Desk.
Point 7 The Retailer Bank must acknowledge the 1220/1221 Financial Transaction
Advice (Repeat) with the 1230 Financial Advice Response.

Transaction Flows
4.8.19 Timeout Processing – Link is down between the Retailer Bank and SPAN (Chip Card)
ISO Message Types: 1100 - Authorisation Request
1110 – Authorisation Response
1221 - Financial Advice Repeat
4B
Diagram: 2 1120/1121
1100 7B
3 1220/1221
KSA Card 1110 SPAN 10 KSA Retailer
- 1121/1221 Bank
Issuer Bank 1220 7C
11
9 1130/1230
1230
4A 7A 5 /8
1100
1220
1110
1230
SAF
1120 /
1220
1 6
POS
Terminal
Purpose: To store Retailer advice transactions when the link to the Retailer Bank
goes down in the middle of a transmission for a chip card.
Used For: Purchase
Refund
diagram above.
Point 1 SPAN (the Terminal Acquirer) receives an 1100 Authorisation Request
Point 2 SPAN formats the 1100 Authorisation Request and uses the Track 2 data
(field 35) from the chip card, to determine the Cardholder's Bank.
then routes a 1100 Authorisation Request, to the Card Issuer Bank, for
authorisation.
Point 3 The Card Issuer Bank receives the 1100 Authorisation Request and
validates it as appropriate.
The Card Issuer Bank responds with an 1110 Authorisation Request
Response.

Transaction Flows

The 1120 message contains detailed information about the authorisation. If
SPAN is unable to deliver the 1120 because the link is down to the Retailer
Bank, SPAN attempts to send an 1121 Authorisation Advice Repeat. If this
also fails SPAN stores the transaction for delivery when the destination is
available (5).
Point 5 SPAN stores the 1120 Authorisation Advice on the Store-and-Forward File
until the link to the Retailer Bank is available.
Advice to SPAN.
SPAN POS Terminal.
as the response (7A) is returned to the SPAN POS Terminal. If SPAN is
unable to deliver the 1220 because the link is down to the Retailer Bank,
SPAN attempts to send an 1221 Financial Advice Repeat. If this also fails
SPAN stores the transaction for delivery when the destination is available
(8).
(7C) A 1220 Financial Advice is sent to the Card Issuer Bank
Point 8 SPAN stores the 1220 Financial Advice on the Store-and-forward (SAF)
File until the link to the Retailer Bank is available.
Point 9 The Card Issuer acknowledges receipt of the 1220 Financial Advice with a
1230 Financial Advice Response.
the SAF file (1120 Authorisation Advices and the 1220 Financial Advices)
are then sent to the Retailer Bank in turn, advising the Retailer Bank of the
authorisation and the transaction completion. Where the transaction has
failed in a previous transmission (4B or 7B) it is converted to a repeat
(1121 Authorisation Advice Repeat or 1221 Financial Advice Repeat). The
next transaction is not sent until a response is received to the previous
transmission.
Point 11 The Retailer Bank must acknowledge each transaction with either an 1130
Authorisation Advice Response or 1230 Financial Advice Response as
appropriate (the next SAF transaction is not sent until the previous
response is received).

Transaction Flows
4.8.20 IBCS Financial Authorisation – Normal Transaction (Magnetic Stripe)

Diagram: 2 4B
1120
0100 KSA Retailer
VISA /MasterCard 3 SPAN 5
1130 Bank
0110
4C
4A
11
20
11
30
1100
1110
KSA Bank Card
6 Scheme Bank
POS
Terminal
Purpose: To request and receive pre-authorisation for a financial transaction.

Used For: Pre-Authorisation for magnetic stripe credit cards only
diagram above.
Point 2 SPAN uses the Track 2 data (DE35) encoded on the Bank card, for a card
swipe, or DE2 when manually entered for a magnetic stripe card, to
then routes an 0100 Authorisation Request Network, for authorisation
Point 3 The International Card Scheme then performs authorisation as appropriate
for a pre-authorisation. The International Bank Card Scheme responds to
the request with an 0110 Authorisation Request Response.
Point 4 (4A) SPAN returns a 1110 Authorisation Request Response message to the
SPAN POS Terminal.
(4B) 1120 Authorisation Advice message is sent to the Retailer Bank at the
(4C) As the transaction is on a International Bank Credit Card, an 1120
Authorisation Advice is sent to the Bank Card Scheme Bank at the same
time as the response (4A) is returned to the SPAN POS terminal.
an 1130 Authorisation Advice Response returned to SPAN, which is used
to acknowledge the delivery of the 1120. When a 1130 is not received by
SPAN in response to an 1120, then the 1121 message is sent until the 1130
is received.

Transaction Flows
Point 6 The Bank Card Scheme Bank must acknowledge the 1120 Authorisation
Advice with an 1130 Authorisation Advice Response returned to SPAN,
which is used to acknowledge the delivery of the 1120. When an 1130 is
not received by SPAN in response to a 1120, then the 1121 message is sent
until the 1130 is received.

Transaction Flows
4.8.21 IBCS Financial Authorisation – Normal Transaction (Chip Card)

4B
Diagram: 1120
5
1130
8B
2 1120
9 KSA Retailer
0100 SPAN 1130
VISA /MasterCard 3 Bank
0110 4C
4A 8A 11
8C 20
11
30
11 6
20
1100
1110
1130
11 KSA Bank Card
1120 30
Scheme Bank
10
1 7
POS
Terminal
Purpose: To request and receive pre-authorisation for a financial transaction.

Used For: Pre-Authorisation for chip credit cards only
diagram above.
Point 2 SPAN uses the chip data (DE 35) to determine the Cardholder's Bank.
then routes an 0100 Authorisation Request to the appropriate Network, for
authorisation
Point 3 The International Card Scheme then performs authorisation as appropriate
for a pre-authorisation. The International Bank Card Scheme responds to
the request with an 0110 Authorisation Request Response.
Point 4 (4A) SPAN returns an 1110 Authorisation Request Response message to
This message has a Function Code (DE 24) indicating that this advice is
related to a pre-authorisation (181).
time as the response (4A) is returned to the SPAN POS terminal. This
message has a Function Code (DE 24) indicating that this advice is related
to a pre-authorisation (181).

Transaction Flows
is received.
not received by SPAN in response to an 1120, then the 1121 message is
Point 7 When the POS terminal has completed the initial pre-authorisation stage of
the transaction, it sends an 1120 Authorisation Advice to SPAN containing
an Authorisation Only Processing Code and the EMV Transaction
Certificate for the Authorisation Only transaction.
Point 8 (8A) SPAN returns an 1120 Authorisation Advice Response message to
This message has a Function Code (DE 24) indicating that this advice is
related to a previous pre-authorisation (182).
time as the response (8A) is returned to the SPAN POS terminal. This
message has a Function Code (DE 24) indicating that this advice is related
to a previous pre-authorisation (182).
is received.
not received by SPAN in response to an 1120, then the 1121 message is

Transaction Flows
4.8.22 IBCS Advice Messages - Pre-Authorisation Completion

Diagram:
2B
1220 KSA Retailer
SPAN 3
1230 Bank
2C
2A
12
20
12
30
1220
1230
KSA Bank Card

4
Scheme Bank
POS
Terminal
Purpose: To notify the Retailer Bank and the Bank Card Scheme Bank when a pre-
authorisation is completed.
Used For: Purchase Advice – Pre-authorised Purchase Completion for credit cards
only.
diagram above.
Point 1 At the completion of a pre-authorisation process the SPAN POS Terminal
generates a Purchase Advice.
• The authorisation code received in the pre-authorisation transaction is
inserted in the Advice
• The Amount can be less or the same as the associated pre-
authorisation.
SPAN uses the Track 2 data (field 35) encoded on the Bank Card, for a
card swipe, or field 2 when manually entered for a magnetic stripe card or
data from the chip (DE 35) to determine whether the card belongs to a card

Transaction Flows
(2B) SPAN formats and sends a 1220 Financial Advice to the Retailer
Scheme Bank. The 1220 message contains detailed information allowing
the Bank Card Scheme Bank to reconcile with the Retailer Bank. Also, the
1220 message contains the Card Scheme Information (DE 123) allowing
the Bank to settle the transaction later through the offline settlement
system.
Advice with the 1230 Financial Advice Response returned to SPAN.

Transaction Flows
4.8.23 IBCS Advice Messages – Retailer receives voice authorisation for the purchase from
the transaction authoriser, where the Retailer Bank is not the Card Scheme Acquirer
International Bank Card Scheme Voice Authorisation
Diagram:
2B
1220 KSA Retailer
SPAN 3
1230 Bank
2C
2A
12
20
12
30
1220
1230
KSA Bank Card

4
Scheme Bank
POS
Terminal
Purpose: To notify the Retailer Bank and the Bank Card Scheme Bank when the
Retailer has received a voice authorisation for a purchase.
Used For: Voice Authorisation Advice
diagram above.
Point 1 Retailer obtains an authorisation for a purchase from a voice authorisation
centre. Retailer enters an advice transaction into the SPAN POS Terminal.
• The authorisation code received from the voice authorisation centre is
entered into the SPAN POS Terminal.
card swipe, or field 2 when manually entered for a magnetic stripe card or
data from the chip (DE 35) to determine whether the card belongs to a card

Transaction Flows
(2B) SPAN formats and sends 1220 Financial Advice to the Retailer
1220 message contains the Card Scheme Information (field 123) allowing
system.

Transaction Flows
4.8.24 IBCS Advice Messages – Retailer receives voice authorisation for the purchase from
the transaction authoriser, where the Retailer Bank is the Card Scheme Acquirer
ISO Message Types: 1220 – Financial Advice
Diagram: KSA Retailer
2B Bank
1220
SPAN 3
1230 KSA Bank Card
Scheme Bank
2A
1220
1230
POS
Terminal
Purpose: To notify the Retailer Bank/Bank Card Scheme Bank when the Retailer
has received a voice authorisation for a purchase.
Used For: Voice Authorisation Advice
diagram above.
Point 1 Retailer obtains an authorisation for a purchase from a voice authorisation
centre.
Retailer enters an advice transaction into the SPAN POS terminal.
The authorisation code received from the voice authorisation centre is
entered into the SPAN POS terminal.
SPAN receives 1220 Financial Advice from a SPAN POS terminal.
card swipe, or field 2 when manually entered, for a magnetic stripe card or
data from the chip (field 35),to determine whether the card belongs to a
card scheme that supports non-electronic authorisation. In this script, the
Bank/Bank Card Scheme Bank.
Point 3 The Retailer Bank/Bank Card Scheme Bank acknowledges the 1220
SPAN.

Transaction Flows
4.8.25 IBCS Refund – Retailer performs a refund transaction, where the Retailer Bank is not
the Card Scheme Acquirer
Diagram:
2B
1220 KSA Retailer
SPAN 3
1230 Bank
2C
2A
12
20
12
30
12 2 0
12 3 0
KSA Bank Card

4
Scheme Bank
POS
Terminal
Retailer has returned funds to a Cardholder in consideration of goods
returned to the Retailer by the Cardholder.
Used For: Off-line Refund – If the Service Code on a magnetic stripe card or the chip
CVM list does not indicate that an on-line PIN is required or card scheme
does not support on-line refunds (for example Visa Base I and MasterCard
CIS do not expect online authorisation requests for refunds).
diagram above.
Point 1 SPAN receives refund request from a SPAN POS Terminal.
Point 2 (2A) SPAN formats and sends the response message to the SPAN POS
Terminal.
system.

Transaction Flows

Transaction Flows
4.8.26 IBCS Refund – Retailer performs a refund transaction, where the Retailer Bank is the
Card Scheme Acquirer.
2B Bank
1220
SPAN 3
1230 KSA Bank Card
Scheme Bank
12 3 0 2A
12 20
POS
Terminal
Purpose: To notify the Retailer Bank/Bank Card Scheme Bank when the Retailer
has returned funds to a Cardholder in consideration of goods returned to
the Retailer by the Cardholder.
Used For: Off-line Refund - If the Service Code on a magnetic stripe card or the
chip CVM list does not indicate that an on-line PIN is required or card
scheme does not support on-line refunds (for example Visa Base I and
MasterCard CIS do not expect online authorisation requests for refunds).
diagram above.
Point 1 Retailer enters a refund transaction into the SPAN POS terminal.
SPAN receives a 1220 Financial Advice from a SPAN POS terminal.
Point 2 (2A) SPAN formats and sends a 1230 Financial Advice Response
Point 3 The Retailer Bank/Bank Card Scheme Bank acknowledges the 1220
SPAN.

Transaction Flows
4.8.27 Chip Card Off-line Purchase Transaction

Diagram: 1220
2C 2B
1220
4 SPAN 3
Bank 1230 1230 Bank
2A
12 3 0
12 2 0
1
POS
Terminal
Purpose: To notify the Retailer Bank and the Card Issuer Bank when the chip card
has authorised a transaction without on-line authorisation.
Used For: Offline Chip Card Advice (Approved or Declined)
diagram above.
Point 1 SPAN receives 1220 Financial Advice from a SPAN POS Terminal.
A declined off-line chip card transaction is recognised by DE 39 Action
Code in the 1220 Financial Advice being set to 188 (offline declined). This
Action Code must be returned in the 1230 Financial Advice Response.
(2C) SPAN formats and sends 1220 Financial Advice to the Card
Issuer Bank. The 1220 message contains detailed information allowing the
Card Issuer bank to bill the customer.
Where the Retailer Bank is also the Card Issuer Bank (2B) is omitted.
If there is a failure to deliver (2B or 2C) these advices will be retained in a
Store-and-Forward (SAF) file for delivery, when the connection is
restored, as 1221 Financial Advice Repeats.
Point 4 The Card Issuer Bank must acknowledge the 1220 Financial Advice with
the 1230 Financial Advice Response returned to SPAN.

Transaction Flows
4.8.28 IBCS Chip Card Off-line Purchase Transaction

Diagram:
2B
1220 KSA Retailer
SPAN 3
1230 Bank
2C
2A
12
20
12
30
12 2 0
12 3 0
KSA Bank Card

4
Scheme Bank
POS
Terminal
chip card has authorised a transaction without on-line authorisation.
Used For: Offline Chip Card Advice (Approved or Declined)
diagram above.
Point 1 SPAN receives 1220 Financial Advice from a SPAN POS Terminal.
A declined off-line chip card transaction is recognised by DE 39 Action
Code in the 1220 Financial Advice being set to 188 (offline declined). This
Action Code must be returned in the 1230 Financial Advice Response.
system.
Where the Retailer Bank is also the Card Scheme Acquirer (2B) is
omitted.
If there is a failure to deliver (2B or 2C) these advices will be retained in a
Store-and-Forward (SAF) file for delivery, when the connection is
restored, as 1221 Financial Advice Repeats.

Transaction Flows
4.8.29 Reversal – Reversal because of SPAN POS Terminal communication problem

(Magnetic Stripe)
1421 – Reversal Advice Repeat
Diagram: 2 4B
1200 1220
3 5
8 SPAN 10
Bank 1420 1420 Bank
9 11
1430 1430
4A 7
1210
1420
1430
1200
1 6
POS
Terminal
Purpose: The purpose of SPAN reversal processing is to provide a mechanism to

handle a communications failure within the network.
Used For: Processing SPAN POS Terminal problems
Note: By SPAN standards, financial settlement of electronic transactions
with International Banks Card Schemes should only happen after the POS
terminal reconciliation transaction has been received by the Bank Card
Scheme Acquirer. When an approved POS transaction has been reversed,
it should be removed from the International Bank Card Scheme financial
settlement batch.
diagram above.

Transaction Flows
authorisation.
it issued the card.
Security).
for processing.
met.
Point 4 (4A) SPAN attempts to return the 1210 Financial Request Response
message to the SPAN POS Terminal, but the link is down or the line has
been disconnected to the SPAN POS Terminal.
(4B) A 1220 Financial Transaction Advice is sent to the Retailer Bank
(Card Scheme Acquirer) at the same time as the response (4A) is returned
to the SPAN POS Terminal. The 1220 messages contains detailed
information allowing the Retailer Bank to post the transaction to the
Retailer's Account.
Note: The 1220 Financial Transaction Advice or Retailer Advice messages
must be retrievable by the Retailer Help Desk.

Transaction Flows
Point 5 The Retailer Bank acknowledges the 1220 Financial Advice with the 1230
Financial Advice Response.
Point 6 The POS terminal generates a conditional reversal (1420 Reversal Advice)
and sends it when the link is re-established.
Point 7 SPAN acknowledges the reversal from the POS terminal with a 1430
Reversal Advice Response.
Point 8 SPAN sends a 1420 Reversal Advice to the Card Issuer Bank.
Included in the 1420 Reversal Advice from SPAN to the Card Issuer are:
• Full amount to be reversed (DE 4)
• Reason for reversal (DE 25 – Message Reason Code)
• Logical link to transaction being reversed (DE 56 – Original Data
Elements)
• Transmission Date and Time (DE 7) is set to the current date and time
at SPAN when the message is transmitted.
• Local Date and Time (DE 12) is set to the time received in the
equivalent field from the POS.
SPAN also logs and adjusts Card Issuer reconciliation totals.
Note: The 1420 Reversal Advice sent to the Card Issuer Bank is placed in
the Store-And-Forward file in SPAN to maintain the reversal transaction
until a successful acknowledgement is received indicating the Card Issuer
Bank is aware of the reversal.
If no 1430 Reversal Advice Response is received by SPAN, the message is
changed to a 1421 Reversal Advice Repeat and placed on the Store-And-
Forward (SAF) file. The Card Issuer Bank may receive a 1421 Reversal
Advice Repeat any time SPAN has previously tried to send that message as
a 1420 Reversal Advice.
Point 9 SPAN receives the 1430 Acquirer Reversal Advice Response message
from the Card Issuer Bank. SPAN then removes the message from the
Store-And-Forward file (SAF).

Transaction Flows
Point 10 SPAN sends a 1420 Reversal Advice to the Retailer Bank.

Included in the 1420 Reversal Advice from SPAN to the Retailer Bank are:
Elements)
• Capture Date (DE 17) is set to the date the 1420 Reversal Advice is
posted by SPAN, as this could be different from the original
transaction if cutover has occurred in the meantime.
Note: The 1420 Reversal Advice is placed in the Store-And-Forward file
in SPAN to maintain the reversal transaction until a successful
acknowledgement is received indicating the Retailer Bank is aware of the
reversal.
changed to a 1421 Reversal Advice Repeat and placed on the SAF File.
The Retailer Bank may receive a 1421 Reversal Advice Repeat any time
SPAN has previously tried to send that message as a 1420 Reversal
Advice.
Point 11 SPAN receives the 1430 Acquirer Reversal Advice Response message
from the Retailer Bank. After a successful log of the reversal information
SPAN adjusts the reconciliation totals of the Retailer Bank to reflect the
reversed amount. SPAN then removes the message from the Store-And-
Forward File (SAF).
Note: Balance Enquiries are not reversed.

Transaction Flows
4.8.30 Reversal – SPAN POS Terminal Communication Problem (Chip Card)

Diagram: 1100
2 4B
1120
3 5
8 SPAN 10
Bank 1420 1420 Bank
9 11
1430 1430
4A 7
1110
1420
1430
1100
1 6
POS
Terminal

The same mechanism is used to provide the Retailer with a means to
cancel a transaction.
Used For: Processing SPAN POS Terminal reversals generated by Retailer action or
terminal action (timeout).
diagram above.
Point 2 SPAN formats the 1100 Authorisation Request and uses the data from the
chip (field 35) to determine the Cardholder's Bank.
then routes a 1100 Authorisation Request, to the Card Issuer Bank, for
authorisation.
that it has issued the card.
The Card Issuer Bank authorises the transaction as appropriate.
Response indicating authorisation approval or decline.

Transaction Flows
Point 4 (4A) SPAN sends the 1110 Authorisation Request Response to the
SPAN POS Terminal. The response is lost.
The 1120 messages contains detailed information on the authorisation.
Note: The 1120 Authorisation Advice must be retrievable by the Retailer
Help Desk.
Point 5 The Retailer Bank acknowledges the 1120 Authorisation Advice with the
1130 Authorisation Advice Response.
Point 6 The transaction is reversed automatically because of no response received.
The 1420 Reversal Advice is sent to SPAN.
Point 7 SPAN acknowledges the reversal from the SPAN POS terminal with a
1430 Reversal Advice Response.
Elements)
Card Issuer Bank. SPAN then removes the message from the SAF File.

Transaction Flows

Elements)
reversal.
Advice.
Point 11 SPAN receives the 1430 Reversal Advice Response from the Retailer
Bank. After a successful log of the reversal information SPAN adjusts the
reconciliation totals of the Retailer Bank to reflect the reversed amount.
SPAN then removes the message from the Store-And-Forward file (SAF).

Transaction Flows
4.8.31 Reversal – SPAN POS Terminal/Retailer reverses the transaction (Magnetic Stripe)
Diagram: 1200
2 4B
1220
3 5
1210 1230
KSA Card Issuer 8 SPAN 10 KSA Retailer
Bank 1420 1420 Bank
9 11
1430 1430
1200 4A 7
1210
1420
1430
1 6
POS
Terminal
Purpose: The purpose of SPAN reversal processing is to provide the Retailer a

means to cancel a transaction.
terminal action.
diagram above.
Point 1 SPAN (the Transaction Acquirer) receives a transaction request from a
SPAN POS Terminal.
Point 2 SPAN formats the 1200 Financial Transaction Request and uses the Track
2 data (field 35) encoded on the card, for a card swipe, or field 2 when
manually entered, to determine the Cardholder's Bank.
authorisation.

Transaction Flows
it issued the card.
Security).
for processing.
met.
Point 4 (4A) SPAN sends the response to the SPAN POS Terminal.
Terminal. The 1220 messages contains detailed information allowing the
Retailer Bank to post the transaction to the Retailer's Account.
Note: The 1220 Financial Transaction Advice or Retailer Advice messages
must be retrievable by the Retailer Help Desk.
Point 5 The Retailer Bank acknowledges the 1220 Financial Transaction Advice
with the 1230 Financial Transaction Advice Response.

Transaction Flows
Point 6 The Retailer receives the response at the SPAN POS terminal. The
Retailer has a short period (defined by SPAN) to reverse ("CANCEL") the
transaction. This can occur because the Retailer and the Cardholder decide
to not complete the transaction.
The transaction can also be reversed automatically because of invalid data
or bad message authentication.
The Reversal Message is sent to SPAN.
Point 7 SPAN acknowledges the reversal from the SPAN POS terminal.
Point 8
SPAN sends a 1420 Reversal Advice to the Card Issuer Bank.
Elements)
Card Issuer Bank. SPAN then removes the message from the Store-and-
Forward File (SAF).

Transaction Flows
Point 10
SPAN sends a 1420 Reversal Advice to the Retailer Bank.
Elements)
reversal.
Advice.
Retailer Bank. After a successful log of the reversal information SPAN
adjusts the reconciliation totals of the Retailer Bank to reflect the reversed
amount. SPAN then removes the message from the Store-And-Forward
file (SAF).

Transaction Flows
4.8.32 Reversal – SPAN POS Terminal or Retailer Reverses the Transaction (Chip Card)
Diagram: 1100
2 4B
1120
3 5
8 SPAN 10
Bank 1420 1420 Bank
9 11
1430 1430
4A 7
1100
1110
1420
1430
1 6
POS
Terminal
Purpose: The purpose of SPAN reversal processing is to provide the Retailer with a
terminal action.
diagram above.
Point 2 SPAN formats the 1100 Authorisation Request and uses the data from the
chip (DE 35) to determine the Cardholder's Bank.
then routes an 1100 Authorisation Request, to the Card Issuer Bank, for
authorisation.
that it has issued the card.
The Card Issuer Bank authorises the transaction as appropriate.
Response indicating authorisation approval or decline.

Transaction Flows
Point 4 (4A) SPAN sends the 1110 Authorisation Request Response to the
SPAN POS Terminal.
The 1120 message contains detailed information on the authorisation.
Note: The 1120 Authorisation Advice must be retrievable by the Retailer
Help Desk.
Point 5 The Retailer Bank acknowledges the 1120 Authorisation Advice with the
1130 Authorisation Advice Response.
Point 6 The Retailer receives the 1110 Authorisation Request Response at the
SPAN POS terminal. The Retailer then has a short period to cancel the
transaction.
The transaction can be reversed automatically because of invalid data or
bad message authentication.
In either of these cases a 1420 Reversal Advice is sent to SPAN.
Point 7 SPAN acknowledges the reversal from the SPAN POS terminal with a
1430 Reversal Advice Response.
Elements)
Card Issuer Bank. SPAN then removes the message from the SAF File.

Transaction Flows

Elements)
reversal.
Advice.
Point 11 SPAN receives the 1430 Reversal Advice Response from the Retailer
Bank. After a successful log of the reversal information SPAN adjusts the
reconciliation totals of the Retailer Bank to reflect the reversed amount.
SPAN then removes the message from the Store-And-Forward file (SAF).

Transaction Flows
4.8.33 Timeout Processing – SPAN timer expires waiting for an Authorisation Request
Response
ISO Message Types: 0100 - Authorisation Request
Diagram: 0100
2
MasterCard 0110 Timeout

5
0110
2
0100
KSA Retailer
0110 Timeout 3B
5 1220 Bank
VISA 0110 SPAN 4
0400
7 Scheme Bank
0410 3A
2
1100/1200
1110/1210
0200
0210 Timeout
5
MasterCard-MDS 0210
6
0420
7
0430
1
POS
Terminal

handle a communications failure within the network or a Switch processing
error.
Used For: Processing SPAN timeouts
settlement batch.
diagram above.
SPAN POS Terminal.

Transaction Flows
then routes an 0100 Authorisation Request or an 0200 Financial Request,
to the Card Issuer Bank or network , as applicable, for authorisation.
Point 3 (3A) A SPAN Request timer expires waiting for the 0110/0210
Request Response. The transaction is then declined by SPAN with an
Action Code (DE-39) of "911" . The SPAN response message is returned
to the SPAN POS Terminal.
Terminal. The 1220 message contains detailed information allowing the
Retailer Bank to assist the Retailer if questions arise regarding this
transaction. Note.. if the transaction had been on a chip card this would be
a 1120 Authorisation Advice.
Advice (or an 1130 Authorisation Advice Response) with the 1230
Financial Transaction Advice Response.
Point 5 SPAN receives the late approved 0110 Authorisation Request Response or
a 0210 Financial Transaction Request Response, as applicable, from the
Switch.
Point 6 Because the transaction was timed out by SPAN, SPAN informs the
Switch of the reversed authorisation amount (where appropriate). The
0400 Reversal Request or 0420 Reversal Advice message is then formatted
by SPAN with the total amount to be reversed. The request message is
sent to the appropriate Switch and placed in the Store-And-Forward file in
SPAN to maintain the reversal transaction until a Reversal Request
Response is received indicating the Switch is aware of the reversal.
See section 4.2.1 for a summary of timeout reversal conditions to IBCS
switches.
Point 7 SPAN receives the 0410 Reversal Request Response or 0430 Reversal
Advice Response message from the Switch. SPAN then removes the
message from the Store-And-Forward file.
Exception Processing: In this example, if the authorisation response in the late 0110 was a
decline, then SPAN would not send reversals to the Switch (for those
interfaces where reversal on approved late response rather than timeout is
applicable)..

Transaction Flows
4.8.34 Reversal – Reversal because of SPAN POS terminal/communication problem

Diagram: 0100
2
MasterCard 3
0110
2 4B
0100 1220 KSA Retailer
3 5 Bank
0110 1230
VISA 8 SPAN 10
9 11 Scheme Bank
0410 1430
4A 7
1110/1210
2
0200
1100/1200
3
0210
1420
1430
MasterCard-MDS 8
0420
9
0430
1 6
POS
Terminal

Used For: Processing SPAN POS Terminal problems
settlement batch.
diagram above.

Transaction Flows

SPAN POS Terminal.
Authorisation Request format. SPAN verifies that the contents of all
message fields are valid, that the requested transaction is allowed, that the
Switch is supported by SPAN and is currently available. SPAN then
routes the 0100 Authorisation Request or the 0200 Financial Transaction
Request, as applicable, to the Switch.
Point 3 The Switch then performs authorisation according to its agreement with the
Bank Card Issuer. The Switch responds to the request with a 0110
Response, as applicable.
Point 4 (4A) SPAN attempts to return the message to the SPAN POS Terminal,
but the link is down or the line has been disconnected to the SPAN POS
Terminal.
(4B) A 1220 Financial Transaction Advice is sent to the Retailer
Bank/Bank Card Scheme Bank at the same time as the response (4A) is
returned to the SPAN POS Terminal. The 1220 message contains detailed
information allowing the Retailer Bank/Bank Card Scheme Bank to
process the transaction for the Retailer's Account. Note.. if the transaction
was on a chip card this would be a 1120 Authorisation Advice.
Note: If the Retailer Bank and Bank Card Scheme Bank are different
SPAN sends separate advice messages to the Retailer Bank and Bank Card
Scheme Bank.
Financial Transaction Advice with the 1230 Financial Transaction Advice
Response returned to SPAN (or an 1120 Authorisation Advice with a 1130
Authorisation Advice Response).
Point 6 The POS terminal generates a conditional reversal (1420 Reversal Advice)
and sends it when the link is re-established.
Point 7 SPAN acknowledges the reversal from the POS terminal.
Point 8 SPAN informs the Switch of the reversed authorisation amount. The 0400
Reversal Request or 0420 Reversal Advice message, as applicable, is then
formatted by SPAN with the total amount to be reversed. The request
message is sent to the Switch and placed in the Interchange Store-and-
Forward File in SPAN to maintain the reversal transaction until a Reversal
Request Response is received indicating the Switch is aware of the
reversal.
Advice Response message, as applicable, from the Switch. SPAN then
removes the message from the Store-And-Forward file.
Point 10 SPAN informs the Retailer Bank/Bank Card Scheme Bank of the reversed
authorisation amount. The 1420 Reversal Advice message is then
formatted by SPAN with the total reversal amount. The 1420 message is
sent to the Retailer Bank/Bank Card Scheme Bank and placed in the Store-
and-Forward File in SPAN to maintain the reversal transaction until a
successful acknowledgement is received indicating the Retailer Bank/Bank
Card Scheme Bank is aware of the reversal.

Transaction Flows
Retailer Bank/Bank Card Scheme Bank and then removes the message
from the Store-and-Forward File (SAF).
Exception Processing: In this example, if the authorisation response in the 0110/0210 was a
decline, the SPAN would not send reversals to the Switch or the Retailer

Transaction Flows
4.8.35 Reversal - SPAN POS terminal reverses the IBCS transaction

Diagram: 0100
2
MasterCard 3
0110
2 4B
0100 1220
3 5
0110 1230 KSA Retailer
VISA 9 SPAN 11
0400 1420 Bank
10 12
0410 1430
4A 8
13
2 14
0200 30
1100/1200
1110/1210
3 4C 14
0210 20
1420
1430
MasterCard-MDS 9 12 14
0420 30
10 12
0430 20 Bank Card
6
Scheme Bank
1 7
POS
Terminal
Purpose: The purpose of SPAN reversal processing is to provide the Retailer a

terminal action (magnetic stripe and chip cards).
settlement batch.
diagram above.

Transaction Flows

SPAN POS Terminal.
then routes an 0100 Authorisation Request or an 0200 Financial Request,
to the Card Issuer Bank or network , as applicable, for authorisation.
Point 3 The Switch then performs authorisation according to its agreement with the
Bank Card Issuer. The Switch responds to the request with a 0110
Response, as applicable. In this instance, the response is an approval.
Point 4 (4A) SPAN sends the response to the SPAN POS Terminal.
Terminal. The 1220 message contains detailed information allowing the
Retailer Bank to process the transaction for the Retailer's Account.
(4C) A 1220 Financial Transaction Advice is sent to the Bank Card
SPAN POS Terminal. The 1210 includes the Card Scheme Information
(field 123) allowing the Bank to settle the transaction later through the
offline settlement system.
Note.. for chip cards 1120 Authorisation Advice and 1130 Authorisation
Advice Response are used.
Advice with the 1230 Financial Transaction Advice Response.
Transaction Advice with the 1230 Financial Transaction Advice Response
returned to SPAN.
Point 7 The Retailer receives the response at the SPAN POS Terminal. The
Retailer has a short period (defined by SPAN) to reverse ("CANCEL") the
transaction. This can occur because the Retailer and the Cardholder decide
to not complete the transaction.
The transaction can also be reversed automatically because of invalid data
or bad message authentication.
The Reversal Message is sent to SPAN.
Point 8 SPAN acknowledges the reversal from the SPAN POS Terminal.
Point 9 SPAN informs the Switch of the reversed authorisation amount. The 0400
Reversal Request or 0420 Reversal Advice message, as applicable, is then
formatted by SPAN with the total amount to be reversed. The message is
sent to the appropriate Switch and placed in the Interchange Store-and-
Forward File in SPAN to maintain the reversal transaction until a Reversal
Request Response is received indicating the Switch is aware of the
reversal.

Transaction Flows
Advice Response message, as applicable, from the Switch. SPAN then
removes the message from the Store-and-Forward File.
Point 11 SPAN informs the Retailer Bank of the reversed authorisation amount.
The 1420 Reversal Advice message is then formatted by SPAN with the
total reversal amount. The 1420 message is sent to the Retailer Bank and
placed in the Store-And-Forward file in SPAN to maintain the reversal
transaction until a successful acknowledgement is received indicating the
Retailer Bank is aware of the reversal.
Retailer Bank and then removes the message from the Store-And-Forward
file (SAF).
Point 13 Because of the cancellation, the 1420 Reversal Advice message is
formatted by SPAN with the total amount to be reversed. The message is
sent to the Bank Card Scheme Bank and placed in the Store-And-Forward
file in SPAN to maintain the reversal transaction until a successful
acknowledgement is received from the Bank Card Scheme Bank. The
Bank Card Scheme Bank should not send the approved transaction that
matches the reversal to the offline settlement system for settlement.
Bank Card Scheme Bank. SPAN then removes the message from the
Store-And-Forward file (SAF).

Transaction Flows
4.9 POS Reconciliation Messages

This subsection describes the flow of Acquirer and Card Issuer reconciliation messages between SPAN
and a Member Bank. The reconciliation transaction provides financial totals between one acquirer and
one card issuer. SPAN sends reconciliation advices by processing an online balancing algorithm and
determining whether accumulated totals at the Bank are in agreement with those sent by SPAN. The
Member Banks must always acknowledge reconciliation advices sent by SPAN and log them for
resolving disputes at a later time. After SPAN completes its cutover, and after the reconciliation time
window period expires, SPAN will follow up with both Acquirer and Card Issuer totals for the posted
SPAN business date.
Reconciliation advice messages request the confirmation of totals (number and value). The totals
contained in a reconciliation advice message indicates an originating institution’s position as either an
acquirer or card issuer (but not both) as defined by the message type identifier. In all reconciliation
messages from SPAN, the Net Reconciliation Amount (field 97) is the basis for determining whether
the Bank and SPAN agree on the settlement amount. The net reconciliation amount is calculated using
the following formulas, based on the debit and credit as posted from SPAN’s perspective. All amounts
in the reconciliation messages are in the currency of reconciliation. If the net reconciliation amount
after completing computation of the results above is a negative value the character “D” shall be inserted
into the “X” portion of the net reconciliation amount otherwise the character “C” shall be inserted in
the “X” position.
Complete details of transaction accumulation for reconciliation purposes are presented in Section 5.
The net settlement amount is calculated using the following formulas, based on the debit and credit as
posted from SPAN's perspective.
1. 1522 Card Issuer Reconciliation Advice
2. 1520 Acquirer Reconciliation Advice
Where,
Credit Totals = Amount Credits + Reversal Amount Credits
Debit Totals = Amount Debits + Reversal Amount Debits
The Amount Credits element is the sum of Transaction Amount (field 4) in all financial
transaction indicated a credit (20-29).
The Reversal Amount Credits element is the sum of Transaction Amount (field 4) in all
financial transaction indicated a debit (00-19).
The Amount Debits element is the sum of Transaction Amount (field 4) in all financial
transaction indicated a Debit (00-19).
The Reversal Amount Debits element is the sum of Transaction Amount (field 4) in all
financial transaction indicated a credit (20-29).

Transaction Flows
3. The net reconciliation position for the Bank is calculated using the following formula.
Net Reconciliation Acquirer (POS) Net Card Issuer (POS) Net
= +
Amount Reconciliation Amount Reconciliation Amount
A positive amount signifies that the Bank has a net credit position, so SPAN will post this
amount as a credit to the Bank at settlement time. A negative amount represents a net debit
position for the Bank, so SPAN will post this amount as a debit at settlement time.
The Bank Card Scheme Totals Information (Field 126) is used to carry additional detailed settlement
information. This field contains the combined totals of all bank card scheme transactions. This field is
for statistical use only, and is not used for financial settlement.

Transaction Flows
4.9.1 Reconciliation – Acquirer reconciliation processing

Diagram: 1
1520
KSA Card Issuer
SPAN 2 Bank
1530
Purpose: The purpose of SPAN Acquirer Settlement processing is to provide a

mechanism within the network to allow for reconciliation error
notification. The totals reflected within these messages are computed based
on the SPAN business day for the period being reported. These totals
reflect the total activity that has occurred between SPAN and the Card
Issuer Bank for the period between the last two cutover messages (ISO
Message Type 1804 with a Function Code of 821) from SPAN. The Card
Issuer Bank must maintain totals of all transactions that have been
period.
SPAN
diagram above.
Point 1 SPAN generates the 1520 Acquirer Reconciliation Advice using totals that
have been accumulated and saved for the period between the two last 1804
Network Management Requests (Cutover) messages sent from SPAN. The
period between the previous two cutover messages sent from SPAN to the
Bank defines the previous business day. The totals in this message reflect
all approved transactions that have financial impact, reversal, and refund
transactions that were authorised or processed by the Card Issuer Bank.
Upon receipt of the 1520 Acquirer Reconciliation Advice, the Bank must
verify the message content. (See Exception Processing below.) The
settlement position, as reflected in the totals in the message, should be
equal to the net settlement position for the SPAN business day as
fully described in Section 5, of this manual. Each total that is provided in
the message is defined in Section 3 - Field Descriptions, of this manual.
In computing this position, the Bank must keep in mind that the totals
point of cutover. In automating the reconciliation process, be sure to allow
for manual processing of the reversals as some may not be included in the
Bank, depending on the Bank's systems processing characteristics.

Transaction Flows
must format the 1530 Acquirer Reconciliation Advice Response with a
value of "500" in the Action Code (field 66). The Conditional Total fields
of the message (all of the totals) may not be sent as they are in agreement
with the SPAN totals. The Bank processing system must log the totals
received from SPAN and use them on a report to be used by Bank
personnel for verification of reconciliation totals.
acknowledgement of settlement totals for the previous business day and
(A) Verify that the Reconciliation Date (field 28) contains the previous
SPAN business day.
When it does not, log the message and set the value of "915" - Error, in the
(B) Verify that the amounts present in the message correspond to the total
If an Out-of-balance Condition exists, the Action Code (field 39) must be
set to a value of "501" indicating such a condition. The Banks computed
totals must be placed in the Conditional Total fields of the 1530 message
for the out-of balance totals that the Bank has identified.

Transaction Flows
4.9.2 Reconciliation - Acquirer reconciliation Store-and-Forward (SAF) processing

1521 – Acquirer Reconciliation Advice Repeat
Diagram: 1
1520
2
SPAN 3 Bank
1530
SAF
1521
Purpose: The purpose of SPAN Acquirer Settlement processing is to provide a

mechanism within the network to allow for reconciliation error
notification. The totals reflected within these messages are computed
based on the SPAN business day for the period being reported. These
totals reflect the total activity that has occurred between SPAN and the
Card Issuer Bank for the period between the last two cutover messages
from SPAN. The Card Issuer Bank must maintain totals of all transactions
that have been exchanged between the Bank processing system and SPAN
for that cutover period.
In the event that the 1530 Acquirer Reconciliation Advice Response is not
received by SPAN upon issuing a 1520 Acquirer Reconciliation Request,
SPAN generates the repeat message (1521) to verify that reconciliation
totals are received by the Bank. This message is sent by SPAN until the
1530 response is received by SPAN from the Bank.
SPAN
diagram above.
Point 1 SPAN generates the 1520 Acquirer Reconciliation Advice to the Card
Issuer Bank and times out.

Transaction Flows
Point 2 SPAN then generates the 1521 Acquirer Reconciliation Advice Repeat.
The totals in this message reflect all transactions that were received from
the Card Issuer Bank in a period between the previous two cutover
messages that were sent from SPAN to the Bank.
Upon receipt of the 1521 Acquirer Reconciliation Request Repeat, the
Bank must verify the message content. (See Exception Processing below.)
The settlement position, as reflected in the totals in the message, should be
equal to the settlement position for the SPAN business day as computed by
in Section 5, of this manual. Each total that is provided in the message is
defined in Section 3 - Field Descriptions, of this manual. Consult these
two sections to further define the processing requirements for online
reconciliation.
In computing this position, the Bank must keep in mind that all totals
reversals as some may not be included in the daily total from the SPAN
and may be included in the reversal counts of the Bank, depending on the
Bank's systems processing characteristics.
must format the 1530 Acquirer Reconciliation Advice Response with a
value of “500” in the Action Code (field 39). The conditional total fields of
the message (all of the totals) must not be sent as they are in agreement
with the SPAN totals. The Bank processing system must log the totals
received from the SPAN and use them on a report to be used by Bank
SPAN receives the 1530 Acquirer Reconciliation Advice Response
verifying the receipt of reconciliation totals by the Bank. SPAN logs the
SPAN business day.

Transaction Flows
4.9.3 Reconciliation – Card Issuer reconciliation processing

1532 – Card Issuer Reconciliation Advice Response
Diagram: 1
1522 KSA Retailer
SPAN 2
1532 Bank
Purpose: The purpose of SPAN Card Issuer Bank Settlement processing is to

are computed based on the SPAN business day for the period being
reported. These totals reflect the total activity that has occurred between
the SPAN and the Retailer Bank for the period between the last two
cutover messages (ISO Message Type 1804 with a Network Management
Information Code of 201) from SPAN. The Retailer Bank must maintain
totals of all transactions that have been forwarded from the Bank
processing system to SPAN for that cutover period.
Used For: Verification of the Cutover Totals between the Retailer Bank and SPAN
diagram above.
Point 1 SPAN generates the 1522 Card Issuer Reconciliation Advice using totals
The period between the previous two cutover messages sent by SPAN
defines the previous SPAN business day. The totals in this message reflect
all approved transactions that have financial impact, reversal, and refund
transactions that originated in the Retailer Bank.
Upon receipt of the 1522 Card Issuer Reconciliation Advice, the Bank
must verify the message content. (See Exception Processing below.) The
settlement position as reflected in the totals in the message should be equal
to the net settlement position for SPAN business day as computed by the
Bank.
In computing this position the Bank must keep in mind that the totals
Bank. Due to reversal processing the Store-and-Forward nature of these
messages it is possible for the reversal totals to be unequal at the point of
cutover. In automating the reconciliation process be sure to allow for
manual processing of the reversals, as some may not be included in the
Bank depending on the Bank's system processing characteristics.

Transaction Flows
Point 2 When the net settlement position is stated correctly in the message, the
Bank must format the 1532 Card Issuer Reconciliation Advice Response
and place a value of "500" in the Settlement Code (field 39). The
Conditional Total fields of the message (all of the totals) must not be sent
as they are in agreement with SPAN totals. The Bank processing system
must log the totals received from SPAN and use them on a report to be
used by Bank personnel for verification of reconciliation totals.
SPAN receives the 1532 Card Issuer Reconciliation Advice Response and
SPAN business day.

Transaction Flows
4.9.4 Reconciliation – Card Issuer reconciliation Store-and-Forward (SAF) processing

1523 – Card Issuer Reconciliation Advice Repeat
1532 – Card Issuer Reconciliation Request Response
Diagram: 1
1522
2 KSA Retailer
SPAN 1523
3 Bank
1532
SAF
1523
Purpose: The purpose of SPAN Card Issuer Bank Settlement processing is to

are computed based on the SPAN business day for the period being
reported. These totals reflect the total activity that has occurred between
SPAN and the Retailer Bank for the period between the last two cutover
messages from SPAN. The Retailer Bank must maintain totals of all
transactions that have been forwarded from the Bank processing system to
SPAN for that cutover period.
In the event that the 1532 Card Issuer Reconciliation Advice Response is
not received by SPAN upon issuing a 1522 Card Issuer Reconciliation
Advice, SPAN generates the repeat message to verify that reconciliation
totals are received by the Bank. This message is sent by SPAN until the
1532 response is received by SPAN from the Bank.
Used For: Verification of the Cutover Totals between the Retailer Bank and SPAN
diagram above.
Point 1 SPAN sends a 1522 Card Issuer Reconciliation Request to the Retailer
Bank, and does not receive a 1532 Card Issuer Reconciliation Request
Response within the allotted time.

Transaction Flows
Point 2 SPAN generates the 1523 Card Issuer Reconciliation Request Repeat. The
totals in this message reflect all transactions that were sent to the Bank in a
period between the previous two cutover messages that were sent from
SPAN to the Bank.
Upon receipt of the 1523 Card Issuer Reconciliation Request Repeat, the
Bank must verify the message content. (See Exception Processing below.)
The settlement position, as reflected in the totals in the message, should be
equal to the settlement position for the SPAN business day as computed by
in Section 5, of this manual. Each total that is provided in the message is
defined in Section 3 - Field Descriptions, of this manual. Consult these
two sections to further define the processing requirements for online
reconciliation.
In computing this position, the Bank must keep in mind that all totals
Bank's systems processing characteristics.
Point 3 When the settlement position is stated correctly in the message the Bank
must format the 1532 Card Issuer Reconciliation Advice Response and
place a value of "500" in the Action Code (field 39). The conditional total
fields of the message (all of the totals) must not be sent as they are in
agreement with SPAN totals. The Bank processing system must log the
totals received from SPAN and use them on a report to be used by Bank
SPAN receives the 1532 Card Issuer Reconciliation Advice Response and
SPAN business day.

Transaction Flows
4.9.5 Reconciliation – Terminal reconciliation processing

ISO Message Types: 1524 – Terminal Reconciliation Advice
1534 – Terminal Reconciliation Advice Response
Diagram:
3
1524 KSA Retailer
SPAN 4
1534 Bank
2
1534
1524
POS
Terminal
Purpose: The purpose of the SPAN POS Terminal Reconciliation Advice is to

provide an automated mechanism within the network to notify the Retailer
Bank of terminal reconciliation activity at that Bank's Retailers. The
Retailers perform terminal reconciliation in order to collect funds for
transactions performed at that terminal.
Used For: Transmitting SPAN POS terminal reconciliation data from SPAN to the
Retailer Bank.
diagram above.
Point 1 The SPAN POS terminal is reconciled by the Retailer and the terminal
sends a reconciliation request to SPAN.
Note.. If a SPAN POS terminal fails to send a terminal reconciliation
message for a sustained period, it is possible for parameters to be set in the
TMS (and then SPAN) which will cause the terminal totals accumulated by
SPAN to be forwarded to the Retailer Bank in a 1524 Terminal
Reconciliation message without this being initiated by receipt of a 1524
Terminal Reconciliation message from the POS.
Point 2 SPAN responds to the SPAN POS terminal reconciliation request with a
terminal reconciliation response.

Transaction Flows
Point 3 SPAN sends a 1524 SPAN Reconciliation Advice message to the Retailer
Bank that contains the transaction totals for that terminal. When the
terminal and SPAN do not agree on the transaction totals, field 124
contains the totals accumulated by the terminal; field 127 contains the
totals accumulated by SPAN for that terminal.
Note: The 1524 SPAN Reconciliation Advice message must be retrievable
by the Retailer Bank's Retailer Help Desk.
Point 4 The Retailer Bank must respond to the 1524 with a 1534 SPAN
Reconciliation Advice Response. The Retailer Bank simply acknowledges
the receipt of the 1524.

Transaction Flows
4.9.6 Reconciliation – Terminal reconciliation Store-and-Forward (SAF) processing

1525 – Terminal Reconciliation Advice Repeat
Diagram: 3
1524
KSA Retailer 5
1525 SPAN
Bank 6
1534
4 2
24
15
1534
1524
SAF
1524
POS
Terminal

provide an automated mechanism within the network to store terminal
reconciliation messages in the event of communication problems with the
Retailer Bank.
Used For: Verification of receipt of SPAN POS terminal reconciliation data from
SPAN to the Retailer Bank.
diagram above.
Point 1 The SPAN POS terminal is reconciled by the Retailer and the terminal
sends a reconciliation request to SPAN.
Bank that contains the transaction totals for that terminal. When the
terminal and SPAN do not agree on the transaction totals, field 124
contains the totals accumulated by the terminal; field 127 contains the
totals accumulated by SPAN for that terminal.
Note: The 1524 SPAN Reconciliation Advice message must be retrievable
by the Retailer Bank's Retailer Help Desk.
Point 4 SPAN does not receive the expected response (1534) in the time period
allowed. The 1524 is stored on the Store-And-Forward file (SAF) for later
transmission.

Transaction Flows
Point 5 When the Retailer Bank link becomes available, a 1525 SPAN
Reconciliation Advice Repeat (created from the 1524 message in the SAF
file) is sent to the Retailer Bank.
Point 6 The Retailer Bank must respond to the 1525 with a 1534 SPAN
Reconciliation Advice Response. The Retailer Bank only acknowledges

Transaction Flows
4.9.7 Reconciliation – POS terminal reconciliation was completed by SPAN but the response
message from SPAN was not received by the POS terminal (repeat reconciliation)
Diagram:
KSA Retailer
SPAN
Bank
1534 2
1524
POS
Terminal
Purpose: The purpose of the SPAN POS Terminal Repeat Reconciliation transaction
is to provide a mechanism for repeating a reconciliation transaction for
which no final response was received at the terminal.
Used For: Re-sending a reconciliation transaction to SPAN.
diagram above.
Point 1 When the Retailer executes a reconciliation request transaction after a
previous reconciliation request has been successfully processed at the
transaction Host, but before the transaction Host has successfully
processed a new transaction request for that POS terminal, this is
considered a repeat reconciliation.
Point 2 SPAN determines that it is in fact a repeat reconciliation request because it
matches the previous one. SPAN assumes the POS terminal did not
receive the original reconciliation response, so SPAN responds to the
terminal with a terminal reconciliation response message with the same
totals as the previous reconciliation response.
SPAN does not send a 1524 SPAN Reconciliation Advice message to the
Retailer Bank because one was successfully sent when the terminal was
originally reconciled.
In this way, the terminal is allowed to complete the reconciliation, print the
receipt, and reset its totals without duplicating information already
accumulated by SPAN and the Retailer Bank.

Transaction Flows
4.9.8 Reconciliation – Retailer Bank and the Bank Card Scheme Bank are the same
institution
3 Bank
1524
SPAN 4
1534 KSA Bank Card
Scheme Bank
1534 2
1524
POS
Terminal

Bank/Bank Card Scheme Bank of terminal reconciliation activity at the
bank's Retailers. The Retailer performs terminal reconciliation in order to
collect funds for transactions performed at that terminal.
Retailer Bank.
diagram above.
Point 1 SPAN POS terminal is reconciled by the Retailer and the terminal sends a
reconciliation request to SPAN.

Transaction Flows
Bank/Bank Card Scheme Bank that contains the POS Terminal
Reconciliation data element (field 124), the card scheme totals
accumulated by the terminal. This data element contains up to 10
occurrences of card scheme totals.
For each card scheme, the following information is present in field 124:
Card Scheme ID
Card Scheme Acquirer ID
Debit Count
Debit Amount
Credit Count
Credit Amount
Cash Back Amount
Cash Advance Amount
When the terminal is out-of-balance in this reconciliation, the 1524
Terminal Reconciliation Advice also contains the totals SPAN
accumulated for the terminal (field 127). This data element gives the
accumulated totals by card scheme similar to field 124, but contains the
totals accumulated by SPAN for the terminal.
Point 4 The Retailer Bank responds to the 1524 with a 1534 SPAN Reconciliation
Advice Response. The Retailer Bank simply acknowledges the receipt of
the 1524.
Note: A terminal reconciliation initiates the payment of funds from the
Retailer Bank/Bank Card Scheme Bank to the Retailer.
For International Bank Card Schemes, the Retailer Bank/Bank Card
Scheme Bank must prepare and transmit a clearing/settlement file to the
International Bank Card Scheme to receive payment of funds from the
International Bank Card Scheme.
It is important for the Retailer Bank/Bank Card Scheme Bank to
warehouse transactions (not submit the transactions for settlement) until it
receives a 1524 Terminal Reconciliation Advice for those transactions.
This ensures that all system-generated reversals have been applied to the
transactions before settlement. When the Retailer does not reconcile each
terminal on a daily basis, then the Retailer Bank/Bank Card Scheme Bank
must continue to accumulate transactions until the Retailer performs the
reconciliation function.

Transaction Flows
4.9.9 Reconciliation - Retailer Bank and the Bank Card Scheme Bank are not the same
institutions and the Bank Card Scheme Bank services both Visa and MasterCard
Diagram:
3A
1524 KSA Retailer
SPAN 4A
1534 Bank
2 3B
15
24
15
34
1534
1524
MasterCard &
4B VISA Bank Card
Scheme Bank
POS
Terminal

Bank and the Bank Card Scheme Bank of terminal reconciliation activity
at that Bank's Retailers. The Retailer performs terminal reconciliation in
order to collect funds for transactions performed at that terminal.
Retailer Bank and Bank Card Scheme Bank.
diagram above.

Transaction Flows
Point 3 (3A) SPAN sends a 1524 SPAN Reconciliation Advice message to the
Retailer Bank that contains the POS Terminal Reconciliation data element
(field 124), the card scheme totals accumulated by the terminal. This data
element contains up to 10 occurrences of card scheme totals.
Card Scheme ID
Debit Count
Debit Amount
Credit Count
Credit Amount
Cash Back Amount
Cash Advance Amount
The 1524 sent to the Retailer Bank has the card scheme totals for all card
schemes used at that terminal.
totals accumulated by SPAN.
(3B) SPAN sends a 1524 SPAN Reconciliation Advice message to the
Bank Card Scheme Bank that contains the POS Terminal Reconciliation
data element (field 124), the card scheme totals accumulated by the
terminal. The 1524 sent to the Bank Card Scheme Bank contains only the
totals for their Card Schemes (in this case Visa and MasterCard) in field
124.
accumulated totals for the relevant card schemes similar to field 124, but
contains the totals accumulated by SPAN for the terminal.
Note:
DE 39 Action Code will be set to either ‘Reconciled-In balance’ OR
‘Reconciled-out of balance’ based on totals received by each Bank whether
it is acting as either retailer bank or bank card scheme bank.

Transaction Flows
Point 4 (4A) The Retailer Bank responds to the 1524 with a 1534 SPAN
(4B) The Bank Card Scheme Bank responds to the 1524 with a 1534
SPAN Reconciliation Advice Response. The Bank Card Scheme Bank
simply acknowledges the receipt of the 1524.
Note: A terminal reconciliation initiates the payment of funds to the
Retailer. Funds flow from the Retailer Bank to the Retailer for SPAN card
transactions. Funds flow from the Bank Card Scheme Bank to the Retailer
for International Bank Card Scheme transactions.
For International Bank Card Schemes, the Bank Card Scheme Bank must
prepare and transmit a clearing/settlement file to each International Bank
Card Scheme to receive payment of funds from the International Bank
Card Scheme.
It is important for the Bank Card Scheme Bank to warehouse transactions
(not submitting the transactions for settlement) until it receives a 1524
Terminal Reconciliation Advice for those transactions. This ensures all
system-generated reversals have been applied to the transactions before
settlement. When the Retailer does not reconcile each terminal on a daily
basis, then the Bank Card Scheme Bank must continue to accumulate
transactions until the Retailer performs the reconciliation function.

Transaction Flows
institutions, different Bank Card Scheme Banks service Visa and MasterCard
Diagram:
VISA Bank Card
4B Scheme Bank
24
15
34
15
3B
3A
1524 KSA Retailer
SPAN 4A
1534 Bank
2 3C
15
24
15
34
1534
1524
MasterCard Bank
4C Card Scheme
Bank
POS
Terminal

Bank and the Bank Card Scheme Banks of terminal reconciliation activity
at the bank's Retailers. The Retailer performs terminal reconciliation in
order to collect funds for transactions performed at that terminal.
Retailer Bank and Bank Card Scheme Banks.
diagram above.

Transaction Flows
Card Scheme ID
Debit Count
Debit Amount
Credit Count
Credit Amount
Cash Back Amount
Cash Advance Amount
Visa Bank Card Scheme Bank that contains the POS Terminal
accumulated by the terminal. The 1524 sent to the Visa Bank Card
Scheme Bank contains only the Visa card scheme totals in field 124.
accumulated for the terminal (field 127). This data element contains the
Visa totals accumulated by SPAN for the terminal.
(3C) SPAN sends a 1524 SPAN Reconciliation Advice message to the
MasterCard Bank Card Scheme Bank that contains the POS Terminal
accumulated by the terminal. The 1524 sent to the MasterCard Bank Card
Scheme Bank contains only the MasterCard card scheme totals in field
124.
Terminal Reconciliation Advice also contains the MasterCard totals SPAN
accumulated for the terminal (field 127). This data element contains the
MasterCard totals accumulated by SPAN for the terminal.
Note:
DE 39 Action Code will be set to either ‘Reconciled-In balance’ OR
‘Reconciled-out of balance’ based on totals received by each Bank whether
it is acting as either retailer bank or bank card scheme bank.

Transaction Flows
(4B) The Visa Bank Card Scheme Bank responds to the 1524 with a
1534 SPAN Reconciliation Advice Response. The Visa Bank Card
Scheme Bank simply acknowledges the receipt of the 1524.
(4C) The MasterCard Bank Card Scheme Bank responds to the 1524
with a 1534 SPAN Reconciliation Advice Response. The MasterCard
Bank Card Scheme Bank simply acknowledges the receipt of the 1524.
transactions. Funds flow from the International Bank Card Scheme Banks
to the Retailer for International Bank Card Scheme transactions.
Card Scheme.

Transaction Flows
4.9.11 Reconciliation – Store-and-Forward (SAF) processing, where Retailer Bank and the
Bank Card Scheme Bank are the same institution
1524
3
Bank 5
1525 SPAN
KSA Bank Card 6
Scheme Bank 1534
4 2
24
15
1524
1534
SAF
1524
POS
Terminal

Bank/Bank Card Scheme Bank of terminal reconciliation activity at the
bank's Retailers. Store-and-Forward Processing provides an automated
mechanism within the network to store terminal reconciliation messages in
the event of communication problems with the Retailer Bank/Bank Card
Scheme Bank.
SPAN to the Retailer Bank/Bank Card Scheme Bank.
diagram above.

Transaction Flows
Bank/Bank Card Scheme Bank that contains the POS Terminal
accumulated by the terminal. This data element contains up to 10
occurrences of card scheme totals.
Card Scheme ID
Debit Count
Debit Amount
Credit Count
Credit Amount
Cash Back Amount
Cash Advance Amount
totals accumulated by SPAN for the terminal.
Point 4 SPAN does not receive the expected response (1534) in the time period
allowed. The 1524 is stored on the Store-And-Forward file (SAF) for later
transmission.
Point 5 When the Retailer Bank/Bank Card Scheme Bank link becomes available,
a 1525 SPAN Reconciliation Advice Repeat is sent to the Retailer
Point 6 The Retailer Bank/Bank Card Scheme Bank responds to the 1525 with a
1534 SPAN Reconciliation Advice Response. The Retailer Bank/Bank
Card Scheme Bank simply acknowledges the receipt of the 1525.
Note: A terminal reconciliation initiates the payment of funds from the
Retailer Bank/Bank Card Scheme Bank to the Retailer.
For International Bank Card Schemes, the Retailer Bank/Bank Card
Scheme Bank must prepare and transmit a clearing/settlement file to the
International Bank Card Scheme to receive payment of funds from the
International Bank Card Scheme.
It is important for the Retailer Bank/Bank Card Scheme Bank to
warehouse transactions (not submit the transactions for settlement) until it
receives a 1524 Terminal Reconciliation Advice for those transactions.
This ensures all system-generated reversals have been applied to the
transactions before settlement. When the Retailer does not reconcile each
terminal on a daily basis, then the Retailer Bank/Bank Card Scheme Bank
must continue to accumulate transactions until the Retailer performs the
reconciliation function.

Transaction Flows
4.9.12 Reconciliation – Retailer Bank and the Bank Card Scheme Bank are not the same
institutions and the Bank Card Scheme Bank services both Visa and MasterCard
Diagram:
3A
KSA Retailer 1524
4A SPAN
Bank 1534
3B 2
24 4B
15
25
1534
1524
15
34
15
MasterCard & 4B
VISA Bank Card 5
Scheme Bank
24 1
15
POS
SAF Terminal
1524

Bank and the Bank Card Scheme Bank of terminal reconciliation activity
at the bank's Retailers. Store-and-Forward Processing provides an
automated mechanism within the network to store terminal reconciliation
messages in the event of communication problems with the Bank Card
Scheme Bank.
SPAN to the Retailer Bank and the Bank Card Scheme Bank.
diagram above.

Transaction Flows
Card Scheme ID
Debit Count
Debit Amount
Credit Count
Credit Amount
Cash Back Amount
Cash Advance Amount
Bank Card Scheme Bank that contains the POS Terminal Reconciliation
data element (field 124), the card scheme totals accumulated by the
terminal. The 1524 sent to the Bank Card Scheme Bank contains only the
Visa and MasterCard card scheme totals in field.
accumulated for the terminal (field 127). This data element gives the totals
SPAN accumulated for International Card Schemes.
(4B) SPAN does not receive the expected response (1534) from the
Bank Card Scheme Bank in the time period allowed. The 0524 is stored
on the Store-And-Forward file (SAF) for later transmission. When the
Bank Card Scheme Bank link becomes available, a 1525 SPAN
Reconciliation Advice Repeat is sent to the Bank Card Scheme Bank.

Transaction Flows
Point 5 The Bank Card Scheme Bank responds to the 1525 with a 1534 SPAN
Reconciliation Advice Response. The Bank Card Scheme Bank simply
acknowledges the receipt of the 1525.
Card Scheme.

Transaction Flows
institutions, different Bank Card Scheme Banks service Visa and MasterCard
Diagram:
VISA Bank Card
Scheme Bank 4B
15
24
15
34
3B
3A
KSA Retailer 1524
4A SPAN
Bank 1534
3C 2
24 4C
15
25
1524
1525
15
34
15
MasterCard Bank 4C
Card Scheme 5
Bank
24 1
15
POS
SAF Terminal
1524

Bank and the Bank Card Scheme Banks of terminal reconciliation activity
at the bank's Retailers. Store-and-Forward Processing provides an
automated mechanism within the network to store terminal reconciliation
messages in the event of communication problems with the Bank Card
Scheme Bank. In this flow, one Bank Card Scheme Bank services Visa
transactions, and another services MasterCard transactions.
SPAN to the Retailer Bank and the Bank Card Scheme Banks.
diagram above.

Transaction Flows
Card Scheme ID
Debit Count
Debit Amount
Credit Count
Credit Amount
Cash Back Amount
Cash Advance Amount
accumulated totals by card scheme similar to S-124, but contains the totals
accumulated by SPAN.
Visa Bank Card Scheme Bank that contains the POS Terminal
accumulated by the terminal. The 1524 sent to the Visa Bank Card
Scheme Bank contains only the Visa card scheme totals in field 124.
accumulated for the terminal (field 127). This data element gives the Visa
totals SPAN accumulated for the terminal.
(3C) SPAN sends a 1524 SPAN Reconciliation Advice message to the
MasterCard Bank Card Scheme Bank that contains the POS Terminal
accumulated by the terminal. The 1524 sent to the MasterCard Bank Card
Scheme Bank contains only the MasterCard card scheme totals in field
124.
Terminal Reconciliation Advice also contains the MasterCard totals SPAN
MasterCard totals SPAN accumulated for the terminal.

Transaction Flows
(4B) The Visa Bank Card Scheme Bank responds to the 1524 with a
1534 SPAN Reconciliation Advice Response. The Visa Bank Card
(4C) SPAN does not receive the expected response (1534) from the
MasterCard Bank Card Scheme Bank in the time period allowed. The
1524 is stored on the Store-and-Forward File (SAF) for later transmission.
When the MasterCard Bank Card Scheme Bank link becomes available, a
1525 SPAN Reconciliation Advice Repeat is sent to the MasterCard Bank
Card Scheme Bank.
Point 5 The MasterCard Bank Card Scheme Bank responds to the 1525 with a
1534 SPAN Reconciliation Advice Response. The MasterCard Bank Card
also prepare and transmit a clearing/settlement file to each International
Bank Card Scheme to receive payment of funds from the International
Bank Card Scheme.

Transaction Flows
4.10 International Bank Scheme Related Messages (ATM & POS)

The messages and message flow description in this section are to be followed for both POS and ATM
transactions. These messages are exchanged between the International Bank Card Scheme switch,
SPAN and the Card Issuer Bank (for ATM only).
Note: SPAN does not route all incoming issuer transactions. All issuer transactions are directly routed
to the Member Banks except for MasterCard MDS, Visa-SMS and GCCNet transactions.

Transaction Flows
4.10.1 Financial Request – IBCS Card Issuer Bank participates in SPAN (ATM/POS)
Diagram: MasterCard - MDS
1
0200
2
GCCNet 4 SPAN 3
0210 1210 Bank
VISA-SMS

Used For: Purchase
ATM Withdrawal
ATM Balance Inquiry
diagram above.
Point 1 SPAN receives a 0200 Financial Transaction Request from the
International Bank Card Scheme Switch.
Point 2 SPAN verifies the following.
SPAN then formats and routes a 1200 Financial Transaction Request to the
Card Issuer Bank for authorisation.
Point 3 The Card Issuer Bank receives the 1200 request message. The Bank
verifies that it issued the card, then uses the Primary Account Number
(PAN) in the first position of Track 2 to determine the Cardholder's
account.
The Card Issuer Bank must carry out the following tasks.
PIN/PAN block using the Host Security Module (Refer to Section 7 -
Network Security).
The Card Issuer Bank builds a 1210 Financial Transaction Response
message and sends it to SPAN.

Transaction Flows
Point 4 SPAN receives the 1210 response message from the Card Issuer, logs the
transaction to the Transaction Log File. SPAN then builds a 0210
Financial Transaction Request Response and routes it to the International
Bank Card Scheme Switch.
SPAN Exception The points below describe some of the potential exception processing
Processing: scenarios and the procedure that is to be followed.
(A) Verify contents of all fields sent and perform Pre-Authorisation Denial
Checks on the 0200 request for validity. When any are invalid fields are
present send the appropriate Response Code field P-39 for the edit failure.
(B) Verify that the Card Issuer institution is supported by the network. When
it is not, the Invalid Destination for Routing (Response Code 92) is
returned to the acquiring institution in field P-39.
(C) Determine the availability of the Card Issuer Bank. When the Bank is
unavailable return a Temporary Service Interruption (Response Code 91)
in field P-39 to the acquiring institution.
institution.
If not, return Invalid Transaction (Action Code 902) in field 39.
117) in field 39.
field 39. The issuer must inhibit further access for that card. The
inhibition should remain in effect until it is lifted through an administrative
procedure upon Cardholder request.
Invalid Amount (Action Code 110) to SPAN in the P-39 field.

in field 39.
If not, send the No Cheque Account (Action Code 114) to SPAN in field 39.
(G) Verify that the Cardholder’s current account has sufficient funds to
If note, send Not sufficient funds (Action Code 116) to SPAN in field 39.

Transaction Flows
(H) Verify that the Cardholder has not exceeded the daily transaction
amount limit.
Code 121) to SPAN in field 39.
to SPAN in field 39.
(J) Verify the Cardholder's daily maximum usage limit has not been
123) to SPAN in field 39.
Inoperative (Action Code 907) to SPAN in field 39.

Transaction Flows
4.10.2 IBCS Reversal Processing (ATM/POS)

0420 – Acquirer Reversal Advice
0430 – Acquirer Reversal Advice Response
1 2
Diagram: 0200 1200
4 3
MasterCard- MDS 0210 1210 KSA Card Issuer
5 SPAN 7
GCCNet 0420 1420 Bank
VISA-SMS 6 8
0430 1430

Used For: Purchase
ATM Withdrawal
diagram above.
Issuer Bank, for authorisation.
account.
Network Security).

Transaction Flows
transaction to the Transaction Log File. SPAN then builds a 0210
Financial Transaction Request Response and routes it to the International
Bank Card Scheme Switch.
Point 5 The International Bank Card Scheme Switch attempts to forward the 0210
message to the Acquirer, but cannot successfully complete the transaction
due to failure of the communications link or failure of the Acquirer
Processing System.
Because the International Bank Card Scheme Switch has determined that
the Issuer's 0210 response is undeliverable, the International Bank Card
Scheme Switch immediately generates a reversal message to SPAN.
Note.. The IBCS do not reverse a Balance Inquiry transaction.
The reversal message sent from the IBCS Switch to SPAN is a 0420
Reversal Advice message.
The purpose of the advice is to let the Issuer know that its 0210 response
was not delivered, and the issuer should "reverse" or adjust its Cardholder
authorisation file as necessary to reflect the transaction was not completed.
Point 6 SPAN returns a reversal response to the International Bank Card Scheme
Switch.
The reversal response sent to the Switch is a 0430 Reversal Advice
Response message.
Point 7 SPAN forwards a 1420 Acquirer Reversal Advice to the Card Issuer Bank.
Point 8 The Card Issuer Bank formats and sends a 1430 Acquirer Reversal
Response to SPAN.

Transaction Flows
4.10.3 Reversal – Foreign withdrawal is partially dispensed; the Switch notifies SPAN, which
sends a partial reversal to the IBCS Card Issuer Bank participant (ATM)
2
Diagram: 1
0200 1200
4 3
MasterCard - MDS 0210 1210 KSA Card Issuer
GCCNet 5 SPAN 7
0420 1420 Bank
VISA-SMS
6 8
0430 1430
Purpose: The purpose of SPAN ATM reversal processing is to handle an ATM

failure.
Used For: ATM withdrawals where the amount requested was partially dispensed.
diagram above.
Point 1 SPAN receives a 0200 Financial Transaction Request from the Switch.
Point 2 SPAN receives the request message and uses the Track 2 data to determine
the Cardholder's Bank.

Transaction Flows
Point 3 The Card Issuer Bank/Network receives the 1200 request message and
account. It is used to cross-reference the card account to the Cardholder's
current account number set up for ATM processing.
Network Security, for PIN/PAN block management).
The Card Issuer Bank/Network begins building a 1210 Financial Request
Response message, as required and sends it to SPAN.
Point 4 SPAN receives the 1210 response message from the Card Issuer and does
the following.
• Logs the transaction to the Transaction Log File (TLF)
• Formulates and routes a 0210 Financial Request Response to the
switch.
Point 5 The Switch receives notice from the Acquirer Bank that the transaction
was dispensed partially. The Switch sends a 0420 Acquirer Reversal
Advice message to SPAN notifying of the partially dispensed withdrawal.
Point 6 SPAN sends 0430 Reversal Advice Response to the IBCS Switch for
onward routing to the acquirer before it sends the 1420 Reversal Advice to
the Card Issuer Bank.
Point 7 SPAN formats and sends a 1420 Reversal Advice to the Card Issuer Bank:
• Transaction Amount (field 4) set to the total amount to be reversed –
this value should be less than or equal to the original amount.
• Original Amounts (field 30) – the original transaction amount should
be supplied in the Transaction Original Amount component of this
data element.
• Message Reason Code (field 25) set to “4004” – to indicate that the
transaction has been completely partially.

Transaction Flows
Point 8 Upon receipt of the 1420 Acquirer Reversal Advice from SPAN, the Card
Issuer system is expected to log the transaction and adjust the balances of
the Cardholder's account, reconciliation totals, and the number and amount
of withdrawals from the Cardholder's account based on the Transaction
Amount field (field 4) in the 1420 message. The issuer must then format a
1430 Acquirer Reversal Advice Response to SPAN acknowledging the
receipt of the reversal from SPAN.

Transaction Flows
4.10.4 Chargeback – IBCS Acquirer Chargeback Processing

ISO Message Types: 0422 – Chargeback
0432 – Chargeback Response
1422 – Chargeback Advice / Chargeback Reversal
1432 – Chargeback Advice Response
Diagram: 1 3
VISA - SMS 0422 1422 KSA Acquirer
2 SPAN 4
MasterCard - 0432 1432 Bank
MDS
Purpose: An issuer uses a chargeback to return a previously accepted financial

transaction to an acquirer. Issuers have the right to charge back to the
acquirer posted transactions that are disputed by the cardholder or
identified as invalid by the issuer. Chargebacks must adhere to applicable
IBCS operating regulations.
The chargeback flows from the issuer to the acquirer, i.e. in the opposite
direction from other financial transactions. The response by the acquirer
acknowledges that the chargeback was successfully received and
processed. The response does not signify that the acquirer is in agreement
with the request.
Acquirers use re-presentments to return invalid chargebacks.
Used For: Chargeback
Chargeback Reversals
diagram above.
Point 1 SPAN receives a 0422 Chargeback message from the International Bank
Card Scheme Switch based on a cardholder claim to reverse a false
transaction. The Chargeback message contains information from the
original transaction.
Point 2 SPAN forwards a 0432 Chargeback Response to the International Bank
Card Scheme Switch.
Point 3 SPAN formulates a 1422 Chargeback Advice with the appropriate function
code and sends it to the Acquirer Bank.
Point 4 The Acquirer Bank returns a 1432 Chargeback Advice Response to SPAN.
(A) In the event that SPAN is unable to send the 1422 Chargeback Advice
message to the Acquirer Bank, it will be stored in a SAF file for later
transmission.

Transaction Flows
4.10.5 Chargeback – IBCS Issuer Chargeback Processing

ISO Message Types: 0422 – Chargeback
0432 – Chargeback Response
1422 – Chargeback Advice / Chargeback Reversal
Diagram: 0422 3 1422
1
VISA - SMS KSA Issuer
SPAN
MasterCard - 4 Bank
2
MDS 0432 1432
Purpose: An issuer uses a chargeback to return a previously accepted financial

transaction to an acquirer. Issuers have the right to charge back to the
acquirer posted transactions that are disputed by the cardholder or
identified as invalid by the issuer. Chargebacks must adhere to applicable
IBCS operating regulations.
The chargeback flows from the issuer to the acquirer, i.e. in the opposite
direction from other financial transactions. The response by the acquirer
acknowledges that the chargeback was successfully received and
processed. The response does not signify that the acquirer is in agreement
with the request.
Acquirers use re-presentments to return invalid chargebacks.
Used For: Chargeback
Chargeback Reversals
diagram above.
Point 1 SPAN receives a 1422 Chargeback Advice message from the KSA Card
Issuer based on a cardholder claim to reverse a false transaction. The
Chargeback message contains information from the original transaction.
Point 2 SPAN responds with a 1432 Chargeback Advice Response to the KSA
Card Issuer International Bank Card Scheme Switch.
Point 3 SPAN formulates a 0422 Chargeback Advice to the International Bank
Card Scheme Switch
Point 4 The International Bank Card Scheme Switch returns a 0432 Chargeback
Advice Response to SPAN.
(A) In the event that SPAN is unable to send the 0422 Chargeback Advice
message to the International Bank Card Scheme Switch it will be stored in
a SAF file for later transmission.

Transaction Flows
4.10.6 Re-presentment – IBCS Acquirer Re-presentment Processing

ISO Message Types: 0220 – Re-presentment Advice
0230 – Re-presentment Advice Response
Diagram: VISA - SMS 0220
3 1
1220 KSA Acquirer
MasterCard - 4 SPAN 2
0230 1230 Bank
MDS
Purpose: To initiate a re-presentment to recover funds for a previous chargeback

message.
Used For: Re-presentment
diagram above.
Point 1 The Acquirer Bank would create a 1220 Financial Advice (Re-
presentment) if it is known that a previous chargeback message is incorrect
and send it to SPAN with information from the original chargeback
transaction.
Point 2 SPAN sends a 1230 Financial Advice Response (Re-presentment
Response) to the Acquirer Bank.
Point 3 SPAN creates a 0220 Re-presentment Advice with and sends it to the
Point 4 The International Bank Card Scheme Switch returns a 0230 Re-
presentment Response to SPAN.

Transaction Flows
4.10.7 Re-presentment – IBCS Issuer Re-presentment Processing

ISO Message Types: 0220 – Re-presentment Advice
0230 – Re-presentment Advice Response
Diagram: VISA- SMS
1
0220
3
1220
KSA Issuer
MasterCard- SPAN
2 4 Bank
MDS 0230 1230
Purpose: To initiate a re-presentment to recover funds for a previous chargeback

message.
Used For: Re-presentment
diagram above.
Point 1 The International Bank Card Scheme Switch forwards an 0220 Financial
Advice (Re-presentment) from the Acquirer, if it is known that a previous
chargeback message is incorrect and sends it to SPAN with information
from the original chargeback transaction.
Point 2 SPAN returns an 0230 Re-presentment Response to the International Bank
Card Scheme Switch.
Point 3 SPAN creates a 1220 Financial Advice (Re-presentment) to the KSA Card
Issuer.
Point 4 The Card Issuer sends a 1230 Financial Advice Response (Re-presentment
Response) to SPAN.

Transaction Flows
4.10.8 Communications Failure - Link Down between SPAN and IBCS Card Issuer Bank
(SPAN Member) - (ATM/POS)
Diagram: MasterCard - MDS

1
GCCNet 2 SPAN
1
VISA - SMS 0210 Bank
Purpose: The purpose of SPAN communication failure processing is to provide a

mechanism to handle a complete communications failure within the
network.
Used For: SPAN Request Transaction for POS and ATM transaction when the link to
a card issuer is completely unavailable.
diagram above.
If the Card Issuer is not currently available, that is all the connections to
the Card Issuer are marked as down, SPAN will not attempt to send a 1200
Financial Request to the Card Issuer. It will respond directly, declining the
transaction indicating that the Card Issuer is unavailable. See Section 6 for
more information about the link down process.
SPAN formats and returns a 0210 Financial Transaction Request Response

to the International Bank Card Scheme Switch with a 91 response code,
indicating the Issuer is not available.

Transaction Flows
4.10.9 Timeout Processing – No Response Received from IBCS Card Issuer Bank, (SPAN
Member Bank) - (ATM/POS)
Diagram: 1
2
1200
MasterCard -MDS 0200 3 KSA Card Issuer
GCCNet 6 SPAN 1210
VISA - SMS 0210 4 Bank
1420
5
1430
Purpose: The purpose of SPAN timeout processing is to provide a mechanism to

handle the event of a communications failure within the network or a Card
Issuer Bank processing error.
Used For: SPAN Request Transaction Timeouts for POS and ATM.
diagram above.
Point 2 SPAN verifies that the contents of all message fields are valid, that the
requested transaction is allowed, and that the Card Issuer is supported by
SPAN and is currently available. SPAN then formats and routes a 1200
Financial Transaction Request to the Card Issuer Bank for authorisation
and sets a timer to wait for a response.
account.
Network Security).
• Validate the Card Verification Value (CVV)/ Card Validation Code
message and attempts to send it to SPAN, but communication problems
prevent the message from being received by SPAN.

Transaction Flows
Point 4 SPAN’s timer expires awaiting the 1210 Financial Request Response from
the Card Issuer Bank. SPAN formats a 1420 Reversal Advice to the Card
issuer.
Point 6 SPAN formats and returns a 0210 Financial Transaction Request Response
to the International Bank Card Scheme Switch with a 91 response code,
indicating the Issuer is not available.
Note: In this example, SPAN returns a response before the International
Bank Card Scheme Switch has timed-out.

Transaction Flows
4.10.10 Communications Failure – Link down between SPAN and IBCS Switch (ATM/POS)
Diagram: 2
1200
3
MasterCard - MDS 1 1210
GCCNet SPAN 5
4 1420 Bank
0210
VISA-SMS 6
1430
Purpose: The purpose of International Bank Card Scheme Switch link down
processing is to provide a mechanism to handle the rare event of a
communications failure or SPAN processing error that does not provide a
0210 Financial Transaction Request Response to the International Bank
Card Switch for an authorised transaction.
Used For: SPAN Response Transactions for POS and ATM when the link is down
with the IBCS switch.
with International Banks Card Schemes should only happen after the
Scheme Acquirer. When an approved transaction has been reversed, it
should be removed from the International Bank Card Scheme financial
settlement batch.
diagram above.
International Bank Card Switch.
Point 2 SPAN uses the Track 2 data from the 0200 request message to determine
the Cardholder's Bank.
• SPAN verifies the following.

Transaction Flows
Point 3 The Card Issuer Bank/Network receives the 1200 request message and
account. It is used to cross-reference the card account to the Cardholder's
current account number set up for ATM/POS processing.
Network Security).
The Card Issuer Bank begins building a 1210 Financial Request Response
In all 1210 messages sent to SPAN, the Card Issuer must include all
mandatory fields described in Section 2 - Message Formats, as well as any
Conditional Total fields when the specified condition is met (i.e.,
withdrawals with balances).
transaction to the Transaction Log File. SPAN then builds a 0210 response
message and attempts to route it to the International Bank Card Switch.
Due to communication problems, SPAN is unable to deliver the 0210 to
the International Bank Card Scheme Switch. For CIRRUS and
MAESTRO the transaction is complete at this point because stand-in is not
available (no SAF).
Note.. Where SPAN sends a response which does not reach the IBCS
issuer, SPAN will be aware of the problem only when the reversal arrives
from the network (if that is supported by the network).
Point 5 When the transaction response from the Card Issuer is an approval, SPAN
formats and sends a 1420 Reversal Advice to the Card Issuer Bank.
Point 6 The Card Issuer Bank must respond to the 1420 with a 1430 Reversal
Advice Response message.
SPAN retains reversal information (Store-and-Forward) in the event that
the Card Issuer does not acknowledge receipt of the reversal with the 1430
response.

Transaction Flows
a field format error or other processing error. In these instances, the issuer
must log the message and return the appropriate Action Code (field 39),
And-Forward (SAF) queue. Additionally, reconciliation totals should not
be adjusted since the Cardholders' accounts have not been adjusted at this
time. This leaves the responsibility for reconciliation of the Cardholder's
account with the issuer (as an administrative procedure) rather than
automatically affecting the balance. SPAN provides the reversal
information to the Card Issuer in its daily reporting.
section 3.4.24.

Transaction Flows
4.10.11 Timeout Processing – Timer set by Switch expires, thus the Switch sends response to
the transaction acquirer and then receives a late response from SPAN (ATM/POS)
0800 – Network Management Request
0810 – Network Management Response
1
Diagram: 0200
4
0210
GCCNet 6
0210
VISA-SMS 8
0420
2
9 1200
0430
3
SPAN 10
1 1420 Bank
0200 11
4 1430
0210
6
0210
7a
0420
MasterCard- MDS 0430 7b
12
0800
13
0810
5
0
04 42
20 14 0 0
082
SAF 15
Purpose: The purpose of Switch timeout processing is to provide a mechanism to

handle the rare event of a communications failure or SPAN processing
error that does not provide a timely response to the Switch for an
authorised transaction.
Used For: SPAN Response Transaction Timeouts.
with International Banks Card Schemes should only happen after the
Scheme Acquirer. When an approved transaction has been reversed, it
should be removed from the International Bank Card Scheme financial
settlement batch.
diagram above.
Point 1 SPAN receives a 0200 Financial Transaction Request from the Switch.
Point 2 SPAN verifies that the contents of all message fields are valid, that the
requested transaction is allowed, and that the Card Issuer is supported by
SPAN and is currently available. SPAN then formats and routes a 1200
Financial Transaction Request to the Card Issuer Bank for authorisation.

Transaction Flows
account.
• The Card Issuer Bank must carry out the following tasks.
Determine the balance of the Cardholder's account, and verify that the
Point 4 SPAN receives the 1210 Financial Transaction Request Response message
from the Card Issuer and logs the transaction to the Transaction Log File.
SPAN then builds a 0210 Financial Transaction Request Response and
attempts to route it to the appropriate Switch.
Point 5 The Switch times out waiting for a response from SPAN. MasterCard
MDS does not provide stand-in processing, so a 0420 Acquirer Reversal
Advice and 0430 Acquirer Reversal Advice Response is forwarded to the
SAF process for later transmission to SPAN.
Point 6 The Switch receives the late 0210 Financial Transaction Request Response
from SPAN. In this example, the 0210 had an approval or a call referral
response code.
Point 7 The MasterCard MDS network will immediately upon receipt of a "late"
approved 0210 message, return a 0420 Acquirer Reversal Advice and
0430 Acquirer Reversal Advice Response message to SPAN, indicating
that the previous 0210 message was "late" and was rejected. SPAN sends
back a 0430 Acquirer Reversal Advice Response.
Point 8 The GCCNet switch formats and sends 0420 Acquirer Reversal Advice to
SPAN.
Point 9 SPAN formats and sends a 0430 Acquirer Reversal Advice Response to
the GCCNet switch.
Point 10 SPAN formats and sends 1420 Acquirer Reversal Advice to the Card
Issuer Bank.
Point 11 The Card Issuer Bank formats and sends a 1430 Acquirer Reversal Advice
Response to SPAN.
Note: At a later time, SPAN can initiate a request for a SAF from
MasterCard.
Point 12 MasterCard-MDS sends a 0800 Network Management Message to SPAN
with the Network Management Code (P-70) set to '270' for an echotest.
Point 13 SPAN responds with a 0810 Network Management Response, indicating
communications are established.

Transaction Flows
Point 14 The MasterCard-MDS SAF process responds by automatically forwarding

the 0420 Acquirer Reversal Advice and 0430 Acquirer Reversal Advice
Response stored on its SAF file to SPAN. Note that SPAN does not send
back a 0430 Acquirer Reversal Advice Response for this advice.
Point 15 The MasterCard-MDS SAF process sends a 0820 SAF EOF message. The
Network Management Information Code (P-70) is set to '363' - Store and
Forward EOF.
SPAN retains reversal information (Store-and-Forward) in the event that
the Card Issuer does not acknowledge receipt of the reversal with the 1430
response.
a field format error or other processing error. In these instances, the issuer
must log the message and return the appropriate Action Code (field 39),
and-Forward queue.
balance.
reporting.
(C) For the full list of supported Action Codes (field 39) for reversals refer to
section 3.4.24.

Transaction Flows
4.10.12 Timeout Processing – SPAN receives Late Response from IBCS Card Issuer (SPAN
Member) - (ATM/POS)
2
Diagram: 1200
1 3
MasterCard- MDS 0200 1420
KSA Card Issuer
GCCNet 4 SPAN 5
0210 1210 Bank
VISA- SMS 6
1430
4
14
20
SAF
Purpose: The purpose of SPAN timeout processing is to provide a

mechanism to handle the event of a communications failure within
the network or a Card Issuer Bank processing error.
Used For: SPAN Request Transaction Timeouts with a late response from the
Card Issuer.
Note: By SPAN standards, financial settlement of electronic
transactions with International Banks Card Schemes should only
happen after the terminal reconciliation transaction has been
received by the Bank Card Scheme Acquirer. When an approved
transaction has been reversed, it should be removed from the
International Bank Card Scheme financial settlement batch.
Normal Processing: The following steps correspond to the numbers in the transaction
flow diagram above.
• The Card Issuer is supported by SPAN and is currently
available.
SPAN then formats and routes a 1200 Financial Transaction
Request to the Card Issuer Bank for authorisation and sets a timer to
wait for a response.

Transaction Flows
Point 3 SPAN’s timer expires awaiting the 1210 Financial Request

Response from the Card Issuer Bank. As SPAN does not know why
there has been no response, SPAN reverses the authorisation to the
Card Issuer. The 1420 Reversal Advice message is formatted by
SPAN with the Total amount to be reversed provided in the
Transaction Amount (field 4). Additionally, SPAN places the
Message Reason Code of 4021 (Timeout waiting response), in DE
25 Message Reason Code.
The Original Data (DE 56) is included in the 1420 message to
indicate the transaction being reversed. This field contains the
Original Transaction message type (1200), the Original Sequence
Number for the transaction, and the Date and Time of the original
message. The Transmission Date and Time field (DE 7), Local
Transaction Date and Time (DE 12), is set to the current time and
date that the reversal message is being sent from SPAN.
The 1420 message is placed in the Store-and-Forward File in SPAN
to maintain the reversal transaction until a successful
acknowledgement is received indicating the Card Issuer is aware of
the reversal. SPAN immediately logs the reversal. After a
successful log of the reversal information SPAN adjusts the
reconciliation totals of the Card Issuer to reflect the reversed
amount. SPAN continues to send the reversal in the form of the
1421Reversal Advice Repeat message, until the 1430 Reversal
Advice Response, is received from the Card Issuer.
Point 4 As the SPAN timer has expired waiting for the 1210 Financial
Transaction Request Response from the Card Issuer authorising the
transaction, SPAN formats a transaction decline (0210 Financial
Request Response) to the International Bank Card Scheme Switch
with the Response Code (field 39) set to "91" indicating the Issuer
Bank is inoperative. SPAN logs the transaction.
Note: In this example, SPAN returns a response before the
International Bank Card Scheme Switch has timed-out.
Point 5 In this example, the 1210 Financial Request Response message
from the Card Issuer arrives after SPAN has timed out the
transaction response and sent a 1420 Reversal Advice to the Card
Issuer and responded on behalf of the Card Issuer to the IBCS
switch (declined). In this case the 1210 Financial Request Response
is discarded.
Point 6 SPAN receives the 1430 Acquirer Reversal Advice Response
message, from the Card Issuer. SPAN then removes the message
from the Store-and-Forward File.
Note: Card Issuers must always send a 1210 response, even when it
is late. However, in the unlikely event that a 1210 approval is lost,
it will be handled by the Issuer at settlement reconciliation time. To
this purpose, Card Issuers are requested to perform a daily process
to automatically reconcile any transaction that was not reflected in
SPAN settlement detail information.
Exception Processing: The points describe some of the potential exception processing

Transaction Flows
(A) Reversal transactions cannot be denied when the system is

operational. The following exceptions are acceptable and require
SPAN to retain and continue sending the reversal information
(Store-and-Forward) until a 1430 response is received from the
Card Issuer.
(B) The reversal recipient could have a problem processing the reversal
due to a field format error or other processing error. In these
instances, the issuer must log the response and return the
appropriate Action Code (field 39), however no financial update to
the Cardholder's account is anticipated and the reversal initiator
logs the transaction and removes it from the Store-and-Forward
queue.
Cardholders' accounts have not been adjusted at this time. This
leaves the responsibility for reconciliation of the Cardholder's
account with the issuer (as an administrative procedure) rather than
automatically affecting the balance. The Acquirer is also required to
provide reports of the reversal to SPAN for reconciliation purposes.
SPAN provides the reversal information to the Card Issuer in its
daily reporting.
(C) For the full list of supported Action Codes (field 39) for reversals
refer to section 3.4.24.

Transaction Flows
4.10.13 Visa SMS Generated Acquirer Bound Reversal Advice Processing

Diagram: 2
0200
1 3
1200 0210
4A 4B
KSA Acquirer 1210 0420
8 SPAN 5 VISA-SMS
Bank 1420 0430
9 6
1430 0420
7
0430
Purpose: The purpose of the Visa SMS generated Acquirer bound Reversal Advice
processing is to provide a mechanism to handle the event when Visa SMS
generates a Reversal bound for the Acquirer. This occurs if Visa SMS cannot
return a 0210 approved response to the Acquirer because the Acquirer is
unavailable; Visa SMS reverses the transaction by creating a 0420 advice that
it immediately sends to the Issuer, and creates and stores a 0420 advice for the
Acquirer to recover.
This mechanism is designed to ensure that a consistent position is reflected at
both the Acquirer and Visa SMS.
Used For: Visa SMS Generated Acquirer Bound Reversals (Visa SMS)
diagram above.
The Bank's ATM processing system determines that the Cardholder is not a
member of its Bank by looking at the first 6 bytes of the PAN number (stored
on Track 2 data ISO field 35 encoded on the ATM card).
processing system and sent to SPAN, and sets a timer to wait for a response.
SPAN verifies the transaction as described in Section 2 and Section 3 and then
routes a 0200 Financial Request to Visa SMS, for authorisation.
Point 3 Visa SMS receives the 0200 request message and performs authorisation
according to its agreement with the Issuer. Visa SMS builds a 0210 Financial
Request Response message and attempts to send it to SPAN, but determines
that it is unable to do so, i.e. communication problems prevent the message
from being received by SPAN.

Transaction Flows
Point 4 (4A) The timer set by the SPAN expires before it receives a response, so
SPAN declines the transaction to Acquirer Bank by sending a 1210 Financial
Request Response with an Action Code (DE39) of "911".
(4B) SPAN also builds and sends Visa SMS a 0420 Reversal Advice upon
determining that a 0210 response has not been received. SPAN sends the 0420
Reversal Advice because there is no way for SPAN to know whether SMS has
already reversed the transaction or whether an approved 0210 Financial
Request Response simply never made it back to SPAN in time. The Reversal
Advice is sent at the same time as the response (4A) is returned to the SPAN
Acquirer Bank indicating the decline.
Point 5 Visa SMS acknowledges with a 0430 Reversal Advice Response.
Point 6 If the transaction was declined, the flow ends here.
For approved transactions, Visa SMS reverses the transaction by creating a
0420 advice that it immediately sends to the Issuer, and creates a 0420 advice
for the Acquirer.
Point 7 SPAN receives the 0420 Reversal Advice message from Visa SMS, logs the
transaction, and formats a 0430 Reversal Advice Response to Visa SMS.
Point 8 SPAN identifies the Acquirer Bank that originated the transaction from the
contents of the message. SPAN constructs and sends a 1420 Reversal Advice
based on the one received from Visa SMS.
Point 9 The Acquirer receives the 1420 Reversal Advice message from SPAN, logs
the transaction, and formats a 1430 Reversal Advice Response to SPAN
acknowledging the receipt of the Reversal.

Transaction Flows
4.10.14 Acquirer Generated Visa SMS Misdispense Advice Processing

ISO Message 0220 – Cash Disbursement Adjustment – Misdispense Advice
Types:
0230 – Cash Disbursement Adjustment – Misdispense Advice
Response
(Misdispense Adjustment)
Diagram: 3 1
0220 1220 KSA Acquirer
VISA - SMS 4 SPAN 2
0230 1230 Bank
Purpose: This is an automatic, usually ATM-initiated, adjustment sent soon after the
original because of a problem such as partial dispense or late completion.
Used For: Cash Disbursement Adjustment – Misdispense
diagram above.
Point 1 An Acquirer Bank receives a notification from an ATM indicating a problem
such as a partial dispense or late completion.
The Acquirer Bank constructs a 1220 Financial Transaction Advice
(Misdispense Adjustment) and sends it to SPAN.
Point 2 SPAN sends a 1230 Financial Transaction Advice Response back to the
Acquirer Bank.
If the Acquirer Bank receives no response, it should resend the advice as a
1221 Financial Transaction Advice Repeat.
Point 3 SPAN constructs an 0220 Cash Disbursement Adjustment – Misdispense
Advice and sends this to Visa.
Visa sends the 0220 to the Issuer. The Issuer sends an 0230 back to Visa.
Point 4 Visa sends an 0230 Advice Response back to SPAN.
If SPAN receives no response, the advice is held in SAF and resent until a
response is received.
Notes SPAN adopts the use of immediate advices response as mandated by SAMA.
At point 2 SPAN sends the 1230 Advice Response to the Acquirer Bank to
acknowledge receipt of the 1220 Financial Transaction Advice. This is
normal SPAN practice for advice responses, but arguably it deviates from
Visa intent. The Visa flow description ([SMSAPS] figure 4-5) shows Visa
awaiting the 0230 response from the issuer before forwarding it to the
acquirer. It is unclear whether Visa intends this behaviour to propagate
through an intermediate switch like SPAN.
(The same applies in other flows when SPAN receives an advice from Visa:
it immediately sends back an advice response to acknowledge receipt, then
passes on the advice to its destination.)

Transaction Flows
4.10.15 Acquirer Generated VISA SMS Reconciliation Adjustment Advice Processing

ISO Message 0220 – Back Office Adjustment Advice
Types:
0230 – Back Office Adjustment Advice Response
(Back Office Adjustment)
Diagram: 3 1
VISA - SMS 4 SPAN 2
0230 1230 Bank
Purpose: This is a manual adjustment sent when an error is discovered during

reconciliation.
Used For: Back Office Adjustment
diagram above.
Point 1 An Acquirer Bank detects an error or problem during reconciliation.
The Acquirer Bank constructs a 1220 Financial Transaction Advice (Back
Office Adjustment) and sends it to SPAN.
Acquirer Bank.
Point 3 SPAN constructs an 0220 Back Office Adjustment Advice and sends this to
Visa.

Transaction Flows
4.10.16 Acquirer Generated VISA SMS Fee Collection Processing

ISO Message 0220 – Acquirer-Generated Fee Collection Advice
Types:
0230 – Acquirer-Generated Fee Collection Advice Response
(Acquirer-Generated Fee Collection)
Diagram: 3 1
VISA - SMS 4 SPAN 2
0230 1230 Bank
Purpose: This is used by an Acquirer Bank to collect miscellaneous fees.

Used For: Acquirer-Generated Fee Collection
diagram above.
Point 1 An Acquirer Bank wants to collect a fee from an Issuer Bank.
(Acquirer-Generated Fee Collection) and sends it to SPAN.
Acquirer Bank.
Point 3 SPAN constructs an 0220 Acquirer-Generated Fee Collection Advice and
sends this to Visa.
Notes See note under MBI Message Flow in section Acquirer-Generated Fee
Collection on the use of immediate Advice Responses.

Transaction Flows
4.10.17 Acquirer Generated VISA SMS Fee Payment Advice Processing

ISO Message 0220 – Acquirer-Generated Funds Disbursement Advice
Types:
0230 – Acquirer-Generated Funds Disbursement Advice Response
(Acquirer-Generated Fee Payment)
Diagram: 3 1
VISA - SMS 4 SPAN 2
0230 1230 Bank
Purpose: This is used by an Acquirer Bank to pay miscellaneous fees.

Used For: Acquirer-Generated Fee Payment
diagram above.
Point 1 An Acquirer Bank wants to pay a fee to an Issuer Bank.
(Acquirer-Generated Fee Payment) and sends it to SPAN.
Acquirer Bank.
Point 3 SPAN constructs an 0220 Acquirer-Generated Funds Disbursement
Advice and sends this to Visa.

Transaction Flows
4.10.18 Issuer Generated VISA SMS Fee Collection Advice Processing

ISO Message Types: 0422 – Issuer-Generated Fee Collection Advice
0432 – Issuer-Generated Fee Collection Advice Response
1422 – Chargeback Advice
(Issuer-Generated Fee Collection)
Diagram: 1 3
VISA - SMS 2 SPAN 4
0432 1432 Bank
Purpose: This is used by an Issuer Bank to collect miscellaneous fees.

Used For: Issuer-Generated Fee Collection
Normal Processing: The following steps correspond to the numbers in the transaction
flow diagram above.
Point 1 An Issuer Bank wants to collect a fee from an Acquirer Bank.
The Issuer Bank constructs a 0422 Issuer-Generated Fee Collection
Advice and sends it to Visa.
Visa sends the 0422 to SPAN.
Point 2 SPAN sends an 0432 Advice Response back to Visa.
Point 3 SPAN constructs a 1422 Chargeback Advice (Issuer-Generated Fee
Collection) and sends this to the Acquirer Bank.
Point 4 The Acquirer Bank sends a 1432 Chargeback Advice Response
back to SPAN.
If SPAN receives no response, it should resend the advice as a
1422 Chargeback Advice Repeat. The advice is held in SAF and
resent until a response is received.

Transaction Flows
4.10.19 Issuer Generated VISA SMS Funds Disbursement Advice Processing

ISO Message Types: 0422 – Issuer-Generated Funds Disbursement Advice
0432 – Issuer-Generated Funds Disbursement Advice Response
1422 – Chargeback Advice
(Issuer-Generated Fee Payment)
Diagram: 1 3
VISA - SMS 2 SPAN 4
0432 1432 Bank
Purpose: This is used by an Issuer Bank to pay miscellaneous fees.

Used For: Issuer-Generated Fee Payment
Normal Processing: The following steps correspond to the numbers in the
transaction flow diagram above.
Point 1 An Issuer Bank wants to pay a fee to an Acquirer Bank.
The Issuer Bank constructs a 0422 Issuer-Generated Funds
Disbursement Advice and sends it to Visa.
Point 2 SPAN sends a 0432 Advice Response back to Visa.
Point 3 SPAN constructs a 1422 Chargeback Advice (Issuer-Generated
Fee Payment) and sends this to the Acquirer Bank.
Point 4 The Acquirer Bank sends a 1432 Chargeback Advice Response
back to SPAN.
If SPAN receives no response, it should resend the advice as a
1423 Chargeback Advice Repeat. The advice is held in SAF and
resent until a response is received.

Transaction Flows
4.10.20 VISA SMS Generated Funds Transfer Totals Advice Response

ISO Message 0620 – Funds Transfer Totals Advice
Types:
0630 – Funds Transfer Totals Advice Response
Diagram: 1
0620 3 Acquirer / Issuer
VISA-SMS SPAN Email/Fax/Report
0630 Bank
2
Purpose: The message provides an accounting of all settlement activity that has been
performed by VisaNet. Members can use this data for reconciliation.
Used For: Funds Transfer Totals
Normal The following steps correspond to the numbers in the transaction flow diagram
Processing: above.
Point 1 Visa constructs an 0620 Funds Transfer Totals Advice.
Point 2 SPAN sends an 0630 Advice Response back to Visa.
Point 3 SPAN will manually forward this information to the relevant Acquirer or Issuer
Bank via a suitable format, i.e. email, fax or report.

Transaction Flows
4.11 Claims Processing

SPAN has a separate system for processing adjustments within the SPAN member banks. This is the
Claims Processing System (CPS). The settlement of a claim causes the generation of a 1220 Advice
Message with the necessary details to the Card Issuer Bank and Acquirer Bank. This is routed via
SPAN for settlement purposes.

Transaction Flows
4.11.1 CPS Adjustment Transaction

Diagram: 1220
2B 4
1220
KSA Card Issuer KSA Acquirer
3 SPAN 5
Bank 1230 1230 Bank
2A
1220
1230
1
Claims
Processing
System
Purpose: To notify the Retailer/Acquirer Bank and the Card Issuer Bank when the
CPS generates an adjustment for settlement.
Used For: Credit Adjustment
Debit Adjustment
diagram above.
Point 1 SPAN receives 1220 Financial Advice from CPS.
DE 3 Processing Code (digits 1 and 2):
• 02 Debit to the customer
• 22 Credit to the customer
DE 24 Function Code – 286
DE 25 Message Reason Code not present.
message to the CPS.
(2B) SPAN formats and sends 1220 Financial Advice to the Card
Issuer Bank. The 1220 message contains detailed information allowing the
Card Issuer bank to debit/credit the customer and settle with the Retailer
Bank.
If there is a failure to deliver (2B), this advice will be retained in a Store-
and-Forward (SAF) file for delivery, when the connection is restored, as
1221 Financial Advice Repeat.
Point 3 The Card Issuer Bank must acknowledge the 1220 Financial Advice with
the 1230 Financial Advice Response returned to SPAN.
If SPAN receives no response the transaction is held in SAF until a
Point 4 After a response is received from the Card Issuer, SPAN formats and sends
1220 Financial Advice to the Acquirer Bank. The 1220 message contains
detailed information allowing the Acquirer Bank to settle the transaction
with the Retailer and the Card Issuer Bank.

Transaction Flows
Point 5 The Acquirer Bank must acknowledge the 1220 Financial Advice with the
If SPAN receives no response the transaction is held in SAF until a

Reconciliation Processing
Section 5 Reconciliation Processing
This section describes the various elements of SPAN reconciliation processing and settlement with
information specific to the SPAN Member Bank Interface, plus an overview of Bank Card Scheme
reconciliation/settlement.
Included in this section are,
• Definitions of terms specific to SPAN reconciliation.
• Description of the cutover process for both ATM and POS transactions.
• Examples of cutover date processing.
• Discussion of exceptions to the cutover process.
• Description of online reconciliation processing.
• Examples of online reconciliation processing.
• Description of net reconciliation position calculation.
• Description of offline reconciliation processing.
• Description of Bank Card Scheme reconciliation processing.
The Online Reconciliation subsection describes the accumulation of transaction data for financial
reconciliation. It includes detailed transaction examples for both ATM and POS, and describes the
financial reconciliation procedure through net reconciliation between SPAN and the Bank. A brief
description of offline reconciliation is also presented.
This section concludes with a description of the financial reconciliation/settlement for Bank Card
schemes. The SPAN Settlement and Reconciliation Procedures manual and Bank Card Scheme's own
documentation establish the procedures for financial reconciliation/settlement. This section is intended
to clarify the flow of reconciliation information.
5.1 Definitions
Acquirer Bank
The Bank that owns and controls the ATM Terminals used in the SPAN network. The ATM Acquirer
Bank is connected online to SPAN.
Bank
As referenced in this section, "Bank" means a participating financial institution in the SPAN network.
Card Issuer Bank
The Bank that issued the SPAN card used in the SPAN network for ATM or POS transactions. The
Card Issuer Bank is connected online to SPAN.
Card Scheme Acquirer Bank
The Bank that contractually agrees with the Retailer to capture and settle certain Bank Card Scheme
transactions. A Retailer must have a commercial relationship with only one Bank for each Bank Card
Scheme.
Card Scheme Bank
Synonym for Card Scheme Acquirer Bank.
Cutover
Cutover refers to the actual change of business date, i.e. the time when the current posting day ends and
the next posting day begins. SPAN has a separate cutover time for the ATM and POS networks: SPAN

cutover for POS occurs daily at 04:00; SPAN cutover for ATM occurs daily at 06:30. SPAN maintains
separate cutover times for POS and ATM for each Bank. Each Bank must cutover its POS and ATM
business day at least 30 minutes prior to the SPAN POS and ATM cutovers.
IBCS
Abbreviation for International Bank Card Scheme.
International Bank Card Scheme
SPAN has authorisation interfaces to International Bank Card Scheme networks (Visa and
MasterCard). This allows Visa and MasterCard Cards (Non-SPAN Cards) to be accepted at ATM and
POS terminals deployed throughout the Kingdom and Visa and MasterCard Card issued by SPAN
Member Banks to be accepted abroad. SPAN routes all Amex transactions to SAIB for onward routing.
See Section 8.
Online Retailer Advice
When the Card Issuer Bank and the Retailer Bank are not the same institution, SPAN sends an Online
Retailer Advice to the Retailer Bank for each SPAN Card POS transaction occurring at the Bank's
Retailer terminals. The Online Retailer Advice is a 1220 Financial Advice message requiring a 1230
Financial Advice Response. Online Retailer Advices must be retrievable by the Retailer Help Desk to
assist the Retailer with Cardholder questions or terminal reconciliation problems.
When the Card Issuer Bank and the Retailer Bank are the same institution, the Bank must accumulate
SPAN Card transaction activity using the 1210 Financial Transaction Response.
For approved International Bank Card Scheme transactions, SPAN sends a copy of the Online Retailer
Advice to the Card Scheme Acquirer Bank when it is not the same institution as the Retailer Bank.
SPAN also sends a copy of the terminal reconciliation message to the Card Scheme Acquirer Bank
when it is not the same institution as the Retailer Bank. Bank Card Scheme Acquirers must reconcile
the transaction activity to the terminal reconciliation messages and pass it on to their Card Scheme
clearing and settlement process.
Reconciliation
The term “reconciliation” is used to imply that an exchange of messages between two institutions
(acquirer and SPAN or card issuer and SPAN) to reach agreement on financial totals.
Reconciliation Calculation
Reconciliation is calculated on each SPAN business day for all authorised and completed SPAN Card
transactions that are logged that business day. Reconciliation is calculated separately for SPAN Card
ATM and POS activity.
Retailer Bank
The Bank that sponsors Retailers into the SPAN network and places SPAN POS terminals at the
Retailer location. The Retailer Bank is connected online to SPAN.
Retailer Reconciliation
Retailer Reconciliation for all SPAN POS activity is the responsibility of the Retailer Bank. The
Retailer Bank is responsible for settling SPAN POS activity with the Retailer. The Card Scheme
Acquirer Bank, which may be a different Bank than the Retailer Bank, is responsible for settling Card
Scheme activity with the Retailer. SPAN is not involved in Card Scheme settlement with the Retailers.
Settlement
Settlement refers to the transfer of funds to compensate each Bank for funds disbursed as a result of
SPAN Card transactions through SPAN. This process is related to the change of the SPAN business
day. Each Bank settles directly with SPAN.
SPAN Business Day
The SPAN business day begins at its cutover time and ends at its cutover the following day.

Terminal Reconciliation
The SPAN POS terminal reconciliation message notifies the Retailer Bank that the Retailer wants to
collect funds for the accumulated SPAN card activity. The Retailer Bank must credit the Retailer for
all SPAN card activity within two business days of receiving the SPAN reconciliation message. The
Retailer receives credit for other Bank Card Scheme transaction activity according to the commercial
agreement between the Retailer and the Card Scheme Acquirer Bank.
Retailer Banks must train Retailers on SPAN reconciliation policies and procedures. Each SPAN POS
terminal must reconcile periodically. SPAN recommends Retailers automatically reconcile terminals
once each business day. If the terminal does not reconcile on a daily basis, the Retailer Bank may need
to accumulate terminal activity to be able to reconcile the 1524/1525 messages (SPAN POS Terminal
Reconciliation Advices). Terminal reconciliation messages contain the individual card scheme totals
accumulated by the terminal and the individual card scheme totals accumulated by SPAN.
Incoming POS transactions from the Card Scheme Networks switches are not subject to terminal
reconciliation on SPAN. However they are included in the Card Issuer Totals in the 1520 Acquirer
Reconciliation Advice.
Incoming POS transactions from the CPS system are not subject to terminal reconciliation on SPAN,
even if they contain a valid SPAN terminal number (DE 41). However they are included in the Card
Issuer Totals in the 1520 Acquirer Reconciliation Advice.
5.2 Cutover Process

The cutover process occurs in three phases.
• Phase 1 – Bank POS cutover
• Phase 2 – Bank ATM cutover
• Phase 3 – SPAN cutover
The following section details a complete cutover cycle. This section highlights the key fields within
the messages.
5.2.1 Bank Cutovers

SPAN maintains separate cutover times for POS and ATM for each Bank. Bank cutover times must be
agreed upon between SPAN and the Bank for both POS and ATM prior to certification.
Each Bank must complete its business day ATM cutover at least 30 minutes prior to the SPAN ATM
network cutover. Each Bank's ATMs must be changed to the next business day, cash in each at ATM
counted and replenished, and all deposits removed from the machines prior to 0600 each day. Each
Bank's ATM transaction log file should be cutover before running settlement reports. After cutover is
completed, no more ATM transaction activity can be logged with the previous business day.
SPAN is responsible for changing the business day for all POS terminals attached to SPAN. Each Bank
must complete its business day POS cutover at least 30 minutes prior to the SPAN POS network
cutover. Each Bank's POS transaction log file should be cut over before running POS settlement
reports. After POS cutover is complete, no more POS transaction activity can be logged with the
previous business day.
To initiate cutover, the Bank sends a 1804 cutover message to SPAN for POS and a separate 1804
cutover message for ATM. The cutover message contains the product identifier (04 for POS and 00 for
ATM) in the SPAN Header and the next Bank business date in the Reconciliation Date (DE 28).
All 1200 ATM requests initiated by the Bank after the ATM cutover must contain the new calendar
date in the Capture Date (DE 17);
Since all POS terminals are connected to SAMA, there are no POS requests initiated by the Bank.
If SPAN does not receive the 1804 cutover message for each Bank within agreed time for POS or
ATM, SPAN initiates the cutover internally, but does not send an 1804 to the Bank.

5.2.2 SPAN Cutovers

SPAN informs member banks of its cutovers by sending 1804 cutover messages to the Banks with the
product identifier in the SPAN Header set to “04” for POS and “00” for ATM and the new
Reconciliation Date (DE 28). A cutover message is sent for POS and a separate cutover message is sent
for ATM.
SPAN has a separate cutover time for the ATM and POS networks (these timings apply during
weekends and holidays).
• SPAN cutover for POS occurs daily at 04:00.
• SPAN cutover for ATM occurs daily at 06:30.
All 1200 ATM and POS requests sent from SPAN to the Banks after SPAN's ATM and POS cutover
contain SPAN’s new business day in the Reconciliation Date (DE 28). The same occurs for the Online
Retailer Advices sent to the Retailer Bank.
All 1200 POS requests initiated by SPAN after SPAN POS cutover contain the new SPAN business
date in the Capture Date (DE 17).
5.2.3 Date Processing

Three dates are contained in the various messages that constitute a transaction:
• Local Transaction Date and Time (DE 12)
The calendar date and time that the transaction takes place at the card acceptor location and is
set by the initiator of the first message.
• Reconciliation Date (DE 28)
The date for which financial totals are reconciled between member banks and SPAN, i.e. the
SPAN business date.
• Capture Date (DE 17)
The date when the transaction was processed by the acquirer/retailer.
The Local Transaction Date and Time remains consistent throughout a transaction.
The use of, and appropriate values for, Reconciliation Date (DE 28) and Capture Date (DE 17) are
shown in the following tables.
ATM Transactions
No Msg Originator Destination Reconciliation Date Capture Date
Type
(DE 28) (DE 17)
1 1200 Acquirer SPAN Set to Acquirer’s business
date
2 1200 SPAN Issuer Set to SPAN’s business Set to Acquirer’s business
date date
3 1210 Issuer SPAN Echo from SPAN’s 1200; Echo from SPAN’s 1200;
i.e. SPAN’s business date i.e. Acquirer’s business
date
4 1210 SPAN Acquirer Set to SPAN’s business Echo from Acquirer’s
date 1200; i.e. Acquirer’s
business date
• Both Retailer and Card Issuer Bank will settle on the Reconciliation Date provided by SPAN
in the 1210 and 1200 messages respectively.
5.2.4 POS Connected to SAMA (Retailer Bank and Issuer Bank are the same)
Type
(DE 28) (DE 17)
1 - EFT POS SPAN
terminal
2 1200 SPAN Issuer Set to SPAN’s business Set to SPAN’s business
date date
i.e. SPAN’s business date i.e. SPAN’s business date
4 - SPAN EFT POS Set to SPAN’s business
terminal date
• Settlement between the Card Issuer and SPAN will be based on the Reconciliation Date
provided in the 1200 message by SPAN.
• Settlement with the merchant will be based on terminal reconciliation messages from the
terminal.
• No notification is required as Retailer Bank and Issuer Bank are the same.
5.2.5 POS Connected To SAMA (Retailer Bank and Issuer Bank are different)
Type
(DE 28) (DE 17)
1 1200 EFT POS SPAN
terminal
2 1200 SPAN Issuer Set to SPAN’s business Set to SPAN’s business
date date
4 1210 SPAN EFT POS Set to SPAN’s business
terminal date
5 1220 SPAN Retailer Bank Set to SPAN’s business Set to SPAN’s business
date date
6 1230 Retailer Bank SPAN Echo from SPAN’s 1220; Echo from SPAN’s 1220;
• Both Retailer and Card Issuer Bank will settle on the Reconciliation Date provided by SPAN
in the 1210 and 1200 messages respectively.
• Settlement with the merchant will be based on terminal reconciliation messages from the
terminal.

5.3 Date Processing Examples

For settlement purposes, a transaction may fall into different SPAN and Bank business days. The
relationship of key date fields to SPAN and the Bank's business day is explained in the examples
below.
The cutover examples detail two banks, Bank A and Bank B. The cutover times for the Banks and
SPAN are as listed in the table below.
Entity POS Cutover Time ATM Cutover Time
SPAN 0400 0630
Bank A 2000 2000
Bank B 0330 0600
In these examples, today's calendar date is Tuesday, 20th August. SPAN's business date is Monday,
19th August.
The following table illustrates the cutover times across three days.
Monday, 19th August Tuesday, 20th August Wednesday, 21st August
POS 0400 0400

SPAN2
ATM 0630 0630
POS 2000 2000

BANK A
ATM 2000 2000
POS 0330 0330

BANK B
ATM 0600 0600
The following table shows the business dates used by Bank A and Bank B relative to the SPAN
business date.
Monday, 19th August Tuesday, 20th August Wednesday, 21st August
SPAN SPAN +1 SPAN SPAN +1 SPAN

POS
BANK A SPAN SPAN +1 SPAN SPAN +1 SPAN
ATM
SPAN SPAN SPAN

POS
BANK B SPAN SPAN SPAN
ATM
Bank Cutover; SPAN2 Cutover; SPAN2 Date + 1
The key points to note from the above diagram is that up until the Bank cuts over the SPAN business
day is the same as that of the Bank. After the Bank cutover, the Bank's business date is one day ahead
of SPAN's business date until SPAN cuts over to the new business day.
The following examples provide some examples of the effect of the various business dates involved in
any transaction i.e. Bank A, Bank B and SPAN.

5.3.1 POS Transactions (POS Terminals Connected to SAMA)

POS Transaction 1 – Monday 19th August, 1900 hours
Cardholder Bank A (Issuer) Bank A 19th August
POS Terminal Bank B (Retailer) Bank B 19th August
Transaction Purchase SPAN 19th August

Type
(DE 28) (DE 17)
1 1200 EFT POS SPAN
terminal
2 1200 SPAN Issuer 19th August 19th August
(SPAN business date) (SPAN business date)
th
3 1210 Issuer SPAN 19 August 19th August
(SPAN business date (SPAN business date
echoed from SPAN’s echoed from SPAN’s
1200 message) 1200 message)
4 1210 SPAN EFT POS 19th August
terminal
(SPAN business date)
5 1220 SPAN Retailer 19th August 19th August
Bank
(SPAN business date) (SPAN business date
inserted by SPAN)
6 1230 Retailer SPAN 19th August 19th August
Bank
Bank A POS Cutover – Monday 19th August, 2000 hours

At 2000 hours Bank A initiates a cutover by sending an 1804 request with the following field values to
SPAN.
• Function Code – set to “821”
• Product Identifier – set to “04”
SPAN responds to the Bank with a 1814 response message acknowledging receipt of the cutover
request.
The business dates of the three parties are as follows.
• Bank A – 20th August
• Bank B – 19th August
• SPAN – 19th August
POS Transaction 2 – Monday 19th August, 2300 hours



Type
(DE 28) (DE 17)
1 1200 EFT POS SPAN
terminal
inserted by SPAN)
3 1210 Issuer SPAN 19th August 19th August
terminal
Bank
inserted by SPAN)
Bank
POS Transaction 3 – Tuesday 20th August, 0300 hours
Cardholder Bank B (Issuer) Bank A 20th August
POS Terminal Bank A (Retailer) Bank B 19th August

Type
(DE 28) (DE 17)
1 1200 EFT POS SPAN
terminal
inserted by SPAN)


Type
(DE 28) (DE 17)
th
4 1210 SPAN EFT POS 19 August
terminal
Bank
inserted by SPAN)
Bank
Bank B POS Cutover – Tuesday 20th August, 0330 hours

At 0330 hours Bank B initiates a cutover by sending an 1804 request with the following field values to
SPAN.
request.

Type
(DE 28) (DE 17)
1 1200 EFT POS SPAN
terminal
inserted by SPAN)
echoed from SPAN’s 1200 echoed from SPAN’s 1200
message) message)


Type
(DE 28) (DE 17)
th
4 1210 SPAN EFT POS 19 August
terminal
Bank
inserted by SPAN)
Bank
message) message)

Type
(DE 28) (DE 17)
1 1200 EFT POS SPAN
terminal
inserted by SPAN)
message) message)
terminal
5 1220 SPAN Retailer Bank 19th August 19th August
inserted by SPAN)
6 1230 Retailer Bank SPAN 19th August 19th August
message) message)

SPAN POS Cutover – Tuesday 20th August, 0400 hours

At 0400 hours SPAN initiates POS cutover by sending an 1804 request with the following field values
to all member banks.
Each Bank must respond to SPAN with a 1814 response message acknowledging receipt of the cutover
request.
Note: SPAN ensures that any transactions occurring during the cutover process are posted to the new
SPAN business day.

Type
(DE 28) (DE 17)
1 1200 EFT POS SPAN
terminal
inserted by SPAN)
message) message)
terminal
5 1220 SPAN Retailer Bank 20th August 20th August
inserted by SPAN)
6 1230 Retailer Bank SPAN 20th August 20th August
message) message)

Note: If the Card Issuer and Retailer Banks are the same then no notification (1220 Financial Advice)
and notification response (1230 Financial Advice Response) messages are required. Therefore, in the
above examples rows 5 and 6 should be omitted.
5.3.2 ATM Transactions

ATM Transaction 1 – Monday 19th August, 1930 hours
ATM Terminal Bank A (Acquirer) Bank B 19th August
Transaction Withdrawal SPAN 19th August

Type
(DE 28) (DE 17)
1 1200 Acquirer SPAN 19th August
(Acquirer business date
inserted by Acquirer)
(SPAN business date set (Acquirer business date
by SPAN) copied from Acquirer’s
1200)
(SPAN business date (Acquirer business date
4 1210 SPAN Acquirer 19th August 19th August
by SPAN) echoed from Acquirer’s
1200)
Bank A ATM Cutover – Monday 19th August, 2000 hours

At 2000 hours Bank A initiates a cutover by sending an 1804 request with the following field values to
SPAN.
request.
ATM Transaction 2 – Tuesday 20th August, 0550 hours



Type
(DE 28) (DE 17)
1200)
1200)
ATM Terminal Bank B (Acquirer) Bank B 19th August

Type
(DE 28) (DE 17)
1200)


Type
(DE 28) (DE 17)
th
4 1210 SPAN Acquirer 19 August 19th August
1200)
Bank B ATM Cutover – Tuesday 20th August, 0600 hours

At 0600 hours Bank B initiates a cutover by sending an 1804 request with the following field values to
SPAN.
request.

Type
(DE 28) (DE 17)
1200)
by SPAN) echoed form Acquirer’s
1200)


ATM Terminal SAMA (Acquirer) Bank B 20th August

Type
(DE 28) (DE 17)
(SPAN business date set (Acquirer, which is
by SPAN) SAMA, business date)
SPAN ATM Cutover – Tuesday 20th August, 0630 hours

At 0630 hours SPAN initiates ATM cutover by sending an 1804 request with the following field values
to all member banks.
Each Bank must respond to SPAN with a 1814 response message acknowledging receipt of the cutover
request.
Note: SPAN ensures that any transactions occurring during the cutover process are posted to the new
SPAN business day.
ATM Terminal SAMA (Acquirer) Bank B 20th August

Type
(DE 28) (DE 17)
(SPAN business date set (Acquirer, which is
by SPAN) SAMA, business date)


Type
(DE 28) (DE 17)
th
2 1210 Issuer SPAN 20 August 20th August


Type
(DE 28) (DE 17)
1200)
1200)
5.4 Exception Conditions During Cutover

In any system, processes should exist to handle exception conditions that may occur, especially in an
online transaction processing scenario such as the SPAN network. SPAN recognises that line failures
or timeouts may occur when either the Bank or SPAN is attempting to cutover. To assure the cutover
process, SPAN has three exception handling mechanisms.
1. The Bank would notify SPAN by re-sending the cutover message using the 1824 advice or 1825
advice repeat message. SPAN would acknowledge all standing cutover messages with one 1834.
2. SPAN has a Bank cutover time defined for each Bank in the network. If the Bank fails to cutover
within a SPAN defined period after the designated time, SPAN forces the Bank cutover.
Note: The Bank cannot decline cutover messages. In the event that a cutover message is not
completed normally, SPAN places the cutover message in the Store-And-Forward (SAF) file. The
SPAN system will make repeated attempts to deliver the cutover message successfully.

3. In the highly unlikely event that a cutover message is rejected due to formatting errors in the
message content, continuous delivery processing is suspended and SPAN operations personnel is
notified of the problem.
5.5 Online Reconciliation

5.5.1 Introduction
After the Bank’s and SPAN have cutover and the five minute buffer window (to allow all prior
transactions to complete) has elapsed, online reconciliation occurs based on the SPAN cutover times.
As soon as the cutover message is sent to the Bank, SPAN begins forwarding transactions with the new
POS or ATM business day. The totals that are sent in the reconciliation messages do not reflect any
transactions that have occurred during the new business day.
SPAN accomplishes online reconciliation for both POS and ATM via the exchange of two separate sets
of 1520 Acquirer Reconciliation Advice and 1522 Card Issuer Reconciliation Advice messages.
1520 ATM 1522 ATM
1530 ATM 1532 ATM Acquirer Bank
Card Issuer Bank SPAN or
1520 POS 1522 POS RetailerBank
1530 POS 1532 POS
5.5.2 Reconciliation Messages

SPAN / Member Bank Reconciliation
The reconciliation messages are named from a SPAN perspective of the reconciliation process.
For POS transactions,
• The 1520 Acquirer Reconciliation Advice is sent from SPAN (which acquires the transaction
on behalf of the Bank) to the Card Issuer Bank.
• The 1522 Card Issuer Reconciliation Advice is sent from SPAN (which routes the message on
behalf of the Bank) to the Retailer Bank.
For ATM transactions,
• The 1520 Acquirer Reconciliation Advice is sent from SPAN to the Card Issuer Bank advising
the Bank of the Acquirer Bank totals.
• The 1522 Card Issuer Reconciliation Advice is sent from SPAN to the Acquirer Bank advising
the Bank of the Card Issuer totals.
In both the 1520 and 1522 messages SPAN calculates the reconciliation total in the Net Reconciliation
Amount (DE 97) using the following formula.
Where,
Credit Totals = Amount Credits + Reversal Amount Credits + Chargeback Amount Credits
Debit Totals = Amount Debits + Reversal Amount Debits + Chargeback Amount Debits
Further details of the meanings of these fields are explained in Section 3.
After SPAN sends the reconciliation advices, it waits for a response message (1530 Acquirer
Reconciliation Advice Response or 1532 Card Issuer Reconciliation Advice Response) indicating
agreement or otherwise of the reconciliation amounts.
The burden of reconciliation lies with the Member Banks. It is the individual Bank's responsibility to
compare its reconciliation totals to its transaction details. A Bank is in balance when its calculated net
reconciliation amount agrees with SPAN's Net Reconciliation Amount (DE 97) for each of the 1520
Acquirer Reconciliation Advice and 1522 Card Issuer reconciliation Advice messages received. The

Bank returns its calculated net reconciliation amount in DE 97 of the 1530 Acquirer Reconciliation
Response or the 1532 Card Issuer Reconciliation Response. In both message types, an in-balance
reconciliation condition is acknowledged by a value of 500 in the Action Code (DE 39). For other
acceptable Action Code values that may be used in the SPAN network and their meanings, see the
Field Description for Action Code (DE 39). If the Action Code indicates an out-of-balance condition,
the Bank inserts its view of the mismatched totals in its response.
POS Terminal / SPAN / Retailer Bank Reconciliation
In addition to the 1520 and 1522 advice messages described above, SPAN also receives daily 1524
Terminal Reconciliation Advices from the POS terminals. These contain a terminal's view of its totals.
They are sent automatically by each terminal once each business day.
If SPAN agrees with a terminal's totals in DE 124 SPAN POS Terminal Reconcile Total, it forwards
the 1524 advice to the Retailer Bank to advise the Bank of the terminal's totals. If SPAN does not agree
with the terminal's totals, it inserts its view of the terminal's total in DE 127 SPAN POS SPAN
Reconcile Total before forwarding the advice.
After SPAN forwards a 1524 Terminal Reconciliation Advice (or its 1525 repeat), it waits for a 1534
Terminal Reconciliation Advice Response to acknowledge receipt of the reconciliation advice.
If a terminal does not send a 1524 Terminal Reconciliation Advice, a Retailer Bank can use the
Terminal Management System to ask SPAN to instruct the terminal the next time it connects to send a
1524 Terminal Reconciliation Advice. This is known as a Force Reconciliation. Alternatively, if a
terminal does not, or can not, contact SPAN, a Retailer Bank can use the Terminal Management
System to ask SPAN to send SPAN's view of the terminal's totals. This is known as a Request
Reconciliation. (See section 5.5.7 for more details.)
POS Terminal / SPAN / Card Scheme Bank Reconciliation
SPAN also forwards 1524 Terminal Reconciliation Advices to the Card Scheme Banks. However,
these differ from the advices sent to the Retailer Banks in that DE 124 SPAN POS Terminal Reconcile
Total and DE 127 SPAN POS SPAN Reconcile Total (if present) contain only the totals for the Card
Scheme or Schemes that the Card Scheme Bank processes for the Retailer.
After SPAN forwards a 1524 Terminal Reconciliation Advice (or its 1525 repeat), it waits for a 1534
Terminal Reconciliation Advice Response to acknowledge receipt of the reconciliation advice.
5.5.3 Reconciliation Calculation Rules

In general, the Message Type Identifier (MTI), Original MTI (if a Reversal), positions 1-2 of DE 3
Processing Code, DE 24 Function Code, DE 39 Action Code and the card product (SPAN or an
International Bank Card Scheme) are the criteria used to decide whether a transaction is accumulated
against reconciliation totals, and if so, against which Card Scheme record and reconciliation fields. The
use of these criteria is explained below.
Only approved or accepted transactions are accumulated against reconciliation totals; declined or
rejected or failed transactions are not accumulated. Note that this also applies to advices of declined
transactions sent to SPAN by the POS terminal and passed on to the Retailer Bank. Hence the decision
to accumulate a transaction must be made when a response is sent or received, not a request.
In ISO 8583:1993, the reconciliation field a transaction applies does not depend on whether a message
is being exchanged with an acquirer or an issuer. Hence, an approved purchase Financial Transaction
made using a SPAN card is counted against DE 76 Number Debits and added to DE 88 Amount Debits
in both the 1520 Acquirer Reconciliation Advice sent to the Card Issuer Bank and the 1522 Card Issuer
Reconciliation Advice sent to the Retailer / Acquirer Bank.
The reconciliation fields present in a 1520 Acquirer Reconciliation Advice, a 1522 Card Issuer
Reconciliation Advice, a 1524 Terminal Reconciliation Advice and their repeats and responses are
defined in Section 2. The rules for the inclusion of a transaction in a particular reconciliation field are
stated in the description of the reconciliation field in Section 3.

SPAN card transactions are accumulated against the standard ISO 8583:1993 reconciliation fields.
International Bank Card Scheme transactions are accumulated against the SPAN-specific reconciliation
subfields of DE 126 Bank Card Scheme Totals Information. POS terminal transactions are accumulated
against the SPAN-specific reconciliation subfields of DE 124 SPAN POS Terminal Reconcile Total
and DE 127 SPAN POS Terminal Reconcile Total.
ISO 8583:1993 Standard Reconciliation Calculations
Table 5-1 and Table 5-2 show the standard ISO 8583:1993 reconciliation fields used for a range of
Message Types and Processing Codes. They show which standard ISO reconciliation amount and
number fields a range of transactions are accumulated against. (These are shown as a general guide.
The Message Types, Processing Codes and reconciliation fields specifically used by SPAN are
described in subsequent tables.)
ISO 8583:1993 Standard Reconciliation Amount Calculations
MTI Original Processing Add Data To Data Element
MTI Code Element
12xx – 00-19 DE 88 Amount Debits
12xx – 20-29 DE 86 Amount Credits
14x0 12xx 00-19 DE 4 Transaction DE 87 Reversal Amount Credits
14x0 12xx 20-29 Amount DE 89 Reversal Amount Debits
14x2 – 00-19 DE 105 Chargeback Amount Credits
14x2 – 20-29 DE 106 Chargeback Amount Debits
Table 5-1 Reconciliation Amount Fields Used In ISO 8583:1993 Standard
ISO 8583:1993 Standard Reconciliation Count Calculations

MTI Original Processing Add To Data Element
MTI Code
11xx – 00-29 DE 81 Number Authorisations
11xx – 30-39 DE 80 Number Inquiries
12xx – 00-19 DE 76 Number Debits
12xx – 20-29 Numeric value DE 74 Number Credits
14x0 12xx 00-19 of 1 DE 75 Reversal Number Credits
14x0 12xx 20-29 DE 77 Reversal Number Debits
14x2 – 00-19 DE 107 Chargeback Number Credits
14x2 – 20-29 DE 108 Chargeback Number Debits
Table 5-2 Reconciliation Count Fields Used in ISO 8583:1993 Standard
SPAN Card Reconciliation Calculations

The reconciliation data is carried in the 1520 Acquirer Reconciliation Advices and 1522 Card Issuer
Reconciliation Advices.
Table 5-3 and Table 5-4 show the reconciliation fields used for the specific subset of Message Types
and Processing Codes used for SPAN card transactions. These transactions are accumulated against
normal ISO 8583:1993 reconciliation fields.

SPAN Card Reconciliation Amount Calculations

MTI Code + Element
Function
Code
1200 – 00, 01, 09 DE 88 Amount Debits
1200 – 20 DE 86 Amount Credits
1220 – 00, 01, DE 88 Amount Debits
02, 09
1220 – 20, 22 DE 86 Amount Credits
1420 1200 00, 01, 09 DE 87 Reversal Amount Credits
DE 4 Transaction
1420 1200 20 Amount DE 89 Reversal Amount Debits
1422 – 00, 01, 09 DE 105 Chargeback Amount Credits
1422 – 00, 01, 09 DE 106 Chargeback Amount Debits
+ 4901
1422 – 20 DE 106 Chargeback Amount Debits
1422 – 20 DE 105 Chargeback Amount Credits
+ 4901
Table 5-3 Reconciliation Amount Fields Used for SPAN Card Transactions
Notes
1. A 1422 Chargeback Advice Reversal with a DE 24 Function Code of 490 is a Chargeback
Reversal. There are no explicit ISO 8583:1993 reconciliation fields for Chargeback Reversals,
hence they are added to the opposite Chargeback Amount fields.
SPAN Card Reconciliation Count Calculations
MTI Code +
Function
Code
1100 – 00, 90 DE 81 Number Authorisations
1120 - 00, 90 DE 81 Number Authorisations
1200 – 00, 01, 09 DE 76 Number Debits
1200 – 20 DE 74 Number Credits
1200 – 31, 38 DE 80 Number Inquiries
1220 – 00, 01, Numeric value DE 76 Number Debits
02, 09 of 1
1220 – 20, 22 DE 74 Number Credits
1420 1100 00, 90 Not Counted2
1420 1200 00, 01, 09 DE 75 Reversal Number Credits
1420 1200 20 DE 77 Reversal Number Debits
1422 – 00, 01, 09 DE 107 Chargeback Number Credits

SPAN Card Reconciliation Count Calculations

MTI Code +
Function
Code
1422 – 00, 01, 09 DE 108 Chargeback Number Debits
+ 4901
1422 – 20 DE 108 Chargeback Number Debits
1422 – 20 DE 107 Chargeback Number Credits
+ 4901
Table 5-4 Reconciliation Count Fields Used for SPAN Card Transactions
Notes
Reversal. There are no explicit ISO 8583:1993 reconciliation fields for Chargeback Reversals,
hence they are counted in the opposite Chargeback Number fields.
2. DE 90 Reversal Number Authorisations is not used by SPAN, hence reversals of Authorisations
are not counted in reconciliation totals.
International Bank Card Scheme Reconciliation Calculations
The reconciliation data is carried in the 1520 Acquirer Reconciliation Advices and 1522 Card Issuer
Reconciliation Advices in subfields of DE 126 Bank Card Scheme Totals Information.
Table 5-5 and Table 5-6 show the reconciliation subfields used for the specific subset of Message
Types and Processing Codes used for International Bank Card Scheme transactions. These transactions
are accumulated against reconciliation subfields of the SPAN-specific field DE 126 Bank Card Scheme
Totals Information.
International Bank Card Scheme Reconciliation Amount Calculations
MTI Code + Element
Function
Code
1200 – 00, 01 DE 126.8 Amount Debits
1220 – 00, 01 DE 126.8 Amount Debits
1220 – 20 DE 126.6 Amount Credits
1420 1200 00, 01 DE 126.7 Reversal Amount Credits
1420 1220 20 DE 126.9 Reversal Amount Debits
DE 4 Transaction
14221 – 00, 01 Amount DE 126.6 Amount Credits
1
1422 – 00, 01 DE 126.9 Reversal Amount Debits
+ 4902
14221 – 20 DE 126.8 Amount Debits
1
1422 – 20 DE 126.7 Reversal Amount Credits
+ 4902
Table 5-5 Reconciliation Amount Fields Used for IBCS Transactions

Notes
1. There are no DE 126 reconciliation fields for Chargebacks, hence they are added to the
appropriate Amount fields.
Reversal. There are no DE 126 reconciliation subfields for Chargeback Reversals, hence they
are added to the opposite Amount subfields.
International Bank Card Scheme Reconciliation Count Calculations
MTI Code +
Function
Code
1100 – 00, 90 DE 126.10 Number Authorisations
1120 - 00, 90 DE 126.10 Number Authorisations
1200 – 00, 01 DE 126.3 Number Debits
1200 – 31 DE 126.5 Number Inquiries
1220 – 00, 01 DE 126.3 Number Debits
1220 – 20 DE 126.1 Number Credits
1420 1100 00, 90 Not Counted
Numeric value
1420 1200 00, 01 of 1 DE 126.2 Reversal Number Credits
1420 1220 20 DE 126.4 Reversal Number Debits
1
1422 – 00, 01 DE 126.1 Number Credits
14221 – 00, 01 DE 126.4 Reversal Number Debits
+ 4902
14221 – 20 DE 126.3 Number Debits
14221 – 20 DE 126.2 Reversal Number Credits
+ 4902
Table 5-6 Reconciliation Count Fields Used for IBCS Transactions
Notes
1. There are no DE 126 reconciliation subfields for Chargebacks, hence they are added to the
appropriate Number subfields.
Reversal. There are no DE 126 reconciliation subfields for Chargeback Reversals, hence they
are counted in the opposite Number subfields.
POS Terminal Reconciliation Calculations
The reconciliation data is carried in 1524 Terminal Reconciliation Advices in DE 124 SPAN POS
Terminal Reconcile Total and, if required, in DE 127 SPAN POS SPAN Reconcile Total. The structure
and content of DE 124 and DE 127 are defined in Section 3.
The rules for the inclusion of a transaction in a particular reconciliation subfield are stated below.
Table 5-7 and Table 5-8 show the reconciliation subfields used for the specific subset of Message
Types and Processing Codes used for SPAN and International Bank Card Scheme transactions. These
transactions are accumulated against reconciliation subfields of SPAN-specific fields DE 124 SPAN

POS Terminal Reconcile Total by the POS terminal and DE 127 SPAN POS SPAN Reconcile Total by
SPAN.
There are separate totals records in DE 124 and DE 127 for each Card Scheme, including one for
SPAN. Each record contains subfields for the different types of Amounts and Counts captured. The
same subfields occur for each Card Scheme record.
The reconciliation advices sent to a Retailer Bank contain all the Card Scheme records. The
reconciliation advices sent to a Card Scheme Bank contain only the Card Scheme records for the
scheme or schemes that the Card Scheme Bank processes for the Retailer.
POS Terminal Reconciliation Amount Calculations
MTI Original Processing Add Data To Data Element1
MTI Code Element
1200 – 00, 01, 09 DE 124.4 / 127.4 Debit Amount
1200 – 20 DE 124.6 / 127.6 Credit Amount
1220 – 00, 01, 09 DE 124.4 / 127.4 Debit Amount
1220 – 20 DE 4 Transaction DE 124.6 / 127.6 Credit Amount
1420 2
1200 00, 01, 09 Amount DE 124.6 / 127.4 Credit Amount
14202 1200 20 DE 124.4 / 127.4 Debit Amount
2
1420 1220 00, 01, 09 DE 124.6 / 127.6 Credit Amount
2
1420 1220 20 DE 124.4 / 127.4 Debit Amount
MTI Original Processing Add3 Additional To Data Element
MTI Code Data Element
1200 – DE 4 Transaction
01 DE 124.8 / 127.8 Cash Advance Amount
1220 – Amount
1200 – DE 54 Additional
09 DE 124.7 / 127.7 Cash Back Amount
1220 – Amounts4
MTI Original Processing Subtract5 From Data Element

MTI Code Additional Data
Element
1420 1200 DE 4 Transaction
01 DE 124.8 / 127.8 Cash Advance Amount
1420 1220 Amount
1420 1200 DE 54 Additional

09 DE 124.7 / 127.7 Cash Back Amount
1420 1220 Amounts4
Table 5-7 Reconciliation Amount Fields Used by POS Terminal
Notes
1. The POS terminal sends its totals in the subfields of DE 124; SPAN sends its totals (if required
to do so) in the subfields of DE 127.
2. There are no DE 124 or DE 127 reconciliation subfields for Reversals, hence they are added to
the opposite Amount subfields.
3. Cash Advance and Cash Back transactions must be applied against two Amount subfields:
added to the normal Debit Amount subfield and also added to an additional, transaction-specific
subfield. (Note that the amounts applied may be different: see below.)
4. The cashback amount of Cash Back transactions applied to the DE 124.8 / 127.8 Cash Back
Amount subfield is taken from DE 54 Additional Amounts, not from DE 4 Transaction Amount.
5. Reversals of Cash Advance and Cash Back transactions must be applied to two Amount
subfields: added to the normal Credit Amount subfield and also subtracted from an additional,
transaction-specific subfield. (There are no DE 124 or DE 127 reconciliation subfields for Cash
Advance Reversals or Cash Back Reversals, hence the transactions must be subtracted from the
transaction-specific subfield.)
POS Terminal Reconciliation Count Calculations
MTI Code
1100 – 00, 09, 20, DE 124.9 / 127.9 Authorisations Count
90
1120 - 00, 09, 20, DE 124.9 / 127.9 Authorisations Count
90
1200 – 00, 01, 09 DE 124.3 / 127.3 Debit Count
1200 – 20 DE 124.5 / 127.5 Credit Count
Numeric value
1220 – 00, 01, 09 DE 124.3 / 127.3 Debit Count
of 1
1220 – 20 DE 124.5 / 127.5 Credit Count
14201 1100 00, 90 Not Counted1
14201 1200 00, 01, 09 DE 124.5 / 127.5 Credit Count
1220
14201 1200 20 DE 124.3 / 127.3 Debit Count
1220
Table 5-8 Reconciliation Count Fields Used by POS Terminal
Notes
1. There are no DE 124 or DE 127 reconciliation subfields for Reversals, hence reversed financial
transactions are added to the opposite Count fields and reversed Authorisations are not counted.
There is a special reconciliation rule used if a POS terminal does not receive a response. This rule helps
the POS terminal find out what happened to the timed-out request so it can adjust its totals. Note that
this rule only applies to the POS terminal totals in DE 124 and DE 127 of a 1524: it does not apply to
the standard ISO totals sent in a 1520 or 1522. The special rule is described below.
If the POS terminal sends an 1100 Authorisation Request or 1200 Financial Transaction Request to
SPAN and receives no response within its predefined time limit, the terminal must consider the
transaction as failed and send a 1420 Reversal Advice to SPAN to indicate it timed-out the request. The
terminal does not apply the failed transaction to its totals.
For reversals generated on timeout, the message originator shall populate this data element with the
current SPAN Business date. However, in some circumstances i.e. transaction occurring during cutover
may result in SPAN returning an updated business date. This is the actual date that must be used.
When SPAN send back a 1430 Advice Response, the DE 39 Action Code in it indicates whether (a)
SPAN received the original request and it was approved; (b) SPAN never received the original (or no
longer has a record of receiving it); or (c) SPAN received the original request and it was declined.
In case (a), an Action Code of 400 means the original request was seen by SPAN and approved and the
reversal has been accepted. In this case the original transaction must be applied retrospectively to the
POS reconciliation totals and well as applying the reversal to the totals.

In case (b), an Action Code of 480 means the original request was never received by SPAN. In case
(c), an Action Code of 481 means the original was received, but was declined. The reversal has been
rejected by SPAN. In both these cases, neither the original transaction, nor the rejected reversal, is
applied to the reconciliation totals.
Note that in all three cases, the reversal has been acknowledged by SPAN so, even if rejected, it must
not be resent by the terminal.
5.5.4 Reconciliation Calculations

This section expands on and clarifies some of the cases summarised in section 5.5.3. Note that it does
not describe every possible transaction. Instead, the rule tables in section 5.5.3 should be used to decide
what reconciliation processing is required for the specific combination of Message Type, Processing
Code, Action Code and card product involved in the transaction.
The SPAN reconciliation amounts for ATM and POS transactions are calculated as follows.
Transaction ATM POS
Card Issuer Acquirer Card Issuer Retailer Bank
Withdrawal Debit Debit
Reversal Credit Credit
Chargeback Credit Credit
Chargeback Reversal Debit Debit
Purchase Debit Debit
Cash Advance Debit Debit
Purchase with Cash Back Debit Debit
Refund Credit Credit
Purchase Reversal Credit Credit
Cash Advance Reversal Credit Credit
Purchase with Cash Back Credit Credit
Reversal
Refund Reversal Debit Debit
Chargeback (Purchase) Credit Credit
Chargeback (Refund) Debit Debit
Chargeback Reversal Debit Debit
(Purchase)
Chargeback Reversal Credit Credit
(Refund)
CPS Debit Adjustment Debit Debit Debit Debit
CPS Credit Adjustment Credit Credit Credit Credit
Table 5-9 ATM and POS Transaction Impact on Bank Totals
For further details of the ATM and POS reconciliation process refer to section 0 above and Table 5-12,
Table 5-13 and Table 5-14 below.
When a POS terminal is reconciled, the terminal reconciliation totals are provided by card type. The
first card type is for SPAN Cards, followed by International Bank Card Scheme Cards (Non-SPAN
Cards). Each card type is listed by name, SPAN, MasterCard, Visa and so on with the total counts and
amounts for each card type included as appropriate.
5.5.5 ATM Net Reconciliation Calculation

The Card Issuer and Acquirer Banks must settle the transactions with SPAN based on the date in the
Reconciliation Date (DE 28) of the Financial Request/Response message. Only approved withdrawals,
reversals, partial reversals and chargebacks have a financial impact on the SPAN ATM reconciliation
process.
Banks accumulate reconciliation totals from the perspective of both the Card Issuer and the Acquirer.
• As Card Issuer, the Bank accumulates transaction counts and amounts to verify the 1520
Acquirer Reconciliation Advice received from SPAN.
• As an Acquirer, the Bank accumulates transaction counts and amounts to verify the 1522
Issuer Reconciliation Advice received from SPAN.
Only the following approved transactions affect the ATM net reconciliation calculation.
• Cash withdrawals/Cash advance
• Full reversals
• Partial reversals
• Full chargebacks
• Partial chargebacks
• CPS adjustments
Table 5-10 shows the impact of these transactions from the perspective of both Card Issuer and
Acquirer.
Transaction Type Card Issuer Bank Acquirer Bank
(1520 Acquirer Reconciliation (1522 Card Issuer
Advice) Reconciliation Advice)
Withdrawal Increase debit count Increase debit count
Cash Advance Increase debit amount Increase debit amount
Full Reversal Increase reversal credit count Increase reversal credit count
Increase reversal credit amount Increase reversal credit amount
Partial Reversal This requires a two step approach; a full reversal followed by a
withdrawal for the correct amount.
Increase reversal credit count Increase reversal credit count
Increase debit count Increase debit count
Increase debit amount Increase debit amount
Full Chargeback Increase chargeback credit count Increase chargeback credit count
Increase chargeback credit Increase chargeback credit
amount amount
Partial Chargeback This requires a two-step approach; a full chargeback followed by a
withdrawal for the correct amount.

Transaction Type Card Issuer Bank Acquirer Bank

Increase chargeback credit count Increase chargeback credit count
amount amount
Increase debit count Increase debit count
CPS Debit Adjustment Increase debit count Increase debit count
CPS Credit Increase credit count Increase credit count
Adjustment
Increase credit amount Increase credit amount
Table 5-10 ATM Transaction Impact on Card Issuer Bank and Acquirer Bank Totals
Table 5-11 presents the method by which ATM activity is accumulated for both Card Issuer Banks
(1520 Acquirer Reconciliation Advice) and Acquirer Banks (1522 Issuer Reconciliation Advice).
SPAN to Card Issuer Bank Field Description SPAN to Acquirer Bank
(1520 Acquirer Reconciliation DE Number – DE Name (1522 Card Issuer Reconciliation
Advice) Advice)
CPS credit adjustment 74 – Number Credits CPS credit adjustment
86 – Amount Credits
Withdrawal by our cardholder at Withdrawal by foreign cardholder at
76 – Number Debits
foreign ATM our ATM
88 – Amount Debits
CPS debit adjustment CPS debit adjustment
Inquiry by our cardholder at foreign Inquiry by foreign cardholder at our
80 – Number Inquiries
ATM ATM
Reversal of withdrawal by our 75 – Reversal Number Credits Reversal or withdrawal by foreign
cardholder at foreign ATM cardholder at our ATM
87 – Reversal Amount Credits
Charged back for false transaction by 107 – Chargeback Number Credits Chargeback for false transaction at
our cardholder at foreign ATM our ATM by foreign cardholder
105 – Chargeback Amount Credits
Net reconciliation amount 97 – Net Reconciliation Amount Net reconciliation amount
Table 5-11 ATM Transaction Impact on Reconciliation Advice Fields
5.5.6 POS Net Reconciliation Calculation

The Card Issuer Banks must settle the transactions with SPAN based on the date in the Reconciliation
Date (DE 28) of the 1200 Financial Transaction Request or 1220 Financial Transaction Advice
message. The Retailer Banks must settle transactions with SPAN based on the date in the
Reconciliation Date (DE 28) of the Online Retailer Advice (1220 Financial Advice) message.
Banks accumulate reconciliation totals from the perspective of both the Card Issuer and the Acquirer.
• As Card Issuer, the Bank accumulates transaction counts and amounts to verify the 1520
Acquirer Reconciliation Advice received from SPAN.

• As an Acquirer, the Bank accumulates transaction counts and amounts to verify the 1522
Issuer Reconciliation Advice received from SPAN.
Only the following approved transactions affect the POS net reconciliation calculation.
• Purchases;
• Purchases with cash backs;
• Refunds;
• Reversals;
• Chargebacks;
• Cash Advance (credit card only);
• CPS adjustments
Table 5-12 shows the impact of these transactions from the perspective of both Card Issuer Bank and
Retailer Bank.
Transaction Type Card Issuer Bank Retailer Bank
Purchase Increase debit count Increase debit count
Purchase with Cashback Increase debit amount Increase debit amount
Cash Advance
Refund Increase credit count Increase credit count
Reversal of POS Increase reversal credit count Increase reversal credit count
Purchase/Cash Advance
Reversal of POS Refund Increase reversal debit count Increase reversal debit count
Increase reversal debit amount Increase reversal debit amount
Full Chargeback Increase chargeback credit count Increase chargeback credit count
(Purchase)
amount amount
CPS Debit Adjustment Increase debit count Increase debit count
CPS Credit Adjustment Increase credit count Increase credit count
Table 5-12 POS Transaction Impact on Card Issuer Bank and Retailer Bank Totals
Table 5-13 and Table 5-14 present the method by which the POS activity is accumulated for both Card
Issuer Banks (1520 Acquirer Reconciliation Advice) and Retailer Banks (1522 Issuer Reconciliation
Advice).

SPAN to Card Issuer Bank Field Description

(1520 Acquirer Reconciliation Advice) DE Number – DE Name
Purchase by SPAN cardholder at SPAN POS terminal SPAN Cards
CPS debit adjustment 76 – Number Debits
Purchase/Cash Advance by Non-SPAN cardholder at Non-SPAN Cards
SPAN POS terminal
126.3 – Number Debits
CPS credit adjustment
126.8 – Amount Debits
Refunds by SPAN cardholder at SPAN POS terminal SPAN Cards
74 – Number Credits
Refunds by Non-SPAN cardholder at SPAN POS Non-SPAN Cards
terminal
126.1 – Number Credits
126.6 – Amount Credits
Inquiry by SPAN cardholder at SPAN POS terminal SPAN Cards
80 –Number Inquiries
Inquiry by Non-SPAN cardholder at SPAN POS Non-SPAN Cards
terminal
126.5 – Number Inquiries
Authorisations by Non-SPAN cardholder at SPAN POS Non-SPAN Cards
terminal
126.10 – Number Authorisations
Reversal of purchase by SPAN cardholder at SPAN SPAN Cards
POS terminal
75 – Reversal Number Credits
87 – Reversal Amount Credits
Reversal of purchase/cash advance by Non-SPAN Non-SPAN Cards
cardholder at SPAN POS terminal
126.2 – Reversal Credits Count
126.7 – Reversal Credits Amount
Reversal of refund by SPAN cardholder at SPAN POS SPAN Cards
terminal
77 – Reversal Number Debits
89 – Reversal Amount Debits
Reversal of refund by Non-SPAN cardholder at SPAN Non-SPAN Cards
POS terminal
126.4 – Reversal Debits Count
126.9 – Reversal Debits Amount
Chargeback for false purchase by SPAN cardholder at SPAN Cards
SPAN POS terminal
107 – Chargeback Number Credits
105 – Chargeback Amount Credits

SPAN to Card Issuer Bank Field Description

(1520 Acquirer Reconciliation Advice) DE Number – DE Name
Chargeback for false purchase by Non-SPAN Non-SPAN Cards
cardholder at SPAN POS terminal
126.2 – Reversal Credits Count
126.7 – Reversal Credit Amount
Net reconciliation SPAN Cards
97 – Net Reconciliation Amount
Table 5-13 POS Transaction Impact on Reconciliation Advice Fields – Card Issuer Bank
Field Description SPAN to Retailer Bank SPAN to Retailer Bank

DE Number – DE Name (1522 Issuer Reconciliation Advice) (1522 Issuer Reconciliation
Advice)
SPAN Card Reconciliation
Non-SPAN Card
Information (DE 126)
SPAN card refund at the Bank’s POS
SPAN Cards
terminal
74 – Number Credits
CPS credit adjustment
Non-SPAN Cards Non-SPAN card refund at

the Bank’s POS terminal
126.1 – Number Credits
126.6 – Amount Credits
SPAN Cards SPAN card purchase at the Bank’s
POS terminal
76 – Number Debits
CPS debit adjustment
Non-SPAN Cards Non-SPAN card purchase at
the Bank’s POS terminal
126.3 – Number Debits
126.8 – Amount Debits
SPAN Cards SPAN card inquiries at the Bank’s
POS terminals
80 –Number Inquiries
Non-SPAN Cards Non-SPAN card inquiries at
the Bank’s POS terminals
126 – (44-53) Number
Inquiries
Non-SPAN Cards Non-SPAN card
authorisations at the Bank’s
126.10 – Number
POS terminals
Authorisations
SPAN Cards SPAN card refund reversal at the
Bank’s POS terminal
77 – Reversal Number
Debits
89 – Reversal Amount
Debits

Field Description SPAN to Retailer Bank SPAN to Retailer Bank

DE Number – DE Name (1522 Issuer Reconciliation Advice) (1522 Issuer Reconciliation
Advice)
SPAN Card Reconciliation
Non-SPAN Card
Information (DE 126)
Non-SPAN Cards Non-SPAN card refund
reversal at the Bank’s POS
126.4 – Reversal Debits
terminal
Count
126.9 – Reversal Debits
Amount
SPAN Cards SPAN card purchase reversal at the
Bank’s POS terminal
75 – Reversal Number
Credits
87 – Reversal Amount
Credits
Non-SPAN Cards Non-SPAN card purchase
reversal at the Bank’s POS
126.2 – Reversal Credits
terminal
Count
126.7 – Reversal Credits
Amount
SPAN Cards SPAN card purchase chargeback
107 – Chargeback
Number Credits
105 – Chargeback
Amount Credits
Non-SPAN Cards Non-SPAN card purchase
chargeback
Not included
SPAN Cards SPAN card refund chargeback
108 – Chargeback
Number Debits
106 – Chargeback
Amount Debits
Non-SPAN Cards Non-SPAN card refund
chargeback
Not included
SPAN Cards Calculated net SPAN totals Not included
97 – Net Reconciliation
Amount
Table 5-14 POS Transaction Impact on Reconciliation Advice Fields – Retailer Bank
5.5.7 POS Terminal Force Reconciliation and Request Reconciliation

If a POS terminal does not send a 1524 Terminal Reconciliation Advice when it is supposed to, there
are two ways a Retailer Bank can ask SPAN for the terminal's totals.

Method 1: Force Reconciliation

This method is used when a POS terminal is physically able to send its totals, but has not done so for
some reason.
The Retailer Bank can use its Terminal Management System client to send a message to SPAN to
Force Reconciliation for the POS terminal. This will cause SPAN to set an internal flag for the
terminal, noting that a Force Reconciliation is required.
When the POS terminal next connects to SPAN and sends a request or advice, SPAN inserts a Force
Reconciliation flag in its response (unless it is a 1534). When the POS terminal sees a Force
Reconciliation flag in a response, it must then send a 1524 Terminal Reconciliation Advice as soon as
it can. The POS terminal may not be able to send a 1524 immediately because it must complete the
current transaction and then forward any stored advices. When it sends the 1524, the terminal sets the
Function Code to 571 to indicate it is a Forced Reconciliation.
When SPAN receives the 1524, it clears its internal flag for the POS terminal, responds with a 1534 as
usual, compares and cycles its totals for the terminal and forwards the 1524 on to the Retailer Bank and
Card Scheme Bank in the normal way. The Retailer Bank and Card Scheme Bank must send back 1534
responses.
Method 2: Request Reconciliation
This method is used when a POS terminal does not, or can not, contact SPAN or is otherwise unable to
send its totals.
The Retailer Bank can use its Terminal Management System client to send a message to SPAN to
Request Reconciliation for a terminal.
This causes SPAN to construct a 1524 Terminal Reconciliation Advice containing only its view of the
terminal's totals in DE 127 SPAN POS SPAN Reconcile Total; it then cycles its totals for the terminal
and sends the 1524 to the Retailer Bank and Card Scheme Bank. The 1524 contains a DE 24 Function
Code of 572 to indicate that it is a Requested Reconciliation and that the totals provided have not been
reconciled. The Retailer Bank and Card Scheme Bank must send back 1534 responses.
5.6 Reconciliation Examples

This section presents an example of online reconciliation totals accumulated for both POS and ATM.
Section 5.6.1 contains a POS online reconciliation totals accumulation example.
Section 5.6.2 contains an ATM online reconciliation totals accumulation example.
Section 5.7.1 then gives an example of the calculation of a Bank's net reconciliation position with
SPAN based on these examples.
5.6.1 POS Online Reconciliation Totals Accumulation Example

The example assumes the following sample POS transactions occur.
Transaction Transaction Type Transaction Retailer Bank Card Issuer
Number Amount Bank
P.1 Purchase 1000 SAR Bank B Bank A
P.21 Purchase 1000 SAR Bank B International
Bank Card
Scheme2
P.31 Authorisation 1500 SAR Bank B International
Bank Card
Scheme2
P.41 Financial Advice 1450 SAR3 Bank B International
Bank Card
Scheme2
P.5 Refund 500 SAR Bank B Bank A
Transaction Transaction Type Transaction Retailer Bank Card Issuer

Number Amount Bank
P.6 Purchase 450 SAR Bank B International
(Approved by Bank Card
Bank A) Scheme
(Bank A issued)
P.7 Purchase 1200 SAR Foreign International
Bank A) Scheme
(Bank A issued)
P.8 Purchase 2000 SAR Bank A4 Bank A
P.9 Purchase 1500 SAR Bank B Bank A
P.10 Purchase Reversal 1500 SAR Bank B Bank A
P.11 Refund 300 SAR Bank B Bank A
P.12 Refund Reversal 300 SAR Bank B Bank A
1. For SPAN, there is no financial impact for card scheme transactions.

2. The Card Issuer is accessed via an Card Scheme Network with which no online totals are
exchanged. However, the Card Scheme Bank receives a copy of the terminal reconciliation
messages.
3. Previously authorised for 1500 SAR in transaction 2.
4. When the Card Issuer and the Retailer Bank are the same (as in this transaction), to minimise
unnecessary message traffic, an Online Retailer Advice (1220 Financial Advice) is not sent to
the Retailer Bank. SPAN accumulates transaction totals for both the 1520 Acquirer
Reconciliation Advice to the Card Issuer Bank and the 1522 Issuer Reconciliation Advice to
the Retailer Bank using the 1210 Financial Request Response. Each Member Bank must be
able to recognise when they are both the Card Issuer Bank and the Retailer Bank and
accumulate the reconciliation totals for both the Issuer and Acquirer reconciliation messages
Accumulation of Bank A POS Totals
Table 5-15 and Table 5-16 show how the sample POS transactions accumulate into the totals in a 1520
Acquirer Reconciliation Advice sent by SPAN to Card Issuer Bank A.
DE Data Element Name Transaction Number Total
P.1 P.2 P.3 P.4 P.5 P.6 P.7 P.8
74 Number Credits +1 1
75 Reversal Number Credits 0
76 Number Debits +1 +1 2
77 Reversal Number Debits 0
80 Number Inquiries 0
81 Number Authorisations 0
86 Amount Credits + 500 500
87 Reversal Amount Credits 0
88 Amount Debits + 1000 + 2000 3000
89 Reversal Amount Debits 0
97 Net Reconciliation Amount - 1000 + 500 - 2000 D 2500
105 Chargeback Amount Credits 0
106 Chargeback Amount Debits 0
107 Chargeback Number Credits 0
108 Chargeback Number Debits 0
126 Bank Card Totals
126.1 Number Credits 0
126.2 Number Reversal 0
Credits

P.1 P.2 P.3 P.4 P.5 P.6 P.7 P.8
126.3 Number Debits +1 +1 2
126.4 Number Reversal Debits 0
126.5 Number Inquiries 0
126.6 Amount Credits 0
126.7 Amount Reversal 0
Credits
126.8 Amount Debits + 450 + 1200 1650
126.9 Amount Reversal Debits 0
126.10 Number Authorisations 0
Table 5-15 Bank A Accumulating 1520 Acquirer Reconciliation Advice POS Totals (Part 1)

P.9 P.10 P.11 P.12
75 Reversal Number Credits +1 1
76 Number Debits +1 3
77 Reversal Number Debits +1 1
87 Reversal Amount Credits + 1500 1500
88 Amount Debits + 1500 4500
89 Reversal Amount Debits + 300 300
97 Net Reconciliation Amount - 1500 + 1500 + 300 - 300 D 2500
Credits
126.3 Number Debits 2
Credits
126.8 Amount Debits 1650
Table 5-16 Bank A Accumulating 1520 Acquirer Reconciliation Advice Totals (Part 2)
Issuer Reconciliation Advice sent by SPAN to Retailer Bank A.
P.1 P.2 P.3 P.4 P.5 P.6 P.7 P.8
74 Number Credits 0


P.1 P.2 P.3 P.4 P.5 P.6 P.7 P.8
86 Amount Credits 0
97 Net Reconciliation Amount - 2000 D 2000
Credits
Credits
Table 5-17 Bank A Accumulating 1522 Issuer Reconciliation Advice Totals (Part 1)

P.9 P.10 P.11 P.12
74 Number Credits 0
76 Number Debits 1
86 Amount Credits 0
88 Amount Debits 2000
97 Net Reconciliation Amount D 2000
Credits

P.9 P.10 P.11 P.12
Credits
Table 5-18 Bank A Accumulating 1522 Issuer Reconciliation Advice Totals (Part 2)
Accumulation of Bank B POS Totals

Acquirer Reconciliation Advice sent by SPAN to Card Issuer Bank B.
P.1 P.2 P.3 P.4 P.5 P.6 P.7 P.8
74 Number Credits 0
76 Number Debits 0
86 Amount Credits 0
88 Amount Debits 0
97 Net Reconciliation Amount 0
Credits
Credits
Table 5-19 Bank B Accumulating 1520 Acquirer Reconciliation Advice Totals (Part 1)

P.9 P.10 P.11 P.12
74 Number Credits 0
76 Number Debits 0


P.9 P.10 P.11 P.12
86 Amount Credits 0
88 Amount Debits 0
97 Net Reconciliation Amount 0
Credits
Credits
Table 5-20 Bank B Accumulating 1520 Acquirer Reconciliation Advice POS Totals (Part 2)
Issuer Reconciliation Advice sent by SPAN to Retailer Bank B.
P.1 P.2 P.3 P.4 P.5 P.6 P.7 P.8
97 Net Reconciliation Amount - 1000 + 500 D 500
Credits
126.3 Number Debits +1 +1 +1 3


P.1 P.2 P.3 P.4 P.5 P.6 P.7 P.8
Credits
126.8 Amount Debits + 1000 + 1450 + 450 2900
126.10 Number Authorisations +1 0
Table 5-21 Bank B Accumulating 1522 Issuer Reconciliation Advice POS Totals (Part 1)

P.9 P.10 P.11 P.12
77 Reversal Number Debits +1 1
89 Reversal Amount Debits + 300 300
97 Net Reconciliation Amount - 1500 + 1500 + 300 - 300 D 500
Credits
Credits
Table 5-22 Bank B Accumulating 1522 Issuer Reconciliation Advice POS Totals (Part 2)
5.6.2 ATM Online Reconciliation Totals Accumulation Example

The example assume the following sample ATM transactions occur.
Transaction Transaction Type Transaction Acquirer Bank Card Issuer
Number Amount Bank
A.1 Withdrawal 1000 SAR Bank B Bank A
A.2 Balance Inquiry - Bank B Bank A
A.3 Withdrawal 1500 SAR Bank B Bank A
A.4 Withdrawal Reversal 1500 SAR Bank B Bank A

Transaction Transaction Type Transaction Acquirer Bank Card Issuer

Number Amount Bank
A.5 Withdrawal 2000 SAR Bank A Bank B
A.6 Withdrawal 1200 SAR Foreign International
Bank A) Scheme
(Bank A issued)
A.7 Withdrawal 600 SAR Bank B International
Bank A) Scheme Dual
Branded Card
(Bank A issued)
Accumulation of Bank A ATM Totals

Table 5-23 shows how the sample ATM transactions accumulate into the totals in a 1520 Acquirer
Reconciliation Advice sent by SPAN to Card Issuer Bank A.

P.1 P.2 P.3 P.4 P.5 P.6 P.7
74 Number Credits 0
76 Number Debits +1 +1 +1 3
80 Number Inquiries +1 1
86 Amount Credits 0
88 Amount Debits + 1000 + 1500 + 600 3100
97 Net Reconciliation Amount - 1000 - 1500 + 1500 - 600 D 1600
Credits
126.3 Number Debits +1 1
Credits
126.8 Amount Debits + 1200 1200
Table 5-23 Bank A Accumulating 1520 Acquirer Reconciliation Advice ATM Totals
Table 5-24 shows how the sample ATM transactions accumulate into the totals in a 1522 Issuer
Reconciliation Advice sent by SPAN to Acquirer Bank A.


P.1 P.2 P.3 P.4 P.5 P.6 P.7
74 Number Credits 0
86 Amount Credits 0
Credits
Credits
Table 5-24 Bank A Accumulating 1522 Issuer Reconciliation Advice ATM Totals
Accumulation of Bank B ATM Totals

Table 5-25 shows how the sample ATM transactions accumulate into the totals in a 1520 Acquirer
Reconciliation Advice sent by SPAN to Card Issuer Bank B.
P.1 P.2 P.3 P.4 P.5 P.6 P.7
74 Number Credits 0
86 Amount Credits 0

P.1 P.2 P.3 P.4 P.5 P.6 P.7
Credits
Credits
Table 5-25 Bank B Accumulating 1520 Acquirer Reconciliation Advice ATM Totals
Table 5-26 shows how the sample ATM transactions accumulate into the totals in a 1522 Issuer
Reconciliation Advice sent by SPAN to Acquirer Bank B.
P.1 P.2 P.3 P.4 P.5 P.6 P.7
74 Number Credits 0
75 Reversal Number Credits +1 +1 2
76 Number Debits +1 +1 2
80 Number Inquiries +1 1
86 Amount Credits 0
88 Amount Debits + 1000 + 1500 + 600 3100
97 Net Reconciliation Amount - 1000 - 1500 + 1500 - 600 D 1600
Credits
Credits
Table 5-26 Bank B Accumulating 1522 Issuer Reconciliation Advice ATM Totals

5.7 Calculation of Bank Net Reconciliation Position with SPAN

The net reconciliation position for each Bank is calculated by subtracting its position as a Card Issuer
Bank from its position as an Retailer / Acquirer Bank, i.e.:
= Position as an Retailer / Acquirer Bank
– Position as a Card Issuer Bank
A positive amount signifies that the Bank has a net credit position, so SPAN will post this amount as a
credit to the Bank at settlement time. A negative amount represents a net debit position for the Bank,
so SPAN will post this amount as a debit at settlement time.
This can be calculates using the following formula:
= – (Sum of 1522 Card Issuer Reconciliation Advice Net Reconciliation Amounts
– Sum of 1520 Acquirer Reconciliation Advice Net Reconciliation Amounts)
This can be simplified to:
= Sum of 1520 Acquirer Reconciliation Advice Net Reconciliation Amounts
– Sum of 1522 Card Issuer Reconciliation Advice Net Reconciliation Amounts
5.7.1 Bank Net Reconciliation Position Example
Message DE Position Amount Sum Net

Net Position to SPAN D 100
Card Issuer Position D 4100
1520 97 POS Position as Card Issuer Bank D 2500
1520 97 ATM Position as Card Issuer Bank D 1600
Retailer / Acquirer Position D 4000
1522 97 POS Position as Retailer Bank D 2000
1522 97 ATM Position as Acquirer Bank D 2000
Table 5-27 Net Reconciliation Position for Bank A
Message DE Position Amount Sum Net

Net Position to SPAN C 100
Card Issuer Position D 2000
1520 97 POS Position as Card Issuer Bank 0
1520 97 ATM Position as Card Issuer Bank D 2000
Retailer / Acquirer Position D 2100
1522 97 POS Position as Retailer Bank D 500
1522 97 ATM Position as Acquirer Bank D 1600
Table 5-28 Net Reconciliation Position for Bank B

5.8 Offline Reconciliation

The SPAN system will provide reconciliation reports to the Bank. The purpose of these reports are to
allow the Bank to resolve disputed amounts.
5.8.1 POS Reports/Extracts

TLF03 - this extract gives the Bank’s a detailed POS Retailer Activity Transaction list at the end of the
reconciliation period for POS.
TLF13 - this extract gives the Bank’s a detailed POS Retailer Activity EMV Transaction list at the end
of the reconciliation period for POS.
TLF04 - this extract gives the Bank’s a detailed Cardholder Activity Transaction list at the end of the
reconciliation period for POS.
TLF14 - this extract gives the Bank’s a detailed Cardholder Activity EMV Transaction list at the end
of the reconciliation period for POS.
Please refer to Section 9 for more details.
5.8.2 ATM Reports/Extracts

TLF01 – this extract gives the Bank’s a detailed ATM Activity Transaction list at the end of the
reconciliation period for ATM.
TLF11 – this extract gives the Bank’s a detailed ATM Activity EMV Transaction list at the end of the
reconciliation period for ATM.
TLF02 – this extract gives the Bank’s a detailed ATM Cardholder Activity Transaction list at the end
of the reconciliation period for ATM.
TLF12 – this extract gives the Bank’s a detailed ATM Cardholder Activity EMV.
Transaction list at the end of the reconciliation period for ATM.
5.8.3 SPAN Reconciliation Reporting

The SPAN network provides a complete set of reports/extracts to allow the Member Bank's staff the
ability to monitor the transactions that involved their Bank. SPAN provides an extract for each
business day indicating all transactions performed for each institution for that business day (SPAN's
business day).
SETL-01 SPAN Clearings Statement Report – A clearing statement summary sheet. This report gives
the Bank's net ATM, POS and overall net positions to SPAN at the end of the reconciliation period.
The above reports, coupled with the Bank’s transaction extracts, provide the means for the Bank to
reconcile and settle with SPAN.
5.8.4 EFT Funds Transfer

An EFT transfer account is set up for each Bank. SPAN manually generates a clearing house
transaction to either debit or credit these accounts based on the consolidated POS & ATM net
reconciliation amounts of each Bank for each business day.
These reports take into account the transactions that the Bank handled for other Banks (ATM Acquirer
and POS Retailer Bank relationships) and dispensed funds. In addition, any transactions handled by
another Bank (ATM and POS Card Issuer relationship) are taken into consideration. By computing the
difference between these two relationships, SPAN arrives at a total to either debit or credit the Bank's
account.
SPAN ensures that debits and credits posted for any business day will zero balance among all Banks.

5.8.5 Fee Accounting

Another report that SPAN produces for each Bank is the Fee Accounting Report. Basically, this report
is provided to each Bank on a monthly basis indicating the total number of transactions they have
performed for other Banks and transactions that have been performed for them. Each of these
transactions is assessed to indicate whether a fee is due to or from SPAN. The report is then sent to the
Bank. The net amount reflected on this report is used by SPAN to generate transactions to the clearing
house.
The complete discussion of Fee Accounting is contained in the existing SPAN Network Fees and
Charges Manual.
5.9 Bank Card Scheme Reconciliation/Settlement

SPAN will retain the existing payment options for Cardholders in the Kingdom by continuing to
maintain transaction processing interfaces to International Bank Card Scheme networks, such as Visa
and MasterCard. SPAN will not perform any financial settlement for International Bank Card Scheme
transactions on behalf of the Banks, as Bank Card settlement is performed outside of SPAN by the
Banks themselves.
International Bank Card Schemes must be sponsored by a Saudi Bank in order to participate in SPAN.
The Card Scheme Acquirer Bank is responsible for paying the Retailer for the Bank Card transactions,
which occur at SPAN POS Retailers. The Card Scheme Acquirer Bank pays the Retailer for these
transactions according to the individual commercial agreements negotiated between the Bank, the
Retailer and the Card Scheme organisation.
When the Card Scheme Acquirer Bank is not the Retailer Bank for the Retailer, SPAN will send to the
Card Scheme Acquirer Bank online advices for the sponsored bank card transaction activity occurring
at the Retailer, as well as terminal reconciliation messages containing the specified card scheme totals.
The Card Scheme Acquirer Bank will need to accumulate terminal activity in order to validate the
SPAN POS card scheme reconciliation totals. If the Retailer does not reconcile each terminal on a
daily basis, then the Card Scheme Acquirer Bank will need to continue the accumulation of
transactions while the Retailer performs the reconciliation function.
On receipt of the terminal reconciliation advice, the Bank Card Scheme Acquiring Bank can perform
processing of the transactions for clearing and settlement as specified by the Card Scheme network.
Each Card Scheme Acquirer Bank must process the reconciled transactions for each Bank Card
Scheme Organisation and format the transactions into interchange data (Pre-Edit Processing) files,
which are used as input to each Bank Card Scheme's Edit Package for processing.
Each Card Scheme Acquirer Bank creates an outgoing Interchange Transaction File containing all valid
interchange transactions for each International Bank Card Scheme Organisation following the Edit
Package Processing requirements for each Organisation
• BASE II format (VISA)
• INET format (MasterCard)
The following diagram highlights the flow of information for Acquired International Bank Card
Scheme transactions and the flow of settlement information.

10
11
Bank Card
Scheme Switch
Retailer Bank
5 2
8
6 SAMA
9
4
Edit Packages Bank Card

Scheme Acquirer
Accumulation Bank
1 7
POS
Terminal
12 Retailer
Figure 5-1 Information Flow for Settlements and International Bank Card Scheme Transactions
Step 1 – Transaction Request from SPAN POS terminal to SPAN.

Step 2 – Transaction Request is routed from SPAN to the Bank Card Scheme Switch for authorisation.
Step 3 – The Bank Card Scheme Switch returns the Transaction Response to SPAN
Step 4 – SPAN forwards the Transaction Response to the SPAN POS terminal.
Step 5 – SPAN forwards the Online Retailer Advice to the Retailer Bank.
Step 6 – SPAN forwards the Online Retailer Advice to the Card Scheme Acquirer Bank.
Step 7 – Reconciliation Advice from the SPAN POS terminal to SPAN.
Step 8 – SPAN forwards the Reconciliation Advice to the Retailer Bank.
Step 9 – SPAN forwards the Reconciliation Advice to the Card Scheme Acquirer Bank.
Step 10 – Card Scheme Acquirer Bank performs settlement and clearing processing according to the
Bank Card Scheme organisations procedures.

Step 11 – Funds flow from Bank Card Scheme organisations to the Card Scheme Acquirer Bank.
Step 12 – Card Scheme Acquirer Bank pays the Retailer for the Bank Card Scheme transactions, which
were performed at the SPAN POS terminal.
For switched-in (Card Issuer) transactions from International Bank Schemes, these are forwarded by
SPAN to the appropriate card Issuer for authorisation. These are not accumulated for terminal
reconciliation. However they are accumulated as normal to the Card Issuer totals in the 1520 Acquirer
Reconciliation Advice.
Settlement of these transactions is with the International Card Schemes, and is outside SPAN.

Protocol and Communications
Section 6 Protocol and Communications
6.1 Introduction
The TCP/IP protocol is used for the links between SPAN and the Member Banks. This section gives a
brief overview of the TCP/IP protocol and then explains how TCP/IP connections are established and
used between SPAN and the Member Banks.
6.2 TCP/IP
6.2.1 General Overview
TCP/IP (Transmission Control Protocol / Internet Protocol) is the basic protocol of the Internet.
However, it is also very commonly used as a communications protocol in private networks.
TCP/IP uses the client/server model of communication in which one computer (a client) requests and is
provided a service by another computer (a server) somewhere on the network. TCP/IP communication
is primarily point-to-point, meaning each communication is from one point (or host computer) in the
network to another point (or host computer).
TCP/IP is primarily a two-layer protocol 3.
The lower (network) layer is the Internet Protocol (IP). This provides basic communication. IP is a
connectionless, unreliable, best-effort, packet protocol. IP provides the address part of each packet so
that it gets to the right destination; each gateway computer on the network checks this address to see
where to forward the message. There is no connection between the sender and receiver at IP level; each
packet is a standalone datagram. Although packets are not discarded without reason, if packets are lost,
IP does not recover them; the receiver does not acknowledge receipt of packets, therefore the sender
cannot retransmit lost packets.
The higher (transport) layer, is the Transmission Control Protocol (TCP). This provides additional
services to overcome the limitations of IP. TCP is a connection-oriented, reliable, streaming protocol.
The client and server must establish a connection before messages can be exchanged. Data can be
transmitted reliably because the TCP layer in the receiver must check for corrupt packets and
acknowledge receipt of good packets, and the TCP layer in the sender must retransmit lost or corrupt
packets. The acknowledgement mechanism also permits flow control that can prevent a sender flooding
a receiver.
TCP is a streaming protocol. Data is delivered in a continuous sequence to the receiving application
process, not necessarily as individual messages. If the sender transmits multiple messages, partial or
concatenated messages may be delivered to the receiving process. Therefore the receiving process must
have a way of identifying discrete application-level messages in the stream. If the application-level
messages are complex and varying-length, this is often accomplished by inserting a simple preamble
before each application-level message giving the length of the subsequent message. This helps isolate
communication handling from application-level message processing. (Note that this preamble is part of
the application data, not part of the TCP header; it is just a useful convention, not part of the protocol.)
3
The term "TCP/IP" is sometimes used loosely to refer to a suite of related protocols, operating at
different levels and performing many different functions, some control-related, some application-
related. In addition to TCP and IP, two other commonly-used protocols in the suite are the User
Datagram Protocol (UDP) and the Internet Control Message Protocol (ICMP). But there are also many
higher application-layer protocols. These include the File Transfer Protocol (FTP); the Simple Mail
Transfer Protocol (SMTP) used for email; and Telnet, which allows logon to remote systems.
For the Member Bank Interface, the application-layer protocol is the set of ISO 8583:1993 messages
defined by this specification.

6.2.2 Related Documentation

The SPAN network takes advantage of widely accepted international standards. It is beyond the scope of
this document to discuss all options and technical requirements of each standard. It is recommended that
the following minimum list of applicable standards be consulted as part of the implementation of the
TCP/IP communications facilities.
1. RFC 793 Transmission Control Protocol, DARPA Internet Program Protocol Specification,
September 1981.
http://www.ietf.org/rfc/rfc793.txt
2. RFC 791 Internet Protocol, DARPA Internet Program Protocol Specification, September 1981.
3. RFC 1122 Requirements for Internet Hosts - Communication Layers, October 1989.
4. RFC 792 Internet Control Message Protocol, DARPA Internet Program Protocol Specification,
September 1981.
5. RFC 768 User Datagram Protocol, August 1980.
6.3 Use of TCP on Member Bank Interface

This section describes how SPAN and a Member Bank communicate using TCP.
6.3.1 Connection Establishment

In TCP connection terms, SPAN is configured to be a server and the Member Bank is configured to be
a client. The Member Bank is responsible for establishing (and re-establishing) the TCP connections to
SPAN. SPAN must listen for, and accept, incoming TCP connection requests.
The source and destination IP addresses and port numbers used for the connections must be pre-
configured at each side.
Under normal circumstances, SPAN and the Member Bank should communicate via a minimum of two
TCP connections. The connections should be spread over two physically separate communication links.
This provides resilience to communication link failure. The maximum number of TCP connections
used must be agreed between SPAN and the Member Bank and pre-configured at each side.
Once established, a TCP connection is maintained continuously, i.e. it is not closed and re-established
under normal circumstances.
6.3.2 Connection Usage

From the viewpoint of SPAN or the Member Bank, each connection is bi-directional: each connection
can be used to transmit or receive application-level messages. The messages sent on the connection
may be application-level requests 4 or application-level responses.
Each application-level message sent on a connection must be preceded by a preamble giving the length
of the subsequent application-level message in bytes. The preamble consists of four ASCII digits. The
length excludes the four bytes of the preamble itself.
Application-level requests and responses can be multi-threaded on a connection, i.e. it is not necessary
for a requester to wait until an application-level response has been received before sending another
4
In this section, except where stated otherwise, the term "request" refers to any ISO 8583:1993 request
or advice message, the term "response" refers to any ISO 8583:1993 response message. Similarly, the
term "requester" refers to the sender of any ISO 8583:1993 request or advice message and the term
"responder" refers to the sender of any ISO 8583:1993 response message.
application-level request. For example, if a Member Bank (acting as a transaction acquirer) sends an
1100 Authorisation Request to SPAN, the bank must be able to send another 1100 request before
receiving the 1110 Authorisation Response for the first request, and to be able to receive the 1110
responses in any order.
Application-level responses do not have to be sent back in the same order as the requests were sent.
Application-level data elements echoed in the response must be used by the requester to match
responses against requests. Section 2 and Section 3 list and describe the echoed data elements.
There is no limit to the number of application-level requests that can be sent before an application-level
response is received. However, the requester must associate a time-out with each request and initiate
application-level recovery as shown in Section 4 if an expected response is not received in time.
An application-level response must be sent back to the requester on the same connection as the request.
If an application-level transaction involves more than one request/response exchange, the separate
exchanges may occur on different connections. For example, an 1100 Authorisation Request / 1110
Authorisation Response exchange may take place on one connection and be followed by a related 1220
Financial Transaction Advice / 1230 Financial Transaction Advice Response exchange on a different
connection.
Under normal circumstances, when more than one connection is available, the requester must round-
robin requests over them.
6.3.3 Normal Connection Termination

Either side may close the connection. However, if SPAN closes the connection, the Member Bank must
automatically attempt to re-establish it. If the Member Bank closes the connection, SPAN must take no
action to re-establish it other than listening for a new TCP connection request.
6.3.4 Connection Failure

If possible, TCP Keep-Alives should be configured at each side to assist the rapid automatic detection
of connection failures. However, it is recognised that some systems may not permit this or may find
that TCP Keep-Alives impose an unacceptable load.
The communication-handling level at each side should try to automatically detect the failure of a
connection and inform the application-level of this as soon as possible so it can be taken out of use.
However, it is recognised that some systems may not permit this and manual intervention may be
required.
Repeated application-level timeouts should not normally be used to decide automatically that a
connection has failed. However, reports of repeated application-level timeouts may lead to manual
intervention that might result in a connection being taken out of use or terminated..
If a connection fails, all requests that were in-flight on the failed connection must be timed-out at the
application-level and the requester must handle the timed-out request according to the application-level
message type flow as shown in Section 4.
Once a connection failure has been detected by a requester, the connection must be taken out of use for
application-level messages until it is re-established. The requester must send new requests only on the
surviving connections to the destination.
If all connections to a destination have been taken out of use because of failures, the requester must
decline new requests and store all new advices for later forwarding as shown in Section 4. This
continues until at least one connection is re-established and put back into use.
6.3.5 Connection Re-Establishment

It is the responsibility of the Member Bank to re-establish a failed connection at TCP level. There must
be a short, configured delay between each attempt to re-establish the connection to avoid swamping
SPAN with TCP connection requests and to allow time for the pre-configured ports to clear if
termination was abnormal.

Once a failed connection has been re-established at TCP level, the communication-handling level at
each side should try to inform the application-level of this as soon as possible so it can be put back into
use. However, it is recognised that some systems may not permit this and manual intervention may be
required.
Once a failed connection has been re-established at TCP level, and this has been detected by the
application-level, the application-level must send an echo-test request (an 1804 Network Management
Request with DE 24 Function Code set to 831). Once a requester has received a valid echo-test
response (an 1814 Network Management Request Response with DE 39 Action Code set to 800), the
connection should automatically be put back to use for other application-level messages.
An application-level logon request (an 1804 Network Management Request with DE 24 Function Code
set to 801) should not be sent after a failed connection has been re-established unless an application-
level response indicates the other side is logged-off (indicated by a DE 39 Action Code of 910).
Note that reliable automatic failure detection and recovery are dependent on whether the application-
level can automatically detect the absence and presence of a TCP connection and whether a successful
echo-test exchange indicates the other side is operating properly. Thus, automatic failure detection and
recovery may not be possible for all systems, and manual intervention may be required.
6.3.6 Configuration Parameters

The table below summarises recommended preamble and TCP Keep-Alive settings.
Parameter Description Recommended Settings

Preamble Format ASCII characters.
Preamble Length Four bytes.
Preamble Header Type Value in the preamble is length of data only, it excludes itself.
Send keep alive message (‘empty message’ or zero header without
Keep Alive Option
any data part).
Thirty seconds (sets maximum inactivity between sending keep
Keep Alive Interval
alive message).
Table 6-1 Port Specific TCP Configuration Parameters

Network Security
Section 7 Network Security
7.1 Introduction
This section addresses the network security requirements of the SPAN system. The main focus of this
section is the encryption and translation methods used on the cardholder Personal Identification
Number (PIN) and the management of network keys.
Included in this section are,
• Key Management;
• Communication Authentication;
• Data Authentication;
• PIN Processing.
7.2 Key Management

7.2.1 Introduction
The key management subsection deals with several factors such as the secure generation, distribution,
and storage of keys.
This section will highlight the management of the following keys.
• LMK (Local Master Key), which is the encryption key stored within the physical secure
device and used to encrypt and decrypt any sensitive key data outside the HSM.
• ZMK (Zone Master Key), which is the KEK (Key Encryption Key), used between the SPAN
switch and member banks to exchange working keys.
• Working keys used for PIN and MAC processing.
• SAMA/Member Bank key pair used for signature and random string sequence encryption.
Note: Actually there is a set of LMKs in the HSM. Different LMKs are used to protect different key
types. However for simplicity in this section we refer to LMKs in the singular.
7.2.2 Key Hierarchy

In symmetric key cryptography both parties involved in a secure transfer require the same set of keys.
This requires keys to be transferred between the two nodes, which might raise a vulnerability concern if
keys are not securely exchanged.
Asymmetric key cryptography on the other hand consist of two keys, one which is private and only
kept by the owner and a public key that can be distributed. In terms of hierarchy, the various keys
above classified by cryptography are as follows.
• Symmetric key hierarchy
o Highest level – LMK.
o Lower level – ZMK, a ZMK per zone, one is used to exchange ZPK and the other is
used to exchange ZAK
o Lowest level – Working keys, per zone, specifically ZPK and ZAK.
• Asymmetric key hierarchy
o SAMA/Member Bank Private key – This can be stored in clear within an HSM or
encrypted under LMK and stored in switch database (it is recommended that the
private key be stored in the HSM);

Network Security
o SAMA/Member Bank Public key – This is stored within the switch database.
o The key pair is only used with network management messages, specifically for
communication authentication.
7.2.3 Key Generation

The key generation process must always be conducted in a secure environment to ensure that all steps
are taken to prevent risk of exposing keys. Ideally, this should always occur within a physically secure
device. The generation should be random or pseudo random and an individual key shall not be
intentionally equal in value to any other key.
In case of key pair and LMK, the generation should occur locally at each point and not centralised.
The security keys that must be generated are:
• LMK – It is a master key per secure device, all keys are stored encrypted under this key within
switch database. The generation of the LMK will be as it is currently done on SPAN network.
For further details please refer to your HSM vendor.
• ZMK – Also known as the Key Encryption Key (KEK), is the key used to exchange working
keys. It is generated manually from the secure device console then exchanged manually.
• SAMA/Member Bank Public/Private key pair – These keys are generated locally within each
secure device node. The SAMA Public keys are distributed to the Member Banks whilst the
Member Banks’ Public key are distributed to SAMA.
• ZWK – Working keys are keys used for PIN encryption and MAC’ing and are generated
within the secure device then exchanged under ZMK encryption.
• Random string sequence – This key is a random DES key generated by the HSM.
LMK Generation
To generate and load the LMK, at least 3 component holders and 3 smart cards are required (each
component is saved on a smart card). The LMK is normally generated and stored on smart cards before
being loaded into the secure device.
The LMK is used to protect key values that are stored on the local switch database and should be
unique per system (except for backup and load balance systems).
The LMK is recommended to be changed at 2-year intervals. After generation, encrypted data is
translated from encryption under the old LMK to encryption under the new key.
ZMK Generation
The ZMK is generated manually using a console command at the SAMA switch side. The output from
the generation process is 3 ZMK clear components that must be sent to the member bank (in a secure
manner) and the ZMK encrypted under the LMK of the HSM for local storage.
SAMA/Member Key Pair Generation Switch node key pair generation should always occur locally in
the key owner node and not centralised. It must also be unique per node. Recommended key length is
1024 bit and the recommended algorithm to be used is RSA. The Public key is used for encryption and
private key is used for digital signature.
For security reasons, when the private key is not stored within the secure device, it is stored encrypted
under the LMK The public key must be held in DER encoding for ASN.1 format.
ZWK Generation
Working keys are keys used for PIN encryption or MAC’ing , namely Zone Pin Key (ZPK) and Zone
Authentication key (ZAK).
A zone working key (ZWK) is encrypted under the ZMK when it is to be exchanged with another
party. While for storage locally, the working keys are encrypted under the LMK.

Network Security
This method of maintaining security is typical and it relies upon frequent key updates that do not
degrade network performance. However, if key synchronisation is not correctly maintained, a large
number of transactions can be rejected during the key exchange period.
To ensure this does not occur, SPAN will maintain two keys for each ZWK (old key and current key).
During the key exchange period both the current key and old key will be acceptable (old key will only
be accepted for a configurable length of time). All messages sent to SPAN and originating from it will
include an index that indicates which key has been used for this specific transaction (see Key Exchange
below).
It is recommended to exchange working keys every 15 minutes or after a configurable number of
transactions (based on the sustained transactions per second processed by SPAN), whichever scenario
comes first.
The ZWK update involves two Network Management messages, an 1804 sent by SPAN and the 1814
response sent by the Bank. The 1804 message must specify which key type and the key index being
updated.
Key Type Key Index

ZPK Key A or Key B
ZAK Key A or Key B
The order in which the working key 1804 Network Management Request messages are sent is
immaterial to the function. Moreover, the SPAN interchange does not require that the first response be
received before the second request is sent. Therefore, although these ZPK and ZAK working key
updates may be initiated at the same time they are independent of each other. . See the SPAN
Technical book Security Framework document for details of the process.
7.2.4 Key Length

The following table summarises the keys used between SPAN and the member banks; the algorithm
that will be utilised and the key lengths.
Key Algorithm Length

LMK 3DES 128 bit
ZMK 3DES 128 bit
ZAK/ZPK 3DES* 128 bit
SAMA/Member Bank Public/Private Key Pair RSA 1024 bit
* There will be no separate keys for the same bank working as acquirer and issuer i.e. ZAK and ZPK
will be used for all transactions handled by the zone with no differentiation whether the bank is
working as acquirer or issuer.
7.2.5 Key Exchange

The ZMK is the key used to securely exchange working keys within the SPAN network. The ZMKs are
exchanged manually..
Using the ZMKs, two working keys are exchanged; ZPK and ZAK. Two ZMKs are used per zone, one
is used to exchange ZPK and the other is used to exchange ZAK.
The frequencies with which the keys are to be exchanged are as follows.

Network Security
• For the ZMK, must be every 6 months.

• For ZWKs, i.e. the ZPK and ZAK must be every 15 minutes or a configurable number of
transactions (based on the sustained transactions per second processed by SPAN).
7.2.5.1 ZMK Update

ZMK update is as defined by the Security Framework Document, this is summarised below.
The ZMK is always kept encrypted under the node LMK, within the switch Database. The ZMK should
never be changed unless SPAN issues a new ZMK. The following diagram shows the ZMK exchange
flow.
SAMA Environment Bank Environment
3 6
Console IST/Switch Bank's Switch Console
ZMK Encrypted under ZMK Encrypted under

SAMA's LMK Bank's LMK
1 5
Console HSM HSM Console
2
ZMK Components
Figure 7-1 ZMK Update
Step Description
1 ZMK components are generated using the HSM via the console connected to it. A
different person generates each component and stores it in a smart card. Each
component should be duplicated for distribution to the bank.
2 The ZMK is manually generated using the ZMK components stored in the smart cards.
The HSM returns the ZMK encrypted under SAMA’s LMK.
3 The output from step 2 above is entered into the SPAN switch.
4 A set of smart cards containing the ZMK components is sent to the bank. These are
produced outside the IST Switch.
5 The ZMK is manually generated using the ZMK components received from SAMA (i.e.
the smart cards). The HSM returns the ZMK encrypted under Bank’s LMK.
6 The output from step 5 above is entered into the Bank’s switch.
Table 7-1 ZMK Update Steps
7.2.5.2 ZWK (ZPK and ZAK) Update

Periodically, SPAN sends online key updates for each of the issuer and acquirer Zone Working Keys.
The period of time after which SPAN sends key updates is based upon a SPAN-configured time
interval and a configurable number of transactions. SPAN sends new key updates after 15 minutes or a

Network Security
configurable number of transactions (based on the sustained transactions per second processed by
SPAN), whichever occurs first.
The 1804 network management message for a working key change from SAMA contains field 96 (Key
Management Data). The components of the field are as follows:
Component Description
1 New key value, encrypted under the Zone Master Key (ZMK) – see Section
3.4.54.
2 New key check digits (used by the Bank's application to verify the key) – see
Section 3.4.54.
3 Key type – 1 character. Valid values are:
1 = PIN key
2 = MAC key
4 Key indicator – 1 character.
Indicates the key, which the Bank should update and use for all new transaction
requests with a PIN or a MAC. Valid values are:
0= Key A
1= Key B
When a Bank receives the message, it will call its HSM to translate the new key (ZWK) from
encryption under the ZMK to encryption under the Bank’s LMK. The output from the HSM is the
ZWK encrypted under the LMK along with its checksum. The first four characters of the check digits
produced by the HSM is compared with the check digit in the 1804 message. If they are the same, then
the translation is successful. If so, the Bank must take the newly translated key and store it in an
encrypted version in a file/database.
The Bank must reply with an 1814 response message indicating the result by assigning the appropriate
response code in the message.
The ZWKs, i.e. the ZPKs and ZAKs, are stored in the database encrypted under LMK. The following
diagram shows the ZPK and ZAK exchange flow.

Network Security
SAMA Network
Member
Bank(2)
IST/ Switch
ZPK or
ZMK
ZAK
Encrypte
Encrypte
d with
d with
7 LMK
LMK
Member
Bank(1) 3
2 1
6
Data
Bas
5 4 e
Data
Bas
e
HSM
HSM
Figure 7-2 ZPK And ZAK Exchange Flow
Step Description
The SAMA switch sends a ZWK generation request to the HSM As part of the request,
1
the encrypted ZMK under LMK is sent.
The HSM responds with the ZWK encrypted under ZMK*. for exchange and ZWK
2
encrypted under LMK for local storage.
The SAMA switch formats an 1804 message for key exchange to be sent to the member
3
bank and includes in it the ZPK or ZAK encrypted under ZMK.
The member bank reads the 1804 message and extracts the ZPK or ZAK encrypted
under ZMK and sends the following to the HSM:
4 Encrypted ZPK or ZAK under ZMK to be encrypted under LMK (to be ready for
storage);
Encrypted ZMK under LMK.
5 The HSM responds with the ZPK or ZAK encrypted under LMK

Network Security
6 The member bank stores the encrypted key in the database

7 The Bank responds to SAMA with an 1814.
* The ANSI X9.17 standard for key encryption scheme will be adopted for encrypting the ZWK under
the ZMK. In addition, the Atalla variant method must be used.
Note: VISA requires Atalla variant for DKE-exchanged keys but does not use it for manually-
exchanged keys.
ZWK (ZPK and ZAK) Synchronisation
Working key synchronisation is needed to minimise the denial of service caused by out-of-sync
working keys. The solution is to keep two copies of the working key, current key and old key; the old
key is kept for a configurable period of time to allow for transactions processed with the old key to be
handled, only within this grace period, as follows:
• For every BIN (Bank Identification Number) there will be two working keys (‘A’ and ‘B’);
• Only one of them should be active at a time;
• If the key ‘A’ is used, and there is key exchange, key ‘A’ is not overwritten, but key ‘B’ will
be the new active key;
• For every transaction sent, the key index (‘A’ or ‘B’) will be included in the message;
• If key ‘A’ is the current active key and a request for exchanging the key is received, ‘B’ will
become the new working key;
• Old key ‘A’ is kept for a configurable period of time, known as the grace period, within which
transactions with the old key ‘A’ can be processed;
• After this time period, Key ‘A’ will be removed and no transaction with the old key ‘A’ is
processed;
• Exchanging the key will work in round robin behaviour, 'A' -> 'B' -> 'A'.
One exception should be handled to avoid any out-of-sync errors, when SAMA switch is sending a
transaction to the issuer (transaction flow is initiated by SAMA switch) and prior receiving a successful
response on the key exchange request from the issuer side, SAMA switch should send the transaction
with the old key and not the new one.

Network Security
The following diagram shows the process of the key synchronisation while the member bank is acting
as an acquirer.
Current key is 'A' Current key is 'A'
1. Generate new
working key
2. Change the
current key from 'A'
to 'B' 3. Send request for key exchange with the
new key 'B'
4. Bank sends a
transaction prior
changing current key
from 'A' to 'B'
5. Current key 'A'
6. Transaction with key 'A'

7. Transaction with
key index = A,
process the 8. Process key
transaction with old exchange request,
key 'A' change the current
key from 'A' to 'B'
9. Bank sends a
transaction after
changing current key
from 'A' to 'B'
10. Transaction with key 'B'
11. Transaction with
key index = B,
process the
transaction with new
key 'B' 12. Send successful response for key
exchange request
13. Start counting
time to remove old
key 'A'
15. Process the

transaction with
current key 'B'
SAMA Member Bank
Figure 7-3 Key Synchronisation Process For Acquirers

Network Security
The following diagram shows the process of the key synchronisation while the member bank is acting
as an issuer.
Current key is 'A' Current key is 'A'
1. Generate new
workingkey
2. Change the
current key from 'A'
to 'B' 3. Send request for key exchange with the
new key 'B'
4. SAMA sends a
transactionprior
receivingresponse
for key exchange
request
6. Transaction with
key index = A,
processthe
transaction with old
key 'A'
8. SAMA sends a 7. Process key

transactionprior exchange request,
receivingresponse change the current
for key exchange key from 'A' to 'B'
request

10. Transaction with
key index = A,
processthe
transaction with old
11.Send successfulresponse forkey key 'A'
exchange request
12. Start counting
time to remove old
key 'A'
14.Processthe
transaction with key
'B'
SAMA MemberBank
Figure 7-4 Key Synchronisation Process For Issuers
7.2.5.3 SAMA/Member Bank Public/Private Key Pair

The exchange of public key between SAMA and Member Banks is manual.
Each party, SAMA as well as member banks, will need to generate a Public/Private key pair. SAMA
will distribute its public key to all member banks. Each member bank will need to give SAMA the
bank’s public key.
The following diagram describes the generation and distribution of RSA keys used for network
messages authentication. Although it shows SAMA’s key generation and distribution process, it is also
applicable to member banks.
For more details on this process please refer to the SPAN Security Framework document.

Network Security
Bank-n Environment
Bank-2 Environment
SAMA Environment Bank-1 Environment
3 5
Console IST/Switch Bank's Switch Console
Private (Secret) Key
Encrypted under SAMA's public key
SAMA's LMK
1
HSM
HSM HSM Console
Interface
2
SAMA's Public Key
Figure 7-5 Generation And Distribution Of RSA Keys For Network Messages Authentication
Step Description
1 Request HSM to generate a Public/Private key pair.
2 HSM returns the public key in ASN.1 DER format and private key encrypted under
LMK.
The information related to the private key to be captured on the switch will depend on
the where the private key is stored.
If private key is stored on the HSM, the switch will need to capture the index that
3
references the private key.
If private key is only stored on the switch, the value would be the private key encrypted
under the LMK (i.e. output from step 2 above)
4 SAMA’s public key is distributed to all member banks.
5 SAMA’s Public key is entered/copied into the Bank’s switch.
7.3 Communication Authentication

7.3.1 Functionality Overview
It is required to support secured and authenticated network messages between SAMA and member
banks. This will be required in log-on messages.
The authentication functionality is achieved using a RSA based digital signature.

Network Security
7.3.2 Network Messages Flow
7.3.2.1 Logon process

Either SAMA or Member Bank can initiate a logon. The diagram below shows the processing flow of
the logon process.
Logon Initiator Respondent
3
1804 (Logon Request)
Switch Switch
8 1814 (Logon Response)
1 2 7 4 5
HSM HSM
Figure 7-6 Member Bank Interface - Logon Process
Step Description
Request HSM to generate a random DES key (32 hex), which is used as the random
1
string for the logon request.
Request HSM to generate a digital signature using its private key. Refer to the table
2
below for the list of fields included in the signature calculation.
Initiator sends an 1804 message indicating its intention to logon. Data in the message
3
includes the random string and digital signature.
Upon receiving the 1804 the respondent verifies the digital signature for the message
4
using the public key of the initiator, by making a request to the HSM,
If verification is successful, respondent requests its HSM to generate a digital signature,
5 using its private key, for the response message. Refer to the table below for the list of
fields included in the signature calculation.
Respondent replies with an 1814 response message. Data in the message includes the
6
random string and digital signature.
7 Initiator makes a request to the HSM to verify the digital signature for the 1814.
The status of the connection will be set accordingly depending on the outcome of the
8
verification/comparison.
At the end of the exchange of messages, there is no need to acknowledge the reply. If a failure occurs
due to communication problem, the originator of the login will retry until the login is successful.
Signature Fields
The following table highlights the fields, which if present are to be used to calculate the digital
signature.

Network Security
Field Description
Number
7 Transmission Date and Time
24 Function Code. The field is used to calculate the digital signature only
when sending the 1804 request message
39 Action Code. The field is used to calculate the digital signature only
when sending the 1814 response message
94 Transaction Originator Institution Identification Code data field. (Only
the data part of DE 94 must be included in the digital signature
calculation. The length part must be excluded.)
96.4 Random string sequence from the Key Management Data
7.4 Data Authentication

7.4.1 Introduction
In any form of secure message transfer the data authentication and integrity, i.e. the prevention of
unauthorised data modification, has to be ensured without introducing unacceptable performance
impact. This will be achieved in the SPAN system using Message Authentication Code (MAC)
techniques.
Message Authentication Code (MAC) is a checksum derived by applying an authentication scheme
with a secret key to the message. The computation and verification are both done with the same key.
7.4.2 Message Fields to be MAC’ed

The MAC’ing technique that will be utilised is the Block-Cipher-Based method with 4 bytes, based on
selected data parts of the variable length fields as indicated by the table. When the selected fields are
used they are taken in sequence from the start of the message, concatenated, and padded to a multiple
of eight bytes to form the data that is used for the message authentication calculation.
The fields to be selected for the MAC calculation are identified in the following tables. If a field is not
present in the message, no corresponding data is included.
Note: Only the data part of a variable-length field is included in the MAC calculation, i.e. the length
part (../…) of the field is not included in the MAC calculation.
Financial Message Class

MT1100
MT1110
MT1120
MT1130
MT1200
MT1210
MT1220
MT1230
MT1420
MT1430
MT1422
MT1432
Bit ISO Field
Message Type Identifier x x x x x x x x x x x x

Primary Bit Map x x x x x x x x x x x x
1 Secondary Bit Map x x x x x x x x x x x x
2 Primary Account Number x x x x x x x x x x x x
3 Processing Code x x x x x x x x x x x x
4 Amount, Transaction x x x x x x x x x x x x
5 Amount, Reconciliation x x x x x x x x x x x x

Network Security
MT1100
MT1110
MT1120
MT1130
MT1200
MT1210
MT1220
MT1230
MT1420
MT1430
MT1422
MT1432
Bit ISO Field
System Trace Audit

11 x x x x x x x x x x x x
Number
Date and Time, Local
12 x x x x x x x x x x x x
Transaction
39 Action Code x x x x x x x
Reconciliation Message Class
MT1520
MT1530
MT1522
MT1532
MT1524
MT1534
Bit ISO Field
Message Type Identifier x x x x x x

Primary Bit Map x x x x x x
1 Secondary Bit Map x x x x x x
2 Primary Account Number x x x x x x
System Trace Audit
11 x x x x x x
Number
Date and Time, Local
12 x x x x x x
Transaction
39 Action Code x x x x
Reconciliation Currency
50 x x x x x x
Code
74 Credits, Number x x x x
75 Credits, Reversal Number x x x x
76 Debits, Number x x x x
77 Debits, Reversal Number x x x x
80 Inquiries, Number x x x x
81 Authorisations, Number x x x x
86 Credits, Amount x x x x
87 Credits, Reversal Amount x x x x
88 Debits, Amount x x x x
89 Debits, Reversal Amount x x x x
Net Reconciliation
97 x x x x x x
Amount
Credits, Chargeback
105 x x x x
Amount

Network Security
MT1520
MT1530
MT1522
MT1532
MT1524
MT1534
Bit ISO Field
Debits, Chargeback
106 x x x x
Amount
Credits, Chargeback
107 x x x x
Number
Debits, Chargeback
108 x x x x
Number
Private – Terminal
124 x x
Reconcile Totals
Private - Bank Card
126 x x x x
Scheme Reconcile Totals
Private – SPAN POS
127 x x
SPAN Reconcile Totals
Administrative Class
Messages in the Administrative Class do not have a MAC.
7.4.3 Message Authentication Block (MAB) Generation

A message Authentication Block is created by taking a string of data, padding it if necessary to a
multiple of 8 bytes in length, and encrypting it using the triple DES CBC algorithm. The result is an 8
byte block which is known as the MAB. The underlying principle is that a third party would be unable
to generate the correct 8 byte value for any particular message text without knowing the secret key
used.
The MAB block bits are labelled 1 to 64 from left to right, bits 1 to 32 form the Message
Authentication Code (MAC) and bits 33 to 64 form the MAC Residue.
The MAC is usually sent in fields DE64 & DE128. The MAC residue is not used (except in some POS
terminal session key derivation schemes).
This process is illustrated in the following example.
A more detailed description of the MAC process is provided in the SPAN technical book Security
Framework document.

Network Security
MESSAGE AUTHENTICATION BLOCK GENERATION
Block 1 Block 2 Block 3 ............. Final Block
Initial XOR XOR XOR XOR

Vector
MAC MAC MAC MAC

DES DES DES DES
Key Key Key Key
Cipher
Cipher1 Cipher2 Cipher3 MAB
n-1
Initial Vector = Hex '0000 0000 0000 0000'
Figure 7-7 Message Authentication Block Generation
7.5 PIN Processing

All card issuer banks assign each cardholder a Personal Identification Number (PIN) that is intended to
uniquely identify that cardholder at the point of service. An assigned PIN can contain a minimum of
four digits and a maximum of twelve digits. The PIN data (field 52) represent the encrypted version of
the assigned clear PIN.
All ATM transactions acquired by Member Bank ATMs should use the ANSI DES algorithm standard
for PIN translation and verification process. The DES algorithm corresponds to the format of the
destination PIN block to be sent through the network.
In all 1200 Financial Request messages the PIN data (field 52) is required to be present. This field must
contain the encrypted PIN/PAN block. Where ATMs are connected to the SPAN switch, the PIN block
is translated from encryption under a Terminal PIN Key (where it was encrypted at the ATM) to
encryption under a Zone PIN Key shared between SPAN and the issuing bank.
Where PIN data is required to be transmitted between multiple parties, it is translated as required from
encryption under one Zone PIN Key to encryption under the next Zone PIN Key as required across
encryption zones.
For a detailed description of the process see the SPAN technical book Security Framework document.

International Bank Card Scheme Processing
Section 8 International Bank Card Scheme Processing
8.1 Introduction
This section details the following aspects of International Bank Card Scheme processing.
• Transaction processing
• Message fields
• Reconciliation
• Settlement requirements
8.2 International Bank Card Scheme Cards

The International Bank Card Scheme Cards that can be used within the SPAN network fall in one of
the following categories.
• Saudi bank issued
• Foreign bank issued
SPAN has transaction processing interfaces to International Bank Card Scheme networks (Visa and
MasterCard). Providing interfaces to these international networks allows Visa and MasterCard Cards
(Non-SPAN Cards) to be accepted at ATM and POS terminals deployed throughout the Kingdom.
SPAN routes all Amex transactions to SAIB for onward routing.
8.3 International Bank Card Scheme Sponsor Banks

In order to participate in the SPAN network, a foreign International Bank Card Scheme must be
sponsored by a Saudi Bank, known as the Bank Card Scheme Issuer Bank or Bank Card Scheme
Acquirer Bank.
Each Retailer Bank may offer Bank Card Scheme services to its Retailers. If a Retailer Bank does not
have a commercial relationship with a Bank Card Scheme organisation, the Retailer may select another
Bank to perform the role of Bank Card Scheme Acquirer.
SPAN has links to International Bank Card Scheme organisations to provide the transaction processing
interface needed to obtain online authorisation processing for these Bank Cards used in the Kingdom,
or Saudi Bank Cardholders using their Cards abroad.
8.4 Transaction Routing

The following table outlines the routing of the transaction and related messages for both Saudi bank
issued Non SPAN cards and Foreign Bank cards used within the Kingdom.
Saudi Bank Non-SPAN Card/Foreign Bank Card
ATM Bank Card transactions initiated at ATMs are received from the Acquirer Bank by SPAN
and routed to the appropriate Bank Card network for authorisation.
Upon receipt of the transaction response from the Bank Card Scheme Network, SPAN
logs the message and returns the transaction response to the Acquirer Bank, which in-
turn routes the response to the ATM.
SPAN’s directly connected ATMs only accept SPAN cards (no IBCS cards).
Transactions on Saudi bank issued cards at ATMs abroad are either routed to SPAN
(MDS, GCC-net and VISA-SMS) for onward routing by SPAN to the KSA Card Issuer,
or (for all other networks) routed directly to the KSA Card Issuer through existing
systems (not via SPAN).

Saudi Bank Non-SPAN Card/Foreign Bank Card

POS Bank Card transactions initiated at SPAN POS terminals are received by SPAN and
routed to the appropriate Bank Card network for authorisation.
Upon receipt of the transaction response from the Bank Card Scheme Network, SPAN
logs the message, updates appropriate terminal activity totals, and returns the transaction
to the appropriate EFTPOS terminal. SPAN also sends a Financial Advice to the Retailer
Bank/Card Scheme Acquirer Bank. When the Retailer Bank is not the Card Scheme
Acquirer Bank, a Financial Advice is sent to both institutions.
The Card Scheme Acquirer Bank pays the Retailer for these reconciled transactions
according to the individual commercial agreement negotiated between the Bank, the
Retailer, and the International Bank Card Scheme organisation.
Transactions on Saudi bank issued cards at POS abroad are either routed to SPAN
(MDS) for onward routing by SPAN to the KSA Card Issuer, or (for all other networks)
routed directly to the KSA Card Issuer through existing systems (not via SPAN).
SPAN SPAN provides each Bank Card Scheme Acquiring Bank with an online notification
detailing the sponsored bank card transaction as well as terminal reconciliation messages
containing specified card scheme totals.
Each Bank Card Scheme Bank must process reconciled transactions for each Bank Card
Scheme Organisation. Outgoing interchange transaction files containing all valid
transactions for each International Bank Card Scheme Organisation must be formatted in
accordance with the processing requirements of the respective network for reconciliation
and settlement (BASEII format for Visa bank cards and INET format for MasterCard
bank cards).
The KSA Card Issuers are responsible for settlement of all incoming (Issuer)
transactions routed to them by SPAN, outside of the SPAN network, with the exception
of GCC transactions (incoming and outgoing) which are settled through SPAN
8.5 International Bank Card Scheme ATM Transaction Processing

8.5.1 IBCS ATM Transactions Acquired in Saudi Arabia Routed by SPAN (Acquirer)
SPAN provides the interfaces needed to obtain online authorisation and data capture of Bank Card
Scheme transactions for bank cards branded with Visa and MasterCard logos. SPAN either acquires or
routes all these ATM transactions.
For both Saudi issued non-SPAN cards and foreign bank cards, the transaction is forwarded to the
appropriate International Card Scheme organisation for authorisation. SPAN also provides all possible
transaction information to the Card Scheme Acquirers in order to clear the captured transactions.
A withdrawal transaction is used to validate a cardholder and whether or not the associated account has
sufficient funds. The Card Scheme Acquirer receives the combination of the authorisation request and
response information on approved withdrawals in order to settle the transaction outside the SPAN
network. When the cardholder requests a withdrawal authorisation at an ATM with an International
Bank Card Scheme Card, the cardholder inserts the card into the ATM which will read the chip (if
available), otherwise it reads Track 2 of the card. The type of transaction, amount, and PIN are entered
by the cardholder.
After all transaction information has been entered by the cardholder, the transaction is sent to the
Acquirer Bank and then on across the data communication network to SPAN. After performing data
consistency checks on the message, SPAN determines the card type using card algorithms and verifies
that the ATM and the Acquirer Bank accept this type of card. The transaction request is then sent to the
appropriate interchange interface. The interchange interface checks to see if the interchange is online
and reformats the message into the specified interchange message format. The interchange performs

the final authorisation of the transaction and responds with a message, either approving or denying the
transaction.
SPAN does not perform stand-in authorisation for ATM. When SPAN receives no response, the
transaction request is declined and returned to the Acquirer Bank and ATM.
Upon receipt of the transaction response, the transaction is logged to the log file before it is returned to
the originating Acquirer Bank. The ATM informs the cardholder of the outcome of the transaction
(approved or denied), prints a receipt, and updates its totals for the appropriate card type.
The Bank Card Scheme Issuer and Acquirer Banks must accumulate the transaction activity advice
records in order to validate the ATM card scheme reconciliation totals.
The following diagram highlights the flow of information for International Bank Card Scheme
transactions and the flow of settlement information.
7
8
Bank Card
Scheme Switch
5 SPAN
Bank Card
Scheme Acquirer
6
Bank
1 ATM
Figure 8-1 Information Flow For Settlement Acquired International Bank Card Scheme
Transactions
Step Description
1 Transaction request from ATM terminal to Acquirer Bank
2 Transaction request is routed from Acquirer Bank to SPAN
Transaction request is routed from SPAN to the Bank Card Scheme Switch for
3
authorisation
4 The Bank Card Scheme Switch returns the transaction response to SPAN
5 SPAN forwards the transaction response to the Acquirer Bank
6 The Acquirer Bank forwards the transaction response to the ATM

Step Description
Bank Card Scheme Acquirer Bank performs reconciliation and clearing processing
7 according to the Bank Card Scheme organisations' procedures (with the exception of
GCC where settlement is done via SPAN).
Funds flow from Bank Card Scheme organisations to the Bank Card Scheme Acquirer
8
Bank
8.5.2 IBCS ATM Transactions Acquired Abroad Routed to SPAN (Issuer)

SPAN has a number of interfaces that support incoming online authorisation and data capture of Bank
Card Scheme transactions for Saudi Arabian bank cards branded with International Card Scheme logos
used at ATMs abroad. SPAN routes these transactions to the appropriate KSA Card Issuer for
authorisation. These interfaces are:
• MDS (MasterCard Debit)
• GCC Net (ATM only)
• VISA SMS (ATM only)
The Saudi Cardholder uses their card in an ATM abroad. After all transaction information has been
entered by the cardholder, the transaction is sent to the Acquirer Bank then to the appropriate IBCS
switch, then on across the data communication network to SPAN. This message is converted from the
particular IBCS interchange format into MBI format. After performing data consistency checks on the
message, SPAN determines the card type using card algorithms and verifies that the Card Issuer Bank
accept this type of card/transaction. The transaction request is then sent to the appropriate Card Issuer
Bank for authorisation.
SPAN does not perform stand-in authorisation for KSA Card Issuers’ ATM transactions. When SPAN
receives no response from the Card Issuer, the transaction request is declined and returned to the IBCS
Switch for onward routing to the Acquirer Bank and ATM.
Upon receipt of the transaction response from the Card Issuer, the transaction is logged to the log file
before it is returned to the originating IBCS interface for formatting of the response before transmission
to the IBCS switch for onward routing to the Acquirer and ATM.
All settlement takes place between the Card Issuer and the IBCS switch outside of SPAN.

9
10
KSA Bank
Scheme
Card Issuer
6 SPAN
International
Bank Card
Scheme 7
Switch
Bank Card
2 Scheme Acquirer
(Abroad)
ATM
Figure 8-2 Information Flow For Settlement Issuer International Bank Card Scheme
Transactions
Step Description
1 Transaction request from ATM terminal to Acquirer Bank (Abroad)
2 Transaction request is routed from Acquirer Bank to International Bank Card Switch
3 Transaction Request is routed from the International Bank Card Switch to SPAN
Transaction request is routed from SPAN to the KSA Bank Card Scheme Issuer for
4
authorisation
5 The KSA Bank Card Scheme Issuer returns the transaction response to SPAN
6 SPAN forwards the transaction response to the International Bank Card Scheme Switch
The International Bank Card Scheme Switch forwards the transaction response to the
7
Bank Card Scheme Acquirer (Abroad)
8 The Acquirer Bank forwards the transaction response to the ATM

Step Description
KSA Bank Card Scheme Issuer Bank performs reconciliation and clearing processing
9 according to the Bank Card Scheme organisations' procedures (with the exception of
GCC where settlement is done via SPAN).
Funds flow from KSA Bank Card Scheme Issuer Bank to the International Card
10
Schemes
8.6 International Bank Card Scheme POS Transaction Processing

8.6.1 IBCS POS Transactions Acquired in Saudi Arabia Routed by SPAN (Acquirer)
SPAN provides the interfaces needed to obtain online authorisation and data capture of Bank Card
Scheme transactions for bank cards branded with Visa and MasterCard logos. Unlike ATM
transactions, SPAN acquires or routes all POS transactions.
• SPAN card and Dual-Branded card transactions are sent to the appropriate Saudi Bank for
authorisation.
• International Bank Card Scheme card transactions are sent to the appropriate organisation for
authorisation.
SPAN also provides all possible transaction information to the Card Scheme Issuers and Acquirers in
order to clear the captured transactions. The Retailer Bank and the Card Scheme Acquirer receive an
advice of authorisation requests and responses.
SPAN supports the following POS transaction types for International Card Schemes:
• Purchase
A purchase transaction is used to validate a cardholder and whether or not the associated card
account has sufficient funds to cover the purchase or services. The Card Scheme Acquirer
receives the combination of the authorisation request and response information on approved
purchases in order to settle the purchase outside the SPAN network.
• Purchase Advice
A purchase advice transaction is a transaction that was authorised by some means other than
the terminal interface to the transaction host. The Retailer must enter the authorisation code
provided by the transaction authoriser into the terminal for successful processing of the
transaction by SPAN. Since no authorisation request is exchanged with the International Bank
Card Scheme Organisation for purchase advices, the Card Scheme Acquirer builds settlement
information from the default values received in field 123 in addition to the current values
purchase advices now generate.
• Authorisation Only
An authorisation only transaction is used to validate a cardholder and whether or not the
associated card account has sufficient funds to cover a future purchase of goods or services.
An authorisation only transaction has no financial impact. The Card Scheme Acquirer does
not send a settlement record to the International Card Scheme Organisation for Authorisation
Only transactions.
• Refunds
A refund transaction is used for payment of funds from a Retailer to a cardholder under
circumstances where goods have been returned to the Retailer by the cardholder. Since no
authorisation request may be exchanged with the International Bank Card Scheme
Organisation for refunds, the Card Scheme Acquirer builds settlement information from the
default values received in field 123 in addition to the current values refunds now generate.

• Purchase Reversal (cancellation/void)

The reversal of a purchase transaction effectively voids the impact of the previous purchase
transaction to the cardholder's and Retailer's accounts. This may occur due to the cardholder
failing to complete the transaction at the point of sale by leaving the premises, or the Retailer
deciding the cardholder signature is invalid. A Reversal requires the Card Scheme Acquirer to
not create a settlement transaction for a previous approved purchase.
• Cash Advance
A cash advance transaction is used to validate a cardholder and whether or not the associated
card account has sufficient funds to cover the cash advance. The Card Scheme Acquirer
receives the combination of the authorisation request and response information on approved
cash advance in order to settle the cash advance outside the SPAN network.
When the cardholder requests a purchase authorisation at a SPAN POS terminal with an International
Bank Card Scheme Card, the Retailer passes the cardholder's card through the SPAN POS terminal's
card reader, which reads the chip (if available) otherwise the Track 2 of the card. The type of
transaction and transaction amount are entered by the Retailer. International Bank Card Cardholders, at
the point of sale, may not be required to enter a PIN.
After all transaction information has been entered by the Retailer, the transaction is sent across the data
communication network to SPAN. After performing data consistency checks on the message, SPAN
determines the card type using card algorithms and verifies the terminal and the Retailer accept this
type of card. Based upon the results of the algorithm, the transaction request is sent to the appropriate
Interchange Interface.
The Interchange Interface checks to see if the interchange is online and reformats the message into the
specified interchange message format. The interchange performs the final authorisation of the
transaction and responds with a message, either approving or declining the transaction.
If the interchange is not online, SPAN does not perform stand-in authorisation for International Bank
Card Scheme transactions. The transaction request is declined and returned to the terminal.
Upon receipt of the transaction response, the transaction is logged to the transaction log file before it is
returned to the originating SPAN POS terminal.
The SPAN POS terminal informs the Retailer of the outcome of the transaction (approved or declined),
and prints a receipt for cardholder signature as required. The SPAN POS terminal updates its terminal
totals for the appropriate card type.
An online Retailer Advice is created and forwarded by SPAN to the Retailer Bank. When the Bank
Card Scheme Acquirer Bank is not the Retailer Bank, an additional advice record is created and
forwarded by SPAN to the Bank Card Scheme Acquirer Bank on approved transactions.
The Bank Card Scheme Issuer Banks and Acquirer Banks must accumulate transaction activity advice
records in order to validate the SPAN POS card scheme reconciliation totals. Once the Retailer
performs the reconciliation function, the Bank Card Scheme Acquirer Bank receives a reconciliation
transaction containing the counts and amounts for the sponsored card scheme.
Upon receipt of the terminal reconciliation advice, the Bank Card Scheme Acquiring Bank has all
available information for subsequent processing of the transactions for clearing and settlement as
specified by the Card Scheme network.
transactions and the flow of reconciliation information.

15
16
Bank Card
Scheme Switch
6
Retailer Bank
12
5
11 2
SPAN
7
4
13 10
8
Bank Card
Scheme Acquirer
Bank
14
1 9
POS
Terminal
17 Retailer
Figure 8-3 Information Flow For Reconciliation and Settlement of Acquired International Bank
Card Scheme Transactions
Step Description
1 Transaction request from SPAN POS terminal to SPAN
Transaction request is routed from SPAN to the Bank Card Scheme Switch for
2
authorisation
3 The Bank Card Scheme Switch returns the transaction response to SPAN
4 SPAN forwards the transaction response to the SPAN POS terminal
5 SPAN forwards the Online Retailer Advice to the Retailer Bank
The Retailer Bank responds with by sending an Online Retailer Advice response to
6
SPAN
SPAN forwards the Online Retailer Advice with the Card Scheme information to the
7
Bank Card Scheme Acquirer Bank on approved transactions

Step Description
The Bank Card Scheme Acquirer Bank responds by sending an Online Retailer Advice
8
response to SPAN
9 SPAN POS Terminal Reconciliation Request from the SPAN POS terminal to SPAN
10 SPAN responds with a Reconciliation Advice Response to the SPAN POS terminal
SPAN forwards the Reconciliation Advice to the Retailer Bank. The advice contains
11
all transaction totals performed at the SPAN POS terminal
The Retailer Bank responds by sending a Reconciliation Advice response to SPAN
12
acknowledging receipt of the totals
SPAN forwards the Reconciliation Advice to the Bank Card Scheme Acquirer Bank.
13 This advice contains Card Scheme transaction totals (i.e. Visa totals or MasterCard
totals) for the Bank Card Scheme sponsored at the Retailer
The Bank Card Scheme Acquirer Bank responds by sending a Reconciliation Advice
14
response to SPAN acknowledging receipt of the totals
Bank Card Scheme Acquirer Bank performs reconciliation and clearing processing
15
according to the Bank Card Scheme organisation procedures
Funds flow from Bank Card Scheme organisation to the Bank Card Scheme Acquirer
16
Bank
Bank Card Scheme Acquirer Bank pays the Retailer for the Bank Card Scheme
17
transactions, which were performed at the SPAN POS terminal
Note: If the Retailer Bank and the Card Scheme Acquirer Bank are the same institution, Step 7 & 8
would not occur. One advice would be sent with the Card Scheme information present.
8.6.2 IBCS POS Transactions Acquired Abroad Routed to SPAN (Issuer)

SPAN has a limited number of interfaces that support incoming online authorisation and data capture
of Bank Card Scheme transactions for Saudi Arabian bank cards branded with International Bank
Schemes logos used at POS abroad. SPAN routes these transactions to the appropriate KSA Card Issuer
for authorisation. These interfaces are:
• MDS (MasterCard Debit)
The Saudi Cardholder uses their card at a POS abroad. After all transaction information has been
entered by the cardholder, the transaction is sent to the Acquirer Bank then to the appropriate IBCS
switch, then on across the data communication network to SPAN. This message is converted from the
particular IBCS interchange format into MBI format. After performing data consistency checks on the
message, SPAN determines the card type using card algorithms and verifies that the Card Issuer Bank
accept this type of card/transaction. The transaction request is then sent to the appropriate Card Issuer
Bank for authorisation.
SPAN does not perform stand-in authorisation for KSA Card Issuers’ transactions. When SPAN
receives no response from the Card Issuer, the transaction request is declined and returned to the IBCS
Switch for onward routing to the Acquirer Bank and the POS.
Upon receipt of the transaction response from the Card Issuer, the transaction is logged to the log file
before it is returned to the originating IBCS interface for formatting of the response before transmission
to the IBCS switch for onward routing to the Acquirer and POS.
All settlement takes place between the Card Issuer and the IBCS switch outside of SPAN.

9
10
KSA Bank
Scheme
Card Issuer
6 SPAN
International
Bank Card
Scheme 7
Switch
Bank Card
2 Scheme Acquirer
(Abroad)
POS
Figure 8-4 Information Flow For Settlement of Issuer International Bank Card Scheme
Transactions
Step Description
1 Transaction request from POS terminal to Acquirer Bank (Abroad)
2 Transaction request is routed from Acquirer Bank to International Bank Card Switch
3 Transaction Request is routed from the International Bank Card Switch to SPAN
Transaction request is routed from SPAN to the KSA Bank Card Scheme Issuer for
4
authorisation
5 The KSA Bank Card Scheme Issuer returns the transaction response to SPAN
6 SPAN forwards the transaction response to the International Bank Card Scheme Switch
The International Bank Card Scheme Switch forwards the transaction response to the
7
Bank Card Scheme Acquirer (Abroad)
8 The Acquirer Bank forwards the transaction response to the POS
KSA Bank Card Scheme Issuer Bank performs reconciliation and clearing processing
9
according to the Bank Card Scheme organisations' procedures

Step Description
Funds flow from KSA Bank Card Scheme Issuer Bank to the International Card
10
Schemes
8.7 SPAN ATM Reconciliation

The Bank Card Scheme Acquirer Bank must accumulate ATM activity in order to validate the
reconciliation totals for each Card Scheme processed. The Acquirer Bank should reconcile each ATM
on a daily basis.
8.8 SPAN POS Terminal Reconciliation

The Bank Card Scheme Acquirer Bank must accumulate terminal activity in order to validate the
SPAN POS card scheme reconciliation totals. If the Retailer does not reconcile each terminal on a
daily basis, the Card Scheme Acquirer Bank must continue the accumulation of transactions until the
Retailer performs the reconciliation function.
When a Retailer reconciles a terminal, SPAN potentially sends up to three reconciliation advice
messages. If the Retailer Bank, Visa Card Scheme Acquirer, and MasterCard Card Scheme Acquirer
are the same institution, only one reconciliation advice is sent. If the Retailer Bank, Visa Card Scheme
Acquirer, and MasterCard Card Scheme Acquirer are all different institutions, the Retailer Bank
receives a reconciliation advice with all transaction total information. But, the Visa Card Scheme
Acquirer receives a reconciliation advice with only Visa totals. Likewise, the MasterCard Card Scheme
Acquirer receives a reconciliation advice with only MasterCard totals.
When a Retailer performs a terminal reconciliation, the Bank Card Scheme Bank receives a 1524
Terminal Reconciliation Advice which contains the POS Terminal Reconciliation data element (field
124). This data element contains up to 10 occurrences of card scheme totals. A Bank Card Scheme
Bank only receives terminal reconciliation totals for the card schemes it services. For each card
scheme, the following information is present in field 124.
• Card Scheme ID
• Card Scheme Acquirer ID
• Debit Count
• Debit Amount
• Credit Count
• Credit Amount
• Cashback Amount
• Cash Advance Amount
If the terminal is out-of-balance in this reconciliation, the 1524 Terminal Reconciliation Advice also
contains the SPAN POS totals for the terminal (field 127). This data element gives the same detailed
information as field 124, but contains the totals accumulated by SPAN.
The Bank Card Scheme Bank must store transactions until it receives a 1524 Terminal Reconciliation
Advice for those transactions. This ensures all system-generated reversals have been applied to the
transactions before they are sent for reconciliation. Upon receipt of the terminal reconciliation advice,
the Bank Card Scheme Acquiring Bank performs reconciliation and clearing as specified by the Card
Scheme network.
Incoming POS transactions from the IBCS switches are not subject to terminal reconciliation on SPAN.
However they are included in the Card Issuer Totals in the 1520 Acquirer Reconciliation Advice.

8.9 International Bank Card Scheme Settlement

The Card Scheme Acquirer Banks are also responsible for the financial settlement for International
Bank Card Scheme transactions. Settlement is performed completely outside the SPAN network.
However, SPAN supplies all available transaction information to the Card Scheme Acquirer Bank via
field 123 – Card Scheme Information.
8.9.1 POS
The Card Scheme Information (field 123) is used for POS and only sent to Card Scheme Acquirers.
When the Retailer Bank is also the Card Scheme Acquirer, field 123 is sent in the 1210 Financial
Request Response or in the 1220 Financial Advice, depending on which institution is connected to the
SPAN POS. However, when the two are different, the Card Scheme Acquirer receives a 1220 Financial
Advice with field 123. The Retailer Bank still receives its 1210 or 1220, but field 123 is not
transmitted.
The Card Scheme Information (field 123) is also sent to Retailer Banks/Bank Card Scheme Banks in
1420 Acquirer Reversal Advices. When the Retailer Bank is not the same institution as the Bank Card
Scheme Bank, the Retailer Bank does not receive the Card Scheme Information (field 123) in the 1420.
8.9.2 ATM
The Card Scheme Information (field 123) is used for Visa SMS transactions acquired by the member
banks.
When the Acquiring Bank sends a 1200 request message to SPAN ATM, field 123 is set-up to denote
that it is a Visa SMS transaction.
Field 123 in the 1210 response sent by SPAN ATM to the Acquiring Bank will contain information,
which will be required for settlement with Visa International.
For reversal transaction, the Acquiring Bank will need to set-up the Payment Service Indicator and
Transaction Identifier sub-fields in field 123 in the 1420 message it sends to SPAN ATM. The value of
Transaction Identifier must be the same as the value in 1210.
8.9.3 Mapping SPAN Interface Fields To Visa Settlement Fields

The following is a cross-reference list of ISO based SPAN interface fields that can be used by the Card
Scheme Acquirer when building VISA ATM and POS (fields as applicable) settlement detail
transactions.
ISO Data
VISA Settlement Field Interface Field Name
Element
Transaction Code 3 Processing Code
Account Number 2 Primary Account Number
Account Number Extension 2 Primary Account Number
Acquirer’s Business ID 32 Acquirer Institution ID Code
Purchase Date 7 Transmission Date and Time
Source Amount 4 Transaction Amount
Source Currency Code 49 Transaction Currency Code
Merchant Name 43 Card Acceptor Name/Location
Merchant City 43 Card Acceptor Name/Location
Merchant Category Code 26 Card Acceptor Business Code
Payment Service Indicator 123 Card Scheme Information (123.7)

ISO Data
VISA Settlement Field Interface Field Name
Element
Authorisation Code 38 Approval Code
POS Terminal Capability 22 Point of Service Data Code, position 1
POS Entry Mode 22 Point of Service Data Code, position 7
42 (POS) Card Acceptor ID Code (POS)
Card Acceptor ID
43 (ATM) Card Acceptor Name
Terminal ID 41 Card Acceptor Terminal ID, positions 1-6
Cardholder Activated Terminal 123 &

Card Scheme Information (123.6)
Indicator 22
Authorisation Source Code 123 Card Scheme Information (123.5)
ATM Account Selection 3 Processing Code
Transaction Identifier 123 Card Scheme Information (123.8)
Authorised Amount 4 Transaction Amount
Auth Currency Code 49 Transaction Currency Code
Auth Response Code 123 Card Scheme Information (123.4)
Validation Code 123 Card Scheme Information (123.9)
8.9.4 Mapping ISO Interface Fields To MasterCard Settlement Fields

The following is a list of ISO interface fields which can be used by the Card Scheme Acquirer when
building MasterCard settlement detail transactions.
ISO Data
MasterCard Settlement Field Interface Field Name
Element
Merchant Category Code 26 Card Acceptor Business Code
Merchant Name 43 Card Acceptor Name/Location
Merchant City 43 Card Acceptor Name/Location
Cardholder Account Number 32 Primary Account Number
Transaction Date 7 Transmission Date and Time
Record Code (Transaction Type) 3 Processing Code
Transaction Amount 4 Transaction Amount
Transaction Currency Code 49 Transaction Currency Code
Authorisation Code 38 Approval Code
8.9.5 Bank Interface Modifications

The International Bank Card Scheme processing utilises the following Bank Interface modifications.
New Message


1644 – Administrative Notification
The definition and layout of these messages can be found in Section 2 - Message Formats.
New Data Element
Card Scheme Information (Field 123)
The definition and layout of this data element is found in Section 3 - Field Descriptions. One layout is
used for 12xx and 14xx messages while a different layout is used for 16xx messages.
New SPAN Action Codes
180 Unable to locate previous message
181 Previous message located for a repeat or reversal, but message data is
inconsistent with original message
182 Invalid date
183 Cryptographic error found in PIN or CVV
184 Incorrect CVV
185 Unable to verify PIN
186 No reason to decline a request for account verification or address verification
Note: The new ISO standard has mapped the old 2-bit Response Code to the new 3-bit Action Code.
For clarity the term Action Code will be used in the passage below although the International Bank
Schemes still operate on the old Response Codes.
The majority of SPAN and Visa Action Codes are identical because each uses the Action Codes
defined by ISO standards. However, SPAN and Visa could, and in some instances do, define the same
response code differently to meet each Bank Card Schemes' processing requirements. This results in
one response code value having two different meanings. To avoid confusion, the Visa response codes
76 through 89 will be translated to new Action Codes to ensure that each Action Code the Retailer
Bank receives has a clear definition.
8.10 International Bank Card Scheme Certification

Both International Bank Card Schemes, Visa and MasterCard define testing and certification
requirements and procedures. They are also responsible for scheduling and administering the tests,
providing certification information to the Banks, and coordinating the use of test scripts and data.
Member Banks will need to be certified by Visa for ATM/CPS and SMS. For MasterCard, Banks need
to be certified by MasterCard-MDS and MasterCard Banknet.

Transaction Log File Extract
Section 9 Transaction Log File Extract
9.1 Introduction
This section defines the format for extract files created by SPAN to facilitate reconciliation. These
extract files are generated daily from the SPAN switch database as part of the report generation
process. Separate files are produced for Member Banks as Acquirer and Issuer for both ATM and POS
activity, i.e. there are four primary extract files. Also, ICC related data for transactions in each of the
four primary extracts mentioned are provided in four secondary extracts as highlighted in the table
below.
Primary Extract Secondary Extract
Transaction Data ICC Data
MB Acquired (ATM) TLF01 - ATM Activity Report TLF11 - ATM Activity EMV
Data Report
MB Issued (ATM) TLF02 - ATM Cardholder TLF12 - ATM Cardholder
Activity Report Activity Report
MB Acquired (POS) TLF03 - POS Retailer Activity TLF13 - POS Retailer Activity
Report EMV Data Report
MB Issued (POS) TLF04 - Cardholder Activity TLF14 - Cardholder Activity
Report EMV Data Report
Note: Although the extract files are sometimes informally referred to as 'reports' in this section and in
parts of section 5.8, they are not intended to be displayable, printable or directly human-readable
without further processing. The extract file records are large and complex, and are intended to be
machine-readable.
9.2 ATM & POS Extracts

The extract files contain transaction records for the transactions processed by SPAN (both ATM and
POS) on a particular day. The following internal message types are included:
No Transaction Type SPAN Internal TLF
Message Type
1 EMV Online Normal Purchase (POS) 110 Y
2 EMV Offline Normal Purchase (POS) 230 Y
3 MAG Normal Purchase (POS) 210 Y
4 EMV Purchase with Cashback (POS) 110 Y
5 EMV Cash Advance (POS) 110 Y
6 MAG Cash Advance (POS) 210 Y
7 EMV Refund (POS) 110 Y
8 MAG Refund (POS) 210 Y
9 EMV Pre-Authorisation (POS) 110 Y
10 MAG Pre-Authorisation (POS) 110 Y
11 EMV Online Purchase Advice (POS) 230 Y
12 EMV Pre-Auth Completion (POS) 230 Y

No Transaction Type SPAN Internal TLF

Message Type
13 MAG Pre-Auth Completion (POS) 230 Y
14 EMV Cash Withdrawal (ATM) 210 Y

15 MAG Cash Withdrawal (ATM) 210 Y
16 EMV Balance Inquiry (ATM) 210 Y
17 MAG Balance Inquiry (ATM) 210 Y
18 Mini Statement (ATM) 210 Y
19 EMV Pre-Paid Token Dispense (ATM) 210 Y
20 EMV Cash Advance (ATM) 210 Y
21 MAG Cash Advance (ATM) 210 Y
22 CPS Adjustment 230 Y
23 Reconciliation 5xx / 15xx Y
24 Fraud Advice 9630 Y
25 Administrative Notification 1644 Y
26 Rejected Messages 9xxx Y
27 Reversals 430 Y
27 Chargebacks 432 Y
Note: The message types in the above table are SPAN internal message type codes: they are not
Member Bank Interface message types.
9.3 Extract Records

9.3.1 General
9.3.1.1 File Content

An extract file may optionally contain records for a single institution or for all institutions. This is
controlled by a parameter at file generation time.
An extract file may optionally contain records for a single settlement date or for a range of dates. This
is controlled by a parameter at file generation time.
An extract file may contain a header record, zero or more data records and a trailer record. The header
and trailer records are optional and may not be present. Their presence is controlled by a parameter at
file generation time.
9.3.1.2 Record Order

An extract file is sorted by Institution (Member Bank) and the Institution (Member Bank) id is
contained in the filename.
9.3.1.3 Field Order

The order of the fields in a record is the same as the order shown in the tables in section 9.3Error!
Reference source not found..
9.3.1.4 Field Separator

Every field in a data record is separated from the next by a field separator. The field separator is present
even if the field is empty.
The field separator may be a single character or a short sequence of characters. The field separator must
be a value that does not occur in the data. The field separator value is controlled by a parameter at file
generation time. The value must be agreed between SAMA and the file recipients. The current
recommended field separator value is "&#^" (i.e. ampersand hash circumflex).
Subfields (e.g. the subfields the Original Data Elements field) are not separated from each other by a
field separator. The field separator is only used between fields.
Header and trailer records do not contain field separators.
9.3.1.5 Data Encoding

The records contain only US-ASCII characters.
9.3.1.6 Data Type Representation

The following abbreviations are used in the Type column in the tables in section 9.3.
A Alpha Characters.
N Decimal Numeric Digit Characters.
P Space (Pad) Characters.
S Special Characters.
b Binary Data.
To avoid the problems caused by the presence of binary data in the record, each 4-bit sequence
in the original binary value is represented in the field by the ASCII character ("0" to "9", "A" to
F") corresponding to its hexadecimal value. For example, an original binary value of 01011100
is represented in the field by the characters "5C".
The length given for the field is the number of bits in the original data followed by the
corresponding number of hexadecimal characters actually present. For example, b 16 (AN 4)
indicates a 16-bit original value represented in the field by 4 hexadecimal characters.
var(n) Variable Length Field ('n' indicates the maximum theoretical length, not necessarily the actual
length).
Unlike the ISO 8583 variable-length data elements used elsewhere in this specification,
variable-length TLF Extract File fields do not have a fixed-length prefix indicating the actual
data length. Like all fields in a data record, variable-length fields are separated from the next
field by a field separator, and this must be used to determine their actual length.
The length shown in the Type column is the maximum theoretical length, not necessarily the field's
actual length.
9.3.2 Primary Extract Files

The primary extract files have a common format as specified in the table below. The files list the
transactions acquired by SPAN (ATMs and POS terminals) that are switched over the SPAN network –
i.e. it excludes those processed by banks as on-us. All transactions for the SAMA business day are
included. The files include magnetic stripe and EMV transactions.
The files are produced for all SPAN Member Banks and SAMA.
9.3.2.1 Header Record

The header record is optional: it is present only if the Header option is specified at file generation time.

The header record contains the extract name (i.e. "TLF" plus Extract File ID), the institution name, the
starting settlement date, the extract date and the number of records. The format is shown below.
Field Name Description Type
TLF Header ID "HDTLF" – a fixed string indicating a TLF header. A5
Extract File ID Code identifying the extract file type (e.g. 01 - ATM N2
Activity Report).
See section 9.1 for a list of values.
Institution Name Code identifying the institution. A4
See section 10 for a list of values.
Settlement Date Settlement date (or starting settlement date if file N8
covers a range of dates). Format is YYYYMMDD.
Extract Date Extract date. Format is YYYYMMDD. N8
Number of Records The number of data records in the file. N var(8)
Example Record
HDTLF02SAMA200705012007050150000
9.3.2.2 Data Record

Message Type This field specifies the SPAN internal message type N4
of the transaction.
PAN This gives the Primary Account Number, Max length N var(19)
of this field is 19.
See section 3.4.2 for more information.
Processing Code This is SPAN internal value specifying the N6
Processing Code of the transaction.
Transaction Amount The amount of the transaction. N 12
Reconciliation The Reconciliation Amount of the transaction. N 12
Amount
Transmission Date This field holds the transmission date and time. This N 10
and Time is in MMDDhhmmss format. The size of this data is
10 with the first 4 bytes give the date and the
remainder give the time.
Reconciliation This field holds the reconciliation conversion rate. N8
Conversion Rate
System Trace Systems Trace Audit Number. N6


Local Date and Time Local transaction date and time. The format of the N 12
field is YYMMDDhhmmss. Bytes 1 to 6 hold the
date and the remainder hold the local time of the
transaction.
Expiration Date Month and year of expiry of the card. The format is N4
YYMM. Bytes 1-2 hold the year and 3-4 hold the
month.
Conversion Date Month and year of conversion date. The format is N4
YYMM. Bytes 1-2 hold the year and 3-4 hold the
month.
Capture Date Month and day of capture date of transaction. The N4
format is MMDD. Bytes 1-2 hold the month and 3-4
hold the day.
POS Data Code Point of service data code. AN 12
Function Code The function code of the transaction. N3
Message Reason The SPAN message reason code data of the N4
Code transaction.
Card Acceptor Holds the Card Acceptor Business Code of the N4
Business Code transaction.
Reconciliation Date The reconciliation date in the format YYMMDD. N6
Original Amount The original amount data to be displayed. N 12
Acquirer Institution Acquirer institution identification code. N var(10)
Identification Code
Refnum Retrieval reference number. ANP 12
Approval Code Approval Code. ANP 6
Action Code The response code of the transaction. N3


Terminal ID Positions 1-8 give the terminal id field from the log ANS 16
and 8-16 hold additional data for the terminal.
Acceptor ID The card acceptor identification code. ANS 15
Acceptor Name Card acceptor name / location. ANS var(99)
Transaction Currency Transaction currency code. N3
Code
Reconciliation Reconciliation currency code. N3
Currency Code
Additional Amounts Holds information on up to six amounts and related ANS var(120)
account data.
Original Data This field consists of a varying number of subfields. ANS var(58)
Elements
For Reversals, Completions, Representments and
Chargebacks there are six subfields. The subfields
and their formats are defined below.
Original Message Type ID – N 4
Original System Trace Audit Number – N 6
Original Transmission Date and Time – N 10
Original Local Transaction Date and Time – N 12
Original Acquiring Institution ID Code – N..11
Original Forwarding Institution Id Code – N..11
Note: The variable-length Original Acquiring
Institution ID Code and Original Forwarding
Institution Id Code subfields are each preceded by
their original two-digit ISO variable-length field
prefixes.
For Refunds there are two subfields. The subfields
and their formats are defined below.
Original Message Type ID – N 4
Original Retrieval Reference Number – N 12
Transport Data Transport data from the log. ANS var(999)
POS Terminal data POS terminal data from the log. ANS var(999)


Data Record This field is required for 1624 Administrative Advice ANS var(999)
messages and is used to provide details of the card
and its capture.
Transaction Transaction destination institution id. N var(11)
Destination
Transaction Transaction originator institution id. N var(11)
Originator
Net Reconciliation Net Reconciliation Amount. The format is X+N 16. X+N 16
Amount In In the Extract File, the X portion is "-" if the
calculated amount is negative, otherwise "0". This
differs from the X+N format used elsewhere in this
specification.
Receiving Institution Receiving Institution Identification Code. N var(11)
ID
Card Scheme Holds card scheme id. AN var(999)
Sponsor ID
Card Scheme The Card Scheme Information field is used by SPAN AN var(255)
Information to provide the Card Scheme Acquirer Bank with
transaction information necessary to perform
settlement with International Bank Card Schemes.
SPAN POS Terminal The SPAN POS Reconciliation Totals is used to AN var(999)
Reconcile Total carry terminal transaction activity.
Bank Card Scheme This field contains the combined totals of all bank N var(999)
Totals Information card scheme transactions. This field is for statistical
use only, and is not used for financial settlement.
SPAN POS SPAN The SPAN POS SPAN Reconciliation Totals is used AN var(999)
Reconcile Total to carry terminal transaction activity. The transaction
details are calculated by SPAN for each card scheme
accepted at that terminal.


Chip Index This field links a Primary Extract File record to a AN 20
corresponding Secondary Extract File record.
Currently, this field is used to link a chip card
transaction in the Primary Extract File to its EMV
data in a Secondary Extract File.
If this is a chip card transaction, then this field will
match the Chip Index field of the corresponding
record in the Secondary Extract File. The secondary
Extract File record will contain the transaction's
DE 55 EMV data.
Note that this field may also be set for non-chip
transactions. However, if this is not a chip
transaction, then there will be no corresponding
record in the Secondary Extract File. Thus, this field
should be ignored for non-chip transactions.
See section 9.3.3.
Card Product This field contains the card product (Card Scheme) AN 10
identifier of the transaction.
9.3.2.3 Trailer Record

The trailer record is optional: it is present only if the Header option is specified at file generation time.
The format is shown below.
TLF Trailer ID "TRTLF" – a fixed string indicating a TLF trailer. A5
Extract File ID Code identifying the extract file type. N2
Institution Name Code identifying the institution. A4
See section 10 for a list of values.
Settlement Date Settlement date (or starting settlement date if file N8
covers a range of dates). Format is YYYYMMDD.
Extract Date Extract date. Format is YYYYMMDD. N8
Number of Records The number of data records for the institution. N var(8)
Example Record
TRTLF01SAMB200704252007042550000
9.3.3 Secondary Extract Files

The secondary extract files have a common format as specified in the table below. The files list the
transactions acquired by SPAN (ATMs and POS terminals) that are switched over the SPAN network –
i.e. they exclude those processed by banks as on-us. All transactions for the SAMA business day are
included. These extracts include only EMV transactions and the fields contained therein are from
DE 55 of the transaction.
The file is produced for all SPAN Member Banks and SAMA.

9.3.3.1 Header Record

The header record is optional: it is present only if the Header option is specified at file generation time.
The header record in a Secondary Extract File has the same format as the header record in a Primary
Extract File. See section 9.3.2.1 for details.
9.3.3.2 Data Record

Chip Index This field links a Primary Extract File record to a AN 20
corresponding Secondary Extract File record.
Currently, this is used to link a chip transaction in a
Primary Extract File to its EMV data in the
Secondary Extract File.
See section 9.3.2.
Transaction Date Local date. Format is YYDDMM. N6
See Transaction Date field in section 3.4.36 for more
information.
Terminal Type Specifies the type of the terminal. N2
See Terminal Type field in section 3.4.36 for more
information.
Terminal Capabilities Indicates card data input, CVM and security b 24
capabilities of the terminal. (AN 6)
See Terminal Capabilities field in section 3.4.36 for
more information.
Terminal Country Numeric country code for merchant terminal N3
Code location.
See Terminal Country Code field in section 3.4.36
for more information.
Transaction Currency Numeric code for transaction currency. N3
Code
See Transaction Currency Code field in
section 3.4.36 for more information.
Cryptogram Amount Total transaction amount including the cashback N 12
amount in a sale with cash transaction.
See Cryptogram Amount Authorised field in section
3.4.36 for more information.
Cryptogram Used for cashback amount. N 12
Cashback Amount
See Cryptogram Amount Other field in section 3.4.36
for more information.
TVR Status of different functions as seen by the terminal. b 40
(AN 10)
See TVR field in section 3.4.36 for more information.
Unpredictable Value used to provide variability and uniqueness in b 32
number the generation of the application cryptogram. (AN 8)
See Unpredictable Number field in section 3.4.36 for
more information.


Interface Device Interface device serial number. AN 8
Serial Number (IFD)
See IFD Serial # field in section 3.4.36 for more
information.
Cryptogram Authorisation Request Cryptogram (ARQC) for b 64
online transactions or Transaction Certificate (TC) (AN 16)
for offline transactions.
See Cryptogram field in section 3.4.36 for more
information.
Application Retrieved from the card. b 16
Transaction Counter (AN 4)
See ATC field in section 3.4.36 for more information.
(ATC)
ARPC Cryptogram Authorisation Response Cryptogram (ARPC). b 64
(AN 16)
See Authorisation Response Cryptogram and Code
field in section 3.4.36 for more information.
ARPC Response ARPC response code. AN 2
Code
See Authorisation Response Cryptogram and Code
field in section 3.4.36 for more information.
Issuer Application Issuer application data. Maximum length 33 bytes. b var(256)
Data (IAD) First byte indicates length, followed by up to 32 bytes (AN var(64))
of data.
See IAD field in section 3.4.36 for more information.
9.3.3.3 Trailer Record

The trailer record is optional: it is present only if the Header option is specified at file generation time.
The trailer record in a Secondary Extract File has the same format as the trailer record in a Primary
Extract File. See section 9.3.3.3 for details.

Field Values Unique to SPAN
Section 10 Field Values Unique to SPAN
This appendix identifies and describes the fields that must contain values assigned by SPAN. The
Member Banks must use the values assigned to them in these fields in order to properly process data
through the SPAN network.
The table below will be applicable to the following fields.
• DE32 – Acquiring Institution Identification Code
• DE 93 - Transaction Destination Institution Identification Code
• DE 94 - Transaction Originator Institution Identification Code
• DE100 – Receiving Institution Identification Code
• DE 122 – Card Scheme Sponsor ID/Card Scheme ID
• DE 124 – SPAN POS Terminal Reconcile Total
• DE 127 – SPAN POS SPAN Reconcile Total
FIID Name ID
ALBI Al Bilad Bank 636120
ANBB Arab National Bank 588848
BMUS Bank of Muscat 443927
BSFB Al Bank Al Saudi Al Fransi 588845
BSHB Saudi Hollandi Bank 588846
EBIL Emirates Bank International Limited 410685
NBOK National Bank of Kuwait 431361
NCBB National Commercial Bank 588850
RAJB Al-Rajhi Banking and Investment Corporation 588847
RYDB Riyadh Bank 588849
SABB The Saudi British Bank 588851
SAIB Saudi Investment Bank 589206
SAMB SAMBA Financial Group 585265
JAZB Bank Al Jazira 504300
SAMA Saudi Arabian Monetary Agency 123456789
VISA VISA Base 1/Dual CPS 9444444444
MCS MasterCard Credit System (Banknet) 9555555555
MDS MasterCard Debit System MDS 9666666666
SMS VISA SMS 9777777777
AMEX American Express 9333333333

The table below will be applicable to the following fields and the ID includes a 3 digit country code of
the GCC countries participating in GCCNet.
• DE 32 – Acquiring Institution Identification Code
• DE 100 – Receiving Institution Identification Code
FIID Name ID
BFIT Bahrain 048
OMAS Oman 512
KNET Kuwait 414
NAPS Qatar 634
SPAN Saudi Arabia 682
UAES United Arab Emirates 784
The table below highlights the Card Scheme IDs that will be allowed within the SPAN network and are
required as part of the following fields.
• DE 122 – Card Scheme Sponsor ID/Card Scheme ID
• DE 124 – SPAN POS Terminal Reconcile Total
• DE 127 – SPAN POS SPAN Reconcile Total
ID Card Scheme
P1 SPAN
VC Visa Credit & Debit
MC MasterCard Credit
DM MasterCard Debit/MAESTRO
AX Amex
The following codes are valid for DE 43 Card Acceptor Name/Location - sub element 3 (Region).
City Code City

101 Riyadh
102 Derieyyah
103 Oyaynah
104 Rumah
105 Ghoraimla
106 Thadiq
107 Majmaah
108 Houtat Sodair
109 Artaweyyah
110 Tumair

City Code City

111 Ghat
112 Zulfy
113 Shagra
114 Oshaiger
115 Marat
116 Durma
117 Muzahmeyah
118 Haier
119 Kharj
120 Delam
121 Houtat Bani-Tamim
122 Hariq
123 Aflaj
124 Sulayyel
125 Wadi Addawaser
126 Dawadmi
127 Sajer
128 Rafayea
129 Bjadeyyah
130 Quaieyyah
131 Afif
132 Rouaidah
133 Qassab
134 Erkah
201 Makkah
202 Bahrah
203 Jaddah
204 Rabegh
205 Kamel
206 Jomoum
207 Taif

City Code City

208 Geya
209 Turbah
210 Khormah
211 Ranyah
212 Laith
213 Qunfothah
214 Ardeyyah Ashamalyyah
215 Mowaih
216 Dhulam
217 Kouz
218 Bani Saad
219 Maisan
301 Dammam
302 Khobar
303 Thogbah
304 Dhahran
305 Bgaig
306 Ain Dar
307 Salwa
308 Adleyah
309 Qatif
310 Taroot
311 Sehat
312 Safwa
313 Ras Tanourah
314 Jubail
315 Neairyyah
316 Olaya Village
317 Ras Meshab

318 Khafjy
319 Rogey

City Code City

320 Hafr Albatin
321 Kaysomah
322 Um-Alhamam
323 Hafouf
324 Mubarraz
325 Jaffr
326 Omran
327 Holilah
328 Oyoun
329 Garah
401 Buraidah
402 Asyah
403 Bukairiyah
404 Khabra
405 Riyadh Alkabra
406 Badaie
407 Shmasyyah
408 Daryyah
409 Oanisah
410 Oqlat Assokoor

411 Methnab
412 Rass
413 Oyoun Aljwa

414 Mulaida
415 Dekhnah
416 Alfawarah
501 Hail
502 Baga'a
503 Turbah (Hail)

504 Jebah
505 Haiet

City Code City

506 Roudah
507 Shamly
601 Tabouk
602 Taima
603 Beda
604 Dheba
605 Wajh
606 Umloj
607 Skaka
608 Gara
609 Domat Aljandal
610 Tabarjal
611 Arar
612 Jadeedat Arar
613 Toraif
614 Owayqlyyah
615 Rafha
616 Gorayyat
617 Hadiethah
618 Halat Ammar

619 Haql
620 Durrah
701 Madina
702 Khaibar
703 Ola
704 Yetmah
705 Honakeyyah
706 Mahd Athahab
707 Badr
708 Uanbu
709 Ras-Buraidy

City Code City

710 Yanbu Alnakhel
801 Abah
802 Khamees Mushait

803 Ahad Rufaidah
804 Sarat Obaidah
805 Harjah
806 Ghahran Aljanoub
807 Tathleeth
808 Bieshah
809 Sabt Alalaya
810 Ballasmar
811 Tanoumah
812 Nomas
813 Sarh
814 Bashaier
815 Mahail
816 Mujardah Bani-Shehr
817 Shaabain
818 Bareg
819 Ballahmar
820 Baha
821 Mandag
822 Robou Quraish

823 Baljorashy
824 Aqiq
825 Mukhwah
826 Qalwah
827 Jisan
828 Abo Araish

829 Dhamad
830 Ahad Al-Masarha

City Code City

831 Samta
832 Twal
833 Farasan
834 Sabya
835 Biesh
836 Darb
837 Shuqaiq
838 Faifa
839 Najran
840 Ariesh
841 Sharorah

POS DE 24–Function Code & DE 25-Message Reason Code Usage
Appendix A POS DE 24–Function Code & DE 25-Message Reason Code Usage
TO
TO ISSUER TO CSA
TRANSACTION FROM POS RETAILER CASE #
MTI BANK* BANK**
BANK
DESCRIPTION
DE25 DE24 DE25 DE24 DE25 DE24 DE25 DE24
ICS CHIP CARD TRANSACTION (CREDIT PRE-AUTH|COMPLETION)
Pre-Auth 1100 15xx 100 15xx 100 - - - - 1
Pre-Auth Notification 1120 - - - - 15xx 181 15xx 181 2
Pre-Auth Initial
1120 - 182 - - 1004 182 1004 182 3
Completion
Pre-Auth Final
1220 1004 201/2 1004 201/2 1004 280 1004 280 4
Completion
ICS MAGNETIC-STRIPE CARD TRANSACTION (CREDIT PRE-AUTH|COMPLETION)
Pre-Auth 1100 - 100 - 100 - - - - 5
Pre-Auth Notification 1120 - - - - - 181 - 181 6
Pre-Auth Final
1220 - 201/2 - - - 280 - 280 7
Completion
ICS FALLBACK TRANSACTION (CREDIT PRE-AUTH|COMPLETION)
Pre-Auth 1100 1776 100 - - - - - - 8
Pre-Auth Notification 1120 - - - - 1776 181 1776 181 9
Pre-Auth Final
1220 - 201/2 - - 1776 280 1776 280 10
Completion
SPAN/ICS MAGNETIC-STRIPE TRANSACTION (PURCHASE)
Financial Request 1200 - 200 - 200 - - - - 11
Financial Advice
1220 - - - - - 281 - 281 12
(Notification)
SPAN/ICS FALLBACK TRANSACTION (PURCHASE)
Financial Request 1200 1776 200 1776 200 - - - - 13
Financial Advice
1220 - - - - 1776 281 1776 281 14
(Notification)
SPAN/ICS CHIP TRANSACTION (DEBIT/CREDIT PURCHASE)
Version: Error! Unknown document property name.; Issue: August 2008.

Page 486
POS DE 24–Function Code & DE 25-Message Reason Code Usage
Financial Request
1100 15xx 100 15xx 100 - - - - 15
Authorisation
Financial Request
1120 - - - - 15xx 181 15xx 181 16
Notification
Financial Advice
1220 1005 200 1005 200 1005 281 1005 281 17
(Completion)
OTHER FINANCIAL MESSAGES
Offline Advice 1220 1005 200 1005 200 1005 281 1005 281 18
Voice Authorisation 1220 1004 201/2 - - 1004 280 1004 280 19
Offline ICS Refund 1220 1004 200 - - 1004 281 1004 281 21
Fallback ICS Offline

1220 - 200 - - 1776 281 1776 281 22
Refund
Notes:
* For ICS transactions these values are to be used for mapping to appropriate ICS specification
(when required) whilst in SPAN transactions these values represent the actual values.
** If Card Scheme Acquirer Bank exists.

Page 487
DE39 In Financial Advice Transactions
Appendix B DE39 In Financial Advice Transactions
The table below provides the scenarios possible with regards to the handling of DE39 Action Code in
both the 1220 Financial Advice and 1230 Financial Advice Response messages and the action be taken
in such cases.
FINANCIAL FINANCIAL
SCENARIO ACTIONS
CASE ADVICE ADVICE RESPONSE
DESCRIPTION TO BE TAKEN
1220/1221 1230
Approved Message Content Valid Approved Log both Action Codes &
1 Action Code ‘000’ Action Code ‘000’ Remove from SAF
Declined Message Content Valid Approved Log both Action Codes &
2 Action Code ‘nnn’ Action Code ‘000’ Remove from SAF
Approved System/Comms No Response Replay from SAF

3 Problem
Action Code ‘000’
Declined System/Comms No Response Replay from SAF

4 Problem
Action Code ‘nnn’
Approved Message Content Declined Log both Action Codes,

Invalid
5 Action Code ‘000’ Action Code ‘ppp’1 Re-send within retry limit &
Remove from SAF
Declined Message Content Declined Log both Action Codes,
Invalid 1
6 Action Code ‘nnn’ Action Code ‘ppp’ Re-send within retry limit &
Remove from SAF
Note 1: Depending on the value of DE39 Action Code e.g. ‘917 – MAC Key Sync’ in the 1230
Financial Advice Response the 1220 Financial Advice may be repeated i.e. 1221 Financial Advice Repeat message sent
until the retry counters are exhausted before removal from SAF.

Page 488
DE4 & DE30 IN Financial Request/Advice Transactions
Appendix C DE4 & DE30 IN Financial Request/Advice Transactions
There are a number of specific relationships between DE 4 Transaction Amount and DE 30 Original Amounts
mentioned in the SPAN Rules and Standards Technical Books for EFTPOS transactions. The table below has been
constructed based on the following statements in the referenced Technical Book and the notes below the table,
a. SPAN Rules and Standards Technical Book, Part IV - Member Bank Interface, Field
Descriptions, Section 3.4.4 DE 4 – Transaction Amount
b. SPAN Rules and Standards Technical Book, Part IV - Member Bank Interface, Message
Formats, Section 2.9.2 Financial Transaction Advice / Advice Repeat / Response (POS)
REQUEST/ADVICE RESPONSE
CASE DESCRIPTION
DE24 DE4 DE30 DE24 DE4 DE30
APPROVED
1 REQUEST 200 Amt Req - - Amt Req -
1200/1210
DECLINED
REQUEST Originally
2 200 Amt Req - - Zero
Req Amt
1200/1210
APPROVED
Amt Req
3 NOTIFICATION 281 - - Amt Req -
(f. 1210)
1220/1230
DECLINED Originally
Zero Originally
4 NOTIFICATION 281 Req Amt - Zero
(f. 1210) Req Amt
1220/1230 (f. 1210)
APPROVED
5 OFFLINE1 200/281 Amt Req - - Amt Req -
1220/1230
DECLINED
OFFLINE1 Originally
6 200/281 Amt Req - - Zero
Req Amt
1220/1230
APPROVED
COMPLETION2 201/202/ Originally
7 New Amt - New Amt -
280 Auth Amt
1220/1230
DECLINED Originally
COMPLETION2 201/202/ Originally Req Amt
8 New Amt - Zero
1220/1230 280 Auth Amt (New
Amt)
Note 1: Since an offline transaction is equivalent to an original transaction (i.e. DE 24 Function Code is ‘200 – Original
Financial Request/Advice’) as such use of DE30 Original Amounts is not permissible in the 1220 Financial Advice.

Page 489
DE4 & DE30 IN Financial Request/Advice Transactions
Note 2: According to ISO 8583:1993, DE 30 Original Amounts is present in a request or advice if it is a replacement
transaction, previously authorised transaction, representment, partial reversal or partial chargeback. Therefore, DE 30
should be present in a 1220 Financial Advice/1221 Financial Advice Repeat when DE 24 Function Code is ‘201 –
Previously Approved Authorisation (Amount Same)’ and ‘202 – Previously Approved Authorisation (Amount Differs)’. In
addition, this rule also holds true in the case where DE 24 Function Code is ‘280 – Notification of a Previously Approved
Financial Transaction’.
It is present in the response for a partial approval, declined or reject transaction. Therefore, DE 30 Original Amounts
should only be present in 1230 Financial Advice Response messages if DE 39 Action Code indicates a declined response.

Page 490
Usage of Data Elements During EMV Migration
Appendix D Usage of Data Elements During EMV Migration
C-1 DE 3 Processing Code

The usage of the From Account Type subfield in DE 3 has changed from the SPAN1system which uses default value of
“20” and the new SPAN2 system which now correctly uses a default value of “00” where there has not been any
account selection. To enable interoperability between SPAN2 and SPAN1 Member Banks, the new SPAN2 system will
remap Account Type “00” to “20”.
C-2 DE 22 Point of Service Data Code

The SPAN system will include additional validation to prevent SPAN2 transactions being offered to non-chip read
transactions. Based on the understanding that SPAN does not allow SPAN Member Banks to issue Chip Cards before
migrating to SPAN2 MBI, the validation specified in the table below will be applied to the SPAN Card scheme.
ACQUIRER CARD TYPE / CARD READ TECH TXNS ALLOWED
SPAN2 MBI (ATM/POS) Chip Card, Chip read (DE 22.7 = 5) SPAN2 transactions only
SPAN2 MBI (ATM/POS) Any card, Chip not read (DE 22.7 ≠5) SPAN1 transactions only
Note: DE 22.7 represents DE 22 – Point of Service Data Code, Position 7 – Card Data Input Mode.
Any transactions not complying with the above table will be declined with SPAN2 DE 39 Action Code
‘119 – Transaction not permitted to cardholder’.
C-3 DE 43 Card Acceptor Name / Location

The SPAN system will use the mapping rules indicated in the following tables for DE 43.
FROM SPAN (ATM) TO SPAN2 (ATM)
Pos Description Pos Description
01-22 Owner Name 01-22 Owner Name
23 Backslash (\)
Street Name – no value
24 Backslash (\)
23-35 City Name 25-37 City Name
38 Backslash (\)
36-38 Blank, not used 39-48 Postal Code – filled with spaces
49-51 Region – filled with spaces
39-40 Country ‘SA’ 52-54 ISO Country Code (SAU)
FROM SPAN2 (ATM) TO SPAN / (ATM)

01 - var Owner Name 01-22 Owner Name (if >22, then truncate)

Page 491
FROM SPAN2 (ATM) TO SPAN / (ATM)

var Backslash (\)
var - var Street Name
var Backslash (\)
var - var City Name 23-35 City Name (if >13, then truncate)
var Backslash (\)
var - var Postal code (length = 10)
var – var Region (length = 3) 36-38 Blank, not used
var - var ISO Country Code (‘SAU’) 39-40 ISO Country Code ‘SA’
FROM GCC (ATM) TO GCC SPAN2 (ATM)

01-22 Owner Name 01-22 Owner Name
23 Backslash (\)
Street Name – no value
24 Backslash (\)
23-35 City Name 25-37 City Name
38 Backslash (\)
36-38 Blank, not used 39-48 Postal Code – filled With Spaces
49-51 Region – filled with spaces
39-40 Country ‘SA’ 52-54 ISO Country Code (SAU)
FROM GCC SPAN2 (ATM) TO GCC / (ATM)

01 – var Owner Name 01-22 Owner Name (if >22, then truncate)
var Backslash (\)
var Backslash (\)
var-var City Name 23-35 City Name (if >13, then truncate)
var Backslash (\)
var - var Region (length = 3) 36-38 Blank, not used
var - var ISO Country Code (‘SAU’) 39-40 ISO Country Code ‘SA’

Page 492
FROM SPAN (POS) TO SPAN2 (POS)

F43: 01 - 20 Retailer Name - Arabic F47: 01 - 20 Arabic Retailer Name
F43: 21- 40 Owner Name - English F43: 01 - 22 English Owner Name
F43: 23 Backslash ( \ )
Street Name - no value
F43: 25 - 37 City Name – filled with spaces
F43: 39 – 48 Postal code - filled with spaces
F43: 49 - 51 Region - filled with spaces
F43: 52 - 54 ISO Country Code (SAU)
FROM SPAN2 (POS) TO SPAN (POS)

F47: 01 - 20 Arabic Retailer Name F43: 01 - 20 Arabic Retailer Name
F43: 01- var English Owner Name F43: 21 - 40 English Owner Name (if > 22, then truncate)
F43: var Backslash (\)
F43: var - var Street Name
F43: var - var City Name
F43: var - var Postal code
F43: var - var Region
F43: var - var ISO Country Code (‘SAU’)
Note:
1. Field 43 mapping between GCC and SPAN2 is exactly the same as SPAN and SPAN2 for ATM.
2. Field 43 mapping between SPAN2 and VISA BASE1 is exactly the same as SPAN2 and VISA SMS and vice versa.
3. The value of ‘SAU’ is the standard ISO Alpha Country (3-char) code for Saudi Arabia. This value can be found also
in VISA and MC and ISO standard specification document.
4. For SPAN2 to SPAN / SPAN to SPAN2 for POS, there are two fields involved, namely F47 – which contains the
Arabic Retailer Name, Field 43 which contains the English Owner Name. Refer to table for SPAN2 (POS) to SPAN

Page 493
(POS) and vice versa in the above tables. If the Arabic Retailer Name is not available, the default value is “Arabic
Retailer Name Unavailable” in English.
FROM MASTERCARD DEBIT TO SPAN2

01 - 22 Owner Name 01 - 22 Owner Name
23 Space 23 Backslash ( \ )
24 Backslash ( \ )
24 - 36 City 25 - 37 City Name
37 Space 38 Backslash ( \ )
39 - 48 Postal code – filled with spaces
49 - 51 Region – filled with spaces
38 - 40 Country Code (SAU) 52 - 54 ISO Country Code (SAU)
FROM SPAN2 (ATM / POS) TO MASTERCARD DEBIT

01 - var Owner Name 01 - 22 Owner Name (if > 22, then truncate)
Var Backslash (\) 23 Space
var Backslash (\)
var – var City Name 24 - 36 City Name (if > 13, then truncate)
var Backslash (\) 37 Space
var - var Region (length = 3)
var - var ISO Country Code (‘SAU’) 38 - 40 ISO Country Code (‘SAU’)
FROM SPAN2 (POS) TO MASTERCARD CREDIT

01 - var Owner Name 01 - 22 Owner Name (if > 22, then truncate)
Var Backslash (\) 23 Space
var Backslash (\)
var – var City Name 24 - 36 City Name (if > 13, then truncate)
var Backslash (\) 37 Space

Page 494
FROM SPAN2 (POS) TO MASTERCARD CREDIT

var - var ISO Country Code (‘SAU’) 38 - 40 ISO Country Code (‘SAU’)
FROM SPAN2 TO VISA BASE 1

01 - var Owner Name 01 – 25 Owner Name (if > 25, then truncate)
Var Backslash (\) Space
var Backslash (\)
var – var City Name 26 – 38 City Name (if > 13, then truncate)
var Backslash (\) Space
var - var ISO Country Code (‘SAU’) 39 - 40 ISO Country Code ‘SA’
FROM SPAN2 TO VISA SMS

01 - var Owner Name 01 – 25 Owner Name (if > 25, then truncate)
Var Backslash (\) Space
var Backslash (\)
var – var City Name 26 – 38 City Name (if > 13, then truncate)
var Backslash (\) Space
var - var ISO Country Code (‘SAU’) 39 - 40 ISO Country Code ‘SA’
FROM VISA SMS TO SPAN2

01 - 25 Owner Name 01 - 25 Owner Name
26 Backslash ( \ )

Page 495
FROM VISA SMS TO SPAN2

27 Backslash ( \ )
26 - 38 City 28 - 40 City Name
41 Backslash ( \ )
42 - 51 Postal code – filled with spaces
52 - 54 Region – filled with spaces
39 - 40 Country Code (SA) 54 - 57 ISO Country Code (SAU)
C-4 DE 47 National Additional Data – Card Acceptor Name (Arabic)

The SPAN system will turn the high bit on in DE 47 for SPAN1 POS terminal transactions sent to SPAN2 Member
Banks and it will turn the high bit off in DE 47 for SPAN2 POS terminal transactions sent to SPAN1 Member Banks
to ensure interoperability during migration of Member Banks and POS terminals from SPAN1 to SPAN2
specifications.
C-5 DE 122 Card Scheme Sponsor ID/Card Scheme ID

SPAN1 terminal messages have Visa scheme received as ‘V’ and not ‘VC’ or ‘VD’. The SPAN system will map the
Visa scheme as ‘VC’ for all SPAN1 terminal Visa scheme messages (i.e. 1100, 1110, 1120, 1121, 1130, 1200, 1210,
1220, 1221, 1230, 1420, 1421 & 1430) to ensure interoperability with the SPAN2 Member Bank interface.
C-6 DE 124 SPAN POS Terminal Reconcile Total

SPAN1 terminal messages have Visa scheme received as ‘V’ and not ‘VC’ or ‘VD’. The SPAN system will map
subfield 124.1 as ‘VC’ for all SPAN1 terminal Visa scheme reconciliation messages (i.e. 1524 & 1525) to ensure
interoperability with SPAN2 Member Bank interface.
C-7 DE 127 SPAN POS SPAN Reconcile Total

SPAN1 terminal messages have Visa scheme received as ‘V’ and not ‘VC’ or ‘VD’. The SPAN system will map
subfield 124.1 as ‘VC’ for all SPAN1 terminal Visa scheme reconciliation messages (i.e. 1524 & 1525) to ensure
interoperability with SPAN2 Member Bank interface.

Page 496
DE 123 – Card Scheme Information Usage Detailed Description
Appendix E DE 123 – Card Scheme Information Usage Detailed Description
This appendix details the requirements for DE 123 – Card Scheme Information based on the
source of the transaction and the destination. For a definition of DE 123 refer to 3.4.61 in the
Field Descriptions section of Member Bank Interface Specification document.
• The bitmap must be present for all transactions even when no other sub-elements are present.
• Mandatory and conditional sub-elements must be present as described.
• The presence of any additional (i.e. non-mandatory/conditional) DE 123 sub-elements shall
NOT result in a decline or rejection but should be ignored by the recipient of the message.
• The values in this data element are from the relevant scheme data elements, which in some
cases may also be the same value as the SPAN interface values.
• Numeric data elements are to be padded with leading zeros and alphanumeric data elements
are to be padded with trailing spaces (refer to section 3.3.7).
• In the event a mandatory/conditional sub-element is missing the transaction will be declined
with ‘904’ indicating ‘Format error’.
The structure of the appendix is as follows,

• ATM
o SAMA ATM – SPAN Transaction
o SPAN Member Bank ATM – SPAN Transaction
o SPAN Member Bank ATM / GCC Member Bank ATM – GCC Transaction
o SPAN Member Bank ATM – MasterCard Transaction
o SPAN Member Bank ATM – Visa Transaction
o SPAN Member Bank Back-office Terminal – Visa SMS Exception Messages
o Visa Member Bank Back-office Terminal – Visa SMS Exception Messages
• POS
o SPAN POS – SPAN Transaction
o SPAN POS – AMEX Transaction
o SPAN POS – Visa Transaction
o SPAN POS – MasterCard Credit Transaction
o SPAN POS – MasterCard Debit Transaction
• Non-KSA Acquired
o MasterCard MDS – MasterCard Transaction

Page 497
ATM
SAMA ATM – SPAN TRANSACTION
Request (RQ)
KSA Issuer
SAMA ATM SPAN
Bank
Response (RP)
RQ Response (RP) Message
Cash Withdrawal
Balance Enquiry
Request (RQ) /
1200/1210
1200/1210
1420/1430
Reversal
Position Description
M M M
123.0 DE 123 Bitmap
RP
M M M
RQ
- - -
123.1 Trace Audit Number
RP
- - -
RQ
- - -
123.2 Retrieval Reference Number
RP
- - -
RQ
- - -
123.3 Acquiring Institution Identification Code
RP
- - -
RQ
- - -
123.4 Original Response Code
RP
- - -
RQ
- - -
123.5 Authorisation Source Code
RP
- - -
RQ
123.6 Reserved for future use - - -

Page 498
Response (RP) Message
Cash Withdrawal
Balance Enquiry
Request (RQ) /
1200/1210
1200/1210
1420/1430
Reversal
RP
- - -
RQ
- - -
123.7 CPS Authorization Characteristics Indicator
RP
- - -
RQ
- - -
123.8 Transaction Identifier
RP
- - -
RQ
- - -
123.9 Message Reason Code
RP
- - -
RQ
- - -
123.10 CVV/iCVV Results Code
RP
- - -
RQ
- - -
123.11 Network Identification Code – 4N 4-bit BCD
RP
- - -
RQ
- - -
123.12 STIP/Switch Reason Code – 4N 4-bit BCD
RP
- - -
RQ
- - -
123.13 Reserved for future use
RP
- - -
RQ
- - -
123.14 Fraud Data
RP
- - -
RQ
123.15 Reimbursement Attribute - - -

Page 499
Cash Withdrawal
Balance Enquiry
Request (RQ) /
1200/1210
1200/1210
1420/1430
Reversal
RP
- - -
RQ
- - -
123.16 Decimal Positions Indicator – 6N 4-bit BCD
RP
- - -
RQ
- - -

RP
- - -
RQ
- - -
123.18 Settlement Date – 4N 4-bit BCD
RP
- - -
RQ
- - -
123.19 PAN extended, country code – 3N
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
Multiple Clearing Sequence Number. 2N 4-bit
123.23
BCD
RP
- - -

Page 500
Cash Withdrawal
Balance Enquiry
Request (RQ) /
1200/1210
1200/1210
1420/1430
Reversal
- - -
123.24 Forwarding Institution Identification Code
RP
- - -

Page 501
SPAN MEMBER BANK ATM – SPAN TRANSACTION
Request (RQ) Request (RQ)

KSA Acquirer KSA Issuer
SPAN
Bank Bank
Response (RP) Response (RP)
Cash Withdrawal
Balance Inquiry
Mini Statement
Request (RQ) /
1200/1210
1200/1210
1200/1210
1200/1210
1420/1430
Purchase
Reversal
M M M M M
123.0 DE 123 Bitmap
RP
M M M M M
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
Acquiring Institution Identification
123.3
Code
RP
- - - - -
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
RP
- - - - -

Page 502
Cash Withdrawal
Balance Inquiry
Mini Statement
Request (RQ) /
1200/1210
1200/1210
1200/1210
1200/1210
1420/1430
Purchase
Reversal
- - - - -
CPS Authorization Characteristics
123.7
Indicator
RP
- - - - -
RQ
- - - - -
123.8 Transaction Identifier RP
- - - - -
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
Network Identification Code – 4N 4-
123.11
bit BCD
RP
- - - - -
RQ
- - - - -
123.12
BCD
RP
- - - - -
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
123.14 Fraud Data
RP
- - - - -
RQ
- - - - -
123.15 Reimbursement Attribute
RP
- - - - -

Page 503
Cash Withdrawal
Balance Inquiry
Mini Statement
Request (RQ) /
1200/1210
1200/1210
1200/1210
1200/1210
1420/1430
Purchase
Reversal
- - - - -
Decimal Positions Indicator – 6N 4-
123.16
bit BCD
RP
- - - - -
RQ
- - - - -

RP
- - - - -
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
Multiple Clearing Sequence Number.
123.23
2N 4-bit BCD
RP
- - - - -
RQ
123.24 Forwarding Institution Identification - - - - -

Page 504
Cash Withdrawal
Balance Inquiry
Mini Statement
Request (RQ) /
1200/1210
1200/1210
1200/1210
1200/1210
1420/1430
Purchase
Reversal
Code
RP
- - - - -

Page 505
SPAN MEMBER BANK ATM / GCC MEMBER BANK ATM – GCC TRANSACTION
Request (RQ)
KSA Acquirer
SPAN GCC-Net
Bank
Response (RP)
- AND -
Request (RQ)
KSA Issuer
GCC-Net SPAN
Bank
Response (RP)
Cash Withdrawal
Balance Inquiry
Request (RQ) /
1200/1210
1200/1210
1420/1430
Reversal
M M M
123.0 DE 123 Bitmap
RP
M M M
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -

Page 506
Cash Withdrawal
Balance Inquiry
Request (RQ) /
1200/1210
1200/1210
1420/1430
Reversal
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -

Page 507
Cash Withdrawal
Balance Inquiry
Request (RQ) /
1200/1210
1200/1210
1420/1430
Reversal
- - -
123.14 Fraud Data
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -

RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ

Page 508
Cash Withdrawal
Balance Inquiry
Request (RQ) /
1200/1210
1200/1210
1420/1430
Reversal
RP
- - -
RQ
- - -
123.23
BCD
RP
- - -
RQ
- - -
RP
- - -

Page 509
SPAN MEMBER BANK ATM – MASTERCARD TRANSACTION
Request (RQ)
KSA Acquirer
SPAN MasterCard-MDS
Bank
Response (RP)
Cash Withdrawal
Balance Inquiry
Request (RQ) /
1200/1210
1200/1210
1420/1430
Reversal
RQ
M M M
123.0 DE 123 Bitmap
RP
M M M
RQ
- - -
RP
M M -
RQ
- - -
RP
M M -
RQ
- - -
RP
M M -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -

Page 510
Cash Withdrawal
Balance Inquiry
Request (RQ) /
1200/1210
1200/1210
1420/1430
Reversal
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ

RP
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
123.14 Fraud Data
RP
- - -
RQ
- - -
RP
- - -

Page 511
Cash Withdrawal
Balance Inquiry
Request (RQ) /
1200/1210
1200/1210
1420/1430
Reversal
RQ
- - -
RP
- - -
RQ
- - -
RP
RQ - - -
- - -
RP
C C -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
123.23
BCD
RP
- - -
RQ
123.24 Forwarding Institution Identification Code - - -

Page 512
Cash Withdrawal
Balance Inquiry
Request (RQ) /
1200/1210
1200/1210
1420/1430
Reversal
RP
M M -

Page 513
SPAN MEMBER BANK ATM – VISA TRANSACTION
Request (RQ)
KSA Acquirer
SPAN VISA-SMS
Bank
Response (RP)
Cash Withdrawal
Balance Inquiry
Request (RQ) /
Administrative
Message (Card
Online Fraud
Misdispense
Adjustment
Reporting
1200/1210
1200/1210
1220/1230
1420/1430
1624/1634
9620/9630
Reversal
RQ
M M M M M M
123.0 DE 123 Bitmap
RP
M M M M M M
M
RQ
- - - - -
(A)
RP
M M M - - ME
M
RQ
- - - M C (A)
(B)
RP
M M ME - ME CE
RQ
- - - - - -
Acquiring Institution
123.3
Identification Code
RP
M M - - - -
RQ
- - - - - -
RP
C C - - - -
RQ
- - - - - -
123.5 Response Reason/Source Code
RP
C C - - - -
RQ
- - - - - -
RP
- - - - - -

Page 514
Cash Withdrawal
Balance Inquiry
Request (RQ) /
Administrative
Message (Card
Online Fraud
Misdispense
Adjustment
Reporting
1200/1210
1200/1210
1220/1230
1420/1430
1624/1634
9620/9630
Reversal
RQ
M M C (C) C (C) - -
CPS Authorization
123.7
Characteristics Indicator
RP
C C CE CE - -
RQ
- - C (C) C (C) - C (B)
RP
C C CE CE - CE
RQ
- - M M - -
RP
- - ME ME - -
RQ
- - - - - -
RP
C C - - - -
M M M
RQ
M M M
Network Identification Code – (B) (B) (B)
123.11
4N 4-bit BCD
RP
M M ME ME ME ME
RQ
- - - - - -
STIP/Switch Reason Code –
123.12
4N 4-bit BCD
RP
C C - - - -
RQ
- - - - - -
RP
- - - - - -
RQ
- - - - - M
123.14 Fraud Data
RP
- - - - - ME
RQ
- - - - - M
RP
- - - - - ME

Page 515
Cash Withdrawal
Balance Inquiry
Request (RQ) /
Administrative
Message (Card
Online Fraud
Misdispense
Adjustment
Reporting
1200/1210
1200/1210
1220/1230
1420/1430
1624/1634
9620/9630
Reversal
RQ
- - - - - -
Decimal Positions Indicator –
123.16
6N 4-bit BCD
RP
- - - - - -
RQ
- - - - - -

RP
- - - - - -
RQ
- - - - M -
Settlement Date – 4N 4-bit
123.18
BCD
RP
M M - - ME M
RQ
- - - - - -
PAN extended, country code –
123.19
3N
RP
C C - - - -
RQ
- - - - - -
RP
- - - - - -
RQ
- - - - - -
RP
- - - - - -
RQ
- - - - - -
RP
- - - - - -
RQ
- - - - - C (D)
Multiple Clearing Sequence
123.23
Number. 2N 4-bit BCD
RP
- - - - - CE
RQ
123.24 Forwarding Institution - - - - - -

Page 516
Cash Withdrawal
Balance Inquiry
Request (RQ) /
Administrative
Message (Card
Online Fraud
Misdispense
Adjustment
Reporting
1200/1210
1200/1210
1220/1230
1420/1430
1624/1634
9620/9630
Reversal
Identification Code
RP
- - - - - -
Notes:
The following notes apply to all Visa SMS tables.
(A) This field must contain the value from the original transaction. If there is no original
transaction, the value should be generated by the Member Bank and should be the
same value as DE 11 System Trace Audit Number (STAN) or DE 37 Retrieval
Reference Number (RRN) as appropriate.
(B) Copy value from original 1210 response, if present, i.e. value in DE 123.
(C) Copy value from original 1210 response only if present and ‘qualified by Visa’, i.e.
DE123.7 value is present and is not ‘N’.
(D) This field is optional in a 9620 notification, but if present, it must be from the
original transaction.
(E) Copy value from original 1422 chargeback, if present, i.e. value in DE 123.

Page 517
SPAN MEMBER BANK BACK-OFFICE TERMINAL – VISA SMS EXCEPTION

MESSAGES
This section deals with outgoing Visa SMS exception messages (for further details refer to the
latest Visa V.I.P. Systems SMS ATM Processing Specifications).
Acquirers can initiate the following transactions (refer to details below),

• Adjustments (back-office)
• Representments
• Fee Collection & Funds Disbursements
Acquirers can receive the following transactions (refer to the proceeding section Visa Member
Bank Back-office Terminal – Visa SMS Exception Messages),
• Chargeback
• Chargeback Reversals
• Fee Collection & Funds Disbursements
A member must decide how to set up its exception handling interface. Exception handling is a
process in which staff members carry out the following activities as a minimum:
• Accumulate exceptions during the day
• Conduct inquiries
• Follow up on correspondence
• Submit adjustment transactions to the interchange system
Members typically establish a workstation platform for this purpose. The workstation can be a
stand-alone system, can be connected to the member’s host, or connected to both.
Once a member is ready to transmit the accumulated exception items, the exception handling
system is connected to SMS.

Page 518
Office Adjustment
1220/1230 Back
Representment
Request (RQ) /
Acquirer Fee
Collection /
1220/1230
1220/1230
RQ
M M M
123.0 DE 123 Bitmap
RP
M M M
M
RQ
- -
(E)
RP
ME - -
M M
RQ
-
(E) (B)
RP
ME - ME
RQ
- - -
Acquiring Institution
123.3
Identification Code
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
C (E) - C (C)
CPS Authorization
123.7
Characteristics Indicator
RP
CE - CE
RQ
C (E) - C (C)
RP
CE - CE

Page 519
Office Adjustment
1220/1230 Back
Representment
Request (RQ) /
Acquirer Fee
Collection /
1220/1230
1220/1230
RQ
M M M
RP
ME ME ME
RQ
- - -
RP
- - -
M M
RQ
M
Network Identification Code – (B) (B)
123.11
4N 4-bit BCD
RP
ME ME ME
RQ
- - -
STIP/Switch Reason Code – 4N
123.12
4-bit BCD
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
123.14 Fraud Data
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
Decimal Positions Indicator –
123.16
6N 4-bit BCD
RP
- - -
RQ

Page 520
Office Adjustment
1220/1230 Back
Representment
Request (RQ) /
Acquirer Fee
Collection /
1220/1230
1220/1230
RP
- - -
RQ
- - -
Settlement Date – 4N 4-bit
123.18
BCD
RP
- - -
RQ
- - -
PAN extended, country code –
123.19
3N
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
Multiple Clearing Sequence
123.23
Number. 2N 4-bit BCD
RP
- - -
RQ
- - -
Forwarding Institution
123.24
Identification Code
RP
- - -

Page 521
VISA MEMBER BANK BACK-OFFICE TERMINAL – VISA SMS EXCEPTION

MESSAGES
This section deals with incoming Visa SMS exception messages (for further details refer to the
latest Visa V.I.P. Systems SMS ATM Processing Specifications).
Acquirer Bound
Request (RQ) /
Response (RP)
Chargeback/
Issuer Fee
1420/1430
1422/1432
1422/1432
RQ
M M M
123.0 DE 123 Bitmap
RP
M M M
RQ
- M M
RP
- ME ME
RQ
M M M
RP
ME ME ME
RQ
M M M
RP
ME ME ME
RQ
123.4 Original Response Code - - -

Page 522
Acquirer Bound
Request (RQ) /
Response (RP)
Chargeback/
Issuer Fee
1420/1430
1422/1432
1422/1432
RP
- - -
RQ
- - -
RP
- - -
RQ - - -
RP
- - -
RQ
C C -
123.7
Indicator
RP
CE CE -
RQ
C C -
RP
CE CE -
RQ
M M M
RP
ME ME ME
RQ
- - -
RP
- - -
M
RQ
M M
Network Identification Code – 4N 4-bit (B)
123.11
BCD
RP
ME ME ME
RQ
C C C
123.12
BCD
RP
CE CE CE
RQ

Page 523
Acquirer Bound
Request (RQ) /
Response (RP)
Chargeback/
Issuer Fee
1420/1430
1422/1432
1422/1432
RP
- - -
RQ
- - -
123.14 Fraud Data
RP
- - -
RQ - - -
RP
- - -
RQ
- - -
123.16
BCD
RP
- - -
RQ
- - -

RP
- - -
RQ
M M M
RP
ME ME ME
RQ
C M -
RP
CE ME -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -

Page 524
Acquirer Bound
Request (RQ) /
Response (RP)
Chargeback/
Issuer Fee
1420/1430
1422/1432
1422/1432
RQ
- - -
RP
- - -
RQ
- - -
Multiple Clearing Sequence Number. 2N
123.23
4-bit BCD
RP
RQ - - -
- - -
Forwarding Institution Identification
123.24
Code
RP
- - -

Page 525
SPAN POS – SPAN TRANSACTION
KSA Issuer
Bank
KSA Acquirer
EFTPOS SPAN
Bank
DE123 is not present for SPAN POS transactions (refer to the definition of DE 123 in section
3.4.61).
SPAN POS – AMEX TRANSACTION
AMEX
(SAIB)
KSA Acquirer
EFTPOS SPAN
Bank
DE123 is not present for SPAN POS transactions (refer to the definition of DE 123 in section
3.4.61).

Page 526
SPAN POS – VISA TRANSACTION
VISA-BASE I
Request (RQ)
KSA Acquirer
EFTPOS SPAN
Bank
Response (RP)
Note: When the ‘KSA Acquirer Bank’ is not the ‘Card Scheme Acquirer Bank’, the ‘Card
Scheme Acquirer Bank’ will receive DE 123 – Card Scheme Information.
Completion / Final
Initial Completion
Request (RQ) /
1120/1130
1220/1230
1420/1430
Reversal
RQ
M M M
123.0 DE 123 Bitmap
RP
- - -
RQ
M M M
RP
- - -
RQ
M M M
RP
- - -
RQ
M M M
RP
- - -
RQ
- - -
RP
- - -

Page 527
Completion / Final
Initial Completion
Request (RQ) /
1120/1130
1220/1230
1420/1430
Reversal
RQ
C C C
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
C C -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -

Page 528
Completion / Final
Initial Completion
Request (RQ) /
1120/1130
1220/1230
1420/1430
Reversal
RQ
- - -
123.14 Fraud Data
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -

RP
- - -
RQ
- - -
RP
- - -
RQ
C C C
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ

Page 529
Completion / Final
Initial Completion
Request (RQ) /
1120/1130
1220/1230
1420/1430
Reversal
RP
- - -
RQ
- - -
123.23
BCD
RP
- - -
RQ
- - -
RP
- - -

Page 530
SPAN POS – MASTERCARD CREDIT TRANSACTION
MasterCard-CIS
Request (RQ)
KSA Acquirer
EFTPOS SPAN
Bank
Response (RP)
Completion / Final
Initial Completion
Request (RQ) /
1120/1130
1220/1230
1420/1430
Reversal
RQ
M M M
123.0 DE 123 Bitmap
RP
- - -
RQ
M M M
RP
- - -
RQ
M M M
RP
- - -
RQ
M M M
RP
- - -
RQ
- - -
RP
- - -

Page 531
Completion / Final
Initial Completion
Request (RQ) /
1120/1130
1220/1230
1420/1430
Reversal
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -

Page 532
Completion / Final
Initial Completion
Request (RQ) /
1120/1130
1220/1230
1420/1430
Reversal
RQ
- - -
123.14 Fraud Data
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
123.16
Decimal Positions Indicator – 6N 4-bit BCD
(D)
RP
- - -
RQ
- - -

RP
- - -
RQ
C C -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ

Page 533
Completion / Final
Initial Completion
Request (RQ) /
1120/1130
1220/1230
1420/1430
Reversal
RP
- - -
RQ
- - -
123.23
BCD
RP
- - -
RQ
M M M
RP
- - -

Page 534
SPAN POS – MASTERCARD DEBIT TRANSACTION
MasterCard-MDS
Request (RQ)
KSA Acquirer
EFTPOS SPAN
Bank
Response (RP)
Completion / Final
Initial Completion
Request (RQ) /
1120/1130
1220/1230
1420/1430
Reversal
RQ
M M M
123.0 DE 123 Bitmap
RP
- - -
RQ
M M M
RP
- - -
RQ
M M M
RP
- - -
RQ
M M M
RP
- - -
RQ
- - -
RP
- - -

Page 535
Completion / Final
Initial Completion
Request (RQ) /
1120/1130
1220/1230
1420/1430
Reversal
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -

Page 536
Completion / Final
Initial Completion
Request (RQ) /
1120/1130
1220/1230
1420/1430
Reversal
RQ
- - -
123.14 Fraud Data
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -

RP
- - -
RQ
C C -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ
- - -
RP
- - -
RQ

Page 537
Completion / Final
Initial Completion
Request (RQ) /
1120/1130
1220/1230
1420/1430
Reversal
RP
- - -
RQ
- - -
123.23
BCD
RP
- - -
RQ
M M M
RP
- - -

Page 538
NON-KSA ACQUIRED
MASTERCARD MDS – MASTERCARD TRANSACTION
Request (RQ)
KSA Issuer
MasterCard-MDS SPAN
Bank
Response (RP)
Cash Withdrawal
Balance Inquiry
Request (RQ) /
ATM Reversal
POS Reversal
POS Purchase
1200/1210
1200/1210
1420/1430
1200/1210
1420/1430
RQ
M M M M M
123.0 DE 123 Bitmap
RP
M M M M -
RQ
M M M M M
RP
ME ME ME ME -
RQ
M M M M M
RP
ME ME ME ME -
RQ
M M M M M
RP
ME ME ME ME -
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
RP
- - - - -
RQ
123.6 Reserved for future use - - - - -

Page 539
Cash Withdrawal
Balance Inquiry
Request (RQ) /
ATM Reversal
POS Reversal
POS Purchase
1200/1210
1200/1210
1420/1430
1200/1210
1420/1430
RP
- - - - -
RQ
- - - - -
123.7
Indicator
RP
- - - - -
RQ - - - - -
RP
- - - - -
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
Network Identification Code – 4N 4-bit
123.11
BCD
RP
- - - - -
RQ
- - - - -
123.12
BCD
RP
- - - - -
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
123.14 Fraud Data
RP
- - - - -
RQ
123.15 Reimbursement Attribute - - - - -

Page 540
Cash Withdrawal
Balance Inquiry
Request (RQ) /
ATM Reversal
POS Reversal
POS Purchase
1200/1210
1200/1210
1420/1430
1200/1210
1420/1430
RP
- - - - -
RQ
- - - - -
123.16
BCD
RP
- - - - -
RQ - - - - -

RP
- - - - -
RQ
M M M M M
RP
ME ME ME ME -
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
RP
- - - - -
RQ
- - - - -
Multiple Clearing Sequence Number. 2N
123.23
4-bit BCD
RP
- - - - -

Page 541
Cash Withdrawal
Balance Inquiry
Request (RQ) /
ATM Reversal
POS Reversal
POS Purchase
1200/1210
1200/1210
1420/1430
1200/1210
1420/1430
RQ
M M M M M
Forwarding Institution Identification
123.24
Code
RP
ME ME ME ME -

Page 542
DE 39 Action Code
Appendix F DE 39 Action Code
The usage of a 3 digit Action Code in the new SPAN Member Bank Interface will require remapping for transactions
that are routed to and from destinations which use a 2 digit Response Code. The tables below specify the mapping rules
that will apply for each such routing scenario.
SRC DEST SRC DEST

SPAN2
SPAN2 SPAN1 SPAN1
RC RC RC RC
000 00 00 000
001 00 01 107
002 01 02 108
003 11 04 207
100 05 05 100
101 54 06 909
102 59 07 207
103 60 08 911
104 62 09 923
105 66 10 002
106 75 11 003
107 01 12 902
108 02 13 110
109 12 14 111
110 13 15 912
111 14 19 903
112 63 30 904
114 42 31 908
115 40 33 201
116 51 34 202
117 55 35 203
118 56 36 204
119 57 37 205
120 58 38 206
121 61 39 114
122 63 40 115
123 65 41 208

Page 543
DE 39 Action Code
SRC DEST SRC DEST

SPAN2
SPAN2 SPAN1 SPAN1
RC RC RC RC
125 56 42 114
126 63 43 209
127 63 44 114
128 87 51 116
129 59 52 114
180 V1 53 114
181 V2 54 101
182 V3 55 117
183 V4 56 118
184 V5 57 119
185 V6 58 120
186 V7 59 102
200 04 60 103
201 00 61 121
202 00 62 104
203 01 63 122
204 11 64 110
205 05 65 123
206 54 66 105
207 59 67 202
208 60 75 106
209 62 81 907
210 66 87 919
902 75 88 921
903 01 90 906
904 02 91 907
906 12 92 908
907 13 93 902
908 14 94 913
909 63 95 915
910 42 96 909
911 91 V1 180
912 51 V2 181

Page 544
DE 39 Action Code
SRC DEST SRC DEST

SPAN2
SPAN2 SPAN1 SPAN1
RC RC RC RC
913 94 V3 182
915 95 V4 183
916 63 V5 184
917 87 V6 185
918 87 V7 186
919 87
920 88
921 88
922 06
923 09

Page 545
SPAN2 Mapping of DE 24 Function Codes & DE 25 Message Reason Codes To
VISA SMS Codes
Appendix G SPAN2 Mapping of DE 24 Function Codes & DE 25

Message Reason Codes To VISA SMS Codes
Appendix G.1 Adjustment Message Reason Code Table

The table shows the correspondence between the specific Visa SMS Message Reason Codes in
DE 123.9 or F63.3 and the (new) general MBI Message Reason Codes in DE 25. For example, an
outbound adjustment with Visa code 2001, 2002, 2102, 2108, 2201 or 2202 in DE 123.9 would have
1376 in DE 25. Note that there is not a one-to-one mapping between the Visa codes and the MBI codes,
which differs from some other MBI usages of DE 25.
Cash Disbursement Adjustment – Misdispense
SPAN SPAN Meaning Visa Code Visa Meaning Notes
Code
1376 Misdispense Adjustment 2002 Wrong amount due to ATM
misdispense (online
correction)
1376 Misdispense Adjustment 2102 Approved transaction,
previously reversed when no
confirmation received from
point of service, did complete
1376 Misdispense Adjustment 2201 Plus – Approved transaction,
previously reversed when no
confirmation received from
point of service, did complete
1376 Misdispense Adjustment 2202 Plus – Partial dispense
detected, did complete.
Back Office Adjustment
Code
1377 Back Office Adjustment 2004 Acquirer correction (back-
office adjustment)
Unknown Adjustment
Code
1376 Misdispense Adjustment 2001 Transaction voided by
cardholder (online correction)
1377 Back Office Adjustment 2108 Credit adjustment, duplicate
correction
1377 Back Office Adjustment 2006 Plus – Reversal of a previous
credit adjustment (back-office
correction used only to back
out a 2002)

Page 546
VISA SMS Codes
1377 Back Office Adjustment 2008 Plus – Reversal of a previous

debit adjustment (back-office
correction used only to back
out a 2004)
Cash Disbursement Adjustment – Visa
Code
1378 Visa Adjustment 2013 ATM Format Conversion
Issuer Credit or Debit
Notes
(all) Visa codes and meanings taken from [SMSAPS] section 4.1.3.1 and [SMSATS1]
section 4.75.6 tables 4-30 and 4-31. SPAN codes are all new private codes.
Appendix G.1.1 Fee Collection / Funds Disbursement Message Reason Code Mapping
Table
The table shows the mapping between the specific Visa SMS Message Reason Codes in DE 123.9 or
F63.3 and the (new) general MBI Message Reason Codes in DE 25. Again, there is not a one-to-one
mapping.
Fee Collection / Funds Disbursement
SPAN SPAN Meaning Visa Code Notes
Code
7600 Acquirer-Generated Fee Any valid Acquirer-Generated Fee (a)
Collection Collection code in [SMSATS1]
section 4.75.6 tables 4-30 or 4-31.
7601 Acquirer-Generated Fee Any valid Acquirer-Generated Funds (a)
Payment Disbursement code in [SMSATS1]
7602 Issuer-Generated Fee Any valid Issuer-Generated Fee Collection (a)
Collection code in [SMSATS1] section 4.75.6
tables 4-30 or 4-31.
7603 Issuer-Generated Fee Payment Any valid Issuer-Generated Funds (a)
Disbursement code in [SMSATS1]
Notes
(all) The codes used are all new private codes. Codes in the 7xxx range have been used because
they indicate the 'reason for a fee collection message' in ISO 8583:1993 terms, even though
the fee collection messages actually used are 1220/1221/1230 and 1422/1423/1432 rather than
17xx series.
(a) [SMSATS1] section 4.75.6 tables 4-30 and 4-31 do not make fully clear which Visa codes are
acquirer-generated and which are issuer-generated; nor do they make clear which codes relate
to fees and which to funds disbursements. Hence it is difficult to be exact at this stage about
the mapping of precise Visa codes to the general MBI codes.

Page 547
VISA SMS Codes
Appendix G.2 Message Reason Code Table

SPAN DE 123.9 Card Scheme Information (reused RFU) – content as per the column ‘DE123.9 SPAN
Code & F63.3 Visa Code’ from the table below and similarly SPAN DE 25 Message Reason Code will
be mapped as defined.
SPAN2 – Visa SMS Message Reason Code Mapping Table

DE 25 SPAN Meaning DE123.9 SPAN Code & F63.3 Visa Code (pass- Notes
SPAN through, logged but no mapping)
Code
2000 Representment Any valid Representment code in (a)
[SMSATS1] section 4.75.6 tables 4-30 or 4
31.
4352 Reversal Any valid Reversal code in [SMSATS1] (b)
4751 Chargeback Any valid Chargeback code in [SMSATS1] (b)
4752 Chargeback Reversal Any valid Chargeback Reversal code in (b)
[SMSATS1] section 4.75.6 tables 4 30 or
4-31.
Notes
(a) This code is from the ISO 8583:1993 standard since it caters for general reason for generating
a representment ‘general – invalid chargeback’.
(b) The codes used are all new private codes.
Appendix G.2.1 Function Codes
The table shows the new DE 24 Function Codes required by the new transactions.
Function Codes
SPAN SPAN Meaning Notes
Code
285 Acquirer-Originated Fee-Related Transaction
492 Issuer-Generated Fee-Related Transaction
Appendix G.3 SPAN2 Support for Visa SMS Point-Of-Service Condition Code
As with the Message Reason Codes the following relationship will be adopted between the
Visa SMS Point-Of-Service Condition Code and the SPAN Function Code.
SPAN2 – Visa SMS Point-Of-Service Condition Code Mapping Table

Page 548
VISA SMS Codes
SPAN SPAN Meaning Visa Code Notes

Code
282 Representment Representment code indicator
[SMSATS1] section 4.23.6 table 4-5, i.e.
value ‘13’ in F25
400 Reversal Must be set to this value. As stated in (a)
[SMSATS1] Table 4-3 “For reversals,
amount must match that in the original
request. Partial reversals are not
allowed.” Not passed to Visa.
490 Chargeback Reversal Chargeback Reversal code indicator
[SMSATS1] section 4.23.6 table 4-5, i.e.
value ‘54’ in F25
491 Chargeback Chargeback code indicator [SMSATS1]
section 4.23.6 table 4-5, i.e. value ‘17’ in
F25
Notes
(a) SPAN DE 24 Function Code set to (existing ISO 8583:1993 code) 400 (Full reversal,
transaction did not complete as approved). As stated in [SMSATS1] Table 4-3 “For reversals,
amount must match that in the original request. Partial reversals are not allowed.” Not
passed to Visa. If inbound reversal supported, DE 24 must be derived from corresponding set
of F63.3 values in section Appendix G.2Appendix G.2.

Page 549

Part IVa - Member Bank Interface v5.3 - HIGHLIGHTED

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Part IVa - Member Bank Interface v5.3 - HIGHLIGHTED

Caricato da

Copyright:

Formati disponibili

SPAN RULES AND STANDARDS

PART IV - MEMBER BANK

ISSUE: AUGUST 2008

TABLE OF FIGURES ................................................................................................................................. X

TABLE OF TABLES .................................................................................................................................. XI

SECTION 1 INTRODUCTION ................................................................................................................ 13

1.1 Purpose of the Document ................................................................................................................ 13

1.2 References ........................................................................................................................................ 13

1.3 Document Structure ........................................................................................................................ 14

SECTION 2 MESSAGE FORMATS ....................................................................................................... 16

2.1 Introduction ..................................................................................................................................... 16

2.2 Supported Messages ........................................................................................................................ 16

2.3 Network Management Messages .................................................................................................... 20

2.4 ATM – Financial Messages............................................................................................................. 23

2.5 ATM – Reversals & Chargebacks.................................................................................................. 28

2.6 ATM – Reconciliation ..................................................................................................................... 33

2.7 ATM – Administrative Message..................................................................................................... 38

2.8 POS – Authorisation Transactions ................................................................................................ 43

2.9 POS – Financial Transactions ........................................................................................................ 48

2.10 POS – Reversals & Chargebacks ................................................................................................... 53

2.11 POS – Reconciliation ....................................................................................................................... 58

2.12 POS – Administrative Message ...................................................................................................... 64

SECTION 3 FIELD DESCRIPTIONS ..................................................................................................... 66

3.1 SPAN External Message ................................................................................................................. 66

3.2 Message Structure ........................................................................................................................... 66

3.3 Message Components ...................................................................................................................... 66

3.4 Data Elements (DE) ......................................................................................................................... 72

Version: 5.3 ; Issue: August 2008 Page ii

3.4.15 DE 24 – Function Code ............................................................................................................... 92

SECTION 4 TRANSACTION FLOWS .................................................................................................. 169

4.1 Introduction ................................................................................................................................... 169

Version: 5.3 ; Issue: August 2008 Page iii

4.2 Additional Reference..................................................................................................................... 169

4.3 Administrative Messages .............................................................................................................. 174

4.4 Rejected Message........................................................................................................................... 178

4.5 Network Management Messages .................................................................................................. 182

4.6 ATM Financial Messages.............................................................................................................. 202

4.7 ATM Reconciliation Messages ..................................................................................................... 231

4.8 POS Financial Transaction Messages.......................................................................................... 241

4.8.7 Financial Transaction – IBCS Normal Magnetic Stripe Transaction Authorisation

4.9 POS Reconciliation Messages ....................................................................................................... 321

Version: 5.3 ; Issue: August 2008 Page v

4.11 Claims Processing .......................................................................................................................... 386

SECTION 5 RECONCILIATION PROCESSING ....................................................................................... 389

5.1 Definitions ...................................................................................................................................... 389

5.2 Cutover Process ............................................................................................................................. 391

5.3 Date Processing Examples ............................................................................................................ 394

5.4 Exception Conditions During Cutover ........................................................................................ 404

5.5 Online Reconciliation .................................................................................................................... 405

Version: 5.3 ; Issue: August 2008 Page vi

5.5.2 Reconciliation Messages ........................................................................................................... 405

5.6 Reconciliation Examples ............................................................................................................... 420

5.8 Offline Reconciliation ................................................................................................................... 431

5.9 Bank Card Scheme Reconciliation/Settlement ........................................................................... 432

SECTION 6 PROTOCOL AND COMMUNICATIONS ............................................................................... 435

6.1 Introduction ................................................................................................................................... 435

6.2 TCP/IP ............................................................................................................................................ 435

6.3 Use of TCP on Member Bank Interface ...................................................................................... 436

SECTION 7 NETWORK SECURITY ......................................................................................................... 439

7.1 Introduction ................................................................................................................................... 439

7.2 Key Management........................................................................................................................... 439

7.3 Communication Authentication ................................................................................................... 448

7.4 Data Authentication ...................................................................................................................... 450