H2Hspecs PDF

Host-to-Host
Specifications
Integrated Transaction Management (ITM) is a registered trademark of Euronet

Worldwide, Inc.
4601 College Boulevard, Suite 300
Leawood, Kansas 66211
Tel: 1-913-327-4200
Fax: 1-913-327-1921
E-mail: mail@euronetworldwide.com
Visit our home page at www.euronetworldwide.com.
Copyright 2004 Euronet Worldwide, Inc.
Printed in the United States of America. All rights reserved.
Any and all product names, company names, logos, and trade names used in this
publication are assumed to be the legal property of their respective companies and are
used here for identification purposes only. No part of this work covered by the copyrights
hereon may be reproduced or used in any form or by any means without the express
written permission of Euronet Worldwide, Inc.
LIMITATION OF LIABILITY: PRODUCT DOCUMENTATION IS AS ACCURATE AS
POSSIBLE AS OF THE TIME OF PRODUCT RELEASE. HOWEVER, EURONET
WORLDWIDE INC. WILL NOT BE LIABLE FOR ANY DIFFERENCES BETWEEN
PRODUCT FUNCTIONALITY AND THE PRODUCT DOCUMENTATION. EURONET
WORLDWIDE, INC. MAKES NO OTHER WARRANTIES WITH RESPECT TO THE
PRODUCTS, OR ANY SERVICES, AND DISCLAIMS ALL OTHER WARRANTIES,
EXPRESSED OR IMPLIED, INCLUDING WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. FURTHER,
EURONET WORLDWIDE, INC. DOES NOT WARRANT, GUARANTEE OR MAKE ANY
RESPRESENTATIONS REGARDING THE USE, OR THE RESULTS OF THE USE, OF
ANY PRODUCTS OR RELATED DOCUMENTATION IN TERMS OF CORRECTNESS,
ACCURACY, RELIABILITY OR OTHERWISE. Some states or jurisdictions do not allow the
exclusion or limitation of incidental or consequential damages; so the above limitations may
not apply to you.
4601 College Boulevard, Suite 300

Leawood, Kansas 66211
Host-to-Host Specifications
Contents
Contents
Chapter One: Online Participant Interface
Specifications for Host-to-Host ................................. 1-1
Section 1: Basic Transaction Support........................ 1-1
Introduction.......................................................................................................................................... 1-1
System Definitions............................................................................................................................... 1-2
Character Set.................................................................................................................................... 1-2
Master Participant, Cutover and Settlement Amounts..................................................................... 1-3
Message Authentication Code Usage .............................................................................................. 1-3
Dynamic Key Exchange Support..................................................................................................... 1-3
File Update 03xx Messages Support................................................................................................ 1-3
Transmission of Binary Data Elements ........................................................................................... 1-4
Differences to ISO-8583: 1987 Standard......................................................................................... 1-4
Message Definitions............................................................................................................................. 1-5
General Message Structure .............................................................................................................. 1-5
Message Types................................................................................................................................. 1-5
Bitmap.............................................................................................................................................. 1-6
Message Matching ........................................................................................................................... 1-6
Matching Response to Request.................................................................................................... 1-6
Match Follow-up Messages to the Original Message.................................................................. 1-7
Issuer Processing.............................................................................................................................. 1-7
Issuer Message Processing........................................................................................................... 1-7
Acquirer Processing ......................................................................................................................... 1-8
Card Acceptance .......................................................................................................................... 1-8
Acquirer Message Processing ...................................................................................................... 1-8
Message Flow .................................................................................................................................. 1-9
Network Management Messages ................................................................................................. 1-9
Normal Completion Logon, Logoff, and Echo Messages .................................................. 1-10
Normal Completion Cutover.................................................................................................. 1-10
Exception Processing No Response.................................................................................... 1-11
Exception Processing Message Declined............................................................................ 1-12
Authorization Messages............................................................................................................. 1-12
Authorization Normal Completion ........................................................................................ 1-13
Authorization Reversal Processing ........................................................................................ 1-14
Authorization Reversal Timeout Processing ......................................................................... 1-15
Authorization Advice Normal Completion............................................................................ 1-16
Authorization Advice Timeout Processing............................................................................ 1-16
Financial Transaction Messages ................................................................................................ 1-17
Financial Transaction Normal Completion............................................................................ 1-17
Financial Transaction Reversal Processing ........................................................................... 1-18
Financial Transaction Reversal Timeout Processing............................................................. 1-19
Euronet Worldwide
Contents
Financial Transaction Advice Normal Completion ............................................................... 1-20

Financial Transaction Advice Timeout Processing ............................................................... 1-21
Reversal Messages ..................................................................................................................... 1-21
Reversal Normal Completion ................................................................................................ 1-22
Reversal Timeout Processing................................................................................................. 1-23
Message Format ............................................................................................................................. 1-24
Data Element Definitions................................................................................................................... 1-28
Data Elements .................................................................................................................................... 1-29
Communications Requirements ......................................................................................................... 1-48
TCP/IP Connection ........................................................................................................................ 1-48
X.25 Connection ............................................................................................................................ 1-48
Security Requirements ....................................................................................................................... 1-49
Security Zones and Key Management ........................................................................................... 1-49
PIN Block Encryption.................................................................................................................... 1-50
Certification Requirements ................................................................................................................ 1-50
Section 2: Optional Extended Transaction Support . 1-51

Introduction........................................................................................................................................ 1-51
General Message Definitions......................................................................................................... 1-52
Message Types........................................................................................................................... 1-52
Request Messages ...................................................................................................................... 1-52
Response Messages.................................................................................................................... 1-53
Extended Data Support .................................................................................................................. 1-53
ISO Data Fields.......................................................................................................................... 1-53
Data Format ............................................................................................................................... 1-54
Field 3: Processing Code ....................................................................................................... 1-54
Fields 120 - 123: Extended Data............................................................................................ 1-54
Message Flow by Transaction Type .............................................................................................. 1-63
List Account Open Account Relationship (OAR) .................................................................. 1-63
OAR Data Flow ..................................................................................................................... 1-64
Acquirer OAR Accounts Returned .................................................................................... 1-64
Acquirer 0 Accounts Returned........................................................................................ 1-65
Acquirer 1 Account Returned ......................................................................................... 1-66
Acquirer OARDS Not Received..................................................................................... 1-67
Goldnet............................................................................................................................... 1-68
Mini-statement ........................................................................................................................... 1-68
PIN Change................................................................................................................................ 1-69
GSM Recharge........................................................................................................................... 1-70
GSM Recharge, Touch-points ............................................................................................... 1-70
GSM Recharge, Voucher-based............................................................................................. 1-70
GSM Recharge, Online-based ............................................................................................... 1-71
Mobile Recharge Registration ............................................................................................... 1-72
Account Verification.............................................................................................................. 1-73
Bill Payment............................................................................................................................... 1-73
Bill Payment, Touch-points ................................................................................................... 1-73
Euronet Worldwide
Contents
Request List of Defined Bill Payment Relationships ............................................................ 1-73

Request Relationship Details ................................................................................................. 1-74
Pay Bill................................................................................................................................... 1-75
Service Request.......................................................................................................................... 1-75
Chapter Two: Batch Participant Specifications.......... 2-1

Introduction.......................................................................................................................................... 2-1
Communication Requirements............................................................................................................. 2-1
Batch Participant File Specifications ................................................................................................... 2-2
Daily Transaction File...................................................................................................................... 2-3
Batch Update File ............................................................................................................................ 2-8
Account Balance Record.................................................................................................................. 2-8
Card Account Relationship Update Record................................................................................... 2-12
Card File Update Record ............................................................................................................... 2-14
Batch Update Balance History Record .......................................................................................... 2-18
Chapter Three: ITM Settlement Procedures .............. 3-1

Introduction.......................................................................................................................................... 3-1
Settlement Concepts............................................................................................................................. 3-1
Settlement Reporting ........................................................................................................................... 3-2
Examples of Report Usage................................................................................................................... 3-3
Cardholder Activity Report.............................................................................................................. 3-4
Terminal Activity Report................................................................................................................. 3-5
Participant Transaction Posting ........................................................................................................... 3-6
Settlement Accounts ........................................................................................................................ 3-6
Adjustments ..................................................................................................................................... 3-6
Suspense Reporting.......................................................................................................................... 3-6
Settlement Report Structure................................................................................................................. 3-7
Cardholder Activity Report.............................................................................................................. 3-7
Terminal Activity Report................................................................................................................. 3-8
Chapter Four: Steps of Certification for Host-to-Host 4-1

Introduction.......................................................................................................................................... 4-1
Related Document............................................................................................................................ 4-1
Areas of Responsibility........................................................................................................................ 4-2
Host .................................................................................................................................................. 4-2
Member Institution........................................................................................................................... 4-2
Certification Process ............................................................................................................................ 4-2
Testing Procedure ............................................................................................................................ 4-2
Test Results...................................................................................................................................... 4-3
Certification Completion ................................................................................................................. 4-3
Detailed Certification Process.............................................................................................................. 4-3
Preparatory Activities ...................................................................................................................... 4-3
Host .............................................................................................................................................. 4-3
Euronet Worldwide
Contents
Member ........................................................................................................................................ 4-4

Connectivity Tests ........................................................................................................................... 4-4
Telecommunication Connectivity Tests ...................................................................................... 4-4
Application Connectivity Tests.................................................................................................... 4-4
Issuer Tests....................................................................................................................................... 4-5
Acquirer Tests.................................................................................................................................. 4-5
Certification Forms .............................................................................................................................. 4-6
Test Cards Form............................................................................................................................... 4-6
Off-us Test Cards Form ................................................................................................................... 4-7
Test Encryption Keys Form ............................................................................................................. 4-8
Certification Scripts ............................................................................................................................. 4-9
Test Case 001: Telecommunication Level Connectivity ................................................................. 4-9
Test Case 002: Application Level Connectivity ............................................................................ 4-10
Test Case 003: Issuer Request Formats for Standard Transaction Types................................... 4-11
Test Case 004: Issuer Response Code Acceptance..................................................................... 4-19
Test Case 005: Issuer PIN Processing ........................................................................................ 4-20
Test Case 006: Acquirer Request Formats for Standard Transaction Types .............................. 4-22
Test Case 007: Acquirer Response Code Acceptance ................................................................ 4-29
Appendix A: Transaction Types ................................. A-1

Appendix B: Response Codes .................................... B-1
Appendix C: Currency Codes ..................................... C-1
Appendix D: Account Types.......................................D-1
Euronet Worldwide
Online Participant Interface Specifications
1-1
Chapter One: Online Participant

Interface Specifications for Host-toHost
Section 1: Basic Transaction Support
Introduction
This document defines the Host-to-Host Interface Specifications in detail. It provides clear
understanding of both the online and batch interfaces, certification information, protocols and
messages used, to enable evaluation and implementation of the Host-to-Host connection, and to
serve as a basic document for future enhancements. Unless indicated otherwise, this document
addresses ISO-8583:1987 standard and standard Host-to-Host transaction set. This document
also addresses underlying communication aspects. Host-to-Host Interface is capable of
supporting both acquirers and issuers.
All terms defined in this section are valid in the context of this document.
Term
Definition
Member
Acquirer
Bank or other institution connecting to host via Host-toHost connection

The master connection that will route or process
transactions for participants.
One of parties in Host-to-Host connection (either host or
the member)
The participant that originates the message
Issuer
The participant that receives the message
Master Participant
The participant (in Host-to-Host connection) that defines

the business day and calculates settlement parameters
The participant (in Host-to-Host connection) that is not
the Master participant
Host
Participant
Slave Participant
Euronet Worldwide
1-2
The following acronyms appear throughout this document.

Acronym
Meaning
ATM
Automated Teller Machine
AWK
Acquirer Working Key
BSC
CVV
Binary Synchronous Point-to-Point Communications

Link Protocol
Card Verification Value
DE
Data Element
DKE
Dynamic Key Exchange
ISO-8583
IWK
International Standards Organization standards for

messaging supported by the host. Unless specified
otherwise, it refers to ISO-8583:1987 version.
Issuer Working Key
MAC
Message Authentication Code
MCC
Merchant Category Code
MTID
Message Type ID
OAR
List Account Open Account Relationship
PAN
Primary Account Number
PIN
Personal Identification Number
POS
Point-of-Sale/Point-of-Service
PVV
PIN Verification Value
STAN
System Trace Audit Number
SVC
Switched Virtual Circuit
WK
Working Key
ZMK
Zone Master Key
System Definitions
Character Set
The Host-to-Host interface supports EBCDIC character set. Optional ASCII character set can be
supported by request during project setup.
Euronet Worldwide
1-3
Master Participant, Cutover and

Settlement Amounts
The participant that defines the business day (by sending a Cutover Message) and calculates the
settlement amounts is regarded as the master participant in Host-to-Host connection. The
participant that is not the master is regarded as the slave participant in Host-to-Host connection.
Unless otherwise agreed, the master participant is the host and the slave participant is the
member.
Message Authentication Code Usage

Message Authentication ensures the integrity of sensitive data elements within the message.
Message Authentication Code (MAC) is generated by the message originator based upon
message elements defined in advance by the originator and recipient, and included into the
message. MAC is verified by recipient based on same criteria set forth in generation. MACing
is done prior to normal processing of the message.
MACing is optional at the members discretion and is not covered in this document.
Dynamic Key Exchange Support

Dynamic Key Exchange (DKE) allows the Host-to-Host connection to process key exchanges
using an 0800 Network Management Message. DE-70 (bit 70) determines what type of key
exchange will be performed. DE-48 (bit 48) transmits the key information.
DKE is optional at members discretion.
File Update 03xx Messages Support

In certain system architectures (when the host performs a stand-in, a transaction pre-validation,
etc. on behalf of issuer member) the host maintains a copy of members card/account/balance
database. File Update 03xx messages allow such a member to update certain information on the
host side, in an online fashion. Examples are online change of card statuses and action codes
(activation, blocking, de-blocking), balance synchronization etc.
File update messages are optional at members discretion.
Euronet Worldwide
1-4
Transmission of Binary Data Elements

Depending on the character set, the Host-to-Host interface uses format specified in the following
table for the data elements defined as binary in ISO-8583 standard:
Format Data Element
EBCDIC
ASCII
Bitmaps
16 EBCDIC char
16 ASCII char
PIN Block
16 EBCDIC char
16 ASCII char
Example:
PIN block with value 4ABF12C3D567980E
Transfer mode: 16 EBCDIC characters
F4 C1 C2 C6 F1 F2 C3 F3 C4 F5 F6 F7 F9 F8 F0 C5
Transfer mode: 16 ASCII characters
34 41 42 46 31 32 43 33 44 35 36 37 39 38 30 45
Differences to ISO-8583: 1987 Standard

Some of the data elements used in the Host-to-Host Interface specification are defined differently
than in ISO-8583:1987 standard. The following table lists changed data elements:
Data Element
Description
Difference
DE-11
STAN
DE-41
Card Acceptor Terminal ID
DE-42
Card Acceptor ID
DE-43
Card Acceptor Location
DE-101
File Update code
Doesnt remain unchanged for all

messages throughout transaction life
cycle
No special characters allowed an8
used instead of ans8
No special characters allowed
an15 used instead of ans15
an40 used instead of ans40
an..17 used instead of ans..17
Euronet Worldwide
1-5
Message Definitions
General Message Structure
The message structure is based on ISO-8583 standard, as defined in the following table:
Message Element
Description
MTID
Message Type Identifier
Bitmap
Primary bitmap
Data
Concatenated data elements
Example:
General Message Structure flowchart
Message Types
The Host-to-Host interface supports the following message types (a subset of ISO-8583 message
set):
MTID
Significance
0100/0110
Authorization messages
0120/0121/0130
Authorization advice messages
0200/0210
Financial transaction messages
0220/0221/0230
Financial advice messages
0420/0421/0430
Reversal messages
0800/0810
Network Management messages
Euronet Worldwide
1-6
Bitmap
The bitmap consists of 64 bits numbered from the left starting with 1. The value of each bit
signifies presence (1) or absence (0) in the message of the data element associated with that
particular bit.
The first bit within a bitmap, when set to 1, denotes the presence of an additional contiguous 64bit bitmap.
Note: The bitmap is always transferred as 16 characters.
Example:
Bitmap for Reversal Request message (bits 2, 3, 4, 5, 7, 9, 11, 12, 13, 15, 22, 32, 37, 38, 39, 41,
42, 43, 49, and 50 are used)
Binary value:
0000000001111111111222222222233333333334444444445555555555666666
1234567890123456789012345678901234567890123456789012345678901234
0111101010111010000001000000000100001110111000001100000000000000
Hexadecimal value (8 bytes):
7A BA 04 01 0E E0 C0 00
Transferred as 16 EBCDIC characters (hexadecimal):
F7 C1 C2 C1 F0 F4 F0 F1 F0 C5 C5 F0 C3 F0 F0 F0
Transferred as 16 ASCII characters (hexadecimal):
37 41 42 41 30 34 30 31 30 45 45 30 43 30 30 30
Message Matching
Matching Response to Request
Use a combination of the following mandatory fields to match a response to the request message:
Cardholder Number (DE-2)

STAN (DE-11)
Local transaction date (DE-12)
Local transaction time (DE-13)
Euronet Worldwide
1-7
Match Follow-up Messages to the Original Message

A Follow-up Message is defined as any request message sent after, and related to, the original
request. For example, when the original request is an 0100 message, the follow-up message can
be a Reversal (0420/0421) or a Financial Transaction (0200 and/or 0220/0221).
Generally, the issuer participant should perform a matching process of follow-up messages
toward any previously received (related) messages. If a match occurs between the follow-up
message and a previously received message, internal action may need to be performed based on
the type of message received.
Use a combination of the following mandatory fields to match follow-up messages to the original
message:
Cardholder Number (DE-2)

Local transaction date (DE-12)
Local transaction time (DE-13)
Card Acceptor Terminal ID (DE-41)
Retrieval Reference Number (DE-37)
As an alternative, Original Data Elements (DE-90) may be used if they are present in the
message.
Issuer Processing
Issuer Message Processing
Issuer Message Processing consists of processing incoming requests and advices, generating
responses as required, and generating and processing network management and file update
requests and responses.
In summary, the issuer must implement:
Receiving and processing of following messages:

4 0800 Network Management request
4 0100 Authorization request
4 0120 Authorization advice
4 0121 Authorization advice, repeated
4 0200 Financial request
4 0220 Financial advice
4 0221 Financial advice, repeated
4 0420 Reversal request
4 0421 Reversal request, repeated
4 0810 Network Management response
Euronet Worldwide
1-8
Generating and sending of following messages:

4 0110 Authorization response
4 0130 Authorization advice response
4 0210 Financial response
4 0230 Financial advice response
4 0430 Reversal response
Taking necessary recovery actions
It is assumed that the issuer is capable of generating the appropriate Response Codes based on
issuer criteria such as validation of PIN, CVV, PVV, expiration date, card/account existence and
status, issuer limits, and account balances.
Acquirer Processing
Card Acceptance
The acquirer may decide whether it accepts a particular card brand at a particular touch-point
based or touch-point type and location, card brand, Primary Account Number (PAN), and service
code.
Acquirer Message Processing

Acquirer Message Processing consists of sending requests and advices and processing the
resulting responses, receiving network management requests and generating responses, and
generating network management requests and receiving the resulting responses.
In summary, the acquirer must implement:
Generating and sending of the following messages

4 0100 Authorization request
4 0120 Authorization advice
4 0121 Authorization advice, repeated
4 0200 Financial request
4 0220 Financial advice
4 0221 Financial advice, repeated
4 0420 Reversal request
4 0421 Reversal request, repeated
Euronet Worldwide
Receiving and processing of following messages

4 0110 Authorization response
4 0130 Authorization Advice response
4 0210 Financial response
4 0230 Financial Advice response
4 0430 Reversal response
4 0420 Reversal advice response
Taking necessary recovery actions
1-9
Message Flow
Network Management Messages
Logon (DE-70=1), Logoff (DE-70=2) and Echo (DE-70=301) network management messages
can be originated by either party, at any time. The message can be initiated by the operator, the
scheduled event, or as a part of recovery process.
The Cutover (DE-70=201) Network Management Message is initiated by the master participant
once per business day.
Note: Dynamic Key Exchange Messages are optional.
Euronet Worldwide
1-10
Normal Completion Logon, Logoff, and Echo Messages
Normal Completion (Logon, Logoff, And Echo) flowchart
Response Code 00 indicates Normal Completion. Upon receipt, the session becomes active and
other messages can be exchanged.
Normal Completion Cutover
Normal Completion (Cutover) flowchart
Response Code 00 indicates Normal Completion. Upon receipt of cutover message, the slave
participant should set its business date to the value received in DE-15 (new business date).
Euronet Worldwide
1-11
Exception Processing No Response
Exception Processing (No Response) flowchart
In case no response is received, the originator of the message will repeat request in regular
intervals (no other messages can be exchanged) until normal completion occurs. Session status
changes accordingly on the message originators side.
Euronet Worldwide
1-12
Exception Processing Message Declined
Exception Processing (Message Declined) flowchart
In case of declined network management message (DE-39 <> 00), the session will be terminated
and the session status will change accordingly on both sides. No messages can be exchanged
until next normal completion of logon message.
Authorization Messages
The Authorization Request (MTID = 0100) and corresponding follow-up requests (042x
Reversal Request, 0200 or 0220 Financial Transaction, and 012x Authorization Advice Request)
may be originated by either party, who will be called the acquirer. Although in most of the cases
the host will be the request originator (acquirer), for certain optional features, the member may
also originate request messages.
Euronet Worldwide
1-13
Authorization Normal Completion
Authorization Normal Completion flowchart
Upon receipt of 0100 request, the issuer will perform transaction validation and financial
authorization, set proper Response Code and approval number (where applicable), and send a
response back to the acquirer.
Upon receipt of the 0110 response, the acquirer will perform action as specified by Response
Code (DE-39).
Euronet Worldwide
1-14
Authorization Reversal Processing
Authorization Reversal Processing flowchart
The Reversal Request (0420 Message) will be initiated by the acquirer.

Upon receipt of the Reversal Request, the issuer will match it to previous messages and, based
on matching results, perform either a full or a partial reversal.
Euronet Worldwide
1-15
Authorization Reversal Timeout Processing
Authorization Reversal Timeout Processing flowchart
If a Reversal Timeout appears, the acquirer will create and repeat a 0421 Reversal Request in
regular intervals until number of repetitions reaches a predefined value* or the 0430 response is
received.
Upon receipt of the 042x request, the issuer will match this message to possible previous
messages and perform the appropriate action based on matching results.
Note: * Current number of repetitions is 5 (including first 0420).
Euronet Worldwide
1-16
Authorization Advice Normal Completion
Authorization Advice Normal Completion flowchart
Upon receipt of the 0120 request, the issuer will match this message to possible previous
messages and perform the appropriate action based on matching results and Response Code in
the 0120 message
Authorization Advice Timeout Processing
Authorization Advice Timeout Processing flowchart

Euronet Worldwide
1-17
If a timeout appears, the acquirer will create and repeat 0121 Authorization Advice Requests in
regular intervals until the number of repetitions reaches a predefined value* or the 0130
Response is received.
Upon receipt of the 012x Request, the issuer will match this message to possible previous
messages and perform the appropriate action based on matching results and the Response Code
in 012x message
Financial Transaction Messages

The Financial Transaction Request (MTID = 0200) and corresponding follow-up requests (042x
Reversal Request, 0220 Financial Transaction) may be originated by either party, who will be
called the acquirer. Although in most cases the host will be the originator (acquirer), for certain
optional features, the member may also originate request messages.
Financial Transaction Normal Completion
Financial Transaction Normal Completion flowchart
Upon receipt of a 0200 Request, the issuer will try to match it to possible previous messages,
perform Transaction Validation and Financial Authorization, set the proper Response Code and
Approval Number (where applicable), and send response back to the acquirer.
Upon receipt of the 0210 Response, the acquirer will perform the action as specified by
Response Code (DE-39).
Note: Matching is necessary since it is possible to have authorization message sent before
financial (usual in POS environment).
Euronet Worldwide
1-18
Financial Transaction Reversal Processing
Financial Transaction Reversal Processing flowchart
The Reversal Request (0420) Message will be initiated by the acquirer. It can be a full or a
partial reversal.
Upon receipt of the Reversal Request, the issuer will match it to possible previous messages and,
based on matching results, perform the appropriate action.
Euronet Worldwide
1-19
Financial Transaction Reversal Timeout Processing
Financial Transaction Reversal Processing flowchart
If Reversal Timeout appears, the acquirer will create and repeat a 0421 Reversal Request in
regular intervals until the number of repetitions reaches a predefined* value or the 0430
Euronet Worldwide
1-20
Financial Transaction Advice Normal Completion
Financial Transaction Advice Normal Completion flowchart
Upon receipt of the 0220 Request, the issuer will match this message to possible previous
in 0220 Message
Note: Matching is necessary since it is possible to have an Authorization and/or Reversal or
Financial Message sent before Financial Advice (usual in POS environment).
Euronet Worldwide
1-21
Financial Transaction Advice Timeout Processing
Financial Transaction Advice Timeout Processing flowchart
If a timeout appears, the acquirer will create and repeat a 0221 Authorization Advice Request in
regular intervals until the number of repetitions reaches a predefined* value or the 0230
in 022x Message
Reversal Messages
The Reversal Request (MTID = 042x) may be initiated by either party provided, that the party is
the acquirer. Although in most cases the host will be the originator (acquirer), for certain
optional features, the member may also originate request messages.
Euronet Worldwide
1-22
Reversal Normal Completion
Reversal Normal Completion Flowchart
The Reversal Request (0420 Message) will always be initiated by the acquirer. It can be a full or
a partial request.
Upon receipt of the Reversal Request, the issuer will match it to previous messages and, based
on matching results, perform the appropriate action.
Note: In case the original request (0100 or 0200) did not reach the issuer at all, a Stand
Alone Reversal will appear on the issuer side and should be ignored.
Euronet Worldwide
1-23
Reversal Timeout Processing
Reversal Timeout Processing flowchart
If a timeout appears, the acquirer will create and repeat a 0421 Reversal Request in regular
intervals until the number of repetitions reaches a predefined value* or the 0430 Response is
received.
Euronet Worldwide
1-24
Message Format
All message format definition tables use the symbols defined in the following table:
Message Types and Corresponding Data Elements
Symbol
Meaning
Mandatory.
M+
Mandatory, echoed from request.
Conditional.
C+
Conditional, echoed from request.
C*
Conditional, value may change.
Optional.
O+
Optional, echoed from request.
Reserved for future use.
Not used.
Network Management Messages

MTID
Data Element
0800
0810
Secondary bitmap
Transmission date/time
11
STAN
15
Date, settlement
C+
32
Acquirer institution ID
O+
39
Response code
48
Key Data (Optional Dynamic Key Exchange)
64
MAC Code (Optional MACing)
70
NMIC
128
MAC Code 2 (Optional MACing)
Euronet Worldwide
Authorization Messages
MTID
Data Element
0100
0110
0120
0130
Secondary bitmap
C+
C+
Processing code
M+
M+
Amount, transaction
M+
M+
Amount, settlement
M+
M+
Date/time, transmission
Fee, cardholder billing
C+
C+
11
Conversion rate,
settlement
STAN
M+
M+
12
Time, local transaction
13
Date, local transaction
14
Date, expiration
15
Date, settlement
C+
C+
18
Merchant type
22
POS entry mode
25
POS condition code
26
POS PIN capture code
32
M+
M+
35
Track 2 data
37
38
Retrieval reference
number
Authorization number
39
Response code
41
Card acceptor terminal ID
42
Card acceptor ID
43
M+
M+
50
Card acceptor
name/location
Currency code,
transaction
Currency code, settlement
C+
C+
52
PIN block
54
Additional amounts
64
MAC Code
102
Account 1 identification
103
120-123
Private use
C*
C*
128
MAC Code 2
49
Euronet Worldwide
1-25
1-26
Financial Messages
MTID
Data Element
0200
0210
0220
0230
Secondary bitmap
C-
C-
C+
C+
Processing code
M+
M+
Amount, transaction
M+
M+
Amount, settlement
C+
C+
C+
C+
11
Conversion rate,
settlement
STAN
M+
M+
12
M+
M+
13
M+
M+
14
Date, expiration
15
Date, settlement
C+
C+
18
Merchant type
22
POS entry mode
25
POS condition code
26
32
M+
M+
35
Track 2 data
37
M+
M+
38
Retrieval reference
number
39
Response code
41
42
Card acceptor ID
43
M+
M+
50
Card acceptor
name/location
Currency code,
transaction
C+
C+
52
PIN block
54
Additional amounts
64
MAC Code
102
103
120-123
Private Use
C*
C*
128
MAC Code 2
49
Euronet Worldwide
Reversal Messages
MTID
Data Element
0420
0430
Secondary bitmap
M+
Processing code
M+
Amount, transaction
M+
Amount, settlement
C+
Conversion rate, settlement
C+
11
STAN
M+
12
M+
13
M+
14
Date, expiration
15
Date, settlement
C+
22
POS entry mode
25
POS condition code
26
32
M+
35
Track 2 Data
37
Retrieval reference number
M+
38
C+
39
Response code
41
42
Card acceptor ID
43
Card acceptor name/location
49
Currency code, transaction
M+
50
C+
64
MAC Code
90
Original Data Elements
O+
95
Replacement Amounts
102
103
120-123
Private Use
C*
128
MAC Code 2
Euronet Worldwide
1-27
1-28
Data Element Definitions

Data element definitions use the following data elements types:
Data Element Types
Type
Significance
Alphabetical, A-Z, a-z.
Numeric, 0 - 9
Special characters
An
Alphabetic and numeric
As
Alphabetic and special
Ns
Numeric and special
ans
Alphabetic, numeric, and special
YY
Year
MM
Month
DD
Day
Hh
Hour
mm
Minute
Ss
Second
LLVAR
Indicates variable format, length as two digits.
LLVVAR
Indicates variable format, length as three digits.
<n>
Fixed length of <number> characters.
..<n>
Variable length up to maximum <number > characters.

Must be preceded by type, for example ans..28.
C = Credit
D = Debit
Must be associated to numeric amount element, for

example x + n16.
Binary (bit) representation.
Track data, as defined in ISO 7811 and ISO 7813.
Unless indicated otherwise, following rules apply:
All fixed length data elements of type n are assumed to be right justified with leading zeros.
All fixed length data elements of B type are assumed to be left justified with trailing zeros.
All other fixed length data elements are assumed to be left justified with trailing blanks.
All data elements are counted from left to right with leftmost position set as number 1.
Euronet Worldwide
Data Elements
Data elements are listed in ascending order as they appear in the bitmaps.
DE-1 Secondary Bitmap
Format
Type
Description
Field Edits
Constraints
b 64 - transferred as 16 bytes (EBCDIC or ASCII

characters).
Bitmap consists of 64 bits numbered from the left
starting with 1. The value of each bit signifies presence
(1) or absence (0) in the message of the data element
(DE-65 to DE-128) associated with that particular bit.
None.
C: Element is present only if message contains any of
data elements from range DE-65 to DE-128.
DE-2 Primary Account Number, PAN

Format
LLVAR
Type
n..19
Description
A series of digits used to identify customer account or

relationship. It is mandatory for all 04xx messages.
If present, it should be echoed in response and all
subsequent messages.
C: Element is present if DE-35 (Track 2) is not present.
Field Edits
Constraints
Euronet Worldwide
1-29
1-30
DE-3 Processing Code

Format
Type
n6
Description
A series of digits that describes the type of transaction and

the accounts affected by the transaction. It consists of
three, two-digit subfields:
Digit 1 and 2: Transaction Code:
00
Purchase of goods/services
01
Cash withdrawal
20
Credit, refund
21
Deposit
22
Credit adjustment
31
Balance inquiry
40
Transfer
90
Extended transaction type**
Digit 3 and 4: From Account Type*
00
Unspecified/unknown
10
Savings
20
Checking
30
Credit card
Digit 5 and 6: To Account Number*
00
Unspecified/unknown
10
Savings
20
Checking
30
Credit card
It is mandatory for all 01xx, 02xx, 04xx messages.
Field Edits
Notes: * Other values may be used for optional features.

**See the Optional Extended Transaction section
for more information.
When present, it should be echoed in response and all
Constraints
Euronet Worldwide
DE-4 Transaction Amount

Format
Type
n12
Description
The amount of funds requested (either for debit or

credit) in the currency of the source location of the
transaction. Number of decimal places is implied by the
Transaction Currency Code (DE-49). It is mandatory
for 01xx, 02xx, and 04xx messages.
For balance inquiry, amount should be 0. When present
it should be echoed in response and all subsequent
messages.
Field Edits
Constraints
DE-5 Settlement Amount

Format
Type
n12
Description
The amount of funds expressed in the settlement

currency (DE-50) by multiplying transaction amount
(DE-4) with settlement currency conversion rate (DE9).
When present, it should be echoed in response and all
C: The field is required when field DE-50 is present.
Field Edits
Constraints
DE-7 Transmission Date and Time

Format
Type
n10 (MMDDhhmmss)
Description
The time the message entered into the interchange

system. It is reset for each outgoing message and is
expressed in GMT. It is mandatory for all message
types.
Field Edits
Constraints
DE-8 Billing Fee Amount

Format
Type
n8
Description
The amount of online fee. The fee rules will be

identified later.
Field Edits
Constraints
R: Reserved for future use.
Euronet Worldwide
1-31
1-32
DE-9 Settlement Conversion Rate

Format
Type
n8
Description
The factor used to convert transaction amount (DE-4)

into settlement amount (DE-5). Transaction amount is
multiplied by settlement conversion rate to determine
settlement amount. This field is in format ABBBBBBB
where A denotes decimal position from the right and
BBB denotes conversion factor. For example,
40012345 denotes 1.2345.
When present it should be echoed in response and all
C: The field is required if DE-50 is present.
Field Edits
Constraints
DE-11 Systems Trace Audit Number

Format
Type
n6
Description
A unique number (within one business day) used for

matching response message to request message. It is not
intended to remain the same throughout the life of a
transaction (e.g. STANs in the reversal and/or
store/forward messages will differ mutually, and from
STAN of the original transaction). STAN is mandatory
for all messages.
STAN is set by a message sender and echoed by the
message receiver.
Field Edits
Constraints
DE-12 Local Transaction Time

Format
Type
n6 (hhmmss)
Description
The local time at which the transaction began at the card

acceptor location. The data element is mandatory for
01xx and 02xx messages.
Field Edits
Constraints
Euronet Worldwide
DE-13 Local Transaction Date

Format
Type
n4 (MMDD)
Description
The local date that the transaction began at the card

acceptor location. The data element is mandatory for
01xx and 02xx messages.
Field Edits
Constraints
DE-14 Expiration Date

Format
Type
n4 (YYMM)
Description
The year and month after which a card expires.
Field Edits
Constraints
C: Element is present if DE-35 (Track 2) is not present.
DE-15 Settlement Date

Format
Type
n4 (MMDD)
Description
The month and the day on which the parties will settle
the transaction.
If present, it should be echoed in response and all
C: Field is present if a) Field DE-50 is present or b)
MTID is 0800 and DE-70=201 (cutover message).
Field Edits
Constraints
Note: In case of cutover message, DE-15 represents new business date.
Euronet Worldwide
1-33
1-34
DE-18 Merchant Category Code (MCC)

Format
Type
n4
Description
MCC is four-digit code in accordance with the

Visa/MasterCard MCC definitions. The data element is
mandatory for 01xx and 02xx request messages. It is
never present in response messages.
Note: Most frequently used values are:
6011
ATM Cash withdrawal.
6010
Over the counter cash advance.
4814
Airtime purchase.
Field Edits
Constraints
DE-22 Point of Service Entry Mode

Format
Type
n3
Description
The code describing the way PAN (card number) and

PIN are entered at a touchpoint.
Data element consists of two sub-fields:
PAN Entry Mode
01
Manual.
02
Magnetic stripe read.
05
ICC.
90
Full and unaltered magnetic stripe read
(enables CVV validation).
PIN Entry Mode
0
Unspecified.
1
PIN entry capability.
2
No PIN entry capability.
6
PIN pad inoperative.
The data element is mandatory for 01xx, 02xx, and 04xx
request messages. It is never present in response
messages.
Field Edits
Constraints
Euronet Worldwide
DE-25 Point of Service Condition Code

Format
Type
n2
Description
Two-digit code indicating conditions at touchpoint:

00
01
02
03
05
07
08
52
59
Normal.
Customer not present.
Unattended terminal (CAT, ADM).
Merchant suspicious.
Customer present, card not present.
Telephone request.
MO/TO request.
mCommerce request.
eCommerce request.

request messages. It is never present in response
messages.
Field Edits
Constraints
DE-26 Point of Service PIN Capture Code

Format
Type
n2
Description
Two-digit code indicating the maximum number of PIN

characters accepted by the acquiring touchpoint used to
construct the PIN data.
Valid values:
04 - 12
Field Edits
Constraints
C: For pass-through acquiring connection, data element

is present in PIN based transaction requests i.e.
whenever DE-52 is present. For issuer connection, data
element is not used.
Euronet Worldwide
1-35
1-36
DE-32 Acquiring Institution Identification Code

Format
LLVAR
Type
n..11
Description
Identifies the acquiring institution for the transaction, or

its agent. The value will be defined by the host. The
data element is mandatory for 01xx, 02xx, and 04xx
request messages. It is optional for 08xx messages.
When present, it is set in request and echoed in response
and all subsequent messages.
O: Member can choose whether to use DE-32 in 08xx
messages or not.
Field Edits
Constraints
DE-35 Track 2 Data

Format
LLVAR
Type
z..37
Description
The information encoded on Track 2 of the magnetic

stripe of the plastic card (per ISO 7813) used for the
transaction, excluding start and end sentinel and LRC
characters.
Field Edits
Constraints
C: Track 2 Data is present for all 01xx, 02xx requests,

provided card was swiped at the touchpoint i.e. when
POS Entry Mode (DE-22 sub-field 1) = 90 or 02 and
Track 2 is used.
O: Track 2 Data is optional for 0420 Reversal Requests.
DE-37 Retrieval Reference Number

Format
Type
an12
Description
The reference, assigned by the acquirer, to identify a

transaction uniquely. It remains unchanged for all
messages throughout the life of a transaction and is used
for matching original message with reversal and/or
store/forward messages. The data element is mandatory
for 01xx, 02xx, and 04xx request messages.
It must be echoed in response message and all
Field Edits
Constraints
Euronet Worldwide
1-37
DE-38 Authorization Identification Response

Format
Type
an6
Description
The unique (within business day) response identification

value (also called approval or authorization code)
assigned by the authorizing institution.
C: For 0110 and 0210 response messages must be
present only if transaction is approved. For 0220 and
0420 request messages, it is present if available.
Constraints
DE-39 Response Code

Format
Type
an2
Description
This code indicates the disposition of a message as

detailed tables below.
Each code is associated with specific action code that is
to be taken:
A
Approve transaction.
D
Decline transaction.
C
Decline transaction and capture card.
Data element is mandatory in all response messages as
well as in reversal and store/forward request messages.
In reversal and store/forward requests, value identifies
the reason for reversal or store/forward message.
Field Edits
Constraints
The following Response Codes are supported for authorization and financial transaction response
(0110, 0210) messages as well as for store/forward request messages (0120/0121, 0220/0221):
0110, 0210, 0120/0121, 0220/0221 Response
Codes
Code
Description
Action
00
03
Approved or completed
successfully.
Invalid merchant.
04
Pick-up.
05
Do not honor.
06
Error.
07
Pick-up card special condition.
11
Approved (VIP).
12
Invalid transaction.
Euronet Worldwide
1-38
0110, 0210, 0120/0121, 0220/0221 Response

Codes
Code
Description
Action
13
Invalid amount.
14
15
Invalid card number (no such

number).
No such issuer.
17
Customer cancellation.
20
Invalid response.
21
No action taken.
22
Suspected malfunction.
30
Format error.
31
Bank not supported by switch.
33
Expired card, capture.
34
Suspected fraud, capture.
35
Card acceptor contact acquirer,

capture.
Restricted card, capture.
Card acceptor call acquirer

security, capture.
Allowable PIN tries exceeded,
capture.
No credit account.
36
37
38
39
C
D
D
41
Requested function not

supported.
Lost card, capture.
42
No universal account.
43
Stolen card, capture.
51
Not sufficient funds.
52
No checking account.
53
No savings account.
54
Expired card, decline.
55
Incorrect personal identification

number.
No card record.
40
56
57
58
59
60
61
62
Transaction not permitted to

cardholder.
Transaction not permitted to
terminal.
Suspected fraud, decline.
Card acceptor contact acquirer,
decline.
Exceeds withdrawal amount
limit.
Restricted card, decline.
Euronet Worldwide
D
D
D
D
D
D
D
1-39
0110, 0210, 0120/0121, 0220/0221 Response

Codes
Code
Description
Action
63
Security violation.
65
90
Exceeds withdrawal frequency

limit.
Card acceptor call acquirers
security department.
Hard capture (requires that card
be picked up at ATM).
Allowable number of PIN tries
exceeded, decline.
Cutoff is in process.
91
Issuer or switch is inoperative.
92
No routing available.
93
94
Transaction cannot be
completed. Violation of law.
Duplicate transmission.
95
Reconcile error.
96
System malfunction.
66
67
75
D
C
D
The following Response Codes are supported for store/forward response messages (0130/0230):
0130/0230 Response Codes
Code
Description
Action
00
successfully.
System malfunction.
96
Euronet Worldwide
1-40
The following Response Codes are supported for Reversal Request (042x) messages:
042x Response Codes
Code
Description
Action
00
17
successfully.
Customer cancellation.
20
Invalid response.
21
No action taken.
22
Suspected malfunction.
32
Completed partially.
68
Response received too late.
The following Response Codes are supported for reversal response messages (0430):
0430 Response Codes
Code
Description
Action
00
successfully.
System malfunction.
96
The following Response Codes are supported for network management response messages
(0810):
0810 Response Codes
Code
Description
Action
00
successfully.
System malfunction, recovery
action must be undertaken.
Other
DE-41 Card Acceptor Terminal Identification

Format
Type
an8
Description
A unique code identifying the terminal at the card

acceptor location. Special characters (including national
character support characters) are not allowed since some
networks and/or back-office systems may have
problems accepting these characters. The data element
is mandatory for 01xx, 02xx, and 04xx request
messages.
When present, it is echoed in response messages and all
Field Edits
Constraints
Euronet Worldwide
DE-42 Card Acceptor Identification Code

Format
Type
an15
Description
Identifies the card acceptor in a transaction if the card

acceptor is different from the acquiring institution.
Special characters (including national character support
characters) are not allowed since some networks or
back-office systems may have problems accepting these
characters. The data element is mandatory for 01xx,
02xx, and 04xx request messages.
Field Edits
Constraints
DE-43 Card Acceptor Name/Location

Format
Type
an40
Description
The name and location of the card acceptor, which

defines the point of service in both local and interchange
environments. Special characters (including national
character support characters) are not allowed since some
networks or back-office systems may have problems
accepting these characters. Data element consists of the
sub-fields detailed in the table below. The data element
is mandatory for 01xx, 02xx, and 04xx request
messages.
Field Edits
Constraints
Structure of DE-43
Position
Length
Field
Name
Description
01 - 22
22
Terminal owner
23 - 35
13
Terminal city
36 - 38
Terminal state
39 - 40
Terminal country
The name of the

institution.
The city in which the
transaction-originating
terminal is located.
A code indicating the
state or province in
which the transactionoriginating terminal is
located.
A code indicating the
country in which the
transaction-originating
terminal is located.
Euronet Worldwide
1-41
1-42
DE-48 Key Management Data Code

Format
LLLVAR
Type
ann..256
Description
Bit 48 transmits key information. Only one key will be

exchanged at a time. A single (16), double (32), or
triple length (48) key may be sent. Therefore, the check
digits may be located in positions 17-22, 33-38, or 4954.
This field is conditional for network management
messages. It is required for key exchanges.
Field Edits
C: Field is present if MTID is 0800 and DE-70 = Key
Exchange information code.
Constraints
Single Length Key

Position
Length
Field Name
01 - 16
an 16
Key Value 1
17 - 22
an 06
Check Digits
Double Length Key

Position
Length
Field Name
01 - 16
an 16
Key Value 1
17 - 32
an 16
Key Value 2
33 - 38
an 06
Check Digits
Triple Length Key

Position
Length
Field Name
01 - 16
an 16
Key Value 1
17 - 32
an 16
Key Value 2
33 - 48
an 16
Key Value 3
49 - 54
an 06
Check Digits
Euronet Worldwide
DE-49 Transaction Currency Code

Format
Type
Description
The three-digit code (ISO 4217) that identifies the

currency that applies to the Transaction Amount (DE-4).
messages.
Field Edits
Constraints
DE-50 Settlement Currency Code

Format
Type
Description
The three-digit code (ISO 4217) that identifies the

currency that applies to the Settlement Amount (DE-4).
If present in request (sent by master party), should be
echoed in response and all subsequent messages. If not
present in request (sent by slave party), should be set in
response (by master party) and echoed in all subsequent
messages.
C: This field is required in 01xx, 02xx, and 04xx
messages sent by the master party.
Field Edits
Constraints
DE-52 Personal Identification Number (PIN) Data

Format
Type
Description
64 - transferred as 16 bytes (EBCDIC or ASCII

characters).
The block of data containing encrypted PIN block.
Field Edits
Constraints
C: Data element is present for PIN based 01xx, 02xx

request messages i.e. when DE-22 sub-field 2 = 1.
DE-54 Additional Amounts

Format
LLVAR
Type
n..120
Description
The block of data carrying up to six balance sub-records

with which the issuer system responds. Structure of the
sub-record is detailed in the table below.
Field Edits
Constraints
C: Present in 01xx, 02xx responses whenever balance

information is needed.
Euronet Worldwide
1-43
1-44
Structure of DE-54
Position
Length
Field Name
01 - 02
n2
Account Type
03 - 04
n2
Amount Type
05 - 07
n3
Currency Code
08 - 20
x+n12
Amount Sign and Amount

D
C
Negative
Positive
DE-70 Network Management Information Code

Format
Type
Description
A code identifying the purpose of a network

management request message. The NMIC is mandatory
for 0800 and 0810 Messages.
Should be echoed in responses.
Field Edits
Constraints
The following table for a list of supported Network Management Informational Codes:
Network Management Informational Codes
Code
Description
001
Logon
002
Logoff
201
Cutover
301
Echo-test
The following codes are only for Dynamic Key Management Messages:
Dynamic Key Management Message Codes
Code
Description
160
Request new Acquirer key.
161
Request new Issuer key.
162
Request new Acquirer MAC key.
163
Request new Issuer MAC Key.
164
Request new PEK. Single key used for both

acquirer and Issuer.
Request new MAC key. Single key used for
both acquirer and Issuer.
165
Euronet Worldwide
Dynamic Key Management Message Codes

Code
Description
166
Request all keys.
180
Acquirer key exchange.
181
Issuer key exchange.
182
MAC Acquirer key exchange.
183
MAC Issuer key exchange.
184
PEK key exchange.
185
MAC key exchange.
DE-90 Original Data Elements

Format
Type
42
Description
This data element contains parts of the original message

being reversed or adjusted and is used to match
reversal/adjustment to previous authorization or financial
transaction message(s). The data element consists of the
sub-elements detailed in table below.
Field Edits
O: Member may choose if this data element will be used.
Constraints
Structure of DE-90
Position
Length
Field
Name
Description
01 - 04
Original MTID
05 - 10
Original STAN
11 - 14
15 - 20
21 - 31
11
32 - 42
11
Original Local
Transaction Date
Original Local
Transaction Time
Original Acquiring
Institution ID
Original
Forwarding
Institution ID
MTID of the original

transaction.
DE-11 of the original
transaction.
transaction, MMDD.
transaction, HHMMSS.
transaction.
All zeros (DE-33 not
used).
Euronet Worldwide
1-45
1-46
DE-95 Replacement Amounts

Format
Type
an42
Description
New actual transaction amounts. This field consists of

the elements detailed in the table below.
Field Edits
C: Present in partial reversal (0400 and 0420) and
store/forward (0120 and 0220) messages, where actual
transaction amount is not equal to originally authorized
amount and not equal to zero.
Constraints
Structure of DE-95
Position
Length
Sub-field
Name
Description
01 - 12
12
13 - 24
12
25 - 25
Actual Transaction
Amount
Actual Settlement
Amount
Actual Transaction
Fee Sign
C
D
Credit
Debit
26 - 33
34 - 34
Actual Transaction
Fee Amount
Actual Settlement
Fee Sign
C
D
Credit
Debit
35 - 42
Actual Settlement
Fee Amount
DE-102 Account Identification 1

Format
LLVAR
Type
ans..28
Description
A series of digits used to identify a customer account. It

denotes the from account number involved in the
transaction (e.g. the debit account in a withdrawal or
transfer transaction or the account being inquired upon
in a balance inquiry transaction). The account number
in the Account Identification 1 field must be right
justified with leading zeros.
Usage:
In request messages, to transfer customer selected
account number (OAR functionality) to transfer
customer selected payee (Bill Payment).
Field Edits
Constraints
In responses, to identify account number that will be

affected by requested transaction
If present, should be echoed in all subsequent messages.
C: The data element is used in 01xx, 02xx, and 04xx
messages, whenever account information must be
transferred.
Euronet Worldwide
DE-103 Account Identification 2

Format
LLVAR
Type
ans..28
Description
A series of digits used to identify a customer account. It

denotes the to account number involved in the
transaction (e.g. the credit account in deposit or transfer
transaction. The account number in the Account
Identification 1 field must be right justified with leading
zeros.
Usage:
In request messages, to transfer customer selected
account number (OAR functionality) to transfer
customer selected payee (Bill Payment).
Field Edits
Constraints
In response, to identify account number that will be

affected by requested transaction.
If present, should be echoed in all subsequent messages.
C: The data element is used in 01xx, 02xx, and 04xx
messages, whenever account information must be
transferred.
DE-120 - DE-127 Reserved for Private Use

Format
LLLVAR
Type
ans..999
Description
These fields are Tag-based.
Field Edits
The contents of field may change in responses

depending on result of transaction.
C: Optional Use.
Constraints
Euronet Worldwide
1-47
1-48
Communications Requirements
The Host-to-Host interface presents the application level protocol designed to run over following
transport mechanisms (as described in following sections)
TCP/IP
X.25
TCP/IP Connection
This type of connection will use stream sockets. Socket connection is permanent and can be
initiated from one of the parties (as agreed between the host and member during project
implementation). The messages will be passed in eight-bit characters, unencrypted. Each
message will be preceded with a two-byte header (high-byte first) denoting length of the message
excluding header, as per example below (86 is hexadecimal 0x0056):
<high-byte><low-byte><message>
<0x00><0x56><86 bytes of message>
Actual communication parameters (IP address, TCP port) will be mutually agreed upon during
project implementation.
TCP/IP is the preferred communication protocol.
Notes:
Encryption may be used on communication level (where routers support it).
Firewall protection should be used.
X.25 Connection
This type of connection will use Switched Virtual Circuit (SVC) initiated by one of parties (as
agreed between the host and member during project implementation). The messages will be
passed in eight-byte characters, unencrypted. Actual communication parameters (X.25 address,
window and packet size, user data, etc.) will be mutually agreed upon during project
implementation.
Note: Encryption may be used on communication level (where routers support it)
Euronet Worldwide
1-49
Security Requirements
Security Zones and Key Management
Acquirer and Issuer security zones are always defined as in the Security Zones example below.
The Acquirer Working Key (AWK) is the key used to encrypt PIN block in requests originated
by member and sent to the host. The Issuer Working Key (IWK) is the key used to encrypt PIN
block in requests originated by the host and sent to member.
Security Zones flowchart
IWK and AWK are exchanged between parties encrypted under Zone Master Key (ZMK).
Currently, single DES or triple DES may be used. ZMK will be exchanged between participants
in three clear text components. The working key exchange process may be static or dynamic.
Both parties need to agree on the encryption method used.
If same logical connection (i.e. one TCP/IP socket or one X.25 SVC) is used for both acquirer
and issuer traffic, AWK and IWK will have the same value and should be regarded simply as a
Working Key (WK).
Euronet Worldwide
1-50
PIN Block Encryption

The PIN block is encrypted using an acquirer or issuer working key. The Host-to-Host interface
supports only ISO-0 PIN block format (also called ANSI) as described below:
Before encryption, PIN block is formed by XOR-combining original PIN block with the mask
consisting of least significant digits of the PAN excluding check digit.
C L P P P P PF PF PF PF PF PF PF PF F F
XOR 0 0 0 0 A A A A A A A A A A A A
C L P P X X X X X X X X
X X X X
C
L
P
F
PF
A
Control filed (value 0, hexadecimal value 0x0).

PIN length field (4 - 12, hexadecimal value 0x4 - 0xC).
PIN digit (0 - 9, hexadecimal value 0x0 - 0x9).
Filler digit (hexadecimal value 0xF).
PIN or filler digit, depending on PIN length.
12 least significant PAN digits (check digit excluded). If PAN is less than 12
digits, it must be right justified with leading zeros.
Result of XOR operation.
Certification Requirements
Each participant connecting to a Host-to-Host interface is required to perform certification prior
to going into live production. Certification is performed on a members and a hosts test systems
by sending online messages.
Certification requirements are described in detail in the Chapter Four: Steps of Certification for
Host-to-Host in this document.
Euronet Worldwide
1-51
Section 2: Optional Extended

Transaction Support
Introduction
Important: This section is intended for use in addition to the basic transaction
specifications in order to support optional extended transactions.
Some features may require additional modifications to the host system to function correctly.
The following section contains specifications of data elements for use in support of optional
extended transactions not supported by the ISO-8583 standard and the modifications required for
ISO-8583-based connections to support the following transactions:
List Account Open Account Relationship (OAR)

Mini-statements
PIN Change
GSM Recharge
Bill Payment
Service Request
This is supporting information for use in conjunction with documentation defining the actual
version of the ISO-8583 message protocol. The definitions outlined within this section are
applicable to any version of the ISO-8583 protocol, although it is recommended that the Euronet
Worldwide Host-to-Host definitions be used as the base for the implementation of the
transactions.
Note: It is assumed that the reader has a good understanding of the ISO-8583 message
protocol.
Euronet Worldwide
1-52
General Message Definitions

Message Types
In accordance with the ISO message standard, the following definitions are applied:
0100/0110
0200/0210
0400/0410
Financial Authorization/Financial Authorization Response.

Financial Transaction/Financial Transaction Response.
Reversal Request/Reversal Request Response.
This manual assumes that the 0200/0210 messages are the base for carrying the data to be passed
between systems. The use of 0100/0110 messages instead of 0200/0210 messages can also be
supported within the same scope and definition. This document also assumes that 0400/0410
messages are used for reversal processing. Message types 0420/0430 can also serve the same
purpose within the same scope and definition.
The following table outlines the message type to be used for each transaction type and whether
reversal transaction processing is supported:
Transaction Type
Message
Reversal Supported
List Account Open Account

Relationship (OAR)
Mini-statements
0200/0210
No
0200/0210
No
PIN Change
0200/0210
Yes
GSM Recharge
0200/0210
Yes
Bill Payment
0200/0210
Yes
Service Request
0200/0210
No
Request Messages
Request messages are generally initiated by the transaction acquirer (0100, 0200, 0400, and
0420). These messages follow the general specifications of the ISO-8583 definitions in
accordance with the specific version of the protocol in use. This section defines the format and
location of extended data to be included in these messages to support transactions outside of the
scope of the ISO-8583 standard. Additionally, the section outlines the relationship with standard
ISO-8583 data fields (such as field 3, processing code) and the extended data.
Euronet Worldwide
1-53
Response Messages
Response messages (0110, 0210, 0410, and 0430) follow the general specifications of the ISO8583 definitions in accordance with the specific version of the protocol in use. This section
defines the format and location of extended data to be included in these messages to support
transactions outside of the scope of the ISO-8583 standard. Additionally, the section outlines the
relationship with standard ISO-8583 data fields (such as field 3, processing code) and the
extended data.
Extended Data Support

ISO Data Fields
The ISO-8583 standard defines fields 120 through 123 as Reserved for private use. These
fields carry information required for the support of the optional extended transaction set. In
accordance with the ISO-8583 standard, the maximum size of each of these fields is 999 bytes.
In cases where the information to be passed between systems exceeds 999 bytes, more than one
field will carry the information.
In general, fields 120 through 123 are used in the following sequence:
120
121
122
123
Primary.
Additional information, if required.
This allows the systems to pass a maximum of 7.992 bytes of additional data. Individual
implementations of the optional extended transaction specifications may use, at their discretion
and requirements, any of the eight data fields as the primary field and subsequent fields for
additional information.
For example, if an implementation requires one of the above fields for other purposes, the next
available field becomes the primary field. This means that if field 120 is required for other
purposes, field 121 becomes the primary field for carrying the extended information.
In addition to fields 120 through 123, field 3 of the ISO-8583 specifications (processing code)
identifies optional extended transactions.
Euronet Worldwide
1-54
Data Format
Field 3: Processing Code
The optional extended transaction support uses the first two digits of the processing code to
identify that an optional extended transaction is in progress. A value of 90 is placed in this
position to indicate an optional extended transaction. A tag, as defined in the following section,
further identifies the actual type of the transaction being executed.
Fields 120 - 123: Extended Data

Fields 120 through 123 carry extended data required for the processing of a transaction. The
contents of these fields are tag-based to identify individual elements within the data field.
The tag-based processing is formatted using the tag-length-data encoding procedure. The
following is an explanation of the tab-based specification:
Field
Size
Description
<TAG>
3 bytes
<LLL>
3 digits
<data>
Variable
A predefined tag identifying the type

of data to follow. For a list of defined
tags, see the Tag Definitions table for
more information.
This field indicates the length of the
following data specific to the
preceding tag value.
A variable length field containing the
data specific to the preceding tag.
The actual length of the data is
defined by field <LLL>
For example, 001002MV would indicate the following:
001
002
MV
Type of transaction definition to follow.

Length of two bytes of data to follow.
GSM Mobile Recharge Voucher transaction.
As all tag definitions follow the same format, an application can choose to ignore unknown tags
and continue processing with the ability to extract any remaining tags from the data element
contents.
Euronet Worldwide
The following table lists the currently defined tags:

Tag Definitions
Tag
Data
Length
Data
Type
Description
001
an
Transaction type identifier.
002
an
Valid values:
AL
Account List.
07
Mini-statement.
08
PIN Change.
AR
Registration for Mobile Recharge.
IV
Mobile Voucher GSM Recharge.
MR
Online GSM Recharge.
CR
POS Recharge by Cash.
PR
POS Recharge by Card.
VC
POS Voucher by Cash.
VP
POS Voucher by Card.
BL
Bill Payment Defined Bill Payment
Relationships.
BB
Bill Payment Detailed Biller
Information.
BP
Bill Payment.
PA
Registration for Mobile Bill Payment.
11
Service Request.
AV
Account Verification.
Product indicator identifying product originating
the transaction.
Valid values:
ATM
ATM Device.
POS
POS Device.
TLF
IVR System.
WEB
Internet-based Application.
MOB
Mobile Phone.
HST
Host System.
xxx
Other acquiring systems.
Euronet Worldwide
1-55
1-56
Tag Definitions
Tag
Data
Length
Data
Type
Description
003
v..196
ans
List of accounts (in response to OAR request).

The structure is as follows:
001 - 002
003 - 004
005 - xxx
Number of debit accounts,

values 00 04.
Number of credit accounts,
values 00 004.
Variable size block with debit
and credit account definitions.
Account definition is 24-characters long. Debit

accounts have to be placed in the beginning of the
variable block. Number of debit account
definitions has to be equal to the number of debit
accounts in position 01 - 02 of Tag 3 specification.
Credit account definitions have to follow debit
account definitions in the variable block.
Number of credit account definitions has to be
equal to the number of debit accounts in position
03 - 04 of Tag 3 specification. Structure of one
account definition is defined as:
01 - 19
004
16
ans
005
an
Account number (left justified,

ans19).
20 - 21
Account Type (as per ISO8583:1987, an2).
22 - 24
Account currency code,
numeric (as per ISO 4217,
ans3).
Bin New PIN value encrypted (PIN change
request).
Number of lines for mini-statement sent from
issuer. At present time, a maximum of 10 lines is
supported. Any statement lines beyond 10 will be
ignored.
Euronet Worldwide
Tag Definitions
Tag
Data
Length
Data
Type
Description
006
v..460
ans
Mini-statement data. Each data line is 46

characters and will be preformatted in accordance
with the following layout:
001 - 006
007 - 026
027 - 034
035 - 035
036 - 046
007
12
an
008
12
an
009
15
Char
010
16
ans
011
10
Char
012
12
ans
013
an
014
v..525
Char
015
v..315
Char
Date (YYMMDD).
Description (ans20).
Amount (ans20).
Sign (+/-) (ans1).
Transaction
Reference Number
(an7).
A maximum of 10 data lines is currently supported

(total data length 460). The total data length of
this field is always a multiple of 46. Any data
exceeding the total length of 460 will be ignored
and any truncated data (i.e. not multiple of 46) will
be ignored.
Starting balance. This can indicate a balance prior
to a transaction or a starting balance in conjunction
with mini-statement data.
Ending balance. This can indicate a balance after a
transaction or an ending balance in conjunction
with mini-statement data.
Registered payment card alias name.
Mobile voucher number, encrypted, for mobile
voucher GSM Recharge Transaction.
Key identifier for key used to encrypt mobile
voucher number.
Mobile voucher serial number.
Expiration date of mobile voucher in format
yyyymmdd.
Bill Payment relationship identification codes.
This field can contain up a maximum of 35 entries,
15 characters each (total 525 characters). Any
entries beyond this will be ignored by the system.
Bill Payment presentment amounts. If a registered
vendor relationship supports amount presentments,
the corresponding entry in this element in relation
to data based on TAG 014 will contain the
presentment amount. This field can contain up to
35 entries, nine characters each (total 315
characters). The number of entries is the same as
in the data for TAG 014. Any entries beyond 35
will be ignored by the system.
Euronet Worldwide
1-57
1-58
Tag Definitions
Tag
Data
Length
Data
Type
Description
016
v..175
Char
017
v..35
Char
018
v..105
Char
019
15
Char
020
Char
021
ans
Bill Payment prompt codes. The Bill Paymentprocessing engine supports variable text prompting
at the touch-point. In this tag element, the system
can pass unique code identifiers for each prompt
type. Each entry in this list corresponds to an entry
in the data presented for TAG 014. This field can
contain up to 35 entries, five characters each (total
175 characters). The number of entries is the same
as for TAG 014. A blank entry indicates that no
prompt is to be provided. Any entries beyond 35
will be ignored by the system.
Bill Payment vendor types. The Bill Payment
system uses a special code to identify types of
vendors. This field can contain up to 35 entries,
one character each (total 35 characters). The
number of entries is the same as the number of
entries for the TAG 014 data element. Any entries
beyond 35 will be ignored by the system.
Bill Payment relationship owner. The Bill
Payment system supports the sharing of vendor
relationships between participants. Individual
entries in this data element identify the owner of
each presented relationship. This field can contain
up to 35 entries, three character each (total 105
characters). The number of entries is the same as
the number of entries for the TAG 014 data
element. Any entries beyond 35 will be ignored by
the system.
Bill Payment relationship ID code. This data
element contains a selected Bill Payment
relationship ID code for the actual Bill Payment.
The value of this data element has to be known
within the Bill Payment engine and can be one of
the elements from data presented based on TAG
014.
Bill Payment relationship owner. This field
contains the relationship owner for a selected Bill
Payment transaction. The combination of the
relationship owner and the relationship ID (Tag
019) must be known within the Bill Payment
engine.
Type of service request. This tag will be populated
when the value of TAG 001 is SR. Currently the
following service requests are supported:
022
Num
023
Num
CB
Check book request.
ST
Statement request.
AV
Account verification.
Start date for period (for example, statement
request) in the format yyyymmdd.
End Date for period (for example, statement
request) in the format yyyymmdd.
Euronet Worldwide
Tag Definitions
Tag
Data
Length
Data
Type
Description
024
16
ans
025
ans
Telephone number (for example, for online GSM

Recharge).
Mobile phone operator ID.
026
v..400
Char
027
Char
Message data. Variable message data with a fixed

length of 80 bytes for each line of the message.
This data element allows for a maximum of five
message lines (maximum size 400). Any entries
beyond five will be ignored by the system.
Bill Payment relationship details. This data
element contains the following information:
001 - 015
016 - 034
035 - 037
038 - 052
053 - 057
058 - 060
061 - 080
081 - 105
106 - 135
136 - 143
144 - 148
149 - 151
152 - 156
157 - 161
162 - 166
167 - 171
172 - 176
177 - 226
227 - 266
267 - 316
317 - 366
367 - 396
397 - 426
427 - 456
457 - 486
Client ID.
User ID.
Client Country Code.
Relationship ID.
Bill presentment Amount.
Bill Presentment Amount
Currency Code.
Bill Reference Number.
Account at Vendor.
Service Description.
Due Date, format yyyymmdd.
Prompt Code.
Relationship Owner.
Phrase Code 1.
Phrase Code 2.
Phrase Code 3.
Phrase Code 4.
Phrase Code 5.
Vendor Name.
Vendor Account #.
Vendor Address 1.
Vendor Address 2.
Note 1.
Note 2.
Note 3.
Note 4.
* Note: Selected fields may be blank dependant on

the availability of the information.
Euronet Worldwide
1-59
1-60
Tag Definitions
Tag
Data
Length
Data
Type
Description
028
Char
Encryption descriptor.
001 - 003
029
ans
030
ans
090
Char
Applicable tag identifier for

tag data encryption.
004 - 004
Encryption method used:
0 = Encryption is not used.
1 = Single DES.
3 = Triple DES.
R = RSA.
005 - 005
Padding character used during
encryption process.
Account qualifiers (to and from account qualifiers,
each an2).
Mini-statement currency code.
Continuation indicator. A value of plus sign (+) in
this data element indicates that further data is
present in the message and the receiving system
should process the next data field for the additional
data.
Reserved for future use.
Note: Length indication of v..100 indicates a variable length with a maximum size of 100
bytes.
Note: Data types are the following:

Char Any character value.
Num Numerical value.
Euronet Worldwide
The following table defines the usage of tags by transaction type:

Tag Usage by Transaction Type
Transaction Type
Request (Tag
#/Usage*)
Response (Tag
#/Usage*)
List Account Open Account

Relationship (OAR)
001 M
002 M
Mini-statement
001 M
002 M
PIN Change
001
002
004
001
002
024
025
001
002
003
001
002
005
006
007
008
030
001
002
M
M
M
M
M
M
M
O
O
M
M
M
001
002
024
025
026
001
002
010
011
012
013
025
026
028
001
002
024
025
026
028
001
002
024
025
001
002
009
M
M
O
O
O
M
M
M
O
M
M
M
O
M
M
M
O
O
O
O
M
M
O
O
M
M
M
GSM Recharge Registration for

Mobile Recharge
M
M
M
M
M
M
C
GSM Recharge Voucher
001 M
002 M
025 M
GSM Recharge Online
001
002
024
025
028
M
M
M
M
O
GSM Recharge Account

Verification
001
002
024
025
001
002
024
M
M
O
O
M
M
M
Bill Payment Registration for

Mobile Bill Payment
Euronet Worldwide
1-61
1-62
Tag Usage by Transaction Type

Transaction Type
Request (Tag
#/Usage*)
Response (Tag
#/Usage*)
Bill Payment Request

Relationship List
001 M
002 M
Bill Payment Request

Relationship Details
001
002
019
020
M
M
M
M
Bill Payment Request Bill

Payment
001
002
019
020
001
002
021
022
023
024
001
002
012
024
025
M
M
M
M
M
M
M
O
O
C
M
M
O
O
O
001
002
014
015
016
017
018
090
001
002
019
020
027
001
002
Service Request
Financial Authorization Related to

Extended Transaction
Note:
M
O
C
M
M
M
M
M
M
M
C
M
M
M
M
M
M
M
001 M
002 M
001
002
012
024
025
M
M
O
O
O
The following is a list of usage codes for the previous table:

Mandatory
Optional
Conditional
Euronet Worldwide
1-63
Message Flow by Transaction Type

List Account Open Account Relationship (OAR)
The List Account Open Account Relationship (OAR) transaction type presents a customer at a
touch-point with a list of accounts valid for a selected transaction type, such as a withdrawal,
transfer, deposit, or inquiry. This transaction type is referred to as a Dual-pass Transaction. A
Dual-pass Transaction is the process in which a customer selects a transaction type at the touchpoint and the device sends a request to the host system to present a list of valid accounts against
which to perform the transaction. The typical message flow is the following:
From -> To
Description
Touch-point -> Device Management
Device sends request indicating an OAR transaction.
Device Management -> Issuer System
Request for account list (0200):

P3
90xxxx
P120
Tag-based request information.
Account list response (0210):
P3
90xxxx
P120
Tag-based response data (account list).
Account list for selection.
Issuer System -> Device Management
Device Management -> Touch-point
Note: Device management may be the processing center and/or another host system.
Note: The processing center may act as a gateway between the device management
system and the actual issuer system.
Euronet Worldwide
1-64
OAR Data Flow
Acquirer OAR Accounts Returned
Acquirer OAR: Accounts Returned flowchart
Euronet Worldwide
Acquirer 0 Accounts Returned
Acquirer 0 Accounts Returned
Euronet Worldwide
1-65
1-66
Acquirer 1 Account Returned
Acquirer 1 Account Returned
Euronet Worldwide
Acquirer OARDS Not Received
Acquirer OARDS Not Received
Euronet Worldwide
1-67
1-68
Goldnet
Figure 1 Goldnet
Mini-statement
A mini-statement is a list of the last 10 transactions performed on a selected account. This
request may be based on a card number or potentially an account number, as a result of an OAR
transaction. The mini-statement is intended to be printed on a typical ATM device receipt printer
and is limited in the size and amount of information presented. The typical message flow for a
mini-statement is the following:
From -> To
Description
Device sends request indicating a mini-statement

transaction.
Request for mini-statement data (0200):
P3
90xxxx
P120
Mini-statement data response (0210):
P3
90xxxx
P120
Tag-based response data (mini-statement data).
Mini-statement data for printing.
Euronet Worldwide
1-69
PIN Change
A PIN change transaction allows a cardholder to request a new PIN. This message contains the
current PIN and the new selected PIN value. The transaction flow for a PIN change transaction
is the following:
From -> To
Description
Device sends request indicating a PIN change

transaction.
Request for PIN change (0200):
P3
90xxxx
P120
PIN change response (0210):
P3
90xxxx
P39
Result of PIN change request.
Result of PIN change request.
Euronet Worldwide
1-70
GSM Recharge
The GSM Recharge Transaction is a type of transaction that allows a customer with a pre-paid
mobile phone to purchase additional airtime for their phone account through various electronic
touch-points. The Euronet Worldwide system supports the following basic types of these
recharge transactions:
Voucher-based
Online-based
Registration for Mobile Recharge
The voucher-based transaction produces a printed voucher with a unique code on the printed
receipt. The customer then dials in to a predefined service number on a mobile phone and enters
the printed voucher number, which generates a credit to the phone account.
The online-based transaction allows the customers account to credit in a real-time environment
as the transaction is processed. To achieve this, the phone number (account number) to credit
must be present in the request message.
GSM Recharge, Touch-points

The Euronet Worldwide system supports various touch-points for the GSM Recharge
Transactions. Due to their nature, certain touch-point points only support an online recharge.
Apart from that, the processing of the recharge transactions within the Euronet Worldwide
environment will be close to identical, depending on the touch-point point used.
GSM Recharge, Voucher-based

The voucher-based recharge transaction uses the following transaction flow:
From > To
Description
Processing Center -> Issuer System
Device sends request indicating a voucher-based

recharge transaction.
Request for Voucher (0200):
P3
90xxxx
P120
Validate that voucher is available in requested
denomination.
Request for financial authorization.
Issuer System -> Processing Center
Response to authorization request.
Processing Center -> Mobile Operator
If financial authorization is granted, indicate to mobile

operator that voucher will be dispensed.
Device Management -> Processing Center
Processing Center-> Mobile Operator
Euronet Worldwide
From > To
Description
Processing Center -> Device Management
Voucher recharge response (0210):

P3
90xxxx
P120
Tag-based data with voucher number, if
approved.
Result of voucher request and printout of voucher
number if approved.
1-71
Note: Device management may be the processing center and/or another host system
Note: Although in the above scenario, the processing center functions as a central point for
voucher retrieval and financial authorization, financial authorization may also be handled by
the device management system independent of the voucher retrieval process.
GSM Recharge, Online-based

The online-based recharge transaction uses the following transaction flow:
From -> To
Description
Device sends request indicating an on line-based

recharge transaction.
Request for Online Recharge (0200):
P3
90xxxx
P120
Validate that phone number is valid for recharge and that
requested amount is available.
If financial authorization is granted, request credit to

phone account.
On line recharge response (0210):
P3
90xxxx
P120
Tag-based data with phone number, if
approved.
Result of recharge request.
Processing Center >Device Management
Euronet Worldwide
1-72
phone account crediting and financial authorization, financial authorization may also be
handled by the device management system independent of the phone account credit
process.
Mobile Recharge Registration

The Mobile Recharge Registration transaction uses the following transaction flow:
From -> To
Description
Processing Center
Device sends request indicating a Mobile Recharge

Registration transaction.
Request for Mobile Recharge Registration (0200):
P3
90xxxx
P120
Validate that phone number if it is valid for recharge.
Request for Card (Account) Verification.
Response to Card (Account) Verification request.
Processing Center
If financial authorization is granted, register user in the

database.
Mobile Recharge Registration response (0210):
P3
90xxxx
P39
Result of recharge registration.
Result of Mobile Recharge Registration request.
phone registration and financial authorization, financial authorization may also be handled
by the device management system independent of the phone registration process.
Note: Card (Account) Verification is described as separate section.
Euronet Worldwide
1-73
Account Verification
Typically, an Account Verification request is sent from the processing center to the card issuer as
a part of some other flow, such as Bill Payment or Mobile Recharge Registration, and uses the
following transaction flow:
From -> To
Description
Request for Account Verification (0200):

P3
90xxxx
P120
Response to authorization request (0210):
P3
90xxxx
P120
Tag-based response information.
Bill Payment
Bill Payment is a service that allows customers to access billing information and initiate
payments of bills through a variety of touch-points. This service supports private billing lists as
well as public billing lists. Additionally, the service supports bill amount presentment. The Bill
Payment message flow normally consists of separate steps in the transaction process:
Request list of defined Bill Payment relationships.

Request details of a selected relationship.
Request payment of a selected bill or relationship.
Registration for mobile Bill Payment.
The optional extended transaction set definition provides support for all of the above listed steps.
Bill Payment, Touch-points

Bill Payment can be performed at a variety of touch-points. Certain limitations may apply to
individual touch-points, such as number of selections presented to the consumer. In general, the
internal processing of Bill Payment transactions is identical, regardless of the touch-point used.
Request List of Defined Bill Payment Relationships
For a standard Bill Payment transaction, the first step is normally a request for a list of defined
relationships, or a list of what bills can be paid. This, however, is not always required; in certain
situations, the customer can initiate the Bill Payment directly without being first presented with a
list of defined payment relationships. If a list of available payment relationships is to be
presented, the transaction flow is the following:
Euronet Worldwide
1-74
From -> To
Description
Device sends request for a list of defined Bill Payment

relationships
Request for list of payment relationships (0200):
P3
90xxxx
P120
Bill Payment relationship list response (0210):
P3
90xxxx
P120/P121
Bill Payment relationship list.
Bill Payment relationship list for selection.
Request Relationship Details

Once a specific Bill Payment relationship is identified or selected, it may be necessary to retrieve
further details about this relationship (for example, vendor details). This is accomplished
through the following transaction flow:
From -> To
Description
Device sends request for details about a specific Bill

Payment relationship.
Request for details on payment relationship (0200):
P3
90xxxx
P120
Bill Payment relationship details response (0210):
P3
90xxxx
P120
Bill Payment relationship details.
Bill Payment relationship details.
Euronet Worldwide
1-75
Pay Bill
Once a Bill Payment relationship is identified for payment and, if required, additional
information regarding the relationship is retrieved, the actual Bill Payment can take place. This
is based on the following transaction flow:
From -> To
Description
Device sends request for Bill Payment of a specific

payment relationship.
Request for Bill Payment (0200):
P3
90xxxx
P120
Validate that payment relationship is known and valid for
customer.
Processing Center -> *internal
If financial authorization is granted, mark bill as paid for

settlement and reconciliation.
Bill Payment response (0210):
P3
90xxxx
P39
Result of Bill Payment.
Result of Bill Payment.
Bill Payment processing and financial authorization, financial authorization may also be
handled by the device management system independent of the Bill Payment or
reconciliation process.
Service Request
The processing center can support the capture and processing of service requests. These requests
are normally offline-based requests that require manual intervention or reaction from the service
provider. To support this, the system facilitates the capture of these request messages and the
forwarding of the requests to the appropriate service provider. There messages uses the
following message flow:
Euronet Worldwide
1-76
From -> To
Description
Device sends service request, including details on

requested service.
Request for service (0200):
P3
90xxxx
P120
Store service request for batch-based transmission to
service provider.
Service request response (0210):
P3
90xxxx
P39
Result of service request.
Result of service request.

Note: Although the above transaction flow depicts the service requests being stored
internally at the processing center and then forwarded in a batch mode to the service
provider, these requests can be forwarded to the service provider in real time if the provider
supports this.
Euronet Worldwide
Batch Participant Specifications
2-1
Chapter Two: Batch Participant

Specifications
Introduction
The communications program, whether a resident on the participant's host computer or on a
communications front-end processor, must handle a variety of communication conditions in
addition to the standard and predictable flow of messages. These conditions include, but are not
limited to the following:
A Positive, Negative, Wait and Delay protocol.

B Protocol error, retry conditions.
C Communications software is active and accepting messages, but the message processing
software is inactive, potentially resulting in lost messages.
D Blocked messages may be sent by the network to the participant or from the participant to
the network, if required.
E Contention recovery where the online participant tries to send at the same time as the
network. The online participant program must retry communications with the network.
Communication Requirements
All acquirer processors have an online communications link to the network. Most card issuers
also have an online link to the network. Other issuer processors operate in a batch mode. The
following sections provide the logical and physical requirements for the online link, including
the protocol procedures required to support the communications link.
TCP/IP
The TCP/IP connection uses stream sockets. Socket connection is permanent and can be
initiated from one of the parties, as agreed between the network and member during project
implementation. Actual communication parameters (IP address, TCP port) should be
mutually agreed upon during project implementation.
Note: Encryption may be used on communication level, where routers support it.
Euronet Worldwide
2-2
Note: TCP/IP is the recommended protocol.
Binary Synchronous Point-to-Point Communications Link protocol (BSC)

The BSC Point-to-Point communications link between the network and the acquirer or card
issuer processor uses a non-switched point-to-point data line on a contention basis.
X.25
An X.25 type of connection uses Switched Virtual Circuit (SVC) initiated by one of the
parties, as agreed between the network and member during project implementation.
Messages pass in unencrypted eight-byte characters. Actual communication parameters
(X.25 address, window and packet size, user data, etc.) should be mutually agreed upon
during project implementation.
Note: Encryption may be used on communication level, where routers support it.
Batch Participant File Specifications

This section provides descriptions of the files required for a batch interface to the network. One
file transmits daily transactions to the participant node, while the other file transmits cardholder
information and account balances from the participating node to the network:
Daily Transaction File

4 Batch Update File
4 Account Balance Record
4 Card Account Relationship Update Record
4 Card File Update Record
History Record
The three record formats for the Batch Update File can be mixed in the actual data file that is
transmitted to the network. The first field of the record identifies the different record formats.
An example of a typical transmission is a batch participant with 15,000 accounts that have cards
managed by the network. Of the 15,000 total accounts, only 1,000 account balances changed
from the previous Batch Update file transmission. In addition, five new cards were added to the
batch participants database; each of these cards has two accounts attached to them. This
scenario would result in a Batch Update file with 1,000 Account Balance records, five Card
Update records, and ten Card Account Relationship records.
Euronet Worldwide
2-3
The Batch Update file layout was designed to reduce problems sometimes caused when numeric
fields are transmitted from one type of computer to another. Because many computer systems
store numeric fields differently, the Batch Update file requires that the numeric fields be sent as
character data. In the following definitions, all the fields that are designated as numeric indicate
that the only valid characters are 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9. Note that blanks are invalid. No
decimal places are indicated. The number of decimal places is implied by the currency code.
In order to reduce data transmission time in the Card Update record and the Card Account
Relationship record, several of the fields at the end of the record are optional. If all of the
optional fields are not to be used for this record, the numeric fields can contain blanks. Note that
if any one optional field contains data, then all of the numeric fields must contain digits.
Daily Transaction File

This file transmits the days transactions to a participant from the network. All of the
transactions processed on behalf of a participant are sent to the participant in the following
format:
Daily Transaction File Layout
Field
Attribute Description
Position
Use
BTPTID
3A
BTTRTY
2A
BTTRFA
2A
Participant ID
Three-character code that identifies the
issuing institution. The network assigns
this code
Transaction Type
Code that identifies the type of
transaction performed. This value is
right justified, zero-filled.
For a complete list of transaction type
codes, see Appendix A: Transaction
Types in this document.
From Account Type
Code that identifies the type of debit
account used in the transaction. This
value is right justified, zero-filled.
For a complete list of the account types,
see Appendix D: Account Types in this
document.
Euronet Worldwide
2-4

Field
Position
Use
BTTRTA
2A
10
17
19
38
39
45
57
BTSER#
7,0S
BTRSPC
2A
BTCRD#
19A
BTMBR#
1A
BTAPR#
6A
BTSTAN
12,0 S
BTTTIM
6,0S
To Account Type
Code that identifies the type of credit
account used in the transaction. This
value is right justified, zero-filled.
For a complete list of the account types,
see Appendix D: Account Types in this
document.
Transaction Serial Number
Number assigned to the acquiring
terminal that uniquely identifies the
transaction at that terminal. This value
is right justified, zero-filled.
Response Code
Code defines if the transaction was
approved and if not, the reason why it
was denied. This value is right
justified, zero-filled.
For a complete list of the response
codes, see Appendix B: Response Codes
in this document.
PAN Number
Series of digits that identify a customer
account or relationship; i.e., card
number. This value is left justified,
blank-filled.
Member Number
This number distinguishes between
separate cards with the same Primary
Account Number (PAN).
Approval Number
Number assigned by the authorizing
participant on a Point-of-Service
transaction. This value is right
justified, zero-filled
System Trace Audit Number
Network-assigned number that uniquely
identifies a transaction. The number
remains unchanged throughout the life
of the transaction. This value is right
Transaction Time
Local time that the transaction was
performed at the card acceptor location.
The format of this field is hour minute
second, HHMMSS.
Euronet Worldwide

Field
Position
Use
BTTDAT
7,0S
63
70
77
81
89
104
144
155
158
177
Transaction Date
Local date on which the transaction was
performed at the card acceptor location.
The format of this field is century year
month day, CYYMMDD, where:
BTSDAT
7,0S
C=0
For the years 1900 - 1999
C=1
Settlement Date
Date on which funds will transfer
between the participant and the
network.
The format of this field is century year
month day, CYYMMDD, where:
BTMCAT
4,0S
BTCATI
8A
BTCAID
15A
BTCATA
40A
BTAQID
11A
BTNTID
3A
BTAC1#
19A
BTAC1B
10A
C=0
C=1
Merchant Category Code
ISO standard code that identifies the
merchant's type of business product or
service.
Card Acceptor Terminal ID
Unique code that identifies the terminal
at the card acceptor location. This
value is left justified, blank-filled.
Card Acceptor ID
Code that identifies the card acceptor.
This code defines the point of the
transaction in both local and
interchange environments.
Card Acceptor Terminal Location
Name and location of the card acceptor.
It defines the Point-of-Service in both a
local and interchange environment.
Acquirer ID
Code that identifies the acquiring
institution (e.g., merchant bank) or its
agent.
Network ID
Code that identifies a single network of
a card issuer.
Account 1 Number
Identifies the account used to perform
the transaction.
Account 1 Branch ID
Code that identifies the branch that
owns the account used to perform the
transaction
Euronet Worldwide
2-5
2-6

Field
Position
Use
BTTRCC
3A
187
190
205
220
235
238
253
268
283
286
BTTRN$
15,0S
BTATR$
15,0S
BTTRFE
15,0S
BTI1CC
3A
BTI1A$
15,0S
BTI1F$
15,0S
BTI1P$
15,0S
BTC1CC
3A
BTC1A$
15,0S
Transaction Currency
ISO standard numeric code that
identifies the currency in which the
transaction was performed.
For a complete list of the currency
codes, see Appendix C: Currency Codes
in this document.
Transaction Amount
Amount of the transaction requested by
the cardholder.
Actual Transaction Amount
The completed amount of the
transaction, expressed in terms of the
transaction currency
Transaction Activity Fee
Fee charged by the card acceptor to the
cardholder for the service of performing
the transaction.
Issuer 1 Settlement Currency
ISO standard numeric code that defines
the type of currency that the card issuer
uses for settlement purposes with the
network.
in this document.
Issuer 1 Settlement Amount
The equivalent amount of settlement for
the transaction expressed in the Issuer 1
Settlement Currency.
Issuer 1 Settlement Fee
Fee that the network charged the card
issuer for processing the transaction.
Issuer 1 Settlement Fee
Fee that the network charged the card
issuer for processing the transaction.
Cardholder 1 Bill Currency
ISO standard code that identifies the
currency of the account used to perform
the transaction.
in this document.
Cardholder 1 Billing Amount
The transaction amount converted to
the Cardholder 1 Bill Currency.
Euronet Worldwide

Field
Position
Use
BTC1AF
15,0S
301
BTC1PF
15,0S
316
BTC1SF
15,0S
331
BTTC1R
15,9S
346
BTSC1R
15,9S
361
BTDBCR
1A
376
377
BTDBTR
1A
Cardholder 1 Bill Activity Fee

The Transaction Processing Fee
expressed in the Cardholder 1 Bill
Currency.
Cardholder 1 Bill Processing Fee
The Issuer 1 Settlement Fee expressed
in the Cardholder 1 Bill Currency
Cardholder 1 Bill Service Fee
Fee charged to the cardholder by the
issuing institution for the service of
processing the transaction.
Transaction/Cardholder 1
Conversion Rate
The rate for converting the transaction
amount from the Transaction Currency
to the Cardholder 1 Bill Currency.
Settlement/Cardholder 1 Conversion
Rate
The rate for converting the transaction
amount from the Issuer 1 Settlement
Currency to the Cardholder 1 Bill
Currency.
Debit/Credit Flag
Flag that indicates whether the
transaction is debit (D) or credit (C).
Valid values:
D
Debit
C
Credit
Double Sided Transaction
A flag that indicates if both a debit and
credit are involved in the transaction.
Valid values:
Y
Yes
N
No
Note:
M
C
O
The following is a list of Use column codes:

Mandatory
Conditional
Optional
Note: Total Record Length for this file is 377.
Euronet Worldwide
2-7
2-8
Batch Update File

The Batch Update File contains card and account information sent from the participant to the
network each day.
Account Balance Record

This record format contains account balances and information for purposes of issuing transaction
authorizations. The participant transmits this record format to the network as a record in the
Batch Update File.
Account Balance Record Layout
Field
Attribute
Description
Position
Use
BBRCID
1A
Record Identifier
Code that identifies the record
type.
BBACTC
1A
Valid value:
B
Balance
Action Code
Specifies how to handle the
account.
Valid values:
A
Add
D
Delete
U
Update
R
Refresh
BBPAR#
3A
A refresh can only apply to the

entire balance file. An R
(refresh) action code causes the
system to delete all records for
that participant whenever it
encounters an R and then treat
the R records as if they are A
records. Only the first record
has to be an R for this to
happen.
Participant Number
Three-character code that
identifies the institution that
owns the account. The
network assigns this code.
Euronet Worldwide

Field
Attribute
Description
Position
Use
BBBCH#
10A
BBTYPE
2A
Branch Number
The specific branch that holds
the cardholder's account. This
value must be left justified,
blank-filled.
Account Type
Code that identifies whether
the account is 01/DDA,
02/Savings, etc. This value
must be right justified, zerofilled.
16
18
37
40
43
BBACCT
19A
BBCURC
3A
BBCONC
3A
BBSTAT
1A
For a complete list of the

account types, see Appendix D:
Account Types in this
document.
Account Number
The identification number for
the account. This value must
be right justified, zero-filled.
Currency Code
ISO standard numeric code that
identifies the currency of the
account.
currency codes, see Appendix
C: Currency Codes in this
document.
Country Code
ISO standard code that
identifies the country in which
this participant is located.
Account Status
Flag that specifies the status of
the account.
Valid values:
1
Active account
2
Dormant account
6
Frozen account
7
Closed account
Format:
Numeric
Euronet Worldwide
2-9
2-10

Field
Attribute
Description
Position
Use
BBCURR
15A
Current Balance
The actual book balance of
the account as well as any
unposted items. This value
44
59
74
89
104
124
BBAVAL
BBCOLL
BBODLM
15A
15A
15A
BBNAME
20A
BBCBR#
10A
Format:
Numeric
Available Balance
The amount available to the
cardholder. It may reflect only
a portion of the unposted items.
This value must be right
Format:
Numeric
Collected Balance
The actual book balance of
the cardholder's account. This
value must be right justified,
zero-filled.
Format:
Numeric
Overdraft Limit
The line of credit assigned to
this account with regard to
overdrafts. This value must be
Format:
Numeric
Customer Short Name
A brief and unique identifier
that locates each cardholder
based on only a few bytes of
their name.
Correspondent Branch
Number
Another branch number, as
defined above, that is
associated with the cardholder's
account.
Euronet Worldwide

Field
Attribute
Description
Position
Use
BBCATY
2A
Correspondent Account Type

Another account type, as
account.
134
136
155
BBCACT
19A
BBCCUR
3A

account types, see Appendix D:
document.
Correspondent Account
Number
Another account number, as
account.
Correspondent Currency
Code
Another type of currency, as
account.
document.
Note:
M
C
O

Mandatory
Conditional
Optional
Euronet Worldwide
2-11
2-12
Card Account Relationship Update Record

This record format updates the card database on the networks system. It contains information to
link the card number to an account number. The participant transmits this record format to the
network as a record in the Batch Update File.
Card Account Relationship Update Record Layout
Field
Attribute
Description
Position
Use
BARCID
1A
Record Identifier
Code that identifies the
record type.
25
26
BAACTC
1A
BAPAR#
3A
BACRD#
19A
BAMBR
BAACTY
1A
2A
Valid value:
A
Account
Relationship
Action Code
This code instructs how to
handle the record; i.e., added,
deleted, or updated.
Valid values:
A
Added record
D
Deleted record
U
Updated record
Participant Number
identifies the institution to
the network.
Card Number
Number that identifies the
card.
Format:
Numeric
Member Number
This number distinguishes
between two separate cards
with the same Primary
Account Number (PAN).
Format:
Numeric
Account Type
Code that identifies the type
of account associated with
the account number field.
account types, see Appendix
D: Account Types in this
document.
Euronet Worldwide

Field
Attribute
Description
Position
Use
BAACCT
19A
28
BAACDC
2A
BAACSQ
2A
Account Number
the cardholder's account.
Account Description Code
Participant-defined short
description for this account
number.
Account Type Sequence
Number
Unique number assigned to
each cardholder account.
BABRCH
10A
BALANG
2A
BACURC
3A
BASCWV
1A
Format:
Numeric
Account Owning Branch
The branch assigned to this
account number (if
applicable)
Language Code
language associated with this
card. The network to which
this file is sent defines this
code.
Currency Code
ISO standard numeric code
that identifies the type of
currency for this account.
document.
Waive Service Charge
Flag that indicates if this
account is exempt from
service charges.
Valid values:
Y
Exempt from
service charge
N
Not exempt from
service charge
(default value)
Euronet Worldwide
47
49
51
61
63
66
2-13
2-14

Field
Attribute
Description
Position
Use
BAPRIM
1A
Primary Account Within

Type
Flag that indicates the
account as primary. Use this
account when an account
number is not specified.
67
Valid values:
Y
Primary account
N/blank Not primary
account
Note:
M
C
O

Mandatory
Conditional
Optional
Card File Update Record

This record format updates the card database on the networks system. It contains information
required to authorize a transaction. The participant transmits this record format to the network as
a record in the Batch Update File.
Card File Update Record Layout
Field
Attribute
Description
Position
Use
BCRCID
1A
Record Identifier
record.
Valid value:
C
Card Update
Record
Euronet Worldwide

Field
Attribute
Description
Position
Use
BCACTC
1A
Action Code
Code that specifies how to
handle the record (i.e.,
added, deleted, inactive, or
updated.)
25
CPAR#
BCCRD#
BCMBR
3A
19A
1A
Valid values:
A
Added record
D
Deleted record
I
Inactive record
U
Updated record
Participant Number
identifies the institution.
Format:
Numeric
Card Number
Number that identifies the
card.
Format:
Numeric
Member Number
This number distinguishes
between separate cards with
the same Primary Account
Number (PAN) if not
applicably set to 0.
Format:
Numeric
Title
BC1ETL
10A
26
BCNAM1
78A
Name Line 1
Embossing name line 1.
36
BCNAM2
78A
114
BC1EFN
25A
192
BC1EMN
25A
217
BC1ESN
25A
242
BCSHNM
20A
267
BCADR1
40A
Name Line 2
Embossing name line 2.
First Name
Encode first name.
Middle Name
Encode middle name.
Surname
Encode short name.
Short Name
Search name.
Address Line 1
Cardholders address line 1.
287
Euronet Worldwide
2-15
2-16

Field
Attribute
Description
Position
Use
BCADR2
40A
327
BCCITY
50A
367
BCCOUN
10A
417
BCZIP1
5A
427
BCZIP2
4A
432
BCBRCH
10A
Address Line 2
Cardholders address line 2.
City
Cardholders city.
Country
Cardholders country.
ZIP-1 (for address verify)
Cardholder's ZIP code.
ZIP-2 (for address verify)
Cardholder's ZIP code
extension.
Card Owning Branch
436
BCLANG
2A
446
BCSCWV
1A
448
BCEXPC
2A
Language Code
language associated with
this card. This value must
be established with the
network to which this file is
sent.
Waive Service Charge
Flag indicating if the card
number is exempt from a
service charge. If the value
is Y, all members and
accounts attached to this
card will be exempt.
Expire Date/Century
The century the card for this
member will expire.
449
2A
Format:
Numeric
Expire Date/Year
The year the card for this
member will expire.
451
2A
Format:
Numeric
Expire Date/Month
The month the card for this
member will expire.
453
BCEXPY
BCEXPM
Format:
Numeric
Euronet Worldwide

Field
Attribute
Description
Position
Use
BCGEN
1A
Generate Card
Indicates the network is to
generate a card.
455
BCPINO
BCPVVX
BCACT
BCSTAT
12A
1A
1A
1A
Valid values:
G
Generate Card.
blank
PIN Offset/PVV/CVV
If this value is a PIN offset,
this is the difference
between a natural PIN and a
customer selected PIN. The
offset is produced when the
member has a customer
selected PIN. If the PIN was
generated using the Visa or
MasterCard algorithms, this
value will contain the PVV
or CVV code respectfully.
This field is currently not
used.
PVV/CVV Index
Index for PVV/CVV codes
if used.
This field is currently not
used.
Current Action for
Negative/Exception Card
Flag indicating the action to
take on this card.
Valid values:
A
Add
D
Delete
Current Status for
Negative/Exception Card
Flag indicating the result of
the reason code.
Valid values:
*
VIP status
B
No cash
withdrawals
(warm card)
C
Capture the card
D
Decline the
transaction but do
not capture card
Euronet Worldwide
456
468
469
470
2-17
2-18

Field
Attribute
Description
Position
Use
BCRECD
2A
Reason Code for Negative

Card
This code indicates the
reason a card can be flagged
as negative.
471
473
479
BCBDTE
BCSSN#
6A
15A
Valid values:
ST
Stolen card
FR
Fraudulent use
WM
Warm card
Birth Date
Date of birth for the
cardholder in Year Month
Day (YYMMDD) format.
Format:
Numeric
Social Security Number
Identification number for the
cardholder.
Format:
Numeric
Batch Update Balance History Record

The Batch Update Balance History Record contains historical data from batch updates to provide
an audit trail.
Batch Update Balance History Record Layout
Field
Attribute
Description
Position
Use
BHRCID
1A
Record Identifier
record type.
Valid value:
H
History Update
Record
Euronet Worldwide

Field
Attribute
Description
Position
Use
BHACTC
1A
Action Code
Specifies how the account
should be handled.
Valid values:
A
Add
D
Delete
U
Update
R
Refresh
BHBANK
3A
BHBCH#
10A
BHTYPE
2A
BHACCT
19A
A refresh can only be done to

the entire balance file. An R
(refresh) action code causes
the system to delete all
records for that participant
whenever it encounters an R
and then treat the R records
as if they are A records.
Only the first record has to be
an R for this to happen.
Participant Number
identifies the institution that
owns the account. The
network assigns this code.
Branch Number
The specific branch where
the cardholder's account is
held. This value must be left
justified, blank-filled.
Account Type
Code that identifies whether
the account is 01/DDA,
02/Savings, etc. This value
For a complete list of account
types, see Appendix D:
document.
Account Number
the account. This value must
be right justified, zero-filled.
Euronet Worldwide
15
17
36
2-19
2-20

Field
Attribute
Description
Position
Use
BHCRCD
3A
Currency Code
ISO standard numeric code
that identifies the currency of
the account.
39
BHSTAT
BHTRCD
1A
2A
BHTRDT
8A
BHEFDT
8A
BHAMT
15A
BHSER
11A
BHDORC
1A
BHMSG#
7A
For a complete list of

document.
Account Status
Flag that specifies the status
of the account.
Valid values:
1
Active account
2
Dormant account
6
Frozen account
7
Closed account
Transaction Code
Code that identifies the type
of transaction that is being
performed. This value is
For a complete list of
transaction type codes, see
Appendix D: Transaction
Types in this document.
Transaction Date
The local date on which the
transaction was performed at
the card acceptor location.
Posting Date
The local date on which the
transaction was posted.
Transaction Amount
The amount of the
transaction that was
requested by the cardholder.
Transaction Check Number
Debit or Credit
Flag that indicates whether
the transaction is debit (D) or
credit (C).
Valid values:
D
Debit
C
Credit
Error Message Number
Identifies an error message
associated with this record.
Euronet Worldwide
40
42
50
58
73
84
85
92
Note:
M
C
O
P

Mandatory
Conditional
Optional
Program Updated
Euronet Worldwide
2-21
2-22
Euronet Worldwide
ITM Settlement Procedures
3-1
Chapter Three: ITM Settlement

Procedures
Introduction
This document describes the settlement functions of the network. A detailed presentation of the
settlement process follows a conceptual overview of settlement.
Simply stated, the settlement process determines who owes how much to whom. In the
network environment, multiple entities must settle with each other. The following is a list of
common settlement terminology:
Terminology
Field
Description
Batch Participant
A batch participant transmits balance and card

information to the network so that the network can
authorize transactions for the participant's cardholders.
Periodically, the network sends transactions it has
processed to the participant for posting to the
cardholders accounts.
A node is an entity that performs transaction acquisition
or authorization. Node values are used for transaction
authorization routing. A node may be an online
participant or a batch participant.
Node
Settlement Concepts
Two monetary flows exist in the settlement process:
Funds an institution owes to the network.

Funds the network owes to an institution.
Euronet Worldwide
3-2
Two primary settlement reports detail this process:
Terminal Activity Report (or Acquirer Activity Report)

The Terminal Activity Report shows the transactions performed at the ATMs or POS devices
owned by the participant. This report details and totals the funds that the network owes the
participant for funds dispensed from the participant's ATMs.
Cardholder Activity Report (or Network Cardholder Activity Report)

The Cardholder Activity Report shows the transactions performed by the participant's
cardholders at the ATMs or POS devices within the network. This report details and totals
the amount that the participant owes the network for the funds dispensed to its cardholders at
network ATMs.
Additionally, fees are generally paid in two directions. The participant pays fees to the network
for various services (such as ATM driving fees) and for transaction fees. The network generally
pays the participant fees for acquiring cardholder transactions for customers of other participants.
The network determines these fees and assesses them to the participants outside of the network
settlement reporting.
Settlement Reporting
An issuer/acquirer network participant is an example of settlement. The participant owes the
network funds for the transactions its cardholders perform at ATMs in the network. The network
owes the participant funds for the money the participant dispenses from the ATMs it owns.
In this phase of settlement, the network is the controlling factor, and the participants (whether
batch or online) settle to the network at the time and on the day dictated by the network.
The network produces previously described Terminal Activity Report and Cardholder Activity
Report. The Terminal Activity Report indicates how much the network owes the participant for
funds withdrawn from the participant's ATMs. The Cardholder Report indicates how much the
participant owes the network for the transactions performed by its cardholders at other ATMs.
It is expected that the software on the computers of the network online participants produce
settlement reports similar to the network's Terminal Activity and Cardholder Activity Reports.
The participant must reconcile these reports with the reports produced by the network.
For batch participants, it is usually sufficient for the participant to use the reports produced by
the network for their settlement.
Euronet Worldwide
3-3
Examples of Report Usage
***Network Name***
Cardholder Activity
Report Terminology
***Network Name***
Terminal Activity
Report Terminology
Acquirer Node
***Network Name***
Holding Company
HOLD 1
Issuer Node
Participant
Acquirer ID
Participant B
Participant A
Card Acceptor
Participant A
Branch #1
ATM 1
Participant A
Branch #2
ATM 2
ATM 3
Terminal ID
Participant B
Branch #1
ATM 4
ATM 5
Terminal ID
Network Settlement Using Cardholder Activity and Terminal Activity Reports flowchart
Euronet Worldwide
3-4
In order to settle with the network via Cardholder Activity and Terminal Activity Reports, the
following sequence of events must occur:
1.
The node is a participant holding company (HOLD 1).
2.
HOLD 1 encompasses two participants (A and B).
3.
Participant A has two branches (A-Branch-1 and A-Branch-2) and participant B has one
branch (B-Branch-1).
4.
Because of its two branches, participant A owns and is responsible for funding and
balancing three ATMs (ATM1, ATM2, and ATM3).
5.
Because of its sole branch, participant B owns and is responsible for funding and
balancing two ATMs (ATM4 and ATM5).
Note: While the ATMs are owned by their respective participants, they are driven by the
network. Diagram indicates settlement hierarchy only, not physical connections.
Cardholder Activity Report

When network settlement runs for the network and its participants, the Cardholder Activity
Report details and totals all transactions performed by a participant's cardholders, regardless of
the source ATM or POS device.
Although not part of this example, if an acquirer processor is attached to the network, those
transactions performed by its cardholders at its own terminals are not seen by the network and
therefore not reported. The acquirer intercepts these transactions and they are processed by the
processor. (An acquirer processor physically drives the devices, whereas in this example, the
network is physically driving the devices.)
In this example, the participant holding company HOLD 1 is the network node. The two
participants it owns are participants A and B.
The Cardholder Activity Report is produced for HOLD 1 and within this report are the detail
transaction lists for A and B. Within each participant's listing, the transactions are grouped and
totaled by currency type. The total settlement amount is listed for each participant.
Euronet Worldwide
3-5
The settlement total for each participant indicates the amount A and B owe to HOLD 1 for
transactions their customers performed at network ATMs. At the end of the Cardholder Activity
Report, a total settlement amount displays for HOLD 1. This is the amount the node owes the
network.
So far, this chapter has addressed what the node owes the network. The following sections
address what the network owes the node for funds dispensed at the ATMs it owns and services.
Terminal Activity Report

When settlement runs for the network and its participants, the Terminal Activity Report details
and totals all transactions performed at the terminals owned and funded by the participants. The
report totals indicate how much the network owes the participants for transactions that occurred
at their ATMs.
In the example, the network is the acquirer node, as it physically drives the devices. The
smallest grouping of the Terminal Activity Report is the Transaction Listing by Terminal ID.
However, within each terminal ID listing the transactions are grouped by currency type.
For each terminal, the transactions are totaled by currency and the total indicated in the selected
network settlement currency. As illustrated in the example, the branches that service and fund
the ATMs are designated as the card acceptors. The terminal totals are indicated for each card
acceptor ID in the settlement currency. This shows the activity for A-BRANCH-1 terminals
ATM1 and ATM2. This total is the amount owed to the card acceptor A-BRANCH-1 by the
card acquirer A, the next higher level.
The participants owning the branches in this example are designated as the card acquirers. The
total on this report in the settlement currency is the amount owed to the card acquirer by the
network. This amount is the total funds dispensed at terminals owned by this acquirer. This
total is the sum of the totals of the card acceptors within the acquirer.
The sum of the settlement totals for the acquirers A and B is what the network owes to HOLD 1.
The settlement totals for the card acceptors within each acquirer are what A and B owe to their
branches for funds dispensed at their terminals.
Note: There are variations on the setup of acquirer and card acceptor. For example, in a
single participant environment with no branches, the participant is set up with a unique
acquirer ID that is also its card acceptor ID.
Euronet Worldwide
3-6
Participant Transaction Posting

For batch participants, the network produces a file of detail transactions for posting. Since the
network is the authorizer, the network determines the final disposition of the transaction.
However, for online participants, the participant is responsible for producing the posting
transaction from the online requests sent to it by the network. The network does not produce a
file of posting transactions for an online participant.
Settlement Accounts
It is recommended that the network establish due-from settlement accounts for each participant
at a local financial institution to receive the funds due to the network from the card issuer
participants. As previously discussed, the Cardholder Activity Reports indicate how much each
issuer participant owes the network.
Likewise, the network should establish due-to accounts at each of the participants to credit the
funds due to the participants from the network. The Terminal Activity Report indicates how
much the network owes to each acquirer. Any fees set by the network calculate outside the
network settlement process.
Adjustments
Occasionally transactions authorized and posted online must be corrected if, for example, an
ATM hardware error occurred. Manually handle such adjustments outside the network.
Suspense Reporting
The network settlement process produces a suspense report of the difference in the balancing of
the network and participants. The difference reported is based on the different settlement cutoff
times that occur within the network.
Euronet Worldwide
3-7
Settlement Report Structure

The diagrams in this section describe the sorting order and totaling characteristics of the
Cardholder Activity and Terminal Activity Reports.
Cardholder Activity Report

The Cardholder Activity Report indicates the amount the participant owes the network for funds
dispensed to customers at network ATMs. The following diagram depicts the sorting order and
totals contained on the Cardholder Activity Report:
Note: In this example, a notation of 1 indicates the first instance of a process. A notation
of N indicates that the process repeats as necessary.
Euronet Worldwide
3-8
Participant 1
Transaction List
Transaction Totals for Currency 1
Transaction List
Transaction Totals for Currency N

Participant 1 Totals in Settlement Currency
Participant N
Participant N Totals in Settlement Currency
Cardholder Activity Report Sorting Order diagram
Terminal Activity Report

The Terminal Activity Report indicates the amount the network owes the participant for funds
dispensed from the participant's ATMs. The following diagram illustrates the sorting order and
totals contained on the Terminal Activity Report:
Note: In this example, a notation of 1 indicates the first instance of a process. A notation
of N indicates that the process repeats as necessary.
Euronet Worldwide
Card Acceptor ID 1
Terminal 1 ID
Transaction List
Transaction List
Transaction Totals for Currency N
Terminal 1 Totals in Settlement Currency

Terminal ID N
Transaction List
Terminal ID N Totals in Settlement Currency
Card Acceptor 1 Totals in Settlement Currency
Card Acceptor ID N Terminal Totals

Card Acceptor ID N Totals in Settlement Currency
Terminal Activity Report Sorting Order diagram
Euronet Worldwide
3-9
3-10
Euronet Worldwide
Steps of Certification
4-1
Chapter Four: Steps of Certification

for Host-to-Host
Introduction
Testing and certification ensures that the member institution is able to communicate properly the
through online Host-to-Host interface using specified message formats and flows.
The testing and certification process takes place on test systems on both member and the host.
For certification purposes, use dedicated test lines (recommended) or production lines that can be
transferred to this test system, provided it will not disrupt current service.
This document provides the member institution with information necessary to perform
certification of members online Host-to-Host connection. The document identifies
responsibilities of both the host and the member institution, describes certification process, and
specifies a full set of certification test scripts.
Note: Member must perform the full or the partial set of certification test scripts, as
specified by related the scope of the project.
Related Document
ISO-8583: 1987 Standard
Euronet Worldwide
4-2
Areas of Responsibility
Host
Coordinate certification schedule with the participant member.

Set up host test environment.
Actively participate in certification.
Activate hosts test system.
Initiate messages according to certification script.
Verify test results.
Member Institution
Set up members test environment, including acquiring terminals for acquirers.

Generate and deliver test cards to the host according to Certification Forms (issuer only) in
this chapter.
Actively participate in certification.
Activate members test system.
Initiate messages according to certification script.
Certification Process
Testing Procedure
The technical staffs on both the host side and the member side activate the test systems at the
beginning of the scheduled certification time slot. The host and members technical staff
members maintain close communications throughout certification.
The hosts technical staff should assist the member with any questions or concerns that arise
during the testing process.
A test session lasts the entire scheduled time unless the hosts technical staff member specifies
otherwise. When the test completes, the member institution logs off the test system and the
technical staff member terminates the session.
Euronet Worldwide
4-3
Test Results
After the test session is completed, the host technical staff member analyzes the results.
Certification Completion
Certification is considered complete when all the steps of testing specified in certification scripts
are successfully performed.
Detailed Certification Process

The certification consists of a series of activities that verify and confirm that the member
(configured as an acquirer and/or an issuer) is capable of processing all online system messages
and message flows in a timely and accurate manner.
Preparatory Activities
In order to begin successful execution of certification test scripts, both the host and member
institutions have to perform the following activities:
Host
Set up the hosts test host environment.

Set up the Host-to-Host interface.
Set up the new participant (member).
Set up routing.
Set up the security and keys according to the Test Encryption Keys Form in this chapter.
Perform any additional setup according to project scope.
Set up the appropriate simulators.
Set up the appropriate test terminals (ATM, POS, etc.) for issuer certification only.
Set up the test telecommunications infrastructure.
Euronet Worldwide
4-4
Member
Complete certification forms and submit the forms to the host according to table below:
Member Type Form
Acquirer Only
Issuer Only
Both
Test Cards
No
Yes
Yes
Test Encryption Keys
Yes
Yes
Yes
Off-us Test Cards
Yes
No
Yes
Generate and deliver test cards to the host according to Test Cards Form (issuer members) in
this chapter.
Set up members test host environment.
Set up Host-to-Host interface.
Perform any additional host setup based on members system infrastructure.
Set up test cards and appropriate statuses according to the Test Cards Form (issuer members)
in this chapter.
Set up security and test keys according to the Test Encryption Keys Form in this chapter.
Set up appropriate test terminals (ATM, POS, etc.) for acquirer certification only.
Set up test telecommunications infrastructure.
Connectivity Tests
The purpose of online connectivity tests is to verify and confirm basic connectivity between the
host and member systems on the telecommunication and application level. Each member must
perform connectivity tests regardless of its type (acquirer/issuer/both).
Telecommunication Connectivity Tests

In order to verify and confirm connectivity on telecommunication level, both the host and
members technical staff will establish connection between the two systems according to the
certification script. See Test Case 001 for further details.
Application Connectivity Tests

In order to verify connectivity on the application level, both the host and members technical
staff will perform exchange of network management messages according to the certification test
script. See Test Case 002 for further details.
Euronet Worldwide
4-5
Issuer Tests
The purpose of online issuer certification tests is to validate message formats, message flows and
contents including cryptographic aspects (where applicable) of the messages processed by issuer
hosts. The issuer certification tests do not relate to the issuers internal processing (it is the
issuers exclusive responsibility) and/or reconciliation between the host and the member (done
during user acceptance testing).
An issuer must successfully perform the following activities in order to be certified.
Perform connectivity tests.

Process received transaction requests and advices, and generate and send appropriate replies
to the host as required by the certification script (within project scope).
Process received transaction reversal requests and generate and send appropriate transaction
reversal replies to the host as required by certification script (within project scope).
Acquirer Tests
The purpose of online acquirer certification tests is to validate message formats, message flows
and contents including cryptographic aspects (where applicable) of the messages generated and
processed by acquirers host. The online acquirer certification tests do not relate to
reconciliation between the host and the member (done during user acceptance testing).
An acquirer must successfully perform the following activities in order to be certified:
Perform connectivity tests.

Perform transactions at any terminal type as required by the certification script (within
project scope or supported by the host) and generate and sent to the host the appropriate
transaction request messages.
Process and complete transactions at the terminal as instructed by the corresponding
transaction replies received from the host.
Perform reversals for transactions at any terminal type as required by the certification script
and generate and sent to the host appropriate transaction reversal request message.
Euronet Worldwide
4-6
Certification Forms
Test Cards Form
Member Banks Name:____________________________________
Test card BINs for cards used during issuer tests.
BIN
Description
Note:
* MasterCard, Visa, proprietary, etc.
Test card information (must be supplied for each BIN).

Card
PIN
Number
Track 1
Data
Track 2
Data
Valid
Valid
Valid
Valid, used for PIN tests
Refer to Issuer
Pickup
Do not honor
Invalid transaction
Invalid amount
Card not on file
10
Expired card, capture
11
Suspected fraud, capture
12
Restricted card, capture
13
Lost card, capture
Euronet Worldwide
Card
PIN
Number
Track 1
Data
Track 2
Data
Valid
14
Stolen card, capture
15
Insufficient funds
16
Invalid checking account
17
Invalid savings account
18
Expired card
19
Restricted card
20
Exceeds w/d $ limit
21
Exceeds w/d # limit
22
Valid, invalid CVV1
Off-us Test Cards Form

Member Banks Name: ________________________________
Test card BINs for cards used during Acquirer tests.
BIN
Description
Note:
* MasterCard, Visa, proprietary, etc.
Off-us test card information (must be supplied for each BIN).

Card
PIN
Number
Track 1
Data
Track 2
Data
Status
Valid
Valid
Valid, used for PIN tests
Euronet Worldwide
4-7
4-8
Card
PIN
Number
Track 1
Data
Track 2
Data
Status
Refer to Issuer
Pickup
Do not honor
Invalid transaction
Invalid amount
Card not on file
10
Expired card, capture
11
Suspected fraud, capture
12
Restricted card, capture
13
Lost card, capture
14
Stolen card, capture
15
Insufficient funds
16
Invalid checking account
17
Invalid savings account
18
Expired card
19
Restricted card
20
Exceeds w/d $ limit
21
Exceeds w/d # limit
22
Valid, invalid CVV1
Test Encryption Keys Form

Member Banks Name:____________________________
Key Type
Value**
Recommended Value
Acquirer Working Key (AWK)
0123456789ABCDEF
Issuer Working Key (IWK)
0123456789ABCDEF
Note:
** Usage of production keys during certification is strongly discouraged.
Should it become necessary for any reason, secure key exchange procedures shall be used
in accordance with both the host and members security requirements.
Euronet Worldwide
4-9
Certification Scripts
Test Case 001: Telecommunication Level
Connectivity
The purpose of this test case is to verify and confirm members ability to establish and break
communication between the member and the host. The member is required to perform
appropriate test case depending on communication type.
1. TCP/IP Connectivity
Step
Tested
Function
Originated
By
1.1
Socket establishment
Host/Member*
1.2
Socket breakdown
Host
1.3
Socket reestablishment
Socket breakdown
Host/Member*
Socket reestablishment
Host/Member*
1.4
1.5
Tested By
Result
Comment
Member
Signature
Date
Note:
* Depending on setup agreed between the host and the member.
2. X.25 Connectivity
Step
Tested
Function
Originated
By
2.1
SVC/PVC
establishment
SVC/PVC
breakdown
SVC/PVC reestablishment
SVC/PVC
breakdown
Host/Member*
2.2
2.3
2.4
Result
Host
Host/Member*
Member
Euronet Worldwide
Comment
4-10
2. X.25 Connectivity
Step
Tested
Function
Originated
By
2.5
SVC/PVC reestablishment
Host/Member*
Tested By
Result
Signature
Comment
Date
Note:
* Depending on setup agreed between the host and the member.
Test Case 002: Application Level

Connectivity
The purpose of this test case is to verify and confirm members ability to originate properly
formatted network management requests and process responses received by the host, as well as
to receive and process network management requests from the host and respond with properly
formatted responses.
1. Application Level Connectivity: Network Management Messages
Step Tested
Originated MTID Special
STAN Expected Result Comment
Function by
Conditions
RC
1.1
Network Logon
Host
0800
DE-070 = 001
00
1.2
Echo
Host
0800
DE-070 = 301
00
1.3
Host
0800
DE-070 = 002
00
1.4
Network
Logoff
Network Logon
Member
0800
DE-070 = 001
00
1.5
Echo
Member
0800
DE-070 = 301
00
1.6
Member
0800
DE-070 = 002
00
1.7
Network
Logoff
Network Logon
Host
0800
DE-070 = 001
00
1.8
Cut-over
Master*
0800
DE-070 = 201
00
Tested By
Signature
Euronet Worldwide
Date
Node Status =
Processing
Node Status =
Offline
Node Status =
Processing
Node Status =
Offline
Node Status =
Processing
4-11
Note:
* Depending on agreement between the host and the member, one of parties will be
nominated as master participant.
Test Case 003: Issuer Request Formats

for Standard Transaction Types
The purpose of this test case is to verify and confirm the members (or issuers) ability to receive
and process standard transaction requests and to respond to the host with properly formatted
responses. Balance Inquiries are interwoven to assure proper account balance impact.
1. ATM, PBT, Card Read, Cash Withdrawal

Special Conditions 1,2
DE-018 = 6011
DE-022 = 901
DE-052-> valid PIN block
Step Tested
Function By
Conditions
RC
1.0
Network Logon
Member
0800
DE-70 = 001
00
1.1
Balance
Verification
Host
0200
00
1.1a
Financial
Request
Host
0200
DE-002 = card #1
DE-003 - 31xxxx
DE-002 = card #1
DE-003 = 01xxxx
1.1b
Balance
Verification
Host
0200
00
1.2
Financial
Request
Host
0200
DE-002 = card #1
DE-003 = 31xxxx
DE-002 = card #1
DE-003 = 01xxxx
1.2a
Full Reversal
Host
0420
17
1.2b
Balance
Verification
Host
0200
1.3
Balance
Verification
Host
0200
1.3a
Financial
Request
Host
0200
DE-002 = card #1
DE-003 = 001xxxx
DE-002 = card #1
DE-003 = 31xxxx
DE-002 = card #2
DE-003 = 31xxxx
DE-002 = card#2
DE-003 = 01xxxx
Euronet Worldwide
00
00
Node status =
Processing.
Starting balance
for card #1.
1000 units of
acquirer
currency.
500 units of
acquirer
currency.
Full reversal.
00
Ending balance
for card #1.
00
Starting balance
for card #2.
00
200 units of
acquirer
currency.
4-12

DE-018 = 6011
DE-022 = 901
DE-052-> valid PIN block
Step Tested
Function By
Conditions
RC
1.3b
Partial Reversal
Host
0420
DE-002 = card #2
DE-003 = 01xxxx
32
1.4
Balance
Verification
Host
0200
00
1.4a
Financial
Advice
Host
0220
DE-002 = card 32
DE-003 = 31xxxx
DE-002 = card #2
DE-003 = 01xxxx
1.4b
Balance
Verification
Host
0200
DE-002 = card #2
DE-003 = 31xxxx
00
Tested By
Signature
00
Partial reversal,
actual amount
150.
1000units of
acquirer
currency.
Ending balance
for card #2.
Date
Note:
1. Condition valid for all steps except 1.0.
2. Condition valid only if field is present in the reversal message.
2. POS PBT, Card Read, Purchase

DE-003 = 00xxxx
DE-018 <> (6011|6010)
DE-022 = 901
DE-052 -> valid PIN block
Step Tested
Function By
Conditions
RC
2.0
Network Logon
Member
0800
DE-070 = 001
00
2.1
Authorization
request
Host
0100
DE-002 = card #1
00
2.2
Authorization
request and full
reversal
Host
0100
DE-002 = card #1
00
0420
00
Euronet Worldwide
Node status =
Processing
1500 units of
acquirer
currency.
500 units of
acquirer
currency.
Full reversal.
4-13

DE-003 = 00xxxx
DE-018 <> (6011|6010)
DE-022 = 901
Step Tested
Function By
Conditions
RC
2.3
Authorization
request and
partial reversal
Host
0100
DE-002 = card #2
0420
00
00
2.4
Authorization
advice
Host
0120
DE-002 = card #2
00
2.5
Financial
advice (followup for 2.1)
Host
0220
DE-002 = card #1
00
2.6
Financial
advice (stand
alone)
Host
0220
DE-002 = card #2
00
Tested By
Signature
200 units of
acquirer
currency.
Partial reversal,
actual amount
500 units.
750 units of
acquirer
currency.
1500 units of
acquirer currency
STAN same as in
2.1
1200 units of
acquirer currency
Date
Note:
3. POS PBT, Card Read, Cash

Special conditions 1,2
DE-003 = 01xxxx
DE-018 = 6010
DE-022 = 901
Step Tested
Function By
Conditions
RC
3.0
Network logon
Member
0800
DE-70 = 001
00
3.1
Authorization
request
Host
0100
DE-002 = card #1
00
Euronet Worldwide
Node status =
Processing
1500 units of
acquirer
currency.
4-14

Special conditions 1,2
DE-003 = 01xxxx
DE-018 = 6010
DE-022 = 901
Step Tested
Function By
Conditions
RC
3.2
3.3
Authorization
request and full
reversal
Host
Authorization
request and
partial reversal
Host
0100
DE-002 = card #1
0420
0100
00
00
DE-002 = card #2
0420
00
00
3.4
Authorization
advice
Host
0120
DE-002 = card #2
00
3.5
Financial
Host
0220
DE-002 = card #1
00
3.6
Financial
advice (stand
alone)
Host
0220
DE-002 card #2
00
Tested By
Signature
500 units of
acquirer currency
Full reversal
200 units of
acquirer
currency.
Partial reversal,
actual amount 50
units/
1000 units of
acquirer
currency.
1500 units of
acquirer currency
STAN same as in
3.1.
1200 units of
acquirer currency
Date
Note:
4. POS SBT, Card Read, Purchase

DE-003 = 00xxxx
DE-018 <> (6001|6010)
DE-022 = 901
Step Tested
Function By
Conditions
RC
4.0
Network logon
Member
0800
DE-070 = 001
00
4.1
Authorization
request
Host
0100
DE-002 = card #1
00
Euronet Worldwide
Node status =
Processing
1500 units of
acquirer currency
4-15

DE-003 = 00xxxx
DE-018 <> (6001|6010)
DE-022 = 901
Step Tested
Function By
Conditions
RC
4.2
4.3
Authorization
request and full
reversal
Host
Authorization
request and
partial reversal
Host
0100
DE-002 = card #1
0420
0100
00
DE-002 = card #1
0420
4.4
4.5
4.6
00
00
00
Authorization
advice
Financial
Host
0120
DE-002 = card #2
00
Host
0220
DE-002 = card #1
00
Financial
advice (stand
alone)
Host
0220
DE-002 = card #2
00
Tested By
Signature
500 units of
acquirer currency
Full reversal
500 units of
acquirer
currency.
Partial reversal,
actual amount 50
units
1000 units of
acquirer currency
1500 units of
acquirer currency
STAN same as in
4.1
1200 units of
acquirer currency
Date
Note:
5. POS SBT, Card Read, Cash

DE-003 = 01xxxx
DE-018 = 6010
DE-022 = 901
Step Tested
Function By
Conditions
RC
5.0
Network logon
Member
0800
DE-070 = 001
Euronet Worldwide
00
Node status =
Processing
4-16

DE-003 = 01xxxx
DE-018 = 6010
DE-022 = 901
Step Tested
Function By
Conditions
RC
5.1
5.2
5.3
5.4
5.5
5.6
Authorization
request
Authorization
request and full
reversal
Host
0100
DE-002 = card #1
00
Host
0100
DE-002 = card #1
00
Authorization
request and
partial reversal
Host
0420
0100
DE-002 = card #1
00
00
Authorization
advice
Financial
Host
0120
DE-002 = card #2
00
Host
0200
DE-002 = card #1
0000
Financial
advice
(standalone)
Host
0220
DE-002 = card #2
00
0420
Tested By
00
Signature
1500 units of
acquirer currency
500 units of
acquirer currency
Full reversal
200 units of
acquirer currency
Partial reversal,
actual amount 50
units
1000 units of
acquirer currency
1500 units of
acquirer currency
STAN same as in
5.1
1200 units of
acquirer currency
Date
Note:
6. POS SBT, Manual 3, Purchase

DE-003 = 00xxxx
DE-018 <> (6011|6010)
DE-022 = 012
DE-035 -> not present
Step Tested
Function By
Conditions
RC
6.0
Network logon
Member
0800
DE-070 = 001
Euronet Worldwide
00
Node status =
Processing
4-17

DE-003 = 00xxxx
DE-018 <> (6011|6010)
DE-022 = 012
Step Tested
Function By
Conditions
RC
6.1
6.2
6.3
6.4
6.5
6.6
Authorization
request
Authorization
request and full
reversal
Host
0100
DE-002 = card #1
00
Host
0100
DE-002 = card #1
00
Authorization
request and
partial reversal
Host
Authorization
advice
Financial
Host
0120
DE-002 = card #2
00
Host
0220
DE-002 = Card #1
00
Financial
advice (stand
alone)
Host
0220
DE-002 = card #2
00
0420
0100
00
DE-002 = card #2
0420
Tested By
00
00
Signature
Date
Note:
3. Manual key entry or voice authorization.
Euronet Worldwide
1500 units of
acquirer currency
500 units of
acquirer currency
Full reversal
500 units of
acquirer currency
Partial reversal,
actual amount 50
units
1000 units of
acquirer currency
1500 units of
acquirer currency
STAN same as in
6.1
1200 units of
acquirer currency
4-18
7. POS SBT, Manual 3, Cash

DE-003 = 01xxxx
DE-018 = 6010
DE-022 = 901
Step Tested
Function By
Conditions
RC
7.0
Network logon
0800
DE-070 = 001
00
7.1
Authorization
request
Authorization
request and full
reversal
0100
DE-002 = card #1
00
0100
DE-002 = card #1
00
0420
0100
DE-002 = card #2
00
00
7.2
7.3
7.4
7.5
7.6
Authorization
request and
partial reversal
0420
00
Authorization
advice
Financial
0120
DE-002 = card #2
00
0220
DE-002 = card #1
00
Financial
advice (stand
alone)
0220
DE-002 = card #2
00
Tested By
Signature
Date
Note:
Euronet Worldwide
Node status =
Processing
1500 units of
acquirer currency
500 units of
acquirer currency
Full reversal
200 units of
acquirer currency
Partial reversal,
actual amount 50
units
100 units of
acquirer currency
1500 units of
acquirer currency
STAN same as in
7.1
1200 units of
acquirer currency
4-19
Test Case 004: Issuer Response Code

Acceptance
The purpose of this test is to verify and confirm the members (or issuers) ability to respond
with appropriate response code.
1. Response Code Acceptance
Step Tested
Function By
Conditions
RC
1.0
Network logon
Member
DE-070 = 001
00
1.1
Auth. req.
(normal card)
Auth. req.
(normal card)
Auth. req.
(refer to issuer)
Auth. req. (do
not honor)
Auth. req.
(invalid
transaction)
Auth. req.
(invalid
amount)
Auth. req. (card
not on file)
Auth. req.
(expired card,
capture)
Auth., req.
(suspected
fraud, capture)
Auth. req.
(restricted card,
capture)
Auth. req. (Lost
card, capture)
Auth. req.
(stolen card,
capture)
Auth. req.
(insufficient
funds)
Auth. req.
(Invalid
checking
account)
Auth. req.
(Invalid savings
account)
Host
DE-002 = card #1
00
Host
DE-002 = card #4
01
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
1.12
1.13
1.14
1.15
Host
0800
DE-002 = card #5
04
Host
0100
DE-002 = card #6
05
Host
0100
DE-002 = card #7
12
Host
0100
DE-002 = card #8
13
Host
0100
DE-002 = card #9
14
Host
0100
DE-002 = card #10
33
Host
0100
DE-002 = card #11
34
Host
0100
DE-002 = card #12
36
Host
0100
DE-002 = card #13
41
Host
0100
DE-002 = card #14
43
Host
0100
DE-002 = card #15
51
Host
0100
DE-002 = card #16
52
Host
0100
DE-002 = card #17
53
Euronet Worldwide
Node status =
Processing
4-20

Step Tested
Function By
Conditions
RC
1.16
1.17
1.18
1.19
1.20
Auth. req.
(expired card)
Auth. req.
(restricted card)
Auth. req.
(exceeds w/d $
limit)
Auth. req.
(exceeds w/d #
limit)
Auth. req.
(invalid CVV1)
Host
0100
DE-002 = card #18
54
Host
0100
DE-002 = card #19
62
Host
0100
DE-002 = card #20
61
Host
0100
DE-002 = card #21
65
Host
0100
DE-002 = card #22
04/05*
1.8Tested By
Signature
Invalid CVV1 on
track
Date
Note:
* Card captured or not, depending on issuer settings.
Test Case 005: Issuer PIN Processing

This test verifies and confirms the members (or issuers) ability to process encrypted PIN block
(good and bad PINs). Issuer must set its system to react after three incorrect PIN entries (capture
or not).
1. PIN Processing
Step Tested
Function By
Conditions
RC
1.0
Network logon
Member
0800
DE-70 = 001
00
1.1
Good PIN
Host
0100
DE-002 = card #3
00
1.2
Bad PIN
Host
0100
DE-002 = card #3
55
1.3
Good PIN
Host
0100
DE-002 = card #3
00
Euronet Worldwide
Node status =
Processing
ATM or POS
PBT used for
test.
ATM or POS
PBT used for
test.
ATM or POS
PBT used for
test.
4-21
1. PIN Processing
Step Tested
Function By
Conditions
RC
1.4
Bad PIN
Host
0100
DE-002 = card #3
55
1.5
Bad PIN
Host
0100
DE-002 = card #3
55
1.6
Good PIN
Host
0100
DE-002 = card #3
05
1.7
Bad PIN
Host
0100
DE-002 = card #3
55
1.8
Bad PIN
Host
0100
DE-002 = card #3
55
1.9
Bad PIN, action
Host
0100
DE-002 = card #3
38/75*
1.10
Good PIN
Host
0100
DE-002 = card #3
38/75*
Tested By
Signature
ATM or POS
PBT used for
test.
ATM or POS
PBT used for
test.
ATM or POS
PBT used for
test.
ATM or POS
PBT used for
test.
ATM or POS
PBT used for
test.
ATM or POS
PBT used for
test.
ATM or POS
PBT used for
test.
Date
Note:
* Depending on issuer settings to capture (38) or not (75) when maximum incorrect PIN
retry limit reached.
Euronet Worldwide
4-22
Test Case 006: Acquirer Request

Formats for Standard Transaction Types
The purpose of this test is to verify and confirm the members (or acquirers) ability to originate
properly formatted requests and receive and process responses sent by the host. Balance
inquiries are interwoven to assure proper account balance impact.
DE-018 = 6011
DE-022 = 901
Step Tested
Function By
Conditions
RC
1.0
Network logon
Member
0800
DE-070 = 001
1.1
Balance
verification
Member
0200
1.1a
Financial
request
Member
0200
1.1b
Balance
verification
Member
0200
1.2
Financial
request
Member
0200
1.2a
Full reversal
Member
0420
1.2b
Balance
Verification
Member
0200
1.3
Balance
Verification
Member
0200
1.3a
Financial
request
Member
0200
1.3b
Partial reversal
Member
0420
DE-002 = card #1
DE-003 = 31xxxx
DE-002 = card #1
DE-003 = 01xxxx
DE-002 = card #1
DE-003 = 31xxxx
DE-002 = card #1
DE-003 = 01xxxx
DE-002 = card #1
DE-003 = 01xxxx
DE-002 = card #1
DE-003 = 31xxxx
DE-002 = card #2
DE-003 = 31xxxx
DE=002 = card #2
DE-003 = 01xxxx
DE-002 = card #2
DE-003 - 01xxxx
1.4
Balance
Verification
Member
0200
1.4a
Financial
advice
Member
0220
1.4b
Balance
Verification
Member
0200
Tested By
00
1000 units of
acquirer currency
500 units of
acquirer currency
17
Euronet Worldwide
Full reversal
Ending balance
for card #1
Starting balance
for card #2
200 units of
acquirer currency
32
DE-002 = card #2
DE-003 = 31xxxx
DE-002 = card #2
DE-003 = 01xxxx
DE-002 = card #2
DE-003 = 31xxxx
Signature
Node status =
Processing
Starting balance
for card #1
Partial reversal,
actual amount
150
1000 units of
acquirer currency
Ending balance
for card #2
Date
4-23
Note:

DE-003 = 00xxxx
DE-018 <> (6011|6010)
DE-022 = 901
Step Tested
Function By
Conditions
RC
2.0
Network logon
Member
0800
DE-070 = 001
00
2.1
Authorization
request
Authorization
request and full
reversal
Member
0100
00
Member
0100
DE-002 = off-us
card #1
DE-002 = off-us
card #1
Authorization
request and
partial reversal
Member
Authorization
advice
Financial
Member
0120
Member
0220
Financial
advice (stand
alone)
Member
0220
2.2
2.3
2.4
2.5
2.6
0420
0100
00
DE-002 - off-us
card #2
0420
Tested By
00
00
00
DE-002 = off-us
card #2
DE-002 = off-us
card #1
00
DE-002 off-us card

#2
00
Signature
00
Date
Note:
Euronet Worldwide
Node status =
Processing
1500 units of
acquirer currency
500 units of
acquirer currency
Full reversal
200 units of
acquirer currency
Partial reversal,
actual amount 50
units
750 units of
acquirer currency
1500 units of
acquirer currency
STAN same as in
2.1
1200 units of
acquirer currency
4-24

DE-003 = 01xxxx
DE-018 = 6010
DE-022 = 901
Step Tested
Function By
Conditions
RC
3.0
Network logon
Member
0800
DE-070 = 001
00
3.1
Authorization
request
Authorization
request and full
reversal
Member
0100
00
Member
0100
DE-002 = off-us
card #1
DE-002 off-us card
#1
Authorization
request and
partial reversal
Member
Authorization
advice
Financial
Member
0120
Member
0220
Financial
advice (stand
alone)
Member
0220
3.2
3.3
3.4
3.5
3.6
0420
0100
00
De-002 = off-us
card #2
0420
Tested By
00
00
00
DE-002 = off-us
card #2
DE-002 = off-us
card #1
00
DE-002 = off-us
card #2
00
Signature
00
Date
Note:
Euronet Worldwide
Node status =
Processing
1500 units of
acquirer currency
500 units of
acquirer currency
Full reversal
200 units of
acquirer currency
Partial reversal,
actual amount 50
units
1000 units of
acquirer currency
1500 units of
acquirer currency
STAN same as in
3.1
1200 units of
acquirer currency
4-25

DE-003 = 00xxxx
DE-018 <> (6011|6010)
DE-022 = 901
Step Tested
Function By
Conditions
RC
4.0
Network logon
Member
0800
DE-070 = 001
4.1
Authorization
request
Authorization
request and full
reversal
Member
0100
Member
0100
DE-002 = off-us
card #1
DE-002 = off-us
card #1
Authorization
and partial
reversal
Member
Authorization
advice
Financial
advice (followup) for 4.1)
Member
0120
Member
0220
Financial
advice (stand
alone)
Member
0220
4.2
4.3
4.4
4.5
4.6
Node status =
Processing
1500 units of
acquirer currency
500 units of
acquirer currency
Full reversal
0420
0100
DE-002 = off-us
card #2
0420
Tested By
DE-002 = off-us
card #2
DE-002 = off-us
card #1
DE-022 = off-us
card #2
Signature
00
00
Date
Note:
Euronet Worldwide
500 units of
acquirer currency
Partial reversal,
actual amount 50
units
1000 units of
acquirer currency
1500 units of
acquirer currency
STAN same as in
4.1
1200 units of
acquirer currency
4-26

DE-003 = 01xxxx
DE-18 = 6010
DE-022 = 901
Step Tested
Function By
Conditions
RC
5.0
Network logon
Member
0800
DE-70 = 001
00
5.1
Authorization
request
Authorization
request and full
reversal
Member
0100
00
Member
0100
DE-002 = off-us
card #1
DE-002 = off-us
card #1
Authorization
request and
partial reversal
Member
Authorization
advice
Financial
Member
0120
Member
0220
Financial
advice (stand
alone)
Member
0220
5.2
5.3
5.4
5.5
5.6
0420
0100
00
DE-002 = off-us
card #2
0420
Tested By
00
00
00
DE-002 = off-us
card #2
DE-002 = off-us
card #1
00
DE-002 = off-us
card #2
00
Signature
00
Date
Note:
Euronet Worldwide
Node status =
Processing
1500 units of
acquirer currency
500 units of
acquirer currency
Full reversal
200 units of
acquirer currency
Partial reversal,
actual amount 50
units
1000 units of
acquirer currency
1500 units of
acquirer currency
STAN same as in
5.1
1200 units of
acquirer currency
4-27

DE-003 = 00xxxx
DE-018 <> (6011|6010)
DE-002 = 012
Step Tested
Function By
Conditions
RC
6.0
Network logon
Member
0800
DE-70 = 001
00
6.1
Authorization
request
Authorization
request and full
reversal
Member
0100
00
Member
0100
DE-002 = off-us
card #1
DE-002 = off-us
card #1
Authorization
request and
partial reversal
Member
Authorization
advice
Financial
Member
0120
Member
0220
Financial
advice (stand
alone)
Member
0220
6.2
6.3
6.4
6.5
6.6
0420
0100
00
DE-002 - off-us
card #2
0420
Tested By
00
00
00
DE-002 = off-us
card #2
DE-002 = off-us
card #1
00
DE-002 = off-us
card #2
00
Signature
00
Date
Note:
Euronet Worldwide
Node status =
Processing
1500 units of
acquirer currency
500 units of
acquirer currency
Full reversal
500 units of
acquirer currency
Partial reversal,
actual amount 50
units
100 units of
acquirer currency
1500 units of
acquirer currency
STAND same as
in 6.1
1200 units of
acquirer currency
4-28
7. POS SBT, Manual 3, Cash

Special Conditions 12,
DE-003 = 01xxxx
DE-018 = 6010
DE-022 = 901
Step Tested
Function By
Conditions
RC
7.0
Network logon
Member
0800
DE-70 = 001
00
7.1
Authorization
request
Authorization
request and full
reversal
Member
0100
00
Member
0100
DE-002 = off-us
card #1
DE-002 = off-us
card #1
Authorization
request and
partial reversal
Member
Authorization
advice
Financial
Member
0120
Member
0220
Financial
advice (stand
alone)
Member
0220
7.2
7.3
7.4
7.5
7.6
0420
0100
00
DE-002 = off-us
card #2
0420
Tested By
00
00
00
DE-002 = off-us
card #2
DE-002 = off-us
card #1
00
DE-002 = off-us
card #2
00
Signature
00
Date
Note:
Euronet Worldwide
Node status =
Processing
1500 units of
acquirer currency
500 units of
acquirer currency
Full reversal
200 units of
acquirer currency
Partial reversal,
actual amount 50
units
1000 units of
acquirer currency
1500 units of
acquirer currency
STAN same as in
7.1
1200 units of
acquirer currency
4-29
Test Case 007: Acquirer Response Code

Acceptance
The purpose of this test is to verify and confirm the members (or acquirers) ability to complete
transactions according to response codes sent by the host.
Step Tested
Function By
Conditions
RC
1.0
Network logon
Member
0800
DE-070 = 001
00
1.1
Auth. req.
(normal card)
Auth. req.
(refer to issuer)
Auth. req.
(Pickup)
Auth. req. (do
not honor)
Auth. req.
(invalid
transaction)
Auth.
req.(invalid
amount)
Auth. req. (card
not on file)
Auth. req.
(expired card,
capture)
Auth. req.
(suspected
fraud, capture)
Auth. req.
(restricted card,
capture)
Auth. req. (lost
card, capture)
Auth. req.
(stolen card,
capture)
Auth. req.
(insufficient
funds)
Auth. req.
(invalid
checking
account)
Auth. req.
(invalid savings
account)
Member
0100
00
Member
0100
Member
0100
Member
0100
Member
0100
DE-002 = off-us
card #1
DE-002 = off-us
card #4
DE-002 = off-us
card #5
DE-002 = off-us
card #6
DE-002 = off-us
card #7
Member
0100
DE-002 = off-us
card #8
13
Member
0100
14
Member
0100
DE-002 = off-us
card #9
DE-002 = off-us
card #10
Member
0100
DE-002 = off-us
card #11
34
Member
0100
DE-002 = off-us
card #12
36
Member
0100
41
Member
0100
DE-002 = off-us
card #13
DE-002 = off-us
card #14
Member
0100
DE-002 = off-us
card #15
51
Member
0100
DE-002 = off-us
card #16
52
Member
0100
DE-002 = off-us
card #17
53
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
1.12
1.13
1.14
1.15
Euronet Worldwide
01
04
05
12
33
43
4-30

Step Tested
Function By
Conditions
RC
1.16
1.17
1.18
1.19
1.20
Auth. req.
(expired card)
Auth. req.
(restricted card)
Auth. req.
(exceeds w/d $
limit)
Auth. req.
(exceeds w/d #
limit)
Auth. req.
(invalid CVV1)
Member
0100
Member
0100
Member
0100
Member
Member
Tested By
DE-002 = off-us
card #18
DE-002 = off-us
card #19
DE-002 = off-us
card #20
54
0100
DE-002 = off-us
card #21
65
0100
DE-002 = off-us
card #22
04\05*
Signature
Euronet Worldwide
62
61
Date
Invalid CVV1 on
track
Appendix A
Appendix A: Transaction Types

Transaction Types
Transaction Type Code
Description
01
Deposit.
02
Payment.
03
Transfer.
04
Withdrawal.
05
Inquiry.
06
Deposit with Cash Back.
07
Mini-Statement Print.
08
PIN Change.
09
Special Transfer.
10
TLB PIN Verification.
11
Service/Supply Request.
12
Full Statement Print.
13
On-Demand Payment (ATM Bill Pay).
14
Voice Bill Payment Override Scheduled.
15
Vendor Inquiry.
16
Vendor Accounts.
17
Consumer Relationship Verification.
18
Foreign Cash Check.
19
Stop Payment.
20
Approve for Lesser Amount.
21
Debit Purchase Authorization.
22
POS Debit Adjustment (Memo Post and Post).
23
Memo Credit Adjustment.
24
POS Inquiry.
25
Debit Purchases.
26
Follow Up Pre-Authorization Purchase.
27
Pre Authorization Cancelled (Reverse Memo Post).
28
Pre Auth Expired (No Memo Post).
29
Fast Cash.
30
Account List.
31
TLB Extension Dial.
32
TLB Voice Mail.
33
TLB Account Balance Refresh.
34
Check Clearing.
Euronet Worldwide
A-1
A-2
Appendix A
Transaction Types
Description
36
Checkbook Request.
37
Statement Request (Interim).
38
Loan Application.
39
Deposit Slip Request.
40
Speedy Transfer Form.
41
Remittance Check.
42
Message to Bank.
46
Manual Passbook Print.
47
Online Passbook Print.
48
Miscellaneous Fee.
49
Reset Passbook Printer.
50
Change Passbook Balance.
52
Business Deposit.
53
Batch Bill Pay Transaction.
54
Bill Pay Payment Inquiry.
55
Bill Pay Correction.
56
Bill Pay Service/Supply Recap for Day.
57
Recap Transaction for Day.
58
Request Copy of Check.
59
Last Statement Request.
60
Summarize Bill Payment for Day.
61
Memo Cash Advance.
62
Recap Bill Pay and Supply for Call.
63
End TLB Call.
64
Check Deposit with Cash Back.
65
Check Verification.
66
Cash Check with Holds.
67
Check Deposit.
68
Merchant Authorization.
69
Hot Card.
70
Withdrawal Authorization.
71
Cash Advance Authorization.
72
POS Representment/Deferred Debit (Memo).
73
POS Chargeback/Deferred Credit (Memo Post).
74
POS Verification (Verify/Authorize, No Memo Post).
75
POS Retrieval Request (Notify of SERVICEPRR).
76
POS Confirmation (Notify of Proc Paper).
77
Retail Sales Reversal.
Euronet Worldwide
Appendix A
Transaction Types
Description
78
Credit Reversal.
79
Cash Advance Reversal.
80
Stop Payment.
81
Credit Authorization.
82
Standing Order.
83
Currency Order.
99
Balance Record.
AB
Account List (Get Balances Only).
AD
Account Details.
AH
Account History.
AL
Account List.
AR
Recharge Registration.
AX
Amex Travelers Cheque Purchase.
BA
Retrieve Bill Pay Account List.
BC
Change Relationship.
BD
Delete Relationship.
BE
Retrieve Payment Relationship.
BH
Relationship History.
BI
Balance Inquiry.
BL
Retrieve Relationship List.
BN
Add Payee.
BP
List Payees.
BR
Retrieve Payee Information.
BS
Retrieve Scheduled Transactions.
BY
Retrieve Pending Payment Requests.
BZ
Retrieve Pending Payment Request.
B0
Initialize Add Payee/Relationship.
B1
Delete Add Payee/Relationship Request.
B2
Initiate Change Relationship.
B3
Delete UPD Payee/Relationship Request.
B4
Initialize Immediate Payment.
B5
Delete Immediate Payment Request.
B6
Initiate Add Additional Payment.
B7
Initiate Delete Additional Payment.
B8
Initiate Override Payment.
B9
Initiate Delete Override Payment.
CA
Card Activation.
C1
Account History.
Euronet Worldwide
A-3
A-4
Appendix A
Transaction Types
Description
C2
Wire Transfer.
C3
Standing Orders.
C4
PC to iSeries File Upload.
DA
Deferred Purchase Authorization.
DP
Deferred Purchase Memo Post.
IA
Delete Wire Template.
IB
Initiate Standing Order Request.
IC
Retrieve Pending Standing Order List.
ID
Retrieve Pending Standing Order Request.
IE
Delete Pending Standing Order Request.
IF
Retrieve Standing Order Templates List.
IG
Retrieve Standing Order Template.
IH
Delete Standing Order Template.
II
Read Bank Mail.
IJ
Send Bank Mail.
IK
Rates.
IV
Recharge Voucher.
I0
Initiate Transfer Request.
I1
Retrieve pending Transfer Request List.
I2
Retrieve pending Transfer Request.
I3
Delete Pending Transfer Request.
I4
Initiate Wire Request.
I5
Retrieve Pending Wire Request List.
I6
Retrieve Pending Wire Request.
I7
Delete Pending Wire Request.
I8
Retrieve List of Wire Templates.
I9
Retrieve Wire Templates.
MR
Online Mobile Recharge.
M1
Online Mobile Recharge (INQ).
NA
Negative Card ADD.
PI
Invalid PIN.
PM
Change Pay Other Relationship.
PO
Pay Other.
PV
Verify Password.
P1
Initiate Add Pay Other Relationship.
P2
Delete Add Pay Other Relationship Request.
P3
Initiate Change Pay Other Relationship.
P4
Delete Update Pay Other Relationship Req.
Euronet Worldwide
Appendix A
Transaction Types
Description
P5
Initialize Pay Other Immediate Payment.
P6
Delete Pay Other Immediate Payment Request.
TF
Transfer.
VI
Telephone Banking Inquiry.
VR
Recharge On-line.
Euronet Worldwide
A-5
A-6
Appendix A
Euronet Worldwide
Appendix B
Appendix B: Response Codes

Response Codes
Code
Action
Description
Short
Description
Explanation
00
Transaction approved.
APPROVED
Transaction approved.
01
INVLD TRAN
02
Card not in file.
CRD NT FLE
03
Expired card.
EXP CARD
04
Invalid Personal
Identification Number.
INV PIN
05
Invalid Transaction
Type.
INV TRN TP
06
Invalid Amount field.
INV AMT FD
Transaction not
defined in this system.
For example, an
attempted deposit in a
network where
deposits are not
supported.
The card is not in the
file.
Expiration date for the
card has been
exceeded.
The Personal
Identification Number
entered for this
customer is not valid.
Transaction not
defined in this system
or set up in definition
files.
1. The amount field in
this transaction is zero
(0) when it must be a
positive numeric
amount
OR
2. There are invalid
characters in the field.
OR
3. Invalid bill mix for
the transaction.
Euronet Worldwide
B-1
B-2
Appendix B
Response Codes
Code
Action
Description
Short
Description
Explanation
07
Invalid Response
Code.
INV RSP CD
1. The network has

sent a code that is not
supported in the switch
or ATM system.
OR
08
Processor down.
PROC DOWN
2. An invalid code has

been received from the
HIM or AIM module.
1. A foreign
transaction has been
sent to the network
that responds that the
card authorizer is not
available to authorize
the transaction.
OR
2. The switch system
sends a transaction to
the switch software,
which responds with
an 08 code because the
AIM or HIM module
is not available for
authorization.
OR
3. The switch software
is not available for the
ATM software to send
a transaction to the
network, so a
"Processor Down"
response is given to
the customer.
OR
4. The ATM system
sends a transaction to
the ATM software and
it responds with an 08
code because the AIM
or HIM module is not
available for
authorization.
Euronet Worldwide
Appendix B
Response Codes
Code
Action
Description
Short
Description
Explanation
09
Invalid card number.
INVAL CARD
1. A transaction has
been sent to the
network, which
responds with a code
that indicates the
cardholder is not on
file at the authorizing
bank.
OR
10
Module processing
error.
MOD PRC ER
11
Excessive PIN tries.
EX PIN TRY
2. The ATM/Switch
software responds to a
transaction when the
cardholder is not in
our card reference file
or has been marked as
deleted.
The software module
processing the
transaction has
encountered an error
and declines the
transaction. Detail of
the processing error
can be found in the log
file.
Maximum number of
PIN tries has been
reached for this card
for the day.
Additional transactions
will be declined, and,
depending upon the
option of the bank, the
card might be retained.
Whether the card is
retained depends on:
1. The flags set for the
local transaction.
OR
2. The response from
the network on foreign
transactions. The Card
Retained flag in the
NETDS data structure
indicates this.
Euronet Worldwide
B-3
B-4
Appendix B
Response Codes
Code
Action
Description
Short
Description
Explanation
12
Invalid account.
INV ACCT
13
Invalid account.
INV ACCT
14
Exceeded withdrawal
limit.
EXD W/D
15
Exceeded number
limit.
EXC # LIM
16
Reached amount limit.
EXC LIMIT
17
Exceeds account limit.
EX ACT LIM
18
Invalid message.
INV MESSGE
The account requested

for the transaction was
not found in the card
reference file.
The account requested
for the transaction was
not found in the card
reference file.
Amount requested in
this limit transaction
would cause the daily
withdrawal limit to be
exceeded. A lesser
amount may be
requested.
This error indicates
that the cardholder has
attempted to do a
greater number of
transactions than are
allowed on a daily
basis. This number
limit is either for an
account level number
of transactions or a
card level number of
transactions.
Prior to this
transaction,
withdrawal limit
amount has already
been reached.
Additional withdrawal
transactions will not be
allowed.
The transaction
amount that the
customer requested
exceeds account daily
limit. A lesser amount
may be requested
A message received by
the host system was an
invalid format or
contained invalid data.
Euronet Worldwide
Appendix B
Response Codes
Code
Action
Description
Short
Description
Explanation
19
Key sync error.
KY SYNC ER
Indicates that the key

being used by one
node is out of sync
with the key being
used by another node.
The note can be:
1. The Switch System
and the Switch
Network.
OR
20
Lost or stolen card.
LOST CARD
2. The ATM System

and the ATM.
This error code
indicates that this will
be treated as a hot
card. Whether the
card is retained
depends on:
1. How the flag is set
in the host system.
OR
21
Warm card; restricted

use.
WARM CARD
22
Do not honor.
NOT HONOR
Euronet Worldwide
2. The response from

the network on foreign
transactions. The Card
Retained flag in the
NETDS data structure
indicates card
retention.
This indicates that the
card has been
transaction usage
marked as a warm
card, either in our card
reference or at the
switch network. The
customer can generally
do credit-only
transactions, but
cannot withdraw cash.
Network sent message
to reject transaction
with no specific
reason.
B-5
B-6
Appendix B
Response Codes
Code
Action
Description
Short
Description
Explanation
23
Account already NSF.
ACCT NSF
24
Exceeds Funds
Available.
NO FUNDS
This error code

indicates that the
account balance minus
any restrictions (such
as minimum balance,
holds, etc.) was
insufficient for this
type of transactions.
This error code
indicates that the
transaction would
make the account
balance insufficient.
This could also present
a Select a Lesser
Amount screen to the
customer.
25
Message Rejected.
MESS REJT
26
Partial Dispense.
PAR DISP
27
Customer Cancel.
CUST CANCL
28
Full Reversal.
FULL REVRL
29
Amount is less than

minimum amount.
AMT < MIN
Euronet Worldwide
The amount requested

is not equal to the
amount dispensed.
The amount requested
is in the transaction
amount field. The
amount dispensed is in
the actual transaction
amount field of
NETDS and the online
transaction file. This
error code is not used
for a full misdispense
condition.
This is a full reversal.
The customer has
pressed the cancel
button to end the
transaction.
A full reversal with no
specific cause
designated (such as
hardware fault).
The customer
requested a minimum
amount that is less
than the minimum
allowable transaction
amount.
Appendix B
Response Codes
Code
Action
Description
Short
Description
Explanation
30
Invalid transaction for

this card.
INV TRAN
1. This error condition

for this card is
generally used for
custom features such
as whether a customer
can do check
validation through a
PBM. It is not for
general usage.
31
Hardware fault.
HRDW FAULT
32
Record Lock on
account.
RECORD LCK
33
General denial.
GENERAL DENIAL
34
INVALID TRANS
35
Bad Account status.
BAD ACCT
Euronet Worldwide
2. This is also defined

as a card that is not
allowed to do the
particular transaction
the customer is
attempting, yet card is
not flagged as warm.
This is a full reversal
transaction due to a
fault at the ATM, such
as a receipt printer
failure or dispenser
failure.
Some other application
is using this account
number.
Self-explanatory.
This error indicates

account conditions
such as inactive
account, closed
account, or restricted
account in the
application balance.
B-7
B-8
Appendix B
Response Codes
Code
Action
Description
Short
Description
Explanation
36
Invalid institution.
INV INSTIT
1. For the incoming

switch transaction, this
response indicates a
card BIN (Bank
Identification Number)
that was not valid for
us to process
OR
2. On the ATM
acquirer side, a
transaction sent to the
network was not for a
valid card BIN. The
network would
respond with this error
code. In unusual
circumstances, this
might be used in the
ATM system if this
error was not caught at
the FIT level to
indicate that this is not
a valid card BIN for
the local ATM
network.
37
38
CUR CNV ERROR
Currency Conversion
Rate error.
Duplicate transaction.
DUP TRANS
39
Unable to process.
UNABLE TO PROC
40
Unable to process
reversal.
REV NOT PROC
42
Unable to process
transaction.
TRAN NOT PROC
43
Maximum Pin tries -card retained.
MAX PIN TRIES
45
Incorrect old balance.
BAD BALANCE
Euronet Worldwide
A duplicate transaction
is received from the
network or the ATM.
Unable to process the
transaction for an
unknown reason.
The host system
received a reversal that
it could not process
properly; for example,
a reversal for a
transaction that is not
found in the current
day's transaction files.
Indicates that the card
was expired and
should be retained.
Too many invalid
PINs entered. Card
should be retained.
Balance entered by
teller does not match
beginning passbook
balance.
Appendix B
Response Codes
Code
Action
Description
Short
Description
Explanation
46
NO BACK ITEMS
No items found when

online passbook tried.
48
No back items to
print.
Suspected fraud.
49
ATM hardware
timeout.
50
Timeout.
TIMEOUT
51
POS invalid offline

approval.
INV OFF APPR
53
Manual reversal.
MANUAL REV
54
Invalid CVV Code II.
55
56
57
Security error during

CVV Verification.
Invalid expiration
date.
Invalid merchant.
INVALID CVV
CODE II
CVV ERROR
INVALID
EXPIRATION DATE
INVALID MERCH
58
POS void.
POS VOID
60
Device error flag.
DEV ER FLG
61
TIA record.
TIA RECORD
SUSPECTED
FRAUD
HARDWARE T/O
Euronet Worldwide
This occurs in the

event the host software
does not get a message
back to the hardware
within the time
allowed and the
hardware rejects our
authorization message.
TMM has determined
that the authorization
is not going to be
received from the
network before the
time allowed to
authorize a transaction
has expired. This is a
complete reversal.
The customer receives
Processor is Down
message screen.
A POS transaction was
authorized by the
merchant without an
approval from the host
and does not meet the
offline authorization
criteria.
Manual reversal.
Invalid CVV Code II.
CVV Processing failed
due to a security error.
A device (dispenser,
etc.) required for this
transaction is already
marked inoperative.
A balancing card was
inserted into the ATM,
and no processing
error occurred (BAD
PIN, etc.)
B-9
B-10
Appendix B
Response Codes
Code
Action
Description
Short
Description
Explanation
62
Device not
responding.
DEVICE NOT RESP
The ATM did not

respond to an approval
authorization at the
protocol level.
63
Message rejected.
MSG REJECT
64
OAR Timeout/Cancel.
OAR T/O
65
Deposit
Timeout/Cancel.
DEP T/O
66
Presentor error.
PRSNTOR ER
67
Success error.
SUCC ERROR
A customer presented
with a choice of
transaction accounts
has either cancelled his
request or allowed the
keyboard to time out.
A customer prompted
to insert an envelope
has either cancelled his
request or allowed the
depository to time out.
A delivery error has
occurred after a cash
dispense, but it is
believed the customer
received the money.
A device error
occurred during this
transaction that did not
affect the outcome;
examples:
1. Out of currency, but
the ATM indicated
that the amount
requested was
delivered.
71
Refer to issuer.
REFER TO ISSUER
75
Invalid debit account.
INV DB ACT
76
Invalid credit account.
INV CR ACT
77
Debit and credit

account are the same.
DB&CR ACCT=
Euronet Worldwide
2. Any printer error.

Set by external
network as General
Issuer Denial
The debit account was
not for a Telephone
Banking transaction.
The credit account was
not found for a
Telephone Banking
transaction.
The debit and credit
account numbers are
the same for a
Telephone Banking
transaction.
Appendix B
Response Codes
Code
Action
Description
Short
Description
Explanation
78
Transfer amount
exceeds limit.
EX XFER LM
The requested amount

to transfer exceeds the
transfer limit for
Telephone Banking
81
Lost card.
LOST CARD
82
Stolen card.
STOLEN CARD
85
Invalid address.
INV ADDRESS
86
No routing for
institution/ network.
NO ROUTING
87
Restricted card.
RSTR CARD
88
Exceeds deposit limit.
EXCD DEP LIMIT
90
Accept
transaction/retain card.
ACPT TRAN
92
No financial impact.
NO FIN IMP
93
Processor not signed

on.
PRC NOT ON
94
Suspect transaction.
SUSP TRANS
Euronet Worldwide
A network or financial
institution cannot be
found for transaction
routing.
The card is restricted.
The customer was not

allowed to complete
this transaction, but
the card was retained.
For example, when we
receive a transaction
from the switch and
debit the account, and
then receive a storeand-forward
transaction. Since this
is a duplicate debit, we
mark the store-andforward as No
Financial Impact and
report it with this
description.
The Switch System is
not signed on to the
switch network.
Generally, this would
cause a transaction to
go to the verification
report. This code is
used only in the switch
system for cardholder
processing.
B-11
B-12
Appendix B
Response Codes
Code
Action
Description
Short
Description
Explanation
96
Reversal exceeds
limits.
REV EX LIM
A reversal was
received from the
switch network that
would credit the
customers account for
greater than the
amount withdrawn
today. This might
occur when:
1. The switch network
is sent a reversal for a
transaction from a
previous day.
OR
98
Fail to see end.
FAIL TO SEE END
99
Incomplete
transaction.
INCOMP TRN
AI
APPROVE WITH ID
BC
Approve transaction
with identification.
Consumer not found.
BD
BR
B0
Date Format is
incorrect.
Relationship not
found.
Invalid payee number.
CONSUMER NOT
FOUND
BAD DATE
RELATIONSHIP
NOT FND
INVALID PAYEE #
Euronet Worldwide
2. The reversal amount

is simply incorrect
from the switch
network.
This is the status of a
transaction prior to
receipt of an
authorization in the
switch software and
prior to completion in
the ATM software. In
the ATM software,
this is commonly
known as Failed to See
End.
This is the status of a
transaction prior to
receipt of an
authorization in the
switch software and
prior to completion in
the ATM software. In
the ATM software,
this is commonly
known as Failed to See
End.
Appendix B
Response Codes
Code
Action
Description
Short
Description
CF
C2
Chip Card security

failure.
MOP: Verify error.
CHIP CARD SEC

FAIL
VERIFY ERROR
C3
RESTR PHONE
C4
MOP: Restricted
phone number.
MOP: Value error.
C5
MOP: General error.
EB
EF
Batch not balanced;

manual balance
required.
Date out of range.
MOP GENERAL
ERROR
ERR BALANCING
BATCH
EP
Expired password.
ET
EX
MD
Error on terminal ID/

not in service.
Expired preauthorization.
MACing decline.
ME
MACing error.
MAC ERR
NB
NP
Batch is out of balance

with control.
Non-processing date.
NV
MOP: No voucher.
BATHC NOT IN
BALANCE
NON-PROCESSING
DATE
NO VOUCHER
N1
N2
N3
N4
N5
N6
N7
N8
N9
CVC1 and CVC2 not

present.
CVC1 good/CVC2 not
present.
CVC1 bad/CVC2 not
present.
CVC1 not present
CVC2 good.
CVC1 not present
CVC2 bad.
CVC1 good/CVC2
good.
CVC1 good/CVC2
bad.
CVC1 bad/CVC2
good.
CVC1 bad/CVC2 bad.
PD
Past date.
P1
Invalid Client on
Customer
Verification.
VALUE ERROR
DATE OUT OF
RANGE
EXPIRED
PASSWORD
ERR ON TERMINL
ID
EXP AUTH
MAC DECLINE
CVC1 & CVC2 NOT

PRESENT
CVC1 GOOD/ CVC2
N/PRE
CVC1 BAD/CVC2
N/PRE
CVC1 N/PRE CVC2
GOOD
CVC1 N/PRE CVC2
BAD
CVC1 GOOD/CVC2
GOOD
CVC1 GOOD/CVC2
BAD
CVC1 BAD/CVC2
GOOD
CVC1 BAD/CVC2
BAD
PAST DATE
INV CLIENT ID
Euronet Worldwide
Explanation
B-13
B-14
Appendix B
Response Codes
Code
Action
Description
Short
Description
Explanation
P2
INVALID SSN#
P3
P4
RC
Invalid Social Security

Number on customer
verification.
Invalid customer ID
on customer
certification.
Invalid birth date on
customer verification.
Capture card.
CAPTURE CARD
RT
Repost timeout.
REPOST T/O
R1
R2
R3
RCI:USERID IN
PWD
RCI: MIN PWD
LENGTH
RCI: MIN # OF
DIGITS
R4
R5
RCI: PWD rejected

User ID in password.
RCI: PWD rejected
not minimum length.
RCI: PWD rejected
not minimum number
of digits.
RCI: PWD rejected
not minimum number
of characters.
Expired user.
EXPIRED USER
R6
Invalid user.
INVALID USER
R7
V1
V3
RCI: MAX # of
CHARS
ADDR MTCH/BAD
ZIP
ZIP(9) MTCH/ BAD
ADD
Used for address

verification.
Used for address
verification.
V4
V5
RCI: PWD rejected

password too long.
Address matches/ZIP
does not.
Nine-digit ZIP
matches/address does
not.
Address and ZIP do
not match.
Address does not
match/ not checking
ZIP.
BAD ADDR AND

ZIP
BAD ADDR/NO ZIP
Used for address

verification.
V5
INV CUSTOMER ID
INV BIRTHDATE
RCI: MIN # OF
CHARS
Euronet Worldwide
Appendix C
Appendix C: Currency Codes

Currency Codes
Country
Country
Code -Numeric
Aden
Country
Code -Alpha
Currency
Code -Numeric
ADE
013
Currency
Code -Alpha
Decimal
Positions
2
Afghanistan
004
AFG
004
AFA
Albania
008
ALB
008
ALL
Algeria
012
DAZ
012
DZD
American Samoa
016
ASM
840
USD
Andorra
020
AND
Spanish Peseta
724
ESP
French Franc
240
FRF
Andorran Peseta
020
ADP
Angola
024
AGO
024
AOK
Anguilla
660
AIA
951
XCD
Antarctica
010
ATA
578
NOK
Antigua and
Barbuda
Argentina
028
ATG
951
XCD
032
ARG
032
ARA
Aruba
533
ABW
533
AWG
Australia
036
AUS
036
AUD
Austria
040
AUT
040
ATS
Bahamas
044
BHS
044
BSD
Bahrain
048
BHR
048
BHD
Bangladesh
050
BGD
050
BDT
Barbados
052
BRB
052
BBD
Belgium
056
BEL
Belgian Franc
056
BEF
Convertible
Franc
Financial Franc
993
BEC
992
BEL
Belize
084
BLZ
084
BZD
Benin
204
BEN
952
XOF
Bermuda
060
BMU
060
BMD
Bhutan
064
BTN
Indian Rupee
356
INR
Ngultrum
064
BTN
Euronet Worldwide
C-1
C-2
Appendix C
Currency Codes
Country
Country
Code -Numeric
Country
Code -Alpha
Currency
Code -Numeric
Currency
Code -Alpha
Decimal
Positions
Bolivia
068
BOL
068
BOB
Botswana
072
BWA
072
BWP
Bouvet Island
074
BVT
578
NOK
Brazil
076
BRA
076
BRC
British Indian
Ocean
British Virgin
Islands
Brunei
Darussalam
Bulgaria
086
IOT
840
USD
840
USD
096
BRN
096
BND
100
BGR
100
BGL
Burkina Faso
854
BFA
952
XOF
Burma
104
BUR
104
BUK
Burundi
108
BDI
108
BIF
Byelorussian SSR
112
BYS
810
SUR
Cameroon
120
CMR
950
XAF
Canada
124
CAN
124
CAD
Cape Verde
Islands
Cayman Islands
132
CPV
132
CVE
136
CYM
136
KYD
Central African
Republic
Chad
140
CAF
950
XAF
148
TCD
950
XAF
Chile
152
CHL
152
CLP
China
156
CHN
156
CYN
Christmas Island
162
CXR
036
AUD
Cocos (Keeling)
Islands
Colombia
166
CCK
036
AUD
170
COL
170
COP
Comoros Islands
174
COM
174
KMF
Congo
178
COG
950
XAF
Cook Islands
184
COK
554
NZD
Costa Rica
188
CRI
188
CRC
Cote D'Ivoire
384
CIV
952
XOF
Cuba
192
CUB
192
CUP
Cyprus
196
CYP
196
CYP
Czechoslovakia
200
CSK
200
CSK
Denmark
208
DNK
208
DKK
Djibouti
262
DJI
262
DJF
Euronet Worldwide
Appendix C
Currency Codes
Country
Country
Code -Numeric
Country
Code -Alpha
Currency
Code -Numeric
Currency
Code -Alpha
Decimal
Positions
Dominica
212
DMA
951
XCD
Dominican
Republic
East Timor
214
DOM
214
DOP
626
TMP
Timor Escudo
626
TPE
Rupiah
360
IDR
Ecuador
218
ECU
218
ECS
Egypt
818
EGY
818
EGP
El Salvador
222
SLV
222
SVC
Equatorial
Guinea
Ethiopia
226
GNQ
950
XAF
230
ETH
230
ETB
954
XEU
European
Monetary
Cooperation
Fund
Faeroe Island
234
FRO
208
DKK
Falkland Islands
238
FLK
238
FKP
Fiji
242
FJI
242
FJD
Finland
246
FIN
246
FIM
France
250
FRA
250
FRF
French Guiana
254
GUF
953
XPF
French Southern
Territories
Gabon
260
ATF
250
FRF
266
GAB
950
XAF
Gambia
270
GMB
270
GMD
German
Democratic
Republic
Germany, Federal
Republic of
Ghana
278
DDR
278
DDM
280
DEU
280
DEM
288
GHA
288
GHC
Gibraltar
292
GIB
292
GIP
Greece
300
GRC
300
GRD
Greenland
304
GRL
208
DKK
Grenada
308
GRD
951
XCD
Guadeloupe
312
GLP
250
FRF
Guam
316
GUM
840
USD
Guatemala
320
GTM
320
GTQ
Guinea
324
GIN
324
GNF
Euronet Worldwide
C-3
C-4
Appendix C
Currency Codes
Country
Country
Code -Numeric
Country
Code -Alpha
Currency
Code -Numeric
Currency
Code -Alpha
Decimal
Positions
Guinea-Bissau
624
GNB
624
GWP
Guyana
328
GUY
328
GYD
Haiti
332
HTI
332
HTG
Gourde
840
USD
Heard and
McDonald Is.
Honduras
334
HMD
036
AUD
340
HND
340
HNL
Hong Kong
344
HKG
344
HKD
Hungary
348
HUN
348
HUF
Iceland
352
ISL
352
ISK
India
356
IND
356
INR
Indonesia
360
IDN
US Dollar
International
Monetary Fund
(IMF)
Iran (Islamic
Republic)
Iraq
360
IDR
960
XDR
364
IRN
364
IRR
368
IRQ
368
IQD
Ireland
372
IRL
372
IEP
Israel
376
ISR
376
ILS
Italy
380
ITA
380
ITL
Jamaica
388
JAM
388
JMD
Japan
392
JPN
392
JPY
Jordan
400
JOR
400
JOD
Kampuchea,
Democratic
Kenya
116
KHM
116
KHR
404
KEN
404
KES
Kiribati
296
KIR
036
AUD
Korea,
Democratic
People's Republic
of
Korea, Republic
of
Kuwait
408
PRK
408
KPW
410
KOR
410
KRW
414
KWT
414
KWD
Laos, People's
Democratic
Republic
Lebanon
418
LAO
418
LAK
422
LBN
422
LBP
Lesotho
426
LSO
Euronet Worldwide
Appendix C
Currency Codes
Country
Country
Code -Numeric
Country
Code -Alpha
Currency
Code -Numeric
Currency
Code -Alpha
Decimal
Positions
Rand
710
ZAR
Maloti
426
LSM
Liberia
430
LRD
Libyan Arab
Jamahiriya
Liechtenstein
434
LBR
434
LYD
438
LIE
756
CHF
Luxembourg
442
LUX
Luxembourg
Franc
Convertible
Franc
Financial Franc
2
442
LUF
989
LUC
988
LUL
Macau
446
MAC
446
MOP
Madagascar
450
MDG
450
MGF
Malawi
454
MWI
454
MWK
Malaysia
458
MYS
458
MYR
Maldives
462
MDV
462
MVR
Mali
466
MLI
952
XOF
Malta
470
MLT
470
MTL
Marshall Islands
474
MHL
840
USD
Martinique
474
MTQ
250
FRF
Mauritania
478
MRT
478
MRO
Mauritius
480
MUS
480
MUR
Mexico
484
MEX
484
MXP
Micronesia
583
FSM
840
USD
Monaco
492
MCO
250
FRF
Mongolia
496
MNG
496
MNT
Montserrat
500
MSR
951
XCD
Morocco
504
MAR
504
MAD
Mozambique
508
MOZ
508
MZM
Namibia
516
NAM
710
ZAR
Naura
520
NRU
036
AUD
Nepal
524
NPL
524
NPR
Netherlands
528
NLD
528
NLG
Netherlands
Antilles
Neutral Zone
532
ANT
532
ANG
536
NTZ
Saudi Riyal
2
682
Euronet Worldwide
SAR
C-5
C-6
Appendix C
Currency Codes
Country
Country
Code -Numeric
Country
Code -Alpha
Currency
Code -Numeric
Currency
Code -Alpha
Decimal
Positions
Kuwaiti Dinar
414
KWD
Iraqi Dinar
368
IQD
New Caledonia
540
NCL
953
XPF
New Zealand
554
NZL
554
NZD
Nicaragua
558
NIC
558
NIC
Niger
562
NER
952
ZOF
Nigeria
566
NGA
566
NGN
Niue
570
NIU
554
NZD
Norfolk Island
574
NFK
036
AUD
Northern
Mariana Islands
Norway
580
MNP
840
USD
578
NOR
578
NOK
Oman
512
OMN
512
OMR
Pakistan
586
PAK
586
PKR
Palau
585
PLW
840
USD
Panama
590
PAN
Balboa
590
PAB
US Dollar
840
USD
2
2
Papua New
Guinea
Paraguay
598
PGN
598
PGK
600
PRY
600
PYG
Peru
604
PER
604
PEI
Philippines
608
PHL
608
PHP
Pitcairn Island
612
PCN
554
NZD
Poland
616
POL
616
PLZ
Portugal
620
PRT
620
PTE
Puerto Rico
630
PRI
840
USD
Qatar
634
QAT
634
QAR
Reunion
638
REU
250
FRF
Romania
642
ROM
642
ROL
Rwanda
646
RWA
646
RWF
St. Helena
654
SHN
654
SHP
St. Kitts-Nevis
658
KNA
951
XCD
Saint Lucia
662
LCA
951
XCD
St. Pierre and

Miquelon
Saint Vincent and
the Grenadines
666
SPM
250
FRF
670
VCT
951
XCD
Euronet Worldwide
Appendix C
Currency Codes
Country
Country
Code -Numeric
Country
Code -Alpha
Currency
Code -Numeric
Currency
Code -Alpha
Decimal
Positions
Samoa
882
WSM
882
WST
San Marino
674
SMR
380
ITL
Sao Tome and

Principe
Saudi Arabia
678
STP
678
STD
682
SAU
682
SAR
Senegal
686
SEN
952
XOF
Seychelles
690
SYC
690
SCR
Sierra Leone
694
SLE
694
SLL
Singapore
702
SGP
702
SGD
Solomon Islands
090
SLB
090
SBD
Somalia
706
SOM
706
SOS
South Africa
710
ZAF
710
ZAR
Spain
724
ESP
Spanish Pesta
724
ESP
Convertible
Peseta Accts
Sri Lanka
144
LKR
144
LKA
144
LKR
Sudan
736
SDN
736
SDP
Suriname
740
SUR
740
SRG
Svalbard and Jan

Mayen Islands
Swaziland
744
SJM
578
NOK
748
SWZ
748
SZL
Sweden
752
SWE
752
SEK
Switzerland
756
CHE
756
CHF
Syrian Arab
Republic
Taiwan, Province
of China
Tanzania, United
Republic of
Thailand
760
SYR
760
SYP
158
TWN
901
TWD
834
TZA
834
TZS
764
THA
764
THB
Togo
768
TGO
952
XOF
Tokelau
722
TKL
554
NZD
Tonga
776
TON
776
TOP
Trinidad and
Tobago
Tunisia
780
TTO
780
TTD
788
TUN
788
TND
Turkey
792
TUR
792
TRL
Turks and Caicos

Islands
796
TCA
840
USD
Euronet Worldwide
C-7
C-8
Appendix C
Currency Codes
Country
Country
Code -Numeric
Country
Code -Alpha
Currency
Code -Numeric
Currency
Code -Alpha
Decimal
Positions
Tuvalu
798
TUV
036
AUD
Uganda
800
UGA
800
UGS
Ukrainian SSR
804
UKR
810
SUR2
Union of Soviet
Socialist Republic
United Arab
Emirates
United Kingdom
810
SUN
810
SUR
784
ARE
784
AED
826
GBR
826
GBP
United States
840
USA
840
USD
Same Day
998
USS
Next Day
997
USN
United States
Minor Outlying
Islands
Uruguay
581
UMI
840
USD
858
URY
858
UYP
Vanuatu
548
VUT
548
VUV
Vatican City State
336
VAT
380
ITL
Venezuela
862
VEN
862
VEB
Vietnam
704
VNM
704
VND
Virgin Islands
(British)
Virgin Islands
(US)
Wallis and
Futuna Islands
Western Sahara
092
VGB
840
USD
850
VIR
840
USD
876
WLF
953
XPF
732
ESH
504
MAD
Yemen
886
YEM
886
YER
Yemen,
Democratic
Yugoslavia
720
YMD
720
YDD
890
YUG
890
YUD
Zaire
180
ZAR
180
ZRZ
Zambia
894
ZMB
894
ZMK
Zimbabwe
716
RHO
716
ZWD
Euronet Worldwide
Appendix D
Appendix D: Account Types

Account Types
Account Type
Description
01
Current.
02
Savings.
03
Credit Card.
04
Other Account.
05
Credit Line.
06
Money Market.
07
Mortgage Loan.
08
Installment Loan.
09
NOW Account.
10
CD.
11
Commercial Loan.
30
Statement Request.
31
Checkbook Request.
32
Loan Application.
33
Utility.
34
Telephone.
35
Enclosed.
40
Bill Pay via Check.
41
Electronic Bill Pay.
42
Bill Pay External.
43
Manual Bill Pay.
Euronet Worldwide
D-1
D-2
Appendix D
Host-to-Host File Specifications
Euronet Worldwide

H2Hspecs PDF

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

H2Hspecs PDF

Transféré par

Droits d'auteur :

Formats disponibles

Host-to-Host

Integrated Transaction Management (ITM) is a registered trademark of Euronet

4601 College Boulevard, Suite 300

Financial Transaction Advice Normal Completion ............................................................... 1-20

Section 2: Optional Extended Transaction Support . 1-51

Request List of Defined Bill Payment Relationships ............................................................ 1-73

Chapter Two: Batch Participant Specifications.......... 2-1

Chapter Three: ITM Settlement Procedures .............. 3-1

Chapter Four: Steps of Certification for Host-to-Host 4-1

Member ........................................................................................................................................ 4-4

Appendix A: Transaction Types ................................. A-1

Online Participant Interface Specifications

Chapter One: Online Participant

Bank or other institution connecting to host via Host-toHost connection

The participant that receives the message

The participant (in Host-to-Host connection) that defines

Online Participant Interface Specifications

The following acronyms appear throughout this document.

Automated Teller Machine

Acquirer Working Key

Binary Synchronous Point-to-Point Communications

Dynamic Key Exchange

International Standards Organization standards for

Message Authentication Code

Merchant Category Code

List Account Open Account Relationship

Primary Account Number

Personal Identification Number

PIN Verification Value

System Trace Audit Number

Switched Virtual Circuit

Zone Master Key

Online Participant Interface Specifications

Master Participant, Cutover and

Message Authentication Code Usage

Dynamic Key Exchange Support

File Update 03xx Messages Support

Online Participant Interface Specifications

Transmission of Binary Data Elements

Differences to ISO-8583: 1987 Standard

Card Acceptor Terminal ID

Card Acceptor Location

File Update code

Doesnt remain unchanged for all

Online Participant Interface Specifications

Message Type Identifier

Concatenated data elements

General Message Structure flowchart

Authorization advice messages

Financial transaction messages

Financial advice messages

Network Management messages

Online Participant Interface Specifications

Note: The bitmap is always transferred as 16 characters.

Cardholder Number (DE-2)

Online Participant Interface Specifications

Match Follow-up Messages to the Original Message

Cardholder Number (DE-2)

Receiving and processing of following messages:

Online Participant Interface Specifications

Generating and sending of following messages:

Taking necessary recovery actions