Have you thought about the process of communication in the financial institutions? On this webinar, we go over the importance of standards ISO 20022 and ISO 8583 and how it can help financial institution to create reports that are useful to all interested parties. Main points covered: • ISO 20022 and its importance on the financial communication. • ISO 8583 and its usage on the most credit and debit card transaction. • How can these two standards leverage to effectively manage the financial transactions and data? Presenter: This webinar was presented by Orlando Olumide Odejide. He is a PECB Certified Trainer and an experienced Enterprise Architect and Programme Director working on various technology solutions. His expertise spans to various ISO standard such as ISO 27001, ISO 20000 and ISO 22301, COBIT, CMMI, TOGAF, PRINCE2, ITIL. Link of the recorded session published on YouTube: https://youtu.be/Ilx6isDrXEU

1. Exploring Payment Platforms: ISO
20022 and 8583
Orlando Olumide Odejide

2. Olumide Odejide
Director
Orlando Olumide Odejide is PECB certified trainer. He is an experienced Enterprise Archited and
Programme Director working on various technology solutions. His expertise spans to various ISO
standard such as ISO 27001, ISO 20000 and ISO 22301,COBIT, CMMI, TOGAF, PRINCE2, ITIL
234-8037154520
orlando@g4vonline.com www.trainingheights.net/
linkedin.com/orlando-olumide-odejide-a7b79927

3. Summary
• What does ISO 20022 have to
offer?
• What does ISO 8583 have to
offer?
• How does an organization align
or choose between ISO 20022
and 8583?

4. • ISO 20022 is an ISO standard for electronic data interchange between
financial institutions. It describes a metadata repository containing
descriptions of messages and business processes, and a maintenance
process for the repository content.
• The repository contains a huge amount of financial services metadata
that has been shared and standardized across the industry. The
metadata is stored in UML models with a special ISO 20022 UML
Profile. Underlying all of this is the ISO 20022 metamodel - a model of
the models. The UML profile is the metamodel transformed into UML.
The metadata is transformed into the syntax of messages used in
financial networks. The first syntax supported for messages was XML
Schema.
• ISO 20022 is widely used in financial services. Organizations
participating in ISO 20022 include: FIX Protocol Limited (Financial
Information eXchange), ISDA (FpML), ISITC, Omgeo, SWIFT, and Visa.
• ISO 20022 is the successor to ISO 15022; originally ISO 20022 was
called ISO 15022 2nd Edition. ISO 15022 was the successor of ISO
7775.

5. • ISO 20022 Financial Services - universal financial industry message
scheme.
– Part 1: Overall Methodology and Format Specifications for Inputs
and Outputs to/from the ISO 20022 Repository (has the status of
International Standard), numbered as ISO 20022-1:2004
– Part 2: Roles and responsibilities of the registration bodies (has the
status of International Standard), numbered as ISO 20022-2:2007
– Part 3: ISO 20022 Modeling guidelines (has the status of Technical
Specification), numbered as ISO/TS 20022-3:2004
– Part 4: ISO 20022 XML design rules (has the status of Technical
Specification), numbered as ISO/TS 20022-4:2004
– Part 5: ISO 20022 Reverse engineering (has the status of Technical
Specification), numbered as ISO/TS 20022-5:2004
– Part 6: ISO 20022 Message Transport Characteristics (has the
status of International Standard), numbered as ISO 20022-6:2009

6. • Almost all of us would have swiped a card or two at an ATM or
a PoS terminal (or a Square dongle ;)). At the very least, the
card serves as an identity factor. Among other things , the
magnetic stripe on each card stores something called the
PAN (Primary Account Number). For most credit cards, it is
the same as the credit card number printed on the front
surface/ plastic.
The act of swiping a card on a card reader essentially
involves passing this 'identity' of the card to the electronic
sub-system and represents a Card Present type of
transaction. Alternatively, one could have typed in this
information (card number) on a screen of an online shopping
interface but then this would effectively become a Card Not
Present transaction.

7. • Anyways, we now have the identity of the card in the
electronic form. One of the most popular uses of this
information is to let the system know which account to
debit. (In case you get confused by 'debit' and 'credit':
Debit = Deduct from your card/ account. Credit = Create
money in your card/ account.

8. • So what is ISO 8583? It is one of the many standards
describing how to pack certain data fields such that it could
reliably be unpacked as well and is mostly relevant for the
financial transaction processing world.
• So this standard helps the electronic system which reads the
card number, the transaction amount and other relevant data
fields to pack it all up so that it could be transmitted
electronically to a transaction processing system where it
could then be unpacked back into individual data components
and then processed.
• It also helps the transaction processing system pack and send
the response back to the initiating device where it could again
be unpacked and the customer be intimated of the transaction
response.

9. • There exist numerous methods for packing and unpacking data. It
could be as simple as comma separated fields. Eg: I could choose
to send the transaction information as simple comma separated
values as:
"1234123412341234,1000,INR,987" (Card Number, Amount,
Currency, Merchant ID).
The issue with such a simplistic model of data packing is that it lacks
meta information. That is, the message itself does not contain any
information on what exactly is being packed in it. Not that it could not
have been overcome even with a comma separated version- just
that it could get cumbersome. Also, I guess at that point in time, it
was important to consider that the packing and unpacking could be
coded easily into mainframes, not sure about this one.

10. • ISO 8583 Financial transaction card originated
messages — Interchange message specifications is the
International Organization for Standardization standard
for systems that exchange electronic transactions made
by cardholders using payment cards.
• It has three parts:
– Part 1: Messages, data elements and code values[1]
– Part 2: Application and registration procedures for
Institution Identification Codes (IIC)[2]
– Part 3: Maintenance procedures for messages, data
elements and code values[3]

11. • A card-based transaction typically travels from a transaction acquiring device,
such as a point-of-sale terminal 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 account number), the terminal (e.g., the merchant number), the
transaction (e.g., the amount), together with other data which may be generated
dynamically or added by intervening systems. 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.
• 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 at ATMs use ISO 8583 at some point in the
communication chain, as do transactions made when a customer uses a card to
make a payment in a store (EFTPOS). In particular, both the MasterCard and
Visa networks base their authorization communications on the ISO 8583
standard, as do many other institutions and networks. ISO 8583 has no routing
information, so is sometimes used with a TPDU header.

12. • 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.
• 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.
• The placements of fields in different versions of the standard varies;
for example, the currency elements of the 1987 and 1993 versions
are no longer used in the 2003 version, which holds currency as a
sub-element of any financial amount element. As of writing, ISO
8583:2003 has yet to achieve wide acceptance.

13. • An ISO 8583 message is made of the following parts:
• Message type indicator (MTI)
• One or more bitmaps, indicating which data elements
are present
• Data elements, the fields of the message

14. • T he IS O 8583 message consists of a Message Type Identifier, Bitmaps, and
Data elements.
A Message T ype Identifier is a four digit numeric field that describes each message
class and function. Some common Message Type Identifiers are as below.
First 2 digits of the Message Type Identifier Description
02XX Financial Transaction Messages
04XX Reversal Messages
08XX Network Management Messages

15. Normal Transaction Message Flow
• Financial transaction messages are messages with the
identifier of 02XX. In a normal situation, it starts with
0200 from the requester and the responder will send a
message with a header of 021 0 stating that it is a
response from the request earlier.
System A
Send 0200XXXXX
Request Message
System A
Receive Response
Transaction Finished
System B
Process Request
Message
System B
Send 021 0XXXXX
Response Message

16. Normal Reversal Message Flow
• Financial transaction message can be either monetary or non-
monetary. Non-monetary message are messages that does inquiries
to the remote system and other non-monetary transactions.
Monetary transactions messages are messages that request the
remote system to credit or debit a certain amount into an account.
System A
Send 0200XXXXX
Request Message
System A
Receive Response
Transaction Finished
System B
Process Request
Message
System B
Send 021 0XXXXX
Response Message

17. • A reversal message is identified by the header of 04XX. For
interactive reversal transaction, the identifier is 0400 message and
the remote host will response the requester with a 041 0 message.
However for non-interactive reversal transaction, the identifier would
be 0420 message and would be responded with a 0430 message.
•
• An example when a reversal message is being sent out is when a
previous successful financial transaction (02XX) is being voided at
credit card terminals. Reversal messages are also being sent out
automatically when the requester does not receive a response in a
certain time frame (time out situation). T his kind of reversal
message is being termed as auto-reversal messages. W hen a
reversal message does not receive a response in time (transaction
timed out), the requester will repeat sending the previous reversal
message, and this is called repeat reversal messages. Repeat
reversal messages have an identifier of 0401 for interactive
transactions and 0421 for non-interactive transactions.

18. • Bit map(s) follows the Message T ype Identifier. A single bit
map consists of sixty-four (64) bits or sixteen (1 6)
hexadecimal characters positioned from left to right. Each bit
denotes the presence or absence of the corresponding data
element.
• Two bit maps can exist on an IS O 8583 message. However
the primary bit map must always be present. T he primary bit
map signifies the presence of data elements 1 to 64 and the
secondary bit map indicates the presence of data elements 65
to 1 28. Each data element represents a certain usage in the
standard IS O 8583 message. Most commonly used data
elements are usually represented in the primary bit map.

19. Thank You and Questions
orlando@trainingheights.net
N.B: Content and Diagrams from CMMI Institute and
ISO 25000 Series

20. ?
QUESTIONS
THANK YOU
234-8037154520
orlando@g4vonline.com www.trainingheights.net/
linkedin.com/orlando-olumide-odejide-a7b79927