Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Code Meaning
3xxx
4xxx
6xxx
7xxx
Message class[edit]
Position two of the MTI specifies the overall purpose of the message.
x3xx
File actions
Used for hot-card, TMS and other exchanges
message
x5xx
Reconciliation
Transmits settlement information message.
message
x6xx
Administrative Transmits administrative advice. Often used for failure
message messages (e.g. message reject or failure to apply).
x7xx
Fee collection
messages
Network
x8xx
Used for secure key exchange, logon, echo test and other
management
network functions.
message
Message function[edit]
Position three of the MTI specifies the message function which defines how the message should
flow within the system. Requests are end-to-end messages (e.g., from acquirer to issuer and
back with time-outs and automatic reversals in place), while advices are point-to-point messages
(e.g., from terminal to acquirer, from acquirer to network, from network to issuer, with
transmission guaranteed over each link, but not necessarily immediately).
Code Meaning Notes
xx0x Request
xx2x Advice
xx4x Notification
xx5x
Notification
acknowledgement
xx6x Instruction
xx8x
Some implementations[which?] use for positive
acknowledgment.[citation needed]
Reserved for ISO use
xx9x
Some implementations[which?] use for negative
acknowledgment.[citation needed]
Message origin[edit]
Position four of the MTI defines the location of the message source within the payment chain.
Code Meaning
xxx0 Acquirer
xxx4 Other
xxx6
xxx7
Reserved by ISO
xxx8
xxx9
Examples[edit]
Given an MTI value of 0110, the following example lists what each position indicates:
0130
Issuer Response to
Confirmation of receipt of authorization advice
Authorization Advice
0210
Issuer Response to
Issuer response to request for funds
Financial Request
0230
Issuer Response to
Confirmation of receipt of financial advice
Financial Advice
Bitmaps[edit]
In ISO 8583, a bitmap is a field or subfield within a message, which indicates whether other data
elements or data element subfields are present elsewhere in the message.
A field is considered to be present only when the corresponding bit in the bitmap is set. For
example, a byte with value 0x82 (decimal 130) is binary 1000 0010, which means
fields 1 and 7 are present in the message and fields 2, 3, 4, 5, 6 and 8 are not.
The bitmap may be represented as 8 bytes of binary data, or as sixteen hexadecimal characters
(0-9, A-F) in the ASCII or EBCDIC character sets. A message will contain at least one bitmap,
called the primary bitmap, which indicates which of data elements 1 to 64 are present. The
presence of an optional secondary bitmap is also indicated by bit 1 of the primary bitmap. If
present, the secondary bitmap indicates whether data elements 65 to 128 are present. Similarly,
a tertiary bitmap can be used to indicate the presence of fields 129 to 192, although these data
elements are rarely used.
Examples[edit]
Given a bitmap value of 42 10 00 11 02 C0 48 04,
0x42 = 0100 0010 (counting from the left, the second and seventh bits are 1, indicating
that fields 2 and 7 are present)
0x10 = 0001 0000 (the first bit corresponds to field 9, so the fourth bit here indicates
field 12 is present)
0x00 = 0000 0000 (no fields present)
0x11 = 0001 0001 (fields 28 and 32 are present)
0x02 = 0000 0010 (field 39 is present)
0xC0 = 1100 0000 (fields 41 and 42 are present)
0x48 = 0100 1000 (fields 50 and 53 are present)
0x04 = 0000 0100 (field 62 is present)
0 10 20 30 40 50 60
nth
bit
12345 12345 12345 12345 12345 12345 12
67890 67890 67890 67890 67890 67890 34
Bit
01000 01000 00000 01000 11000 00100 01
ma 01000 00000 00100 00010 00001 00000 00
p