Inter-host interface
In order for banks working in the same Association to understand each other during transaction authorization, clearing and settlement, it is necessary to agree on the syntax and semantics of information exchange within the payment system. For this purpose, the ISO 8583 standard was created, which defines the formats and purpose of messages circulating between banks that are members of the payment Association.
Issuers and servicing banks can act as both the sender and the recipient of information.
The ISO 8583 standard defines the following message structure for the interbank interface:
the ID of the message type (Message Type Identifier);
a bitcard (bitcard representation) of a message that has a size of 64 or 128 bits (if the bitcard size is 128 bits, then its first bit is 1; if the size is 64 bits, then the first bit is
bit is 0). Today, some payment systems use a 192-bit bitcard (third bit card) to represent transactions on microprocessor cards to the network);
— message body consisting of data elements whose presence is determined by the message bitcard. The standard operates with a certain set of data elements, the meaning of which is precisely defined. Each data item has a number assigned to it, and the value of the bit in the bit representation with the item number determines the presence of the data item in the message: a value of 1 indicates the presence of the item, 0 indicates its absence. Some data elements have a fixed length, while others have a variable length. In the latter case, the data element has a fixed-size prefix that defines the length of the data element.
Let’s look at the structure of the interbank interface message in more detail. Let’s start with the message type ID, which consists of four decimal digits. The first (left) digit of the identifier defines the version of the ISO 8583 standard and currently takes one of three values: 0 – for the first version of the 1987 standard, 1-for the 1993 version of the standard, and 2-for the last version of the standard that appeared in its final form in 2003. Values 3-9 of the first digit are reserved for future use in the ISO 8583 standard (in previous versions of the standard, the value 8 was used for national payment systems, and 9 for private systems).
The second digit of the identifier defines the message class according to the following agreement:
- reserved value;
—authorization. Messages of this class are used for
receipt of confirmation or guarantee that funds related to a particular transaction will be reimbursed by the Issuer to the servicing Bank. As a result of authorization, the Issuer does not debit funds from the client’s account immediately. This happens only after the Issuer receives a financial message from the servicing Bank that confirms the completion of the transaction that initiated the authorization; - financial message. Messages of this class are executed
they perform a financial transaction and are directly attached to the cardholder’s account. Sometimes these messages are called presentations); - messages for changing information in databases.
Messages of this class are used to initialize a remote control transaction for adding, changing, deleting, and replacing records in files, as well as adding/deleting individual files in the file system. In particular, these messages are used to keep up – to-date the so-called stop lists of the payment system, consisting of stolen/lost / compromised cards; - transaction cancellation/payment rejection (reverse/chargeback).
Transaction cancellation is used by the servicing Bank to cancel the result of a previous authorization or financial transaction. The servicing Bank sends reverse whenever it does not receive a response to the authorization request from the Issuer within the set time (timeout). Transaction cancellation is also used when the customer refuses to purchase at the point of sale. Chargeback, like transaction cancellation, is used to cancel the result of a previous authorization or financial transaction, but at the initiative of the Issuer. The reason for refusal of payment can be a challenge to the transaction by the cardholder, violation of the rules of the payment system (for example, incorrect use of the card product or type of operation, violation of the terms of submission of the financial message, etc.); - reconciliation control messages. Message
this class is used for reconciliation of records for transactions;
— administrative message. These messages are most common
used by the Issuer to request additional information about the transaction from the servicing Bank (retrieval request), for which a payment rejection can be sent, and to transmit information to the sender about an error that occurred in its message; - messages intended for collecting commissions
fees arising between banks of the payment system (servicing banks and issuers) in accordance with the rules of this system. These messages are not applied to client accounts. In the English version of the standard, they are called fee collection message. Fee collection messages can be sent from the servicing Bank to the Issuer, and Vice versa;
— network management messages.
they are used for many tasks, including establishing an inter-host connection and monitoring the connection, changing keys and passwords, marking the beginning and end of a file transfer or message group, and marking the end of a record reconciliation procedure.
The third digit of the message type identifier defines the requirements for the message recipient that the recipient must follow in order to complete the transaction successfully. The following options for requirements for the message recipient are considered:
the sender sends a request message (the third digit is 0) to the recipient to inform them that a response is required from the sender to approve or reject the request in order to complete the transaction. Thus, the recipient is required to evaluate the request, make a decision on its approval or rejection, and report the result of the decision to the sender in the response message (the sign of the response to the request is the value of the third digit equal to 1);
the sender informs the recipient (the third digit is equal to
that some operation took place at the point of sale and the recipient is required to confirm (the third digit in the response message is 3) that the notification of this operation was received (the recipient does not need authorization to perform the operation). The messages used by the sender in this case are called notifications (advice message);
the sender notifies the recipient (the third digit of the message is 4) that some operation took place at the point of sale. In this case, the recipient is not required to confirm the receipt of information about this operation, or to authorize the operation. The message used by the sender in this case is called a notification.
Finally, the last fourth digit of the message type identifier identifies the source of the message and the fact that the message is repeated. The fourth digit takes the following values:
—the servicing Bank is the initiator of the transaction;
—the servicing Bank is the initiator of the re-registration
transactions; - the Issuer is the initiator of the transaction;
- the Issuer is the initiator of the repeated transaction;
—The other party is the initiator of the transaction;
—the other party is the initiator of the repeated transaction.
It should be noted that there are dependencies between the latter
three digits of the message type identifier. Here are some message flow diagrams that illustrate the order of messages when performing transactions. In these diagrams, the message type is determined by the last three digits (the first digit indicating the ISO 8583 version number is omitted).