Messaging Standards in Fast Payments | A

FOCUS NOTE

MESSAGING STANDARDS
IN FAST PAYMENTS
Part of the World Bank Fast Payments Toolkit

FEBRUARY 2022
B | Fast Payment Systems: Preliminary Analysis of Global Developments

FINANCE, COMPETITIVENESS & INNOVATION GLOBAL PRACTICE

Payment Systems Development Group

© 2022 International Bank for Reconstruction and Development / The World Bank
1818 H Street NW
Washington DC 20433
Telephone: 202-473-1000
Internet: www.worldbank.org

This volume is a product of the staff of the World Bank. The findings, interpretations, and conclusions expressed in this
volume do not necessarily reflect the views of the Executive Directors of the World Bank or the governments they represent.

The World Bank does not guarantee the accuracy of the data included in this work. The boundaries, colors, denominations,
and other information shown on any map in this work do not imply any judgment on the part of the World Bank
concerning the legal status of any territory or the endorsement or acceptance of such boundaries.

RIGHTS AND PERMISSIONS

The material in this publication is subject to copyright. Because the World Bank encourages dissemination of their
knowledge, this work may be reproduced, in whole or in part, for noncommercial purposes as long as full attribution
is given.
CONTENTS

SETTING THE CONTEXT AND BACKGROUND   2

1. INTRODUCTION TO MESSAGING STANDARDS   4
2. COMPARATIVE ANALYSIS OF MESSAGING STANDARDS   6
2.1. Summary  7
2.2. Detailed Comparative Information  8
3. IMPLICATIONS OF MESSAGING STANDARDS   16
3.1. Linkage between Transaction Flow and Processing Steps with
Messaging Standards  16
3.1.1. Proxy Verification Flow  17
3.1.2. Successful/Rejected Transaction Flow  18
3.1.3. Request to Pay  19
3.2. Customer-Authentication Models  19
3.2.1. ISO 8583   21
3.2.2. ISO 20022   21
3.2.3. Proprietary  22
3.3. System Performance and Scalability  22
4. PAYMENT SYSTEM OPERATORS’ EXPERIENCE WITH PROPRIETARY SYSTEMS   25
5. CONCLUSION  27
5.1. Decision Framework  27
5.2. Key Takeaways  29

APPENDIX A: Structure of ISO 8583 Message   32

APPENDIX B: Comparative Analysis: Parameter Field Length   33
APPENDIX C: Comparative Analysis: Parameter Remittance Information   34
APPENDIX D: Comparison of UTF-8 and ASCII   35
APPENDIX E: Scope of RTPG   35
APPENDIX F: ISO 8583 Message Linkage   36
APPENDIX G: ISO 20022 Message Linkage   37
APPENDIX H: Proprietary Message Linkage   40
APPENDIX I: Authorization <Authstn> details   41
APPENDIX J: Authentication <Authntcn> Tag Details   41
APPENDIX K: UPI: Mobile Binding Process   42

| 1
 SETTING THE CONTEXT
AND BACKGROUND

SETTING THE CONTEXT

The World Bank has been monitoring closely the development of fast pay-
ment systems (FPS) by central banks and private sector players across the
globe. This comprehensive study of FPS implementations has resulted in a
policy toolkit. The toolkit was designed to guide countries and regions on
the likely alternatives and models that could assist them in their policy and
implementation choices when they embark on their FPS journeys. Work on
the FPS Toolkit work was supported by the Bill and Melinda Gates Founda-
tion. The toolkit can be found at fastpayments.worldbank.org and consists
of the following components:

1. The main report, Considerations and Lessons for the Development and
Implementation of Fast Payment Systems

2. Case studies of countries that have already implemented fast payments

3. Short focus notes on specific technical topics related to fast payments

This note is part of the third component of the toolkit and aims to provide
inputs on the technical implications of messaging standards used in pay-
ment systems with a focus on fast payments. This topic is of relevance as
new players enter the payment service industry and as fast payments con-
tinue to mature in many markets.

2 |
BACKGROUND

The mass adoption of fast payments and changing business dynamics around
the globe have created an environment in which upgrades, along with new
implementations, are becoming a key trend in the payments industry. Costs
and risks are associated with such tasks, but with deep research and prior
knowledge of the factors, operators can mitigate the risk and lead to benefits
for society as a whole.

This technical note on messaging standards addresses the key questions

that implementors face when choosing messaging standards (ISO 8583, ISO
20022, or proprietary) while implementing fast payments. The first section of
this note presents a brief introduction of messaging standards. The second
section presents a comparative analysis of the following aspects of messaging
standards: message specification, standard characteristics, and operational
capabilities. The third section analyzes the impact of messaging standards on
transaction flow and processing steps, customer-authentication models, and
performance and scalability. The fourth section addresses the experience of
payment system operators with proprietary systems. The last section presents
key takeaways and proactively provides a decision framework for choosing
message formats while implementing fast payments.

| 3
1 INTRODUCTION TO MESSAGING STANDARDS

“A messaging standard defines the syntax, structure, and semantics of a family of messages that are
exchanged between counterparts.”1

A messaging standard defines the syntax, structure, and processes, it is the messaging standard used most for card
semantics of a family of messages that are exchanged transactions processed globally.
between two or more parties trying to communicate and Since its inception, three versions have been released—
transfer information. Globally, three main types of messag- ISO 8583:1987, ISO 8583:1993, and ISO 8583:2003. The
ing standards are used in FPS: ISO 8583, ISO 20022, and most common version remains ISO 8583:1987, which is used
proprietary. by dominant card-based payment providers, such as Mas-
According to IBM, a messaging standard “defines the tercard and Visa.
syntax, structure, and semantics of a family of messages The ISO 8583 messaging standard comprises the follow-
that are exchanged between counterparts.” These stan- ing three parts:2
dards are necessary for allowing a common understanding
of transmitted data across linguistic, regional, or system • Part 1: Interchange message specifications
boundaries. Using a messaging standard ensures that the • Part 2: Application and registration procedures for Insti-
data exchanged is understood correctly and is machine tution Identification Codes (IIC)
friendly, resulting in cost reduction and efficiency. In addi- • Part 3: Maintenance procedures for codes
tion, messaging standards describe the fields/data elements
that are part of a message and can be used for various use Each payment message that uses this standard is identified
cases. In some cases, the definition and usage of the hier- by a four-digit message type indicator (MTI), in which each
archical messages is also provided where multiple messages digit has its own significance. The first digit indicates the
are to be exchanged between two parties. version of the messaging standard, the second digit denotes
the message class, the third digit provides the message
function, and the fourth digit indicates the origin of the
ISO 8583
message. (For details on ISO 8583 MTIs and the significance
Originally published by the International Organization for of each digit, refer to appendix A.)
Standardization (ISO) in 1987, ISO 8583 has been at the The Faster Payment System in the United Kingdom,
core of payment systems for many payment system opera- Immediate Payment Service (IMPS) in India, and Transferen-
tors, banks, and other financial institutions across the globe. cias en Línea (TEF) in Chile are systems that are based on ISO
Though usage is restricted mostly to legacy systems and 8583 messaging standards.

4 |
 Messaging Standards in Fast Payments | 5

ISO 20022 • Account management (acmt.XXX.XXX.XX)

• Administration (admi.XXX.XXX.XX)
Revered as the global standard for the exchange of elec-
tronic messages between financial institutions, both for • Cash management (camt.XXX.XXX.XX)
payment as well as nonpayment transactions, ISO 20022 is • Payment remittance advice (remt.XXX.XXX.XX)
now the messaging standard that most FPS utilize. The ISO
introduced it in 2004 to provide a standardized platform for The Clearing House Real Time Payments (TCHRTP) in the
message development in one eXtensible Markup Language United States, New Payments Platform (NPP) in Australia,
(xml) rulebook. and Fast and Secure Transactions (FAST) in Singapore are
ISO 20022 is based on a flexible framework that allows FPS that use the ISO 20022 messaging standards.
user communities and message-development organiza-
tions to define message sets on internationally agreed
PROPRIETARY
approaches, using business semantics. Using richer, higher
standardization, quality, and carrying capacity of data than Proprietary payment messages are a unique message format
other standards, ISO 20022 easily adapts and is driving defined by a country/region/monetary authority for facilitat-
improved payment outcomes by providing both structured ing payments. This messaging format is generally localized
and unstructured data fields. and requires extensive adoption by the entire payment eco-
ISO 20022 has formed the Real Time Payments Group system to be successful. Proprietary messages can be XML
(RTPG), comprising board members from more than 17 based, such as ISO 20022 messages, or non-XML based, such
countries, to bring international users together to create as ISO 8583 or SWIFT MT messages. Proprietary messages
global market practices. The group’s objective is to docu- offer high levels of customization and can take advantage
ment a consistent and harmonized view of ISO 20022 mes- of the acquired experience/resources of a payment system
sage components, business processes, elements, and data implementor, enabling common platforms and fewer user
content with respect to FPS in different market implemen- training requirements.
tations. Both the Unified Payments Interface (UPI) in India and
ISO 20022 is very detailed and divided into 32 message Sistema de Pagos Electrónicos Interbancários (SPEI) in Mex-
types.3 The most common types used can be understood as ico are examples of FPS with a proprietary messaging for-
the following: mat. Both use XML-based message formats.
• Payment initiation (pain.XXX.XXX.XX)
• Payment clearing and settlement (pacs.XXX.XXX.XX)
2 COMPARATIVE ANALYSIS OF MESSAGING STANDARDS

The purpose of this section is to bring out the various char- as lacking, basic, and/or comprehensive on the basis of each
acteristics of the three most-used messaging standards in parameter examined, and detailed information backing up
FPS around the world—ISO 8583, ISO 20022, and propri- the summary table. The detailed analysis is done based on
etary. This section is divided into two subsections: an over- the 14 parameters and three categories shown in table 1.
view of the messaging standards, with functionalities listed

TABLE 1 Categorization of Parameters Used for Research on Comparative Analysis of Messaging Standards
PARAMETER CATEGORY PARAMETERS PARAMETER DESCRIPTION

Message • Message format Comparison based on the messaging standard format

specifications
• Field length Comparison based on the length of the most-used fields in transaction messages
• Message size Comparison of overall size of similar messages of different standards
• Remittance information Comparison of amount of remittance-information carrying capacity of a
messaging standard
Standard • Character set Comparison of messaging standards’ openness to accommodating different
characteristics characters and languages
• Message customization Comparison of the extent of customization feasible in a messaging standard
• Message standardization Comparison of the extent of standardization in a messaging standard
• Scheme maintenance Comparison of the frequency of updates and change/maintenance requests from
the standard
• Future prospect Predictive comparison of the messaging standards
• Nonpayment Comparison of the ability to carry nonpayment information
information
Operational • Interoperability Comparison based on capability of messaging standard for multiple FPS
capabilities collaborations
• Operational Comparison of messaging standards based on convenience of operations
considerations
• Data analytics Comparison of messaging standards based on the ability to support data
compatibility analytics
• Ease of reconciliation Comparison based on support for auto and manual reconciliation

6 |
 Messaging Standards in Fast Payments | 7

FIGURE 1 Research Methodology for Comparative Analysis of Messaging Standards

QUANTITATIVE QUANLITATIVE
Based on the data available for a Used the secondary data available
standard, on which comparative to build comparisons between
analysis is done for reaching the
outcome. For example: Field Length
as a parameter has been compared
for sample fields available in different
+ the messaging standards. For
example: Schema maintenance as
a parameter has been compared
based on the past updates and the
= RESEARCH
METHODOLOGY

messaging standards to arrive at the openness for new updates.

conclusion

2.1 SUMMARY TABLE 2 Summary of Messaging Standards Based on Parameters

The comparative analysis of messaging standards PARAMETER ISO 8583 ISO 20022 PROPRIETARY
is done using mixed methodology in which both Message format   
quantitative and qualitative research is done to Field length   
integrate perspectives.
Message size   
Table 2 maps the three messaging standards
Remittance information   
against the parameters for comparison with respect
Character set   
to FPS. The representation is done in a way that
allows the comparison of two parameters if a Message customization   

parameter is a benefit of more than one messaging Message standardization   

standard. Scheme maintenance O  

ISO 8583 defines the majority of the fields/data Interoperability   

elements as standard but also has a few reserved Future prospect   

fields for passing implementation-specific informa- Operational considerations   
tion. These fields are unstructured and allow data to Nonpayment information   
be entered in free-text ASCII or binary format. ISO Data analytics compatibility   
8583 is the standard of choice where infrastructure Ease of reconciliation   
capabilities such as storage and network efficiency
 Lacking   Basic   Comprehensive
are weak, because it is smaller than other messag-
ing standards. Recently, there have been no updates
to the messaging standard; the last version was released in the messages in the standard, based on change requests
2003, and no major future modifications are anticipated. raised by the participants and approved by a committee
The use of unstructured data, a lack of fields, such as remit- comprising members from various nations holding differ-
tance information, and limited field lengths adversely affect ent interests. The standard fares well in the capacity to carry
the standard’s operational (handling customer claims, return remittance information in both structured and unstructured
requests, reports generation, and value-addition tasks such format. This information can be used for auto reconcilia-
as new product offering) and reconciliation capabilities. tion of invoices and helps in bookkeeping, in addition to
ISO 20022 is considered as the global standard for the providing support to data analytics tools. Overall, the stan-
exchange of electronic messages between financial insti- dard is best suited when network capacity is stronger, and
tutions. It offers standardized messages with the capacity the requirement is to have a standardized message with a
to carry both structured and unstructured data. Although higher data-carrying capacity. As one of the most accepted
the standard has field lengths greater than such previous international standards, it leads to high feasibility of interop-
standards as ISO 8583, there are also unstructured subfields erability with other schemes and systems
present in key fields, such as address, which can be used Proprietary messages are uniquely defined for a coun-
in addition to the structured fields, thus enhancing the try/region and are best suited for addressing niche require-
data-holding capacity. There are regular yearly updates for ments. They can take up any format or structure or support
8 | Messaging Standards in Fast Payments

any character set. Because of this, they are preferred when B. ISO 20022 
local languages are to be used during a transaction. Pro- ISO 20022 offers both structured and unstructured fields.
prietary messages are the most customizable messages; The structured fields help distinguishing the components
the field presence and lengths can be customized to meet of a field. For example, ISO 20022 has structured fields for
local requirements, which can save considerable operational address, which means the address field is further divided
costs. Due to the extent of customization, they lack the into subfields such as building number, street name, city,
standardization that is essential for cross-border payments, state, and so on. In addition to these subfields, unstruc-
but with the use of middleware, there have been successful tured address lines can be used to carry additional data
implementations of interoperability. Proprietary messages for the user.
are the standard of choice when the implementors pre-
C. Proprietary 
fer flexibility over standardized messages, or when niche
Proprietary messages are uniquely defined, specific to
requirements cannot be fulfilled by the available messaging
an FPS for a country/region. They have the advantage
standards.
of modification as per requirements but require care-
ful analysis of current and future scope while designing
2.2 DETAILED COMPARATIVE INFORMATION the structure. In proprietary standards, format acts as an
advantage, as the system can be built to match the legacy
Each parameter evaluated for the messaging standards can
systems, avoiding the translation time, cost, and effort.
be categorized as a benefit or limitation of that particular
standard based on the methodology adopted. The legends 2. FIELD LENGTH
below were used to summarize the comparison.
Overview
Benefit  This parameter compares the standards based on the
Limitation  most common fields, such as name, address, amount,
Neutral  account number, institution, and transaction identifiers.
For large data sets, ISO 8583 is limited to capturing the
Undetermined 
data in the defined fields. For example, address fields
may be unable to carry the detailed address of a propri-
1. MESSAGE FORMAT
etary business where “care of” details are also present.
Overview ISO 20022 has structured fields with ample space to cap-
This parameter compares the messages based on the for- ture such details. For proprietary messaging standards,
mat that the messaging standard follows. Both ISO 8583 field lengths can be customized as per the requirements,
and ISO 20022 have clear definitions of the message making it a suitable option.
structure and fields. On the other hand, message struc-
ture and fields in proprietary messages can be defined A. ISO 8583 
as per requirements. While ISO 8583 has unstructured ISO 8583 has shorter field length than ISO 20022, while
fields, ISO 20022 has both structured and unstructured comparison with proprietary messaging standards can-
fields. Proprietary messaging standards can leverage the not be defined, as the field length is customizable. (For
customization and define fields to meet the require- details on the ISO 8583 field lengths used for compari-
ments of legacy systems, saving translation time, cost, son, refer to appendix B.)
and effort. B. ISO 20022 
A. ISO 8583  ISO 20022 has a greater number of defined fields and
ISO 8583 has 128 fields/data elements (as defined in ISO longer field lengths than ISO 8583. Comparison with
8583:1987, but this can go up to 192 elements, as defined proprietary messaging standards cannot be defined, as
in later releases) that can store unstructured data—that the field length is customized to the FPS implementation
is, data that is in free-text format. In these data elements, requirement. (For details on the ISO 20022 field lengths
the data present might not be distinguishable from the used for comparison, refer to appendix B.)
various components present. For example, in the address C. Proprietary 
fields, the street name and building name might not be Proprietary messages are highly customizable. This adds
easily identified separate from the entered data. the flexibility to introduce new fields and define the
length to meet the requirements while implementing.
 Messaging Standards in Fast Payments | 9

(For details on proprietary the field lengths used for business use cases. ISO 8583 lacks predefined remittance
comparison and taking UPI as an example, refer to fields, while for proprietary messages, it depends on the
appendix B.) implementation.

3. MESSAGE SIZE A. ISO 8583 

There is no predefined remittance field, but custom
Overview
fields are reserved for national use (57–60 and 112–119)
This parameter is to compare the standards based on the
and private use (61–63 and 120–127), and each field is
size of message. The size of the transaction message var-
999 characters long. The implementors and financial
ies with the messaging standard chosen for the scheme.
institutions can use these fields to capture remittance
Both ISO 8583 and proprietary messages are most suit-
information.
able if message size is the key consideration. ISO 8583 has
(For details on the ISO 8583 remittance information
a small size that is largely attributed to fewer fields and a
fields, refer to appendix C.i.)
binary or ASCII data format. ISO 20022 consumes much
more space than ISO 8583, while proprietary messages B. ISO 20022 
can be defined in a way that makes minimum tags/fields ISO 20022 provides rich remittance information in the
mandatory, saving on space. ISO 20022 is approximately multiple fields available at a granular level. The remit-
five times bulkier than ISO 8583, while implementors of tance information can be structured or unstructured or
proprietary messages in Mexico claim ISO 20022 is seven both, and it can be sent with the payment or a separate
times heavier than their proprietary implementation. message can be sent with the remittance information
of the original payment (by providing a reference to the
A. ISO 8583 
original payment). (For details on the ISO 20022 remit-
The size of the payment messages is smaller in ISO 8583
tance information fields, refer to appendix C.ii.)
format than in ISO 20022. This is due to the adoption of a
binary format, along with the limited amount of informa- C. Proprietary 
tion being transferred. Hence, less bandwidth is required Proprietary messages have the flexibility of adding remit-
to process these transactions. tance information as per the requirement. Thus, imple-
mentors can choose to provide remittance information
B. ISO 20022 
fields and customize the lengths. (For details on propri-
Message size is larger than ISO 8583. Hence, compara-
etary remittance-information fields and taking UPI as an
tively greater bandwidth is required to process transac-
example, refer to appendix C.iii.)
tions and may create capacity and performance issues
for regions that lack good infrastructure connecting end 5. CHARACTER SET
users, payment service providers (PSPs), and the FPS
Overview
operator.
Character sets are the different characters that can be
C. Proprietary  used and are supported by a messaging standard. This
Message size for proprietary messages varies with the parameter helps to establish the different characters in a
implementation, format, character sets, and type of infor- messaging standard that are available for use while trans-
mation contained in a message. This cannot be gener- mitting a payment/nonpayment transaction message.
alized, but the implementors have the advantage of Proprietary messages are the best suite for character-set
choosing the message attributes to fit the requirements support, as local languages can also be part of propri-
and meet the data-handling capacity of the system. etary messages, while both ISO 8583 and ISO 20022 do
not support that. ISO 8583 is based on ASCII or binary,
4. REMITTANCE INFORMATION while ISO 20022 supports UTF-8 characters. (For a com-
Overview parison of UTF-8 and ASCII, refer to appendix D.)
Remittance information is used by financial institutions to
A. ISO 8583 
establish the link between the transaction and the pur-
ISO 8583 messages can be encoded in either an ASCII or
pose of the transaction. This parameter compares the
a binary character set, where ASCII is the most-used char-
messaging standards’ capability to carry remittance-re-
acter set. In ASCII format, the message type is four bytes
lated information. ISO 20022 messages are the most suit-
long, as the ASCII-coded characters are sent as text, while
able, as they have clearly defined remittance fields, with
in binary encoding, the message type is two bytes long.
both structured and unstructured data used for various
10 | Messaging Standards in Fast Payments

The ASCII character set is limited to 256 characters, The fields 57–60 and 112–119 are reserved/avail-
which might not be enough to represent different lan- able for national use, and fields 61–63 and 120–127 are
guage structures. reserved for private use. Only these fields can be used to
carry proprietary information not included in the defined
B. ISO 20022 
fields.
ISO 20022 uses XML 1.0, which supports UTF-8 (encodes
characters of variable length using one to four eight-bit B. ISO 20022 
bytes), UTF-16 (encodes characters of variable length ISO 20022 defines a standard set of fields, tags, and the
using two or four eight-bit bytes), and many more. Since structure of the message, with limited customization
UTF-8 is the most efficient method to transport char- options. The customization comes into play when imple-
acters lengthwise, ISO 20022 uses only UTF-8. The only menting schemes, when the optional fields are made
exception is exotic characters, for which UTF-8 becomes mandatory at the scheme end as per the business use
lengthier, but these characters are rarely required in ISO cases.
20022 messages. ISO 20022 also provides some unstructured fields,
ISO 20022 does not support local languages, for which can be used to capture information for which
which a workaround needs to be crafted. For example, structured fields are not present or information is big-
to continue the use of local languages and special char- ger than the space provided. In addition, based on the
acters in implementation in the Single Euro Payments implementor, a type of message can have different pur-
Area, a broader character set was defined, along with a poses. For example, pacs.008 with structured remittance
conversion table and best practices, while migrating to information carrying the unique transaction code of the
ISO 20022. original transaction acts as a payment return message in
RTP in the United States, while returns are done using
C. Proprietary 
pacs.004 message in NPP in Australia.
Proprietary messages are advantageous in that the user
can choose the character set and is not bound by an C. Proprietary 
external entity governing the messaging standard. This Proprietary messages are the most customizable mes-
means that proprietary messages can support local char- sages and are not governed by an external organiza-
acters that are otherwise not supported by ISO 8583 tion. This permits solutions to be implemented for the
or ISO 20022. For example, UPI in India supports the requirements in any phase of the FPS without external
UTF-8-character set. interference and certifications required. For example,
UPI in India has tags to capture the geocode, location, IP,
6. MESSAGE CUSTOMIZATION operating system, and so forth of both the payee’s and
Overview the payer’s mobile devices used to make the transaction.
This parameter takes into consideration the ability to
Key Takeaways
customize a messaging standard to adapt and imple-
Proprietary messages are the most customizable mes-
ment any specific requirement or use case. Proprietary
sage formats, permitting the implementor to customize
messages are the most customizable message formats,
at the most granular level according to the requirements,
permitting the implementor to customize at the most
while both ISO 8583 and ISO 20022 are governed by an
granular level according to the requirements, while both
international body, thus making changes to the struc-
ISO 8583 and ISO 20022 are governed by an interna-
ture/fields difficult, as the changes go through various
tional body, thus making changes to the structure/fields
level of review and approval.
difficult, as the changes go through various levels of
review and approval. 7. MESSAGE STANDARDIZATION
A. ISO 8583  Overview
ISO 8583 provides limited options for customization, as This parameter highlights the level of standardization in
it defines many standard fields that remain the same in a messaging standard. Message standardization makes it
all systems. It provides only limited fields for passing net- easier for interoperability and ease of access/understand-
work-specific details. For adapting the standard for own ing for users using different FPS systems. ISO 20022 is
use, the network-specific fields are used to provide cus- the most standardized message, with predefined struc-
tom usages. ture, syntax, and format, followed by ISO 8583 and pro-
prietary messages.
 Messaging Standards in Fast Payments | 11

A. ISO 8583  that organizations using the standard need to migrate to

ISO 8583 defines many standard fields (data elements) new version. A classic example is ISO 8583:1987: the old-
that remain the same in all systems. ISO 8583:1987 (the est version is most widely used. This version is used by
most common version) has a total of 128 data fields, Visa and Mastercard.
of which 96 fields are standardized—that is, they are
B. ISO 20022 
defined by the standard and, hence, have the same
Considering the vast scope covered by ISO 20022, the
meaning in various implementations.
authority publishes regular updates. In general, there are
B. ISO 20022  yearly updates at the message-type level, rather than the
ISO 20022 is more standardized than the other two types entire set of messages. The updates are done based on
of messages. The business message syntax is internation- the change requests shared by the partner, and since the
ally agreed, and developers and user organizations make standard is governed by a central entity, the updates are
use of common message structure, form, and meaning done at the global level.5
to exchange transaction information globally. As the Only those change requests that are approved are
standard is not controlled by a single interest or party, included in the future versions of a message type. This
anyone in the financial services industry can use it.4 means that if country- or region-specific changes are to
ISO 20022 created the RTPG with the objective of be made, they might not be included in the standard,
bringing members of the international payments com- leaving little room to accommodate such changes.
munity together to focus on standard market practices. A new version of a message type may not necessar-
The focus is to build a global market practice for ISO ily mean that the participants need to migrate to that
20022 in a retail real-time system by providing founda- version. It is on the payment operator of the schemes to
tion-level usage guidelines that can be enhanced as per decide to take action. If the payment operator does not
the requirements. It covers different real-time payment migrate to the newer version, the operator risks skipping
use cases covering overlay services and request-to-pay the new features and the change requests as part of the
transfers besides the basic credit transfer. release. In addition, in case of interoperability, if one of the
(For details on the scope of the RTPG, refer to appen- party migrates but the other doesn’t, translators would be
dix E.) required to find common ground between the parties.

C. Proprietary  C. Proprietary 
Proprietary messages are the least standardized mes- Proprietary messages are the most flexible in terms of
sages. Even if they are built on the same messaging schema maintenance, as they can be updated as and
format, language, or structure, integrating a proprietary when the requirement changes for the region/payment
system with another proprietary or standardized system operator. They are not governed by an international
requires extensive research and a compatibility check. entity; thus, the changes are at a local level and, hence,
require less scrutiny and research into the impact of
8. SCHEME MAINTENANCE these changes.
Overview On the other hand, building and maintaining a pro-
Schema maintenance is used for providing regular updates, prietary solution would involve considerable time, cost,
fixing bugs, and addressing new/changed requirements. and effort. Proprietary standards need to maintain an
This parameter compares the messaging standards on appropriate level of governance and schema manage-
the openness for schema maintenance. Schema main- ment frameworks. If the scheme lacks documentation
tenance is the easiest with proprietary messages due to and processes for business continuity, coding is inher-
localized development and maintenance, followed by ISO ently opaque and hard to understand.
20022, where yearly updates are provided based on open
change requests. ISO 8583 is the least favorable because 9. INTEROPERABILITY
of a lack of updates in recent years. Overview
Interoperability in this context refers to two or more
A. ISO 8583 
systems communicating with each other so that par-
Version updates of ISO 8583 are infrequent, and there are
ticipants/users from one system can transact with par-
only three versions: 1987, 1993, and 2003. This means that
ticipants/users in the other systems participating in the
the schema is not changed easily with changes in business
interoperability arrangement. Because of the standard-
requirements. In addition, a new version does not imply
12 | Messaging Standards in Fast Payments

ization, the availability of a vast number of fields, and While various payment systems are eyeing interopera-
the capacity to carry structured data, ISO 20022 is most bility by leveraging common standards, the use of ISO
favorable for interoperability, while proprietary messages 20022 provides further flexibility in implementation. For
would require translators/converters/development for example, solution operators and service providers that
interoperability, making them least favorable. implement ISO 20022 standards may employ various
types of data elements that meet their specific use cases,
A. ISO 8583 
and these elements may vary across different geogra-
ISO 8583 has unstructured fields and an absence of pre-
phies or different types of users that need to interact
defined key fields, assisting cross-border payments. Due
with each other.
to the absence of structured fields, the data interpreta-
tion may not be the same in different countries/regions. C. Proprietary 
For example, assuming “ABCDE” is a building that is a Proprietary messages are least interoperable because
restricted entity in the creditor’s country, when data such they are more localized than standardized. To be interop-
as “ABCDE Avenue” (that is, the name of the street not erable with the proprietary messages, either party or
linked to the building ABCDE) is entered in the unstruc- both parties in the FPS interoperability arrangement
tured address field for the transaction, it may lead to a need to use translators to have a common communica-
false anti-money-laundering or sanction hit in case of tion medium between them. For example, UPI, which
interoperable systems. SWIFT6 estimates that approxi- is based on the XML format, has tags that are different
mately 10 percent of international payments are delayed than those in ISO 20022 or another proprietary imple-
for compliance checks as false positives and wasted mentation; hence, for such interoperability, a translator
investigations. That is a significant volume; a marginal is required to map the messages between the two pay-
decrease could save organizations considerable opera- ment schemes. In addition, the complexity increases with
tional costs and enable faster international payments for variance in mandatory and nonmandatory fields.
customers. However, there are examples of integration of BHIM
No examples of collaboration between two FPS oper- UPI with Singapore, where the integration is done based
ating on ISO 8583 are known. on the QR code. Any UPI user can scan a code at a mer-
chant registered with NETS to accept UPI payments and
B. ISO 20022 
make the transactions. The payments are debited in
ISO 20022 is the preferred method for interoperability
Indian rupees, while the merchant is credited in Singa-
due to standardization and wide acceptance. One of the
pore dollars.
key improvements over other standards and steps toward
UPI in India has integrated with the National Electronic
interoperability is the implementation of structured
Toll Collection (NETC) platform in India to allow seamless
address fields. With defined and consistent fields such as
recharging of the prepaid toll-payment device FASTag by
Street Name, Building Number helps prevent false pos-
initiating the transaction directly from the BHIM UPI appli-
itive sanction hits. For example, assuming “ABCDE” is a
cation. The user needs to enter the UPI ID in a predefined
building that is a restricted entity in the creditor’s coun-
format (Vehicle_number@Issuer Bank) and directly add
try, when data such as “ABCDE Avenue” (that is, the name
the recharge amount with the help of PIN authentication.
of the street not linked to the building ABCDE) is entered
The transaction flows between two different platforms
in the ISO 20022, it will be entered in a structured street
that have their own defined messaging standards.
field. With the help of that field, the sanctions system
can easily identify and differentiate it from the restricted 10. FUTURE PROSPECT
entity.
Overview
A common messaging format and business process
This parameter helps examine the future prospects of
standards are the backbone for a payment system with
a messaging standard and what to expect from the
lower operational complexity and greater consistency.
standard in the near future. ISO 20022 is emerging as
The following are examples of live ISO 20022 interop-
a global standard since it has the ability to adapt to
erable systems:
new technologies and advancements in the payments
1. PromptPay (Thailand) and PayNow (Singapore) in domain, while proprietary messaging standards would
April 2021 be the standard of choice when the requirements are
2. PromptPay (Thailand) and DuitNow (Malaysia) in June niche and not generic.
2021
 Messaging Standards in Fast Payments | 13

A. ISO 8583  • Further, rich payment data allows digital reconcilia-

ISO 8583 is an international standard for payments orig- tion. This offers banks the opportunity to reevaluate
inated from cards. It also has deep roots in the banking their business models and market positioning.
industry, and it would require considerable investment to
C. Proprietary 
migrate away from it.
Proprietary messages are being used by countries/oper-
In the fast payment space, there are examples such
ators that want to leverage their existing infrastructure or
as PromptPay in Thailand, where, rather than migrating
have specific requirements that cannot be met by using
all at once to ISO 20022, the implementors have granted
the global standards—for example, capturing details
flexibility to participants to migrate at their own pace. In
about the mobile devices used for transactions done
the transition period, translators are being used to con-
by UPI (such as the geocode, IP, operating system, and
vert ISO 8583 messages originated from financial institu-
so on) that cannot be captured by either ISO 8583 or
tions to ISO 20022, so that all parties in a transaction are
ISO 20022. Such requirements can be met only by using
on the same ground. There are also examples such as TEF
proprietary messages, and, thus, the implementors rely
in Chile, which has no plans to migrate to another stan-
heavily on proprietary messages. As today’s world is mov-
dard and will continue using the standard for its existing
ing toward interoperability and cross-border payments,
FPS system.
the requirement is to build an inclusive system where
No major changes are expected in the ISO 8583 format.
exclusive fields (unavailable in other standards) should
B. ISO 20022  be nonmandatory.
ISO 20022 is emerging as an open global standard for
payments data and is the expected future standard of 11. OPERATIONAL CONSIDERATIONS
fintech innovation and competition. Overview
• ISO 20022 has formulated the RTPG to deliver usage This parameter distinguishes the standards based on the
guidelines for ISO 20022 as a global market practice operational factors, abilities, or issues related to the work-
for retail real-time payments. The group is currently ing of systems implemented using the three different
focused on interbank payment messaging but plans messaging standards. ISO 20022 is a heavier message
to cover payment initiation, settlement, and remit- but comes with benefits such as easier troubleshoot-
tance data as well. ing, compliance with global standards, and so on, while
ISO 8583 is a lighter message that is harder to operate
• ISO 20022 utilizes a rich data format promising higher
because of format and structure limitations. Proprietary
quality than other standards. This leads to improved
messages cannot be generalized but, in general, are
payment outcomes that adapt to new requirements
designed to comply with local standards and context.
and are not controlled by a single beneficiary/user/
party but representatives from different parts of the A. ISO 8583 
globe. • ISO 8583 messages are lighter and require less band-
• ISO 20022 banks on more transparency and bet- width and storage space.
ter remittance information for customers than other • ISO 8583 troubleshooting is difficult, as ASCII or binary
standards. This means improved analytics, less human digits need to be converted to drive meaning.
intervention, accuracy in compliance processes, and
• ISO 8583 uses consistent standards, resulting in fewer
the performance of multilevel fraud checks. All this
processing errors.
leads to enhanced customer experience.
• A lack of predefined remittance fields leads to higher
• A foundation for end-to-end automation, leveraging
manual interventions in case of reconciliation and
a single standard for all business domains and pro-
returns.
cesses, leading to enhanced straight-through pro-
cessing (STP). B. ISO 20022 
• According to SWIFT,7 almost 200 market-infrastruc- • With ISO 20022, troubleshooting and maintenance
ture-driven initiatives are implementing the ISO 20022 are faster, as the standard employs flexible and mod-
standard or are considering adopting it for payments ern technologies and a globally accepted language,
and securities-transformation projects. resulting in simpler translation.
14 | Messaging Standards in Fast Payments

• ISO 20022 uses consistent standards, resulting in B. ISO 20022 

fewer processing errors. ISO 20022 has made different nonpayment messages
• Since ISO 20022 is a standard format, it allows faster available for use. These nonpayment messages are used
deployment with less customization per financial for such purposes as reconciliation, cash management,
institution. and account management. The following are the most
commonly used nonpayment messages9 in faster pay-
• ISO 20022 allows the use of rich data sets to drive
ment implementations across the globe:
compelling business intelligence.
• camt.054: Bank to customer debit credit notification
ISO 20022 complies with changing global requirements,
• camt.055: Customer payment-cancellation request
such as requirements from the Financial Action Task
Force, anti-money-laundering and know-your-customer • camt.056: Financial institution to financial institution
requirements, extended remittance data, and so on. payment-cancellation request

C. Proprietary  • pain.002: Customer payment status report

Proprietary messages may/may not have structured data, • remt.001: Remittance advice
definite positions, or format. This plays a major role in • admi.001: Administration message
operational considerations.
C. Proprietary 
• Proprietary messages can make it easier to comply
Proprietary messages have the flexibility to build non-
with the local anti-money-laundering and know-your-
payment information messages specific to a task (such as
customer checks (wherever applicable).
name verification) and may skip the implementation of
• Based on the message structure, definition, and avail- an entire set of messages. For example, UPI in India has
ability of documentation, the troubleshooting and an application programming interface named “Check
handling can be made easier. Txn Status” that allows PSPs to request the status of the
• Proprietary messages are generally not supported out transaction after the specified timeout period.
of the box by automated reconciliation software and
13. DATA ANALYTICS COMPATIBILITY
are tweaked to meet these requirements.
Overview
12. NONPAYMENT INFORMATION This parameter analyzes the openness of a messaging
Overview standard to integrate with data analytics tools to provide
Nonpayment information as a parameter relates to the useful insights for the transactions being made using the
ability of a messaging standard to be used outside the implemented FPS. The more structured the data, the bet-
actual transaction (payment) message. Nonpayment ter its readability by humans and machines and, hence,
information is available in both ISO 8583 and ISO 20022, the better the analytics. Thus, ISO 20022 is the most suit-
while proprietary messages can also implement it. The able when data analytics is the key deciding factor, fol-
extent of detail and number of messages are higher in lowed by proprietary standards and ISO 8583.
ISO 20022 than in ISO 8583, giving an advantage to the
A. ISO 8583 
former. On the other hand, for proprietary, these mes-
ISO 8583 uses “free-format” fields to define support-
sages need to be built but can be effective in meeting
ing information related to a transaction. This limits the
specific requirements.
extent of data that can be collected in a standard format
A. ISO 8583  for performing contextual analysis, thus hindering the
ISO 8583 has limited nonpayment messages,8 which are data analytics capability. For example, analytics could be
available under the following categories: used to analyze customer demographics and make offer-
ings. Since the address fields are free format, extracting
• X5XX: Reconciliation message
regions or cities would be difficult.
• X6XX: Administrative message
B. ISO 20022 
• X7XX: Fee collection message
ISO 20022 leads to more efficient financial messaging
• X8XX: Network management message by standardizing and harmonizing payments message
formats.
 Messaging Standards in Fast Payments | 15

It increases STP rates while simplifying cost-intensive A. ISO 8583 

processes such as payment processing, data analytics, Reconciliation is a cross-check method or a bookkeep-
transaction investigation, and reporting. ing method that requires detailed data for better under-
ISO 20022 allows three times more data storage than standing and readability. For a business customer (such as
previous standards, such as ISO 8583. This provides a merchant), accurate details mean a clear picture of the
improved data management, along with formulating business, including cash flows, strengths, and improve-
dashboards, which provide essential insights that give a ment areas, while for individuals, it helps in expense and
competitive advantage to implementing institutions. cash management. ISO 8583 relies heavily on unstruc-
Regulators, reporting firms, market watchdogs, and tured data and lacks predefined remittance fields,
customers require unambiguous data for analysis. For restricting the standard’s ability to provide rich data, low-
this, they place confidence in the rich and structured ering the automated reconciliation potential. Techniques
data provided by ISO 20022 messages. such as implementor’s guidelines on the usage of sepa-
The combination of the ISO 20022 migration, which rators, or specifying positions in fields to distinguish the
creates usable data, and the analytics that could be different elements present, can aid reconciliation.
applied to this data has the potential both to increase
B. ISO 20022 
significantly the access of the unbanked to financial ser-
Reconciliation is easier when the data is structured, and
vices and to create new revenue streams.
remittance fields are available.
C. Proprietary  ISO 20022 helps customers in automated account rec-
Data analytic tools use historical data, and the insights onciliation or payment management “on behalf of” other
are applied to the current business to provide better ser- parties because of the large remittance data that can be
vices, which directly relates to better revenue. To reap carried with the payment messages. Enabling easier and
the benefits of data analytics, the more structured the quicker exchange of data between customers, service
data, the clearer the insights. Since proprietary systems providers, and technology partners, ISO 20022 will fur-
do not have a defined format/structure, compatibility ther help to meet the objectives of open banking.
with data analytics tools increases as the data becomes ISO 20022 with ERI (extended remittance informa-
more structured. tion) allows the addition of detailed information about
a transaction, including linked documents, line items,
14. EASE OF RECONCILIATION extending the automated reconciliation potential.
Overview
C. Proprietary 
Reconciliation is used to compare two set of records
Reconciliation for a proprietary messaging standard is
for correctness and agreement with each other. This
subject to the implementation of the messaging stan-
parameter is used to compare the messaging standards
dard. If the messaging standard has structured data, rec-
based on reconciliation capability and the use of auto-
onciliation is comparatively easier and automated tools
mated reconciliation tools. In the context of financial
can be deployed. If the messaging standard is unstruc-
institutions, reconciliation is comparable, as the basic
tured, it would aid the process of automated reconcilia-
details required and shared are the number of records,
tion if a country/region would define the positions/fields
the total amount, and the differential, in the case of
in the message that would be used for reconciliation. If
deferred settlements. In this section, the customer-rec-
the data is unstructured and no defined places are avail-
onciliation capabilities of messaging standard will be
able, then automated reconciliation cannot be done.
compared. Reconciliation is easier when detailed infor-
Hence, reconciliation for proprietary standards largely
mation is present. Hence, ISO 20022 is more suitable
depends on the implementation of the format and can-
when reconciliation is the deciding factor, followed by
not be generalized, but proprietary messages give the
proprietary standards and ISO 8583.
flexibility to change the structure of a message to meet
this requirement.
3 PROXY DATABASES

The choice of a messaging standard has huge implications on the use cases and design implemented. However, the
on the transaction flow and processing steps, customer exchange of transaction messages and corresponding data
authentication, and performance and scalability in FPS. This fields depends on the messaging standard adopted as part
section is divided into three subsections: (i) linkage between of implementation.
transaction flow and processing steps with messaging stan- The three most widely implemented transaction flows
dards; (ii) customer-authentication models; and (iii) system in FPS have been detailed here to represent the linkage
performance and scalability. between transaction flows and processing steps with the
The subsection on linkage between transaction flow and choice of messaging standards. These flows can be lever-
processing steps with messaging standards assesses the aged to enable multiple business use cases as per the design
impact of the choice of a messaging standard by utilizing requirement during implementation. In addition, these
the four major payment flows, based on which multiple use flows can be implemented in multiple ways, and different
cases can be developed to meet the business requirements. messages provided by a messaging standard can be used
The subsection on customer-authentication models to achieve the same outcome. Here, indicative processing
assesses the impact of the choice of a messaging standard steps for transaction flows are illustrated, while alternatives,
by analyzing the fields available for carrying the custom- such as clubbing two processing steps into one or using
er-authentication details. alternative routes, are always feasible.
The subsection on system performance and scalability With a shift toward the inclusion of nonfinancial insti-
assesses the impact of the choice of a messaging standard tutions in the payment infrastructure, these players enable
by analyzing four specific aspects—message size, STP, data a wider range of customer services and features by riding
truncation, and the addition of new use cases. on the FPS. These nonfinancial institutions are represented
either as third-party players in some regions or as overlay
service providers in other regions. These third-party play-
3.1. LINKAGE BETWEEN TRANSACTION FLOW
ers or overlay service providers can be represented along
AND PROCESSING STEPS WITH MESSAGING
with channels in the transaction flows presented below and
STANDARDS
connected to a financial institution’s core payment engine
In general, the entire payments transaction, from initiation to enable use cases. The messaging standard for commu-
to completion, occurs seamlessly in a few seconds. A trans- nicating between a channel and a financial institution’s
action takes a lot of intermediate steps, including exchange core engine is defined by the financial institution or cen-
of communication messages between multiple participants tral payment scheme, and the same is leveraged by these
for transaction closure. Transaction flow between partic- third-party or overlay service providers to integrate with the
ipants varies in different payment schemes and depends ecosystem.

16 |
 Messaging Standards in Fast Payments | 17

The following flows are used in the document: cessed. The debtor’s core payment engine sends an X200
1. Proxy verification/resolution flow: Proxies or aliases message to the FPS, filling in proxy ID details using standard
make payments easy by replacing the complicated or private fields. This X200 message is then forwarded to the
and long account/card details with a simple proxy/vir- creditor’s financial institution, which responds with an X210
tual address to transfer funds or initiate other financial message carrying the verification response. The FPS then
or nonfinancial transactions. User account details are sends this response message back to the debtor’s finan-
mapped to unique proxies such as mobile numbers, cial institution. The proxy verification can be performed by
email addresses, or user-defined proxies. As part of the either the FPS or the creditor’s financial institution (as indi-
transaction flow, a name or other details are pulled from cated in the flow), based on the implementation design of
the payment scheme against the proxy for the initiator to the FPS.
verify the correct destination party. (For details on the processing steps, messages used, and
important fields, refer to appendix F.ii.)
2. Successful/rejected transaction flow: These are typical
flows of a real-time credit transfer transaction in which 2. ISO 20022
the transaction initiated by the debtor is successfully A customer initiates a transaction from the channels using
credited to the customer. Or the creditor financial insti- the proxy or alias details of the creditor party. The proxy ID
tution rejects the transaction because of issues such as details need to be verified, and creditor details such as name
when the creditor’s account is incorrect, closed, or dor- need to be fetched, to verify the creditor’s identity before a
mant, or some other restriction is placed on the creditor’s transaction is processed. The core payment engine sends an
account. acmt.023 message to the FPS, filling in proxy details. This
acmt.023 message is then forwarded to the creditor’s finan-
3. Request-to-pay flow: This flow can be used to cover
cial institution, which responds with an acmt.024 message
use cases in which a customer of a financial institution
filling in the proxy verification details. The FPS then sends
requests a payment from another customer—for exam-
this response message back to the debtor’s financial institu-
ple, a merchant requesting funds from a customer for
tion. The proxy verification can be performed by either the
services offered by the merchant.
FPS or the creditor’s financial institution (as indicated in the
(For details on the ISO 8583 and ISO 20022 message types flow), based on the implementation design of the FPS.
and the fields used in the flows below, refer to appendix F.i (For details on the processing steps, messages used, and
and appendix G.i, respectively.) important fields, refer to appendix G.ii.)

3.1.1 Proxy Verification Flow 3. Proprietary

A customer initiates a transaction from the channels using
1. ISO 8583 the proxy or alias details of the creditor party. These details
A customer initiates a transaction from the channels using need to be verified, and creditor details such as name need
proxy or alias details of the creditor party using a propri- to be fetched, to verify the creditor’s identity before a trans-
etary format or X200 messages. The proxy ID details need action is processed. The core payment engine sends a proxy
to be verified, and creditor details such as name need to be verification message to the FPS with proxy ID details. This
fetched, to verify the creditor before a transaction is pro- message is then forwarded to the creditor’s financial institu-

FIGURE 2 Proxy Verification Flow: Request Initiated by the Debtor for New Transaction

1 2 3
Core Core
Channels payment FPS payment
engine engine
6 5 4

Debtor’s financial institution Creditor’s financial institution

18 | Messaging Standards in Fast Payments

tion, which responds with the proxy verification and cred- 2. ISO 20022
itor details. The FPS sends this response message back to A payment initiated by the customer at channels is for-
the debtor’s financial institution. The proxy verification can warded to the core payment engine using proprietary for-
be performed by either the FPS or the creditor’s financial mat messages or ISO 20022-specific pain.001 messages.
institution (as indicated in the flow), based on the imple- The core payment engine sends a pacs.008 message to the
mentation design of the FPS. FPS, which, after validation, passes it to the creditor’s finan-
(For details on the processing steps, messages used, and cial institution. The creditor’s financial institution processes
important fields, refer to appendix H.i.) the transaction and sends back a pacs.002 message to the
FPS. The response message could be positive (that is, all the
3.1.2 Successful/Rejected Transaction Flow details are correct and the customer can be credited) or neg-
ative (that is, the customer cannot be credited). On receipt
1. ISO 8583
of a positive pacs.002 message from the creditor, the FPS
A payment initiated by a customer using channels of the
sends an FPS-generated pacs.002 message to the financial
debtor’s financial institution using a proprietary format or
institutions of both the debtor and the creditor for posting
X200 messages is forwarded to the core payment engine.
to their customer’s account. Otherwise, a negative pacs.002
The core payment engine sends an X200 message to the
message is sent to the debtor’s financial institution, stating
FPS, which, after validation, is passed to the creditor’s
that the transaction was rejected.
financial institution. The creditor’s financial institution
(For details on processing steps, messages used, and
processes the message and sends back a response to the
important fields refer to appendix G.iii)
FPS, using X210 messages. The response message could
be positive (that is, all the details are correct and the cus- 3. Proprietary
tomer can be credited) or negative (that is, the customer A payment initiated by the customer at channels is for-
cannot be credited). This message is be passed by the FPS warded to the core payment engine. The core payment
to the debtor’s financial institution, which takes action on engine sends a proprietary credit-transfer message to the
the transaction based on the response received and noti- FPS, which, after validation, passes it to the creditor’s finan-
fies the customer. cial institution. The creditor’s financial institution processes
Please note: In most implementations, there is no step 5 the transaction and sends a confirmation message back to
(from the scheme to the core payment engine of the cred- the FPS. The response message could be positive (that is, all
itor’s financial institution) in the flow using an ISO 8583 the details are correct and the customer can be credited)
message—that is, the creditor’s bank settles the customer’s or negative (that is, the customer cannot be credited). On
account and then sends a response to the scheme if the receipt of a positive confirmation message from the creditor,
transaction is successful. The same approach has been fol- the FPS sends an FPS-generated settlement message to the
lowed here. financial institutions of both the debtor and the creditor for
(For details on the processing steps, messages used, and posting to their customer’s account. Otherwise, a negative
important fields, refer to appendix F.iii.) confirmation message is sent to the debtor’s financial insti-
tution, stating that the transaction was rejected.
(For details on the processing steps, messages used, and
important fields, refer to appendix H.ii.)

FIGURE 3 Successful/Rejected Transaction Flow: Request Initiated by the Debtor for New Transaction

3
Channels 1 2
4 Core
Core 6 Customer
payment FPS payment
notification
Customer 5 engine
engine and advices
notification 6 5
and advices

Debtor’s financial institution Creditor’s financial institution

 Messaging Standards in Fast Payments | 19

3.1.3 Request to Pay details on the processing steps, messages used, and import-
ant fields, refer to appendix H.iii.)
1. ISO 8583
This flow is unavailable in the ISO 8583 messaging standard
3.2 CUSTOMER-AUTHENTICATION MODELS
out of the box.

2. ISO 20022 In a world of digital payments, a customer holds several

A customer raises a request for payment using channels pro- financial accounts with a single or multiple PSPs. For these
vided by a financial institution. The core payment engine accounts, the first layer of security ensured by the ser-
sends this message to the FPS in the form of a pain.013 mes- vice provider is by authenticating customers before giving
sage, and the FPS, after validation, passes it to the debtor’s them access to their account. The most common factors
financial institution. The debtor’s financial institution noti- for authentication are passwords, PINs, and other knowl-
fies the customer and requests an authorization. The autho- edge-based identifiers. Financial institutions are innovating
rization response is sent back to the core payment engine, the use of new factors, such as inherence (such as biomet-
which sends a pain.014 message back to the FPS. The FPS rics) or possession (such as using security tokens as time-
forwards the response to the creditor’s financial institution, bound dynamic codes), even combining different factors to
which notifies the customer. enhance security.
If the debtor agrees to pay, the debtor’s financial institu- Customer-authentication factors can be classified into
tion raises a new transaction on behalf of the customer, and the following broad categories:
the flow is similar to a successful transaction flow. Otherwise, a. Something the customer has (possession factors):
no action is taken, and the return request is closed. These factors include items that are physical objects,
(For details on the processing steps, messages used, and such as smart cards, smart phones, mobile binding, hard
important fields, refer to appendix G.iv.) or soft tokens, keys, and so on. These factors rely on a
unique string of random characters, numbers, or letters
3. Proprietary
generated using predefined algorithms or real-time ran-
A customer raises a request for payment by using channels
dom character generators. This string is then used to
provided by a financial institution. The core payment engine
access the system, rather than the credentials, provided
sends this request to the FPS in the proprietary format. After
the customer already has the required permissions.
message validation, the FPS passes it to the debtor’s finan-
cial institution, which notifies the customer and requests an b. Something the customer knows (knowledge fac-
authorization. The authorization response is sent back to tors): These factors include memory-based items such
the core payment engine, which sends a proprietary autho- as passwords, combinations, and PINs that are used to
rization response back to the FPS. The FPS forwards the authenticate a customer. These are the most widely used
response to the creditor’s financial institution, which notifies authentication factors. They rely on letters, numbers,
the customer. strings, or special characters, or combinations of them,
If the debtor agrees to pay, the debtor’s financial insti- in a case-sensitive format. The substitute for a customer-
tution raises a new transaction on behalf of the customer, controlled, static, knowledge-based authenticator is a
and the flow is similar to a successful transaction flow. Other- dynamically generated one-time password, which is valid
wise, no action is taken, and the return request is closed. (For only for a limited period.

FIGURE 4 Request-to-Pay Flow: Request Initiated by the Creditor

1
4 3 2 Channels
Core
Core
Channels payment FPS payment
engine
engine Customer
5 6 7 notification
8 and advices

Debtor’s financial institution Creditor’s financial institution

20 | Messaging Standards in Fast Payments

c. Something the customer is (inherence factors): These providing any financial/nonfinancial services. Use of these
factors refer to biometric authentication, in which parts customer-authentication models is also influenced by the
of the human body—the face, fingerprints, and so on— payment ecosystem of the country/region of implemen-
are used to authenticate a customer. Biometric authen- tation. Lately, only the financial institutions had access to
tication relies on the unique biological characteristics of their customer accounts and would enable payment ser-
an individual. Its higher adoption rate lately is attributed vices over the central payment scheme of the region. With
largely to user convenience and resistance to spoofing. changing guidelines and movement toward open econo-
Biometric authentication does not require the physical mies, operators/regulators have enabled non-store of value
aspect that a customer presents to match a stored copy (SoV) service providers—also referred to as third-party
exactly; rather, it is the most likely match. The biomet- providers10—to have access of customers’ accounts, to
ric authentication model can use a variety of physical enhance customer experience. With respect to fast pay-
aspects, such as facial recognition, voice recognition, fin- ments, customers have been provided access to services
gerprint scans, iris scans, and so forth. via either of the following providers, based on the scheme
design and local regulations:
Using the factors mentioned above, different customer-au-
thentication models can be implemented. They can be clas- 1. Store of value (SoV) providers:
sified into the following two broad types: SoV providers store customer funds in accounts (such as
prepaid, savings, credit, and so on), from which financial or
1. Single-Factor Authentication Model:
nonfinancial transactions are initiated. Here, account details
In single-factor authentication, any one of the above fac-
are readily available with the financial institution, making
tors is used to verify a customer. The most common form
it easy to authenticate the customer without sharing the
of single-factor authentication is using passwords or PINs.
authentication details over the network.
2. Multifactor Authentication Model:
2. Non-store of value (non-SoV) providers:
Multifactor authentication models use more than one
Non-SoV providers do not hold the customer accounts
factor to identify a customer. Multifactor authentication
and rely on customers of other institutions. Hence, one of
increases the level of confidence in an authentication due
the key actions required as part of a transaction is shar-
to its multilayer security implementation, making it diffi-
ing the authentication details over a secure channel with
cult to breach, compared to single-factor authentication.
an SoV provider for authentication. Only after receiving a
successful response is the customer given access to the
Central operators and financial institutions across the globe
payment system.
have been shifting toward multifactor authentication (two-
factor authentication) to validate the end customer before

FIGURE 5 Types of Participants and Authentication Methods

SoV providers Authentication by SoV

provider; authentication
details not shared

PARTICIPANTS

Non-SoV providers Authentication details Standard defined by

may be shared with SoV central operator
provider by the non-SoV
providers for authentication
using either ISO 8583,
Standard not
ISO 20022, or a
defined by central
proprietary standard
operator
 Messaging Standards in Fast Payments | 21

Customer-authentication details are required to be shared • Fields reserved for national and private use:
across the network in the scenario defined in figure 5. Dif- National and private fields provided in ISO 8583 can be
ferent messaging standards define different set of fields for used to capture additional authentication details of the
capturing customer authentication, thus enabling various customer. These can capture any information related
authentication models. A detailed description of the avail- to customer-authentication factors, such as passwords,
able fields in each of the messaging standards is below: token-based information, and so forth.

3.2.1 ISO 8583 3.2.2 ISO 20022

Different customer-authentication methods are imple- ISO 20022 is the most widely used standard in FPS across
mented by different schemes relying on ISO 8583. Most of the globe. Different schemes that have implemented ISO
the implementations do not support non-SoV accounts; 20022 rely on different customer-authentication methods.
hence, there is no transfer of authentication details. In these Similar to ISO 8583, most implementors have not neces-
cases, the SoV providers can choose to authenticate the cus- sarily relied on any standard but have left it to the par-
tomers by using any messaging standard for internal com- ticipants to ensure that the customer is authenticated. In
munication—for example, FPS in the United Kingdom and these cases, the SoV providers can choose to authenticate
IMPS in India, where the authentication as a requirement is the customers by using any messaging standard for inter-
done at the remitter bank in line with scheme guidelines. nal communication—for example, RTP in the United States,
In the case of non-SoV providers, if ISO 8583 is the pre- where the authentication as a requirement is done at the
ferred standard for customer authentication, a predefined remitter bank.
data element (DE 52) can be used to authenticate a cus- In the case of non-SoV providers, if ISO 20022 is the
tomer along with the data elements reserved for national preferred standard for customer authentication, ISO 20022
use (57–60, 112–119) and private use (61–63, 120–127), as messages carry tags for customer authentication in various
described below: messages used in the transaction flow. In the Payment Initi-
• DE 52: Personal identification number ation (pain.001) message, the Authorisation <Authstn> tag
Implementors can use this element to authenticate in the Group Header <GrpHdr> can carry details required for
the customer, along with such other data elements as customer authentication. (For details on the <Authstn> tag,
“Account Identification.” This field is mandatory for card- refer to appendix I.)
based payment mechanisms and can be used to carry In case an implementation allows mandates (pain.009
authentication details for a customer in the FPS. In use, and similar), fields are available to enter the authentication
this field is encrypted using symmetric keys exchanged details. They are part of the Authentication <Authntcn> tag
between the payee’s financial institution and the FPS and present in the Mandate <Mndt> tag of the message. (For
decrypted by the FPS and re-encrypted using different details on the <Authntcn> tag, refer to appendix J.)
keys exchanged between the FPS and the payer’s finan- Apart from the above, ISO 20022 has defined different
cial institution. Including a non-SoV provider in this flow message sets for card transactions that can carry card and
will require suitable encryption for the flow between the customer-authentication details.
non-SoV provider and FPS.

CASE STUDY 1 NPP AUSTRALIA

In NPP in Australia, financial institutions have deployed the channels, if an overlay service (a non-SoV provider)
a combination of multifactor authentication meth- is selected as a method, pain.a09, a proprietary appli-
ods to protect customers from account compromise. cation programming interface, is used, which asks the
Non-SoV providers are accessed through the channels NPP participant (a SoV provider in this case) to create a
of SoV providers. Hence, authentication is done at the payment resource.
SoV provider itself. While submitting a transaction from
22 | Messaging Standards in Fast Payments

3.2.3 Proprietary Key Takeaway

Proprietary messages cannot be generalized, as the authen- Customer authentication is subject to the requirements
tication depends on the implementation and can have and regulations of a country/region, based on which imple-
different authentication regulations across different imple- mentation of FPS has been done. Each messaging stan-
mentations. UPI in India is one of the most successful FPS dard provides certain predefined fields that can be used
implementations globally using a proprietary standard. It has to authenticate the customer. Most implementations allow
engaged varied payments service providers (SoV provid- SoV providers to implement the authentication locally and
ers and third-party providers) in the ecosystem; hence, the define a set of guidelines for implementing authentication
authentication mechanism deployed is much sophisticated. by non-SoV providers.
UPI has deployed two-factor authentication: first at the
mobile application in the form of “mobile binding,” and 3.3 SYSTEM PERFORMANCE AND SCALABILITY
then in the form of a PIN/password, which is validated at
the SoV provider. As designed, a customer may use the UPI System performance is the amount of useful work that can
mobile application provided by either a SoV or a non-SoV be done using a system. The accomplished work is mea-
provider. If a non-SoV provider is chosen for the transaction, sured against preset known standards, such as efficiency,
authentication details captured by the non-SoV application accuracy, and speed of executing a set of instructions (trans-
provider are securely shared with the SoV provider after actions in the case of a payment system). On the other hand,
the authentication information is processed using a trusted scalability is the system’s ability to handle increased work
common library provided by NPCI. while not compromising the performance of a system. A sys-
tem is considered as scalable if it does not need to be rede-
Mobile Binding signed to accommodate an increased workload. The more
Mobile device binding is the process by which the cus- scalable the system, the better its prospects for the future.
tomer’s mobile device is bound with the UPI application The performance and scalability of a system depends on the
during registration. The device is then validated every time following system parameters:
the customer accesses the application to conduct a trans-
action. Mobile binding is used as one of the authentication 1. System Design
factors in UPI. This parameter relates to the complexity of the design of
(For details on the mobile binding process, refer to the system. A complex system would adversely affect sys-
appendix K.) tem performance and limit its scalability, as dependence
Trusted Common Library on different components in the system would increase.
A trusted common library is provided by NPCI for captur- The complexity of system design can be attributed to the
ing customer-sensitive information. The PIN travels over the number of components in the system, the hops a trans-
secure channel from UPI to the issuing bank using encryp- action will take, dependence on one component for mul-
tion based on public key infrastructure, where the PIN is tiple tasks, and interdependence between components.
encrypted using the public key at UPI, and it is decrypted All of these factors are crucial while designing the system.
by the issuing bank at its end using its private key.11 This A simple system design would mean better performance,
library is used to provide the same user experience over dif- compared to a complex system design.
ferent SoV and non-SoV applications. In addition, it provides
2. Hardware Capabilities
a unique platform for financial institutions, which don’t have
to rely on different third-party applications for encrypting This parameter relates to the hardware components of
user credentials. the system and their capabilities affecting the system
performance. The higher the configuration of hardware
• The trusted common library provided by NPCI is required
used in a system, the better the system performance
to be integrated with PSP applications for capturing cre-
would be, keeping other factors common. For example,
dentials, such as passwords, PINs, MPINs, biometrics, and
the higher the processing power of the processor, the
so on.
greater the number of transactions that can be pro-
• Authentication details are captured and base 64 encoded cessed in a predetermined time frame, leading to better
by the trusted common library and sent back to the PSP performance.
for subsequent transport throughout the payment cycle
in UPI.
 Messaging Standards in Fast Payments | 23

3. Network Capabilities 2. Straight-Through Processing

In a payment system, transactions are sent from one STP means the automatic processing of payment trans-
system to another, which requires network connectivity actions, with no manual intervention required. STP is
between the different parties involved in the transaction. key to system performance, as it reduces the processing
So the better the network capabilities of the system, the time and the resources required for manual intervention
better the system performance would be and the greater from operators while increasing the speed, efficiency,
the scalability would be. For example: The better the and accuracy of the system. ISO 8583 messages are
throughput and the less the latency, the better the sys- unstructured and rely heavily on free format. For exam-
tem performance. ple, in address fields, there is no demarcation of address
parameters such as city or state, which makes it vulnera-
However, the performance and scalability of any payment ble to misinterpretation. This type of data is difficult for
scheme is determined by the design, hardware, and net- the processing system to process, leading to increased
work capabilities of the system. These factors are further manual intervention and, hence, decreasing the STP rate.
influenced by characteristics of the messaging standard, In contrast, ISO 20022 messages are structured and have
such as message size, STP, data truncation, and adoption of supporting unstructured fields to pass additional infor-
new use cases. mation. The data entered in these fields can be differ-
1. Message Size entiated easily, which helps in processing the payments.
The message size is directly related to the informa- For example, address fields have city, state, country, sub-
tion-holding capacity, richness of the message format, division, and other subfields, making it easy for the sys-
and structure of the message. Message size plays an tem to interpret and process the data automatically and
important role in measuring the system performance, as leading to decreased manual intervention and, hence,
the larger the size, the longer the processing time and increasing the STP rate. The structure of a proprietary
the greater the hardware requirements, while the pro- messaging standard varies based on implementation and
cessing speed would be less, and vice versa. ISO 8583 cannot be generalized. Implementors of proprietary sys-
messages are approximately five times lighter than ISO tems have the freedom to choose between structured
20022 messages. This is due to the limited amount of or unstructured fields and, in the case of free text fields,
information being transferred, thus saving on the mem- to define separators at the field level to make the data
ory required for storage. In addition, less bandwidth is more understandable. The STP rates achieved are usually
required to process these transactions, increasing the higher using a proprietary message format.
speed and efficiency of the system. In comparison, 3. Data Truncation
ISO 20022 messages are bulkier. Their bigger size is This parameter is used to compare the messaging stan-
attributed to the presence of nested tags in the XML for- dards based on the data-carrying capacity of a messag-
mat, the structure of the message, the message-holding ing standard. The greater the data-carrying capacity,
capacity, and the message format. Hence, the bandwidth the greater the information that can be carried from the
required to process transactions is comparatively higher message sender to the receiver. The less the data-car-
and may create a capacity problem at some locations, rying capacity, the greater the data truncation would
due to unavailability of good network infrastructure. The be, to fit in the data, leading to loss of data. If the data
message size for a proprietary message varies based on entered is larger than the space available, how the data
implementation, the format, the character sets, and the is truncated—such as by truncating the first or last char-
type of information contained in a message. Generalizing acters that do not fit in the defined space—will depend
about the message size of proprietary formats is difficult, on the implementing system. ISO 8583 has shorter field
but implementors have the advantage of being able to lengths than ISO 20022 in such essential fields as name,
choose the message attributes to fit the requirements, as address, and identifiers. These data fields are required for
well as meet the data-handling capacity of the system. In the accuracy of the payment transaction. For example, in
addition, since the messaging standard is not standard- the case of ISO 8583, the 140-character limit applied to
ized, implementors have the flexibility to remove unused the address fields may not be sufficient to capture all the
fields/tags, which is not feasible in messaging standards information contained in international correspondence
such as ISO 20022. addresses. ISO 20022 messages have more field lengths
24 | Messaging Standards in Fast Payments

in essential fields than ISO 8583 messages. ISO 20022 role in defining the scalability of a messaging standard.
provides both structured and unstructured fields for cap- ISO 8583 has limited business use cases for FPS due to
turing the data. Unstructured fields can be used over and its inclination toward the interchange of card-originated
above the structured fields to provide extensibility to the transactions. In the current scenario, certain use cases
transaction-related data. For example, the address field cannot be implemented using the messaging standard
<PstlAdr> in ISO 20022 has unstructured fields in addi- out of the box, such as request-to-pay messages and
tion to the structured fields. As per the latest specifica- remittance information messages. In addition, no recent
tion for payment clearing and settlement messages, there updates for ISO 8583 limit the addition of new use cases
can be seven instances of the 70-character unstructured by changes in the message structure, while ISO 20022
address line for each party involved in the transaction. is an open standard that can adapt to changing needs
These additional unstructured address lines, along with and new approaches within the payments industry.
the structured data, provide sufficient field length to cap- Since ISO 20022 is not controlled by a single interest, it
ture most of the data, increasing the accuracy of trans- is open to changes and can be used by anyone in the
action. On the other hand, proprietary messages have financial industry. It has been designed with the dynamic
the advantage of allowing the message structure and nature of business requirements in mind, allowing for
field lengths to be tweaked as and when required based better compatibility with business use cases. The major-
on the requirements. The field lengths can be defined ity of the current use cases for FPS can be implemented
keeping in mind the regional requirements, and imple- using ISO 20022, and the messaging standard has a
mentors can cut off excessive fields/field lengths that are dedicated change-request portal for the participants
predefined in standardized message formats, increasing to submit their requirements for the rest. If approved,
the efficiency of the transaction messages. the changes become part of the yearly or emergency
upgrade cycle. Proprietary messaging standards are best
4. Addition of New Use Cases
suited for incorporating niche or local use cases based on
This parameter is used to compare the messaging stan-
demographic, geographic, infrastructural, or regulatory
dards based on the use cases that can be implemented
requirements. Whenever a new requirement is encoun-
and the openness of the messaging standard to incorpo-
tered, proprietary messaging standards can accommo-
rating new use cases. Use cases may range from features
date such requests better than other standards, as no
enhancing customer experience, increasing target mar-
third party is needed to make or approve such changes
ket, or enabling cross-border transactions. This capabil-
in the messaging standard.
ity to undertake new use case with ease plays a major
4 PAYMENT SYSTEM OPERATORS’ EXPERIENCE
WITH PROPRIETARY SYSTEMS

Proprietary systems require detailed research and analysis messaging format. Although there are many challenges
of the requirements, the process, available technologies, when implementing a proprietary system, implementors
infrastructure, stakeholders, expected outcomes, and key in certain cases feel that these challenges are outweighed
influencing factors, such as cost, before a decision is taken. by the perceived benefits. The experiences of the central
All these requirements need to be carefully considered operators in deciding, implementing, and operating FPS
while designing the system to match the expected out- based on a proprietary messaging standard for UPI in India
come, making the research and design phase the most and SPEI in Mexico are recounted in case study 2 and case
crucial phase of the implementation using a proprietary study 3, respectively.

| 25
26 | Messaging Standards in Fast Payments

CASE STUDY 2 UPI IN INDIA

UPI in India was launched on April 11, 2016, based on a tems were technical—for example, bandwidth needed
proprietary messaging standard. Before choosing a pro- to be upgraded at both NPCI’s and the banks’ end. In
prietary messaging standard, various feasibility analyses addition, the banks had to introduce an integration
were done to understand how existing standards, such layer for transmitting the UPI messages (in proprietary
as ISO 20022, fit a set of preliminary requirements. The format) to the core banking system. Implementation
major reasons for the choice was the belief that, in the of UPI also required rigorous technical training of the
case of the standard messages, the UPI implementors parties involved, along with customer education. NPCI
would be dependent on different versions released by was of the view that all the implementations across the
the ISO, while for a proprietary standard, that decision world would not be on a single messaging standard or
would lie with them. In addition, ISO 20022 and other even on a single version of a messaging standard. So
messaging standards were perceived to be compli- if there were cross-border payment integrations where
cated, while a less complicated messaging standard was the two parties were on different versions, then they
required. Because UPI in India is an in-house standard, it would require a central translator or convertor to make
was expected to deliver efficiency, ease of understand- the messages understandable to both parties. Due to
ing, and accommodation of new requirements as major this hinderance, they preferred proprietary messages,
benefits over the standardized messages. The process as the translators would be required in both cases,
of accommodating new requirements can be compared whereas, with proprietary messages, they could reap
to the change request process of ISO 20022, which is a the benefits of flexibility and better efficiency. Today
lengthy and, generally, an annual affair. This is not the UPI in India is integrated with Singapore; merchants
case with proprietary formats. The other two perceived registered with NETS (Singapore) can accept UPI pay-
benefits are subjective and vary between different ments from users in India registered on the UPI plat-
users. UPI in India has integrated with different domes- form. UPI has also recently integrated with Bhutan and
tic products, such as NETC for toll collection. The major the United Arab Emirates, and conversations with differ-
challenges faced while integrating UPI with other sys- ent countries about integrating their FPS are ongoing.

CASE STUDY 3 SPEI IN MEXICO

SPEI in Mexico was introduced in 2004, long before ISO to be used as a proxy ID. The decision to include a credit
20022 was introduced. The only prevalent standard was card is left to the issuer banks, and they can decide to
ISO 8583 for card-based payments, which had different include the same. Currently SPEI is not integrated with
implementations in two similar systems, Mastercard and another FPS, but it plans to integrate soon with other
Visa. The central system felt a need to bring out a system systems across the world. The implementors at SPEI
in which data is represented efficiently and elegantly in Mexico are of the view that all the implementations
while focusing on achieving higher efficiency rates. The across the world would not be on a single messaging
implementors perceived speed, size of the message, standard or even on a single version of a messaging
and efficiency as the benefits of choosing a proprietary standard. So if there were cross-border payment inte-
messaging standard over the others. In 2015, they ana- grations where the two parties were on different ver-
lyzed ISO 20022 and found that an ISO 20022 message sions, then they would require a central translator or
was seven times heavier in byte size than a similar pro- convertor to make the messages understandable to
prietary message used by SPEI in Mexico. SPEI in Mexico both parties. SPEI in Mexico is planning to undertake a
has not integrated with other payment systems in the change where they would embed an ISO 20022 trans-
domestic market but has given credit cards as an option lator in the system that would increase interoperability.

26 |
5 CONCLUSION

5.1 DECISION FRAMEWORK Three broad implementation types are seen globally in the
implementation of FPS. The type of FPS implementation
Any FPS implementation needs to be planned as a com- can affect the decision of a messaging standard heavily, as
munity effort. Decisions about the style, speed, and scope it has a material impact on program structure and guide-
of the implementation of the messaging standard must lines. For example, the FPS implementation NPP in Australia
be made after considering the widest set of stakeholders: saw a large impact on program structure based on the new
direct participants, indirect participants, regulators, vendors, implementation of ISO 20022 from scratch. Also, beyond
service providers, and consultants. Even where the overall FPS, several high-value payment schemes in the European
business case is strong, it is important to understand that Union for Target 2 and CHAPS in the United Kingdom have
all participants may not feel the benefits and costs of the ongoing multiyear programs to implement a common mes-
implementation equally. saging framework.
The choice of an appropriate messaging standard is piv-
• Building FPS from scratch: This implementation gener-
otal for the scheme to enable PSPs and others to develop
ally entails a long-term program in which a new system is
services and innovations that are adaptable to the needs of
built—that is, all the components to be implemented are
end users. From an FPS perspective, a decision on messag-
built and deployed, and there is no reuse from other pay-
ing standards depends on one or more of the points below,
ment products. This type of implementation has been
which have ramifications from strategic, technical, opera-
used by India and Australia and is best suited when the
tions, collaboration, and scheme-expansion perspectives.
existing systems/infrastructure, if reused, would be inca-
1. Type of FPS Implementation pable of providing the desired outcomes.
The various implementation approaches taken by FPS across
• Migrating from one messaging standard to another:
the globe have been customized to the local context and
In this implementation, a scheme migrates from one
benchmarked to some of the world’s most popular live FPS
payment messaging standard to another to realize ben-
schemes. The choice of an appropriate implementation
efits that were impossible in the existing system—for
approach is governed by the following factors:
example, the development of a common ISO 20022
• Interaction with other payment systems messaging standard for the New Payment Architecture
• Regulatory push and urgency in the United Kingdom encompassing FPS, retail pay-
• Evolving dynamics in the local payments industry and ment frameworks, and high-value payments with a
customer demographics key objective of increasing interoperability across the
• Financial considerations schemes, wherein all three schemes have a common
• Level of reliance on third-party organizations settlement interface owned and operated by the central

| 27
28 | Messaging Standards in Fast Payments

bank, which provides a common ground for the imple- inference can be drawn. One of the key aspects of these
mentation of settlement messages. consultative sessions is the selection of an appropriate mes-
• Leveraging existing systems: In this type of implemen- saging standard.
tation, a system is built over another system or as an It has been observed with various global FPS implemen-
extension of the existing system. This implementation is tations that local experience with the chosen messaging
beneficial as it saves cost, gives a faster return on invest- standard is a deciding factor in choosing a specific mes-
ment, and has lower risk with less operational disruption, saging standard. Having prior experience with messaging
but leveraging existing systems may limit the scope of standards has the following benefits:
the new system. A classic example of leveraging existing • Predictability in implementation milestones
systems is TIPS, which is built as an extension of Target 2. • Lessons learned from similar implementations to further
The following are two major approaches for implementing streamline scheme delivery
any of the above-mentioned categories: • More accurate cost projections

1. Big Bang: This approach entails a single program in • Ready-made libraries of technical message definitions for
which there is one major rollout of the desired payment baselining
system—that is, all the desired functionalities are deliv-
In addition to experience with similar implementations in
ered in one go. This approach costs less than a phased
other schemes, the readiness of the participants is one of
rollout, as the operating expenses are lower, but higher
the key components that influences the scheme’s decision
risk is attributed to a single-step implementation.
on an appropriate messaging framework. Participants in the
2. Phased rollout: Under this approach, the program is FPS schemes, especially the traditional financial institutions,
divided into phases, and each phase is an incremental have varied experience across multiple geographies, includ-
improvement over the previous phase. For example, in ing experience and components within the participant’s
a phased rollout, a scheme may implement the FPS in payment service architecture, that can handle various mes-
a way that allows them only to accept the payments saging standards. If scheme participants have a high degree
(receive), while participants would need to use other of readiness, participants can start deriving the full level of
existing payment methods to send payment. business benefits from the mandated messaging standard
and move beyond just compliance.
When leveraging existing systems or migrating from one
Also, the amount of time taken by the industry to stream-
standard to another, extra caution is needed so as not to dis-
line communication based on messaging standards and
turb the existing system. The following major points should
build upon the mandated messaging standards will help
be considered before envisaging such implementations:
develop innovative use cases that will help translate into
• Identify affected systems, rules, channels, processes, and newer payment services built on top of the FPS infrastruc-
touchpoints. ture—for example, embedding QR codes within payloads to
• Determine the level of impact on the touchpoints, sys- help corporate customers to derive and automatically cap-
tems, and channels, and explore their readiness to accept ture payment-specific details such as invoice details, amount
the change. details, tax information, and use them in corporate-specific
systems such as enterprise resource planning, terminal man-
• Plan the incremental change and prioritize based on the
agement systems.
impact of the change on the overall system, timeline of
However, the experience of participants with a specific
change, and operational considerations.
messaging standard in one domain/geography doesn’t
• Emphasize minimizing the impact on customers. guarantee a replication in the FPS architecture, but the
• Map system parameters such as efficiency, speed, turn- experience certainly makes the process more streamlined,
around time, and other expected outcomes to the actual and the scheme can also draw inferences during the col-
outcomes. laboration.

2. Experience and Participant Readiness 3. Time to Market

Before any FPS implementations, the scheme undertakes The development of FPS frameworks are timed-bound
elaborate consultative sessions to look at the best practices implementations that are undertaken and planned to be
both globally and locally that can be adopted or from which delivered within a specific time for a variety of reasons.
 Messaging Standards in Fast Payments | 29

Given the various technical and functional components of • Liquidity management

an FPS, messaging standards are the key drivers in deter- • Contingent data-recovery centers
mining if the scheme can be delivered within the specified
• Any new technology implementation, such as hosting
time frame and if it is able to accelerate successful delivery
payment solutions in the cloud
due to reasons such as technical integrations, collaboration,
embedding business processes into messaging standards. • Security infrastructure
One of the reasons for a need to accelerate the time to
For example, the ISO 20022 implementation for cross-bor-
market, as seen in global FPS implementations, is the emer-
der payments has necessitated the overhaul of the legacy
gence of a fragmented marketplace in which multiple closed
framework of both the scheme and participants in areas of
loops and privately owned FPS are established in the coun-
payment hubs, data warehousing, gateway routing. Given
try with no basis for underlying interoperability, and each
the context, the types of participants in the FPS and their
payment scheme offers only a limited use case.
financial capability to deliver these costly implementations
4. Cost are important points to be considered by the scheme when
Any implementation of a messaging standard is a com- deciding on a messaging framework.
plex program that needs to be treated like another long-
term strategic program and requires certain principles to be
5.2 KEY TAKEAWAYS
adhered to, so that delivery can be completed successfully.
One of the most important principles is the aspect that the 1. ISO 8583
cost and budget allocated to the overall program will span ISO 8583 was originally published by ISO in 1987 and
the transformation of technology components, resource since has been predominantly used in card-originated
budgets. transactions. Some of the early FPS implementations are
The scheme needs to plan accordingly and consider the using ISO 8583 messaging formats and are still opera-
practical aspects of the implementation of a messaging tional. ISO 8583 relies on an unstructured free-text for-
standard for delivering the messaging standard correctly, on mat and is smaller in size than other standards, which
time, and at an acceptable cost to all stakeholders. The fol- makes it the standard of choice where limited bandwidth,
lowing factors will affect the cost of implementation: storage, or processing capabilities are the factors under
• The availability of the resource skill set needed to imple- consideration. ISO 8583 has a predefined data element
ment the messaging standard in the region would affect for PIN and reserved-data elements that can be used to
cost. Also, the greater the complexity of the messaging carry details of various factors used for customer authen-
standard chosen, the higher the cost, due to the special- tication. In addition, ISO 8583 defines various message
ized resources required. types that can be used to implement different use cases,
although certain use cases, such as request to pay, cannot
• The strategy chosen by the scheme would also affect
be implemented with the available message types.
cost. For example, choosing a tactical solution in the form
of central translators would require a one-time set-up 2. ISO 20022
cost, but avoiding a complete overhaul of technical com- ISO 20022 was first introduced by ISO in 2004 and is
ponents would bring savings. considered as the global standard for the exchange of
electronic messages between financial institutions, both
• Generally, the longer the implementation timeline, the
for payment as well as nonpayment transactions. The
higher the costs, due to higher resource costs, large-scale
widespread adoption of ISO 20022 is attributed to the
transformations.
standardization of the message, interoperability, the
One of the costliest propositions for implementing a mes- availability of a large number of fields for carrying trans-
saging standard is the ramification on the following existing action information, and better STP rates. ISO 20022 is
technical components used by the scheme and the partic- very detailed and has different message types that can
ipants: be used to implement various use cases. This also means
• Legacy integration interfaces that the message is bigger in size than other standards
and schema maintenance is difficult, as it takes a holistic
• Data warehouses
picture of all the participants, rather than a single inter-
• Physical data centers est. To implement customer authentication, predefined
• Payment-processing hubs
30 | Messaging Standards in Fast Payments

fields can be used to carry the authentication details. In whenever necessary, can be done based on a single
addition, ISO 20022 has defined a real-time payments interest, which is not possible in the other two formats.
group to document a consistent and harmonized view This also means that proprietary messages are less stan-
of ISO 20022 message components, business processes, dardized and less interoperable than other standards.
elements, and data content with respect to FPS in differ- Most of the customer-authentication implementations
ent market implementations. for fast payments have been done using a proprietary
format, as it provides the flexibility to design the stan-
3. Proprietary
dard to embed solutions supporting different factors at
Proprietary payment messages are a unique message
various levels of authentication. In addition, the stan-
format defined by a country/region/monetary author-
dard can be designed in a way to match the local infra-
ity for facilitating payments. This messaging format is
structure capabilities to achieve the required level of
generally localized and best suited for serving niche
system performance.
requirements. Proprietary messages offer high levels
of customization, and schema maintenance activities,
6 ACKNOWLEDGMENTS

Organization Contributor
PwC India PwC India
World Bank Harish Natarajan
Nilima Ramteke
Holti Banka

| 31
7 APPENDICES

APPENDIX A: STRUCTURE OF ISO 8583 MESSAGE The first digit denoting the version of the message can
be understood as shown in table A1.
Each ISO 8583 message is identified by a message type indi-
TABLE A1 ISO 8583 MTI: Meaning of First Digit
cator (MTI). The significance and usage of each digit is as
shown in figure A1. MESSAGE TYPE INDICATOR MEANING
0XXX ISO 8583:1987
FIGURE A1 Significance of Digits in MTI 1XXX ISO 8583:1993
2XXX ISO 8583:2003
3XXX ISO reserved
X X X X 4XXX
5XXX
6XXX
7XXX
8XXX Reserved for national use
Version of Message Message Message
the message class function origin 9XXX Reserved for private use
Source: Payment Systems Blog12

As shown in table A2, the second digit shows the

message class.

TABLE A2 ISO 8583 MTI: Meaning of Second Digit

MESSAGE TYPE INDICATOR MEANING

X0XX Reserved by ISO
X1XX Authorization message
X2XX Financial message
X3XX File actions message
X4XX Reversal and chargeback
messages
X5XX Reconciliation message
X6XX Administrative message
X7XX Fee collection message
X8XX Network management message
X9XX Reserved by ISO
Source: Payment Systems Blog13

32 |
 Messaging Standards in Fast Payments | 33

As shown in table A3, the third digit shows the message As shown in table A4, the last digit is for the message
function. origin.

TABLE A3 ISO 8583 MTI: Meaning of Third Digit TABLE A4 ISO 8583 MTI: Meaning of Fourth Digit

MESSAGE TYPE INDICATOR MEANING MESSAGE TYPE INDICATOR MEANING

XX0X Reserved by ISO XXX0 Acquirer

XX1X Authorization message XXX1 Acquirer repeat

XX2X Financial message XXX2 Issuer

XX3X File actions message XXX3 Issuer repeat

XX4X Reversal and chargeback XXX4 Other

messages XXX5 Other repeat
XX5X Reconciliation message XXX6 Reserved by ISO
XX6X Administrative message XXX7
XXX8
XX7X Fee collection message XXX9
XX8X Network management message Source: Payment Systems Blog14
XX9X Reserved by ISO

APPENDIX B: COMPARATIVE ANALYSIS: PARAMETER FIELD LENGTH

TABLE B1 Comparison of Field Length of Sample Fields

FIELD ISO 8583 ISO 20022 PROPRIETARY (UPI)

Name fields (debtor/creditor/ulti- 40 140 99
mate debtor/ultimate creditor)
Address 140 Department <Dept>—70 255
SubDepartment <SubDept>—70
StreetName <StrtNm>—70
BuildingNumber <BldgNb>—16
BuildingName <BldgNm>—35
Floor <Flr>—70
PostBox <PstBx>—16
Room <Room>—70
PostCode <PstCd>—16
TownName <TwnNm>—35
TownLocationName <TwnLctnNm>—35
DistrictName <DstrctNm>—35
CountrySubDivision <CtrySubDvsn>—35
Country <Ctry>—2
AddressLine <AdrLine>—70
Amount 14 18 with 5 fraction digits 14
Account number 34 34 255 (total length of IFSC,
ACTYPE, ACNUM)
Institution identifiers 11 Multiple with maximum length of 35 20
Transaction identifiers 18 Multiple with maximum length of 35 35
34 | Messaging Standards in Fast Payments

APPENDIX C: COMPARATIVE ANALYSIS: 2. Remittance information [tag <RmtInf>]

PARAMETER REMITTANCE INFORMATION This is the information supplied to match an entry with
the items that the transaction intends to settle—for
ISO 8583
example, commercial invoices for an accounts receivable
There is no predefined field for remittance information in
system.
ISO 8583 messages, but this information can be provided
The remittance information field is further divided
in fields reserved for national or private use (57–63 and
into the following two parts:
112–127), which have a field length of 999 characters. For
example, banks in the United Kingdom specify two fields: a. Structured
Field 120: payment reference information (in most cases, this Information supplied to match an entry with the items
is a client reference or account number that allows the ben- that the transaction intends to settle in a structured
eficiary to identify the sender or purpose of payment), and form. This field is further divided into the following
Field 121: remittance information. parts:

ISO 20022 i. ReferredDocumentInformation [tag <RfrdDocInf>]:

Remittance information can be provided in the following This field is further divided into multiple tags/ele-
two places in an ISO message: ments for providing identification and content of
the referred document.
1. Related Remittance Information [tag <RltdRmtInf>]
ii. ReferredDocumentAmount [tag <RfrdDocAmt>]:
Provides remittance-related handling information for
This field is further divided into multiple tags/
use in transaction processing by any agent in the chain.
elements for providing details on amounts of the
Related Remittance Information is further divided into the
referred document.
following two subtags/elements:
iii. CreditorReferenceInformation [tag <CdtrRefInf>]:
a. Remittance Identification [tag <RmtId>]
This field is further divided into multiple tags/ele-
This unique identification is assigned by the initiating
ments to be used to provide reference information
party to identify unambiguously remittance informa-
provided by the creditor to allow the identification
tion that is sent separately from the payment instruc-
of the underlying documents.
tion. It is 35 characters in length.
iv. Invoicer [tag <Invcr>]: This field is further divided
b. Remittance Location Details [tag <RmtLctnDtls>] into multiple tags/elements to be used to iden-
Remittance location details is further divided into the tify the organization issuing the invoice in cases
following: where it is different from the creditor or ultimate
creditor.
i. Method [tag <Mtd>]: This tag is list of predefined
code sets. v. Invoicee [tag <Invcee>]: This field is further
divided into multiple tags/elements to be used to
ii. Electronic Address [tag <ElctrncAdr>]: The elec-
identify the party to whom an invoice is issued
tronic address to which an agent is to send the
when it is different from the debtor or ultimate
remittance information. This field has a length of
debtor
2,048 characters.
vi. TaxRemittance [tag <TaxRmt>]: This field is further
iii. Postal Address [tag <PstlAdr>]: This field is the divided into multiple tags/elements to be used to
postal address to which an agent is to send the provide remittance information about a payment
remittance information. It is further divided into the made for tax-related purposes.
following two parts:
vii. GarnishmentRemittance [tag <GrnshmtRmt>]: This
• Name [tag <Nm>]: This field is 140 characters field is further divided into multiple tags/elements
long. to be used to provide remittance information about
• Address [tag <Adr>]: This field has further a payment made for garnishment-related purposes.
address subtags/elements.
 Messaging Standards in Fast Payments | 35

viii. AdditionalRemittanceInformation [tag <AddtlRm- Proprietary message

tInf>]: This field is 140 characters long in free-text In UPI, the remittance information is added in the “note” tag
form for additional information, to complement and “refId” tag.
the structured remittance information.
1. “note” tag is 50 characters long. It is the description of
b. Unstructured the transaction and in free text format (which is printed
Information supplied to match an entry with the items on the passbook).
that the transaction intends to settle in an unstruc-
2. “refId” tag is an external reference number to identify the
tured form—that is, free text. This field has a length
payment, such as a loan number, invoice number, and so
of 140 characters.
forth. It is 35 alphanumeric characters long.

APPENDIX D: COMPARISON OF UTF-8 AND ASCII

PARAMETER UTF-8 ASCII

Definition UTF-8 is a universal character set. It is the IT stan- ASCII stands for American Standard Code for Information Inter-
dard that encodes, represents, and handles text for change. It is the IT standard that encodes the characters for elec-
computers, telecommunication devices, and other tronic communication only.
equipment.
Function UTF-8 represents a large number of characters, ASCII represents a specific number of characters, such as upper-
such as mathematical symbols, letters of different case and lowercase letters of the English language, digits, and
languages, historical scripts, and so on. symbols.
Space UTF-8 supports many characters and occupies ASCII supports only 128 characters and occupies less space by
utilization more space. It uses eight bits to present any char- converting the characters to numbers and using seven bits to
acter, and ASCII is a subordinate of Unicode. present any character.

APPENDIX E: SCOPE OF RTPG

The Real Time Payments Group (RTPG)15 was formed to document a consistent and harmonized view of ISO 20022 message
components, business processes, elements, and data content with respect to FPS in different market implementations. Table
E1 presents the scope of messages.

TABLE E1 Scope of RTPG of ISO 20022

SERVICE MESSAGES MEANING

Interbank Recommended messages (pacs.008, pacs.002) RTPG-recommended ISO 2022 messages between two banks for
services credit transfer and payment-status reporting
Optional and implementation driven (pacs.004, Optional messages that can be used by the implementors or for
pain.013/pain.014, camt.052/053/054, which the alternatives are present. For example, pacs.004 is used for
camt.056/029, remt.001/002) returns, while TCHRTP in the United States uses pacs.008 for returns
with details of original transaction.
Payer Optional and implementation driven (pain.001, Optional messages between the payer and the channel/overlay
pain.002, pain.013/pain.014, camt.052/053/054, services
camt.056/029, remt.001/002)
Payee Optional and implementation driven (pain.013/ Optional messages between the channel/overlay and the payee
pain.014, camt.052/053/054, remt.001/002)
Settlement Optional and implementation driven (pacs.009, Optional messages between financial institutions for settlement
pacs.010, pacs.002)
36 | Messaging Standards in Fast Payments

APPENDIX F: ISO 8583 MESSAGE LINKAGE

i. ISO 8583 Messages and Field Descriptions

TABLE F1 ISO 8583 Messages Used in Linkage between Transaction Flow, Processing Steps with Messaging Standards

MESSAGE MESSAGE FIELDS AVAILABLE PRIVATE FIELDS REQUIREMENT

CATEGORY
X200 Acquirer financial request DE 2 Primary account number Fields missing for carrying debtor’s
DE 3 Processing code and creditor’s information, remit-
DE 18 Merchant category code tance information, and on-behalf-of
DE 32 Acquiring institution identification code transaction fields
DE 41 Card acceptor terminal identification
DE 42 Card acceptor terminal code
DE 43 Card acceptor name/location
DE 102 Account identification 1
X210 Acquirer financial response DE 2 Primary account number Fields missing for carrying debtor’s
DE 3 Processing code and creditor’s information, remit-
DE 18 Merchant category code tance information, and settlement
DE 32 Acquiring institution identification code information
DE 39 Response code
DE 41 Card acceptor terminal identification
DE 42 Card acceptor terminal code
DE 43 Card acceptor name/location
DE 102 Account identification 1

ii. Proxy Verification Flow

TABLE F2 ISO 8583 Messages and Important Fields for Proxy Verification Flow

STEPS MESSAGE IMPORTANT FIELDS/DATA ELEMENTS (DE)

1 FI specific Debtor, creditor, proxy ID
2–3 X200 DE2, DE 3, DE 18, DE 32, DE 41, DE 42, DE 43, DE 102, and fields for carrying proxy ID details
4–5 X210 DE 39, echo fields from request message, response details to proxy verification
6 FI specific Counterparty details, identifiers

iii. Successful/Rejected Transaction Flow

TABLE F3 ISO 8583 Messages and Important Fields for Successful/Rejected Transaction Flow

STEPS MESSAGE IMPORTANT FIELDS/DATA ELEMENTS (DE)

1 FI specific Debtor, creditor, transaction details
2–3 X200 DE2, DE 3, DE 18, DE 32, DE 41, DE 42, DE 43, DE 102, and private fields for carrying debtor’s information
4–5 X210 DE 39 and echo fields from request message
6 FI specific Transaction information, counterparty details
 Messaging Standards in Fast Payments | 37

APPENDIX G: ISO 20022 MESSAGE LINKAGE

i. ISO 20022 Messages and Field Descriptions

TABLE G1 ISO 8583 Messages Used in Linkage between Transaction Flow, Processing Steps with Messaging
Standards
MESSAGE MESSAGE CATEGORY FIELDS AVAILABLE
acmt.023 Account management <Assgnmt> - Assignment
<MsgId> - Message Identification
<CreDtTm> - Creation Date Time
<Assgnr> - Assigner
<Assgne> - Assignee
<Vrfctn> - Verification
<Id> - Identification
<PtyAndAcctId> - Party and Account Identification
<Acct> - Account
<Othr> - Other
<Id> - Identification
acmt.024 Account management <Assgnmt> - Assignment
<MsgId> - Message Identification
<CreDtTm> - Creation Date Time
<Assgnr> - Assigner
<Assgne> - Assignee
<Rpt> - Report
<OrgnlId> - Original Identification
<Vrfctn> - Verification
<OrgnlPtyAndAcctId> - Original Party and Account Identification
<Pty> - Party
pain.013 Payment initiation <MsgId> - Message Identification
<CreDtTm> - Creation Date Time
<InitgPty> - Initiating Party
<PmtInf> - Payment Information
<PmtMtd> - Payment Method
<ReqdExctnDt> - Requested Execution Date
<Dbtr> - Debtor
<DbtrAcct> - Debtor Account
<DbtrAgt> - Debtor Agent
<CdtTrfTx> - Credit Transfer Transaction
<PmtId> - Payment Identification
<Amt> - Amount
<ChrgBr> - Charge Bearer
<CdtrAgt> - Creditor Agent
<Cdtr> - Creditor
<CdtrAcct> - Creditor Account
<RmtInf> - Remittance Information
pain.014 Payment initiation <MsgId> - Message Identification
<CreDtTm> - Creation Date Time
<InitgPty> - Initiating Party
<OrgnlGrpInfAndSts> - Original Group Information and Status
<OrgnlMsgId> - Original Message Identification
<OrgnlMsgNmId> - Original Message Name Identification
<OrgnlPmtInfId> - Original Payment Information Identification
<GrpSts> - Group Status
<TxInfAndSts> - Transaction Information and Status
pacs.002 Payment clearing and <OrgnlMsgId> - Original Message Identification
settlement <OrgnlMsgNmId> - Original Message Name Identification
<OrgnlCreDtTm> - Original Creation Date Time
<GrpSts> - Group Status
<TxInfAndSts> - Transaction Information and Status
<TxSts> - Transaction Status
<OrgnlTxRef> - Original Transaction Reference
<ClrSysRef> - Clearing System Reference
38 | Messaging Standards in Fast Payments

MESSAGE MESSAGE CATEGORY FIELDS AVAILABLE

pacs.004 Payment clearing and <MsgId> - Message Identification
settlement <CreDtTm> - Creation Date Time
<InitgPty> - Initiating Party
<SttlmInf> - Settlement Information
<TxInf> - Transaction Information
<OrgnlInstrId> - Original Instruction Identification
<OrgnlClrSysRef> - Original Clearing System Reference
<OrgnlIntrBkSttlmAmt> - Original Interfinancial institution Settlement Amount
<RtrdIntrBkSttlmAmt> - Returned Interfinancial institution Settlement Amount
<Dbtr> - Debtor
<DbtrAcct> - Debtor Account
<DbtrAgt> - Debtor Agent
<Cdtr> - Creditor
<CdtrAgt> - Creditor Agent
<CdtrAcct> - Creditor Account
pacs.008 Payment clearing and <MsgId> - Message Identification
settlement <CreDtTm> - Creation Date Time
<InitgPty> - Initiating Party
<CdtTrfTxInf> - Credit Transfer Transaction Information
<Dbtr> - Debtor
<DbtrAcct> - Debtor Account
<DbtrAgt> - Debtor Agent
<PmtId> - Payment Identification
<Amt> - Amount
<Cdtr> - Creditor
<CdtrAgt> - Creditor Agent
<CdtrAcct> - Creditor Account
<RmtInf> - Remittance Information
<IntrBkSttlmAmt> - Interfinancial institution Settlement Amount
<ChrgBr> - Charge Bearer
remt.001 Remittance informa- <MsgId> - Message Identification
tion <CreDtTm> - Creation Date Time
<InitgPty> - Initiating Party
<RmtInf> - Remittance Information
<Ustrd> - Unstructured
<Strd> - Structured
<OrgnlPmtInf> - Original Payment Information

ii. Proxy Verification Flow

TABLE G2 ISO 20022 Messages and Important Fields for Proxy Verification Flow
STEPS MESSAGE IMPORTANT FIELDS
1 FI specific Debtor, proxy ID
2–3 acmt.023 <Assgnmt>, <MsgId>, <CreDtTm>, <Assgnr>, <Assgne>, <Vrfctn>, <Id>, <PtyAndAcctId>, <Acct>, <Othr>,
<Id>
4–5 acmt.024 <Assgnmt>, <MsgId>, <CreDtTm>, <Assgnr>, <Assgne>, <Rpt>, <OrgnlId>, <Vrfctn>,
<OrgnlPtyAndAcctId>, <Pty>
6 FI specific Identifiers, counterparty details
 Messaging Standards in Fast Payments | 39

iii. Successful/Rejected Transaction Flow

TABLE G3 ISO 20022 Messages and Important Fields for Successful/Rejected Transaction Flow

STEPS MESSAGE IMPORTANT FIELDS

1 FI specific Identifiers, debtor, creditor, transaction details
2–3 pacs.008 <MsgId>, <CreDtTm>, <InitgPty>, <CdtTrfTxInf>, <Dbtr>, <DbtrAcct>, <DbtrAgt>, <PmtId>, <Amt>,
<Cdtr>, <CdtrAgt>, <CdtrAcct>, <RmtInf>, <IntrBkSttlmAmt>, <ChrgBr>
4 pacs.002 <OrgnlMsgId>, <OrgnlMsgNmId>, <OrgnlCreDtTm>, <GrpSts>, <TxInfAndSts>, <TxSts>, <OrgnlTxRef>
5 pacs.002 Fields of step 4 and <ClrSysRef>
6 FI specific Creditor, Transaction details, Charges, Value Date, Identifiers

iv. Request-to-Pay Flow

TABLE G4 ISO 20022 Messages and Important Fields for Request-to-Pay Flow

STEPS MESSAGE IMPORTANT FIELDS

1 FI specific Identifiers, debtor, creditor, requested transaction details including amount, reason
2–3 pain.013 <MsgId>, <CreDtTm>, <InitgPty>, <PmtInf>, <PmtMtd>, <ReqdExctnDt>, <Dbtr>, <DbtrAcct>, <DbtrAgt>,
<CdtTrfTx>, <PmtId>, <Amt>, <ChrgBr>, <CdtrAgt>, <Cdtr>, <CdtrAcct>, <RmtInf>
4 FI specific Requested transaction details, requestor details, amount details
5 FI specific Response details
6–7 pain.014 <MsgId>, <CreDtTm>, <InitgPty>, <OrgnlGrpInfAndSts>, <OrgnlMsgId>, <OrgnlMsgNmId>,
<OrgnlPmtInfId>, <GrpSts>, <TxInfAndSts>
8 FI specific Response details
40 | Messaging Standards in Fast Payments

APPENDIX H: PROPRIETARY MESSAGE LINKAGE

i. Proxy Verification Flow

TABLE H1 Proprietary Messages and Important Fields for Proxy Verification Flow

STEPS MESSAGE TYPE IMPORTANT FIELDS

1 FI specific Debtor, proxy ID
2–3 Implementation Debtor, proxy ID, identifiers
specific
4–5 Implementation Identifiers, creditor, original transaction, proxy response
specific
6 FI specific Identifiers, counterparty details

ii. Successful/Rejected Transaction Flow

TABLE H2 Proprietary Messages and Important Fields for Successful/Rejected Transaction Flow

STEPS MESSAGE TYPE IMPORTANT FIELDS

1 FI specific Identifiers, debtor, creditor, transaction details, on-behalf-of fields (optional)
2–3 Implementation Identifiers, debtor, creditor, transaction details, on-behalf-of fields (optional), clearing specific fields
specific
4–5 Implementation Response code, response details, settlement information(optional)
specific
6 FI specific Transaction information, counterparty details

iii. Request-to-Pay Flow

TABLE H3 Proprietary Messages and Important Fields for Request-to-Pay Flow

STEPS MESSAGE TYPE IMPORTANT FIELDS

1 FI specific Identifiers, debtor, creditor, requested transaction details including amount, remittance information
2–3 Implementation Identifiers, debtor, creditor, requested transaction details, charge bearer, remittance information
specific
4 FI specific Requested transaction details, requestor details, amount details
5 FI specific Response details
6–7 Implementation Response code, response details, identifier, original request message details
specific
8 FI specific Response details
 Messaging Standards in Fast Payments | 41

APPENDIX I: AUTHORIZATION <AUTHSTN> APPENDIX J: AUTHENTICATION <AUTHNTCN>

DETAILS TAG DETAILS

This tag is used for user identification or to check whether The Authentication <Authntcn> tag can carry the following
the initiating party is permitted to make the transaction details:
from the specified account in the message by usage of any
type of user key. 1. Message Authentication Code <MsgAuthntcnCd>
Message Authentication Code is used for assuring nonre-
1. Code <Cd>
pudiation of messages. It is used for confirming that the
This tag represents authorization in a predefined coded
stated sender has sent the message and that it has not
format and can be used for sending the authentication
been changed in the transportation of the message.
confirmation. The codes are defined as follows:
a. AUTH (Preauthorized file) 2. Date <Dt>
b. FDET (File-level authorization details) This tag will contain date and time information on which
c. FSUM (File-level authorization summary) the authentication is provided.
d. ILEV (Instruction-level authorization)
3. Channel <Chanl>
2. Proprietary <Prtry> This tag is a parent tag and represents the channel used
This tag specifies the authorization in a free-text format to authenticate the transaction. This tag does not carry
with a maximum length of 128 characters. This tag can information but has the following subtags/elements:
be used to carry PINs, passwords, and other customer-au-
3.1 Code <Cd>
thentication details after encrypting the data.
The tag contains a list of predefined values for the chan-
nels used to authenticate the customer—that is, the
channel used to authenticate the mandate. The list has
the following:
a. ATM
b. CARD
c. INBA (Internet banking)
d. MOBI (Mobile)

3.2 Proprietary <Prtry>

Proprietary codes can be input in this tag to represent
another form of customer authentication done apart
from the predefined list of codes.
42 | Messaging Standards in Fast Payments

APPENDIX K: UPI: MOBILE BINDING PROCESS 4. Register user webservices

In this process, a call is made to the PSP server name
The process of mobile binding is accomplished by the fol-
used at the time of registration. If all the data sent is cor-
lowing steps:
rect and matches the PSP records, either the PSP sends
1. Telephony manager a successful message or an error message is displayed to
the user.
This process is to collect the device ID and International
Mobile Equipment Identity (IMEI) of the device on which
5. Log-in page
the application is going to be used.
On a successful registration, the user is redirected to a
2. Silent SMS process log-in page, where, to add the bank account, a log-in pin
is required that was set at the time of registration.
In this process, a message is sent to verify the user’s
mobile number entered during the registration process.
6. Validate user webservice
3. Get mobile number PSP server Once the PIIN is entered, a validated user webservice is
called. If the details are correct, the user is redirected to
This process has three input parameters—that is, device
the main menu, from where the actual transactions can
ID, IMEI, and SMS (which is sent to the server). The
be made.
server responds back with the mobile number confir-
mation of user.
 Messaging Standards in Fast Payments | 43

NOTES
1. IBM, https://www.ibm.com/docs/en/ftmswsfm324?topic=components-message-standards-message-
definitions-message-domains
2. ISO, https://www.iso.org/obp/ui/#iso:std:iso:8583:-2:ed-1:v1:en
3. ISO, https://www.iso20022.org/iso-20022-message-definitions?business-domain=1
4. SWIFT, https://www.swift.com/standards/iso-20022
5. The details of the change requests submitted are available on the following portal: https://www.
iso20022.org/development/status-iso-20022-submissions
6. BCS Consulting, https://www.bcsconsulting.com/blog/iso20022-interoperable-or-not-so-standard/
7. SWIFT, https://www.swift.com/standards/iso-20022
8. Financial Transaction Message Tools, http://www.fintrnmsgtool.com/iso-mti-code.html
9. ISO, https://www.iso20022.org/iso-20022-message-definitions?business-domain=1
10. Third-party providers rely on customer accounts of other financial institutions.
11. IRDBT, https://www.idrbt.ac.in/assets/publications/Reports/IPTS2018/K.Spandana.pdf
12. https://sites.google.com/site/paymentsystemsblog/iso8583-financial-transaction-message-format
13. https://sites.google.com/site/paymentsystemsblog/iso8583-financial-transaction-message-format
14. https://sites.google.com/site/paymentsystemsblog/iso8583-financial-transaction-message-format
15. More details on the RTPG scope and messages can be found at https://www.iso20022.org/cata-
logue-messages/additional-content-messages/iso-20022-real-time-payments-group-rtp