Swift Mi Brochure Swiftforhvpsystems

SWIFT for high-value payment market
infrastructures
– End-to-end solutions for payment clearing and settlement
1
SWIFT’s offering for high-value payment market infrastructures
Table of contents
Introduction
03 – 03
Executive Summary
04 – 04 Evolving demand
05 – 05 SWIFT’s compelling offer
06 – 06 Benefits
High-value payment market infrastructure – customer perspective

09 – 09 Introduction
10 – 10 Stakeholders of HVP MI
12 – 16 Functional overview
17 – 17 Conclusion

18 – 21 SWIFT Standards
21 – 43 SWIFTNet messaging services
43 – 46 SWIFTNet messaging infrastructure
46 – 50 Examples of domestic and regional models of HVP MIs
50 – 50 Professional services
Appendices
52 – 57 A: Details on transaction processing
57 – 61 B: Delivery versus payment (DVP)
61 – 65 C: Payment market infrastructures clearing and settling high and low value
payments in the same system
65 – 67 D: Summary of SWIFT interface products
67 – 67 E: Links to related documentation
67 – 67 F: Abbreviations
68 – 68 G: Glossary
3
Introduction
In this document we explain how SWIFT’s products and services offering supports
business functions of a high-value payment market infrastructure (HVP MI). We propose
that the payments market infrastructure community considers using the SWIFTNet
messaging platform to develop future national payment systems.
Our purpose is to:
— Share views and observations about HVP MIs such as deffered net settlement (DNS)
and real-time gross settlement (RTGS) systems derived from our involvement in
various markets, and
— Provide an outline of how we believe SWIFT’s capabilities can support the evolution of
a HVP MI generally.
SWIFT – a community founded by and for the financial services industry

SWIFT is a community-inspired co-operative, founded by and for the financial services
industry. SWIFT works globally with more than 8,400 organisations including banks,
market infrastructures, securities institutions, corporations, network providers, business
partners and technology companies to ensure the financial world can carry out its
business operations with certainty.
SWIFT’s role is two-fold:
1. To provide the platform, products and services that allow customers to connect and
exchange financial information securely and reliably;
2. To act as the catalyst that brings the financial community together to work
collaboratively to shape market practice, define standards and consider solutions to
issues of mutual concern and interest.
More than 60 payments clearing systems rely on SWIFT services

SWIFT is the messaging hub for an expanding number of clearing and settlement
systems in payments, securities and foreign exchange. In payments, more than 60
clearing systems covering 85 countries around the world rely on SWIFT for the secure
messaging, connectivity and common message standards essential to their smooth
operation. SWIFT services have been adopted by many communities for their HVP MI,
and increasingly so in support of low-value payment market infrastructures (LVP MIs).
We welcome questions, feedback and further discussion on the content of this
document.
4
Executive Summary
Evolving demand
Towards a more harmonised, efficient and less risky payment system environment
Driven by technological developments, regulatory pressure and evolving business
practices, payment systems globally are undergoing constant enhancements to increase
operational efficiency, while reducing associated costs and risks for both the operator and
users of the system.
In addition, we have observed trends that are common across a number of communities
examining the potential evolution of their high-value payments landscape:
— Attracting processing of a greater range of low-value payments;
— Further increasing security, operational reliability, and business continuity;
— Adopting international standards to increase linkages and improve interoperability
between alternative systems, and facilitate on-boarding.
Consequently, the new demands that are developing in HVP MIs are:
1. A transaction input service, to forward payment instructions to the HVP MI in order to
achieve the settlement of funds. The transport mechanisms needed are transaction-
by-transaction in real-time or files of bulk payments in batch mode.
2. A transaction monitoring and control service, to access online information to monitor
payment flows and exposures, and to control payment process parameters. The
transport mechanisms needed are through a secure interactive session or browse
using the HTTPS protocol.
3. A report and reference data exchange service, to transport files of data that includes
operational and statistical reports related to the payments process or participant
profiles and reference data.
4. A common language and rules, covering the entire payment process chain from
transaction input, to cash management, to reporting management.
SWIFT’s compelling offer

A compelling offer with the flexibility to adapt to the needs of domestic
communities
Our objective is to propose to the community a compelling offer that can support the next
generation of HVP MIs towards a world-class structure. SWIFTNet is SWIFT’s advanced
Internet protocol-based messaging platform that is at the base of offerings described below.
1. A complete set of ISO 20022 and SWIFT message standards, covering the entire
payment process chain from transaction input, to cash management, to reporting
management. Standards are at the heart of SWIFT’s value proposition.
2. A complete set of SWIFTNet messaging services for high-value transactions with the
security, reliability and availability that our customers expect. They include:
5
— FIN: SWIFT’s core store-and-forward messaging service that enables the

exchange of individual structured financial messages in a secure and reliable way.
— InterAct: supports the exchange of payment messages in XML format as well as
real-time information exchange and transaction control.
— FileAct: SWIFT’s secure and reliable file transfer service that is most efficient when
used to transfer large batches of messages, such as bulk payment files, very large
reports, or operational data.
— Browse: makes it possible to access remote web servers of the payment system
to view and monitor the entire payment process online.
3. A complete set of SWIFTNet connectivity products that enables you to access the
SWIFTNet network and that meets your resilience and throughput requirements.
4. A complete set of professional services, from business consultancy to comprehensive
implementation and support services delivered by SWIFT or SWIFT partners, enable
easier deployment and the operational usage of SWIFT messaging services.
Benefits
The role of SWIFT in the financial community
Engaging the community
It is the involvement of our customers as part of a dynamic community that gives us our
unique strength. We are actively and continuously collecting input and feedback from the
broader SWIFT community.
We have a customer-centric organisation to be in touch with the needs of the different
geographical markets, while maintaining the global scale that is fundamental to our
business. Three autonomous regions – EMEA, Asia Pacific and Americas – bring
decision-making closer to our customers.
Unique resilience, reliability and availability

We consistently deliver quantifiable business value and proven technical excellence to our
members through our comprehensive messaging standards, the security, reliability and
high availability (99.999%) of our messaging platform and our role in advancing straight-
through processing.
The results of a recent customer survey confirm that our customers continue to place
significant value on our core strengths – security, reliability and resilience – and that we
continue to deliver to your high expectations in these areas.
6
Pricing to maximise usage and benefits to the community

Our main business model is based on economies of scale. The lower the prices, the more
traffic customers send and, because of economies of scale, the lower are our unit costs.
The lower the unit costs, the lower prices can be and the more traffic is sent.
Over the past ten years our message prices have been reduced by over 70%. In 2007
alone, prices were reduced cumulatively by 25 percent, with a combination of reduced
prices and a rebate on all messaging traffic. A further 5 percent price reduction was
applied in January 2008.
In addition, high-volume customers are able to opt for a fixed fee pricing scheme. This
Fixed Fee pricing scheme enables customers to increase their current volume base by
50% at no additional cost. The scheme offers significant cost savings and meets
customer demand for predictability.
A single window to the financial industry

By using a shared technology platform to communicate with market infrastructures,
counterparties and customers globally, our customers reduce the costs of implementing,
maintaining and operating their communications infrastructure. They avoid the
development costs of a proprietary solution and the complexity of operating disparate
systems.
Benefits for market infrastructures

High resilience
The SWIFTNet communication services comply with the applicable principles (e.g.
security and resilience) established by the Committee on Payment and Settlement
Systems (CPSS) for Systemically Important Payment Systems.
SWIFT is always looking to evolve its resilience appropriately and currently going through a
strategic evolution that will further enhance SWIFT’s already very high resilience. Furthermore,
we are also actively exploring how to provide our own emergency backup. In addition,
SWIFT is exploring how to better support market infrastructures and large financial
institutions in their need to improve their own resilience (e.g. for central applications).
World-class security
The SWIFTNet architecture includes three layers of security, ensuring user authentication
and data confidentiality. The SWIFTNet Public Key Infrastructure verifies the user
certificates validity and Closed User Group (CUG) membership in real time. It also allows
immediate revocation.
Industry standard solution

By adopting SWIFTNet, market infrastructures and their users will benefit from compatible
application software and off-the-shelf connectivity products.
7
Cost reduction
By using SWIFTNet, central institutions avoid the development costs related to a
proprietary communication solution and leverage SWIFT’s global economies of scale. It
also provides a future-proof solution whereby SWIFT takes care of technology upgrades
over time.
Time to market
New services can be made rapidly available to the entire SWIFT community or to a selection
of financial institutions within a SWIFTNet Closed User Group. There is no need to define,
implement, test, roll out and support a proprietary communication and security solution.
Risk reduction
SWIFTNet is already used to provide access to mission critical services such as CLS,
TARGET2, and Euroclear. SWIFT has also gained experience in migrating a worldwide
user base from an X.25 network to an IP environment.
Focus on core service

SWIFTNet allows the market infrastructure to focus its investments and resources on its
core services by taking advantage of an industry-owned messaging infrastructure.
Benefits for participants
Cost reduction
Most financial institutions need to access a large number of services, in some cases
mandated by regulators, to access service providers. They often implement many
business critical communication chains ensuring reliable transactions exchanges with
peer institutions and market infrastructures. These communication chains include various
components such as communication lines, and resilient computers running
communication protocols and ensuring end-to-end security.
SWIFTNet offers single window access to these institutions. The same communication
infrastructure can be reused many times. This represents significant cost avoidance,
hence a competitive advantage to SWIFT customers.
Most IT projects indeed underestimate less visible costs. While some costs such as the
cost of communication lines, software and hardware are easily identified, other costs
relate to hidden overhead, such as the involvement of legal, audit and procurement
departments. Costs related to staff training, documentation of processes and procedures,
disaster procedures and disaster take-over exercises are usually forgotten. Re-usability
represents a significant reduction of IT expenditures. Simulation shows that as of three
communication chains, SWIFTNet is significantly more cost effective compared to
isolated communication chains. These benefits are for a large part due to effort reduction
during implementation and operations.
8
Business flexibility
A standard SWIFTNet access infrastructure introduces flexibility in doing business. Joining
any new service or changing provider is a pure business decision. The decision is not
constrained by the need to learn, invest and implement yet another communication chain.
Independence from service providers

Selecting a financial service provider connected to SWIFTNet is also a pure business
decision. SWIFTNet makes it easy to move rapidly from one service provider to another if
deemed necessary.
Trusted third party service

To facilitate dispute resolution, non-repudiation may be invoked when exchanging data
over SWIFTNet, SWIFT playing the role of the trusted third party.
9
High-value payment market infrastructure –

customer perspective
Introduction
Payment market infrastructure services
The Committee on Payment and Settlement Systems (CPSS)1 in January 2006 outlined
the three key payment infrastructure services as follows:
— Transaction infrastructure service provides services to create, validate, and transmit
payment instructions.
— Clearing infrastructure service provides services to transmit, reconcile, and in some
cases confirm payment instructions between financial institutions and calculate
interbank settlement positions.
— Settlement infrastructure service provides interbank funds transfer services by settling
the claims between the participating institutions’ accounts at the settlement bank.
Payment market infrastructure services

Clearing Settlement Transaction
Transaction infrastructure
infrastructure infrastructure infrastructure
Transaction input Validation Clearing Settlement Notification
Types of payment Business Clearing process Settlement process Output delivery

— Individual payment — Verify user — Sort and match — Collect and check — Communicate the
orders credentials payment the integrity of result of the clearing
— Balances of instructions settlement claims & settlement
ancilliary systems — Payment instrument between processes to
(ACH, CSD, etc.) validation participants — Verify the availability relevant
— Cash legs of of sufficient funds participant(s)
— Verify the paying — Collect, process for settlement
securities participant’s ability — Communicate the
transactions (DvP) and aggregate
to pay payment data for — Settle claims status of
Submission mode each participant through funds unprocessed
Transaction transfer between transactions to
— Real-time basis – — Payment message — Store payment data participants’ relevant
typically for validation (syntax reports accounts participant(s)
payments with large and semantic)
amount and time — Calculate gross or — Record the — Transmit payment
critical Technical net settlement settlement activities data reports as
— Batch process – for — User authentication positions for each appropriate to
payments that are participant relevant
— integrity and non- participant(s)
not time critical
repudiation of the
payment orders
Figure 3.1: Service components of HVP MIs

1 The Committee on Payment and Settlement Systems (CPSS) of the Bank for International Settlements (BIS) contributes
to strengthening the financial market infrastructure by promoting sound and efficient payment and settlement systems.
BIS is an international organisation which fosters international monetary and financial cooperation and serves as a bank for
central banks.
10
Stakeholders of HVP MIs

Ecosystem
Many different types of institutions either directly or indirectly take part in HVP MIs
because the settlement of balances at the end of the day must occur across the books of
the central bank (i.e. in central bank money).
Indirect participants
Indirect participant
Direct participant A Direct participant B

Corporate
HVP MI
Payment system participant (I) CSDs LVP MI

Special participants Ancillary systems
Figure 3.2: Stakeholders of HVP MIs

11
HVP MI service administrator

The HVP MI service administrator typically owns and manages the HVP MI and is
responsible for the services that it provides, for example, the RTGS service. It is typically
either a central bank or a bank-owned entity (such as a bankers’ association).
The service administrator is also often the business operator which provides liquidity
facilities to the participants of the HVP MI.
Furthermore, the service administrator is responsible for managing the HVP MI membership,
general administration, and providing the payment market infrastructure services.
Participants
In general, all institutions that use payment system services are referred to as ’participants’.
These participants can further be subdivided into direct and indirect participants (see also
section 3.6 below). Institutions that participate directly in the HVP MI are:
5. Banks that are involved in clearing of high-value payments for their own account or
on behalf of account holding customers.
6. Central bank as a participant to execute its own payments arising from treasury
operation, to inject liquidity in the system via credit facilities, or to facilitate settlement
of government securities transactions.
7. Other institutions authorised by the service administrator to participate in the service
such as governmental bodies, corporates, and other non-financial institutions.
8. Ancillary systems:
— Low-value payment market infrastructures including Automated Clearing Houses (ACH)
or other clearing agencies which require settlement of balances through the HVP MI.
— The domestic Central Securities Depository (CSD) to facilitate collateralised
lending, delivery-versus-payment (DVP) of securities issuance and transfer in
settlement of primary and secondary market obligations. Additionally, the HVP MI
may require a link to an International Central Securities Depository (ICSD) to
facilitate transfer of securities collateral for collateralised lending in the HVP MI.
Regulator
The banking regulators usually do not participate in the payment system itself. However, they
require from financial institutions that they oversee reporting of transactions settled through
the HVP MI. Furthermore, regulators have a responsibility to oversee systemically important
payment systems to ensure financial stability of the market in which they operate.
12
Functional overview
Business and operational components
The primary functions of an HVP MI are to receive payment instructions, check a set of
conditions, queue payments if needed, clear them, perform settlement, and notify
relevant participants.
On the bank side
Clearing and Customer

Initiation Processing Reconciliation
Settlement Service
On the MI side
Payment transaction Transaction

Validation Clearing Settlement Notification
processing input
Cash
Liquidity management — Risk management — Payment investigation
management
Participant
Membership and profile management — Reference data
administration
Reporting
Operational — Regulatory — Statistical
management
Generic
Customer end-to-end secure communication
communication
Figure 3.3: Business and operational components of HVP MIs

13
Payment transaction processing

The life cycle of a payment
Figure 3.4 illustrates the flow of payment transactions through the processes in an HVP
MI, from the receipt of an individual payment transaction or multilateral settlement
transactions through to validation, clearing, settlement and notifications of settled and
also non-settled payment transactions.
For further details, please refer to Appendix A: Details on the transaction processing.
HVP MI
Central Receiving
Institution participant
Y Are all Y
Submission Reception conditions Settlement Notification Receipt
Validation
(a) (b) met? (g) (h) (i)
(c)
(d)
Event or
N time driven
Abort notification (c’)
Payment queued
Abort notification if not (e)
Paying settled at the end of
participant settlement period (f)
Figure 3.4: Payment process
a. A paying participant generates payments that will settle through the HVP MI. It then
sends those payment instructions through the appropriate communication channel
either individually or in batches. The submission of payment instructions to the HVP
MI are typically automated, though manual entry is possible.
b. The payment instructions are received through an interface system that routes to the
appropriate channel those payment instructions that must be processed through the
HVP MI. Or if the HVP MI also accepts non HVP MI payments, then all payments are
routed through the same channel.
c. The HVP MI performs initial business validation of the incoming payment instructions.
Validation determines whether transactions can be accepted for further processing. If
valid, payment transactions are queued according to value date. If invalid, instructions
are rejected, logged and advised to paying participants.
14
d. The clearing process verifies various conditions of the settlement claim. For example, it
assesses queued transactions according to priority for debit against the clearing
balances of the associated participants. Where the clearing balance is insufficient, the
HVP MI may automatically draw on intraday credit facilities or collateralised credit
facilities provided by the service administrator to facilitate payment.
e. If a payment transaction cannot be funded from the clearing balance, taking into
account intraday credit and collateralised credit availability, the payment transaction is
re-submitted to the queue.
f. At end-of-day, any payment transactions for that value date remaining in the queue or
frozen are automatically rejected.
g. If all conditions are met, the claim is transferred and booked between the settlement
accounts of the paying and receiving participants. As a general rule, the payment is
said to be final (i.e. the point in time at which a payment becomes irrevocable) when
the transfer of the settlement claim between the settlement accounts of the
underlying parties is completed.
h. Notification to the receiving participant is sent either in the form of releasing the
original payment instruction or sending a credit advice (i.e. confirmation of credit).
i. The receiving participant receives the original payment instruction or the notification that
confirms the credit of fund in its settlement account. It also receives the end-of-day report
that includes a recap of all transaction activities throughout the day (e.g. bank statement).
Cash management
Sound liquidity management to sustain financial stability
The ability to fund payments is crucial to the stability not only of the HVP MI per se but
also at the industry level, since a liquidity shortfall at a single institution can have a
gridlock effect that can lead to system-wide repercussions and beyond. Therefore,
managing liquidity is among the most important activities conducted by direct participants
of the HVP MI. Sound liquidity management includes not only the management of the
liquidity position of the bank’s settlement account but also the monitoring and
management of evolution of funding requirements intraday.
In order to sustain settlement efficiency within the HVP MI, central banks manage the
aggregate level of funds in the system and usually provide participants with several
sources of funding:
— Centralised sources of funds: intraday liquidity through for example credit extensions
in order to sustain settlement efficiency within the HVP MI. Two common forms of
credit extension are repos and overdrafts on central bank accounts.
— Liquidity bridges between systems: the possibility to transfer liquidity held in different
payment systems in order to facilitate the settlement process.
15
Participant administration
Participant structure and access criteria

As mentioned in section 3.2, one of the key roles of the service administrator is to
manage the membership of the HVP MI, often known as the access criteria. The access
criteria may feature various requirements such as the capital base, credit rating, legal
status, as well as technical, operational and geographical criteria.
As for the participant structure, there are usually two basic access alternatives available to
join the HVP MI:
— Direct participation: hold a settlement account at the central bank with direct access
to the system for settlement of high-value payments.
— Indirect participation: establish an agency or correspondent banking relationship with a
direct participant of the system. The indirect participant typically does not hold a
settlement account at the central bank and does not have direct access to the HVP MI.
In some countries, it is mandatory for financial institutions to participate directly in the HVP MI.
Participant profile management

The service administrator must be able to define and amend all participant and operator
profile settings including security and access controls, and any other business
administration functions such as intraday credit and account information enquiries and
updates. Additionally, it must be able to, if needed, update any changes to the
participants’ profile with immediate effect.
Reporting and reference data management
Exchange of bulk data including reports and reference data

Various categories of reports are generated by the HVP MI to inform participants about
their operational and statistical activities.
Some examples of report categories are:
— Operational reports: statement of account, statement of transaction status summary
and details, interim statements of account and transactions, transaction history and
audit trails, end-of-day reports, etc.;
— Statistical reports: Throughput performance, payment submission time, system start-
up/close, etc.;
— Reference data: User directory information;
— Administration reports: Operational/system guidelines, etc.
They can further be broken down into intraday enquiry reports on request basis and
scheduled reports at end-of-day sent automatically at predefined times.
16
Generic communication
Person-to-person exchange of sensitive data

The financial services industry is an industry where documentation is crucial and where it
needs to travel securely between parties.
The HVP MI segment needs a facility for the exchange of secure information person-to-
person for sensitive data such as credit lines, service level agreements, and business
relationships exchanged within the market infrastructure community.
Conclusion
SWIFT’s response to the key demands
This chapter talked about an overview of the HVP MI environment from the community
perspective and the key functions of a national high-value payment system.
The following chapter will focus on SWIFT’s products and services that support those key
functions – a) payment transaction processing, b) cash management, c) participant
administration, d) reporting management, and e) generic communication, with an aim to
illustrate how the key features of SWIFT’s offerings – resilient messaging platform, industry
message standards and a complete set of messaging services – indeed respond to the
key demands in building a state-of-the-art payment system and benefiting from it.
17
SWIFT’s offering for high-value payment

market infrastructures
SWIFT Standards
Standards are at the heart of SWIFT’s value proposition. SWIFT’s leadership in financial
messaging standards is built on decades of success made possible through the active
participation of the entire community.
SWIFT is committed to the collaboration of efforts and interoperability of standards, so
that our community can benefit from potential cost savings, eliminate inefficiencies, and
smoothly expand into previously untapped markets. SWIFT strives to achieve the best
balance between global, regional and sector-specific requirements; and between what is
optimal technically and achievable operationally.
In payments, SWIFT develops and maintains a comprehensive set of business standards
to support end-to-end payment transactions.
SWIFT Standards MT
The message text (MT) standards in ten categories have been developed to support the
business transactions of SWIFT users. To ensure that the multitude of practices and
conventions of users are in harmony, financial messages transmitted via the SWIFT
network must adhere to the message text standards. Standards enable financial
institutions to move from manual to automated initiation and processing of financial
transactions.
SWIFT Standards MX
The new XML-based message standards (MX) have been developed to complement the
traditional MT messages to enable the transfer of richer data for more complex business
transactions. The development of MX standards is based on a number of guiding
principles or concepts that will enforce consistency and predictability across all
messages, the most important being: flexibility, granularity, character sets, maintenance,
and application header.
SWIFT has created a set of standards covering payment initiation, inter-bank settlement
and cash management that are ISO 20022 compliant. (You can find more information on
the UNIFI Payments Messages section on the ISO 20022 website.) The inter-bank
payment standards have a broad scope and cater for high and low-value, single and
multiple, and urgent and non-urgent payments.
18
SWIFT is the registration authority under ISO for the ISO 20022 standards.
Figure 4.1 illustrates the standards that are used in the end-to-end payments transaction
processing.
Interbank Payments (CT & DD)

+ Related Messages
Exceptions & Investigations
Cash Management
MT 1xx, 2xx
MT 9xx
Payment Initiation (CT + DD)

B2C Cash Management
B2C Cash Management

+ Related Messages
MT 101
MT 9xx
MT 9xx
MT-based
XML-based
Ordering Beneficiary
customer customer
Figure 4.1: End-to-end payments standards
The standards usage in each messaging protocol is further described in the following
section.
19
List of message standards

A list of SWIFT Standard MT and MX message categories is shown in table 4.1.
MT Category MX Category
MT 1xx Customer Payments and Cheques acmt.xxx.xxx.xx Account Management
MT 2xx Financial Institution Transfers admi.xxx.xxx.xx Administration
MT 3xx Treasury Markets - Foreign Exchange, camt.xxx.xxx.xx Cash Management

Money Markets and Derivatives
MT 4xx Collection & Cash Letters defp.xxx.xxx.xx Derivatives
MT 5xx Securities Markets pacs.xxx.xxx.xx Payments Clearing

and Settlement
MT 6xx Treasury Markets – Precious Metals pain.xxx.xxx.xx Payments Initiation

and Syndications
MT 7xx Documentary Credits and Guarantees reda.xxx.xxx.xx Reference Data
MT 8xx Travellers Cheques seev.xxx.xxx.xx Securities Events
MT 9xx Cash Management and semt.xxx.xxx.xx Securities Management

Customer Status
MT nxx Common Group Messages sese.xxx.xxx.xx Securities Settlement
setr.xxx.xxx.xx Securities Trade
trea.xxx.xxx.xx Treasury
tsmt.xxx.xxx.xx Trade Services

Management
Table 4.1: SWIFT Standards MT and MX categories and messages

20
SWIFTNet messaging services

Overview
SWIFTNet is SWIFT’s global, secure and reliable messaging platform
SWIFTNet includes an Internet Protocol (IP) based network with a standard connectivity
interface and a range of configurable processing and validation features. SWIFTNet
supports different types of messaging services for different needs in:
— Transaction exchanges;
— Bulk data exchanges;
— Interactive services.
A range of value added features

Using SWIFT’s messaging network offers several layers of added value over traditional
network connections, including high availability and resilience, standardised secure
message protocols, non-repudiation, message validation and store-and-forward
capabilities. These features are typically required by payment systems, and are available,
deployed and used with SWIFTNet.
The following is a summary of major HVP MI business functions with key elements and
the SWIFT products and services that support them.
21
Functions Elements SWIFT’s offering
Payment transaction Transaction input SWIFTNet offers secure, reliable and resilient
processing messaging services to transfer payment and
securities instructions to the central payment
systems.
— FIN for the exchange of individual
structured financial messages in SWIFT
standard format (MTs);
— InterAct for the exchange of individual
structured payment messages in XML
format (MXs).
— FileAct for the exchange of bulk payment
files in any format, including ISO 20022.
Validation SWIFTNet offers central message validation in

FIN and InterAct to ensure messages are
formatted according to SWIFT message
standards, delivery monitoring and
prioritisation, and other value-added features.
Clearing n/a
Settlement n/a
Notification SWIFT Standard messages are available both

in MTs and MXs to support the two flows of
information exchange related to the status of
settled or rejected payments.
Interactive services Cash management SWIFT’s Cash Management solution enables

the exchange of information related to cash
held in settlement accounts as well as
forecasted balance on a real-time intraday
basis. It is built on a set of components:
— SWIFT Standard MT and FIN: A set of MT
Standards in category 9 can be used over
FIN for cash management and
reconciliation purposes.
— SWIFT Standard MX and InterAct: A set of
MX Standards is available using InterAct to
communicate about status, returns,
reversals, and requests for cancellation of
the payment messages.
Transaction monitoring Browse makes it possible to access remote

and information exchange web servers of the HVP MI and view online
information on the payment process. This
includes queued payments, actual and
projected settlement account balances, and
status of unsettled payments.
22
Transaction control InterAct is valuable for transaction-based

functions that can affect the processing of
payment and settlement messages by host
systems. For example, it can be used to
control parameters if a payment is not final,
such as updating limits, the position of
payments in the queues, the priority, or the
revocation of payments.
Participant administration Membership management A key value-added feature of SWIFTNet is the

(access criteria) possibility to form a Closed User Group (CUG)
to exchange specific types of messages or files
in a business community on SWIFTNet.
A CUG consists of:
— Sending and receiving institutions (service
participants)
— A clearing or settlement institution (the
service administrator)
The membership and business rules of a
closed group are owned and administered by
the service administrator.
Reporting management Bulk data exchange FileAct provides a cost-effective way to

(for operational, statistical exchange bulk files in different formats with
and administration reports) your correspondents, while leveraging the
unparalleled security and reliability provided by
the SWIFTNet platform.
Generic communication Secure email Mail provides the simplicity and ease of use of
services desktop email with the security, reliability and
reach that only SWIFT provides.
SWIFT’s compelling offer for HVP MIs supports all key business and operational functions
with appropriate messaging, standards and connectivity products or services that are
simple to use and easy to implement.
HVP business functions Message standards Messaging services Messaging infrastructure
Payment transaction MT/MX FIN/InterAct

Yes
processing Proprietary FileAct
MT/MX FIN/InterAct
Cash management Yes
Proprietary FileAct
Participant MT/MX FIN (V)/InterAct
Yes
administration Proprietary FileAct/Browse
MT/XML FIN (V)/FINInform
Reporting management Yes
Proprietary InterAct/FileAct/Browse
Generic communication N/A Mail Yes
Support Yes Yes Yes
Figure 4.2: SWIFT’s compelling offer

23
SWIFTNet for transaction processing

Overview
As depicted in figure 3.3 above, payment transaction processing is comprised of
transaction input, validation, clearing, settlement and notification. SWIFT’s offerings
support transaction input, validation and notification processes as described below. The
clearing and settlement modules are managed by the central institution.
Transaction input
SWIFT’s messaging services for transaction input enables banks to forward their high-
value payment instructions (and government securities settlement instructions if operated
on the same platform) to the HVP MI securely and reliably in order to achieve the
settlement of funds. They are based on FIN, InterAct or FileAct messaging services.
The payment instructions can be submitted on the following basis:
(a) transaction-per-transaction in real-time, typically for high-value and urgent payments,
as covered by transaction input options 1 and 2 below;
(b) bulk payments in files on batch, typically for non-urgent payments, as covered by
option 3.
All options can coexist in the same system, addressing the entire business flow and
leveraging the same architecture.
Option 1: FIN Y-Copy service for transaction-to-transaction payments

The first transaction input option is FIN Y-Copy, which is a message duplication service.
This topology is normally used for transaction exchange between two direct participants
on a transaction-by-transaction basis. The payment flow from a paying bank to a
receiving bank is illustrated in figure 4.3.
The FIN Y-Copy function is used by more than 70 RTGS systems worldwide, including
domestic, regional as well as global systems such as CHAPS in the United Kingdom and
TARGET2 in Europe.
For further information, please refer to the FINCopy Service Description module of SWIFT
User Handbook.
24
Bank A SWIFTNet Bank B

Internal payment FIN Copy
system
Payment message Payment message
(settled)
SWIFT interface
Settlement Authorisation/
request refusal
SWIFT interface
Central institution
Payment processing
Bank A Bank B Central web server
FIN Copy transaction flow
Figure 4.3: Transaction input using FIN Y-Copy
SWIFT Standards MT that are used for transaction exchange in FIN Y-Copy are illustrated
in figure 4.4. Please note that the SWIFT Standards MX equivalent for customer and
financial institution credit transfers are available, but copying services for such MX
messages are not available at the moment.
Standards in FIN Y-Copy

MT MX
for transaction exchange
Customer Credit Transfer MT 102/103 Not applicable for the moment
FI Credit Transfer MT 200/201/202/203/205 Not applicable for the moment
Request for Cancellation MT 192/292 Not applicable for the moment
Settlement Request MT 096 Not applicable for the moment
Settlement Authorisation MT 097 Not applicable for the moment
Sender Notification MT 012 Not applicable for the moment
Abort Notification MT 019 Not applicable for the moment
Figure 4.4: SWIFT Standards MT for transaction exchange in FIN Y-Copy

25
Option 2: FIN and InterAct in V-topology for transaction-to-transaction payments

The second transaction input option is the V-topology based on the FIN and/or InterAct
messaging services. With the V-topology, Bank A sends its payment instructions to the
HVP MI which clears and settles them before forwarding them to Bank B (see figure 4.5).
This topology is typically used for transaction input from direct participants to the central
point on a transaction-by-transaction basis.
FIN protocol usage will imply the MT standards, and the usage of the InterAct service will
require the market infrastructure to use the MX/ISO 20022 message format.
For further information, please refer to the FIN Service Description and SWIFTNet Service
Description modules of SWIFT User Handbook.

Internal payment V-topology for
system FIN and InterAct
SWIFT interface P
ins aym n d)
tru e tio ttle
ct nt ica e
io
n tif e (s
No ag
s
es
m
SWIFT interface
HVP MI
Payment processing
FIN/InterAct transaction input flow
Figure 4.5: V-topology for transaction input using FIN and InterAct
SWIFT Standards MT and MX that can be used for transaction exchange in V-topology
are illustrated in figure 4.6.
26
Standards in V-topology
MT MX
FIToFICustomerCreditTransfer
Customer Credit Transfer MT 102/103
pacs.008.001.01
FinancialInstitutionCreditTransfer
FI Credit Transfer MT 200/201/202/203/205
pacs.009.001.01
PaymentCancellationRequest*
Request for Cancellation MT 192
pacs.006.001.01
PaymentStatusReport*
Payment Status MT n96/n99
pacs.002.001.01
Payment Reject Cat 1/2 Field :72:/REJT/
pacs.002.001.01
PaymentReturn
Payment Return Cat 1/2 Field :72:/RETN/
pacs.004.001.01
FIPaymentReversal*
Payment Reversal ----
pacs.007.001.01
* Also available in pain area

Figure 4.6: SWIFT Standards MT and MX for transaction exchange in V-topology
Option 3: FileAct in V-topology for bulk payments

The third transaction input option is also the V-topology based on the FileAct messaging
service which is typically used by ancillary systems such as automated clearing houses to
send files of netted position at the end of their netting windows to the HVP MI for final
settlement. Similar to option 1 above, the HVP MI will clear and settle the balance before
notifying the receiving participant with a confirmation of credit. The flow is illustrated in
figure 4.7.
Bulk payments are typically low-value, non-urgent payments batched together for
efficiency. They can be centrally processed by automated clearing houses or they can be
exchanged and cleared bilaterally between banks. Credit transfers and direct debits are
the most commonly used instruments. FileAct can also be used by direct participants to
submit low-value payments in batch to the HVP MI if those bulk payments need to be
settled immediately during the day.
The payment flow from a paying bank to a receiving bank is illustrated in figure 4.7.
For further information, please refer to the SWIFTNet Service Description module of SWIFT
User Handbook.
27

Internal payment
system
Transaction input
SWIFT interface using FileAct
Bulk payments Notification

instruction message
(file based) (file based)
SWIFT interface
HVP MI
Payment processing
FIN/InterAct transaction input flow
Figure 4.7: Transaction input using FileAct
SWIFT Standards MT and MX that can be used for transaction exchange using FileAct in
V-topology are illustrated in figure 4.8.
Standards in bulk payments

MT MX
FIToFICustomerCreditTransfer
Customer Credit Transfer MT 102/103
pacs.008.001.01
FinancialInstitutionCreditTransfer
FI Credit Transfer MT 200/201/202/203/205
pacs.009.001.01
PaymentCancellationRequest*
Request for Cancellation MT 192
pacs.006.001.01
Payment Status MT n96/n99
pacs.002.001.01
Payment Reject Cat 1/2 Field :72:/REJT/
pacs.002.001.01
PaymentReturn
Payment Return Cat 1/2 Field :72:/RETN/
pacs.004.001.01
FIPaymentReversal*
Payment Reversal ----
pacs.007.001.01
* Also available in pain area

Figure 4.8: SWIFT Standards MT and MX for transaction exchange using FileAct
28
Option 4: FileAct header copy service for bulk payments

This fourth transaction input option is typically used for integrating bilateral exchange of
low-value payments with immediate settlement.
The FileAct header copy offers a simple way to copy file data to a central point for settlement
authorisation and further processing of the bulk payments file. The FileAct header copy
service currently copies header data. In future releases, it will offer full file copying capabilities,
as illustrated in figure 4.9. In addition, more details can be found in appendix C.

File Header Copy
Internal payment
system 1 Sender
sends file
SWIFT interface
3 Receiver gets file
when approved
for delivery
2 File header OK! 4 Central institution
copy approves file delivery
SWIFT interface
Central institution
Payment processing
File header copy transaction flow
Figure 4.9: File Header Copy transaction flow

29
Validation
Central message validation
SWIFT only delivers messages to the intended recipient if the contents conform to a
specific reference format. This format is specified in the corresponding SWIFT
Standards documentation. Central message validation is available in FIN and InterAct.
In FIN, central message validation always applies and FIN messages are checked for
correct syntax and semantics. In InterAct, the service administrator can choose to
apply central message validation.
For further details, please refer to the Technical – Message Format Validation Rules module of the
SWIFT User Handbook.
Notification
Sender notification
Appropriate MT and MX messages for flows of information related to the status of
payments from HVP MI to paying participants are shown in table 4.2.
Confirmation of debit
The paying participant is notified with a confirmation of debit when the settlement is
completed.
SWIFT Standard Message name Purpose
MT 900 Confirmation of debit Advises an account owner of a debit to its

account
MT 012 Sender notification An optional feature in the FIN Copy service.

Notifies the sender when the message has been
released (i.e. settled) by the Central Institution.
camt.004.001.03 ReturnAccount Provides information on the details of one or

more accounts held at the transaction
administrator, including information on the
balances.
camt.006.001.02 ReturnTransaction Provides information on transactions and

booked entries held at the transaction
administrator.
Table 4.2: Notification messages for paying participant about settled payments
30

Internal payment
system Co (a)
nf No
tifi
SWIFT interface an irma ca
d t tio
no /or ion n
tifi se of
ca nd de
tio er bi
n t
SWIFT interface
HVP MI
Payment processing
Bank A Bank B
Central web server
D C
Figure 4.10 : Notification flow for paying participant about settled payments
Abort/rejected notification
The paying participant receives an abort notification if the original payment instruction has
been rejected by the central system.
MT 019 Abort notification Notifies the sender when the message has been
rejected by the Central Institution.
pacs.002.001.02 PaymentStatusReport Informs the previous party in the payment chain

about the negative status of an instruction
(either single or file).
Table 4.3: Relevant messages for notification of rejected payments

31

Internal payment
system (b
)
Re No
SWIFT interface jec tific
no te at
tifi d/ io
ca ab n
tio or
n t
SWIFT interface
HVP MI
Payment processing
Bank A Bank B
Central web server
Figure 4.11 : Notification flow for paying participant about rejected payments
Receiver notification
Appropriate MT and MX messages for flows of information related to the status of
payments from HVP MI to receiving participants are shown in table 4.4.
Confirmation of credit or forwarding the original payment instruction
The HVP MI may send a credit notice and forward the original payment instruction to the
receiving participant to advise the confirmation of settlement.
MT 910 Confirmation of credit Notifies the account owner of an entry

which has been credited to its account.
pacs.002.001.02 PaymentStatusReport Informs the previous party in the payment

chain about the positive or negative status
of an instruction (either single or file).
Original payment instruction Funds transfer Orders the movement of funds to the
beneficiary institution
Table 4.4: Notification messages for receiving participant about settled payments
32

Internal payment
system (a)
Co Not
n if of
SWIFT interface se de firm icat ion t
nd bit at io at en
er an ion n
no d/ o firm aym
tifi or f Con / p tion
ca it c
tio (c) red stru
n c in
SWIFT interface
HVP MI
Payment processing
Bank A Bank B
Central web server
D C
Figure 4.12 : Notification flow for receiving participant about settled payments
SWIFTNet for cash management

Cash management
SWIFT’s Cash Management solution enables the exchange of information related to cash
held in settlement accounts as well as forecasted balances on a real-time intraday basis.
It is built on a set of SWIFT Standards and messaging service components which provide
an industry-wide solution for the exchange of transactional and balance information
between an account owner and its account servicing institution.
— SWIFT Standard MT and FIN, A set of SWIFT Standards MT in category 9 Cash
Management can be used by participants over FIN to provide information on both
corporate and financial institution accounts for cash management and reconciliation
purposes.
— SWIFT Standard MX and InterAct, A set of SWIFT Standards MX for cash
management is available for participants using InterAct to communicate about status,
returns, reversals, and requests for cancellation of the payment messages.
For further information, including the inventory of MT and MX messages,

please visit Standards > More information on swift.com
33
SWIFT Standards MT for Cash Management.
Message Type MT Name Purpose
MT 900 Confirmation of Debit Advises an account owner of a debit to its

account.
MT 910 Confirmation of Credit Advises an account owner of a credit to its

account.
MT 920 Request Message Requests the account servicing institution to

send an MT 940, 941, 942 or 950.
MT 935 Rate Change Advice Advises the Receiver of general rate

change(s) and/or rate change(s) which
applies to a specific account other than a
call/notice loan/deposit account.
MT 940 Customer Statement Message Provides balance and transaction details of

an account to a financial institution on
behalf of the account owner.
MT 941 Balance Report Provides balance information of an account

to a financial institution on behalf of the
account owner.
MT 942 Interim Transaction Report Provides balance and transaction details of

an account, for a specified period of time, to
a financial institution on behalf of the
account owner.
MT 950 Statement Message Provides balance and transaction details of

an account to the account owner.
Table 4.5: SWIFT Standards MT for Cash Management

34
SWIFT Standards MX for Cash Management.
MX Identifier MX Name Purpose
Camt.003.001.03 GetAccount Requests information on the details of one

or more accounts held at the transaction
balances.
Camt.004.001.03 ReturnAccount Provides information on the details of one or

more accounts held at the transaction
balances.
Camt.005.001.03 GetTransaction Requests information about payment

instructions held at the transaction
administrator.
Camt.006.001.02 ReturnTransaction Provides information on transactions and

booked entries held at the transaction
administrator.
Camt.007.001.02 ModifyTransaction Requests one modification in one payment

instruction held at the transaction
administrator and sent by the member,
debiting or crediting its account at the
transaction administrator.
Camt.007.002.02 RequestToModifyPayment Requests the modification of characteristics

of an original payment instruction.
Camt.008.001.03 CancelTransaction Requests the cancellation of one payment

instruction held at the transaction
administrator and sent by the member.
Camt.008.002.02 RequestToCancelPayment Requests the cancellation of an original

payment instruction.
Camt.009.001.03 GetLimit Requests information on the details of one

or more limits set by the member (or on
behalf of the member) and managed by the
Camt.010.001.03 ReturnLimit Provides information on the details of one or

more limits set by the member (or on behalf
of the member) and managed by the
Camt.011.001.03 ModifyLimit Requests modifications in the details of one

particular limit set by the member and
managed by the transaction administrator.
Camt.012.001.03 DeleteLimit Requests the deletion of one particular limit

set by the member and managed by the
Table 4.6: SWIFT Standards MX for Cash Management

35
Participant administration
Closed User Group (CUG)
Membership management
A key feature of SWIFT’s solution for HVP MIs is the possibility to form a Closed User
Group (CUG) to control membership and service parameters to allow exchange of
specific types of messages or files within the market infrastructure community.
A CUG consists of:
— Sending and receiving institutions (also known as service participants)
— A clearing or settlement institution (also known as the service administrator)
The membership and business rules of a closed group are owned and administered by
the service administrator. Any messages from an unauthorised institution will be rejected,
as illustrated in figure 4.13.
User A User B
Central institution
x
Figure 4.13: Closed User Group
HVP MI
36
Profile management
Profile update
As mentioned in section 4.2.1 Overview of SWIFTNet messaging services, SWIFT’s
interactive services – Browse and InterAct – support online business activity monitoring
and profile management.
— Browse offers the service administrator an interface with a secure interactive
browsing capability to monitor business activities including account balances, queued
payments, exceptions and errors, as well as user access. Similarly, Browse can also
be used by participants to effectively monitor payments transaction processing as
well as liquidity management intraday.
— InterAct can be used for critical functions by both the service administrator and
participants. Some examples of critical functions from the service administrator’s
perspective are:
— Opening and suspending settlement accounts
— Managing intraday and overnight credit limits
— Managing all system participants and their access privileges.
InterAct also enables participants to manage queued payments, update any bilateral
intraday credit limits, and better manage liquidity. Figure 4.14 illustrates the interactive
services of InterAct and Browse.

Internal payment InterAct real-time
system information exchange
& transaction control
SWIFT interface
Browse
online information
query
SWIFT interface
Central
institution
Payment processing
InterAct information exchange and control

Browse online information query
Figure 4.14: InterAct and Browse for online information exchange and transaction control
37
Reporting management
Option 1: Bulk data exchange or reporting exchange to and from the central bank
— FileAct provides secure and reliable transfer of files, such as batches of structured
financial messages or large reports in any format. Typical applications in HVP MIs, in
addition to bulk payments processing mentioned earlier, include areas such as
exchange of operational and statistical reports as well as user directory and reference
data as shown in figure 4.15.
For further details about FileAct, please refer to the SWIFTNet Service Description module of the
SWIFT User Handbook.

Internal payment
system
SWIFT interface
FileAct for bulk FileAct for bulk
reporting reporting
SWIFT interface
Central institution
Payment processing
FileAct for bulk reporting
Figure 4.15: FileAct for bulk reporting
Option 2: Transaction-to-transaction reporting to the central bank

The FIN service allows the participants and the central institution to exchange various
types of reports on a transaction-by-transaction basis as well as movements, balance
and statements of settlement accounts.
As described in section 4.2.3 SWIFTNet for cash management, types of messages in
category 9 that can be used for reporting are:
— Balance reporting messages, which provide both cash management and nostro
reconciliation information (balance and transaction details).
— An interest rate change message, which provides a means of advising interest rate
changes to the receiver of the message.
38
— Netting messages (sent between financial institutions and netting systems), which
enable financial institutions to receive balances and details about transactions which
are included in the netting process.
— Status messages, which provide a mechanism for requesting and responding to
business-related information about customers or institutions.
Additionally, various types of reports are available for securities markets or trading
systems such as status reporting, which is provided to inform the instructing party and/or
executing parties of the trade status, for example, prior to its final confirmation or
affirmation, or whatever the position of the trade within the process.
Generic communication
Desktop email with the security, availability and reach of SWIFTNet
— Mail allows the exchange of confidential information within the market infrastructure
community over SWIFTNet securely and reliably, using the installed email applications.
Moreover, Mail helps communities comply with relevant security and audit requirements,
and minimises reputational risk.
An end-user simply adds ‘.swift’ to the end of the addressee’s email address and the
email gets routed over to SWIFTNet automatically, as illustrated in figure 4.17.
Signing with
User A SWIFTNet PKI User B
SNL SNL
Mail SWIFTNet PKI Mail
PKI
gateway FileAct gateway
Store-and-Forward
Local Local
security security
Internet
Email Email
server Email Email server
gateway gateway
Email Email
client client
From: [email protected] From: [email protected]

To: [email protected] To: [email protected]
Figure 4.17: Mail overview

39
SWIFTNet messaging infrastructure

Connecting to SWIFTNet
Messaging infrastructure
Connecting to SWIFTNet requires a connectivity infrastructure and dedicated interfaces at
the customers’ site. Users can opt for direct or indirect connectivity to SWIFT. Figure 4.18
illustrates the typical customer SWIFTNet infrastructure.
SWIFTNet Interfaces SWIFTNet Connectivity

Desktop Messaging Communication
Network
HSM Partner
Alliance Router
WebStation
VPN Network
Alliance box Partner 1
Access
HSM
systems
SWIFT
Alliance
SIPN
Messenger Back
SWIFTNet Link
Office
VPN Network
Alliance
box Partner 2
Gateway
Alliance
WebStation
Internet
Alliance
Lite
Figure 4.18: SWIFTNet connectivity and interface infrastructure overview
Direct connectivity
SWIFT has adopted a multi-vendor model for its Secure IP Network (SIPN) with four
network partners: AT&T, BT Infonet, Colt and Orange Business Services. Each Network
Partner provides a standard offering of managed IP-VPN services. A user wanting to
directly connect to SWIFT can opt to contract with one or more of the network partners
for connectivity to the SWIFTNet messaging platform.
Depending on the resilience and throughput required, customers have the choice
between several connectivity options as follows:
— Alliance Connect Bronze for low volume users;
— Alliance Connect Silver for medium volume users;
— Alliance Connect Gold for high volume users.
40
SWIFTNet requires dedicated interfaces to connect to the users’ applications. SWIFT

provides third-party vendors with mandatory standards and rules for building compatible
interfaces. SWIFT itself also offers interface products for the entire range of SWIFTNet
services.
Depending on the messaging services used and the resilience and throughput required,
customers have the choice between several interface configuration options as follows:
— Alliance Access for FIN only
— Alliance Gateway for InterAct and FileAct
— Alliance Starter Set for low volume users of FIN, FileAct, and Browse
— Alliance Lite for new low volume users
For further information about the SWIFTNet connectivity and interface products, please visit the
Connectivity section on swift.com under the Solutions tab.
Indirect connectivity
For those users who do not wish to connect directly to the SWIFT network, there are
three indirect connectivity options:
— Via another customer. This is called a shared connection.
— By outsourcing the day-to-day operation of the connection to a third party, called a
Service Bureau.
— By turning to a Member-Concentrator who, in addition to the technical connectivity,
provides additional business services like taking care of the SWIFT administration and
invoicing.
41
Example of a SWIFTNet configuration for high-value payment market

infrastructures
A typical HVP MI system configuration
Figure 4.19 illustrates a typical example of system and software configurations for HVP MI
service administrators and participants.
Configurations for both the service provider and participants depend on the capacity,
security, redundancy and integration requirements.
Most of the world’s key financial institutions are today connected to SWIFTNet. As such,
they already have integration software and redundancies in place according to their size
and needs.
SWIFT provides a team of business and technical experts to advise and propose an
optimised configuration for the service provider and participants based on individual and
local requirements (also see section 4.4 below).
Low volume user A Low volume user B Low to Medium volume user High volume user
Alliance Alliance Alliance Alliance Alliance

Lite WebStation WebStation WebStation Access
Alliance Alliance
Starter Set Gateway
VPN VPN VPN

box box VPN VPN
box box box
SWIFTNet
Internet
VPN VPN
box box
Alliance Gateway
Service Central Central Alliance Alliance

Administrator application application Access WebStation
Primary site Disaster site
Figure 4.19: Configuration overview – example
Figure 4.19: Configuration overview - example

42
Examples of domestic and regional models of HVP MIs

As a result of increasingly globalised financial markets, the demand for cross-border and
multi-currency settlement services is likely to grow. Two of the most significant and
tangible changes that we saw in the payment landscape are the launch of the single
European currency which led to the establishment of the first cross-border RTGS
interlinking arrangement, TARGET2, which was subsequently followed by the launch of
the centralised TARGET23 system. This section gives three models of HVP MI
infrastructures – one domestic and two regional – that SWIFT supports.
Domestic model
Figure 4.20 illustrates the most common model of a domestic HVP MI, where the central
institution provides clearing and settlement services for payments in the domestic
currency. The participants of such a domestic HVP MI are typically all located in the
domestic marketplace.
Indirect participants – Indirect participants –

may be domestic may be domestic
and/or xborder Bank C
and/or xborder
Bank D
Bank Z
Bank X
Bank Y
Bank B
Transaction input Bank E
Corporate 2
Corporate 1
Payment control
FileAct for bulk Bank n
Bank A reporting
Internal
Internal
payment system
SWIFT interface
Settlement of
Online balances
monitoring
Ancillary system n
SWIFT interface
Central Payment processing
Direct participants in
institution Bank A Bank B Central web server
the domestic market
Figure 4.20: Domestic model of HVP MI

2 TARGET, the Trans-european Automated Real-time Gross settlement Express Transfer, is the RTGS for the euro.
3 TARGET2, the new generation of the TARGET system, is based on the single technical infrastructure called the Single
Shared Platform (SSP). It provides a uniform wholesale payment infrastructure services for all banks in the EU – irrespective
of where they are located. Figure 4.20: Domestic model of HVP MI
43
Regional models
As mentioned earlier, new HVP MIs are emerging to meet an expanding demand for cross-
border payments. TARGET and TARGET2 are the primary examples which both adopted the
SWIFTNet messaging platform. Similar developments are emerging in other regions.
The regional HVP MIs are typically a group of countries in the region that form a single
shared platform of the HVP MI to clear a single currency. Two different types of regional
models are illustrated in figures 4.21 and 4.22.
a) Centralised
The messaging service is similar to that of the domestic model. However, some
participants have special roles to play, such as central banks of other countries.
The example of this model is TARGET2.
Indirect participants – Indirect participants –

may be domestic may be domestic
and/or xborder and/or xborder
Bank C Bank D
Country C Country D
Bank Z
Bank X
Bank Y
Bank B
Country B
Central Bank E
Transaction input
Corporate 2
Corporate 1
Payment control
FileAct for bulk
Bank A reporting
Internal
payment system Bank n
Country n
SWIFT interface
Country A Settlement of
Online balances
monitoring
Ancillary system a
Country a
SWIFT interface
Payment processing
Direct participants in
Central system the regional market
Figure 4.21: Regional centralised model of HVP MI
Figure 4.20: Domestic model of HVP MI

44
b) Decentralised
Central Bank D Central Bank E
Country D Country E
Domestic
Domestic Bank Z HVP MI 4 Domestic
HVP MI 3 HVP MI 5 Bank X
Bank Y Domestic
HVP MI 6
Central Bank C Central
Bank Y,
Country Y
Corporate 2 Country C
Corporate 1
Interlinking HVP MIs in the region

Central Bank B Central Bank n
Domestic Domestic
HVP MI 2 HVP MI 7
Country B Country n
SWIFT interface
Domestic
HVP MI 1 Payment processing
Bank A Bank B Central Web Server
Central Bank A, Country A
Figure 4.22: Regional de-centralised model of HVP MI
Figure 4.22: Regional de-centralised model of HVP MI
The HVP MIs of each central bank belonging to the regional decentralised HVP MI model
are interlinked to all other central banks on a bilateral basis. Each central bank serves its
own domestic market with its payment clearing and settlement service. The example of
this model is TARGET.
Typical cross-border payment flows between the HVP MIs in the regional decentralised
model is illustrated in figure 4.23.
HVP MI 1 HVP MI 2
Domestic Interlinking Domestic
Bank A Central Bank A Central Bank B Bank B
Payment request Payment confirmation
Figure 4.23: Cross-border payment flow in the regional de-centralised model

45
Professional services
Business Assessment Programme for market infrastructures
Consultancy service to analyse your business flows and your infrastructure
The Business Assessment Programme is a consultancy service that SWIFT offers to its
key customers including HVP MIs. In support of those customers’ key business drivers,
the programme facilitates the rationalisation of their existing infrastructure and
communication channels. The programme also helps them to improve their straight-
through processing, their messaging capabilities, and the quality of service that they
provide to their end customers. Furthermore, the programme provides benchmarking of
messages and operational efficiency.
Entry Package Bespoke

Financial Messaging Strategy Business & technical assessment
8 days, 2 consultants, Time and material basis

3 days on site,1 day off-site
Helps our clients optimise financial flows,
Helps our clients with strategy/vision, improve efficiency and productivity,
high-level cost efficiency assessment and reduce risks, messaging infrastructure
comparative benchmarking redesign and benchmarking.
Content:
Scope, duration and price of the project
Content:
are dependent on the requirements of
Competitive benchmark against peer
the MI
group of MIs in the industry
Typically,
— Entry package
— High level readiness assessment
against best practice — Detailed analysis “as is” vs “to-be”
situation, Identifying wins of
— Recommendations on best practice
improving business processes, from
in the market
risk mitigation to STP
— High-level opportunity report
— Develop cost/benefit analysis
Travel & accommodation not included supporting infrastructure
replacement, upgrade and
integration
— Implementation recommendation
report
— Analyse business domains/flows
— Deliver implementation plan for
SWIFT Solutions
46
SWIFT Support
World class customer service
SWIFT provides 24x7 support services using the follow the sun principle. You can use the
SWIFT Support online services available on www.swift.com > Support or you can contact
the SWIFT Customer Service Centre by telephone.
For high volume and mission critical customers, the SWIFT Support Enhanced service
provides you with a dedicated SWIFT service manager. The SWIFT service manager is
your primary contact for enhanced support and is a member of the technical team.
Additional reports, proactive monitoring and preventive system care are also key
components of the SWIFT Support Enhanced service offering which helps manage
service levels and improves upon these service levels.
SWIFT Training
SWIFT training programme
The SWIFT training programme aims to support SWIFT members and to help them get
the most out of their SWIFT connection. The mission is to help members increase their
knowledge of the SWIFT infrastructure and the different message types in order to
improve automation and service levels and decrease operational costs.
The experienced SWIFT training team offers the latest SWIFT information through a wide
range of classroom courses, onsite training and e-learning products.
For further information about SWIFT Training, please visit the Training section on swift.com.
47
Appendices
Appendix A: Details on transaction processing
Transaction input
The transaction input process is comprised of two steps: submission of a payment
instruction by a paying participant and reception of the payment instruction by the HVP MI.
Payment submission
Different types of payments can be submitted to the HVP MI, such as individual payment
instructions from participating financial institutions, balances of ancillary systems, or cash
legs of securities transactions.
Individual payment instructions can be credit transfers or debit transfers. However, in
practice, almost all HVP MI transactions are credit transfers, where both payment
messages and funds move from the paying participant to the receiving participant.
Ancillary systems settling balances in the HVP MI may use several models to submit the
related payment instructions:
1. All payment instructions with credit transfers and direct debit are submitted
individually or in a file.
2. Payment instructions with all debit positions are simultaneously submitted first. Then,
only after settlement of all the related payment instructions has occurred, the
payment instructions with credit positions are released.
Furthermore, HVP MIs usually offer a range of technical methods for payment
submissions:
— Transaction based: individual payment instructions usually for payments of high value
that require urgent and timely settlement. They are typically submitted in real time;
— File based: bulk payments in a file for a large volume of payments of relatively low value,
such as credit transfers and direct debits. They are typically submitted in batches.
Typically, the HVP MI will process individual payment transactions (one to one credit
transfer of high value) from paying participants and multilateral settlements for retail
payment systems, domestic ACHs and domestic CSDs.
48
Payment reception
The HVP MI receives all transactions through an interface system. The transactions may
be related to the payment business (e.g. RTGS), treasury operations (e.g. market
intervention), or any other central bank business operation. Based on certain criteria, the
interface system therefore routes to the appropriate channel (e.g. RTGS operations unit or
central application system) those payment instructions that need to be processed
through the HVP MI.
Validation
Validation refers to the process that checks that a set of data conforms to a pre-defined
structure and rules. Three types of validation – business, message, and technical – are
further described in the context of an HVP MI:
Business validation
Business validation is normally performed by the central HVP MI application and typically
covers the following areas:
authenticating the identity of the parties involved in the transaction, sometimes using
encryption technologies;
— validating the payment instrument against system standards;
— verifying the paying participant’s ability to pay;
— verifying that the limits are not breached;
— authorising the transfer of funds between the payee’s and the payer’s financial
institutions;
— value date of the payment instruction is within the timeframe defined by the system
(some systems do not allow input of future-value transactions).
Message validation
All transaction input and monitoring messages are checked for correct syntax and
semantics based on the predefined structure and rules agreed within the HVP MI
community.
Technical validation
Technical validation refers to the integrity and non-repudiation of transaction-related
messages (e.g. payment instructions, reports, etc.) that are exchanged over the
communication network used.
49
Clearing process
The clearing process refers to the process of calculating the individual obligations of
system participants for the exchange of funds. In this context, it includes the process of
reconciling and confirming payment instructions. The checking against all the conditions,
reconciling and confirming payment instructions are all performed by the central
application system.
Reconciliation process
Some of the conditions that must be met in order for a payment to settle are:
— Availability of sufficient funds in the settlement account of the paying participant
— The priority of each individual payment e.g. high priority or low priority
— Condition on the settlement of another transfer e.g. a security in a Delivery versus
Payment mechanism such as in the Securities Settlement System or another
currency in Payment versus Payment mechanism such as in the Continued Linked
Settlement system.
There may be other conditions that apply depending on the specific local jurisdictions or
market practices.
Queuing arrangement
If a payment does not satisfy the conditions for immediate settlement, it is typically placed
in a temporary system queue until the payment meets all the conditions for settlement or
gets rejected.
There are different ways in which unsettled payments are released (i.e. tested for
settlement). Such standard rules for queuing arrangements vary among HVP MIs; some
of the methods commonly used are:
— FIFO (First-In, First-Out): queued payments are released on a first-in, first-out basis in
a sequential order
Different levels of priority: this mechanism can be operated in combination with FIFO (i.e.
— FIFO for each priority level) to allow the settlement of time-critical payments
— Reordering of payments: Some systems offer paying participants the possibility to
reorder or revoke queued payments
— FAFO (First-Available, First-Out): the system scans and tests each queued payment
for settlement
In recent years, several systems have introduced more complex algorithms such as
“offsetting” which means simultaneous gross settlement of individual payments on a
bilateral basis, or the settlement of net balances on a bilateral or multilateral basis.
50
Settlement process
Once all the financial risk controls are satisfied and sufficient funds/collateral/credit are
confirmed, the transfer of the settlement asset takes place from the settlement account of
the paying participant to the settlement account of the receiving participant. As a general
rule, payment finality is said to be achieved when the transfer of the settlement asset is
completed.
Figure A.1: Funds transfer between the settlement accounts

Internal payment
system
Settlement Confirmation
request of credit
SWIFT interface
SWIFT interface
HVP MI
Payment processing
D C
51
Appendix B: Delivery versus payment (DVP)
Introduction
With the elimination of paper-based communications and the increase in cross-border
trading, infrastructures need to find ways to increase the speed and efficiency not only in
settlement of high-value payments but also securities transactions. Increased automation,
coupled with the adoption of internationally accepted message standards and access to
a global, secure network are key to their success.
Definition
Delivery versus payment (DVP) is a mechanism of exchange-for-value settlement, a
system which ensures that the final transfer of one asset (securities) occurs if and only if
the final transfer of another asset (funds) occurs. Assets can include monetary assets,
securities, or other financial instruments.
Structure of DVP
The process of clearing and settling of a securities trade includes a number of key steps,
including the matching of the terms of the trade, the calculation of the obligations of the
counterparties as a consequence of matched trades (clearance), the discharge of those
obligations (settlement) through the final transfer of securities (delivery) and the final
transfer of funds (payment).
Settlement via DVP assures both counterparties that no loss of principal will occur during
the settlement process. To achieve DVP, a communication link between the payment
system and securities delivery system is necessary.
Ideally, DVP is the simultaneous, real-time, trade by trade exchange of payment and
securities in same-day funds with immediate and irrevocable finality. This requires a prior
matching of settlement instructions and link to a payment system that follows the real
time gross settlement principle.
Figure B.1 shows an example of DVP where the government securities settlement system
runs on the same platform as the real-time gross settlement system, both of which are
managed by the central institution. In another model, the CSD is also able to offer DVP on
a real-time gross basis, being linked to the RTGS system.
52
Deliverer 1) MT 543 SWIFTNet 2) MT 541 Receiver

(Seller) (Buyer)
3) MT 548 (matched) 4) MT 548 (matched)
9) MT 547
8) MT 900
7c) MT 012 10) MT 545

FINCopy
7b) MT 202 5) MT 202
7a) MT 097 6) MT 096
Central
institution RTGS system GSS system
Securities flow RTGS: Real-Time Gross Settlement

Cash flow GSS: Government Securities Settlement
Figure B.1: Generic message flow for GSS system (DvP)

53
Key steps
— 1 and 2) The ‘against payment’ transfer instructions are sent to the government
securities settlement (GSS) system.
— 3 and 4) The instructions are matched. Once matched the securities will be reserved
in the account of the seller (or the account of the seller’s delivering agent). Settlement
status messages are then sent to the deliverer and the receiver.
— 5) The GSS system sends a payment instruction to the deliverer through the RTGS
system, requesting the debit of the receiver’s fund account (or the account of the
buyer’s receiving agent) and a credit of the seller’s funds account (or the funds
account of the seller’s delivering agent).
— 6) The funds settlement request is sent by the FINCopy service to the RTGS system.
— 7a, b and c) The RTGS system processes the payment instructions. If the funds are
transferred, the authorisation message is sent to the FINCopy service for releasing the
payment instruction to the intended receiver (i.e. in this case the deliverer). The
settlement notification is optionally sent to the sender of the payment instruction (i.e.
in this case the GSS system).
— 8) Confirmation of debit is sent to the receiver.
— 9) Confirmation of delivery is sent to the deliverer.
— 10) Confirmation of receipt is sent to the receiver.
54
Message types that can be used
SWIFT MT Standard Message name Purpose
MT 541 Receive against payment Instruct the receipt of financial

instruments against payment,
physically or by book entry, from a
specified party.
MT 543 Delivery against payment Instruct the delivery of financial

physically or by book entry, to a
specified party.
MT 545 Receive against payment confirmation Confirm the receipt of financial

specified party.
MT 547 Delivery against payment confirmation Confirm the delivery of financial

specified party.
MT 548 Settlement status and processing advice Advise the status of a settlement
instruction previously sent by the
account owner.
MT 900 Confirmation of debit Advises an account owner of a debit

to its account
MT 012 Sender notification An optional feature in the FIN Copy

service. Notifies the sender when the
message has been released (i.e.
settled) by the central institution.
MT 202 General financial institution transfer Order the movement of funds to the
beneficiary institution.
55
Appendix C: Payment market infrastructures clearing and settling

high and low value payments in the same system
Introduction
Some payment settlement systems (PSS) handle high and low value payment in a single
system. These systems can follow three basic messaging exchange services:
1. All messages exchanged using a transaction-by-transaction messaging service
2. All messages exchanged using a file based messaging service
3. A transaction-by-transaction messaging service for high-value, urgent payments and
file-based messaging service for low, non-urgent payments.
Drivers to converge payments into a single platform can be strategic or regulatory
requirements, business efficiency, risk management and cost reduction. This section
describes how SWIFT supports such a converged system when market infrastructures
and their community take the business decision to combine high and low value payment
settlement.
The SWIFTNet transaction processing services described in section 4.2.2.1 are
applicable to both high and low value payments using either FIN Y-copy (option 1) or the
V-shaped topology using FIN or InterAct (option 2).
Transaction-by-transaction messaging service for all payments

Some payment settlement systems may use the file-based messaging mechanism to
exchange systematically all high and low value payments from the participants to the
market infrastructure. In this situation, SWIFTNet transaction processing services
described in section 4.2.2.1 using FileAct in a V-topology (option 3) would apply.
File-based messaging service for all payments

Converged payment settlement systems wishing to gain the benefits of transaction-by-
transaction messaging for high-value, urgent payments and the benefits of file-based
messaging for low-value, non-urgent payments are supported by a mix of the above
messaging services.
56
Mix of transaction-by-transaction and file exchange

In a V-topology, the FIN or InterAct service described in section 4.2.2.1 (option 2) is used
to exchange high-value, urgent payments with the payment system. The FileAct service in
a V-topology described in section 4.2.2.1 (option 3) allows the participant to exchange
with the MI low-value, non-urgent payments and any ancillary multilateral payment file
leveraging economy of scale. The payment flow from a paying bank to a receiving bank is
illustrated in figure C.1.
Participant A SWIFTNet Participant B

Internal payment
system
in Pay
SWIFT interface st m
r
by uct ent n
Fi ion io
le s at e
in Pa it fic sag
s y No es
tra truc me m
ns tio nt
ac n
tio by
n
SWIFT interface
Central
institution
Payment processing
Bank A Bank B Central Web Server
FIN/InterAct V-topology for transaction-per-transaction payment flow

FileAct V-topology for Bulk or Batch payments flow
Figure C.1: Payment flow from a paying bank to a receiving bank
In a Y-topology, FIN Y-copy described in section 4.2.2.1 (option 1) is the messaging

service for exchanging transaction-by-transaction payments. To apply the same
mechanism to low-value bulk payments, FileAct Header Copy provides the Y-topology
file-based message exchange capability described in section 4.2.2.1 (option 4).
57
FileAct Header Copy stores the file in the SWIFT systems until the third party receiving the
header approves or rejects the file transaction based on the information in the header.
The service can be set up to copy the technical header information (for example sender
or receiver) as well as the business information provided by the sender (typically file
summary data such as number of items or total amount). This allows the central point to
process the transaction without needing the full file. The payment flow from a paying bank
to a receiving bank is illustrated in figure C.2.
SWIFTNet
Participant A Participant B
Internal payment
system Payment Payment
message message settled
SWIFT interface
Payment file Payment file
settled
Authorization/
Authorization/
Settlement
Settlement
rejection
rejection
request
request
SWIFT interface
Central
institution
Payment processing
FIN Y-topology for transaction-per-transaction payment flow

FileAct Header copy Y-topology for Bulk or Batch payments flow
Figure C.2: Payment flow from a paying bank to a receiving bank
Message types
The message formats described in section 4.2.2.1 for the four options are applicable with
a mixed usage of FIN, InterAct and FileAct.
Business flows coverage

In addition to the transaction processing flow support described above, the SWIFTNet
support for cash management (section 4.2.3), participant management (4.2.4), report
management (4.2.5) and generic communication (4.2.6) are applicable for a converged
high and low-value payment system.
58
Appendix D: Summary of SWIFT interface products
The Alliance interface product portfolio enables access to the entire range of SWIFTNet
and FIN services.
Desktop interfaces
The desktop interfaces enable manual creation of messages by an operator. Low volume
organisations use them to create all of their messages, while larger volume ones tend to
use them for message editing or repair.
— Alliance Webstation: A manual, browser-based, generic interface to SWIFTNet;
— Alliance Messenger: A browser-based Graphical User Interface for manual message
processing;
— Alliance Lite: A new connectivity product targeted at new low volume users.
Messaging interfaces
The messaging interfaces do not actually generate messages, but they include the
intelligence needed to process and route messages containing structured standards
(such as MT for FIN and MX Standards for services like Cash Reporting). They can be
used in combination with a desktop interface, or plugged directly into the back-office
applications for full automation.
— Alliance Access and Entry: Provide customers with core message-management
functions.
Communication interfaces
The communication interfaces provide the link between the interfaces generating the
messages and the connection to SWIFTNet itself. They are used to consolidate the traffic
flow from multiple messaging or desktop interfaces. They ease administration of the
infrastructure, improve automation, and increase resilience and security;
— SWIFTNet Link: a mandatory SWIFT software component that is required to connect
to SWIFTNet; it offers a set of communication APIs to service applications and
ensures end-to-end interoperability. SWIFTNet Link embeds the SWIFTNet PKI
software. SWIFTNet Link is integrated into SWIFTNet interfaces provided by SWIFT or
by third-party vendors;
— Hardware Security Module: a hardware device that is tamper-resistant and that
ensures the secure storage and the processing of SWIFTNet PKI security profiles
which are accessed and used through the SWIFTNet Link;
— Alliance Gateway: a messaging platform concentrating all the business flows;
— VPN Box: a mandatory SWIFT network component for the connection to the multi-
vendor Secure IP Network.
59
Appendix E: Related documentation
General For all documentation: SWIFT Documentation
Corporate Glossary: SWIFT glossary
Corporate rules (By-Laws): Corporate Rules
General Terms and Conditions: General Terms and Conditions
Legal documents Setup of Market Infrastructure: Setup of Market Infrastructure

related to HVP MI
Appendix F: Abbreviations
ACH Automated clearing house
BIS Bank for International Settlements
CSD Central securities depository
CLS Continuous Linked Settlement
CPSS Committee of Payment and Settlement Systems
DVP Delivery versus payments
DNS Deferred net settlement
HVP MI High-value payment market infrastructure
HVPS High-value payment system
ICSD International central securities depository
LVP MI Low-value payment market infrastructure
LVPS Low-value payment system
PVP Payment versus payment
RPS Retail payment system
RTGS Real-time gross settlement
TARGET Trans-european Automated Real-time Gross settlement Express Transfer
TARGET2 The next generation of the TARGET system

60
Appendix G: Glossary
Glossary of terms used in payment and settlement systems

Terms used herein will generally have the same meanings as described in the CPSS
glossary of terms used in payment and settlement systems. The terms below have the
following meaning in the context of SWIFT’s high-value payment market infrastructure
services.
Term Meaning
Automated clearing house An electronic clearing system in which payment orders are
exchanged among financial institutions, primarily via
magnetic media or telecommunications networks, and
handled by a data processing centre. See also clearing.
Central institution The central bank or designated authority (e.g. bankers’

association) with responsibility to manage and oversee a
high-value payment system.
Clearing balance The accounting balance maintained by an RTGS for

recording the funds available to a participant in the high-
value payment system.
Deferred net settlement (DNS) system A system that effects the settlement of obligations or
transfers between or among counterparties on a net basis
at some later time.
High-value payment system See Large-value funds transfer system
Individual payment transaction A payment instruction from a paying participant to the

HVP MI for credit transfer to a receiving participant.
Individual payment transactions can have a forward value
date or a current value date. Participants can designate
selected transactions as high priority rather than the
default FIFO priority.
Intraday credit A loan of funds from the central institution to a participant

to fund RTGS settlements. Intraday credit can be
automatically drawn and repaid by the RTGS system
during processing. The central institution will set a limit on
intraday credit for each participant.
Intraday credit limit The value limit configured by the central institution as the
maximum amount of intraday credit that a participant can
borrow through automated RTGS processing.
61
Large-value funds transfer system A funds transfer system through which large-value and
high priority funds transfers are made between
participants in the system for their own account or on
behalf of their customers. Although, as a rule, no minimum
value is set for the payments they carry, the average size
of payments passed through such systems is usually
relatively large. Two major designs of systems exists:
deferred net settlement (DNS) systems, which settled only
at the end of the day, and the real-time gross settlement
(RTGS) systems, which settle on a continuous basis.
Large-value payment system See Large-value funds transfer system
Large-value payments Payments, generally of very large amounts, which are

mainly exchanged between banks or between participants
in the financial markets and usually require urgent and
timely settlement.
Low-value payment system See retail funds transfer system
This payment system which accepts bulk files of payment

instructions for processing, netting and clearing, either
directly from bank participants or from ancillary payments
and clearing infrastructure such as ACHs. Settlement of
net claims and obligations among low-value payment
system participants is via interface to a linked RTGS in the
same currency.
Multilateral settlement transaction An instruction for simultaneous debit and credit of multiple
participant accounts to settle net settlement obligations of
ancillary payment systems such as ACHs.
Participant A party which participates in a transfer system. This

generic term refers to an institution which is identified by a
transfer system (e.g. by a bank identification number) and
is allowed to send payment instructions directly to the
system or which is directly bound by the rules governing
the transfer system. There are direct participants and
indirect participants.
Paying participant The participant originating an individual payment

transaction.
Payment The payer’s transfer of a monetary claim on a party

acceptable to the payee. Typically, claims take the form of
banknotes or deposit balances held at a financial
institution or at a central bank.
Payment instruction An order or message requesting the transfer of funds (in

the form of a monetary claim on a party) to the order of
the payee. The order may relate either to a credit transfer
or to a debit transfer. Also called payment order.
Payment system A payment system consists of a set of instruments,

banking procedures and, typically, interbank funds transfer
systems that ensure the circulation of money.
62
Real-time gross settlement system A payment system which processes individual payment
instructions as received in real-time for instantaneous
transfer of funds between system participants’ clearing
accounts with a central institution. In other words, it is a
settlement system in which processing and settlement
take place on an order-by-order basis (without netting) in
real time (continuously).
Real-time processing The processing of instructions at the time they are

received rather than at some later time.
Receiving participant The participant whose clearing balance will be credited

upon successful clearing of a payment transaction.
Repos Repurchase agreements
Retail funds transfer system A funds transfer system which handles a large volume of
payments of relatively low value in such forms as cheques,
credit transfers, direct debits, ATMs and EFTPOS
transactions.
Retail payment system See Retail funds transfer system
Retail payments This term describes all payments which are not included in
the definition of large-value payments. Retail payments are
mainly consumer payments of relatively low value and
urgency.
Service administrator The central institution or designated authority responsible

for business operations and governance of a national
high-value payment system.
Settlement The completion of a transaction, wherein the seller

transfers securities or financial instruments to the buyer
and the buyer transfers money to the seller. A settlement
may be final or provisional.
Systemically important payment system A payment system is systemically important where, if the
system were insufficiently protected against risk,
disruption within it could trigger or transmit further
disruptions amongst participants or systemic disruptions
in the financial area more widely.
Wholesale funds transfer system See Large-value funds transfer system

Wish to know more about SWIFT? SWIFT
Browse our website www.swift.com Avenue Adèle, 1
55745 - FEB 2009

B-1310 La Hulpe
Belgium
+32 2 655 31 11

Swift Mi Brochure Swiftforhvpsystems

Uploaded by

Copyright:

Available Formats

Swift Mi Brochure Swiftforhvpsystems

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Swift Mi Brochure Swiftforhvpsystems

Uploaded by

Copyright:

Available Formats

SWIFT for high-value payment market

SWIFT’s offering for high-value payment market infrastructures

High-value payment market infrastructure – customer perspective

SWIFT’s offering for high-value payment market infrastructures

SWIFT’s offering for high-value payment market infrastructures

SWIFT – a community founded by and for the financial services industry

More than 60 payments clearing systems rely on SWIFT services

SWIFT’s offering for high-value payment market infrastructures

SWIFT’s compelling offer

SWIFT’s offering for high-value payment market infrastructures

— FIN: SWIFT’s core store-and-forward messaging service that enables the

Unique resilience, reliability and availability

SWIFT’s offering for high-value payment market infrastructures

Pricing to maximise usage and benefits to the community

A single window to the financial industry

Benefits for market infrastructures

Industry standard solution

SWIFT’s offering for high-value payment market infrastructures

Focus on core service

Benefits for participants

SWIFT’s offering for high-value payment market infrastructures

Independence from service providers

Trusted third party service

SWIFT’s offering for high-value payment market infrastructures

High-value payment market infrastructure –

Payment market infrastructure services

Transaction input Validation Clearing Settlement Notification

Types of payment Business Clearing process Settlement process Output delivery

Figure 3.1: Service components of HVP MIs

SWIFT’s offering for high-value payment market infrastructures

Stakeholders of HVP MIs

Direct participant A Direct participant B

Payment system participant (I) CSDs LVP MI

Figure 3.2: Stakeholders of HVP MIs

SWIFT’s offering for high-value payment market infrastructures

HVP MI service administrator

SWIFT’s offering for high-value payment market infrastructures

On the bank side

Clearing and Customer

Payment transaction Transaction

Figure 3.3: Business and operational components of HVP MIs

SWIFT’s offering for high-value payment market infrastructures

Payment transaction processing

Transaction input Validation Clearing Settlement Notification

Figure 3.4: Payment process

SWIFT’s offering for high-value payment market infrastructures

SWIFT’s offering for high-value payment market infrastructures

Participant structure and access criteria

Participant profile management

Reporting and reference data management

Exchange of bulk data including reports and reference data

SWIFT’s offering for high-value payment market infrastructures

Person-to-person exchange of sensitive data

SWIFT’s offering for high-value payment market infrastructures

SWIFT’s offering for high-value payment

SWIFT’s offering for high-value payment market infrastructures

Interbank Payments (CT & DD)

Exceptions & Investigations

Exceptions & Investigations