ISO 8583:1993

Financial transaction card originated messages - Interchange message specifications

Specifies a common interface by which financial transaction card originated messages may be interchanged between acquirers and card issuers, message structure, format and content, data elements and values for data elements. Also specifies a numbering system for institution identification codes for financial institutions which do not have an ISO 7812 institution identification number and the procedures used for the registration of institution identification codes. Establishes procedures for a maintenance agency for codes used in this standard, the method of applying for codes and the method of obtaining lists of codes.

Messages initiés par carte de transaction financière — Spécifications d'échange de messages

La présente Norme internationale aborde les aspects suivants : a) Spécifications d'échange de messages. La présente Norme internationale définit une interface commune par laquelle les acquéreurs et émetteurs de carte peuvent échanger des transactions financières initiées par carte. Elle précise la structure du message, son format et son contenu, les éléments d'information et les valeurs des éléments d'information. La méthode par laquelle se fait le règlement n'est pas du domaine de la présente norme. b) Autorité d'enregistrement. La présente Norme internationale définit un système de numérotation des codes d'identification pour les organismes financiers qui n'ont pas de numéro d'identification d'organisme selon l'ISO 7812. Elle précise aussi les procédures utilisées pour l'enregistrement des codes d'identification des organismes. c) Agence de maintenance. La présente Norme internationale établit des procédures pour une agence de maintenance des codes utilisés dans la présente norme, les méthodes de demande de codes et les procédures d'obtention des listes de codes.

General Information

• Status: Withdrawn
• Publication Date: 22-Dec-1993
• Withdrawal Date: 22-Dec-1993
• ICS: 35.240.15 - Identification cards. Chip cards. Biometrics
• Technical Committee: ISO/TC 68 - Financial services
• Drafting Committee: ISO/TC 68 - Financial services
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 17-Jun-2003
• Completion Date: 13-Dec-2025

Relations

• Corrected By: ISO 8583:1993/Cor 1:1999 - Financial transaction card originated messages - Interchange message specifications - Technical Corrigendum 1: .
• Effective Date: 28-Dec-2008
• Revised: ISO 8583-2:1998 - Financial transaction card originated messages - Interchange message specifications - Part 2: Application and registration procedures for Institution Identification Codes (IIC)
• Effective Date: 02-Mar-2013
• Revised: ISO 8583-3:2003 - Financial transaction card originated messages - Interchange message specifications - Part 3: Maintenance procedures for messages, data elements and code values
• Effective Date: 02-Mar-2013
• Revised: ISO 8583-1:2003 - Financial transaction card originated messages - Interchange message specifications - Part 1: Messages, data elements and code values
• Effective Date: 15-Apr-2008
• Revised: ISO 18245:2003 - Retail financial services - Merchant category codes
• Effective Date: 15-Apr-2008
• Parent: ISO 8583:1993/Cor 1:1999 - Financial transaction card originated messages - Interchange message specifications - Technical Corrigendum 1: .
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL
STANDARD
Second edition
1993-12-15
Financial transaction card originated
- Interchange message
messages
specificatiorls
Messages initie’s par carte de transaction financi&re - Spkifications
d’khange de messages
Reference number
IS0 8583:1993(E)
IS0 8583 : 1993 (E)
Contents
Page
iv
Foreword .
V
Introduction .
................................................................................................. 1
Scope
....................................................................... 1
Normative references
Definitions . 1
Message structure . 3
........................................................................................ 3
4.1 General
...................................................................................... 13
4.2 Bit maps
4.3 Data element directory . 28
4.4 Requirements for data elements . 36
Message and transaction flows . 41
5.1 General . 41
5.2 Message flow diagrams .
5.3 Transaction flow diagrams . 48
Message and transaction matching . 50
6.1 General . 50
6.2 Message matching . 50
................................................................ 50
6.3 Transaction matching
Maintenance Agency and Registration Authority .
7.1 Maintenance of codes . 50
7.2 IS0 8583 Institution identification codes . 50
7.3 All other IS0 8583 codes . 51
Guidance on the use of this International Standard . 51
8.1 Additional message types . 51
........................................................... 51
8.2 Additional data elements
8.3 Mandatory and conditional data elements . 51
8.4 Unintentional introduction of control characters .
@ IS0 1993
All rights reserved. No part of this publication may be reproduced or utilized in any form or by any
means, electronic or mechanical, including photocopying and microfilm, without permission in
writing from the publisher.
International Organization for Standardization
Case postale 56 l CH-1211 Genbve 20 l Switzerland
Printed in Switzerland
ii
ISO8583:1993(E)
Figures
1 Bit maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 Reconciliation example .*. 49
Tables
1 Amounts in types of authorization messages . 4
2 Amounts in types of financial transaction messages . 5
Amounts in reversal messages . 6
4 Financial transactions . 6
5 Amounts in chargeback messages . 7
6 Message type identifiers . 9
7A Bit maps (in numerical order) . 15
7B Bit maps (by message type) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*. 19
8 Conditions used in table 7B . . . . . . .*. 27
9 .
Data element directory 29
10 Usage of institution identification codes .
11 .
Reconciliation calculation 39
Annexes
A Code listings . 52
A.1 Action codes . 53
A.2 Amount type codes . 55
A.3 Authorization life cycle codes . 55
A.4 Card acceptor business codes . 55
A.4.1 Card acceptor business codes (numerically) . 55
A.4.2 Card acceptor business codes (alphabetically) . 59
A.5 Fee type codes . 63
A.6 Function codes . 64
A.7 Message reason codes . 65
A.8
Point of service data code . 68
A.9 Processing codes . 70
B Conversion guide . . .I. 72
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.l 73
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 73
Differences between 1987 and 1993 editions of IS0 8583 . . . . . . . . . . . . . .
B.3 73
B.3.1 General .*.*.,. 73
B.3.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
B.3.2.1 Additions . . . . . . . . .I. 74
B.3.2.2 Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.3.2.3 Deletions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
. . .
III
IS0 8583 : 1993 (E)
B.3.3 Message structure .
B.3.4 Message types .
8.3.5 Data elements .
B.3.5.4 Additions .
........................................................................................... 84
B.3.5.2 Changes
.......................................................................................... 85
B.3.5.3 Deletions
Action, function and message reason code mapping . 86
B.3.5.4
................................................ 90
B.3.5.5 Point of sevice data code mapping
Usage of data elements . 92
B.3.6
B.3.7 Message flows .
................................................................. 107
B.3.7.1 Authorization messages
B.3.7.2 Financial messages .
...................................................................... 107
B.3.7.3 File action messages
......................................................................... 107
B.3.7.4 Reversal messages
Chargeback messages . 107
B.3.7.5
Reconciliation messages . 108
B.3.7.6
Administrative messages . 108
B.3.7.7
................................................................ 108
B.3.7.8 Fee collection messages
.................................................. 108
B.3.7.9 Network management messages
Exception message flows . 109
B.3.7.10
.................................................................................
Further advice
B.4
B.4.1 Usage of amount data elements .
B.4.1.1 General .
Authorizations . 110
B.4.1.2
..................................................................... 111
B.4.1.3 Financial transactions
......................................................................................... 111
B.4.1.4 Reversals
.................................................................................... 111
B.4.1.5 Chargebacks
Reconciliation processing . 112
B.4.2
General . 112
B.4.2.1
B.4.2.2 Accumulation . 112
B.4.3 Fee collection .
B.4.4 Usage of fee amount data elements .
Tables
B.l Comparison of message classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2 File update code (1987) mapped to function code (1993) .,.,.
Network management information code (1987) mapped to
B.3
function code (1993) . . . . . . . . . . . . .*.*.
Response code (1987) mapped to message reason code and
B.4
action code (1993) . . . . . . . . . . . . . . . . . . . . . . . . . . .*.*.
..,... . . . . . . . . . . 90
B.5 Settlement code (1987) mapped to action code (1993)
Point of service PIN capture code (1987) mapped to point of
B.6
service data (1993) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.7 Point of service condition code (1987) mapped to point of
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
service data (1993)
Point of service entry mode (1987) mapped to point of service
B.8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
data (1993)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
B.9 Data elements by message class
..11.........,....,.,.,.,..,,.,,....,......,. 114
B.10 Reconciliation processing examples
Forms for application for institution identifiers and codes . . . . . . . . . .
C
IS0 8583 : 1993 (E)
IS0 (the International Organization for Standardization) is a worldwide
federation of national standards bodies (IS0 member bodies). The work of
preparing International Standards is normally carried out through IS0 technical
committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that
committee. International organizations, governmental and non-governmental,
in liaison with ISO, also take part in the work. IS0 collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
Draft International Standards adopted by the technical committees are
circulated to the member bodies for voting. Publication as an International
Standard requires approval by at least 75 % of the member bodies casting a
vote.
International Standard IS0 8583 was prepared by Technical Committee lSO/rC 68,
Banking and related financial services, subcommittee SC 6, Financial
transaction cards, related media and operations.
This second edition cancels and replaces the first edition (IS0 858319871, of
which it constitutes a technical revision.
Annex A forms an integral part of this International Standard. Annexes B and C
are for information only.
V
IS0 8583:1993(E)
Introduction
Services of the financial industry include the exchange of electronic messages
relating to financial transactions. Agreements on application specifications are
generally at a private level. This International Standard is designed as an
interface specification enabling messages to be exchanged between systems
adopting a variety of application specifications. The application specification
may remain at the private level. Designers of such applications have complete
design freedom within the overall constraint that messages shall be convertible
to this interface format in order that international interchange may take place.
This International Standard introduces the concept of a message version
number to distinguish between messages which comply with this or
subsequent editions of the Standard, and those complying with the 1987
edition.
This International Standard uses a concept called bit map, whereby each data
element is assigned a position indicator in a control field, or bit map. The
presence of a data element in a specific message is indicated by a one in the
assigned position; the absence of a data element is indicated by a zero in the
assigned position.
Data representation used in individual systems is subject to the commercial
relationships between the parties contracting to each system. The message
formats specified in this International Standard are designed to ensure that
compatibility between systems conforming to this International Standard is
always feasible.
VI
INTERNATIONAL STANDARD IS0 8583 : 1993 (E)
Financial transaction card originated messages -
Interchange message specifications
IS0 4909:1987, Bank cards - Magnetic stripe data
1 Scope
content for track 3.
This International Standard addresses the following:
IS0 7372:1986, Trade data interchange - Trade data
elements directory (Endorsement of UNECEFDED,
a) Interchange Message Specifications
sections 1,2,3,4 and 9).
This International Standard specifies a common
IS0 7810:1985, Identification cards - Physical
interface by which financial transaction card
characteristics.
originated messages may be interchanged between
acquirers and card issuers. It specifies message
IS0 78 12: 1987, Identification cards - Numbering
structure, format and content, data elements and values
system and registration procedure for issuer
for data elements. The method by which settlement
identification.
takes place is not within the scope of this standard.
IS0 78 13: 1990, /den tification cards - Financial
b) Registration Authority
transaction cards.
This International Standard specifies a numbering
IS0 8601:1988, Data elements and interchange
system for institution identification codes for
formats - Information interchange - Representation
financial institutions which do not have an IS0 7812
of dates and times.
institution identification number. It also specifies
the procedures used for the registration of
IS0 9564-1:1991, Banking - Persona/ identification
institution identification codes.
Number management and security - Part I: PIN
protection principles and techniques.
c) Maintenance Agency of Codes
IS0 9807: 199 1, Banking and related financial services
This International Standard establishes procedures
-Requirements for message authentication (retail).
for a Maintenance Agency for codes used in this
standard, the method of applying for codes and the
IS0 1 OZOZ- 1: 199 1, Financial transaction cards -
method of obtaining lists of codes.
Security architectures of financial transaction systems
using integrated circuit cards - Part I: Card life cycle.
2 Normative references
3 Definitions
The following standards contain provisions which,
through reference in this text, constitute provisions of
For the purpose of this International Standard, the
this International Standard. At the time of publication,
following definitions apply.
the editions indicated were valid. All standards are
subject to revision, and parties to agreements based
3.1 acquirer: Financial institution (or its agent) which
on this International Standard are encouraged to
investigate the possibility of applying the most recent acquires from the card acceptor the data relating to
editions of the standards indicated below. Members the transaction and initiates that data into an
of IEC and IS0 maintain registers of currently valid interchange system. The acquirer remains unchanged
International Standards. throughout the transaction.
IS0 3166: 1988, Codes for the representation of names
3.2 advice: A message where the sender notifies the
of countries.
receiver of an activity that has been taken, requiring
no approval but requiring a response.
IS0 4217:1990, Codes for the representation of
currencies and funds.
IS0 8583 : 1993 (E)
r guarantee
33 authorization: The approval o of funds 3.18 message: A set of data elements used to
uirer (see 4. 1.3.1). exchange information between institutions (or their
give n by the card issuer to the acq
agents). No communications (header/trailer, protocol,
or character code) or security implications are
3.4 authorizing agent: An institution that acts on
assumed or identified.
behalf of and with the authority of the card issuer.
3.19 message class: The set of messages which
3.5 bit map: A series of 64 bits used to identify the
describes the specific activit ies bein g performe d.
presence (denoted by 1) or absence (denoted by 0) of
each data element in a message (see 4.2).
3.20 message function: The identification of the
purpose of a message and the activity involved.
36 card acceptor: Party accepting the card and
pie senting transacti on data to an acqu irer.
3.21 notification: A message where the sender
notifies the receiver of an activity taken, requiring no
3.7 cardholder: Customer associated with the
approval or response.
primary account number requesting the transaction
from the card acceptor.
3.22 payment: A movement of funds from a cardholder
account to another party, e.g., a utility bill payment.
3.8 (card) issuer: Financial institution (or its agent)
which issues the financial transaction card to the
cardholder. The card issuer remains unchanged
3.23 point of service: Card acceptor locat ion wh ere
throughout a transaction.
the cardholder agrees the transaction takes place.
3.9 chargeback: A transaction from the card issuer to
3.24 receiving institution: Institution within a
the acquirer used to partially or completely reverse a
transaction flow that receives a message before it
previously completed financial transaction (see
reaches the final destination (see 4.4.4).
4.1.3.5).
3.25 reconciliation: An exchange of messages between
3.10 credit transaction: A claim for funds by the
two institutions (acquirer, card issuer or their agents)
cardholder for the credit of his account. At the same
to reach agreement on financial totals (see 4.1.3.6).
time it provides details of funds acknowledged as
payable by the acquirer (and/or the card acceptor) to
3.26 registration authority: Entity under the
the card issuer.
authority of the IS0 Council designated to allocate
institution identification codes and maintain the
3.11 debit transaction: An approval by the
register of those codes.
cardholder of the debit to his account. At the same
time it provides a claim of funds made by the acquirer
3.27 replacement authorization: An authorization
(and/or the card acceptor) against the card issuer.
used when a previous authorization was approved
and a subsequent authorization is required because
3.12 financial transaction: A transaction from the
the amount, transaction is now different from the
acquirer to the card issuer containing all the
originally approved amount (see 4.1.3.1).
necessary data elements for authorization, posting
and reconciliation (see 4.1.3.2).
3.28 representment: A financial transaction
originated by an acquirer to partially or wholly
3.13 file action: A transaction used to add, change,
recover funds charged back to the acquirer by a card
delete or replace a file or a record (see 4.1.3.3).
issuer in a chargeback (see 4.1.3.2).
3.14 forwarding institution: Institution within a
3.29 request: A message where the sender informs
transaction flow that sends a message forward from
the receiver that a transaction is in progress and a
the originating institution (see 4.4.4).
response is required to complete the activity.
An authorization transaction that
3.15 inquiry:
3.30 resubmission: The reentry of a request message
requests information.
which was previously denied or rejected (see 4.1.3.1
and 4.1.3.2).
3.16 institution identification code: Unique number
assigned to an institution participating in financial card
3.31 reversal: A transaction from the acquirer to the
originated message interchange (see 4.4.4and 4.4.16).
card issuer informing the card issuer that the
previously initiated transaction cannot be processed
3.17 maintenance agency: Entity under the authority
as instructed, i.e., is undeliverable, unprocessed or
of the IS0 Council responsible for maintaining the list
cancelled by the receiver (see 4.1.3.4).
of codes within this International Standard.
IS0 8583 : 1993 (El
4.1 .l Message type identifier structure
3.32 settlement: A transfer of funds to complete one
r
or more prior transactions made, subject to final
The message type identifier is a four-digit numeric
accounting.
field identifying each message version number,
message class, message function and transaction
3.33 settlement institution: Financial institution (or
originator. Every message shall begin with a message
its agent) at which the accounts are held by the
type identifier. Version numbers shall not be assigned
parties settling. This institution, acting on information
as the result of editorial or code list changes.
provided by the parties, transfers the appropriate
funds between the accounts.
First Position -Version Number
0 - IS0 8583:1987
3.34 supplementary authorization: An authorization
1 - IS0 8583:1993
used when a previous authorization was approved
2-7 - reserved for IS0 use
and one or more subsequent authorizations are
8- reserved for national use
required for additional amounts (see 4.1.3.1).
9- reserved for private use
3.35 transaction: One or more related messages
Where the first position is 1, the second through
within the same message class designed to complete
fourth posit ions shall be defined as follows:
(insofar as this is possible) the intention of the sender
of the original message. Second Position - Message Class
reserved for IS0 use
O-
3.36 transaction destination institution: The final
authorization
l-
institution receiving the request, advice or notification
- financial
in a transaction. The transaction
message
3 - file action
destination remains unchanged throughout the
4- reversaI/chargeback
transaction.
reconciliation
5-
6- administrative
3.37 transaction originator institution: The
7 -fee collection
institution initiating the request, advice or notification
message in a transaction. The transaction originator
8- network management
remains unchanged throughout the transaction,
reserved for IS0 use
9 -
- Message Function
Third Position
3.38 transfer: The movement of funds by a
0 - request
cardholder from one of its accounts to another of the
cardholder’s accounts both of which are held by the
1 -request response
same financial institution.
advice
2-
advice response
3-
3.39 version: A description of interchange message
4- notification
between different
formats that distinguishes
5-9 - reserved for IS0 use
arrangements of data elements within bit maps (i.e.,
where the data elements are added, deleted or their
Fourth Position -Transaction Originator
meaning, position or format changes or the message
0 - acquirer
flows are modified) resulting from revisions of this
1 - acquirer repeat
’ standard (see 4.1.1).
-card issuer
-card issuer repeat
other
4-
4 Message structure
5 -other repeat
6-9 - reserved for IS0 use
4.1 General
identified in this International
Each message 4.1.2 Message Repeats
Standard shall be constructed in the following
In 4.1.3, whenever a repeat message is identified, that
sequence: message type identifier, (see 4.1.1), one
repeat message shall be identical to its original
or two bit maps (see 4.2) and a series of data
message with the exception of the message type
elements in the order of the bit map representation
identifier and, if necessary, date and time,
(see 4.3). Clause 5 shows the circumstances when a
transmission and the message authentication code
message shall (or may) be sent, and the relationship
data elements.
between messages.
e) Authorization notification messages shall be
4.1.3 Message Type Identifier Descriptions
used to inform the card issuer of an authorization
Table.6 identifies the message types supported for
transaction which has completed at the point of
each message class. Each of the following message
service. There is no response message to an
classes support a particular activity:
authorization notification message.
4.1.3.1 Authorization message class
f) The function code data element shall be used to
indicate the type of authorization required (see table 1)
An authorization is an approval or guarantee of funds
and whether the amount, transaction is accurate or
given by the card issuer to the acquirer. Authorization
estimated. If the final amount, transaction is
messages are not intended to permit the application
available the amount, transaction shall be an
of the approved transaction amount to the
accurate amount. If the final amount, transaction
cardholder’s account for billing or posting.
cannot be determined until later, the amount,
transaction shall be an estimated amount.
The following applies to all authorizations:
g) The following types of authorizations are
a) Authorization request messages shall be used
defined:
when the transaction cannot complete at the point of
service until the response message is received
i) Original authorization - the first or only
indicating the action to be taken. The use of an
authorization used.
authorization request message does not imply that the
ii) Replacement authorization - an authorization
cardholder is present (e.g. telephone or mail order).
used when a previous authorization was
b) An authorization request response message shall
approved and a subsequent authorization is
be sent in response to an authorization request
required to replace the previously authorized
message. Itindicates the approval or guarantee of
amount because the amount of the transaction is
funds or the action to be taken as specified in the
now greater or less.
action code data element.
iii) Resubmission authorization - an
c) Authorization advice messages shall be used to inform
authorization used to reenter a previous
the card issuer of an authorization transaction which
authorization that was denied or rejected.
has completed at the point of service.
iv) authorization - an
Supplementary
d) An authorization advice response message shall
authorization used when one or more previous
be sent in response to an authorization advice
authorizations were approved and a further
An authorization advice response
message.
authorization is required for an additional
message indicates if the card issuer accepts or
amount (see table 1).
rejects the transfer of financial liability.
Table 1 - Amounts in types of authorization messages
In request, advice and notification messages:
T
Authorization type Function code Amount, transaction Original amount, transaction
ma
original 100,101 transaction amount
102,103 new amount originally authorized amount
replacement
--
resubmission 104,105 transaction amount
sum of previous approvals, if
supplementary 1 106,107 additional amount
I I
I I
available
I
In response messages:
.
Original amount, transaction
Authorization type Function code Amount, transaction
L
a- mm
full approval transaction amount
we
part;al approval approved amount originally requested amount
, I zero originally requested amount
decline/reject , --
I
I I
approval or guarantee of funds or the action to be
h) The following types of authorization decisions
taken as specified in the action code data element.
are defined:
i) Full approval - an authorization where the
c) Financial advice messages shall be used to
response from the card issuer indicates approval
inform the card issuer of a financial transaction
of the requested amount.
which has completed at the point of service.
ii) Partial approval - an authorization where the
d) A financial advice response message shall be
response from the card issuer indicates approval
sent in response to a financial advice message. A
of an amount less than the originally requested
financial advice response message indicates if the
amount (see table 1).
card issuer accepts or rejects the transfer of
financial liability.
iii) Declined or rejected - an authorization
where the request for approval is declined or the
e) Financial notification messages shall be used to
authorization request or advice message is
inform the card issuer of a financial transaction
rejected (see table 1).
which has completed at the point of service. There is
no response message to a financial notification
Table 1 identifies the usage of amount, transaction
message.
and original amount, transaction within these
authorization message types.
f) The function code shall be used to indicate the
type of financial transaction and whether the
amount, transaction is the same or different from
any previously authorized amount (see table 2).
4.1.3.2 Financial message class
g) The following types of financial transactions are
A financial transaction permits the application of the
defined:
approved transaction amount to the cardholder’s
account for billing or posting.
i) Original - first or only financial transaction
used.
The following applies to all financial transactions:
ii) Previously authorized - a financial
a) Financial request messages shall be used when
transaction used when an authorization was
the transaction cannot complete at the point of
previously approved (see table 2).
service until the response message is received
iii) Resubmission - a financial transaction used
indicating the action to be taken. The use of a
to reenter a previous financial transaction that
financial request message does not imply that the
was denied or rejected (see table 2).
cardholder is present, (e.g. telephone or mail order).
iv) Representment - a financial transaction
b) A financial request response message shall be
originated by an acquirer to partially or wholly
sent in response to a financial request message. A
recover funds charged back to the acquirer by a
financial request response message indicates the
card issuer in a chargeback (see table 2).
Table 2 -Amounts in types of financial transaction messages
In request, advice and notification messages:
Financial type Function cod2 Amount, transaction Original amount, transaction
I I I I I
--
original 200 transaction amount
201,202 new amount originally authorized amount
previously
authorized
transaction amount
resubmission 203,204
representment 205,2@6,207 transaction amount amount of chargeback
In response messages:
.
Function code Amount, transaction Original amount, transaction
Financial type
ww -w
transaction amount
full approval
-w
partial approval approved amount originally requested amount
Be
decline/reject zero originally requested amount
5.
IS0 8583 : 1993 (E)
d) A reversal advice response message shall be sent
h) The following types of financial transaction
to a reversal advice message. A reversal advice shall
decisions are defined:
not be declined by the card issuer, except for
i) Full approval - a financial transaction where
specific reasons as defined in clause A. 1.
the response from the card issuer indicates
approval of the originally requested amount (see e) A reversal shall not be reversed.
table 2).
f) The processing code in a reversal advice or
ii) Partial approval - a financial transaction
notification shall be the same as presented in the
where the response from the card issuer
original message. If the original transaction was a
indicates approval of an amount less than the
debit, the reversal also indicates debit; if the original
originally requested amount (see table 2).
transaction was a credit, the reversal also indicates
a credit.
iii) Declined or rejected - a financial transaction
where the request for approval is declined or the
Table 3 shows the use of amounts in reversal
financial request or advice message is rejected
messages:
(see table 2).
Table 3 -Amounts in reversal messages
Table 2 identifies the usage of amount, transaction
and original amount, transaction within these
financial message types.
, -.
Original
Type of Amount,
4.1.3.3 File action message class
reversal transaction amount,
A file action message shall be used to add, change, transaction
delete or replace a file or record. In addition, file action
--
amount
full
messages may be used to inquire into a file or perform
reversed
card administration (e.g., report lost or stolen cards).
The data record data element shall be used to convey
specific file action record or file information.
4.1.3.4 Reversal message class
A reversal shall be used to partially or completely
II
nullify the effects of a previous financial or
authorization transaction. All reversals shall use the
14xx message series.
g) Only 1 lxx or 12xx transactions shall be reversed.
A reversal shall use the advice or notification
h) Table 4 shows 12xx financial transactions that
messages since the activity has already occurred. The
are not reversals :
following applies to all reversals:
Table 4 - Financial transactions
a) A reversal advice or notification shall be initiated
by an acquirer. Message reason codes are used to
indicate the reason for the reversal (see clause A.7).
I I
It I Irl
b) The amount, transaction data element in a
Function Processing Function
reversal advice or notification shall contain the
code code
II I I II
amount to be reversed and shall be less than or
equal to the original amount as shown in table 3. adjustment 02,22 200
I I II
II
return 20 200
c) Whenever the acquirer times out waiting for a
response to an authorization or financial transaction
. I representment 205, 206, 207
request or advice, a reversal advice or notification of
the transaction shall be sent (see 5.2.12).

4.1.3.5 Chargeback message class charged back. If the original transaction was a
debit, the chargeback shall also indicate a debit.
A chargeback shall be used to partially or completely
If the original transaction was a credit, the
nullify a previous 12xx financial transaction. All
chargeback shall also indicate a credit.
chargebacks shall use the 14xx message series.
ii) to cancel, either partially or completely, a
A chargeback shall be an advice or notification as the previous chargeback that was submitted in error,
activity has already occurred. the card issuer shall initiate a subsequent
chargeback containing
one of the two
The following applies to all chargebacks:
adjustment processing codes. If the original
transaction was a debit, this subsequent
a) A chargeback advice or notification shall only be
chargeback shall indicate a credit. If the original
initiated by the card issuer. It shall be used when the
transaction was a credit, this subsequent
card issuer determines that a customer dispute
chargeback shall indicate a debit.
exists, or that an error or a violation of rules has been
f) If the transaction that is being charged back
committed. Message reason codes are used to indicate
requires a response, this response message shall be
the reason for the chargeback (see clause A.7).
sent before the chargeback is generated.
b) A chargeback advice or notification shall be
g) A card issuer may charge back an original
generated only if the original transaction had
transaction plus any subsequent representment
financial impact on the cardholder’s net position. A
submitted by the acquirer. A separate chargeback
chargeback shall not be used to cancel a balance
message shall be used for each.
account transfer or an authorization
inquiry,
transaction.
h) This International Standard specifies no limits on
the timeframe or the number of chargebacks and
c) A chargeback advice response shall be sent in
representments that may be exchanged between an
response to a chargeback advice message. A
acquirer and card issuer.
chargeback advice shall not be declined by the
receiver except for specific reasons as defined in
clause A.1 although the original transaction may be
4.1.3.6 Reconciliation message class
represented by the acquirer.
A reconciliation transaction provides financial totals
d) The amount, transaction data element in a
between one acquirer and one card issuer. The
chargeback shall be the amount to be charged back
following applies to all reconciliation messages:
and shall be less than or equal to the original
amount, transaction as shown in table 5 following:
a) Reconciliation request messages request the
reconciliation totals (number and value).
Table 5 -Amounts in charge back messages
b) A reconciliation request response message shall
be sent in response to a reconciliation request
message. A reconciliation request response
Type of Amount, Original amount,
message shall contain the requested totals, if
chargeback transaction transaction
available. The totals contained in a reconciliation
request response message shall be used to indicate
full amount charged
-w
the originating institution’s position as either
back
acquirer or card issuer (but not both) as defined by
partial amount charged original the message type identifier.
back transaction
c) Reconciliation request response messages shall
amount
indicate one of the following results:
i) Totals provided - all amounts and number
data elements shall be returned with the values
from the institution sending the reconciliation
e) The processing code in a chargeback may be
request response message.
used to indicate an adjustment where the card
issuer corrects a chargeback, partially or
ii) Totals not available - all amount and number
completely, that was submitted in error. All card
data elements shall be returned with zero values.
issuer initiated adjustments are chargeback (14~~)
transactions. The processing code in a chargeback
d) Reconciliation advice messages request the
may differ from the value in the original
confirmation of totals (number and value). The
transaction.The processing code used in a
totals contained in a reconciliation advice message
chargeback shall be selected as follows:
indicates an originating institution’s position as
either an acquirer or card issuer (but not both) as
i) to charge back a 12xx financial transaction, the
defined by the message type identifier.
chargeback shall contain the same processing
code value as the transaction that is being
IS0 8583 : 1993 (E)
I) Reconciliation in multiple currencies shall use a
e) A reconciliation advice response message shall
separate reconciliation transaction for each
be sent in response to a reconciliation advice
currency.
message.
advice response m essages shall
f) Reconciliation
4.1.3.7 Administrative message class
18 following results:
indicate one of th
Administrative messages shall be used when two
i) Reconciled, in balance - only the amount, net
institutions have identified a need for the exchange of
reconciliation data element shall be returned in
information e.g., retrieval requests.
the reconciliation advice response message.
4.1.3.8 Fee collection message class
ii) Reconciled, out of balance - all amount and
number data elements shall be returned with the
Fee collection messages shall be used to collect or
sending the
values from the institution
disburse miscellaneous service fees. All fee collection
reconciliation advice response message.
messages shall use the 17xx messages series.
iii) Totals not available-all amount and number
The following applies to all fee collection messages:
data elements shall be returned with zero values.
a) Fee collection messages may be in either directi on;
g) Reconciliation notification messages shall be
acquirer to card issuer or card issu er to acquirer.
used to provide totals (number and value). A
response message shall not be sent.
b) A fee collection message shall not be declined by
the receiver except for specific reasons as defined in
h) Two types of reconciliation transactions are
clause A. 1.
defined:
i) A checkpoint reconciliation transaction shall be c) Fee collection messages have a financial impact
and affect reconciliation totals (see table 11). They
indicated by the function code “501” or “503”. A
reconciliation period shall be shall not affect a cardholder account.
checkpoint
identified with the reconciliation indicator. The
d) To cancel, either partially or completely, a
date, reconciliation remains unchanged in a
previous fee collection transaction that was
checkpoint reconciliation.
submitted in error, a subsequent fee collection
ii) A final reconciliation shall be indicated by the transaction shall be sent using function code 701.
function code “500” or “502”. A final
reconciliation period shall be identified with the
4.1.3.9 Network management message class
date, reconciliation. A final reconciliation period
contain number of checkpoint Network management messages shall be used to
may any
control the system security and operating condition of
reconciliation periods.
the interchange network and may be initiated by any
The final reconciliation amounts shall be the sum
interchanging The types of network
PaflY.
of all the financial amounts from the individual
management messages are:
transactions identified with the same date,
reconciliation. The final reconciliation counts
a) system condition messa
...

NORME
ISO
INTERNATIONALE
Deuxiéme édition
1993-12-15
Messages initiés par carte de
- Spécifications
transaction financière
d’échange de messages
Financial transaction tard originated messages - Interchange message
specifications
Numéro de référence
ISO 8583: 1993(F)
ISO 8583 : 1993 (F)
Sommaire
Page
Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
V
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 Domaine d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Références normatives . . . . . . . . . . . . . . . . . . . . .*.*.*. 1
3 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*. 1
4 Structure des messages . 3
4.1 Généralités .
......................................... 14
4.2 Topogrammes binaires (bit maps)
4.3 Répertoire des éléments d’information . 29
4.4 Les éléments d’information . 38
5 Messages et flux de transactions . 43
5.1 Généralités . 43
5.2 Diagrammes de flux des messages . 43
5.3 Diagrammes de flux des transactions . 52
Rapprochement des messages et des transactions . 54
6.1 Généralités . 54
6.2 Rapprochement de message . 54
6.3 Rapprochement de transaction . 54
7 Agence de maintenance des codes et autorité d’enregistre-
ment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1 Maintenance des codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Codes ISO 8583 d’identification des organismes . . . . . . . . . . . . . . . . .
7.3 Tous les autres codes ISO 8583 . . . . . . . . .I. 55
....... 55
8 Conseils d’utilisation de la présente Norme internationale
8.1 Types de message supplémentaires . 55
8.2 Éléments d’information supplémentaires . 55
......... 55
8.3 Éléments d’information obligatoires et conditionnels
....... 55
8.4 Introduction involontaire de caractères de commande
0 ISO 1993
Droits de reproduction r6serv6s. Aucune partie de cette publication ne peut être reproduite ni
utilisée sous quelque forme que ce soit et par aucun pro&& 6lectronique ou mkanique, y
compris la photocopie et les microfilms, sans l’accord 6crit de I’editeur.
Organisation internationale de normalisation
Case postale 56 l CH-121 1 Gen&ve 20 l Suisse
Imprime en Suisse
ii
ISO 8583 : 1993 (F)
Figures
Topogrammes binaires (bit maps) . 14
.............................................................. 53
2 Exemple de consolidation
Tableaux
1 Montants dans les types de messages d’autorisation . 4
Montants dans les types de messages de transaction financiere 5
3 Montants dans les messages de redressement . 6
Transactions financiéres . 6
5 Montants dans les messages de rejet .
6 Identificateurs du type de messages (ITM) . 9
7A Topogrammes binaires (bit maps) (ordre numerique) .
Topogrammes binaires (bit maps) (par type de message) . 20
7B
Conditions utilisées dans le tableau 78 . 28
........................................ 30
9 Répertoire des éléments d’information
Utilisation des codes d’identification d’organisme . 38
11 Calcul de consolidation .
Annexes
.............................................................................. 56
A Listes des codes
.................................................................................... 57
A.1 Codes action
Codes des types de montants . 59
A.2
Codes de période d’autorisation . 60
A.3
....................................... 60
A.4 Codes d’activité de l’accepteur de carte
A.4.1 Codes d’activité de l’accepteur de carte (par ordre numérique) .
A.4.2 Codes d’activité de l’accepteur de carte (par ordre alphabéti-
..................................................................................................
que)
A.5 Codes types de frais .
A.6 Codes de fonctions . 70
A.7 Codes de raisons de messages . 72
A.8 Codes de données de point de service . 75
Codes de traitement . 78
A.9
Guide de conversion . 80
B
Généralités .
B.1
................................................................................................
Objet
B.2 81
Différences entre leséditions de 1987 et de 1993 de I’ISO 8583. .
B.3
B.3.1 Généralités . 81
B.3.2 Définitions . 82
Ajouts . 82
B.3.2.1
.................................................................................. 82
B.3.2.2 Changements
................................................................................... 83
B.3.2.3 Suppressions
ISO 8583 : 1993 (F)
Structure des messages . 83
B.3.3
Types de messages .
B.3.4 83
8.3.5 Éléments de données . 91
B.3.5.1 Ajouts . 91
B.3.5.2 Changements . 92
B.3.5.3 Suppressions . 94
B.3.5.4 Comparaison du code raisons de messages et gestion et
fonction . 94
B.3.5.5 Comparaison des codes de données de points de service . 98
Utilisation des éléments de données
B.3.6 . 100
Flux des messages .
B.3.7 115
B.3.7.1 Messages d’autorisation . 115
B.3.7.2 Messages financiers . 115
B.3.7.3 Messages de gestion de fichier .
Messages de redressement
B.3.7.4 . 115
B.3.7.5 Messages de rejet . 115
B.3.7.6 Messages de réajustement . 116
B.3.7.7 Messages administratifs . 116
B.3.7.8 Messages de recouvrement de frais . 116
B.3.7.9 Messages de gestion de réseau . 116
B.3.7.10 Flux des messages d’exception . 117
Autres avis .
B.4 118
B.4.1 Usage des éléments de données de montants . . . . . . . . . . . . . . . . . . . . . . . . 118
B.4.1.1 Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
B.4.1.2 Autorisations . . . . . . . . .I. 118
B.4.1.3 Transactions financières . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*. 119
B.4.1.4 Redressements .I.I. 119
B.4.1.5 Rejets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
B.4.2 Traitement de réajustement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.4.2.1 120
Cumuls
B.4.2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*. 120
Recouvrement des frais
B.4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .* 121
B.4.4 Usage des éléments de données montants de frais . . . . . . . . . . . . . . . 124
Tableaux
Comparaison des classes de messages . . . . . .*.I.
B.l 84
B.2 Code de mise à jour de fichier (1987) comparé au code fonc-
tion (1993) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*. 94
Code d’information de gestion de réseau (1987) comparé au
B.3
code fonction (1993)
. . . . . . . . . . . . . . . . . . . .*. 95
B.4 Code réponses (1987) comparé au code raisons des messa-
ges et au code gestion (1993) I.,.,
B.5 Code règlement (1987) comparé au code gestion (1993) . . . . . . . 98
B.6 Code de saisie du PIN point de service (1987) comparé aux
données de point de service (1993) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Code d’état du point de service (1987) comparé aux données
B.7
du point de service (1993)
. . . . . . . . .I. 99
B.8 Mode d’entrée au point de service (1987) comparé avec les
donnees du point de service (1993) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Éléments de données par classe de message . . . . . . . . . . . . . . . . . . . . . . ,.
B.9 101
B.10 Exemples de traitement de réajustement ,.,,. 122
Formulaires de demande de codes d’identification d’orga-
C
nisme et de tous les autres codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
iv
ISO 8583 : 1993 (FI
Avant-propos
L’ISO (Organisation internationale de normalisation) est une féderation mon-
diale d’organismes nationaux de normalisation (comites membres de I’ISO).
L’élaboration des Normes internationales est en general confiee aux comités
techniques de I’ISO. Chaque comite membre intéresse par une étude a le droit
de faire partie du comité technique crée à cet effet. Les organisations internatio-
nales, gouvernementales et non gouvernementales, en liaison avec I’ISO pattici-
pent également aux travaux. L’ISO collabore étroitement avec la Commission
électrotechnique internationale (CEI) en ce qui concerne la normalisation Blec-
trotechnique.
Les projets de Normes internationales adoptés par les comités techniques sont
soumis aux comités membres pour vote. Leur publication comme Normes inter-
nationales requiert l’approbation de 75 % au moins des comités membres
votants.
La Norme internationale ISO 8583 a été élaborée par le comité technique ISOFC 68,
Banque et services financiers liés aux opérations bancaires, sous-comit& SC 6,
Cartes de transactions financières, supports et opérations relatifs a celles-ci.
Cette deuxième édition annule et remplace la premiére Édition (ISO 8583:1987),
qui a fait l’objet d’une révision technique.
L’annexe A fait partie intégrante de la présente Norme internationale. Les
annexes B et C sont données uniquement 21 titre d’information.

SO 8583 : 1993 (F)
Introduction
Les services du secteur financier comprennent l’échange de messages électroni-
ques concernant des transactions financières. Les accords portant sur les spécifi-
cations des applications sont généralement pris dans un cadre privé. La présente
Norme internationale est destinée à être une spécification d’interface permettant
l’échange de messages entre des systèmes adoptant différentes spécifications
d’application. Les spécifications d’application peuvent demeurer au niveau pri-
vé. Les concepteurs de ces applications sont complètement libres au niveau de
la conception dans la mesure où ils respectent une contrainte globale, à savoir
que les messages doivent être convertibles en ce format d’interface, pour per-
mettre les échanges internationaux.
La présente Norme internationale introduit le concept de numéro de version de
message pour faire la distinction entre les messages qui sont conformes à cette
édition ou à celles qui suivront, et ceux qui sont conformes à l’édition de 1987.
La présente Norme internationale utilise un concept appelé topogramme binaire
(bit map), par lequel chaque élément d’information se voit attribuer un indica-
teur de position dans une zone de contrôle ou topogramme binaire. La présence
d’un élément d’information dans un message spécifique est indiquée par un
«un» dans la position assignée ; l’absence d’un élément d’information est indi-
quée par un «zéro)) dans la position assignée.
La représentation des données utilisée dans les systèmes individuels est sou-
mise aux relations commerciales entre les parties contractantes à chaque sys-
tème. Les formats de messages prescrits dans la présente Norme internationale
sont conçus pour assurer I’interopérabilité entre les systèmes conformes à la
présente Norme internationale.
vi
NORME INTERNATIONALE SO 8583 : 1993 (F)
Messages initiés par carte de transaction financière -
Spécifications d’échange de messages
ISO 4909: 1987, Cartes bancaires - Zone magnetique
1 Domaine d’application
- Contenu en données de la piste 3.
La présente Norme internationale aborde les aspects ISO 7372:1986, Échange de données dans le com-
suivants : mefce - Répertoire d’éléments de données commer-
ciales (Ratification du CEENU/REDC, sections 7,2,3,4
a) Spécifications d’échange de messages
et 9).
La présente Norme internationale définit une interface
ISO 7810: 1985, Cartes d’identification - Caracteristi-
commune par laquelle les acquéreurs et émetteurs
ques physiques.
de carte peuvent échanger des transactions finan-
ISO 7812:1987, Cartes d’identification - Systeme de
cières initiées par carte. Elle précise la structure du
numérotation et procédure d’enregistrement pour les
message, son format et son contenu, les éléments
identificateurs d’émetteur.
d’information et les valeurs des éléments d’infor-
mation. La méthode par laquelle se fait le règle-
ISO 7813:1990, Cartes d’identification - Cartes de
ment n’est pas du domaine de la présente norme.
transactions financières.
b) Autorité d’enregistrement
ISO 8601:1988, Éléments de données et formats
d’echange - Échange d’information - Representa-
La présente Norme internationale définit un système
tion de /a date et de l’heure.
de numérotation des codes d’identification pour les
organismes financiers qui n’ont pas de numéro
ISO 956401:1991, Banque - Gestion et sécurite du
d’identification d’organisme selon I’ISO 7812. Elle
numéro d’identification personnel - Partie 7 : Princi-
précise aussi les procédures utilisées pour I’enregis-
pes et techniques de protection des PIN.
trement des codes d’identification des organismes.
ISO 9807: 1991, Banque et services financiers lies aux
c) Agence de maintenance
opérations bancaires - Spécifications liees à /‘au-
thentification des messages (service aux particuliers).
La présente Norme internationale établit des procé-
dures pour une agence de maintenance des codes
ISO 10202-l : 199 1, Cartes de transactions financières
utilisés dans la présente norme, les méthodes de
- Architecture de sécurité des systèmes de transac-
demande de codes et les procédures d’obtention
tions financières utilisant des cartes a circuits inté-
des listes de codes.
grés - Partie 7 : Cycle de vie des cartes.
2 Références normatives
3 Définitions
Les normes suivantes contiennent des dispositions
Pour les besoins de la présente Norme internationale,
qui, par suite de la référence qui en est faite, consti-
les définitions suivantes s’appliquent .
tuent des dispositions valables pour la présente
Norme internationale. Au moment de la publication,
3.1 acquéreur: Organisme financier (ou son agent)
les éditions indiquées étaient en vigueur. Toute
qui reçoit de l’accepteur de carte les donnees finan-
norme est sujette à révision et les parties prenantes
cières relatives à une transaction et qui introduit ces
des accords fondés sur la présente Norme internatio-
données dans un système d’échange. L’acquereur
nale sont invitées à rechercher la possibilité d’appli-
reste inchangé pendant toute la transaction.
quer les éditions les plus récentes des normes
indiquees ci-après. Les membres de la CEI et de I’ISO
3.2 avis: Message dans lequel l’expéditeur notifie au
possèdent le registre des Normes internationales en
destinataire qu’une action a été prise qui n’exige pas
vigueur à un moment donné,
d’approbation mais demande une réponse.
ISO 3166:1988, Codes pour /a représentation des
3.3 autorisation: Accord ou garantie pour un mou-
noms de pays.
vement de fonds donne par I’emetteur de la carte à
ISO 4217:1990, Codes pour /a représentation des
l’acquéreur (voir 4.1.3.1).
monnaies et types des fonds.
ISO 8583 : 1993 (FI
anisme qui ag it au 3.18 message: Ensemble de données utilisé pour
3.4 organisme d’autorisation: Org
rdelac arte. échanger des informations entre organismes (ou
nom et sous l’autorité de I’émetteu
leurs agents). Les particularités de communications
(en-tête/fin, protocole, ou codification des caractères)
3.5 topogramme binaire (bit map): Série de 64 bits
ou de sécurité n’entrent pas dans le champ de la pre-
utilisés pour déceler la présence (indiquee par 1) ou
sente norme.
l’absence (indiquee par 0) de chaque élément d’infor-
mation dans un message (voir 4.2).
3.19 classe de message: Ensemble de messages qui
décrit les activités spécifiques prises en compte.
3.6 accepteur de carte: Entité qui accepte la carte et
présente à l’acquéreur les données de la transaction.
3.20 fonction du message: Identification de l’objet
3.7 titulaire de carte: Client associé au numéro de d’un message et de l’action qu’il implique.
compte primaire qui génère une transaction chez
3.21 notification: Message dans lequel l’expéditeur
l’accepteur de carte.
notifie au destinataire l’action prise, ne demandant ni
accord ni réponse.
3.8 émetteur (de carte): Organisme financier (ou son
agent) qui émet la carte de transaction financière au
L’émetteur de carte reste 3.22 paiement: Mouvement de fonds depuis le
titulaire (de carte).
compte d’un titulaire de carte à une autre partie, par
inchangé pendant toute la transaction.
ex. le règlement d’une facture d’électricité.
3.9 rejet: Transaction de l’émetteur de carte vers
3.23 point de service: Lieu où le titulaire de carte
l’acquéreur utilisée pour redresser partiellement ou
donne son accord pour que la transaction se fasse.
complètement une transaction financière déjà exécu-
tée (voir 4.1.3.5).
3.24 organisme récepteur: Dans un flux de transac-
3.10 transaction de crédit: Transaction créditée au tion, organisme qui reçoit un message avant qu’il
n’atteigne sa destination finale (voir 4.4.4).
compte du titulaire de carte. Donne en même temps
à l’émetteur de la carte les détails des fonds recon-
nus comme payables par l’acquéreur (et/ou I’accep- 3.25 consolidation: Échange de messages entre
teur de carte). deux organismes (acquéreur, émetteur de carte ou
leurs agents) pour parvenir à un accord sur les totaux
3.11 transaction de débit: Accord du titulaire de financiers (voir 4.1.3.6).
carte pour que son compte soit débité. Constitue en
même temps une demande de transfert de fonds 3.26 autorité d’enregistrement: Entité sous l’autorité
faite par l’acquéreur (et/ou l’accepteur de carte) à du Conseil ISO destinée à attribuer les codes d’identifica-
l’émetteur de la carte. tion des organismes et tenir le registre de ces codes.
3.12 transaction financière: Transaction de I’acqué- 3.27 autorisation de remplacement: Autorisation
utilisée lorsqu’une autorisation précédente a été
reur vers l’émetteur de carte contenant tous les élé-
ments d’information nécessaires pour l’autorisation, approuvée et qu’une autorisation ultérieure est
la passation d’écritures et la consolidation (voir nécessaire parce que le montant de la transaction est
4.1.3.2). maintenant différent du montant initialement
approuvé (voir 4.1.3.1).
3.13 gestion de fichier: Transaction utilisée pour
ajouter, modifier, supprimer ou remplacer un fichier 3.28 nouvelle présentation: Transaction financière
ou un enregistrement (voir 4.1.3.3). émise par un acquéreur pour recouvrer tout ou partie
des fonds suite à l’émission d’un rejet (voir 4.1.3.2).
3.14 organisme transmetteur: Dans un flux de trans-
action, organisme intermédiaire qui fait suivre un 3.29 demande: Message par lequel l’expéditeur
message provenant de l’organisme initiateur de la informe le destinataire qu’une transaction est en
transaction (voir 4.4.4). cours et qu’une réponse est nécessaire pour complé-
ter l’action.
15 demande de renseignements: Transaction
autorisation qui demande des renseig n ements. 3.30 resoumission: Réintroduction d’un message de
d’
demande qui a précédemment été décliné ou refusé
(voir 4.1.3.1 et 4.1.3.2).
3.16 code d’identification d’organisme: Nombre unique
attribué à un organisme participant à l’échange de mes-
sages initiés par carte financière (voir 4.4.4 et 4.4.16). 3.31 redressement: Transaction de l’acquéreur à
l’émetteur de carte informant ce dernier que la trans-
action émise précédemment ne peut pas être traitée
3.17 agence de maintenance: Entité sous l’autorité
selon les instructions, c’est-à-dire que la distribution ne
du Conseil de I’ISO et responsable de la gestion de la
peut avoir lieu, que le traitement est impossible ou
liste des codes dans le cadre de la présente Norme
qu’il y a annulation par le destinataire (voir 4.1.3.4).
internationale.
ISO 8583 : 1993 (F)
3.32 règlement: Transfert de fonds finalisant une ou 4.1.1 Structure de l’identificateur de type de message
plusieurs transactions antérieures, sous réserve ‘de
L’identificateur de type de message est une zone
vérification comptable finale.
numérique de 4 chiffres identifiant le numéro de ver-
sion du message, la classe de message, sa fonction et
3.33 organisme de règlement: Organisme financier
l’émetteur de la transaction. Chaque message doit
(ou son agent) qui tient les comptes des parties. Cet
commencer par un identificateur du type de mes-
organisme, agissant sur les informations fournies par
sage. Les numeros de version ne doivent pas être
les parties, transfère les fonds appropriés entre les
attribués à la suite de changements editoriaux ou
comptes.
dans la liste de codes.
3.34 autorisation supplémentaire: Autorisation utili-
Première position - Numéro de version
sée quand une autorisation précédente a été approu-
vée et qu’une ou plusieurs autorisations ultérieures 0
- ISO 8583: 1987
sont nécessaires pour des suppléments de montants
1 - ISO 8583: 1993
(voir 4.1.3.1).
2-7 - Réservé pour usage par I’ISO
8 - Réservé pour usage national
3.35 transaction: Un ou plusieurs messages asso-
9 - Réservé pour usage privé
ciés appartenant à la même classe de messages, des-
tinés à résoudre (dans la mesure du possible) le
Lorsque la première position est 1, les positions 2 à 4
besoin de l’expéditeur du message initial.
doivent être définies comme suit :
3.36 organisme destinataire de la transaction: Orga-
Seconde position - Classe de message
nisme final recevant le message de demande, d’avis
- réservé pour usage par I’ISO
ou de notification dans une transaction. Le destina-
1 - autorisation
taire de la transaction reste inchangé pendant toute
celle-ci. 2 - financière
3 - gestion de fichier
3.37 organisme initiateur de la transaction: Orga-
4 - redressement/rejet
nisme émettant le message de demande, avis ou
5 -consolidation
notification dans une transaction. L’initiateur de la
6 - administratif
transaction reste inchangé pendant toute celle-ci.
7 - recouvrement de frais
8 - gestion du réseau
3.38 transfert: Mouvement de fonds demandé par
9 - réservé pour usage par I’ISO
un titulaire de carte, de l’un de ses comptes vers un
autre de ses comptes, les deux comptes étant tenus
Troisième position - Fonction du message
par le même organisme financier.
0 - demande
3.39 version: Description de formats de message
1 - réponse à une demande
d’échange qui fait la distinction entre différentes
2 - avis
positions des éléments d’information dans’ les topo-
3 - réponse a un avis
grammes binaires (bit map) (c’est-à-dire quand des
4- notification ., . .
éléments d’information sont ajoutés, supprimés ou
-5-g - réservé pour usage par l’Lso
bien leur signification, leur position ou leur format
sont changés ou bien le flux du message est modi-
Quatrième position - Initiateur de la transaciion
fié) à la suite des révisions de la présente norme
(voir 4.1 .l).
0 -‘acquéreur I’
1 - acquéreur,, répétition
2- é~metteur de carte.
4 Structure. des ‘messages
‘3 - émetteur de carte’ répétition
4 b autre
- autre, répétition
4.1 Généralités 5
.
6-9 - réservé pour usage par I’ISO
1 .
Chaque message identifié dans la présente Norme
., >
.
internationale doit se ‘présenterdans l’ordre suivant :
4.12 Rbpétitions de message : ‘: , ) _ ’
. ,. ,,
identificateur de type’ de message (voir 4.1.1), un ou
plusieurs topogrammes binaires (bit map) (voir 4.2)
Dans 4.1.3, pour qu’il y ait repétition de message, le
., I
et une série d’éléments d’information dans l’ordre de
message répeté doit être identique au ‘message in$
la représentation du @@ogramme binaire (bit map)
.;, tial, a I.‘exception de l’identificateur du type de mesi
(voir 4.3). L’article 5 montre’ les circonstances dans ,
sage et, si nécessaire, la ‘date et l’heure de la
lesquelles un message doit (ou peut) être envoyé et la
transmission et l’élément d’information du code d’au-
relation entre les messages.
thentification du message (IVIAC).
,
ISO 8583 : 1993 (F)
f) L’élément d’information : code fonction doit être
4.1.3 Descriptions de l’identificateur de type de
utilisé pour indiquer le type d’autorisation requis
message
(voir tableau 1) et si le montant de la transaction est
Le tableau 6 identifie les types de messages pris en
exact ou estime. Si le montant final de la transaction
charge pour chaque classe de message. Chacune des
est disponible, le montant de la transaction sera le
classes de message suivantes prend en charge une acti-
montant exact. Si le montant final de la transaction
vité particuliere :
ne peut être déterminé qu’ulterieurement, le mon-
tant de la transaction doit être le montant estime.
4.1.3.1 Classe de message d’autorisations
‘g) Les types d’autorisation définis sont les suivants :
Une autorisation est un accord ou une garantie
pour un mouvement de fonds, donné par l’émetteur i) Autorisation initiale - Premiere ou seule
autorisation utilisée.
de carte à I’acqu&eur. Les messages d’autorisation
ne sont pas destines 81 permettre l’imputation du
ii) Autorisation de remplacement - autorisation
montant de la transaction approuvee au compte du
utilisée lorsqu’une autorisation precédente a éte
titulaire de carte aux fins de passation d’ecriture.
approuvée et qu’une autorisation ultérieure est
nécessaire pour remplacer le montant prece-
Les points suivants s’appliquent à toutes les autorisations :
demment autorisé parce que le montant de la
transaction est maintenant différent.
a) Les messages de demande d’autorisation doivent
être utilisés lorsque la transaction ne peut pas s’effec-
iii)Autorisation resoumise-autorisation utilisee pour
tuer au point de service jusqu’à réception du mes-
réintroduire une autorisation qui a été rejetée.
sage de réponse indiquant l’action à prendre. L’uti-
iv) Autorisation supplémentaire - autorisation
lisation d’un message de demande d’autorisation
utilisée lorsqu’une ou plusieurs autorisations
n’implique pas que le titulaire de carte soit présent
précédentes ont été approuvees et qu’il faut une
(par ex. téléphone ou vente par correspondance).
autre autorisation pour un montant supplémen-
b) Un message de réponse à une demande d’auto-
taire (voir tableau 1).
risation doit être envoye en réponse à un message
h) Les types de décisions d’autorisation définis sont
de demande d’autorisation. II indique l’accord ou
lessuivants:
l’action à prendre spécifié par le code action.
i) Approbation totale -
accord de l’émetteur de
c)
Les messagesd’avisd’autorisation doivent être utili-
carte sur le montant demandé.
sés pour informer l’émetteur de carte qu’une transaction
d’autorisation a été effectuée au point de service.
ii) Approbation partielle - accord de l’émetteur
d) Un message de réponse à un avis d’autorisation
de carte pour un montant inférieur au montant
doit être envoye en réponse à un message d’avis
demandé à l’origine (voir tableau 1).
d’autorisation. Un message de réponse à un avis
d’autorisation indique si l’émetteur de carte accepte
iii) Refusée ou rejetée - la demande d’accord est
ou refuse le transfert de la responsabilite financière.
refusée ou bien le message d’avis ou la demande
d’autorisation est rejetée (voir tableau 1).
e) Les messages de notification d’autorisation doi-
vent être utilis&s pour informer I’emetteur de carte
Le tableau 1 identifie l’usage des élbments d’informa-
qu’une transaction d’autorisation a 6t6 effectuée au
tion : montant de la transaction et montant initial de
point de service. II n’y a pas de message de réponse
transaction, dans les messages d’autorisation.
à un message de notification d’autorisation.
Tableau 1 - Montants dans les types de messages. d’autorisation
Dans les messages de d.emande, avis et notification :
,
.
Type d’autorisation Code fonction Montant de la transaction Montant initial de la transaction
initiale 100,101 montant de la transaction
I
de remplacement 102,103 nouveau montant montant autorisé initialement
I
resoumise 104,105 montant de la transaction
I
supplémentaire 106,107 montant supplémentaire somme des montants précédemment autorisés
/ 1
Dans les messages de rbponse :
\ I
Type d’sutorkation Code fonction Montant de la transaction Montant initial do la transaction
I 1
approbation totale montant. de la transaction
montant approuvé montant demandé initialement
approbation partielle
déclinékejeté zéro montant demandé initialement
ISO8583:1993(F)
f) Le code fonction doit être utilise pour indiquer le
4.1.3.2 Classe de messages financiers
type de transaction financiere et si le montant de la
Une transaction financière permet l’imputation du
transaction est le même ou s’il est different du
montant de transaction approuvé au compte du
montant autorisé précédemment (voir tableau 2).
titulaire de carte aux fins de passation d’écritures.
g) Les types de transactions financières definis sont
Ce qui suit s’applique à toutes les transactions finan-
les suivants :
cières :
i) Initiale - première ou seule transaction finan-
a) Les messages de demande financière doivent cière utilisée.
être utilises lorsque la transaction ne peut pas
ii) Autorisee précédemment - transaction
être exécutee au point de service jusqu’à récep-
financière utilisée quand une autorisation a été
tion d’un message de réponse indiquant l’action à
approuvée précédemment (voir tableau 2).
prendre. L’utilisation d’un message de demande
financière n’implique pas que le titulaire de carte
iii) Resoumise - transaction financiere utilisée
soit présent (par ex. téléphone ou vente par cor-
pour réintroduire une transaction financiere pré-
respondance).
cédemment déclinée ou refusée (voir tableau 2).
b) Un message de réponse à une demande finan-
iv) Nouvelle présentation - transaction financière
cière doit être envoyé en réponse à un message de
émise par un acquéreur pour recouvrer partiellement
demande financière. Un message de réponse à une
ou totalement des fonds redresses dans un rejet
demande financière indique l’accord ou l’action à
par un émetteur de carte (voir tableau 2).
prendre.
Les types de décisions de transaction financière
h)
c) Les messages d’avis financier doivent être sont lessuivants:
utilisés pour informer l’émetteur de carte qu’une
i) Approbation totale - l’émetteur de carte indi-
transaction financière a été exécutée au point de
que son accord sur le montant demandé initiale-
service.
ment (voir tableau 2).
d) Un message de réponse à avis financier doit être
ii) Approbation partielle - l’émetteur de carte
envoyé en réponse à un message d’avis financier.
indique son accord pour un montant inférieur à
Un message de réponse à un avis financier indique
celui demandé initialement (voir tableau 2).
si l’émetteur de carte accepte ou refuse le transfert
de l’engagement financier. iii) Refusée ou rejetée - la demande d’accord
est refusée ou la demande financière ou le mes-
e) Les messages de notification financière doivent
sage d’avis est rejeté (voir tableau 2).
être utilisés pour informer l’émetteur de carte
qu’une transaction financière a été exécutée au Le tableau 2 identifie l’usage des champs, montant de
point de service. II n’y a pas de message de réponse la transaction et montant initial de la transaction,
à un message de notification financière. dans les messages financiers.
Tableau 2 - Montants dans les types de messages de transaction financière
Dans les messages de demande, avis et notification :
1 Type de transaction financière 1 Code fonction 1 Montant de la transaction 1 Montant initial de la transaction 1
initiale 200 montant de la transaction
I I
autorisée précédemment 201,202 nouveau montant montant autorisé initialement
resoumise 203,204 montant de la transaction
nouvelle présentation 205,206,207 montant de la transaction montant du rejet
Dans les messages de réponse :
Code fonction Montant de la transaction
Type de décisions Montant initial de la transaction
I I I I
approbation totale montant de la transaction
approbation partielle montant approuvé montant demandé initialement
zéro
décliné/rejeté montant demandé initialement
A
ISO 8583 : 1993 (FI
4.1.3.3 Classe de messages de gestion de fichiers Tableau 3 - Montants dans les messages
de redressement
Un message de gestion de fichier doit être utilisé
pour ajouter, changer, supprimer ou remplacer un
Type de Montant de Montant initial de
fichier ou un enregistrement. En outre, les messages
redressement la transaction la transaction
de gestion de fichier peuvent servir à interroger un
fichier ou effectuer la gestion des cartes (par ex.
total montant
diffuser les cartes perdues ou volées). L’élément
redressé
d’information : enregistrement de données doit servir
à véhiculer des enregistrements spécifiques pour partiel
montant montant de
gérer des fichiers ou des informations globales sur redressé la transaction initiale
L
les fichiers.
g) Seules les transactions 1 lxx ou 12xx peuvent
4.1.3.4 Classe de messages de redressement
être redressées.
Un redressement doit servir à annuler partiellement
h) Le tableau 4 décrit des transactions financières
ou complètement les effets d’une transaction
12xx qui ne peuvent pas donner lieu àdes redressements.
financière ou d’une autorisation précédente. Tous les
redressements doivent utiliser la série de messages
14xX.
Tableau 4 -
Transactions financières
,
Un redressement doit utiliser les messages avis ou
notification puisque l’action s’est déjà produite. Les Fonction Code traitement Code fonction
points suivants s’appliquent à tous les redressements :
ajustement 02,22 200
a) Un redressement doit être initié par un acquéreur.
retour 20 200
Les codes raison du message servent à indiquer la
raison du redressement (voir article A.7).
nouvelle
205,206,207
présentation
b) L’élément d’information : montant de la
transaction, dans un redressement doit contenir le
4.1.3.5 Classe de messages de rejet
montant à redresser, et ce montant doit être inférieur
ou égal au montant initial comme le montre le
Un rejet ou une notification ne doit être initialisé(e)
tableau 3.
que par l’émetteur de carte. Tous les rejets doivent
utiliser la série de messages 14xx.
c) Chaque fois que l’acquéreur dépasse le temps
imparti à attendre une réponse à une autorisation,
Un rejet doit être un avis ou une notification puisque
ou à une demande ou un avis de transaction finan-
l’action s’est déjà produite.
cière, un redressement de la transaction doit être
envoyé (voir 5.2.12).
Les points suivants s’appliquent à tous les rejets.
d) Un message réponse avis de redressement doit
a) Un rejet ne peut être initié que par l’émetteur de
être envoyé en réponse à un message avis de
carte. II doit être émis lorsque l’émetteur de carte
redressement. Un avis de redressement ne doit pas
détermine qu’il existe un litige entre client, ou
être rejeté par l’émetteur de carte, sauf pour les rai-
qu’une erreur ou une violation des règles a été
sons précises (voir article A.V.
commise. Les codes raisons des messages sont utili-
e) Un redressement ne peut pas être lui-même
sés pour indiquer la cause du rejet (voir article A.7).
redressé.
b) Un rejet doit être généré uniquement si la trans-
f) Le code traitement dans un redressement doit
action initiale a eu un impact financier sur la posi-
être le même que celui présent dans le message ini-
tion nette du titulaire de carte. Un rejet ne doit pas
tial. Si la transaction initiale était un débit, le
servir à annuler une demande de solde, un transfert
redressement indique lui aussi un débit ; si la trans-
de compte ou une transaction d’autorisation.
action initiale était un crédit, le redressement indi-
c) Un message réponse doit être envoyé en réponse
que lui aussi un crédit.
à un message rejet. Un rejet ne doit pas être refusé
par le destinataire sauf pour les raisons spécifiques
Le tableau 3 montre l’utilisation des montants dans
(voir article A.6), même si la transaction initiale peut
les messages de redressement :
être représentée par l’acquéreur.
lSO8583:1993 (F)
d) L’élément d’information : montant de la transac- a) Les messages de demande de consolidation
tion dans un rejet doit être le montant rejeté, et il demandent les totaux de consolidation (nombre et
valeur).
doit être inférieur ou égal au montant initial de la
transaction, comme le montre le tableau 5 suivant. -
b) Un message de réponse à une demande de
consolidation doit être envoye en repense à un
Tableau 5 - Montants dans les messages de rejet
message de demande de consolidation. Un mes-
I , sage de réponse à une demande de consolidation
Montant initial de doit contenir les totaux demandes, s’ils sont dispo-
Type de rejet Montant de
la transaction nibles. Les totaux contenus dans un message de
la transaction
repense à une demande de consolidation doivent
montant rejeté
total
être utilises pour indiquer si l’organisme initiateur
occupe la position d’acquereur ou d’émetteur de
partiel montant rejeté montant de
carte (mais non les deux) comme le définit I’identi-
la transaction initiale
ficateur de type de message.
c) Les messages de réponse à une demande de
e) Le code traitement dans un rejet peut servir à
consolidation doivent indiquer l’un des resultats
indiquer un ajustement dans lequel l’émetteur de
suivants :
carte corrige un rejet, partiellement ou totalement,
qui a été présenté par erreur. Tous les ajustement
i) Totaux fournis - tous les cléments d’informa-
initiés par l’émetteur de carte sont des transactions
tion montants et nombres doivent être renvoyés
de rejet (1 ~XX). Le code traitement dans un rejet
avec les valeurs par l’organisme envoyant le
peut différer de la valeur de la transaction initiale.
message de réponse à la demande de
Le code traitement utilisé dans un rejet doit être
consolidation.
choisi comme suit :
ii) Totaux non disponibles - tous les elements
i) Pour rejeter une transaction financière 12xx, le
d’information montants et nombres doivent être
rejet doit contenir la même valeur de code trai-
renvoyés avec des valeurs zéro.
tement que la transaction qui est rejetée. Si la
transaction initiale était un débit, le rejet doit lui
d) Les messages d’avis de consolidation deman-
aussi indiquer un débit. Si la transaction initiale
dent la confirmation des totaux (nombre et valeur).
était un crédit, le rejet doit lui aussi indiquer un
Les totaux contenus dans un message d’avis de
crédit.
consolidation indiquent la position de l’organisme
initiateur comme étant soit l’acquéreur soit I’émet-
ii) Pour annuler, soit partiellement soit complè-
teur de carte (mais non les deux) comme le définit
tement, un rejet précédent qui a été présenté
l’identificateur du type de message.
par erreur, l’émetteur de carte doit émettre un
nouveau rejet contenant l’un des deux codes de
e) Un message de réponse à un avis de consolida-
traitement de consolidation. Si la transaction
tion doit être envoyé en réponse à un message
initiale était un débit, ce nouveau rejet doit indi-
d’avis de consolidation.
quer un crédit. Si la transaction initiale était un
f) Le message de réponse à l’avis de consolidation
crédit, ce nouveau rejet doit indiquer un débit.
doit indiquer l’un des résultats suivants :
f) Si la transaction qui est en cours de rejet
demande une réponse, ce message de réponse doit
i) Consolidé, équilibré - seul l’élément d’infor-
être envoyé avant le traitement du rejet.
mation : montant de consolidation net doit être
renvoyé dans le message de réponse a l’avis de
g) Un émetteur de carte peut rejeter un
...

NORME
ISO
INTERNATIONALE
Deuxiéme édition
1993-12-15
Messages initiés par carte de
- Spécifications
transaction financière
d’échange de messages
Financial transaction tard originated messages - Interchange message
specifications
Numéro de référence
ISO 8583: 1993(F)
ISO 8583 : 1993 (F)
Sommaire
Page
Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
V
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 Domaine d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Références normatives . . . . . . . . . . . . . . . . . . . . .*.*.*. 1
3 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*. 1
4 Structure des messages . 3
4.1 Généralités .
......................................... 14
4.2 Topogrammes binaires (bit maps)
4.3 Répertoire des éléments d’information . 29
4.4 Les éléments d’information . 38
5 Messages et flux de transactions . 43
5.1 Généralités . 43
5.2 Diagrammes de flux des messages . 43
5.3 Diagrammes de flux des transactions . 52
Rapprochement des messages et des transactions . 54
6.1 Généralités . 54
6.2 Rapprochement de message . 54
6.3 Rapprochement de transaction . 54
7 Agence de maintenance des codes et autorité d’enregistre-
ment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1 Maintenance des codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Codes ISO 8583 d’identification des organismes . . . . . . . . . . . . . . . . .
7.3 Tous les autres codes ISO 8583 . . . . . . . . .I. 55
....... 55
8 Conseils d’utilisation de la présente Norme internationale
8.1 Types de message supplémentaires . 55
8.2 Éléments d’information supplémentaires . 55
......... 55
8.3 Éléments d’information obligatoires et conditionnels
....... 55
8.4 Introduction involontaire de caractères de commande
0 ISO 1993
Droits de reproduction r6serv6s. Aucune partie de cette publication ne peut être reproduite ni
utilisée sous quelque forme que ce soit et par aucun pro&& 6lectronique ou mkanique, y
compris la photocopie et les microfilms, sans l’accord 6crit de I’editeur.
Organisation internationale de normalisation
Case postale 56 l CH-121 1 Gen&ve 20 l Suisse
Imprime en Suisse
ii
ISO 8583 : 1993 (F)
Figures
Topogrammes binaires (bit maps) . 14
.............................................................. 53
2 Exemple de consolidation
Tableaux
1 Montants dans les types de messages d’autorisation . 4
Montants dans les types de messages de transaction financiere 5
3 Montants dans les messages de redressement . 6
Transactions financiéres . 6
5 Montants dans les messages de rejet .
6 Identificateurs du type de messages (ITM) . 9
7A Topogrammes binaires (bit maps) (ordre numerique) .
Topogrammes binaires (bit maps) (par type de message) . 20
7B
Conditions utilisées dans le tableau 78 . 28
........................................ 30
9 Répertoire des éléments d’information
Utilisation des codes d’identification d’organisme . 38
11 Calcul de consolidation .
Annexes
.............................................................................. 56
A Listes des codes
.................................................................................... 57
A.1 Codes action
Codes des types de montants . 59
A.2
Codes de période d’autorisation . 60
A.3
....................................... 60
A.4 Codes d’activité de l’accepteur de carte
A.4.1 Codes d’activité de l’accepteur de carte (par ordre numérique) .
A.4.2 Codes d’activité de l’accepteur de carte (par ordre alphabéti-
..................................................................................................
que)
A.5 Codes types de frais .
A.6 Codes de fonctions . 70
A.7 Codes de raisons de messages . 72
A.8 Codes de données de point de service . 75
Codes de traitement . 78
A.9
Guide de conversion . 80
B
Généralités .
B.1
................................................................................................
Objet
B.2 81
Différences entre leséditions de 1987 et de 1993 de I’ISO 8583. .
B.3
B.3.1 Généralités . 81
B.3.2 Définitions . 82
Ajouts . 82
B.3.2.1
.................................................................................. 82
B.3.2.2 Changements
................................................................................... 83
B.3.2.3 Suppressions
ISO 8583 : 1993 (F)
Structure des messages . 83
B.3.3
Types de messages .
B.3.4 83
8.3.5 Éléments de données . 91
B.3.5.1 Ajouts . 91
B.3.5.2 Changements . 92
B.3.5.3 Suppressions . 94
B.3.5.4 Comparaison du code raisons de messages et gestion et
fonction . 94
B.3.5.5 Comparaison des codes de données de points de service . 98
Utilisation des éléments de données
B.3.6 . 100
Flux des messages .
B.3.7 115
B.3.7.1 Messages d’autorisation . 115
B.3.7.2 Messages financiers . 115
B.3.7.3 Messages de gestion de fichier .
Messages de redressement
B.3.7.4 . 115
B.3.7.5 Messages de rejet . 115
B.3.7.6 Messages de réajustement . 116
B.3.7.7 Messages administratifs . 116
B.3.7.8 Messages de recouvrement de frais . 116
B.3.7.9 Messages de gestion de réseau . 116
B.3.7.10 Flux des messages d’exception . 117
Autres avis .
B.4 118
B.4.1 Usage des éléments de données de montants . . . . . . . . . . . . . . . . . . . . . . . . 118
B.4.1.1 Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
B.4.1.2 Autorisations . . . . . . . . .I. 118
B.4.1.3 Transactions financières . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*. 119
B.4.1.4 Redressements .I.I. 119
B.4.1.5 Rejets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
B.4.2 Traitement de réajustement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.4.2.1 120
Cumuls
B.4.2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*. 120
Recouvrement des frais
B.4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .* 121
B.4.4 Usage des éléments de données montants de frais . . . . . . . . . . . . . . . 124
Tableaux
Comparaison des classes de messages . . . . . .*.I.
B.l 84
B.2 Code de mise à jour de fichier (1987) comparé au code fonc-
tion (1993) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*. 94
Code d’information de gestion de réseau (1987) comparé au
B.3
code fonction (1993)
. . . . . . . . . . . . . . . . . . . .*. 95
B.4 Code réponses (1987) comparé au code raisons des messa-
ges et au code gestion (1993) I.,.,
B.5 Code règlement (1987) comparé au code gestion (1993) . . . . . . . 98
B.6 Code de saisie du PIN point de service (1987) comparé aux
données de point de service (1993) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Code d’état du point de service (1987) comparé aux données
B.7
du point de service (1993)
. . . . . . . . .I. 99
B.8 Mode d’entrée au point de service (1987) comparé avec les
donnees du point de service (1993) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Éléments de données par classe de message . . . . . . . . . . . . . . . . . . . . . . ,.
B.9 101
B.10 Exemples de traitement de réajustement ,.,,. 122
Formulaires de demande de codes d’identification d’orga-
C
nisme et de tous les autres codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
iv
ISO 8583 : 1993 (FI
Avant-propos
L’ISO (Organisation internationale de normalisation) est une féderation mon-
diale d’organismes nationaux de normalisation (comites membres de I’ISO).
L’élaboration des Normes internationales est en general confiee aux comités
techniques de I’ISO. Chaque comite membre intéresse par une étude a le droit
de faire partie du comité technique crée à cet effet. Les organisations internatio-
nales, gouvernementales et non gouvernementales, en liaison avec I’ISO pattici-
pent également aux travaux. L’ISO collabore étroitement avec la Commission
électrotechnique internationale (CEI) en ce qui concerne la normalisation Blec-
trotechnique.
Les projets de Normes internationales adoptés par les comités techniques sont
soumis aux comités membres pour vote. Leur publication comme Normes inter-
nationales requiert l’approbation de 75 % au moins des comités membres
votants.
La Norme internationale ISO 8583 a été élaborée par le comité technique ISOFC 68,
Banque et services financiers liés aux opérations bancaires, sous-comit& SC 6,
Cartes de transactions financières, supports et opérations relatifs a celles-ci.
Cette deuxième édition annule et remplace la premiére Édition (ISO 8583:1987),
qui a fait l’objet d’une révision technique.
L’annexe A fait partie intégrante de la présente Norme internationale. Les
annexes B et C sont données uniquement 21 titre d’information.

SO 8583 : 1993 (F)
Introduction
Les services du secteur financier comprennent l’échange de messages électroni-
ques concernant des transactions financières. Les accords portant sur les spécifi-
cations des applications sont généralement pris dans un cadre privé. La présente
Norme internationale est destinée à être une spécification d’interface permettant
l’échange de messages entre des systèmes adoptant différentes spécifications
d’application. Les spécifications d’application peuvent demeurer au niveau pri-
vé. Les concepteurs de ces applications sont complètement libres au niveau de
la conception dans la mesure où ils respectent une contrainte globale, à savoir
que les messages doivent être convertibles en ce format d’interface, pour per-
mettre les échanges internationaux.
La présente Norme internationale introduit le concept de numéro de version de
message pour faire la distinction entre les messages qui sont conformes à cette
édition ou à celles qui suivront, et ceux qui sont conformes à l’édition de 1987.
La présente Norme internationale utilise un concept appelé topogramme binaire
(bit map), par lequel chaque élément d’information se voit attribuer un indica-
teur de position dans une zone de contrôle ou topogramme binaire. La présence
d’un élément d’information dans un message spécifique est indiquée par un
«un» dans la position assignée ; l’absence d’un élément d’information est indi-
quée par un «zéro)) dans la position assignée.
La représentation des données utilisée dans les systèmes individuels est sou-
mise aux relations commerciales entre les parties contractantes à chaque sys-
tème. Les formats de messages prescrits dans la présente Norme internationale
sont conçus pour assurer I’interopérabilité entre les systèmes conformes à la
présente Norme internationale.
vi
NORME INTERNATIONALE SO 8583 : 1993 (F)
Messages initiés par carte de transaction financière -
Spécifications d’échange de messages
ISO 4909: 1987, Cartes bancaires - Zone magnetique
1 Domaine d’application
- Contenu en données de la piste 3.
La présente Norme internationale aborde les aspects ISO 7372:1986, Échange de données dans le com-
suivants : mefce - Répertoire d’éléments de données commer-
ciales (Ratification du CEENU/REDC, sections 7,2,3,4
a) Spécifications d’échange de messages
et 9).
La présente Norme internationale définit une interface
ISO 7810: 1985, Cartes d’identification - Caracteristi-
commune par laquelle les acquéreurs et émetteurs
ques physiques.
de carte peuvent échanger des transactions finan-
ISO 7812:1987, Cartes d’identification - Systeme de
cières initiées par carte. Elle précise la structure du
numérotation et procédure d’enregistrement pour les
message, son format et son contenu, les éléments
identificateurs d’émetteur.
d’information et les valeurs des éléments d’infor-
mation. La méthode par laquelle se fait le règle-
ISO 7813:1990, Cartes d’identification - Cartes de
ment n’est pas du domaine de la présente norme.
transactions financières.
b) Autorité d’enregistrement
ISO 8601:1988, Éléments de données et formats
d’echange - Échange d’information - Representa-
La présente Norme internationale définit un système
tion de /a date et de l’heure.
de numérotation des codes d’identification pour les
organismes financiers qui n’ont pas de numéro
ISO 956401:1991, Banque - Gestion et sécurite du
d’identification d’organisme selon I’ISO 7812. Elle
numéro d’identification personnel - Partie 7 : Princi-
précise aussi les procédures utilisées pour I’enregis-
pes et techniques de protection des PIN.
trement des codes d’identification des organismes.
ISO 9807: 1991, Banque et services financiers lies aux
c) Agence de maintenance
opérations bancaires - Spécifications liees à /‘au-
thentification des messages (service aux particuliers).
La présente Norme internationale établit des procé-
dures pour une agence de maintenance des codes
ISO 10202-l : 199 1, Cartes de transactions financières
utilisés dans la présente norme, les méthodes de
- Architecture de sécurité des systèmes de transac-
demande de codes et les procédures d’obtention
tions financières utilisant des cartes a circuits inté-
des listes de codes.
grés - Partie 7 : Cycle de vie des cartes.
2 Références normatives
3 Définitions
Les normes suivantes contiennent des dispositions
Pour les besoins de la présente Norme internationale,
qui, par suite de la référence qui en est faite, consti-
les définitions suivantes s’appliquent .
tuent des dispositions valables pour la présente
Norme internationale. Au moment de la publication,
3.1 acquéreur: Organisme financier (ou son agent)
les éditions indiquées étaient en vigueur. Toute
qui reçoit de l’accepteur de carte les donnees finan-
norme est sujette à révision et les parties prenantes
cières relatives à une transaction et qui introduit ces
des accords fondés sur la présente Norme internatio-
données dans un système d’échange. L’acquereur
nale sont invitées à rechercher la possibilité d’appli-
reste inchangé pendant toute la transaction.
quer les éditions les plus récentes des normes
indiquees ci-après. Les membres de la CEI et de I’ISO
3.2 avis: Message dans lequel l’expéditeur notifie au
possèdent le registre des Normes internationales en
destinataire qu’une action a été prise qui n’exige pas
vigueur à un moment donné,
d’approbation mais demande une réponse.
ISO 3166:1988, Codes pour /a représentation des
3.3 autorisation: Accord ou garantie pour un mou-
noms de pays.
vement de fonds donne par I’emetteur de la carte à
ISO 4217:1990, Codes pour /a représentation des
l’acquéreur (voir 4.1.3.1).
monnaies et types des fonds.
ISO 8583 : 1993 (FI
anisme qui ag it au 3.18 message: Ensemble de données utilisé pour
3.4 organisme d’autorisation: Org
rdelac arte. échanger des informations entre organismes (ou
nom et sous l’autorité de I’émetteu
leurs agents). Les particularités de communications
(en-tête/fin, protocole, ou codification des caractères)
3.5 topogramme binaire (bit map): Série de 64 bits
ou de sécurité n’entrent pas dans le champ de la pre-
utilisés pour déceler la présence (indiquee par 1) ou
sente norme.
l’absence (indiquee par 0) de chaque élément d’infor-
mation dans un message (voir 4.2).
3.19 classe de message: Ensemble de messages qui
décrit les activités spécifiques prises en compte.
3.6 accepteur de carte: Entité qui accepte la carte et
présente à l’acquéreur les données de la transaction.
3.20 fonction du message: Identification de l’objet
3.7 titulaire de carte: Client associé au numéro de d’un message et de l’action qu’il implique.
compte primaire qui génère une transaction chez
3.21 notification: Message dans lequel l’expéditeur
l’accepteur de carte.
notifie au destinataire l’action prise, ne demandant ni
accord ni réponse.
3.8 émetteur (de carte): Organisme financier (ou son
agent) qui émet la carte de transaction financière au
L’émetteur de carte reste 3.22 paiement: Mouvement de fonds depuis le
titulaire (de carte).
compte d’un titulaire de carte à une autre partie, par
inchangé pendant toute la transaction.
ex. le règlement d’une facture d’électricité.
3.9 rejet: Transaction de l’émetteur de carte vers
3.23 point de service: Lieu où le titulaire de carte
l’acquéreur utilisée pour redresser partiellement ou
donne son accord pour que la transaction se fasse.
complètement une transaction financière déjà exécu-
tée (voir 4.1.3.5).
3.24 organisme récepteur: Dans un flux de transac-
3.10 transaction de crédit: Transaction créditée au tion, organisme qui reçoit un message avant qu’il
n’atteigne sa destination finale (voir 4.4.4).
compte du titulaire de carte. Donne en même temps
à l’émetteur de la carte les détails des fonds recon-
nus comme payables par l’acquéreur (et/ou I’accep- 3.25 consolidation: Échange de messages entre
teur de carte). deux organismes (acquéreur, émetteur de carte ou
leurs agents) pour parvenir à un accord sur les totaux
3.11 transaction de débit: Accord du titulaire de financiers (voir 4.1.3.6).
carte pour que son compte soit débité. Constitue en
même temps une demande de transfert de fonds 3.26 autorité d’enregistrement: Entité sous l’autorité
faite par l’acquéreur (et/ou l’accepteur de carte) à du Conseil ISO destinée à attribuer les codes d’identifica-
l’émetteur de la carte. tion des organismes et tenir le registre de ces codes.
3.12 transaction financière: Transaction de I’acqué- 3.27 autorisation de remplacement: Autorisation
utilisée lorsqu’une autorisation précédente a été
reur vers l’émetteur de carte contenant tous les élé-
ments d’information nécessaires pour l’autorisation, approuvée et qu’une autorisation ultérieure est
la passation d’écritures et la consolidation (voir nécessaire parce que le montant de la transaction est
4.1.3.2). maintenant différent du montant initialement
approuvé (voir 4.1.3.1).
3.13 gestion de fichier: Transaction utilisée pour
ajouter, modifier, supprimer ou remplacer un fichier 3.28 nouvelle présentation: Transaction financière
ou un enregistrement (voir 4.1.3.3). émise par un acquéreur pour recouvrer tout ou partie
des fonds suite à l’émission d’un rejet (voir 4.1.3.2).
3.14 organisme transmetteur: Dans un flux de trans-
action, organisme intermédiaire qui fait suivre un 3.29 demande: Message par lequel l’expéditeur
message provenant de l’organisme initiateur de la informe le destinataire qu’une transaction est en
transaction (voir 4.4.4). cours et qu’une réponse est nécessaire pour complé-
ter l’action.
15 demande de renseignements: Transaction
autorisation qui demande des renseig n ements. 3.30 resoumission: Réintroduction d’un message de
d’
demande qui a précédemment été décliné ou refusé
(voir 4.1.3.1 et 4.1.3.2).
3.16 code d’identification d’organisme: Nombre unique
attribué à un organisme participant à l’échange de mes-
sages initiés par carte financière (voir 4.4.4 et 4.4.16). 3.31 redressement: Transaction de l’acquéreur à
l’émetteur de carte informant ce dernier que la trans-
action émise précédemment ne peut pas être traitée
3.17 agence de maintenance: Entité sous l’autorité
selon les instructions, c’est-à-dire que la distribution ne
du Conseil de I’ISO et responsable de la gestion de la
peut avoir lieu, que le traitement est impossible ou
liste des codes dans le cadre de la présente Norme
qu’il y a annulation par le destinataire (voir 4.1.3.4).
internationale.
ISO 8583 : 1993 (F)
3.32 règlement: Transfert de fonds finalisant une ou 4.1.1 Structure de l’identificateur de type de message
plusieurs transactions antérieures, sous réserve ‘de
L’identificateur de type de message est une zone
vérification comptable finale.
numérique de 4 chiffres identifiant le numéro de ver-
sion du message, la classe de message, sa fonction et
3.33 organisme de règlement: Organisme financier
l’émetteur de la transaction. Chaque message doit
(ou son agent) qui tient les comptes des parties. Cet
commencer par un identificateur du type de mes-
organisme, agissant sur les informations fournies par
sage. Les numeros de version ne doivent pas être
les parties, transfère les fonds appropriés entre les
attribués à la suite de changements editoriaux ou
comptes.
dans la liste de codes.
3.34 autorisation supplémentaire: Autorisation utili-
Première position - Numéro de version
sée quand une autorisation précédente a été approu-
vée et qu’une ou plusieurs autorisations ultérieures 0
- ISO 8583: 1987
sont nécessaires pour des suppléments de montants
1 - ISO 8583: 1993
(voir 4.1.3.1).
2-7 - Réservé pour usage par I’ISO
8 - Réservé pour usage national
3.35 transaction: Un ou plusieurs messages asso-
9 - Réservé pour usage privé
ciés appartenant à la même classe de messages, des-
tinés à résoudre (dans la mesure du possible) le
Lorsque la première position est 1, les positions 2 à 4
besoin de l’expéditeur du message initial.
doivent être définies comme suit :
3.36 organisme destinataire de la transaction: Orga-
Seconde position - Classe de message
nisme final recevant le message de demande, d’avis
- réservé pour usage par I’ISO
ou de notification dans une transaction. Le destina-
1 - autorisation
taire de la transaction reste inchangé pendant toute
celle-ci. 2 - financière
3 - gestion de fichier
3.37 organisme initiateur de la transaction: Orga-
4 - redressement/rejet
nisme émettant le message de demande, avis ou
5 -consolidation
notification dans une transaction. L’initiateur de la
6 - administratif
transaction reste inchangé pendant toute celle-ci.
7 - recouvrement de frais
8 - gestion du réseau
3.38 transfert: Mouvement de fonds demandé par
9 - réservé pour usage par I’ISO
un titulaire de carte, de l’un de ses comptes vers un
autre de ses comptes, les deux comptes étant tenus
Troisième position - Fonction du message
par le même organisme financier.
0 - demande
3.39 version: Description de formats de message
1 - réponse à une demande
d’échange qui fait la distinction entre différentes
2 - avis
positions des éléments d’information dans’ les topo-
3 - réponse a un avis
grammes binaires (bit map) (c’est-à-dire quand des
4- notification ., . .
éléments d’information sont ajoutés, supprimés ou
-5-g - réservé pour usage par l’Lso
bien leur signification, leur position ou leur format
sont changés ou bien le flux du message est modi-
Quatrième position - Initiateur de la transaciion
fié) à la suite des révisions de la présente norme
(voir 4.1 .l).
0 -‘acquéreur I’
1 - acquéreur,, répétition
2- é~metteur de carte.
4 Structure. des ‘messages
‘3 - émetteur de carte’ répétition
4 b autre
- autre, répétition
4.1 Généralités 5
.
6-9 - réservé pour usage par I’ISO
1 .
Chaque message identifié dans la présente Norme
., >
.
internationale doit se ‘présenterdans l’ordre suivant :
4.12 Rbpétitions de message : ‘: , ) _ ’
. ,. ,,
identificateur de type’ de message (voir 4.1.1), un ou
plusieurs topogrammes binaires (bit map) (voir 4.2)
Dans 4.1.3, pour qu’il y ait repétition de message, le
., I
et une série d’éléments d’information dans l’ordre de
message répeté doit être identique au ‘message in$
la représentation du @@ogramme binaire (bit map)
.;, tial, a I.‘exception de l’identificateur du type de mesi
(voir 4.3). L’article 5 montre’ les circonstances dans ,
sage et, si nécessaire, la ‘date et l’heure de la
lesquelles un message doit (ou peut) être envoyé et la
transmission et l’élément d’information du code d’au-
relation entre les messages.
thentification du message (IVIAC).
,
ISO 8583 : 1993 (F)
f) L’élément d’information : code fonction doit être
4.1.3 Descriptions de l’identificateur de type de
utilisé pour indiquer le type d’autorisation requis
message
(voir tableau 1) et si le montant de la transaction est
Le tableau 6 identifie les types de messages pris en
exact ou estime. Si le montant final de la transaction
charge pour chaque classe de message. Chacune des
est disponible, le montant de la transaction sera le
classes de message suivantes prend en charge une acti-
montant exact. Si le montant final de la transaction
vité particuliere :
ne peut être déterminé qu’ulterieurement, le mon-
tant de la transaction doit être le montant estime.
4.1.3.1 Classe de message d’autorisations
‘g) Les types d’autorisation définis sont les suivants :
Une autorisation est un accord ou une garantie
pour un mouvement de fonds, donné par l’émetteur i) Autorisation initiale - Premiere ou seule
autorisation utilisée.
de carte à I’acqu&eur. Les messages d’autorisation
ne sont pas destines 81 permettre l’imputation du
ii) Autorisation de remplacement - autorisation
montant de la transaction approuvee au compte du
utilisée lorsqu’une autorisation precédente a éte
titulaire de carte aux fins de passation d’ecriture.
approuvée et qu’une autorisation ultérieure est
nécessaire pour remplacer le montant prece-
Les points suivants s’appliquent à toutes les autorisations :
demment autorisé parce que le montant de la
transaction est maintenant différent.
a) Les messages de demande d’autorisation doivent
être utilisés lorsque la transaction ne peut pas s’effec-
iii)Autorisation resoumise-autorisation utilisee pour
tuer au point de service jusqu’à réception du mes-
réintroduire une autorisation qui a été rejetée.
sage de réponse indiquant l’action à prendre. L’uti-
iv) Autorisation supplémentaire - autorisation
lisation d’un message de demande d’autorisation
utilisée lorsqu’une ou plusieurs autorisations
n’implique pas que le titulaire de carte soit présent
précédentes ont été approuvees et qu’il faut une
(par ex. téléphone ou vente par correspondance).
autre autorisation pour un montant supplémen-
b) Un message de réponse à une demande d’auto-
taire (voir tableau 1).
risation doit être envoye en réponse à un message
h) Les types de décisions d’autorisation définis sont
de demande d’autorisation. II indique l’accord ou
lessuivants:
l’action à prendre spécifié par le code action.
i) Approbation totale -
accord de l’émetteur de
c)
Les messagesd’avisd’autorisation doivent être utili-
carte sur le montant demandé.
sés pour informer l’émetteur de carte qu’une transaction
d’autorisation a été effectuée au point de service.
ii) Approbation partielle - accord de l’émetteur
d) Un message de réponse à un avis d’autorisation
de carte pour un montant inférieur au montant
doit être envoye en réponse à un message d’avis
demandé à l’origine (voir tableau 1).
d’autorisation. Un message de réponse à un avis
d’autorisation indique si l’émetteur de carte accepte
iii) Refusée ou rejetée - la demande d’accord est
ou refuse le transfert de la responsabilite financière.
refusée ou bien le message d’avis ou la demande
d’autorisation est rejetée (voir tableau 1).
e) Les messages de notification d’autorisation doi-
vent être utilis&s pour informer I’emetteur de carte
Le tableau 1 identifie l’usage des élbments d’informa-
qu’une transaction d’autorisation a 6t6 effectuée au
tion : montant de la transaction et montant initial de
point de service. II n’y a pas de message de réponse
transaction, dans les messages d’autorisation.
à un message de notification d’autorisation.
Tableau 1 - Montants dans les types de messages. d’autorisation
Dans les messages de d.emande, avis et notification :
,
.
Type d’autorisation Code fonction Montant de la transaction Montant initial de la transaction
initiale 100,101 montant de la transaction
I
de remplacement 102,103 nouveau montant montant autorisé initialement
I
resoumise 104,105 montant de la transaction
I
supplémentaire 106,107 montant supplémentaire somme des montants précédemment autorisés
/ 1
Dans les messages de rbponse :
\ I
Type d’sutorkation Code fonction Montant de la transaction Montant initial do la transaction
I 1
approbation totale montant. de la transaction
montant approuvé montant demandé initialement
approbation partielle
déclinékejeté zéro montant demandé initialement
ISO8583:1993(F)
f) Le code fonction doit être utilise pour indiquer le
4.1.3.2 Classe de messages financiers
type de transaction financiere et si le montant de la
Une transaction financière permet l’imputation du
transaction est le même ou s’il est different du
montant de transaction approuvé au compte du
montant autorisé précédemment (voir tableau 2).
titulaire de carte aux fins de passation d’écritures.
g) Les types de transactions financières definis sont
Ce qui suit s’applique à toutes les transactions finan-
les suivants :
cières :
i) Initiale - première ou seule transaction finan-
a) Les messages de demande financière doivent cière utilisée.
être utilises lorsque la transaction ne peut pas
ii) Autorisee précédemment - transaction
être exécutee au point de service jusqu’à récep-
financière utilisée quand une autorisation a été
tion d’un message de réponse indiquant l’action à
approuvée précédemment (voir tableau 2).
prendre. L’utilisation d’un message de demande
financière n’implique pas que le titulaire de carte
iii) Resoumise - transaction financiere utilisée
soit présent (par ex. téléphone ou vente par cor-
pour réintroduire une transaction financiere pré-
respondance).
cédemment déclinée ou refusée (voir tableau 2).
b) Un message de réponse à une demande finan-
iv) Nouvelle présentation - transaction financière
cière doit être envoyé en réponse à un message de
émise par un acquéreur pour recouvrer partiellement
demande financière. Un message de réponse à une
ou totalement des fonds redresses dans un rejet
demande financière indique l’accord ou l’action à
par un émetteur de carte (voir tableau 2).
prendre.
Les types de décisions de transaction financière
h)
c) Les messages d’avis financier doivent être sont lessuivants:
utilisés pour informer l’émetteur de carte qu’une
i) Approbation totale - l’émetteur de carte indi-
transaction financière a été exécutée au point de
que son accord sur le montant demandé initiale-
service.
ment (voir tableau 2).
d) Un message de réponse à avis financier doit être
ii) Approbation partielle - l’émetteur de carte
envoyé en réponse à un message d’avis financier.
indique son accord pour un montant inférieur à
Un message de réponse à un avis financier indique
celui demandé initialement (voir tableau 2).
si l’émetteur de carte accepte ou refuse le transfert
de l’engagement financier. iii) Refusée ou rejetée - la demande d’accord
est refusée ou la demande financière ou le mes-
e) Les messages de notification financière doivent
sage d’avis est rejeté (voir tableau 2).
être utilisés pour informer l’émetteur de carte
qu’une transaction financière a été exécutée au Le tableau 2 identifie l’usage des champs, montant de
point de service. II n’y a pas de message de réponse la transaction et montant initial de la transaction,
à un message de notification financière. dans les messages financiers.
Tableau 2 - Montants dans les types de messages de transaction financière
Dans les messages de demande, avis et notification :
1 Type de transaction financière 1 Code fonction 1 Montant de la transaction 1 Montant initial de la transaction 1
initiale 200 montant de la transaction
I I
autorisée précédemment 201,202 nouveau montant montant autorisé initialement
resoumise 203,204 montant de la transaction
nouvelle présentation 205,206,207 montant de la transaction montant du rejet
Dans les messages de réponse :
Code fonction Montant de la transaction
Type de décisions Montant initial de la transaction
I I I I
approbation totale montant de la transaction
approbation partielle montant approuvé montant demandé initialement
zéro
décliné/rejeté montant demandé initialement
A
ISO 8583 : 1993 (FI
4.1.3.3 Classe de messages de gestion de fichiers Tableau 3 - Montants dans les messages
de redressement
Un message de gestion de fichier doit être utilisé
pour ajouter, changer, supprimer ou remplacer un
Type de Montant de Montant initial de
fichier ou un enregistrement. En outre, les messages
redressement la transaction la transaction
de gestion de fichier peuvent servir à interroger un
fichier ou effectuer la gestion des cartes (par ex.
total montant
diffuser les cartes perdues ou volées). L’élément
redressé
d’information : enregistrement de données doit servir
à véhiculer des enregistrements spécifiques pour partiel
montant montant de
gérer des fichiers ou des informations globales sur redressé la transaction initiale
L
les fichiers.
g) Seules les transactions 1 lxx ou 12xx peuvent
4.1.3.4 Classe de messages de redressement
être redressées.
Un redressement doit servir à annuler partiellement
h) Le tableau 4 décrit des transactions financières
ou complètement les effets d’une transaction
12xx qui ne peuvent pas donner lieu àdes redressements.
financière ou d’une autorisation précédente. Tous les
redressements doivent utiliser la série de messages
14xX.
Tableau 4 -
Transactions financières
,
Un redressement doit utiliser les messages avis ou
notification puisque l’action s’est déjà produite. Les Fonction Code traitement Code fonction
points suivants s’appliquent à tous les redressements :
ajustement 02,22 200
a) Un redressement doit être initié par un acquéreur.
retour 20 200
Les codes raison du message servent à indiquer la
raison du redressement (voir article A.7).
nouvelle
205,206,207
présentation
b) L’élément d’information : montant de la
transaction, dans un redressement doit contenir le
4.1.3.5 Classe de messages de rejet
montant à redresser, et ce montant doit être inférieur
ou égal au montant initial comme le montre le
Un rejet ou une notification ne doit être initialisé(e)
tableau 3.
que par l’émetteur de carte. Tous les rejets doivent
utiliser la série de messages 14xx.
c) Chaque fois que l’acquéreur dépasse le temps
imparti à attendre une réponse à une autorisation,
Un rejet doit être un avis ou une notification puisque
ou à une demande ou un avis de transaction finan-
l’action s’est déjà produite.
cière, un redressement de la transaction doit être
envoyé (voir 5.2.12).
Les points suivants s’appliquent à tous les rejets.
d) Un message réponse avis de redressement doit
a) Un rejet ne peut être initié que par l’émetteur de
être envoyé en réponse à un message avis de
carte. II doit être émis lorsque l’émetteur de carte
redressement. Un avis de redressement ne doit pas
détermine qu’il existe un litige entre client, ou
être rejeté par l’émetteur de carte, sauf pour les rai-
qu’une erreur ou une violation des règles a été
sons précises (voir article A.V.
commise. Les codes raisons des messages sont utili-
e) Un redressement ne peut pas être lui-même
sés pour indiquer la cause du rejet (voir article A.7).
redressé.
b) Un rejet doit être généré uniquement si la trans-
f) Le code traitement dans un redressement doit
action initiale a eu un impact financier sur la posi-
être le même que celui présent dans le message ini-
tion nette du titulaire de carte. Un rejet ne doit pas
tial. Si la transaction initiale était un débit, le
servir à annuler une demande de solde, un transfert
redressement indique lui aussi un débit ; si la trans-
de compte ou une transaction d’autorisation.
action initiale était un crédit, le redressement indi-
c) Un message réponse doit être envoyé en réponse
que lui aussi un crédit.
à un message rejet. Un rejet ne doit pas être refusé
par le destinataire sauf pour les raisons spécifiques
Le tableau 3 montre l’utilisation des montants dans
(voir article A.6), même si la transaction initiale peut
les messages de redressement :
être représentée par l’acquéreur.
lSO8583:1993 (F)
d) L’élément d’information : montant de la transac- a) Les messages de demande de consolidation
tion dans un rejet doit être le montant rejeté, et il demandent les totaux de consolidation (nombre et
valeur).
doit être inférieur ou égal au montant initial de la
transaction, comme le montre le tableau 5 suivant. -
b) Un message de réponse à une demande de
consolidation doit être envoye en repense à un
Tableau 5 - Montants dans les messages de rejet
message de demande de consolidation. Un mes-
I , sage de réponse à une demande de consolidation
Montant initial de doit contenir les totaux demandes, s’ils sont dispo-
Type de rejet Montant de
la transaction nibles. Les totaux contenus dans un message de
la transaction
repense à une demande de consolidation doivent
montant rejeté
total
être utilises pour indiquer si l’organisme initiateur
occupe la position d’acquereur ou d’émetteur de
partiel montant rejeté montant de
carte (mais non les deux) comme le définit I’identi-
la transaction initiale
ficateur de type de message.
c) Les messages de réponse à une demande de
e) Le code traitement dans un rejet peut servir à
consolidation doivent indiquer l’un des resultats
indiquer un ajustement dans lequel l’émetteur de
suivants :
carte corrige un rejet, partiellement ou totalement,
qui a été présenté par erreur. Tous les ajustement
i) Totaux fournis - tous les cléments d’informa-
initiés par l’émetteur de carte sont des transactions
tion montants et nombres doivent être renvoyés
de rejet (1 ~XX). Le code traitement dans un rejet
avec les valeurs par l’organisme envoyant le
peut différer de la valeur de la transaction initiale.
message de réponse à la demande de
Le code traitement utilisé dans un rejet doit être
consolidation.
choisi comme suit :
ii) Totaux non disponibles - tous les elements
i) Pour rejeter une transaction financière 12xx, le
d’information montants et nombres doivent être
rejet doit contenir la même valeur de code trai-
renvoyés avec des valeurs zéro.
tement que la transaction qui est rejetée. Si la
transaction initiale était un débit, le rejet doit lui
d) Les messages d’avis de consolidation deman-
aussi indiquer un débit. Si la transaction initiale
dent la confirmation des totaux (nombre et valeur).
était un crédit, le rejet doit lui aussi indiquer un
Les totaux contenus dans un message d’avis de
crédit.
consolidation indiquent la position de l’organisme
initiateur comme étant soit l’acquéreur soit I’émet-
ii) Pour annuler, soit partiellement soit complè-
teur de carte (mais non les deux) comme le définit
tement, un rejet précédent qui a été présenté
l’identificateur du type de message.
par erreur, l’émetteur de carte doit émettre un
nouveau rejet contenant l’un des deux codes de
e) Un message de réponse à un avis de consolida-
traitement de consolidation. Si la transaction
tion doit être envoyé en réponse à un message
initiale était un débit, ce nouveau rejet doit indi-
d’avis de consolidation.
quer un crédit. Si la transaction initiale était un
f) Le message de réponse à l’avis de consolidation
crédit, ce nouveau rejet doit indiquer un débit.
doit indiquer l’un des résultats suivants :
f) Si la transaction qui est en cours de rejet
demande une réponse, ce message de réponse doit
i) Consolidé, équilibré - seul l’élément d’infor-
être envoyé avant le traitement du rejet.
mation : montant de consolidation net doit être
renvoyé dans le message de réponse a l’avis de
g) Un émetteur de carte peut rejeter un
...