ISO 8583 :: MTI
As it's name suggests, the message type indicator provides information
about the type of message we are dealing with. The MTI consists of four
components describing version, class, function and originator of the
message. Typically, the four MTI components are encoded as two
bytes, with each half-byte or nibble representing one of the components.
For example, a message beginning 0x01 0x00 has the version info set to
0, the class set to 1, and function and originator fields both set
to 0.
Version
This is the first piece of information contained in the message, indicating the ISO standard version the message is based on. The following version values are defined:
| Value | Version |
|---|---|
| 0 | 1987 |
| 1 | 1993 |
| 2 | 2003 |
| 3-9 | Reserved for ISO use |
Message Class
the next position of the MTI provides information about the message class that the message is categorized as:
| Value | Message Class |
|---|---|
| 0 | Reserved for ISO use |
| 1 | Authorization |
| 2 | Financial presentment |
| 3 | File action |
| 4 | Reversal/Chargeback |
| 5 | Reconciliation |
| 6 | Administrative |
| 7 | Fee collection |
| 8 | Network management |
| 9 | Reserved for ISO use |
At this point, one could asked oneself naively, what exactly do these classes mean? How are 'Financial Presentment' and 'Financial Presentment' different? What about the difference between the 'Administrative' and 'Network management' classes? It turns out that those are very good questions and not everybody using 8583 to create a protocol came up with identical answers. A semantically identical message marked 'Authorization' in one protocol may be 'Financial Presentment' in another. So vaguely, the classes should mean roughly what you think they mean, but you need to check the description of the protocol you're talking about to be certain.
Message Function
The following table contains the possible values of the message function component of the MTI. Note that here again the precise meaning of these functions are dependent on the flavor of ISO you're using.
| Value | Message Function |
|---|---|
| 0 | Request |
| 1 | Request response |
| 2 | Advice |
| 3 | Advice response |
| 4 | Notification |
| 5 | Notification acknowledgment |
| 6 | Instruction |
| 7 | Instruction acknowledgment |
| 8,9 | Reserved for ISO use |
Again, don't ask what the difference is between an 'Advice', a 'Notification' and an 'Instruction'. The answer is: it depends.
Transaction Originator
The final component is information about who initiated the transaction. The possible values are:
| Value | Message Function |
|---|---|
| 0 | Acquirer |
| 1 | Acquirer Repeat |
| 2 | Card Issuer |
| 3 | Card Issuer Repeat |
| 4 | Other Originator |
| 5 | Other Originator Repeat |
| 6-9 | Reserved for ISO |
An important aspect to note is the existence of 'Repeat' messages. In case no response was received, it's usually possible to resend the identical message with the originator information set to 'Repeat'.
MTI example
A typical message a new terminal sends out when first connected might be
an 0800 message. Looking up the information above, we see the
terminals protocol is old'ish (1987). The message class is 'Network
Management', the message's function is a 'Request' and it's being sent
by the 'Acquirer'. You could argue about the sense of claiming the
acquirer sent the message when in fact it's being sent by a terminal at
the merchant.
If the host the terminal is trying to communicate with answers, it would
send back a 0810 message. The message type is identical, apart
from being a 'response' and not a 'request'. But, if the terminal
doesn't receive an answer from the host, the terminal may try to resend
the message, this time as a 0801 message, indicating the message to be
a repeat.
When the answer from the host finally arrives, the terminal will be able
to tell apart delayed answers to the first (0810) message and answers
to the repeat (0811).