ISO8583 (93) Specifications

ZimSwitch Technical Specification

For
Third Party Acquirers to Zimswitch

Version 0.5(Draft)
October 2006

_____________________________________

-0-

No part of this document may be reproduced or transmitted

in any form or by any means, electronic or mechanical,
for any purpose, without express written permission of:
The Managing Director
ZimSwitch
Harare Zimbabwe
ZimSwitch is committed to ongoing research and development
in order to track technological developments and customer in the
market. Consequently, information contained in this document may be
subject to change without prior notice.
Windows NT, Windows 2000, SQL Server are trademarks
of Microsoft Corporation.

-1-

Document Version Control

Date

Version

Comments

September 5,
2006

0.1

Zimswitch 3PA Technical Specification

created from the Zimswitch Technical
Specification for ATM Transactions
and Point Of Sale Debit Card
Transactions.

September 28,
2005

0.2

Re-released for Comments

October 13,
2006

0.3

Released to 3PAs for comments and

guidance.

October 27,

0.4

Included additional Transaction sets

as per 3PAs requirements

0.5

No Changes, released with new

Version

2006
November 17,
2006

-2-

CONTENTS
1

General Points ..................................................................... 7

1.1

Scope ...........................................................................7

1.2

Authorisation Criteria ......................................................7

1.2.1 Reversals Store and Forward ..................................7
1.2.2 PIN Authorisation ..................................................8

1.3

Security ........................................................................8
1.3.1 Link between 3PAs and Zimswitch ...........................8
1.3.2 Card Presence Transactions (POS/ATM)....................8
1.3.3 Message Authentication..........................................8
1.3.4 Key Management ..................................................8

1.4

Communication ..............................................................9

1.5

Call Setup......................................................................9

1.6

Cut off ..........................................................................9

1.7

Card Types to be Switched through Zimswitch ...................9

1.7.1 Current Cards .......................................................9
1.7.2 Possible Future Cards.............................................9

1.8

PIN Block Formats ........................................................10

1.9

Transaction Fee Charges ...............................................10

1.9.1 Reversals ...........................................................10
1.9.2 Fee Management.................................................10
1.9.3 Unknown ISID ....................................................10
1.9.4 Current Known Fees ............................................10

1.10

Identification of FIs and Forwarder.................................11

1.11

Zone Master Keys and Zone Working Keys.......................13

1.12

Store and Forward ........................................................13

-3-

Message Structure ............................................................. 15

2.1

Message Type Identifier ................................................15

2.2

Bitmaps.......................................................................15

2.3

Data Elements .............................................................16

2.4

Matching of Messages Edition 1993 ..............................16

2.4.1 Financial Transactions 12XX and 14XX ...................16
2.4.2 Network Management Transactions 18XX ...............17
2.4.3 Responses To Messages - 12XX, 14XX, 18XX..........17

2.5

Message Flow...............................................................17
2.5.1 Message and Transaction Flows.............................17

Error Handling ................................................................... 18

3.1

Message Rejection ........................................................18

3.1.1 General..............................................................18
3.1.2 Logging of Indecipherable Messages ......................18

3.2

Message Time-out ........................................................19

3.3

System Malfunction ......................................................19

Message Handling.............................................................. 20
4.1

LOGON 1804/1805 and 1814 ........................................20

4.2

ECHO TEST (HANDSHAKE) 1804/1805 and 1814 ..............21

4.3

KEY EXCHANGE 1804/1805 and 0814 .............................21

4.4

LOGOFF 1804/1805 And 1814........................................22

4.5

CUT OFF 1804/1805 AND 1814 ......................................22

4.6

FINANCIAL TRANSACTION PROCESSING...................................23

4.6.1 Balance Enquiry 1200 and 1210 ............................23
4.6.2 Financial Transaction 1200 AND 1210 ....................23

4.7

REVERSAL PROCESSING................................................24

4.8

LOGOFF.......................................................................25
4.8.1 ACQUIRER FI LOGOFF..........................................25

-4-

4.9

FINANCIAL TRANSACTION ..........................................25

4.9.1 CANCELLATION ...................................................25
4.9.2 FINANCIAL TRANSACTION - TIME OUT...................25

Message fields ................................................................... 27

5.1

FIELD 1

BIT MAP, EXTENDED .......................................28

5.2

FIELD 2 PRIMARY ACCOUNT NUMBER (PAN) ....................28

5.3

FIELD 3 PROCESSING CODE ..........................................28

5.4

FIELD 4 AMOUNT, TRANSACTION ...................................30

5.5

FIELD 7 TRANSMISSION DATE AND TIME ........................31

5.6

FIELD 11 SYSTEMS TRACE AUDIT NUMBER......................31

5.7

FIELD 12 DATE AND TIME, LOCAL TRANSACTION .............31

5.8

FIELD 13 DATE, EFFECTIVE ...........................................32

5.9

FIELD 14 DATE, EXPIRATION .........................................32

5.10

FIELD 15 DATE, SETTLEMENT ........................................32

5.11

FIELD 19

ACQUIRER INSTITUTION COUNTRY CODE........33

5.12

FIELD 22

POINT OF SERVICE DATA CODE......................33

5.13

FIELD 23 CARD SEQUENCE NUMBER ..............................34

5.14

FIELD 24 FUNCTION CODE ...........................................34

5.15

FIELD 26 CARD ACCEPTOR BUSINESS CODE...................35

5.16

FIELD 28

5.17

FIELD 32 ACQUIRING INSTITUTION IDENTIFICATION CODE36

5.18

FIELD 33 FORWARDING INSTITUTION IDENTIFICATION CODE

..................................................................................36

5.19

FIELD 35 TRACK 2 DATA ...............................................37

5.20

FIELD 37 RETRIEVAL REFERENCE NUMBER ......................37

5.21

FIELD 39 ACTION CODE ...............................................37

5.22

FIELD 40 SERVICE CODE...............................................40

5.23

FIELD 41 CARD ACCEPTOR TERMINAL IDENTIFICATION ...41

DATE, RECONCILIATION ................................35

-5-

5.24

FIELD 43 CARD ACCEPTOR NAME / LOCATION ...............42

5.25

FIELD 49 CURRENCY CODE, TRANSACTION ....................42

5.26

FIELD 52 PERSONAL IDENTIFICATION NUMBER (PIN) ......43

5.27

FIELD 54 ADDITIONAL AMOUNTS ..................................43

5.28

FIELD 56

ORIGINAL DATA ELEMENTS............................44

5.29

FIELD 59

TRANSPORT DATA ........................................44

5.30

FIELD 60 POINT OF SERVICE DEVICE TYPE......................45

5.31

FIELD 93 TRANSACTION DESTINATION INSTITUTION ID CODE

..................................................................................46

5.32

FIELD 94 TRANSACTION ORIGINATOR INSTITUTION ID CODE

..................................................................................46

5.33

FIELD 100 RECEIVING INSTITUTION ID CODE .................47

5.34

FIELD 102 ACCOUNT INDENTIFICATION 1 .......................47

5.35

FIELD 103 ACCOUNT IDENTIFICATION 2 .........................47

5.36

FIELD 128 MESSAGE AUTHENTICATION CODE .................47

Message Layouts ............................................................... 49

6.1

MESSAGE LAYOUTS - ISO 8583 EDITION 1993 ................49

6.1.1 MESSAGE LAYOUTS GENERAL ............................49
6.1.2 1804/1805 NETWORK MANAGEMENT REQUEST......50
6.1.3 1814 NETWORK MANAGEMENT REQUEST RESPONSE50
6.1.4 1200/1201 FINANCIAL TRANSACTION REQUEST ....51
6.1.5 1210 FINANCIAL TRANSACTION REQUEST RESPONSE51
6.1.6 1420/1421 ACQUIRER REVERSAL REQUEST ...........52
6.1.7 1430 ACQUIRER REVERSAL REQUEST RESPONSE...53

ISO 8583 MESSAGES - FIELD USAGE MATRIX .................... 54

Appendices ................................................................................. 55
Appendix A Glossary............................................................55

-6-

General Points

1.1

Scope

This document specifies a technical interface between ZimSwitch and Third

Party Providers (3PAs) who will connect on-line to process

ATM transactions

Point of Sale transactions

Mobile phone originated transactions

Internet e-Commerce transactions

This is a working document and extensions to the specification will be made to

other transactions sets to accommodate third party processors and or
Independent Service Organisations (ISO).
This interface is based on the International Standard ISO 8583 Second Ed
1993-12-15 message protocol standard. Where possible, this standard has
been adhered to, but in circumstances where either ZimSwitch or FI
requirements cannot be accommodated, exceptions have been made to the
usage of the 1993 edition.
ZIMSWITCH personnel, ZIMSWITCH partners and software suppliers are
assumed to be in possession of the ISO 8583 standard. Reference must be
made to the ISO 8583 second edition 1993-12-15 to obtain absolute clarity on
such things as data elements. Whilst field requirements as they pertain to
ZimSwitch are specified in this document no attempt has been made to
reproduce the ISO specification.

1.2

Authorisation Criteria

ZimSwitch will not be configured to perform any stand-in authorisation on

behalf of 3PAs. In circumstances when the link from the Acquirer to ZimSwitch
is unavailable the Acquirer will reject the transaction. In circumstances when
the link from ZimSwitch to the card Issuer is unavailable, then the transaction
will be rejected by ZimSwitch. There will be no attempt to process transactions
on a store and forward basis.
1.2.1

Reversals Store and Forward

The one exception to this rule pertains to 1400 messages which are reversal
messages which are mandatory, 'must deliver' messages. An Acquirer is
obliged to keep repeating reversal messages until such time as they are
acknowledged by the Issuer. It can happen that an Issuer goes 'off-line' to
ZimSwitch environment after having authorised a transaction which
subsequently fails at the Acquirer for any number of reasons. In these
circumstances, the Acquirer repeats the reversal endlessly without there being
-7-

any possible acknowledgement from the Issuer. This endless repetition creates
stress in all the systems involved. Hence if ZimSwitch receives a reversal for an
Issuer who is off-line to the switch, ZimSwitch will intervene and acknowledge
the reversal and effectively store and forward it, thus taking responsibility for
the risk and the delivery of that transaction. If such a transaction has still not
been delivered at cut-off, it will be reported in the settlement reports.
1.2.2

PIN Authorisation

All Card Presence transactions will be PIN based. However there are some
Issuers who have issued cards that require signature authorisation at POS e.g.
Barclays Bank Zimbabwe. Zimswitch POS acquirer terminals can prompt for
PIN or signature verification, according to BIN number. However it is still a
single message authorisation process, and Zimswitch and Zimswitch
participants accept no risk liability with regard to these signature authorised
transactions. All risk lies with the Issuer.
Card not present transaction will not require a PIN across Zimswitch.

1.3

Security

1.3.1

Link between 3PAs and Zimswitch

The 3PA must ensure that the security procedures in use meets the
requirements of ZimSwitch and its Issuers.
To authenticate and secure the link between the 3PA and Zimswitch a Secure
Socket Layer (SSL) session will be used.
1.3.2

Card Presence Transactions (POS/ATM)

All PINs are to be transmitted as encrypted PIN Blocks in accordance with

secure hardware methods. ZimSwitch will change the Acquirer Working Key
(AWK) every time the link has been re-established after having dropped and
may change the key randomly throughout the day even if the link has not been
dropped.
1.3.3

Message Authentication

To ensure that messages are not tampered with between 3PAs and ZimSwitch,
all messages to Zimswitch from the 3PAs must be transmitted using a Message
Authentication Code (MAC). Message authentication operates by sharing an
operational Message Authentication Key (KWA) between two systems. This key
is exchanged under a mutual Key Encrypting Key (KEK).
The MAC generation algorithm is based on the DES CBC mode and is specified
in the ANSI X9.9 standard.

1.3.4

Key Management

The key management scheme to be employed between ZimSwitch and the 3PA
-8-

is the Zone Working Key scheme. ZimSwitch will be the sole provider of both
key types. The Zone Working Key is provided over the interchange. Each end
of the link holds a Zone Control Master key which is established by the three
person manual key loading scheme. The frequency with which the Zone
Working Keys are changed is at ZimSwitch discretion.

1.4

Communication

The 3PA will connect to Zimswitch via a TCP/IP server connection. As TCP is a
stream-oriented protocol the first two bytes of any message arriving at
ZimSwitch indicates the length of the message (excluding the length indicator).
Similarly, a two byte length indicator is prefixed to any message sent by
Zimswitch.
The length indicator is packed as an unsigned 16-bit integer, with the most
significant (the high 8 bits) in the first byte, and the least significant (the low 8
bits) in the second byte.
1.5

Call Setup

At Call Set-up time the 3PA must establish a TCP/IP client connection to
ZimSwitch This may be over a single physical link, or distributed over the dual
links which each 3PA supports. The latter would be preferable as this provides
automatic redundancy in case of a single failure.
Once established, the TCP/IP connection should remain permanently connected
and should only be cleared under exception conditions (i.e. bad line conditions,
etc.). If the connection is cleared for any reason, the 3PA should automatically
attempt to re-establish the TCP/IP session at regular intervals of no less than 5
seconds.
Once a connection has been established the 3PA must initiated a Logon
1.6

Cut off

Cut-Off between the 3PA and ZimSwitch is to be effected by an online

exchange of messages.
Cut-Off will always be initiated by ZimSwitch and is governed at the agreed
cut-off time, currently that is at 1900 hours every day.
If an 3PA is off-line to ZimSwitch at the time of cut-off, the cut-off message will
go into the ZimSwitch store-and-forward (SAF) file for delivery as soon as that
3PA comes on-line again
1.7

Card Types to be Switched through Zimswitch

1.7.1

Current Cards

Participant FI Proprietary ATM cards

1.7.2

Possible Future Cards

VISA

MasterCard

-9-

American Express

Diners Club

International Cards

Maestro

Electron

Smart Cards

1.8

PIN Block Formats

DIEBOLD & IBM ATM(IBM-3624)

PIN left justified with pad character 'F'.
Digits 1 to n

Digits n+1 to 16 =

Pad Characters (F)

1.9

PIN (n = PIN length)

Transaction Fee Charges

ZimSwitch has elected not to have Acquirer and Switch fees travel in each
message but to be determined by parameter at settlement time. Fees will not
travel with transaction messages as the fee field concerned (field 46) is related
to on-line reconciliation, whereas ZimSwitch settlement and reconciliation is
performed as a batch operation, after the event.
Acquirer and Switch fees are determined by the participant Financial
Institutions in agreement with each other and are entered to the switch as
parameters to a table for the purposes of settlement and for reporting.
1.9.1

Reversals

No fee payable for reversals.

1.9.2

Fee Management

These charges are subject to change on agreement by the participants and will
be managed by ZimSwitch.

1.9.3

Unknown ISID

In the event that ZimSwitch receives a Request for an unknown card

(determined by the value of the ISID in the first six positions of the Primary
Account Number) ZimSwitch will reject the request with a response code 908.

1.9.4

Current Known Fees

See Zimswitch User Manual (to be replaced by Zimswitch Operating Guide) for
-10-

current Fees and charges which are not strictly relevant to Technical
Specification.
However, for Settlement purposes, the basic points need to be noted here. The
basic transactions that are permissible across the ZimSwitch network,
depending on the policies and capacities of each participating FI are as follows:

Cash withdrawal at ATM

Cash withdrawal at POS

Balance enquiry at ATM

Balance enquiry at POS

Purchase at POS

Purchase and Cash Withdrawal at POS

Debit adjustment at POS

Credit adjustment for cash at POS

Credit adjustment for purchase at POS

Reversals at ATM

Airtime purchases via card-not-present transaction (NEW)

Balance enquiry at Mobile and Internet devices

Mini-statement at Mobile and Internet devices

TBAs

1.10 Identification of FIs and Forwarder

Acquirer Institution Identification Code is used to denote the initiator of a
message, either the 3PA in the case of a Zimswitch acquired Transaction or the
generator of a network message which could be the 3PA owner or the
Authoriser (Issuer) or ZimSwitch as appropriate.
The release of Acquirer Institution Identification Code to 3PAs will be managed
by the Standards Association of Zimbabwe.
Forwarder Institution Identification Code is used to denote ZimSwitch for
messages that are passed through from Acquirer to Issuer such as Cash
Withdrawals and Balance Enquiries.
Receiving Institution Identification Code is used to denote the recipient of
the message. If the acquirer is not able to insert a valid value in this field a
value of all zeroes is acceptable. ZimSwitch will insert the derived value in this
on pass-through.
In order to determine the Receiving Institution Identification Code the following
-11-

sequence of check and value derivation will be followed at ZimSwitch.

If recognisable ISID (first six characters of Primary Account Number)

then set up relevant code in Receiving Institution Identification Code
field.

If not recognisable ISID then check Receiving Institution Identification

Code for valid value, if valid then route accordingly, if not valid reject
message with suitable response code.

-12-

1.11 Zone Master Keys and Zone Working Keys

Key Exchange

Acquirer

AWK encrypted
under ZMK 1

IWK encrypted
under ZMK 2

ZimSwitch

Issuer

AWK and IWK

generation
HSM

Message Transmission

Acquirer

PIN encrypted
under AWK

PIN encrypted
under IWK

ZimSwitch

Issuer

PIN translation,
Acquirer to Issuer
zone
HSM

ZMK1 refers to Zone Master Key for Bank 1 ( in this case as Acquirer)
ZMK2 refers to Zone Master Key for Bank 2 ( in this case as Issuer )
AWK refers to Acquirer Working Key
IWK refers to Issuer Working Key
AWK can also be referred to as Outbound Key
IWK can also be referred to as Inbound Key

The Zone Master Keys will be introduced to the Hardware Security Modules
(HSM) at ZimSwitch and at FI sites by FI personnel.

1.12 Store and Forward

-13-

Store and Forward will be introduced to ZimSwitch. This will cover Reversal
processing. The 3PA will deliver a reversal to ZimSwitch when appropriate
exactly as it does in the current system. It will be the responsibility of
ZimSwitch to deliver this reversal to the Issuer FI. If the Issuer FI is available
and does not time out to ZimSwitch, the latter will forward the Reversal
Response from the Issuer FI to the 3PA. If the Issuer FI is not logged on to
ZimSwitch or the response times out, ZimSwitch will store the reversal for later
delivery and will immediately respond to the 3PA with a code indicating
acceptance of the Reversal.
The Issuer FI must accept this message. In the unlikely event that the Issuer
FI rejects the Reversal (inability to match to the original request should be the
only criteria) when it is received from the ZimSwitch store and forward
process, ZimSwitch will log the rejection for off-line reconciliation between the
relevant FIs.
ZimSwitch will retain all un-delivered transactions in its store-and-forward
(SAF) file even and especially if an FI is off-line to ZimSwitch at the time of
cut-off.
ZimSwitch will hold transactions in its SAF file for varying and appropriate
lengths of time, but will clear its SAF files manually by FI on an as and when
needed basis. All such cleared transactions will be reported.

-14-

Message Structure

The messages passed between the 3PA and ZimSwitch are to be constructed
with the basic message structure prescribed by ISO8583.
Messages are constructed in the sequence:

message type identifier

bitmap(s)

data elements

Message Type
Identifier

Bit map 1

Bit map 2
(Optional)

Data elements

4 bytes

64 bits (8
bytes)

64 bits (8
bytes)

variable
according to bit
maps

fields 01 64

fields 65 - 128

bit on = field
present

2.1

Message Type Identifier

This is a 4-digit field which identifies the type of message. The first 2 digits
describe the class of message. The following classes are used in this
specification:

2.2

12XX

Financial Transaction Messages (1993)

14XX

Reversal Messages (1993)

18XX

Network Management Messages (1993)

Bitmaps

Each bitmap represents 64 bits of data. The value of each bit within a bitmap
represents the presence (value '1') or absence (value '0') of a corresponding
data element in the message. The exception to this principle applies to the first
bit within the primary bitmap, which, when valued at '1', denotes the presence
of an additional, contiguous bitmap and not the presence of a data element.

-15-

The secondary bitmap is optional and will only be included for those messages
requiring field(s) beyond 64.
For transmission purposes each bitmap of 64 bits is converted to 8 bytes. The
64 bits are first converted into 16 groups of four. Then, each group of four bits
is assigned an hexadecimal equivalent according to the table shown on the
next page:
BIT

2.3

VALUE

HEX

VALUE

0000

0001

0010

0011

0100

0101

0110

0111

1000

1001

1010

1011

1100

1101

1110

1111

Data Elements

The bitmap serves as an index of data elements that are present in the
message. In terms of ISO8583, some elements are mandatory for certain
message types, others are optional.
The data elements (fields) which will be used in the messages in this
specification are detailed in Section 5.

2.4

Matching of Messages Edition 1993

2.4.1

Financial Transactions 12XX and 14XX

-16-

The following fields will be used to uniquely identify each transaction

Message Type Identifier

Reference Retrieval Number

Field 37

Date & Time Local

Field 12

Acquiring Institution Id Number

Field 32

Ref.Ret.No. is anything which is unique for the acquirer e.g. terminal no.
+ sequence no. These fields will be echoed in the response and will be
inserted into field 56 for Reversal processing.

2.4.2

Network Management Transactions 18XX

The following fields will be used to uniquely identify each transaction

Reference Retrieval Number

Field 37

Date & Time, Local

Field 12

Reference Retrieval Number is generated by the message initiator.

These fields will be echoed in the response.
2.4.3

Responses To Messages - 12XX, 14XX, 18XX

The responses to these messages must reflect the fields noted as echoed data
at least.
The 1993 edition of ISO 8583, introduces the concept of matching transactions
in addition to matching messages and to this end introduces field 37, Retrieval
Reference number. Please be guided by section 6.3 of the 1993 standard
2.5

Message Flow

ZimSwitch is acting as a financial message forwarder and will not normally

initiate messages or responses. It is important to view the network as if there
is a logical connection between each 3PA and each Issuer FI when considering
the implications of message flows and possible inconsistencies.

2.5.1

Message and Transaction Flows

Not Applicable.

-17-

Error Handling

Conversation exception conditions have been detailed for particular

conversations
3.1

Message Rejection

3.1.1

General

If either party receives a message that it cannot process, it is to reject the

message as follows:

If the message type is not recognised or is not specified as supported by

the ZimSwitch to Financial Institution Interface, then the receiver is not
to respond to the sender. (The reasoning being that if the message type
identifier is not recognised, the receiver would be unable to unpack the
message for the message matching fields (section 2.4) and also unable
to respond with the corresponding response message.).

If the message type is recognised and supported but the contents cannot
be processed, then the receiver is to reply with the appropriate response
message with the response code field signifying the reason for the error,
e.g. code 30 'format error'.

Similarly, ZimSwitch will intervene and return the message with

appropriate response code if routing information or formatting (e.g.
inability to assign as POS or ATM transaction) is invalid.

If ZimSwitch is aware that the Issuer FI is not logged on then ZimSwitch

will generate a response to the 3PA with the response code 97 Issuer
not available. This is one of the few occasions when ZimSwitch initiates
messages.

If ZimSwitch is aware that the Issuer FI is not logged on AND that the
transaction is a Reversal, ZimSwitch will process the reversal as a store
and forward message.

3.1.2

Logging of Indecipherable Messages

In the event that a message recipient is unable to parse a message it is

recommended that the message be logged for further analysis off-line so that
resolution of the problem can be achieved. It is recommended that the
message is not responded to so that the originator may take normal time-out
action.

-18-

3.2

Message Time-out

The party initiating the message establishes the amount of time it will wait for
a response to the message it initiated. Consideration should be given to the
following in establishing time-out periods:
The time-out period at the device (ATM/POS/MOBILE/INTERNET) must be at
least long enough to allow for the various processes noted below to complete.
DEVICE ----------> Acquirer FES ----------> ZimSwitch-----------> Issuer
DEVICE<---------- Acquirer FES <---------- ZimSwitch<----------- Issuer
There are some 13 processes to be carried out.
Given the above, ZimSwitch recommends a device terminal time-out period of
50 seconds on NOT ON-US transactions. In practical terms it will probably be
more sensible to set the device time-out the same for all transaction types - be
they ON-US or NOT ON-US.
If timeouts are excessive (greater than a predefined number per time period)
ZimSwitch recommends that the following manual procedure will be followed:

the 3PA operator will Logoff and follow the procedure detailed in *****

if this does not help, the Link will be dropped and re-established.

The 3PA operator will phone ZimSwitch to establish the problem.

3.3

System Malfunction

General Malfunction
ZimSwitch may experience repeated problems with a 3PA (e.g. repeated PIN
failures, system problems). Should this happen then the ZimSwitch monitor
personnel will take appropriate action. This will be a learned response to
problems as the nature of the problems is unknown at this time. It is
recommended that a full incident log be kept and that the incident be recorded
by either ZimSwitch or by the 3PA. The incidents must be reviewed
periodically by the ZimSwitch technical committee or operational committee.

-19-

Message Handling

Note for 1993 version:

Bits which must be set to '1' are specified in the message details, per bitmap
(BMP). ZimSwitch participants have elected to work with fixed messages under
1993 and therefore selected fields that may be optional in accordance with the
ISO 8583 specification will always be present and will be fixed length. All other
bits must default to zero. In accordance with this rule a secondary BMP will
always be included in the network management message.
Network Management Processing
Network management functions between the 3PA and ZimSwitch are to be
implemented using the ISO8583 18XX series network management messages.
1804 = network management request
1805 = network management request repeat
1814 = network management request response

4.1

LOGON 1804/1805 and 1814

A Logon is the means by which one party identifies itself to the other for the
purpose of requesting to process further transactions.
Pre-requisites to a successful Logon request are:

A TCP/IP connection is established by the 3PA by sending a TCP/IP client

call connection. ( Port Numbers and IP addresses are supplied by
Zimswitch on request )

the 3PA will send a Logon request

ZimSwitch will respond to the Logon request with an action code '860' for
a 1993 3PA (Logon not allowed, keys must first be exchanged). the FI
should not attempt to Logon again

ZimSwitch will initiate key exchange with an action code 101

if key exchange is successful, the key will be implemented and the FI will
respond with an approval

if key implementation is successful, ZimSwitch will send a Logon request

to the FI

the FI will respond to the Logon request

In the event that the 1804 request is not responded to in the configured time,
the message initiator will repeat the message twice (maximum) using the 1805
message. If at this stage there is still no response, the message initiator will
drop the Link, re-establish it and attempt to Logon (3PA), implement key

-20-

exchange and then Logon (ZimSwitch). The frequency at which the initiator will
retry this procedure will be predefined and configurable.
If the 3PA Link drops, the 3PA will be logged off by Zimswitch. Under such a
condition, the 3PA will re-establish the link and send the Logon sequence to reinitiate the session.
If the Forwarding Institution Identification Code is not recognised by
ZimSwitch, no 1814 will be sent and the Link will be cleared immediately.

4.2

ECHO TEST (HANDSHAKE) 1804/1805 and 1814

The purpose of the echo test is for either ZimSwitch or the 3PA to determine
the status of the other party. It may be initiated by either party and the
frequency is unspecified.
The echo test will be initiated using an 1804 request with field 70 (networkmanagement-information-code) set to '301' and the receiving party will
respond with an 1814.

4.3

KEY EXCHANGE 1804/1805 and 0814

Key exchange is the means by which ZimSwitch requests the FI to change

Zone Working/Authentication keys and by which the 3PA acknowledges the
request. Until acknowledgement has been received, the 'new' key will not be
implemented and messages will continue to be exchanged using the 'old' keys.
Please see chapter 1 for an expanded view and definition of the Zone Key
concept and to clarify the names used. The key used in encrypting PIN blocks
over the switch will be exchanged as follows:

ZimSwitch will send an 1804 request with field 70 (networkmanagement-information-code) set to '101'

the 3PA will respond with an 1814.

If a response is not received within the pre-configured time-out period,

ZimSwitch will drop the link, and notify the ZimSwitch operator.
The 3PA is to return standard check digits for the session key received in the
1804 request in the 1814. This corresponds to the key verification code (KVC)
defined by ZimSwitch. The check digits are calculated as follows:

-21-

(DATA)
64 bits of binary zeros
_______|__________
Zone Working Key

_________

(encrypted under
Zone Control Master Key)

| DES ALGORITHM
| (ANSI X3.92)

|
|

|_________________|
|
Encrypted Key
123456789ABCDEF
|
Standard check digits (most significant 24 bits)
4.4

LOGOFF 1804/1805 And 1814

A Logoff is the means by which one party advises the other that it will be
dropping the link.
Logoff messages are to be implemented in both directions on the switch. The
initiating party sends an 1804 request with field 024 (function code) set to
'802' and waits for an 1814 response. When the response is received, the
initiating party may drop the Link. If a response is not received, a maximum of
two 1805 repeats will be attempted. If there is still no response, the party
initiating the Logoff may drop the Link.
If a Logoff is processed while there is an outstanding transaction, the
appropriate reversal processing will come into effect. If the Issuer is logged off
to ZimSwitch then ZimSwitch will respond to any requests received from an
acquirer for that issuer with an action code of 910.
4.5

CUT OFF 1804/1805 AND 1814

CUT-OFF PROCESS
Cut-Off is driven by ZimSwitch. At 19h00 ZimSwitch will increment the
settlement-date and will send an 1804 advice to each 3PA. The 3PA will then
register the changed business day.
BUSINESS DAY
The following ZimSwitch value dates apply currently:
PERIOD TRANSACTIONS RECEIVED VALUE DATE
-22-

Saturday

- after 19:00:00 up to & including 24:00:00

Sunday

- after 19:00:00 up to & including 24:00:00

Monday

- after 19:00:00 up to & including 24:00:00

Tuesday

- after 19:00:00 up to & including 24:00:00

Wednesday - after 19:00:00 up to & including 24:00:00

4.6

Thursday

- after 19:00:00 up to & including 24:00:00

Friday

- after 19:00:00 up to & including 24:00:00

FINANCIAL TRANSACTION PROCESSING

The following dialogue scenarios are to be supported by ZimSwitch. In the

desired processing scenario, all transactions are handled on-line. Therefore, all
financial transactions are Financial Transaction Requests.
The financial transaction functions between the 3PA and ZimSwitch are to be
implemented using the ISO8583 12XX series messages:
1200 Financial Transaction Request
1210 Financial Transaction Request Response
If a repeat message is sent, it will have the same matching fields as the
message it is repeating.

4.6.1

Balance Enquiry 1200 and 1210

Balance enquiries are allowed at the Device. The Acquirer 3PA will forward an
1200 request to ZimSwitch. ZimSwitch will forward the request to the Issuer FI
which will reply with an 1210 containing the account balance which ZimSwitch
will forward to the Acquirer.

4.6.2

Financial Transaction 1200 AND 1210

The Acquirer 3PA will forward an 1200 request to ZimSwitch. ZimSwitch will
forward the request to the Issuer FI which will reply with a 1210 containing the
account balances which ZimSwitch will forward to the Acquirer. If the 1200 is
not responded to by the Issuer FI to Zimswitch in the time configured,
Zimswitch will reply with a 1210 to the Acquirer 3PA.

-23-

If the Acquirer 3PA receives a 1210 response after the transaction has timed
out, if no previous 1210 had been received and if there was no outstanding
1200 request, then the 3PA will initiate reversal/refund processing.
If the 3PA receives another 1210 response and a previous 1210 had been
received and processed, matched by the full range of matching fields, then the
3PA should ignore the 1210.
Note - Refund transactions will be considered to be unique transactions and will
be distinguished by the contents of the processing code.(field 3).
If the 3PA receives a 0210 response after the transaction has timed out, if no
previous 0210 had been received and if there was no outstanding 0200
request, then the 3PA will initiate reversal/refund processing.
If the 3PA receives another 0210 response and a previous 0210 had been
received and processed, matched by the full range of matching fields, then the
3PA should ignore the 0210.

4.7

REVERSAL PROCESSING

DEFINITIONS
The terms cancellation & reversal are used in this section and are clarified
below:
CANCEL
In terms of ZimSwitch certification procedures, once a transaction has
been 'flighted', the Device should not be able to accept a cancellation.
Certification will check for this disablement as a specific test.
REVERSAL
Reversals will immediately be generated by the 3PA, using the same
matching fields (section 2.4) as the original transaction, in the following
circumstances:
Incomplete or timed-out transactions
If a transaction message sent from the 3PA to ZimSwitch has timed-out
and the 3PA has not received a response.
If a transaction response message from the 3PA to the ATM has timed
out.
If the 3PA has indicated to the device that the transaction has been
unsuccessful, and then receives a response from ZimSwitch indicating that the
transaction has been successfully received and updated.

-24-

Financial Reversals are MUST DELIVER messages which must be delivered by

all parties.
ISO8583 MESSAGES FOR REVERSALS
1420 = acquirer reversal request
1421 = acquirer reversal request repeat
1430 = acquirer reversal request response

4.8

LOGOFF

4.8.1

ACQUIRER FI LOGOFF

If a request 1200 is outstanding and the Issuer FI responds with a 1210,

ZimSwitch will be unable to forward the response. In this case of difficulty in
delivering the response 2 further attempts, 1200, will be made. If the repeats
fail, ZimSwitch will record the response. The Acquirer is responsible for
sending the reversal 1420 in the event of an outstanding 1200 request. This
will be the normal situation where the device has timed-out and the Acquirer is
not yet aware of the response, whether accepted or rejected.

4.9

FINANCIAL TRANSACTION

4.9.1

CANCELLATION

Not applicable.
4.9.2

FINANCIAL TRANSACTION - TIME OUT

If the device times out before an 1210 response is received, the 3PA must
generate an 1420 reversal. The Issuer FI receives the 1420 reversal matching
it with the related 1200 request. If the original 1200 request was declined the
Issuer can record the 1420 as received and return an 1430 response. If the
1200 request was accepted then the Issuer FI should record the 1420, recredit the client account with the transaction amount and return an 1430
response. If an unmatched 1420 reversal arrives at the Issuer FI it should be
recorded and ignored. If the 3PA receives a late 1210 ( after the 1420 request
has been initiated ) response it must be recorded and ignored.
If the Issuer times-out to ZimSwitch or the Issuer FI is logged off, ZimSwitch
will send a Reversal Response to the 3PA and will log the reversal for Store and
Forward to the Issuer FI when contact is re-established.
N.B. Should ZimSwitch receive a late request response it will discard it. The
3PA will send a reversal. The Issuing FI will react to the reversal according to
the original request action taken - e.g. reverse the debit posting if it occurred.

-25-

-26-

Message fields

Please note the following default values for the more common data types.
a

alphabetic character, A through Z and a through z

Numeric digits, 0 through 9

ans

alphabetic, numeric and special characters

MM

Month, 01 through 12

YY
century.

Year, 00 through 99 no apparent allowance for the turn of the

hh

Hour, 00 through 23

mm

Minute, 00 through 59

ss

second, 00 through 59

LL

length of variable length data element that follows, 01 through 99

LLL

length of variable length data element that follows, 01 through 999

fixed length of 3 characters

..11

variable length up to 11

binary representation of data

track 2 code

Note - all fixed length n elements are presumed to be right justified with
leading zeroes, except for those where examples show left justified with trailing
spaces. All other fixed length data elements are left justified with trailing
spaces.
See page Table 7 of ISO 8583 (1993) for legend of abbreviations used for the
attributes in the following field descriptions.

-27-

5.1

FIELD 1

BIT MAP, EXTENDED

Field No.
1

Format Attribute
b 8

This field is a series of 64 bits used to identify the

presence(denoted by 1) or absence (denoted by 0) of the data
elements in the range 65 through 128.
The values must exactly reflect the presence or absence of data
elements 65 to 128.
Note: A bit stream such as a bit map, PIN or password data
elements in the ISO 8583 standard, may unintentionally
introduce a control character into the transmission stream under
certain communications protocols. In such cases the bit stream
should be divided into 4-bit blocks and transferred to ASCII or
EBCDIC depending on the protocol.
1993 messages will conform to the standard in that
variable length fields will be variable length in the style
of the standard.

5.2

FIELD 2

PRIMARY ACCOUNT NUMBER (PAN)

Field No.
2

Format Attribute
LLVAR

n 19

PAN is a series of digits used to identify a customer account or

relationship.
Must be present for Card Not Present Transactions

5.3

FIELD 3

PROCESSING CODE
Field No.
3

Format Attribute
n6

The same code appears in all messages for a given transaction.

The field is logically divided into three subfields as follows:

-28-

Pos. Subfield Values

1-2 Tran code
00
01
02
09
18
20
22
28
31
50

Description
Goods and services
Cash
Debit Adjustment
Goods & services + cash
PrePaid
Refund
Credit Adjustment - purchase
Credit Adjustment - cash
Balance enquiry
Utility Bill Payment

Device
001 - ATM

Description
01 Cash
18 PrePaid
31 Balance

Device
101 - POS

Description
00 Goods and Services
01 Cash
09 Sale and Cash Back
18 PrePaid
20 Refund
31 Balance enquiry
50 Utility Bill Payment

Device
201 Mobile

Description
18 PrePaid
21 - Credit
31 Balance Enquiry
38 Mini Statement
40 Transfer Inter Acc
42 Transfer 3rd Party
50 Utility Bill Payment
91 Message to Bank

Device
301 Internet

-29-

Description
18 PrePaid
21 - Credit
31 Balance Enquiry
38 Mini Statement
40 Transfer Inter Acc
42 Transfer 3rd Party
50 Utility Bill Payment
91 Message to Bank

3-4

From
00
Account type 10
20
30

Default
Savings account
Cheque account
Credit card

5-6

To
00
N/A
Account type

until transfers are introduced

If Account type (digits 3-4) = 00 then the transaction must be

performed to the default account for the relevant card.
N.B. This is an Authoriser / Issuer responsibility.
CHECKED BY SWITCH - VALID CODE

5.4

FIELD 4

AMOUNT, TRANSACTION
Field No.
4

Format Attribute
n 12

Transaction amount gives the value of the funds requested by

the cardholder in the local currency of the acquirer or source
location of the transaction.
Where a transaction amount does not apply to a transaction
type (e.g. balance enquiries) the element must still be present
in the request message, zero filled. This is a fixed-length field,
lead zero fill is always required.
The value in response messages must match the value in the
corresponding request message.
The value in reversal request messages must match the value in
the original request.
N.B. Amounts are expressed in the minor unit of the currency thus ZWD100.00 is expressed as 000000010000
CHECKED BY SWITCH - NUMERIC

-30-

5.5

FIELD 7

TRANSMISSION DATE AND TIME

This field is not necessary in edition 1993, but if is included it

must be expressed in Co-ordinated Universal Time (UTC),
formerly GMT.
Zimswitch will time stamp this field regardless
5.6

FIELD 11 SYSTEMS TRACE AUDIT NUMBER

Field No.

Format Attribute

11

n 6

Contains a number assigned by the transaction acquirer to

identify uniquely the message reply.
The value used in the original request must be saved and used
in any related response messages and in subsequent reversal
messages.
Acquirers should generate this field in every request message.
For Reversals, Acquirers must use the identical STAN that was
used in the original transaction
Zimswitch will map the STAN in all reversal requests to field 37
(Retrieval Reference number) before sending the reversal onto
issuer. The 93 Issuer must then ensure that all reversals are
matched to the original financial transaction using field 37.
Effectively this field has been superseded by field 37, Retrieval
Reference number.
CHECKED BY SWITCH - PRESENT

5.7

FIELD 12 DATE AND TIME, LOCAL TRANSACTION

Field No.
12

Format

Attribute

YYMMDDhhmmss

n 12

-31-

Contains the local date time at which the transaction takes place
at the point of the card acceptor location.
All parties should ensure that this field's integrity is maintained
and that it is logged with each message within the network.
CHECKED BY SWITCH - PRESENT
5.8

FIELD 13 DATE, EFFECTIVE

Note - this field is no longer relevant and has been REMOVED. It
now refers to the date that the card becomes effective. It is
therefore omitted in ZIMSWITCH messages. Generally cards
only have effective or expiry dates if there is a specific contract
in place for their use such as that between a Credit card issuer
and their clients.

5.9

FIELD 14 DATE, EXPIRATION

Field No.
14

Format Attribute
YYMM

n4

Contains the year and month after which the card expires.
Generally cards only have effective or expiry dates if there is a
specific contract in place for their use such as that between a
Credit card issuer and their clients. This field has been
requested by ZIMSWITCH.
Responses should return the value contained in the original
request.
CHECKED BY SWITCH PRESENT

5.10 FIELD 15 DATE, SETTLEMENT

Field No.
15

Format

Attribute

YYMMDD

n 6

Contains the year, month and day that funds will be transferred
between acquirer and card issuer.
This field is set up by ZIMSWITCH for all requests before
forwarding the messages to the issuer. It will contain the switch
settlement date that applies to the transaction. Issuers should
return the value received in all related responses.
-32-

Responses should return the value contained in the original

request.
N.B. This field also referred to as Current Business Day.
Zimswitch will time stamp this field regardless

5.11

FIELD 19

ACQUIRER INSTITUTION COUNTRY CODE

Field No.

Format Attribute

19

5.12

FIELD 22

n 3

POINT OF SERVICE DATA CODE

Field No.

Format Attriibute

22

an 12

A series of codes intended to identify terminal capability, terminal

environment and presentation security data. It shall be used to
indicate specific conditions that are (or were) pertinent at the time of
transaction.
The table below illustrates the contents of this field that are currently
valid for ZIMSWITCH ATM and POS transactions.
Pos 1 Card data input capability
Pos 2 Cardholder authentication capability
Pos 3 Card capture capabilit
Pos 4 Operating environment

Pos 5 Cardholder present

Pos 6 Card present
Pos 7 Card data input mode
Pos 8 Cardholder authentication method
Pos 9 Cardholder authentication entity
Pos 10 Card data output capability
Pos 11 Terminal output capability

-33-

1 Manual, no terminal
2 Magnetic stripe read (ATM & POS)
1 PIN (ATM & POS)
0 None
1 Capture
2 On premises of card acceptor, unattended
(ATM)
3 Off premises of card acceptor, attended
(POS)
0 Cardholder present (ATM & POS)
1 Card present (ATM & POS)
1 Manual, no te rminal
2 Magnetic stripe read ATM & POS)
1 PIN (ATM & POS)
5 Manual, signature verification (POS)
3 Authorising agent (ATM & POS)
0 Unknown (POS)
1 None (ATM &/or POS)
0 Unknown (POS)
1 None (POS)
2 Printing (ATM & POS)

3 Display (ATM & POS)

4 Printing and display (ATM & POS)
4 Four characters (ATM & POS)

Pos 12 PIN capture capability

CHECKED BY SWITCH - VALID CODE

N.B.****** update this field for card not present, airtime, mobile purchases
see ISO 8583 appendix A.8

5.13

FIELD 23

CARD SEQUENCE NUMBER

Field No.
23

Format Attribute
n

A number distinguishing between separate cards with the same primary

account number or primary account number extended.

5.14

FIELD 24

FUNCTION CODE

Field No.
24

Format Attribute
n 3
-34-

Contains a number assigned to a network management activity. The

table below illustrates the contents of this field (codes used to represent
network activity).
200
400
801
802
811
821
831
860

Original financial request

Full reversal, transaction did not complete as approved
Log on
Log off
Key change
Cut off
Echo Test
Return of indecipherable message

CHECKED BY SWITCH - VALID CODE

5.15

FIELD 26

CARD ACCEPTOR BUSINESS CODE

Field No.

Format Attribute

26

n 4

Code classifying the type of business being done by the card acceptor for
this transaction.
Please refer to the ISO 8583 1993 edition specification section A.4 for
the code to be inserted in this field.
ZIMSWITCH will not check the value, but will pass on the value to the
Issuer.
5.16

FIELD 28

DATE, RECONCILIATION

Field No.
28

Format

Attribute

YYMMDD

n6

Contains the year, month and day that funds will be reconciled between
acquirer and card issuer.
This field is set up by ZIMSWITCH for all requests before forwarding the
messages to the issuer. It will contain the switch reconciliation (same
as settlement date in edition 87) date that applies to the transaction.
Issuers should return the value received in all related responses.
Responses should return the value contained in the original request.
N.B. This field may also be referred to as current Business Day.

-35-

Zimswitch will time stamp this field regardless

CHECKED BY SWITCH - PRESENT

5.17

FIELD 32 ACQUIRING INSTITUTION IDENTIFICATION CODE

Field No.
32

Format Attribute
LLVAR

n..11

Contains the code identifying the 3PA or ZIMSWITCH in the case

of messages initiated by ZIMSWITCH.
This field is one of the key data elements used to uniquely
identify messages associated with a particular transaction.
Participants should ensure that this field's integrity is maintained
and that it is logged with each message within the network.
In requests and reversals the acquirer should use the value
assigned at certification time. The value used in the original
request / reversal should be used by issuers in subsequent
responses.
CHECKED BY SWITCH - PRESENT

5.18

FIELD 33

FORWARDING INSTITUTION IDENTIFICATION CODE

Field No.
33

Format Attribute
LLVAR

n..11

Contains the code identifying the message forwarder (i.e.

ZIMSWITCH)
This field is one of the key data elements used to uniquely
identify messages associated with a particular transaction.
Participants should ensure that this field's integrity is maintained
and that it is logged with each message within the network.
In requests and reversals the acquirer should use the value
assigned at certification time. The value used in the original
request / reversal should be used by issuers in subsequent
responses.

-36-

In the context of ZIMWITCH as it currently is configured, the

only acceptable value is the ZIMSWITCH code. In the event that
ZIMSWITCH connects to other interchanges or switches, this
field will contain the relevant Forwarding Institution
Identification Code. Refer - table 10 of ISO 8583 edition 1993
for clarification of Institution Identification Code relationships.
CHECKED BY SWITCH - PRESENT

5.19

FIELD 35
Field No.
35

TRACK 2 DATA
Format Attribute
LLVAR

z 37

Contains the information encoded on track 2 of the magnetic

stripe as defined in ISO 7813, excluding beginning and ending
sentinels and LRC characters as defined therein.
This field is required in all financial requests where Card Present
transactions are processed.
5.20

FIELD 37

RETRIEVAL REFERENCE NUMBER

Field No.
37

Format Attribute
anp 12

A reference supplied by the system retaining the original source

information and used to assist in locating that information or a
copy thereof.
New field, effectively replaces STAN, field 11, for matching
transactions, messages.
CHECKED BY SWITCH - PRESENT

5.21

FIELD 39
Field No.
39

ACTION CODE
Format Attribute
n3

Contains a code which defines the disposition of the message

-37-

TABLE OF ACTION CODES

CODE ACTION DESCRIPTION
000
100
101
104
106
107
111
114
115
116
117
120
121
123
126
200
201
206
400
800
860
861
862
902
904
907
908
909
930

Approved
Do not honour
Expired card
Restricted card
PIN tries exceeded
Refer to card issuer
Invalid card number
Invalid account
Requested function not supported
Not sufficient funds
Incorrect PIN Issuer
Transaction not permitted to terminal
Exceeds withdrawal amount limit
Exceeds withdrawal frequency limit
Invalid PIN block
Do not honour
Expired Card
Allowable PIN tries exceeded
Accepted - applicable to
reversal - 14XX
Accepted - applicable to network
management - 18XX
Nat.Use - wait for key exchange
Nat.Use - problem in key exchange
message
National.Use (Issuer can't do key exchange)
Invalid transaction
Format error e.g. missing Bitmap
Card issuer unavailable
No such Issuer
Default for failed transaction,
really system malfunction
Nat. Use - default for tran.
not processed

RETURNED BY

ACTN

Issuer
Issuer
Issuer
Issuer
Issuer
Issuer
Issuer
Issuer
Issuer
Issuer
Decline
Issuer
Issuer
Issuer
Zimswitch/Issuer
Issuer
Issuer
Issuer
Issuer
Issuer
Zimswitch/Issuer

Accept
Decline
Decline
Decline
Decline
Decline
Decline
Decline
Decline
Decline

(POS)
(POS & ATM)
(ATM)
(POS)

Decline
Decline
Decline
Decline
Capture
Capture (ATM)
Capture
Accept
Accept

Zimswitch
Issuer

Accept
Accept

Issuer

Accept

Zimswithc/Issuer
Zimswitch
Zimswitch
Zimswitch
Zimswitch/Issuer

Decline
Decline
Decline
Decline
Decline

Issuer

Decline

CHECKED BY SWITCH - VALID CODE

Note : Now that 1987 transactions are no longer supported and
there is no need for mapping messages and response/action codes,
Zimswitch now endorses he full table of action-codes as detailed in the
93 edition of the standard, Table A.1.
However it is conceded that many FEPs even if they support 1993, 2003
versions of the standard, are still based in 1987 in their core systems therefore
The following table may be useful.
93_Code Fields
APPROVED

93 Resp
Code
000

-38-

87 Resp
Code
0

CTL
Approved

APPROVED_CHANGED_ACC
APPROVED_PARTIAL_CHANGED_ACC
APPROVED_UPDATE_ICC
FILE_ACTION_SUCCESSFUL
REV_ACCEPTED
RECON_IN_BALANCE
ADMIN_ACCEPTED
FEE_ACCEPTED
NWRK_MNG_ACCEPTED
REFER_TO_CI

005
006
007
300
400
500
600
700
800
107

0
0
0
0
0
0
0
0
0
1

REFER_TO_CI_SPECIAL
INVALID_MERCHANT
DO_NOT_HONOUR
DO_NOT_HONOUR
SPECIAL_CONDITIONS_PICK_UP
HONOUR_WITH_ID
REQUEST_IN_PROGRESS
APPROVED_PARTIAL
APPROVED_VIP
INVALID_TRANSACTION
INVALID_AMOUNT
INVALID_CARD_NUMBER

108
109
100
100
207
001
923
002
003
902
110
111

APPROVED_UPDATE_TRACK_3

004

REENTER_TRANSACTION

903

UNACCEPTABLE_FEE
FILE_ACTION_NOT_SUPORTED
ADMIN_ORIG_TRAN_NOT_FOUND

113
301
601

FILE_FIELD_EDIT_ERROR
FILE_LOCKED_OUT
FILE_ACTION_NOT_SUCCESSFUL
FORMAT_ERROR
CARD_ISSUER_UNAVAILABLE

304
305
306
904
912

EXPIRED_CARD_PICK_UP
SUSPECTED_FRAUD_PICK_UP
CONTACT_ACQ_PICK_UP
RESTRICTED_CARD_PICK_UP
CALL_ACQUIRER_SECURITY_PICK_UP
PIN_TRIES_EXCEEDED
PIN_TRIES_EXCEEDED_PICK_UP
FUNCTION_NOT_SUPPORTED
LOST_CARD_PICK_UP
NO_ACCOUNT_OF_REQUESTED_TYPE
STOLEN_CARD_PICK_UP
NO_ACCOUNT_OF_REQUESTED_TYPE
NO_ACCOUNT_OF_REQUESTED_TYPE

201
202
203
204
205
106
206
115
208
114
209
114
114

NOT_SUFFICIENT_FUNDS

116

2
3
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
51

-39-

Approved
Approved
Approved
Approved
Approved
Approved
Approved
Approved
Approved
Refer to issuer
Refer to card issuer, special
condition
Invalid merchant
Do not honor
Error
pick us special
Honour with identification
Request in progress
Approved for partial amount
VIP Approval
Invalid transaction
Invalid amount
Card number does not exist
No such issuer
Approved, update track 3
Customer cancellation
Customer dispute
Re-enter transaction
Invalid response
No action taken (no match)
Suspected malfunction
Unacceptable transaction fee
File upd not supported by rcvr
Unable to locate record
Duplicate file update record
File update field edit error
File temporarily unavailable
File update not successful
Format error
Issuer sign-off
Completed partially
Expired card
Suspected fraud
Card acceptor contact acquirer
Restricted card
Card acceptor call acquirer
Allowable PIN tries exceeded
No credit account
Function not supported
Pick up card (lost card)
No universal account
Pick up card (stolen card)
No investment account
Account closed
Identification required
Not sufficient funds

NO_ACCOUNT_OF_REQUESTED_TYPE
NO_ACCOUNT_OF_REQUESTED_TYPE
EXPIRED_CARD
INCORRECT_PIN
NO_CARD_RECORD
TRAN_NOT_PERMITTED_CARDHOLDER
TRAN_NOT_PERMITTED_TERMINAL
SUSPECTED_FRAUD
CONTACT_ACQUIRER
EXCEEDS_WITHDRAWAL_AMNT_LIMIT
RESTRICTED_CARD
SECURITY_VIOLATION

114
114
101
117
118
119
120
102
103
121
104
122

EXCEEDS_WITHDRAWAL_FREQ_LIMIT

123

DO_NOT_HONOUR_PICK_UP

200

PIN_TRIES_EXCEEDED

106

CARD_NOT_EFFECTIVE

125

CUTOVER_OR_CHKPT_ERROR

915

CUTOVER_IN_PROGRESS
ISSUER_OR_SWITCH_INOPERATIVE
CARD_ISSUER_UNAVAILABLE
ROUTING_ERROR
VIOLATION_OF_LAW
DUPLICATE_TRANSMISSION
RECON_OUT_OF_BALANCE
SYSTEM_MALFUNCTION
MAC_INCORRECT
MAC_KEY_SYNC_ERROR
CARD_ISSUER_SIGNED_OFF
CARD_ISSUER_TIMED_OUT
CUTOVER_OR_CHKPT_ERROR
NO_COMMS_KEY
ENCR_KEY_SYNC_ERROR
SECURITY_ERROR_RETRY
SECURITY_ERROR_NO_ACTION
MSG_NR_OUT_OF_SEQ

906
907
912
908
124
913
501
909
916
917
910
911
915
918
919
920
921
922

5.22

FIELD 40 SERVICE CODE

Field No.

Format Attribute

-40-

52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
75
76
77
80
81
82
83
84
85
86
88
89
90
91
91
92
93
94
95
96
XA
XD

No checking account
No savings account
Expired card
Incorrect PIN
No card record
Trxn not permitted to card
Trxn not permitted to card
Suspected fraud
Card acceptor contact acquirer
Exceeds withdrawal limit
Restricted card
Security violation
Original amount incorrect
Activity count exceeded
Card acceptor call acquirer
Card pick up at ATM
Response received too late
Too many wrong PIN tries
Previous message not found
Data does not match original m
Invalid date
Cryptographic error in PIN
Incorrect CVV
Unable to verify PIN
Invld authorization life cycle
No reason to decline
PIN validation not possible
Cryptographic failure
Authentication failure
Cutoff is in process
Issuer or switch inoperative
Issuer or switch inoperative
No routing path
Violation of law
Duplicate transmission
Reconcile error
System malfunction
Forward to issuer
Forward to issuer

43

n 3

An identification of geographic/service availability. Contains:

The area of usage and whether the card has additional read
facilities
1 International card
2 International card - integrated circuit facilities
5 National use only
6 National use only - integrated circuit facilities
9 Test card - online authorization mandatory
The authorization processing requirements for this card
0 Normal authorization
2 Online authorization mandatory
4 Online authorization mandatory
The range of services available and PIN requirements
0 PIN required
1 No restrictions - normal cardholder verification
2 Goods and services only
3 PIN required, ATM only
5 PIN required, goods and services only at POS, cash at ATM
6 PIN required if PIN pad present
7 PIN required if PIN pad present, goods and services only at
POS, cash at ATM

5.23

FIELD 41 CARD ACCEPTOR TERMINAL IDENTIFICATION

Field No.
41

Format Attribute
ans 8

Contains a unique code identifying a device at the card acceptor

location.
The value in a reversal and in all responses must match the
value in the original financial request.
The purpose of this field is to provide a unique identifier for all
3PA device positions.
-41-

3PAs should generate this field in every request message.

5.24

FIELD 43

CARD ACCEPTOR NAME / LOCATION

Field No.
43

Format Attribute
LLVAR

ans..99

Contains the name and location of the card acceptor.

The value in all responses must match the value in the original
financial request.
The purpose of this field is to provide a unique identifier for all
acquirer ATM or POS device positions. The acquirer must ensure
that the data in this field is consistent with the requirements of
ISO 8583. ZIMSWITCH will pass on what it receives, it will not
verify or change the data.
Acquirers should generate this field in every request message.
5.25 FIELD 48 ADDITIONAL DATA
Field No.

Format Attribute

48

LLLVAR ans..999

Used to provide linked account or mini-statement information

for a linked account inquiry or a mini-statement inquiry.
Format - TBA.

5.26

FIELD 49
Field No.
49

CURRENCY CODE, TRANSACTION

Format Attribute
a or n 3

Code 716 = Zimbabwe $

The local currency of the acquirer or source location of the
transaction. Currency used in amount, transaction and amount,
transaction fees.

-42-

The inclusion of this field at this stage is not essential, but there
is a possibility that transactions will be switched to foreign
switches in the future, e.g. SASWITCH in South Africa.
ISO 4217 provides currency code values.
5.27

FIELD 52
Field No.
52

PERSONAL IDENTIFICATION NUMBER (PIN)

Format Attribute
b 8

Contains a number assigned to a cardholder intended to

uniquely identify that cardholder at the ATM. The field will
contain the encrypted field data.
Note: To maintain the security of customer identification, PINs
are never sent through ZIMSWITCH in the clear. PINs must
always be transmitted in encrypted form. All PIN encryption /
decryption / re-encryption functions will be performed through
hardware security modules.
The Acquirer should translate the PIN provided at the ATM to a
PIN block encrypted under the Acquirer Working Key (AWK).
ZIMSWITCH will re-encrypt the PIN block to the Issuer Working
Key (IWK) for delivery to the issuer for the issuer to perform
PIN verification.
This field will be blank if the message originates from a mobile
phone for a mobile payment, which fact will be indicated by
201 for Mobile phone in field 60 Point of Service Device type
5.28

FIELD 54

ADDITIONAL AMOUNTS

Field No.

Format Attribute

54

LLLVAR ans..120

The value in a reversal response message (0410) must match

the value in the corresponding request response message
(0210).
N.B. Amounts are expressed in the minor unit of the currency thus ZIM $ 100.00 is expressed as 000000010000
note - field 054 is made up as follows:field
length data

-43-

account type 2
as defined in positions 3/4 or 5/6 of Processing Code
amount type 2
01
currency code 3
716 if Zimbabwe $
sign
1
- or blank ( - if balance negative )
value
12
account ledger balance
- - -- - - - - - - - -- - - - - - - - - - -- - - - - - - - - account type 2
as defined in positions 3/4 or 5/ 6 of Processing Code
amount type 2
02 (see standard appendix A.2)
currency code 3
716 if Zimbabwe $
sign
1
- or blank ( - if balance negative )
value
12
account available balance
-----------------------------------------account type 2
as defined in positions 3/4or 5/6 of Processing Code
amount type 2
40
currency code 3
716 if Zimbabwe $
sign
1
- or blank ( - if balance negative )
value
12
amount cash (POS - value of cash with purchase)
Zeroes are acceptable in this field. One set or all sets may be present.

5.29

FIELD 56

ORIGINAL DATA ELEMENTS

Field No.
56

Format Attribute
LLVAR

n..35

Contains the data elements contained in the original message,

intended for transaction matching.
The data contents are as follows
Pos 1-4
Pos 5-10
Pos 11-22
Pos 23-24
Pos 25-35

msg
field
field
field

type
11
12
32

n4
Original message type identifier
n 6
Original system trace audit number
n 12
Original date and time, local transaction
n..11(LLVAR)Original acquiring institution identification code- length
Original acquiring institution identification code data

CHECKED BY SWITCH - FOR PRESENCE AND VALIDITY

5.30

FIELD 59

TRANSPORT DATA

Field No.

Format Attribute

59

LLLVAR ans..999

This field is used in two ways:

a)

Contains the key exchange data.

-44-

The purpose of this field is to transmit the encrypted Issuer

Working, Acquirer Working and MAC Keys using the following
sub-fields.
Field 059 has the following format:
Sub-field name Format Position

Comment

Key Type

n 2

04-05

Key Direction

n 2

06-07

PIN AWK
PIN AWK cd
PIN IWK
PIN IWK cd
MAC WK
MAC WK cd

an-16
an-6
an-16
an-6
an-16
an-6

08-23
24-29
30-45
46-51
52-67
68-73

00 = PIN key
01 = PIN & MAC key
01 = Inbound key only
02 = Outbound key only
03 = Both In& Outbound keys
Hex chars 0...9 and A...F
Hex chars 0...9 and A...F
Hex chars 0...9 and A...F
Hex chars 0...9 and A...F
Hex chars 0...9 and A...F
Hex chars 0...9 and A...F

The Working Key contains the hexadecimal representation of

the 64 bits of the new encryption key, encrypted under the
current Zone control key.
The cd (check digit) contains the hexadecimal representation of
the first four check digits (binary zeroes encrypted under the
new key). The check value is formed by encrypting 64 binary
zeroes with the working key. The HSM will return the most
significant (left-most) 24 bits as 6 hexadecimal characters.
This field is also used to return an indecipherable message to
the sender. The full message will be inserted in this field as
follows -

5.31

Sub-field name Format

Position

Comment

Key Type

04-999

Indecipherable message

ans..999

FIELD 60 POINT OF SERVICE DEVICE TYPE

Field No.

Format Attribute

60

LLLVAR ans..999

Contains the point of service device type as below -

-45-

Pos 4-6

Device type

001
101
201
301
401

ATM
POS
Mobile phone
Internet
VRU

If this field is not present in financial message it will be rejected.

CHECKED BY SWITCH - FOR PRESENCE AND VALIDITY

5.32

FIELD 61 E-COMMERCE SECURITY TAG

Field No.

Format Attribute

61

LLLVAR ans..999

Contains a TAG that the Switch can use to verify if the message
was authorised via the eDirectory Contents to be advised.
CHECKED BY SWITCH - FOR PRESENCE AND VALIDITY

5.33 FIELD 93 TRANSACTION DESTINATION INSTITUTION ID CODE

Field No.
93

Format Attribute
LLVAR

n..11

Code identifying the institution that is the transaction destination

Only used in 18XX messages.

5.34 FIELD 94 TRANSACTION ORIGINATOR INSTITUTION ID CODE

Field No.
94

Format Attribute
LLVAR

n..11

Code identifying the institution that is the transaction originator.

-46-

Note :

5.35

Acquiring FI will not use this field.

Only apply in 1800 messages

FIELD 100
Field No.
100

RECEIVING INSTITUTION ID CODE

Format Attribute
LLVAR

n..11

Contains the code identifying the receiving institution, be it the

ATM owner bank or the Issuer bank or ZIMSWITCH or external
interchange or switch.

5.36

FIELD 102
Field No.
100

ACCOUNT INDENTIFICATION 1
Format Attribute
LLVAR

an..28

A series of digits used to identify a customer account or

relationship (e.g. for the from account). This will be used in
the ZIMSWITCH context to contain the From account in a
Request Response. Note - the Primary Account value in Track II
is not relevant for receipt printing and this field must be used for
ATM / POS receipts.

5.37

FIELD 103
Field No.
100

ACCOUNT IDENTIFICATION 2
Format Attribute
LLVAR

an..28

A series of digits used to identify a customer account or

relationship (e.g. for the to account). This account
identification will only become relevant if Account transfers are
permitted through ZIMSWITCH.

5.38

FIELD 128

MESSAGE AUTHENTICATION CODE

-47-

Field No.
128

Format Attribute
b 8

Contains the code used to validate the source and text of the
message between the sender and the receiver.

-48-

Message Layouts

6.1
6.1.1

MESSAGE LAYOUTS - ISO 8583 EDITION 1993

MESSAGE LAYOUTS GENERAL

6.2.1.1 CONDITIONS IN MESSAGE TABLES

Conditions used to determine presence or absence of a field, such as M for
Mandatory. This applies to the column in message layouts that is headed M/O.
01
02
03
07
10
16
19
27
M
ME
O

Mandatory if fees affect reconciliation

Mandatory if information is available and not present in the track II
data
Mandatory, shall contain the same data as the original financial
message
Mandatory if the account number conforms to ISO 7812
Mandatory when the forwarding institution is not the same as the
institution originating the message
Mandatory in a response message if the data element was present in
the original request or advice message. If present, it shall contain the
same data as the original message.
Mandatory when the receiving institution is not the same as the final
destination of the message
Mandatory, shall echo the first two positions of the processing code in
the original message
Mandatory
Mandatory echo, shall echo the same data as the original message
Optional

6.2.1.2 COMMENTS COLUMN

The comments column contains data specific only to the relevant field. In
previous editions of the specification this column contained cross-references to
other sections in the specification. This is not necessary as all field
characteristics can be found in the relevant field definitions in the relevant
section - please refer to the table of contents.

-49-

6.1.2

1804/1805 NETWORK MANAGEMENT REQUEST

FIELD N
001
007
011
012
015
024
028
032
037
059
093
094
128

6.1.3

DATA ELEMENT NAME

Bit map, extended
Transmission Date & Time
System Trace Audit Number
Date & Time, Local Transaction
Date settlement
Function code
Date, reconciliation
Acquiring Institution ID code
Retrieval Reference Number
Transport data

M/O
COMMENTS
M
M (for 1987 Messages)
M
M
M
M
M
M
M
O Key Exchange data or
indecipherable message
Transaction destination institution
M
ID code
Transaction originator institution
M
ID code
Message Authentication Code
M

1814 NETWORK MANAGEMENT REQUEST RESPONSE

FIELD N DATA ELEMENT NAME
001
Bit map, extended
007
Transmission Date & Time
011
System Trace Audit No
012
Date & Time, Local Tran
015
Date settlement
024
Function Code
028
Date, reconciliation
032
Acquiring System ID Code
037
Retrieval Reference No
039
Action Code
059
Transport data
093
094
128

M/O COMMENTS
M
M (for 1987 messages)
ME
ME
ME
ME
ME
ME

Transaction destination
institution ID code
Transaction originator
institution ID code
Message Authentication Code

-50-

ME
M
16 Key Exchange data
/indecipherable message
ME
ME
M

6.1.4

1200/1201
FIELD N
001
002
003
004
007
011
012
014
015
019
022
024
026

6.1.5

FINANCIAL TRANSACTION REQUEST

DATA ELEMENT NAME

Bit map, extended
Primary Account Number
Processing Code
Transaction Amount
Transmission Date & Time
System Trace Audit Number
Date & Time, Local Transaction
Date expiration
Date settlement
Acquiring Institution country code
Point of Service data code
Function Code
Card Acceptor Business Code

M/O COMMENTS
M
07
M
M
M (for 1987 messages)
M
Matching field
M
Matching field
M
M
M
M
M
M See ISO 8583
section A.4
M
M Matching field
M
O
M
M
M
M

028
032
033
035
037
041
043
049
052
054

Date, Reconciliation
Acquiring Institution Identification Code
Forwarding Institution Identification Code
Track 2 Data
Retrieval reference number
Card Acceptor Terminal ID
Card Acceptor Name/Location
Transaction Currency Code
PIN Data M
Amounts, Additional

060

Point of service device type

100
128

Receiving Institution Identification Code

Message Authentication Code

19
M

Only required if
Cash Back (POS)
001 - ATM, 101 POS

1210 FINANCIAL TRANSACTION REQUEST RESPONSE

FIELD N DATA ELEMENT NAME
001
Bit map, extended
002
Primary Account Number
003
Processing Code
004
Transaction Amount
007
Transmission date & time
011
System Trace Audit Number
012
Date & Time, Local Transaction
014
Date expiration
015
Date settlement
019
Acquiring Institution country code
022
Point of Service data code
024
Function Code
026
Card Acceptor Business Code
028

Date, Reconciliation

-51-

M/O COMMENTS
M
16
27
M
M for '87 messages
ME Matching field
ME Matching field
ME
ME
ME
ME
ME
ME See ISO 8583
section A.4
ME

032
033
035
037
039
043
041
049
054
060
100
102
103
128

6.1.6

Acquiring Institution Identification Code

Forwarding Institution Identification Code
Track 2 Data
Retrieval reference number
Action Code
Card Acceptor Name/Location
Card Acceptor Terminal ID
Currency code, transaction
Amounts, additional
Point of service device type
Receiving Institution Identification Code
Account Identification 1
Account Identification 2
Message Authentication Code

ME
M
OE
ME
M
M
ME
ME
M
ME
ME
M
O
M

1420/1421 ACQUIRER REVERSAL REQUEST

FIELD N DATA ELEMENT NAME
001
Bit map, extended
002
Primary Account Number
003
Processing Code
004
Transaction Amount
007
Transmission Date & Time
011
System Trace Audit Number
012
Date & Time, Local Transaction
014
Date expiration
015
Date settlement
022
Point of service data code
024
Function Code
026
Card acceptor business code
028
Date, Reconciliation
032
Acquiring Institution Identification Code
033
Forwarding Institution Identification Code
035
Track 2 Data
037
Retrieval reference number
041
Card Acceptor Terminal ID
043
Card Acceptor Name/Location
049
Transaction Currency Code
054
Amounts, Additional
056

Original data elements

060
100
102
103
128

Point of service device type

Receiving Institution Identification Code
Account Identification 1
Account Identification 2
Message Authentication Code

-52-

M/O COMMENTS
M
07
03
ME
M
ME
ME
ME
ME
ME
M
ME
ME
ME
O
ME
ME
ME
ME
ME
O Only required if
Cash Back(POS)
M Orig. data
for matching
M
ME
M
O not this phase
M

6.1.7

1430 ACQUIRER REVERSAL REQUEST RESPONSE

FIELD N DATA ELEMENT NAME
001
Bit map, extended
002
Primary Account Number
003
Processing Code
004
Transaction Amount
007
Transmission date & time
011
System Trace Audit Number
012
Date & Time, Local Transaction
014
Date expiration
015
Date settlement
022
Point of service data code
024
Function Code
026
Card Acceptor Business Code
028
Date, Reconciliation
032
Acquiring Institution Identification Code
033
Forwarding Institution Identification Code
035
Track 2 Data
037
Retrieval reference number
039
Action Code
041
Card Acceptor Terminal ID
049
Currency code, transaction
054
Amounts, Additional
056
Original data elements
060
Point of service device type
100
Receiving Institution Identification Code
102
Account Identification 1
103
Account Identification 2
128
Message Authentication Code

-53-

M/O COMMENTS
M
16
16
M
ME
ME
ME
ME
ME
ME
ME
ME
ME
ME
M
OE
ME
M
ME
ME
ME no bals for rev.
ME
ME
ME
M
O not this phase
M

ISO 8583 MESSAGES - FIELD USAGE MATRIX

Field
001
002
003
004
007
011
012
014
015
019
022
024
026
028
032
033
035
037
039
041
043
049
052
054
056
059
060
093
094
100
102
103
128

X1 -

Name

1200/1 1210

Bit map, extended

X
Primary account number (PAN)
Processing code
X
Amount, transaction
X
Transmission data and time
X
System Trace Audit Number
X
Date & Time, Local transaction
X
Date, Expiration
X
Date, Settlement
X
Acquiring Institution Country Code X
Point of service data code
X
Function Code
X
Card Acceptor Business Code
X
Date, reconciliation
X
Acquiring Institution ID Code
X
Forwarding Institution ID Code
X
Track 2 Data
X
Retrieval reference number
Action code
Card acceptor terminal ID
X
Card acquirer name / location
X
Currency code, transaction
X
Personal ID number (PIN)
X
Amounts, additional
X
Original data elements
Transport data
Point of service device type
X
Transaction destination FI id code
Transaction originator FI id code
Receiving FI Identification Code X
Account Identification 1
Account Identification 2
Message Auth.Code (Long)
X

X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X

1420/1 1430

1804/5 1814

X
X
X
X
X
X
X
X
X

X
X
X
X
X
X
X
X
X

X
X
X

X
X
X

X
X
X
X
X
X
X
X
X

X
X
X
X
X
X
X
X

X
X

X
X

X
X

X1

X1

X
X

X
X

X
X

X
X

X
X

X
X

X
X

Used in Key Exchange messages - contains the encrypted Zone Working Key
indecipherable messages returned to sender by switch

-54-

and Used in

Appendices
Appendix A Glossary

ATM

Automatic Teller Machine

FI

Financial Institution

TCP/IP

Transmission Control Protocol / Internet Protocol

IWK

Issuer Working Key

PIN

Personal identification number

AWK

Acquirer Working Key

MAC

Message Authentication Code

-55-