ISO 8583

Last updated

ISO 8583 is an international standard for financial transaction card originated interchange messaging. It is the International Organization for Standardization standard for systems that exchange electronic transactions initiated by cardholders using payment cards.

Contents

ISO 8583 defines a message format and a communication flow so that different systems can exchange these transaction requests and responses. The vast majority of transactions made when a customer uses a card to make a payment in a store (EFTPOS) use ISO 8583 at some point in the communication chain, as do transactions made at ATMs. In particular, the Mastercard, Visa and Verve networks base their authorization communications on the ISO 8583 standard, as do many other institutions and networks.

Although ISO 8583 defines a common standard, it is not typically used directly by systems or networks. It defines many standard fields (data elements) which remain the same in all systems or networks, and leaves a few additional fields for passing network-specific details. These fields are used by each network to adapt the standard for its own use with custom fields and custom usages like Proximity Cards.

Introduction

The ISO 8583 specification has three parts:

Message format

A card-based transaction typically travels from a transaction-acquiring device, such as a point-of-sale terminal (POS) or an automated teller machine (ATM), through a series of networks, to a card issuing system for authorization against the card holder's account. The transaction data contains information derived from the card (e.g., the card number or card holder details), the terminal (e.g., the terminal number, the merchant number), the transaction (e.g., the amount), together with other data which may be generated dynamically or added by intervening systems. Based on this information, the card issuing system will either authorize or decline the transaction and generate a response message which must be delivered back to the terminal within a predefined time period.

An ISO 8583 message is made of the following parts:

The placements of fields in different versions of the standard varies; for example, the currency elements of the 1987 and 1993 versions of the standard are no longer used in the 2003 version, which holds currency as a sub-element of any financial amount element. As of June 2017, however ISO 8583:2003 has yet to achieve wide acceptance. ISO 8583 messaging has no routing information, so is sometimes used with a TPDU header.

Cardholder-originated transactions include purchase, withdrawal, deposit, refund, reversal, balance inquiry, payments and inter-account transfers. ISO 8583 also defines system-to-system messages for secure key exchanges, reconciliation of totals, and other administrative purposes.

Message type indicator (MTI)

The message type indicator is a four-digit numeric field which indicates the overall function of the message. A message type indicator includes the ISO 8583 version, the Message Class, the Message Function and the Message Origin, as described below.

ISO 8583 version

The first digit of the MTI indicates the ISO 8583 version in which the message is encoded.

CodeMeaning
0xxxISO 8583:1987
1xxxISO 8583:1993
2xxxISO 8583:2003
3xxxReserved by ISO
4xxx
5xxx
6xxx
7xxx
8xxxNational use
9xxxPrivate use

Message class

Position two of the MTI specifies the overall purpose of the message.

CodeMeaningUsage
x0xxReserved by ISO
x1xxAuthorization messageDetermine if funds are available, get an approval but do not post to account for reconciliation. Dual message system (DMS), awaits file exchange for posting to the account.
x2xxFinancial messagesDetermine if funds are available, get an approval and post directly to the account. Single message system (SMS), no file exchange after this.
x3xxFile actions messageUsed for hot-card, TMS and other exchanges
x4xxReversal and charge-back messagesReversal (x4x0 or x4x1): Reverses the action of a previous authorization.
Charge-back (x4x2 or x4x3): Charges back a previously cleared financial message.
x5xxReconciliation messageTransmits settlement information message.
x6xxAdministrative messageTransmits administrative advice. Often used for failure messages (e.g., message reject or failure to apply).
x7xxFee collection messages
x8xxNetwork management messageUsed for secure key exchange, logon, echo test and other network functions.
x9xxReserved by ISO

Message function

Position three of the MTI specifies the messages function which defines how the message should flow within the system. Requests are end-to-end messages (e.g., from acquirer to issuer and back with time-outs and automatic reversals in place), while advices are point-to-point messages (e.g., from terminal to acquirer, from acquirer to network, from network to issuer, with transmission guaranteed over each link, but not necessarily immediately).

CodeMeaningNotes
xx0xRequestRequest from acquirer to issuer to carry out an action; issuer may accept or reject
xx1xRequest responseResponse to a request
xx2xAdviceAdvice that an action has taken place; receiver can only accept, not reject
xx3xAdvice responseResponse to an advice
xx4xNotificationNotification that an event has taken place; receiver can only accept, not reject
xx5xNotification acknowledgementResponse to a notification
xx6xInstructionISO 8583:2003
xx7xInstruction acknowledgement
xx8xReserved for ISO useSome implementations (such as MasterCard) use for positive acknowledgment. [4]
xx9xSome implementations (such as MasterCard) use for negative acknowledgement. [5]

Message origin

Position four of the MTI defines the location of the message source within the payment chain.

CodeMeaning
xxx0Acquirer
xxx1Acquirer repeat
xxx2Issuer
xxx3Issuer repeat
xxx4Other
xxx60Reserved by ISO
xxx6
xxx41

Examples

Given an MTI value of 0110, the following example lists what each position indicates:

  • 0xxx → version of ISO 8583 (0 = 1987 version)
  • x1xx → class of the message (1 = authorization message)
  • xx1x → function of the message (1 = response)
  • xxx0 → who began the communication (0 = acquirer)

Therefore, MTI 0110 is an authorization response message where actual transaction was originated by the acquirer.

Bearing each of the above four positions in mind, an MTI will completely specify what a message should do, and how it is to be transmitted around the network. Unfortunately, not all ISO 8583 implementations interpret the meaning of an MTI in the same way. However, a few MTIs are relatively standard:

MTIMeaningUsage
0100Authorization RequestRequest from a point-of-sale terminal for authorization for a cardholder purchase
0110Authorization ResponseRequest response to a point-of-sale terminal for authorization for a cardholder purchase
0120Authorization AdviceWhen the point-of-sale device breaks down and you have to sign a voucher
0121Authorization Advice RepeatIf the advice times out
0130Issuer Response to Authorization AdviceConfirmation of receipt of authorization advice
0200Acquirer Financial RequestRequest for funds, typically from an ATM or pinned point-of-sale device
0210Issuer Response to Financial RequestIssuer response to request for funds
0220Acquirer Financial Advicee.g. Checkout at a hotel. Used to complete transaction initiated with authorization request
0221Acquirer Financial Advice RepeatIf the advice times out
0230Issuer Response to Financial AdviceConfirmation of receipt of financial advice
0320Batch UploadFile update/transfer advice
0330Batch Upload ResponseFile update/transfer advice response
0400Acquirer Reversal RequestReverses a transaction
0420Acquirer Reversal Advice
0430Acquirer Reversal Advice Response
0510Batch Settlement ResponseCard acceptor reconciliation request response
0800Network Management RequestHypercom terminals initialize request. Echo test, logon, logoff etc.
0810Network Management ResponseHypercom terminals initialize response. Echo test, logon, logoff etc.
0820Network Management AdviceKey change

Bitmaps

In ISO 8583, a bitmap is a field or subfield within a message, which indicates whether other data elements or data element subfields are present elsewhere in the message.

A field is considered to be present only when the corresponding bit in the bitmap is set. For example, a hex with value 0x82 (decimal 130) is binary 1000 0010, which means fields 1 and 7 are present in the message and fields 2, 3, 4, 5, 6 and 8 are not.

The bitmap may be represented as 8 bytes of binary data or as 16 hexadecimal characters (0–9, A–F) in the ASCII or EBCDIC character sets. A message will contain at least one bitmap, called the primary bitmap, which indicates data whether elements 1 to 64 are present. The presence of an optional secondary bitmap is also indicated by the first bit in the primary bitmap. If present, the secondary bitmap indicates whether data elements 65 to 128 are present. Similarly, a tertiary bitmap can be used to indicate the presence of fields 129 to 192, although these data elements are rarely used.

Examples

Given a bitmap value of 70 10 00 11 02 C0 48 04,

0x70 = 0111 0000 (counting from the left, the second, third and fourth bits are 1, indicating that fields 2, 3 and 4 are present)
0x10 = 0001 0000 (the first bit corresponds to field 9, so the fourth bit here indicates field 12 is present)
0x00 = 0000 0000 (no fields present)
0x11 = 0001 0001 (fields 28 and 32 are present)
0x02 = 0000 0010 (field 39 is present)
0xC0 = 1100 0000 (fields 41 and 42 are present)
0x48 = 0100 1000 (fields 50 and 53 are present)
0x04 = 0000 0100 (field 62 is present)
nth bit0102030405060
1234567890123456789012345678901234567890123456789012345678901234
Bitmap0111000000010000000000000001000100000010110000000100100000000100

Therefore, the given bitmap defines the following fields present in the message::
2, 3, 4, 12, 28, 32, 39, 41, 42, 50, 53, 62 .

Data elements

Data elements are the individual fields carrying the transaction information. There are up to 128 data elements specified in the original ISO 8583:1987 standard, and up to 192 data elements in later releases. The 1993 revision added new definitions, deleted some, while leaving the message format itself unchanged.

While each data element has a specified meaning and format, the standard also includes some general purpose data elements and system- or country-specific data elements which vary enormously in use and form from implementation to implementation.

Each data element is described in a standard format which defines the permitted content of the field (numeric, binary, etc.) and the field length (variable or fixed), according to the following table:

AbbreviationMeaning
aAlpha, including blanks
nNumeric values only
x+nNumeric (amount) values, where the first byte is either 'C' to indicate a positive or Credit value, or 'D' to indicate a negative or Debit value, followed by the numeric value (using n digits)
sSpecial characters only
anAlphanumeric
asAlpha & special characters only
nsNumeric and special characters only
ansAlphabetic, numeric and special characters.
anpAlphabetic, numeric and pad characters.
bBinary data
pPad character, space
zTracks 2 and 3 code set as defined in ISO/IEC 7813 and ISO/IEC 4909 respectively
. or .. or ...variable field length indicator, each . indicating a digit.
x or xx or xxxfixed length of field, or maximum length in the case of variable length fields.

Additionally, each field may be either fixed or variable length. If variable, the length of the field will be preceded by a length indicator.

TypeMeaning
Fixedno field length used
LLVAR or (..xx)Where 0 < LL < 100, means two leading digits LL specify the field length of field VAR
LLLVAR or (...xxx)Where 0 < LLL < 1000, means three leading digits LLL specify the field length of field VAR
LL and LLL are hex or ASCII. A VAR field can be compressed or ASCII depending on the data element type.LL can be one or two bytes. For example, if compressed as one hex byte, '27x means there are 27 VAR bytes to follow. If ASCII, the two bytes '32x, '37x mean there are 27 bytes to follow. Three-digit field length LLL uses two bytes with a leading '0' nibble if compressed, or three bytes if ASCII. The format of a VAR data element depends on the data element type. If numeric it will be compressed, e.g. 87456 will be represented by three hex bytes '087456x. If ASCII then one byte for each digit or character is used, e.g. '38x, '37x, '34x, '35x, '36x.

Examples

Field DefinitionMeaning
n 6Fixed length field of six digits
n.6LVAR numeric field of up to 6 digits in length
a..11LLVAR alpha field of up to 11 characters in length
b...999LLLVAR binary field of up to 999 bytes in length

ISO-defined data elements (ver 1987)

Data fieldTypeUsage
1b 16Bitmap
2n..19Primary account number (PAN)
3n 6Processing Code
4n 12Amount Transaction
5n 12Amount, settlement
6n 12Amount, cardholder billing
7n 10Transmission date & time
8n 8Amount, cardholder billing fee
9n 8Conversion rate, settlement
10n 8Conversion rate, cardholder billing
11n 6System trace audit number (STAN)
12n 6Local transaction time (hhmmss)
13n 4Local transaction date (MMDD)
14n 4Expiration date (YYMM)
15n 4Settlement date
16n 4Currency conversion date
17n 4Capture date
18n 4Merchant type, or merchant category code
19n 3Acquiring institution (country code)
20n 3PAN extended (country code)
21n 3Forwarding institution (country code)
22n 3Point of service entry mode
23n 3Application PAN sequence number
24n 3Function code (ISO 8583:1993), or network international identifier (NII)
25n 2Point of service condition code
26n 2Point of service capture code
27n 1Authorizing identification response length
28x+n 8Amount, transaction fee
29x+n 8Amount, settlement fee
30x+n 8Amount, transaction processing fee
31x+n 8Amount, settlement processing fee
32n ..11Acquiring institution identification code
33n ..11Forwarding institution identification code
34ns ..28Primary account number, extended
35z ..37Track 2 data
36n ...104Track 3 data
37an 12Retrieval reference number
38an 6Authorization identification response
39an 2Response code
40an 3Service restriction code
41ans 8Card acceptor terminal identification
42ans 15Card acceptor identification code
43ans 40Card acceptor name/location (1–25 card acceptor name or automated teller machine (ATM) location, 26-38 city name, 39-40 country code)
44an ..25Additional response data
45an ..76Track 1 data
46an ...999Additional data (ISO)
47an ...999Additional data (national)
48an ...999Additional data (private)
49a or n 3Currency code, transaction
50a or n 3Currency code, settlement
51a or n 3Currency code, cardholder billing
52b 64 Personal identification number data
53n 16Security related control information
54an ...120Additional amounts
55ans ...999ICC data – EMV having multiple tags
56ans ...999Reserved (ISO)
57ans ...999Reserved (national)
58ans ...999
59ans ...999
60ans ...999Reserved (national) (e.g. settlement request: batch number, advice transactions: original transaction amount, batch upload: original MTI plus original RRN plus original STAN, etc.)
61ans ...999Reserved (private) (e.g. CVV2/service code   transactions)
62ans ...999Reserved (private) (e.g. transactions: invoice number, key exchange transactions: TPK key, etc.)
63ans ...999Reserved (private)
64b 64 Message authentication code (MAC)
65b 1Extended bitmap indicator
66n 1Settlement code
67n 2Extended payment code
68n 3Receiving institution country code
69n 3Settlement institution country code
70n 3Network management information code
71n 4Message number
72n 4Last message's number
73n 6Action date (YYMMDD)
74n 10Number of credits
75n 10Credits, reversal number
76n 10Number of debits
77n 10Debits, reversal number
78n 10Transfer number
79n 10Transfer, reversal number
80n 10Number of inquiries
81n 10Number of authorizations
82n 12Credits, processing fee amount
83n 12Credits, transaction fee amount
84n 12Debits, processing fee amount
85n 12Debits, transaction fee amount
86n 16Total amount of credits
87n 16Credits, reversal amount
88n 16Total amount of debits
89n 16Debits, reversal amount
90n 42Original data elements
91an 1File update code
92an 2File security code
93an 5Response indicator
94an 7Service indicator
95an 42Replacement amounts
96b 64Message security code
97x+n 16Net settlement amount
98ans 25Payee
99n ..11Settlement institution identification code
100n ..11Receiving institution identification code
101ans ..17File name
102ans ..28Account identification 1
103ans ..28Account identification 2
104ans ...100Transaction description
105ans ...999Reserved for ISO use
106ans ...999
107ans ...999
108ans ...999
109ans ...999
110ans ...999
111ans ...999
112ans ...999Reserved for national use
113ans ...999
114ans ...999
115ans ...999
116ans ...999
117ans ...999
118ans ...999
119ans ...999
120ans ...999Reserved for private use
121ans ...999
122ans ...999
123ans ...999
124ans ...999
125ans ...999
126ans ...999
127ans ...999
128b 64 Message authentication code

Processing code

The following is a table specifying the type of messages and processing code for each transaction type.

TransactionMessage typeProcessing code
Authorization010000 a0 0x
Balance inquiry31 a0 0x
Sale020000 a0 0x
Cash01 a0 0x
Credit Voucher20 a0 0x
Void02 a0 0x
Mobile topup57 a0 0x

Response code

Ver 1987

The following table shows response codes and their meanings for ISO 8583-1987, later versions uses 3 and 4 digit response codes.

CodeDescription
00Approved or completed successfully
01Refer to card issuer
02Refer to card issuer's special conditions
03Invalid merchant
04Pick-up
05Do not honor
06Error
07Pick-up card, special condition
08Honour with identification
09Request in progress
10Approved for partial amount
11Approved (VIP)
12Invalid transaction
13Invalid amount
14Invalid card number (no such number)
15No such issuer
16Approved, update track 3
17Customer cancellation
18Customer dispute
19Re-enter transaction
20Invalid response
21No action taken
22Suspected malfunction
23Unacceptable transaction fee
24File update not supported by receiver
25Unable to locate record on file
26Duplicate file update record, old record replaced
27File update field edit error
28File update file locked out
29File update not successful, contact acquirer
30Format error
31Bank not supported by switch
32Completed partially
33Expired card
34Suspected fraud
35Card acceptor contact acquirer
36Restricted card
37Card acceptor call acquirer security
38Allowable PIN tries exceeded
39No credit account
40Requested function not supported
41Lost card
42No universal account
43Stolen card, pick-up
44No investment account
45-50Reserved for ISO use
51Not sufficient funds
52No checking account
53No savings account
54Expired card
55Incorrect personal identification number
56No card record
57Transaction not permitted to cardholder
58Transaction not permitted to terminal
59Suspected fraud
60Card acceptor contact acquirer
61Exceeds withdrawal amount limit
62Restricted card
63Security violation
64Original amount incorrect
65Exceeds withdrawal frequency limit
66Card acceptor call acquirer's security department
67Hard capture (requires that card be picked up at ATM)
68Response received too late
69-74Reserved for ISO use
75Allowable number of PIN tries exceeded
78Card not activated
80Visa transactions: credit issuer unavailable
82Invalid card expiration date
82CVN Mismatch: Negative CAM, dCVV, iCVV, or CVV results
85Success: address verification
76-89Reserved for private use
76-89Reserved for private use
76-89Reserved for private use
76-89Reserved for private use
90Cutoff is in process

(switch ending a day's business and starting the next. Transaction can be sent again in a few minutes)

91Issuer or switch is inoperative
92Financial institution or intermediate network facility cannot be found for routing
93Transaction cannot be completed. Violation of law
94Duplicate transmission
95Reconcile error
96System malfunction
97-99Reserved for national use
Zero A-9ZReserved for ISO use
A Zero-MZReserved for national use
N Zero-ZZReserved for private use
Ver 1993
CodeDescription
000‑099Used in 1110, 1120, 1121, 1140 and 1210, 1220, 1221 and 1240 messages to indicate that the transaction has been approved.
000approved
001honour with identification
002approved for partial amount
003approved (VIP)
004approved, update track 3
005approved, account type specified by card issuer
006approved for partial amount, account type specified by card issuer
007approved, update ICC
008‑059reserved for ISO use
060‑079reserved for national use
080‑099reserved for private use
100‑199Used in 1110, 1120, 1121, 1140 and 1210, 1220, 1221 and 1240 messages to indicate that the transaction has been processed for authorization by or on behalf of the card issuer and has been denied (not requiring a card pick-up)
100do not honour
101expired card
102suspected fraud
103card acceptor contact acquirer
104restricted card
105card acceptor call acquirer's security department
106allowable PIN tries exceeded
107refer to card issuer
108refer to card issuer's special conditions
109invalid merchant
110invalid amount
111invalid card number
112PIN data required
113unacceptable fee
114no account of type requested
115requested function not supported
116not sufficient funds
117incorrect PIN
118no card record
119transaction not permitted to cardholder
120transaction not permitted to terminal
121exceeds withdrawal amount limit
122security violation
123exceeds withdrawal frequency limit
124violation of law
125card not effective
126invalid PIN block
127PIN length error
128PIN key sync error
129suspected counterfeit card
130‑159reserved for ISO use
160‑179reserved for national use
180‑199reserved for private use
200‑299Used in 1110, 1120, 1121, 1140 and 1210, 1220, 1221 and 1240 messages to indicate that the transaction has been processed for authorization by or on behalf of the card issuer and has been denied requiring the card to be picked up.
200do not honour
201expired card
202suspected fraud
203card acceptor contact acquirer
204restricted card
205card acceptor call acquirer's security department
206allowable PIN tries exceeded
207special conditions
208lost card
209stolen card
210suspected counterfeit card
211‑259reserved for ISO use
260‑279reserved for national use
280‑299reserved for private use
300‑399Used in 1314, 1324, 1325 and 1344 messages to indicate the result of the file action.
300successful
301not supported by receiver
302unable to locate record on file
303duplicate record, old record replaced
304field edit error
305file locked out
306not successful
307format error
308duplicate, new record rejected
309unknown file
310‑359reserved for ISO use
360‑379reserved for national use
380‑399reserved for private use
400‑499Used in 1430, 1432, 1440 and 1442 messages to indicate the result of the reversal or chargeback.
400accepted
401‑459reserved for ISO use
460‑479reserved for national use
480‑499reserved for private use
500‑599Used in 1510, 1512, 1530 and 1532 messages to indicate the result of a reconciliation.
500reconciled, in balance
501reconciled, out of balance
502amount not reconciled, totals provided
503totals not available
504not reconciled, totals provided
505‑559reserved for ISO use
560‑579reserved for national use
580‑599reserved for private use
600‑699Used in 1614, 1624, 1625, and 1644 messages
600accepted
601not able to trace back original transaction
602invalid reference number
603reference number/PAN incompatible
604POS photograph is not available
605item supplied
606request cannot be fulfilled - required/requested documentation is not available
607‑659reserved for ISO use
660‑679reserved for national use
680‑699reserved for private use
700‑799Used in 1720, 1721, 1740, 1722, 1723 and 1742 messages.
700accepted
701‑749reserved for ISO use
750‑769reserved for national use
770‑799reserved for private use
800‑899Used in 1814, 1824, 1825 and 1844 messages.
800accepted
801‑859reserved for ISO use
860‑879reserved for national use
880‑899reserved for private use
900Advice acknowledged, no financial liability accepted
901Advice acknowledged, financial liability accepted
902‑949Used in request response and advice response messages to indicate transaction could not be processed.
902invalid transaction
903re-enter transaction
904format error
905acquirer not supported by switch
906cutover in process
907card issuer or switch inoperative
908transaction destination cannot be found for routing
909system malfunction
910card issuer signed off
911card issuer timed out
912card issuer unavailable
913duplicate transmission
914not able to trace back to original transaction
915reconciliation cutover or checkpoint error
916MAC incorrect
917MAC key sync error
918No communication keys available for use
919encryption key sync error
920security software/hardware error - try again
921security software/hardware error - no action
922message number out of sequence
923request in progress
924‑929reserved for ISO use
930‑939reserved for national use
940‑949reserved for private use
950‑999Used in advice response messages (1x3x) to indicate the reason for rejection of the transfer of financial liability.
950violation of business arrangement
951‑983reserved for ISO use
984‑991reserved for national use
992‑999reserved for private use

Point of service entry modes (Field 22)

The point of service (POS) mode field state what conditions the card has been read under, which type of authentication has been made, and depending on the version of the specification, what the capabilities of the terminal are.

Ver 2003

For the 2003 specification the POS code consists of 16 binary characters split into four parts:

  1. Card reading method used
  2. Cardholder verification method used
  3. POS environment
  4. Security characteristics
Ver 1993

For the 1993 [6] version it is a 12-character field consisting of 5 parts:

  1. The terminal input capabilities (1st to 3rd character)
    • Card Data Input Capability
    • Cardholder Authentication Capability
    • Card capture capability
  2. The operating environment (4th to 6th character)
    • Operating Environment / Terminal placement
    • Cardholder Present indicator
    • Card Present indicator
  3. Authentication and verification done (7th to 9th character)
    • Card Data Input Method
    • Cardholder Verification Method
    • Cardholder Authentication Entity
  4. The terminal's output capabilities (10th and 11th character)
    • Card data output capability - can the terminal write to the magnetic stripe, or to the chip
    • Terminal output capability - can the terminal display or print something to the cardholder.
  5. PIN capture capability (12th character) indicates if the terminal can capture a pin code, and if so, the maximum length it can capture.
Ver 1987

The point of service entry mode value consists of two parts:

  1. PAN entry mode, the first two digits
  2. PIN entry capability, the third digit

The following table shows PAN entry modes and their meanings.

PAN Entry ModeMeaning
00Unknown
01Manual
02Magnetic stripe
03Bar code
04OCR
05Integrated circuit card (ICC). CVV can be checked.
07Auto entry via contactless EMV.
10Merchant has Cardholder Credentials on File.
80Fallback from integrated circuit card (ICC) to magnetic stripe
90Magnetic stripe as read from track 2. CVV can be checked.
91Auto entry via contactless magnetic stripe
95Integrated circuit card (ICC). CVV may not be checked.
99Same as original transaction.

The following table shows PIN entry capabilities and their meanings.

PIN Entry CapabilityMeaning
0Unknown
1Terminal can accept PINs
2Terminal cannot accept PINs
3mPOS software-based PIN-entry capability
8Terminal has PIN-entry capability but the PIN pad is not currently operative

The Australian standard AS 2805 incorporates ISO 8583 and also covers a large number of other payments topics. [7]

See also

Related Research Articles

<span class="mw-page-title-main">ISO 8601</span> International standards for dates and times

ISO 8601 is an international standard covering the worldwide exchange and communication of date and time-related data. It is maintained by the International Organization for Standardization (ISO) and was first published in 1988, with updates in 1991, 2000, 2004, and 2019, and an amendment in 2022. The standard provides a well-defined, unambiguous method of representing calendar dates and times in worldwide communications, especially to avoid misinterpreting numeric dates and times when such data is transferred between countries with different conventions for writing numeric dates and times.

ISO/IEC 7816 is an international standard related to electronic identification cards with contacts, especially smart cards, and more recently, contactless mobile devices, managed jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC).

Abstract Syntax Notation One (ASN.1) is a standard interface description language (IDL) for defining data structures that can be serialized and deserialized in a cross-platform way. It is broadly used in telecommunications and computer networking, and especially in cryptography.

ISO 9362 is an international standard for Business Identifier Codes (BIC), a unique identifier for business institutions, approved by the International Organization for Standardization (ISO). BIC is also known as SWIFT-BIC, SWIFT ID, or SWIFT code, after the Society for Worldwide Interbank Financial Telecommunication (SWIFT), which is designated by ISO as the BIC registration authority. BIC was defined originally as Bank Identifier Code and is most often assigned to financial organizations; when it is assigned to non-financial organization, the code may also be known as Business Entity Identifier (BEI). These codes are used when transferring money between banks, particularly for international wire transfers, and also for the exchange of other messages between banks. The codes can sometimes be found on account statements.

Health Level Seven, abbreviated to HL7, is a range of global standards for the transfer of clinical and administrative health data between applications with the aim to improve patient outcomes and health system performance. The HL7 standards focus on the application layer, which is "layer 7" in the Open Systems Interconnection model. The standards are produced by Health Level Seven International, an international standards organization, and are adopted by other standards issuing bodies such as American National Standards Institute and International Organization for Standardization. There are a range of primary standards that are commonly used across the industry, as well as secondary standards which are less frequently adopted.

<span class="mw-page-title-main">EMV</span> Smart payment card standard

EMV is a payment method based on a technical standard for smart payment cards and for payment terminals and automated teller machines which can accept them. EMV stands for "Europay, Mastercard, and Visa", the three companies that created the standard.

<span class="mw-page-title-main">Modbus</span> Serial communications protocol mainly developed for programmable logic controllers

Modbus or MODBUS is a client/server data communications protocol in the application layer. It was originally designed for use with its programmable logic controllers (PLCs), but has become a de facto standard communication protocol for communication between industrial electronic devices in a wide range of buses and networks.

<span class="mw-page-title-main">QR code</span> Type of matrix barcode

A QR code is a type of two-dimensional matrix barcode, invented in 1994, by Japanese company Denso Wave for labelling automobile parts. It features black squares on a white background with fiducial markers, readable by imaging devices like cameras, and processed using Reed–Solomon error correction until the image can be appropriately interpreted. The required data are then extracted from patterns that are present in both the horizontal and the vertical components of the QR image.

Registration authorities (RAs) exist for many standards organizations, such as ANNA, the Object Management Group, W3C, and others. In general, registration authorities all perform a similar function, in promoting the use of a particular standard through facilitating its use. This may be by applying the standard, where appropriate, or by verifying that a particular application satisfies the standard's tenants. Maintenance agencies, in contrast, may change an element in a standard based on set rules – such as the creation or change of a currency code when a currency is created or revalued. The Object Management Group has an additional concept of certified provider, which is deemed an entity permitted to perform some functions on behalf of the registration authority, under specific processes and procedures documented within the standard for such a role.

STEP-file is a widely used data exchange form of STEP. ISO 10303 can represent 3D objects in computer-aided design (CAD) and related information. Due to its ASCII structure, a STEP-file is easy to read, with typically one instance per line. The format of a STEP-file is defined in ISO 10303-21 Clear Text Encoding of the Exchange Structure.

<span class="mw-page-title-main">On-board diagnostics</span> Automotive engineering terminology

On-board diagnostics (OBD) is a term referring to a vehicle's self-diagnostic and reporting capability. In the United States, this capability is a requirement to comply with federal emissions standards to detect failures that may increase the vehicle tailpipe emissions to more than 150% of the standard to which it was originally certified.

ISO/IEC 7813 is an international standard codified by the International Organization for Standardization and International Electrotechnical Commission that defines properties of financial transaction cards, such as ATM or credit cards.

The C0 and C1 control code or control character sets define control codes for use in text by computer systems that use ASCII and derivatives of ASCII. The codes represent additional information about the text, such as the position of a cursor, an instruction to start a new line, or a message that the text has been received.

ISO 2709 is an ISO standard for bibliographic descriptions, titled Information and documentation—Format for information exchange.

<span class="mw-page-title-main">Payment card</span> Card issued by a financial institution that can be used to make a payment

Payment cards are part of a payment system issued by financial institutions, such as a bank, to a customer that enables its owner to access the funds in the customer's designated bank accounts, or through a credit account and make payments by electronic transfer with a payment terminal and access automated teller machines (ATMs). Such cards are known by a variety of names, including bank cards, ATM cards, client cards, key cards or cash cards.

3-D Secure is a protocol designed to be an additional security layer for online credit and debit card transactions. The name refers to the "three domains" which interact using the protocol: the merchant/acquirer domain, the issuer domain, and the interoperability domain.

<span class="mw-page-title-main">Card security code</span> Security feature on payment cards

A card security code is a series of numbers that, in addition to the bank card number, is printed on a credit or debit card. The CSC is used as a security feature for card not present transactions, where a personal identification number (PIN) cannot be manually entered by the cardholder. It was instituted to reduce the incidence of credit card fraud. Unlike the card number, the CSC is deliberately not embossed, so that it is not read when using a mechanical credit card imprinter which will only pick up embossed numbers.

jPOS is a free and open source library/framework that provides a high-performance bridge between card messages generated at the point of sale or ATM terminals and internal systems along the entire financial messaging network. jPOS is an enabling technology that can be used to handle all card processing from messaging, to processing, through reporting.

GSM 03.40 or 3GPP TS 23.040 is a mobile telephony standard describing the format of the Transfer Protocol Data Units (TPDU) of the Short Message Transfer Protocol (SM-TP) used in the GSM networks to carry Short Messages. This format is used throughout the whole transfer of the message in the GSM mobile network. In contrast, application servers use different protocols, like Short Message Peer-to-Peer or Universal Computer Protocol, to exchange messages between them and the Short Message Service Center (SMSC).

The term digital card can refer to a physical item, such as a memory card on a camera, or, increasingly since 2017, to the digital content hosted as a virtual card or cloud card, as a digital virtual representation of a physical card. They share a common purpose: Identity Management, Credit card, Debit card or driver license. A non-physical digital card, unlike a Magnetic stripe card can emulate (imitate) any kind of card.

References

  1. ISO 8583-1:2003 Financial transaction card originated messages -- Interchange message specifications -- Part 1: Messages, data elements and code values
  2. ISO8583-2:1998 Financial transaction card originated messages -- Interchange message specifications -- Part 2: Application and registration procedures for Institution Identification Codes (IIC)
  3. ISO8583-3:2003 Financial transaction card originated messages -- Interchange message specifications -- Part 3: Maintenance procedures for messages, data elements and code values
  4. MasterCard Customer Interface Specification, 25 July 2017
  5. MasterCard Customer Interface Specification, 25 July 2017
  6. "Iso 8583:1993".
  7. Arthur Van Der Merwe. "AS2805 Standards for EFT". Archived from the original on 7 Jun 2023.

Tools

A simple and free ISO8583 Editor