Zimswitch Technical Spec Including3PA v0-51

8/9/2019 Zimswitch Technical Spec Including3PA v0-51

1/56

-0-

ISO8583(93)

Specifications

ZimSwitch Technical Specification

For

Third Party Acquirers to Zimswitch

Version 0.5(Draft)

October 2006

_____________________________________


2/56

-1-

No part of this document may be reproduced or transmittedin any form or by any means, electronic or mechanical,for any purpose, without express written permission of:

The Managing DirectorZimSwitch

Harare ZimbabweZimSwitch is committed to ongoing research and development

in order to track technological developments and customer in themarket. Consequently, information contained in this document may be

subject to change without prior notice.

Windows NT,Windows 2000, SQL Serverare trademarksof Microsoft Corporation.


3/56

-2-

Document Version Control

Date Version Comments

September 5,2006

0.1 Zimswitch 3PA Technical Specificationcreated from the Zimswitch TechnicalSpecification for ATM Transactionsand Point Of Sale Debit CardTransactions.

September 28,2005

0.2 Re-released for Comments

October 13,2006

0.3 Released to 3PAs for comments andguidance.

October 27,

2006

0.4 Included additional Transaction setsas per 3PAs requirements

November 17,

2006

0.5 No Changes, released with newVersion


4/56

-3-

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


5/56

-4-

2 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

3 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

4 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


6/56

-5-

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

4.9.1 CANCELLATION...................................................25

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

5 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 DATE, RECONCILIATION................................35

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


7/56

-6-

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

6 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

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

Appendices ................................................................................. 55

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


8/56

-7-

1 General Points

1.1 Scope

This document specifies a technical interface between ZimSwitch and ThirdParty 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 toother transactions sets to accommodate third party processors and orIndependent Service Organisations (ISO).

This interface is based on the International Standard ISO 8583 Second Ed1993-12-15 message protocol standard. Where possible, this standard hasbeen adhered to, but in circumstances where either ZimSwitch or FIrequirements cannot be accommodated, exceptions have been made to theusage of the 1993 edition.

ZIMSWITCH personnel, ZIMSWITCH partners and software suppliers areassumed to be in possession of the ISO 8583 standard. Reference must bemade 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 toZimSwitch are specified in this document no attempt has been made toreproduce the ISO specification.

1.2 Authorisation Criteria

ZimSwitch will not be configured to perform any stand-in authorisation onbehalf of 3PAs. In circumstances when the link from the Acquirer to ZimSwitchis unavailable the Acquirer will reject the transaction. In circumstances whenthe link from ZimSwitch to the card Issuer is unavailable, then the transactionwill be rejected by ZimSwitch. There will be no attempt to process transactionson a store and forward basis.

1.2.1 Reversals Store and Forward

The one exception to this rule pertains to 1400 messages which are reversalmessages which are mandatory, 'must deliver' messages. An Acquirer isobliged to keep repeating reversal messages until such time as they areacknowledged by the Issuer. It can happen that an Issuer goes 'off-line' to

ZimSwitch environment after having authorised a transaction whichsubsequently fails at the Acquirer for any number of reasons. In thesecircumstances, the Acquirer repeats the reversal endlessly without there being


9/56

-8-

any possible acknowledgement from the Issuer. This endless repetition createsstress in all the systems involved. Hence if ZimSwitch receives a reversal for anIssuer who is off-line to the switch, ZimSwitch will intervene and acknowledgethe reversal and effectively store and forward it, thus taking responsibility forthe risk and the delivery of that transaction. If such a transaction has still notbeen 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 someIssuers who have issued cards that require signature authorisation at POS e.g.Barclays Bank Zimbabwe. Zimswitch POS acquirer terminals can prompt forPIN or signature verification, according to BIN number. However it is still asingle message authorisation process, and Zimswitch and Zimswitchparticipants accept no risk liability with regard to these signature authorisedtransactions. 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 therequirements of ZimSwitch and its Issuers.

To authenticate and secure the link between the 3PA and Zimswitch a SecureSocket 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 withsecure hardware methods. ZimSwitch will change the Acquirer Working Key(AWK) every time the link has been re-established after having dropped andmay change the key randomly throughout the day even if the link has not beendropped.

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 MessageAuthentication Code (MAC). Message authentication operates by sharing anoperational Message Authentication Key (KWA) between two systems. This keyis exchanged under a mutual Key Encrypting Key (KEK).

The MAC generation algorithm is based on the DES CBC mode and is specifiedin the ANSI X9.9 standard.

1.3.4 Key Management

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


10/56

-9-

is the Zone Working Key scheme. ZimSwitch will be the sole provider of bothkey types. The Zone Working Key is provided over the interchange. Each endof the link holds a Zone Control Master key which is established by the threeperson manual key loading scheme. The frequency with which the ZoneWorking 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 astream-oriented protocol the first two bytes of any message arriving atZimSwitch indicates the length of the message (excluding the length indicator).Similarly, a two byte length indicator is prefixed to any message sent byZimswitch.

The length indicator is packed as an unsigned 16-bit integer, with the mostsignificant (the high 8 bits) in the first byte, and the least significant (the low 8bits) in the second byte.

1.5 Call Setup

At Call Set-up time the 3PA must establish a TCP/IP client connection toZimSwitch This may be over a single physical link, or distributed over the duallinks which each 3PA supports. The latter would be preferable as this providesautomatic redundancy in case of a single failure.

Once established, the TCP/IP connection should remain permanently connectedand should only be cleared under exception conditions (i.e. bad line conditions,etc.). If the connection is cleared for any reason, the 3PA should automaticallyattempt to re-establish the TCP/IP session at regular intervals of no less than 5seconds.

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 onlineexchange of messages.

Cut-Off will always be initiated by ZimSwitch and is governed at the agreedcut-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 willgo into the ZimSwitch store-and-forward (SAF) file for delivery as soon as that3PA 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


11/56

-10-

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 = PIN (n = PIN length)

Digits n+1 to 16 = Pad Characters (F)

1.9 Transaction Fee Charges

ZimSwitch has elected not to have Acquirer and Switch fees travel in eachmessage but to be determined by parameter at settlement time. Fees will nottravel with transaction messages as the fee field concerned (field 46) is relatedto on-line reconciliation, whereas ZimSwitch settlement and reconciliation isperformed as a batch operation, after the event.

Acquirer and Switch fees are determined by the participant FinancialInstitutions in agreement with each other and are entered to the switch asparameters 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 willbe 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 PrimaryAccount 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


12/56

-11-

current Fees and charges which are not strictly relevant to TechnicalSpecification.

However, for Settlement purposes, the basic points need to be noted here. Thebasic 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 Codeis used to denote the initiator of amessage, either the 3PA in the case of a Zimswitch acquired Transaction or thegenerator of a network message which could be the 3PA owner or theAuthoriser (Issuer) or ZimSwitch as appropriate.

The release of Acquirer Institution Identification Code to 3PAs will be managedby the Standards Association of Zimbabwe.

Forwarder Institution Identification Codeis used to denote ZimSwitch formessages that are passed through from Acquirer to Issuer such as CashWithdrawals and Balance Enquiries.

Receiving Institution Identification Codeis used to denote the recipient ofthe message. If the acquirer is not able to insert a valid value in this field avalue of all zeroes is acceptable. ZimSwitch will insert the derived value in thison pass-through.

In order to determine the Receiving Institution Identification Code the following


13/56

-12-

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 Codefield.

If not recognisable ISID then check Receiving Institution Identification

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


14/56

-13-

1.11 Zone Master Keys and Zone Working Keys

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

Key Exchange

Acquirer ZimSwitch Issuer

AWK encryptedunder ZMK 1

IWK encryptedunder ZMK 2

HSM

AWK and IWKgeneration

Message Transmission

Acquirer ZimSwitch Issuer

PIN encryptedunder AWK

PIN encryptedunder IWK

HSM

PIN translation,Acquirer to Issuer

zone


15/56

-14-

Store and Forward will be introduced to ZimSwitch. This will cover Reversalprocessing. The 3PA will deliver a reversal to ZimSwitch when appropriateexactly as it does in the current system. It will be the responsibility ofZimSwitch to deliver this reversal to the Issuer FI. If the Issuer FI is availableand does not time out to ZimSwitch, the latter will forward the ReversalResponse 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 laterdelivery and will immediately respond to the 3PA with a code indicatingacceptance of the Reversal.

The Issuer FI must accept this message. In the unlikely event that the IssuerFI rejects the Reversal (inability to match to the original request should be theonly criteria) when it is received from the ZimSwitch store and forwardprocess, ZimSwitch will log the rejection for off-line reconciliation between therelevant 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 ofcut-off.

ZimSwitch will hold transactions in its SAF file for varying and appropriatelengths of time, but will clear its SAF files manually by FI on an as and whenneeded basis. All such cleared transactions will be reported.


16/56

-15-

2 Message Structure

The messages passed between the 3PA and ZimSwitch are to be constructedwith the basic message structure prescribed by ISO8583.

Messages are constructed in the sequence:

message type identifier

bitmap(s)

data elements

Message TypeIdentifier

Bit map 1Bit map 2(Optional)

Data elements

4 bytes64 bits (8bytes)

64 bits (8bytes)

variableaccording to bitmaps

fields 01 64 fields 65 - 128bit on = fieldpresent

2.1 Message Type Identifier

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

12XX Financial Transaction Messages (1993)14XX Reversal Messages (1993)

18XX Network Management Messages (1993)

2.2 Bitmaps

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


17/56

-16-

The secondary bitmap is optional and will only be included for those messagesrequiring field(s) beyond 64.

For transmission purposes each bitmap of 64 bits is converted to 8 bytes. The64 bits are first converted into 16 groups of four. Then, each group of four bitsis assigned an hexadecimal equivalent according to the table shown on the

next page:BIT VALUE HEX VALUE

0000 0

0001 1

0010 2

0011 3

0100 4

0101 5

0110 6

0111 7

1000 8

1001 9

1010 A

1011 B

1100 C

1101 D

1110 E

1111 F

2.3 Data Elements

The bitmap serves as an index of data elements that are present in themessage. 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 thisspecification are detailed in Section 5.

2.4 Matching of Messages Edition 1993

2.4.1 Financial Transactions 12XX and 14XX


18/56


19/56

-18-

3 Error Handling

Conversation exception conditions have been detailed for particularconversations

3.1 Message Rejection

3.1.1 General

If either party receives a message that it cannot process, it is to reject themessage as follows:

If the message type is not recognised or is not specified as supported bythe ZimSwitch to Financial Institution Interface, then the receiver is notto respond to the sender. (The reasoning being that if the message typeidentifier is not recognised, the receiver would be unable to unpack the

message for the message matching fields (section 2.4) and also unableto respond with the corresponding response message.).

If the message type is recognised and supported but the contents cannotbe processed, then the receiver is to reply with the appropriate responsemessage 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 withappropriate 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 ZimSwitchwill generate a response to the 3PA with the response code 97 Issuernot available. This is one of the few occasions when ZimSwitch initiatesmessages.

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

3.1.2 Logging of Indecipherable Messages

In the event that a message recipient is unable to parse a message it isrecommended that the message be logged for further analysis off-line so thatresolution of the problem can be achieved. It is recommended that the

message is not responded to so that the originator may take normal time-outaction.


20/56

-19-

3.2 Message Time-out

The party initiating the message establishes the amount of time it will wait fora response to the message it initiated. Consideration should be given to thefollowing in establishing time-out periods:

The time-out period at the device (ATM/POS/MOBILE/INTERNET) must be atleast long enough to allow for the various processes noted below to complete.

DEVICE ----------> Acquirer FES ----------> ZimSwitch-----------> Issuer

DEVICE


21/56

-20-

4 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 theISO 8583 specification will always be present and will be fixed length. All otherbits must default to zero. In accordance with this rule a secondary BMP willalways be included in the network management message.

Network Management Processing

Network management functions between the 3PA and ZimSwitch are to beimplemented 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 thepurpose 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 clientcall connection. ( Port Numbers and IP addresses are supplied byZimswitch on request )

the 3PA will send a Logon request

ZimSwitch will respond to the Logon request with an action code '860' fora 1993 3PA (Logon not allowed, keys must first be exchanged). the FIshould 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 willrespond with an approval

if key implementation is successful, ZimSwitch will send a Logon requestto 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 1805message. If at this stage there is still no response, the message initiator willdrop the Link, re-establish it and attempt to Logon (3PA), implement key


22/56


23/56

-22-

(DATA)

64 bits of binary zeros

_______|__________

Zone Working Key _________ | |

(encrypted under | DES ALGORITHM |

Zone Control Master Key) | (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 bedropping the link.

Logoff messages are to be implemented in both directions on the switch. Theinitiating party sends an 1804 request with field 024 (function code) set to'802' and waits for an 1814 response. When the response is received, theinitiating party may drop the Link. If a response is not received, a maximum oftwo 1805 repeats will be attempted. If there is still no response, the partyinitiating the Logoff may drop the Link.

If a Logoff is processed while there is an outstanding transaction, theappropriate reversal processing will come into effect. If the Issuer is logged offto ZimSwitch then ZimSwitch will respond to any requests received from anacquirer 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 thesettlement-date and will send an 1804 advice to each 3PA. The 3PA will thenregister the changed business day.

BUSINESS DAY

The following ZimSwitch value dates apply currently:

PERIOD TRANSACTIONS RECEIVED VALUE DATE


24/56

-23-

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:00Thursday - after 19:00:00 up to & including 24:00:00

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

4.6 FINANCIAL TRANSACTION PROCESSING

The following dialogue scenarios are to be supported by ZimSwitch. In thedesired processing scenario, all transactions are handled on-line. Therefore, allfinancial transactions are Financial Transaction Requests.

The financial transaction functions between the 3PA and ZimSwitch are to beimplemented 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 themessage it is repeating.

4.6.1 Balance Enquiry 1200 and 1210

Balance enquiries are allowed at the Device. The Acquirer 3PA will forward an1200 request to ZimSwitch. ZimSwitch will forward the request to the Issuer FI

which will reply with an 1210 containing the account balance which ZimSwitchwill forward to the Acquirer.

4.6.2 Financial Transaction 1200 AND 1210

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

Zimswitch will reply with a 1210 to the Acquirer 3PA.


25/56

-24-

If the Acquirer 3PA receives a 1210 response after the transaction has timedout, if no previous 1210 had been received and if there was no outstanding1200 request, then the 3PA will initiate reversal/refund processing.

If the 3PA receives another 1210 response and a previous 1210 had beenreceived 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 willbe distinguished by the contents of the processing code.(field 3).

If the 3PA receives a 0210 response after the transaction has timed out, if noprevious 0210 had been received and if there was no outstanding 0200request, 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 the3PA should ignore the 0210.

4.7 REVERSAL PROCESSING

DEFINITIONS

The terms cancellation & reversal are used in this section and are clarifiedbelow:

CANCEL

In terms of ZimSwitch certification procedures, once a transaction hasbeen '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 samematching 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-outand the 3PA has not received a response.

If a transaction response message from the 3PA to the ATM has timedout.

If the 3PA has indicated to the device that the transaction has been

unsuccessful, and then receives a response from ZimSwitch indicating that thetransaction has been successfully received and updated.


26/56

-25-

Financial Reversals are MUST DELIVER messages which must be delivered byall 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 repeatsfail, ZimSwitch will record the response. The Acquirer is responsible forsending the reversal 1420 in the event of an outstanding 1200 request. Thiswill be the normal situation where the device has timed-out and the Acquirer isnot 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 mustgenerate an 1420 reversal. The Issuer FI receives the 1420 reversal matchingit with the related 1200 request. If the original 1200 request was declined theIssuer can record the 1420 as received and return an 1430 response. If the1200 request was accepted then the Issuer FI should record the 1420, re-credit the client account with the transaction amount and return an 1430

response. If an unmatched 1420 reversal arrives at the Issuer FI it should berecorded and ignored. If the 3PA receives a late 1210 ( after the 1420 requesthas been initiated ) response it must be recorded and ignored.

If the Issuer times-out to ZimSwitch or the Issuer FI is logged off, ZimSwitchwill send a Reversal Response to the 3PA and will log the reversal for Store andForward to the Issuer FI when contact is re-established.

N.B. Should ZimSwitch receive a late request response it will discard it. The3PA 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.


27/56

-26-


28/56

-27-

5 Message fields

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

a - alphabetic character, A through Z and a through z

n - Numeric digits, 0 through 9

ans - alphabetic, numeric and special characters

MM - Month, 01 through 12

YY - Year, 00 through 99 no apparent allowance for the turn of thecentury.

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

3 - fixed length of 3 characters

..11 - variable length up to 11

b - binary representation of data

z - track 2 code

Note - all fixed length n elements are presumed to be right justified withleading zeroes, except for those where examples show left justified with trailingspaces. All other fixed length data elements are left justified with trailingspaces.

See page Table 7 of ISO 8583 (1993) for legend of abbreviations used for theattributes in the following field descriptions.


29/56

-28-

5.1 FIELD 1 BIT MAP, EXTENDED

Field No. Format Attribute1 b 8

This field is a series of 64 bits used to identify thepresence(denoted by 1) or absence (denoted by 0) of the dataelements in the range 65 through 128.

The values must exactly reflect the presence or absence of dataelements 65 to 128.

Note: A bit stream such as a bit map, PIN or password dataelements in the ISO 8583 standard, may unintentionallyintroduce a control character into the transmission stream undercertain communications protocols. In such cases the bit streamshould be divided into 4-bit blocks and transferred to ASCII orEBCDIC depending on the protocol.

1993 messages will conform to the standard in thatvariable length fields will be variable length in the styleof the standard.

5.2 FIELD 2 PRIMARY ACCOUNT NUMBER (PAN)

Field No. Format Attribute

2 LLVAR n 19

PAN is a series of digits used to identify a customer account orrelationship.

Must be present for Card Not Present Transactions

5.3 FIELD 3 PROCESSING CODE


3 n 6

The same code appears in all messages for a given transaction.The field is logically divided into three subfields as follows:


30/56

-29-

Pos. Subfield Values Description1-2 Tran code 00 Goods and services

01 Cash02 Debit Adjustment09 Goods & services + cash

18 PrePaid20 Refund22 Credit Adjustment - purchase28 Credit Adjustment - cash31 Balance enquiry50 Utility Bill Payment

Device Description001 - ATM 01 Cash

18 PrePaid

31 Balance

Device Description101 - POS 00 Goods and Services

01 Cash09 Sale and Cash Back18 PrePaid20 Refund31 Balance enquiry

50 Utility Bill Payment

Device Description201 Mobile 18 PrePaid

21 - Credit31 Balance Enquiry38 Mini Statement40 Transfer Inter Acc42 Transfer 3rdParty

50 Utility Bill Payment91 Message to Bank

Device Description301 Internet 18 PrePaid

21 - Credit31 Balance Enquiry38 Mini Statement40 Transfer Inter Acc42 Transfer 3rdParty50 Utility Bill Payment91 Message to Bank


31/56

-30-

3-4 From 00 DefaultAccount type 10 Savings account

20 Cheque account30 Credit card

5-6 To 00 N/A until transfers are introducedAccount type

If Account type (digits 3-4) = 00 then the transaction must beperformed 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


4 n 12

Transaction amount gives the value of the funds requested bythe cardholder in the local currency of the acquirer or sourcelocation of the transaction.

Where a transaction amount does not apply to a transactiontype (e.g. balance enquiries) the element must still be presentin 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 inthe 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


32/56

-31-

5.5 FIELD 7 TRANSMISSION DATE AND TIME

This field is not necessary in edition 1993, but if is included itmust 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


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 usedin any related response messages and in subsequent reversalmessages.

Acquirers should generate this field in every request message.For Reversals, Acquirers must use the identical STAN that wasused in the original transaction

Zimswitch will map the STAN in all reversal requests to field 37(Retrieval Reference number) before sending the reversal ontoissuer. The 93 Issuer must then ensure that all reversals arematched to the original financial transaction using field 37.Effectively this field has been superseded by field 37, RetrievalReference number.

CHECKED BY SWITCH - PRESENT

5.7 FIELD 12 DATE AND TIME, LOCAL TRANSACTION


12 YYMMDDhhmmss n 12


33/56

-32-

Contains the local date time at which the transaction takes placeat the point of the card acceptor location.

All parties should ensure that this field's integrity is maintainedand that it is logged with each message within the network.


5.8 FIELD 13 DATE, EFFECTIVE

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

5.9 FIELD 14 DATE, EXPIRATION


14 YYMM n 4

Contains the year and month after which the card expires.Generally cards only have effective or expiry dates if there is aspecific contract in place for their use such as that between a

Credit card issuer and their clients. This field has beenrequested by ZIMSWITCH.

Responses should return the value contained in the originalrequest.

CHECKED BY SWITCH PRESENT

5.10 FIELD 15 DATE, SETTLEMENT


15 YYMMDD n 6

Contains the year, month and day that funds will be transferredbetween acquirer and card issuer.

This field is set up by ZIMSWITCH for all requests beforeforwarding the messages to the issuer. It will contain the switchsettlement date that applies to the transaction. Issuers shouldreturn the value received in all related responses.


34/56

-33-

Responses should return the value contained in the originalrequest.

N.B. This field also referred to as Current Business Day.


5.11 FIELD 19 ACQUIRER INSTITUTION COUNTRY CODE


19 n 3

5.12 FIELD 22 POINT OF SERVICE DATA CODE

Field No. Format Attriibute

22 an 12

A series of codes intended to identify terminal capability, terminalenvironment and presentation security data. It shall be used to

indicate specific conditions that are (or were) pertinent at the time oftransaction.

The table below illustrates the contents of this field that are currentlyvalid for ZIMSWITCH ATM and POS transactions.

Pos 1 Card data input capability 1 Manual, no terminal2 Magnetic stripe read (ATM & POS)

Pos 2 Cardholder authentication capability 1 PIN (ATM & POS)Pos 3 Card capture capabilit 0 None

1 Capture

Pos 4 Operating environment 2 On premises of card acceptor, unattended(ATM)

3 Off premises of card acceptor,attended(POS)

Pos 5 Cardholder present 0 Cardholder present (ATM & POS)Pos 6 Card present 1 Card present (ATM & POS)Pos 7 Card data input mode 1 Manual, no te rminal

2 Magnetic stripe read ATM & POS)Pos 8 Cardholder authentication method 1 PIN (ATM & POS)

5 Manual, signature verification (POS)Pos 9 Cardholder authentication entity 3 Authorising agent (ATM & POS)Pos 10 Card data output capability 0 Unknown (POS)

1 None (ATM &/or POS)Pos 11 Terminal output capability 0 Unknown (POS)

1 None (POS)2 Printing (ATM & POS)


35/56

-34-

3 Display (ATM & POS)4 Printing and display (ATM & POS)

Pos 12 PIN capture capability 4 Four characters (ATM & POS)


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

5.13 FIELD 23 CARD SEQUENCE NUMBER


23 n 3

A number distinguishing between separate cards with the same primaryaccount number or primary account number extended.

5.14 FIELD 24 FUNCTION CODE


24 n 3


36/56

-35-

Contains a number assigned to a network management activity. Thetable below illustrates the contents of this field (codes used to representnetwork activity).

200 - Original financial request

400 - Full reversal, transaction did not complete as approved801 - Log on802 - Log off811 - Key change821 - Cut off831 - Echo Test860 - Return of indecipherable message


5.15 FIELD 26 CARD ACCEPTOR BUSINESS CODE


26 n 4

Code classifying the type of business being done by the card acceptor forthis transaction.

Please refer to the ISO 8583 1993 edition specification section A.4 forthe code to be inserted in this field.

ZIMSWITCH will not check the value, but will pass on the value to theIssuer.

5.16 FIELD 28 DATE, RECONCILIATION


28 YYMMDD n 6

Contains the year, month and day that funds will be reconciled betweenacquirer and card issuer.

This field is set up by ZIMSWITCH for all requests before forwarding themessages to the issuer. It will contain the switch reconciliation (sameas 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.


37/56

-36-



5.17 FIELD 32 ACQUIRING INSTITUTION IDENTIFICATION CODE


32 LLVAR n..11

Contains the code identifying the 3PA or ZIMSWITCH in the caseof messages initiated by ZIMSWITCH.

This field is one of the key data elements used to uniquelyidentify messages associated with a particular transaction.Participants should ensure that this field's integrity is maintainedand that it is logged with each message within the network.

In requests and reversals the acquirer should use the valueassigned at certification time. The value used in the originalrequest / reversal should be used by issuers in subsequentresponses.


5.18 FIELD 33 FORWARDING INSTITUTION IDENTIFICATION CODE


33 LLVAR n..11

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

This field is one of the key data elements used to uniquelyidentify messages associated with a particular transaction.Participants should ensure that this field's integrity is maintainedand that it is logged with each message within the network.

In requests and reversals the acquirer should use the valueassigned at certification time. The value used in the original

request / reversal should be used by issuers in subsequentresponses.


38/56

-37-

In the context of ZIMWITCH as it currently is configured, theonly acceptable value is the ZIMSWITCH code. In the event thatZIMSWITCH connects to other interchanges or switches, thisfield will contain the relevant Forwarding InstitutionIdentification Code. Refer - table 10 of ISO 8583 edition 1993for clarification of Institution Identification Code relationships.


5.19 FIELD 35 TRACK 2 DATA


35 LLVAR z 37

Contains the information encoded on track 2 of the magneticstripe as defined in ISO 7813, excluding beginning and endingsentinels and LRC characters as defined therein.

This field is required in all financial requests where Card Presenttransactions are processed.

5.20 FIELD 37 RETRIEVAL REFERENCE NUMBER


37 anp 12

A reference supplied by the system retaining the original sourceinformation and used to assist in locating that information or acopy thereof.

New field, effectively replaces STAN, field 11, for matching

transactions, messages.


5.21 FIELD 39 ACTION CODE


39 n 3

Contains a code which defines the disposition of the message


39/56

-38-

TABLE OF ACTION CODES

CODE ACTION DESCRIPTION RETURNED BY ACTN

000 Approved Issuer Accept100 Do not honour Issuer Decline (POS)

101 Expired card Issuer Decline (POS & ATM)104 Restricted card Issuer Decline (ATM)106 PIN tries exceeded Issuer Decline (POS)107 Refer to card issuer Issuer Decline111 Invalid card number Issuer Decline114 Invalid account Issuer Decline115 Requested function not supported Issuer Decline116 Not sufficient funds Issuer Decline117 Incorrect PIN Issuer Decline120 Transaction not permitted to terminal Issuer Decline121 Exceeds withdrawal amount limit Issuer Decline123 Exceeds withdrawal frequency limit Issuer Decline

126 Invalid PIN block Zimswitch/Issuer Decline200 Do not honour Issuer Capture201 Expired Card Issuer Capture (ATM)206 Allowable PIN tries exceeded Issuer Capture400 Accepted - applicable to Issuer Accept

reversal - 14XX Issuer800 Accepted - applicable to network Zimswitch/Issuer Accept

management - 18XX860 Nat.Use - wait for key exchange Zimswitch Accept861 Nat.Use - problem in key exchange Issuer Accept

message862 National.Use - Issuer Accept

(Issuer can't do key exchange)

902 Invalid transaction Zimswithc/Issuer Decline904 Format error e.g. missing Bitmap Zimswitch Decline907 Card issuer unavailable Zimswitch Decline908 No such Issuer Zimswitch Decline909 Default for failed transaction, Zimswitch/Issuer Decline

really system malfunction930 Nat. Use - default for tran. Issuer Decline

not processed


Note : Now that 1987 transactions are no longer supported andthere is no need for mapping messages and response/action codes,Zimswitch now endorses he full table of action-codes as detailed in the93 edition of the standard, Table A.1.

However it is conceded that many FEPs even if they support 1993, 2003versions of the standard, are still based in 1987 in their core systems thereforeThe following table may be useful.

93_Code Fields93 Resp

Code87 Resp

Code CTL

APPROVED 000 0 Approved


40/56

-39-

APPROVED_CHANGED_ACC 005 0 Approved

APPROVED_PARTIAL_CHANGED_ACC 006 0 Approved

APPROVED_UPDATE_ICC 007 0 Approved

FILE_ACTION_SUCCESSFUL 300 0 Approved

REV_ACCEPTED 400 0 Approved

RECON_IN_BALANCE 500 0 Approved

ADMIN_ACCEPTED 600 0 Approved

FEE_ACCEPTED 700 0 Approved

NWRK_MNG_ACCEPTED 800 0 ApprovedREFER_TO_CI 107 1 Refer to issuer

REFER_TO_CI_SPECIAL 108 2Refer to card issuer, specialcondition

INVALID_MERCHANT 109 3 Invalid merchant

DO_NOT_HONOUR 100 5 Do not honor

DO_NOT_HONOUR 100 6 Error

SPECIAL_CONDITIONS_PICK_UP 207 7 pick us special

HONOUR_WITH_ID 001 8 Honour with identification

REQUEST_IN_PROGRESS 923 9 Request in progress

APPROVED_PARTIAL 002 10 Approved for partial amount

APPROVED_VIP 003 11 VIP ApprovalINVALID_TRANSACTION 902 12 Invalid transaction

INVALID_AMOUNT 110 13 Invalid amount

INVALID_CARD_NUMBER 111 14 Card number does not exist

15 No such issuer

APPROVED_UPDATE_TRACK_3 004 16 Approved, update track 3

17 Customer cancellation

18 Customer dispute

REENTER_TRANSACTION 903 19 Re-enter transaction

20 Invalid response

21 No action taken (no match)

22 Suspected malfunction

UNACCEPTABLE_FEE 113 23 Unacceptable transaction fee

FILE_ACTION_NOT_SUPORTED 301 24 File upd not supported by rcvr

ADMIN_ORIG_TRAN_NOT_FOUND 601 25 Unable to locate record

26 Duplicate file update record

FILE_FIELD_EDIT_ERROR 304 27 File update field edit error

FILE_LOCKED_OUT 305 28 File temporarily unavailable

FILE_ACTION_NOT_SUCCESSFUL 306 29 File update not successful

FORMAT_ERROR 904 30 Format error

CARD_ISSUER_UNAVAILABLE 912 31 Issuer sign-off

32 Completed partially

EXPIRED_CARD_PICK_UP 201 33 Expired card

SUSPECTED_FRAUD_PICK_UP 202 34 Suspected fraudCONTACT_ACQ_PICK_UP 203 35 Card acceptor contact acquirer

RESTRICTED_CARD_PICK_UP 204 36 Restricted card

CALL_ACQUIRER_SECURITY_PICK_UP 205 37 Card acceptor call acquirer

PIN_TRIES_EXCEEDED 106 38 Allowable PIN tries exceeded

PIN_TRIES_EXCEEDED_PICK_UP 206 39 No credit account

FUNCTION_NOT_SUPPORTED 115 40 Function not supported

LOST_CARD_PICK_UP 208 41 Pick up card (lost card)

NO_ACCOUNT_OF_REQUESTED_TYPE 114 42 No universal account

STOLEN_CARD_PICK_UP 209 43 Pick up card (stolen card)

NO_ACCOUNT_OF_REQUESTED_TYPE 114 44 No investment account

NO_ACCOUNT_OF_REQUESTED_TYPE 114 45 Account closed46 Identification required

NOT_SUFFICIENT_FUNDS 116 51 Not sufficient funds


41/56

-40-

NO_ACCOUNT_OF_REQUESTED_TYPE 114 52 No checking account

NO_ACCOUNT_OF_REQUESTED_TYPE 114 53 No savings account

EXPIRED_CARD 101 54 Expired card

INCORRECT_PIN 117 55 Incorrect PIN

NO_CARD_RECORD 118 56 No card record

TRAN_NOT_PERMITTED_CARDHOLDER 119 57 Trxn not permitted to card

TRAN_NOT_PERMITTED_TERMINAL 120 58 Trxn not permitted to card

SUSPECTED_FRAUD 102 59 Suspected fraud

CONTACT_ACQUIRER 103 60 Card acceptor contact acquirerEXCEEDS_WITHDRAWAL_AMNT_LIMIT 121 61 Exceeds withdrawal limit

RESTRICTED_CARD 104 62 Restricted card

SECURITY_VIOLATION 122 63 Security violation

64 Original amount incorrect

EXCEEDS_WITHDRAWAL_FREQ_LIMIT 123 65 Activity count exceeded

66 Card acceptor call acquirer

DO_NOT_HONOUR_PICK_UP 200 67 Card pick up at ATM

68 Response received too late

PIN_TRIES_EXCEEDED 106 75 Too many wrong PIN tries

76 Previous message not found

77 Data does not match original mCARD_NOT_EFFECTIVE 125 80 Invalid date

81 Cryptographic error in PIN

82 Incorrect CVV

83 Unable to verify PIN

84 Invld authorization life cycle

85 No reason to decline

86 PIN validation not possible

CUTOVER_OR_CHKPT_ERROR 915 88 Cryptographic failure

89 Authentication failure

CUTOVER_IN_PROGRESS 906 90 Cutoff is in process

ISSUER_OR_SWITCH_INOPERATIVE 907 91 Issuer or switch inoperative

CARD_ISSUER_UNAVAILABLE 912 91 Issuer or switch inoperative

ROUTING_ERROR 908 92 No routing path

VIOLATION_OF_LAW 124 93 Violation of law

DUPLICATE_TRANSMISSION 913 94 Duplicate transmission

RECON_OUT_OF_BALANCE 501 95 Reconcile error

SYSTEM_MALFUNCTION 909 96 System malfunction

MAC_INCORRECT 916 XA Forward to issuer

MAC_KEY_SYNC_ERROR 917 XD Forward to issuer

CARD_ISSUER_SIGNED_OFF 910

CARD_ISSUER_TIMED_OUT 911

CUTOVER_OR_CHKPT_ERROR 915

NO_COMMS_KEY 918

ENCR_KEY_SYNC_ERROR 919

SECURITY_ERROR_RETRY 920

SECURITY_ERROR_NO_ACTION 921

MSG_NR_OUT_OF_SEQ 922

5.22 FIELD 40 SERVICE CODE



42/56

-41-

43 n 3

An identification of geographic/service availability. Contains:The area of usage and whether the card has additional read

facilities

The authorization processing requirements for this card

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 atPOS, cash at ATM

5.23 FIELD 41 CARD ACCEPTOR TERMINAL IDENTIFICATION


41 ans 8

Contains a unique code identifying a device at the card acceptorlocation.

The value in a reversal and in all responses must match thevalue in the original financial request.

The purpose of this field is to provide a unique identifier for all3PA device positions.

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

0 Normal authorization

2 Online authorization mandatory4 Online authorization mandatory


43/56

-42-

3PAs should generate this field in every request message.

5.24 FIELD 43 CARD ACCEPTOR NAME / LOCATION


43 LLVAR ans..99

Contains the name and location of the card acceptor.

The value in all responses must match the value in the originalfinancial request.

The purpose of this field is to provide a unique identifier for allacquirer ATM or POS device positions. The acquirer must ensurethat the data in this field is consistent with the requirements ofISO 8583. ZIMSWITCH will pass on what it receives, it will notverify or change the data.

Acquirers should generate this field in every request message.

5.25 FIELD 48 ADDITIONAL DATA


48 LLLVAR ans..999

Used to provide linked account or mini-statement informationfor a linked account inquiry or a mini-statement inquiry.

Format - TBA.

5.26 FIELD 49 CURRENCY CODE, TRANSACTION


49 a or n 3

Code 716 = Zimbabwe $The local currency of the acquirer or source location of thetransaction. Currency used in amount, transaction and amount,transaction fees.


44/56

-43-

The inclusion of this field at this stage is not essential, but thereis a possibility that transactions will be switched to foreignswitches in the future, e.g. SASWITCH in South Africa.

ISO 4217 provides currency code values.

5.27 FIELD 52 PERSONAL IDENTIFICATION NUMBER (PIN)


52 b 8

Contains a number assigned to a cardholder intended touniquely identify that cardholder at the ATM. The field willcontain the encrypted field data.

Note: To maintain the security of customer identification, PINsare never sent through ZIMSWITCH in the clear. PINs mustalways be transmitted in encrypted form. All PIN encryption /decryption / re-encryption functions will be performed throughhardware security modules.

The Acquirer should translate the PIN provided at the ATM to aPIN block encrypted under the Acquirer Working Key (AWK).ZIMSWITCH will re-encrypt the PIN block to the Issuer WorkingKey (IWK) for delivery to the issuer for the issuer to perform

PIN verification.

This field will be blank if the message originates from a mobilephone 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


54 LLLVAR ans..120

The value in a reversal response message (0410) must matchthe 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


45/56

-44-

account type 2 as defined in positions 3/4 or 5/6 of Processing Codeamount type 2 01currency 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 Codeamount 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 Codeamount type 2 40currency 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


56 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 msg type n 4 Original message type identifierPos 5-10 field 11 n 6 Original system trace audit numberPos 11-22 field 12 n 12 Original date and time, local transactionPos 23-24 field 32 n..11(LLVAR)Original acquiring institution identification code- lengthPos 25-35 Original acquiring institution identification code data

CHECKED BY SWITCH - FOR PRESENCE AND VALIDITY

5.30 FIELD 59 TRANSPORT DATA


59 LLLVAR ans..999

This field is used in two ways:

a) Contains the key exchange data.


46/56

-45-

The purpose of this field is to transmit the encrypted IssuerWorking, Acquirer Working and MAC Keys using the followingsub-fields.

Field 059 has the following format:

Sub-field name Format Position Comment

Key Type n 2 04-05 00 = PIN key01 = PIN & MAC key

Key Direction n 2 06-07 01 = Inbound key only02 = Outbound key only03 = Both In& Outbound keys

PIN AWK an-16 08-23 Hex chars 0...9 and A...FPIN AWK cd an-6 24-29 Hex chars 0...9 and A...FPIN IWK an-16 30-45 Hex chars 0...9 and A...F

PIN IWK cd an-6 46-51 Hex chars 0...9 and A...FMAC WK an-16 52-67 Hex chars 0...9 and A...FMAC WK cd an-6 68-73 Hex chars 0...9 and A...F

The Working Key contains the hexadecimal representation ofthe 64 bits of the new encryption key, encrypted under thecurrent Zone control key.

The cd (check digit) contains the hexadecimal representation ofthe first four check digits (binary zeroes encrypted under thenew key). The check value is formed by encrypting 64 binaryzeroes with the working key. The HSM will return the mostsignificant (left-most) 24 bits as 6 hexadecimal characters.

This field is also used to return an indecipherable message tothe sender. The full message will be inserted in this field asfollows -

Sub-field name Format Position Comment

Key Type ans..999 04-999 Indecipherable message

5.31 FIELD 60 POINT OF SERVICE DEVICE TYPE


60 LLLVAR ans..999

Contains the point of service device type as below -


47/56

-46-

Pos 4-6 Device type - 001 ATM101 POS201 Mobile phone301 Internet401 VRU

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


5.32 FIELD 61 E-COMMERCE SECURITY TAG


61 LLLVAR ans..999

Contains a TAG that the Switch can use to verify if the messagewas authorised via the eDirectory -

Contents to be advised.


5.33 FIELD 93 TRANSACTION DESTINATION INSTITUTION ID CODE


93 LLVAR n..11

Code identifying the institution that is the transaction destinationOnly used in 18XX messages.

5.34 FIELD 94 TRANSACTION ORIGINATOR INSTITUTION ID CODE


94 LLVAR n..11

Code identifying the institution that is the transaction originator.


48/56

-47-

Note : Acquiring FI will not use this field.Only apply in 1800 messages

5.35 FIELD 100 RECEIVING INSTITUTION ID CODE


100 LLVAR n..11

Contains the code identifying the receiving institution, be it theATM owner bank or the Issuer bank or ZIMSWITCH or externalinterchange or switch.

5.36 FIELD 102 ACCOUNT INDENTIFICATION 1


100 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 inthe ZIMSWITCH context to contain the From account in aRequest Response. Note - the Primary Account value in Track IIis not relevant for receipt printing and this field must be used forATM / POS receipts.

5.37 FIELD 103 ACCOUNT IDENTIFICATION 2


100 LLVAR an..28

A series of digits used to identify a customer account orrelationship (e.g. for the to account). This accountidentification will only become relevant if Account transfers arepermitted through ZIMSWITCH.

5.38 FIELD 128 MESSAGE AUTHENTICATION CODE


49/56

-48-


128 b 8

Contains the code used to validate the source and text of the

message between the sender and the receiver.


50/56

-49-

6 Message Layouts

6.1 MESSAGE LAYOUTS - ISO 8583 EDITION 1993

6.1.1 MESSAGE LAYOUTS GENERAL

6.2.1.1 CONDITIONS IN MESSAGE TABLES

Conditions used to determine presence or absence of a field, such as M forMandatory. This applies to the column in message layouts that is headed M/O.

01 Mandatory if fees affect reconciliation02 Mandatory if information is available and not present in the track II

data

03 Mandatory, shall contain the same data as the original financialmessage

07 Mandatory if the account number conforms to ISO 781210 Mandatory when the forwarding institution is not the same as the

institution originating the message16 Mandatory in a response message if the data element was present in

the original request or advice message. If present, it shall contain thesame data as the original message.

19 Mandatory when the receiving institution is not the same as the finaldestination of the message

27 Mandatory, shall echo the first two positions of the processing code inthe original messageM MandatoryME Mandatory echo, shall echo the same data as the original messageO Optional

6.2.1.2 COMMENTS COLUMN

The comments column contains data specific only to the relevant field. Inprevious editions of the specification this column contained cross-references toother sections in the specification. This is not necessary as all field

characteristics can be found in the relevant field definitions in the relevantsection - please refer to the table of contents.


51/56

-50-

6.1.2 1804/1805 NETWORK MANAGEMENT REQUEST

FIELD N DATA ELEMENT NAME M/O COMMENTS

001 Bit map, extended M

007 Transmission Date & Time M (for 1987 Messages)

011 System Trace Audit Number M

012 Date & Time, Local Transaction M

015 Date settlement M

024 Function code M

028 Date, reconciliation M

032 Acquiring Institution ID code M

037 Retrieval Reference Number M

059 Transport data O Key Exchange data or

indecipherable message

093 Transaction destination institution M

ID code

094 Transaction originator institution M

ID code128 Message Authentication Code M

6.1.3 1814 NETWORK MANAGEMENT REQUEST RESPONSE



007 Transmission Date & Time M (for 1987 messages)011 System Trace Audit No ME

012 Date & Time, Local Tran ME

015 Date settlement ME

024 Function Code ME

028 Date, reconciliation ME

032 Acquiring System ID Code ME

037 Retrieval Reference No ME

039 Action Code M

059 Transport data 16 Key Exchange data

/indecipherable message

093 Transaction destination ME

institution ID code094 Transaction originator MEinstitution ID code

128 Message Authentication Code M


52/56

-51-

6.1.4 1200/1201 FINANCIAL TRANSACTION REQUEST



002 Primary Account Number 07

003 Processing Code M

004 Transaction Amount M

007 Transmission Date & Time M (for 1987 messages)011 System Trace Audit Number M Matching field012 Date & Time, Local Transaction M Matching field014 Date expiration M

015 Date settlement M

019 Acquiring Institution country code M

022 Point of Service data code M

024 Function Code M

026 Card Acceptor Business Code M See ISO 8583

section A.4

028 Date, Reconciliation M032 Acquiring Institution Identification Code M Matching field033 Forwarding Institution Identification Code M

035 Track 2 Data O

037 Retrieval reference number M

041 Card Acceptor Terminal ID M

043 Card Acceptor Name/Location M

049 Transaction Currency Code M

052 PIN Data M

054 Amounts, Additional O Only required if

Cash Back (POS)060 Point of service device type M 001 - ATM, 101 -

POS

100 Receiving Institution Identification Code 19

128 Message Authentication Code M

6.1.5 1210 FINANCIAL TRANSACTION REQUEST RESPONSE



002 Primary Account Number 16003 Processing Code 27


007 Transmission date & time M for '87 messages

011 System Trace Audit Number ME Matching field012 Date & Time, Local Transaction ME Matching field014 Date expiration ME


019 Acquiring Institution country code ME

022 Point of Service data code ME


026 Card Acceptor Business Code ME See ISO 8583section A.4

028 Date, Reconciliation ME


53/56


54/56

-53-

6.1.7 1430 ACQUIRER REVERSAL REQUEST RESPONSE



002 Primary Account Number 16

003 Processing Code 16


007 Transmission date & time ME011 System Trace Audit Number ME

012 Date & Time, Local Transaction ME

014 Date expiration ME


022 Point of service data code ME


026 Card Acceptor Business Code ME

028 Date, Reconciliation ME

032 Acquiring Institution Identification Code ME

033 Forwarding Institution Identification Code M035 Track 2 Data OE

037 Retrieval reference number ME

039 Action Code M

041 Card Acceptor Terminal ID ME

049 Currency code, transaction ME

054 Amounts, Additional ME no bals for rev.056 Original data elements ME

060 Point of service device type ME

100 Receiving Institution Identification Code ME

102 Account Identification 1 M

103 Account Identification 2 O not this phase128 Message Authentication Code M


55/56

-54-

7 ISO 8583 MESSAGES - FIELD USAGE MATRIX

Field Name 1200/1 1210 1420/1 1430 1804/5 1814

001 Bit map, extended X X X X X X

002 Primary account number (PAN) X X X

003 Processing code X X X X

004 Amount, transaction X X X X

007 Transmission data and time X X X X X X

011 System Trace Audit Number X X X X X X

012 Date & Time, Local transaction X X X X X X

014 Date, Expiration X X X X

015 Date, Settlement X X X X X X

019 Acquiring Institution Country Code X X

022 Point of service data code X X X X

024 Function Code X X X X X X

026 Card Acceptor Business Code X X X X

028 Date, reconciliation X X X X X X

032 Acquiring Institution ID Code X X X X X X

033 Forwarding Institution ID Code X X X X

035 Track 2 Data X X X X

037 Retrieval reference number X X X X X X

039 Action code X X X

041 Card acceptor terminal ID X X

043 Card acquirer name / location X X

049 Currency code, transaction X X X X

052 Personal ID number (PIN) X

054 Amounts, additional X X X X

056 Original data elements X X059 Transport data X1 X1

060 Point of service device type X X X X

093 Transaction destination FI id code X X

094 Transaction originator FI id code X X

100 Receiving FI Identification Code X X X X

102 Account Identification 1 X X X

103 Account Identification 2

128 Message Auth.Code (Long) X X X X X X

X1 - Used in Key Exchange messages - contains the encrypted Zone Working Key and Used in

indecipherable messages returned to sender by switch


56/56

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

Date post:	01-Jun-2018
Category:	Documents
Upload:	takuoteo9580
View:	284 times
Download:	7 times

Zimswitch Technical Spec Including3PA v0-51

Documents