swift finaldoc

7/31/2019 Swift FinalDoc

1/133

S I C S R

M B A - I T

B F M - I I

9 / 2 9 / 2 0 1 1

Amruta Kadam10030141074

Sreyasi Roy 10030141084

Pranav Kataria 10030141114

Abhinav Misra 10030141124

S.W.I.F.T.


2/133

2 | P a g e

Index

INDEX .............................................................................................................................................................. 2

INTRODUCTION ............................................................................................................................................... 5

MISSION: .............................................................................................................................................................. 5

VISION .................................................................................................................................................................. 5

CONCRETE ACTIVITIES: ...................................................... ................................................................. ....................... 6

SWIFT USERS.................................................................................................................................................... 7

SWIFTUSERS ........................................................................................................................................................ 7

MARKET DISTRIBUTION ................................................................................................................................... 9

MARKET DISTRIBUTION (YEAR 2011) ......................................................................................................................... 9

REGIONAL DISTRIBUTION (YEAR 2011) ................................................................................................................... .... 9

SWIFT SERVICES ............................................................................................................................................. 10

ARCHITECTURE .............................................................................................................................................. 11

DISTRIBUTED ARCHITECTURE ................................................................................................................................... 11

SWIFTNET NETWORK ..................................................................................................................................... 13

FIN .................................................................................................................................................................... 14

INTERACT ............................................................................................................................................................ 16

FILEACT............................................................................................................................................................... 18

BROWSE.............................................................................................................................................................. 19

SWIFT ADDRESSES ......................................................................................................................................... 21

BANK IDENTIFIER CODES (BICS) ............................................................... ................................................................ 21

IBAN(INTERNATIONAL BANK ACCOUNT NUMBER) ..................................................................................................... 22

STANDARDS ................................................................................................................................................... 24

SWIFT MESSAGES .......................................................................................................................................... 26

STRUCTURE OF A MESSAGE ..................................................................................................................................... 26

LENGTH OF A MESSAGE .......................................................................................................................................... 27

PRESENTATION OF A MESSAGE................................................................................................................................. 27

SWIFTC

HARACTERS

ET......................................................................................................................................... 36

CASH MANAGEMENT ..................................................................................................................................... 76

SWIFTNET BULK PAYMENTS .................................................................................................................................. 77

Benefits ........................................................................................................................................................ 77

Features & Components ............................................................................................................................... 77

SWIFTNET CASH REPORTING ................................................................................................................................. 80

Benefits ........................................................................................................................................................ 80

Key characteristics ....................................................................................................................................... 80

Industry trends ............................................................................................................................................. 81

Features & Components: .............................................................................................................................. 82

Market infrastructure cash Management ................................................................................................... 84Cash reporting for financial Institutions....................................................................................................... 86


3/133

3 | P a g e

Application models ....................................................................................................................................... 88

Exceptions and Investigations ...................................................................................................................... 88

Benefits: ....................................................................................................................................................... 89

The SWIFT E&I service: ................................................................................................................................. 89

Example of E&I Workflow: ........................................................................................................................... 90

TREASURY & DERIVATIVES ............................................................................................................................. 91

SWIFTNET ACCORD.............................................................................................................................................. 92

Reviewing Treasury Operations ................................................................................................................... 92

Assisting with the selection of a Treasury Workstation ............................................................................... 92

FX OPTIONS ON ACCORD FOR TREASURY ................................................................................................................. 93

Benefits: ....................................................................................................................................................... 93

How does Accord for Treasury work? .......................................................................................................... 96

SWIFTAFFIRMATIONS ........................................................................................................................................ 100

Benefits ...................................................................................................................................................... 100

How SWIFTNet Affirmations works? .......................................................................................................... 101

Instruments supported by Affirmations ..................................................................................................... 102

SWIFTS CLSTHIRD PARTY SERVICE ..................................................................................................................... 103

Benefits ...................................................................................................................................................... 103

How SWIFTs CLSThird Party Service works?............................................................................................ 104

Case Study: TMS Infrastructure .................................................................................................................. 105

The business challenge .................................................................................................................................. 105

The technology solution ................................................................................................................................ 105

The activities .................................................................................................................................................. 105

Advice and experience ................................................................................................................................... 106

SECURITIES .................................................................................................................................................. 107

SWIFT IN THE SECURITIES MARKET ......................................................................................................................... 107

SWIFTNET FIX .................................................................................................................................................. 108

SWIFTNET FUNDS .............................................................................................................................................. 109

Why SWIFTNet Funds? ............................................................................................................................... 109

Benefits of using SWIFT .............................................................................................................................. 110

ACCORD FOR SECURITIES ...................................................................................................................................... 111

Why do I need AccordforSecurities? ........................................................................................................ 111

What benefits does Accord for Securities bring? ....................................................................................... 111

Who can use Accord for Securities? ........................................................................................................... 112

1. Matching of trades between prime brokers and executing brokers ...................................................... 113

2. Matching of trades between custodians and executing brokers ........................................................... 1153. Matching of trades between two executing brokers ............................................................................. 117

Key features of Accord for Securities ......................................................................................................... 118

SWIFTNET TRADE SERVICES UTILITY ............................................................................................................. 120

THE EVOLUTION OF TRADE AND ADOPTION OF OPEN ACCOUNT TRADING. ..................................................................... 120

SUPPLY CHAIN CHALLENGES .................................................................................................................................. 121

Buyers and sellers are driven by different needs ........................................................................................ 122

Driving costs down ..................................................................................................................................... 122

Coping with growth.................................................................................................................................... 123

Managing working capital ......................................................................................................................... 123

Managing information flows ..................................................................................................................... 123MEETING THE SUPPLY CHAIN CHALLENGE ................................................................................................................ 124


4/133

4 | P a g e

WHAT IS SWIFTNET TRADE SERVICES UTILITY? ................................................................ ........................................ 124

TSUENABLED SERVICES ....................................................................................................................................... 127

SIMPLE TSUOPEN ACCOUNT FLOW ....................................................................................................................... 131

TSUBENEFITS TO BANK AND CORPORATE................................................................................................................ 133


5/133

5 | P a g e

Introduction

The Society for Worldwide Interbank Financial Telecommunication ("SWIFT") operates a

worldwide financial messaging network which exchanges messages between banks andother financial institutions. SWIFT also markets software and services to financial

institutions, much of it for use on the SWIFTNet Network, and ISO 9362 Bank Identifier

Codes (BICs) are popularly known as "SWIFT codes".

Mission:To enable interoperability between our members, their market infrastructures and their

end-user communities

Vision Embed Corporate Social Responsibility(CSR) in the SWIFT corporate mindset and

make it an intrinsic part of the company strategy

Leverage SWIFT's role as the CSR/sustainability facilitator within the financial

industry

The majority of international interbank messages use the SWIFT network. As of September

2010, SWIFT linked more than 9,700 financial institutions in 209 countries and territories,

who were exchanging an average of over 15 million messages per day. SWIFT transports

financial messages in a highly secure way, but does not hold accounts for its members and

does not perform any form ofclearing or settlement.

SWIFT does not facilitate funds transfer, rather, it sends payment orders, which must be

settled via correspondent accounts that the institutions have with each other. Each financial

institution, to exchange banking transactions, must have a banking relationship by either

being a bank or affiliating itself with one or more particular business features.

SWIFT has its headquarters in Belgium and has offices in the world's major financial centres

and developing markets. SWIFT headquarters are located in La Hulpe, Belgium,

near Brussels. SWIFT provides additional products and associated services through Arkelis

N.V., a wholly owned subsidiary of SWIFT, the assets of which were acquired from SunGard

in 2010.

SWIFT does not hold funds nor does it manage accounts on behalf of customers, nor does it

store financial informationon an on-going basis. This activity involves the secure exchange

of proprietary data while ensuring its confidentiality and integrity.

The opening up of SWIFT to the corporate community has not been without controversy

many of SWIFTs financial institution members felt corporate access would dis-intermediate

banks if corporates could communicate with each other across the network they could

perhaps cut financial institutions out of the loop. That is why corporate access has been

developed in a measured way by SWIFT and its member banks. Even today, a significant

number of banks still take a defensive approach towards offering corporate services through

SWIFT. The first step to bring corporates on to SWIFT was the introduction of treasury
http://en.wikipedia.org/wiki/Computer_networkhttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Clearinghttp://en.wikipedia.org/wiki/Settlement_(finance)http://www.swift.com/about_swift/company_information/swift_offices.page?http://en.wikipedia.org/wiki/La_Hulpehttp://en.wikipedia.org/wiki/Brusselshttp://www.swift.com/about_swift/company_information/arkelis_index.page?http://www.swift.com/about_swift/company_information/arkelis_index.page?http://www.swift.com/about_swift/company_information/arkelis_index.page?http://www.swift.com/about_swift/company_information/arkelis_index.page?http://en.wikipedia.org/wiki/Brusselshttp://en.wikipedia.org/wiki/La_Hulpehttp://www.swift.com/about_swift/company_information/swift_offices.page?http://en.wikipedia.org/wiki/Settlement_(finance)http://en.wikipedia.org/wiki/Clearinghttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Computer_network


6/133

6 | P a g e

confirmation messages in 1997, which allowed for limited activity from corporates, without

enabling payments to be initiated through SWIFT or statements to be received.

Payments (e.g. cross-border, domestic, corporate)

Securities (e.g. equity, fixed income, funds)

Treasury (e.g. foreign exchange, swaps, options)

Trade Services (e.g. letters of credit)

Concrete activities: Establish secure and reliable network application

Standardize information flows (messages)


7/133

7 | P a g e

SWIFT Users

SWIFT Users

Although originally the network was designed to support the requirements of Treasury and

Correspondent banking operations, it has over the years allowed other institutions access to

the services, albeit in some cases only to a limited degree. Currently the following categories

of organization can access the service:

Banks

Trading Institutions

Money Brokers

Securities Broker Dealers

Investment Management Institutions

Clearing Systems and Central Depositories

Recognized Exchanges

Trust and Fiduciary Service Companies

Subsidiary Providers of Custody and Nominees

Treasury Counterparties

The Society is owned by its Members, and in order to become the member of the

organization one must hold a Banking License. In return Members own shares in the society

and have voting rights.

SWIFT user categories

The SWIFT user categories are defined in three main groups.

Supervised Financial Institution

This group also includes shareholders (Members).

Non-Supervised Entity active in the financial industry

Closed User Groups and Corporate entities.

This group is composed of the following SWIFT user categories: Corporate,

Financial Market Regulator, Payment System Participant, Securities Market

Data Provider, Securities Market Infrastructure System Participant, Service

Participant within Member Administered Closed User Group and Treasury

Counterparty.

The eligibility criteria are described in the Corporate Rules.


8/133

8 | P a g e

Shareholding Eligibility

The following types of organisations are eligible for shareholding:

Shareholder (Member)

An eligible organisation holding a share in S.W.I.F.T. SCRL, including banks,

eligible securities broker-dealers and regulated investment management

institutions. Details about SWIFT shareholding can be found in the SWIFT By-

laws.

Non-Shareholding Member

A Non-Shareholding Member is an organisation which complies with the

eligibility criteria of a Shareholder (Member), and which has either chosen

not to or is prevented from becoming a Shareholder.

Sub-Member

A Sub-member is an organisation more than 50 percent directly or 100

percent indirectly owned by a shareholder and which meets the criteria set

forth for shareholder. A Sub-member must be under full management control

of the shareholder.


9/133

9 | P a g e

Market Distribution

Market Distribution (Year 2011)

SWIFTNet FIN total traffic distribution and growth by market

Data Traffic Distribution

Payment ** 162,998,805 48.12%

Securities 150,734,837 44.50%

Treasury 20,313,239 6.00%

Trade Finance 3,540,838 1.05%

System 1,161,110 0.34%

Total 338,748,829 100.00%

Regional Distribution (Year 2011)

Region Traffic Distribution

Europe, Middle east,

Africa

226,435,208 66.84%

Americas 69,782,890 20.60%

Asia-Pacific 42,530,731 12.56%

Total 338,748,829 100.00%


10/133


11/133

11 | P a g e

Architecture

Distributed Architecture

SWIFTs distributed architecture partitions messaging into zones, with pairs of operating

centre cooperating to process and store traffic for each zone. To address the data

protection concerns for zones like the European Zone, this architecture enables storing of

the intra-zone data in the same zone.

Figure: Distributed architecture

The distributed architecture is being implemented in two phases: Phase 1 calls for the

minimum implementation possible that addresses European data protection concerns and

delivers the highest priority resilience improvements. To implement phase 1 in the shortest

possible period, SWIFT accelerated delivery by leasing data centre space from a hosting

company. The new European operating centre OPC CH, will serve as the companion for the

existing Netherlands operating centre to process and store traffic for the European Zone.

The existing Netherlands operating centre serves as the companion to the US operating

centre to process and store traffic for the Trans-Atlantic Zone. In other words, theNetherlands operating centre is the global operating centre. Phase 2 plans to further

enhance the security and reliability of SWIFTs messaging services through specific system

and operating centre enhancements.

2. Messaging zones

Distributed architecture allocates traffic to zones. For technical and data protection reasons,

SWIFT allocates traffic to zones on a country-by-country basis. In other words, each country

is hosted in either the European Zone or the Trans-Atlantic Zone. Upgraded customer

interfaces connect to zones at the BIC8 level, with the country code in the BIC8 being used

to determine the zone to which to connect.

OPC = Operating

Center


12/133

12 | P a g e

FIN messages exchanged between compliant BIC8s connected to the same zone are

processed and stored only in that zone; FIN messages exchanged between compliant BIC8s

connected to different zones are processed and stored in both zones. SWIFTNet store-and-

forward storage and processing, for both messages and files, continues to be performed in

the EU zone.

Inter-zone message processing and storage

3. Country to zone allocation

Distributed architecture requires the allocation of countries to zones. For reasons of data

protection, the countries in the European Economic Area (EEA), Switzerland and other

territories and dependencies considered a part of the European Union or associated with

European countries have been assigned to the European Zone.

To balance traffic and connections across zones, the default allocation of remaining

countries is to the Trans-Atlantic Zone, except in cases where a country has requested to be

included in the European messaging zone.

This preference, expressed by the National Member Group Chairperson, reflects the

majority opinion within the country.

4. Availability reporting

SWIFT reports on availability for SWIFTNet and FIN core messaging systems. These statistics,

currently provided as weighted percentages, have historically reported on global availability.

Starting in February 2010 SWIFT publishes availability information per zone.


13/133

13 | P a g e

SWIFTNet Network

SWIFT moved to its current IP Network infrastructure, known as SWIFTNet, from 2001 to

2005, providing a total replacement of the previous X.25 infrastructure. The processinvolved the development of new protocols that facilitate efficient messaging, using existing

and new message standards. The adopted technology chosen to develop the protocols was

XML, where it now provides a wrapper around all messages legacy or contemporary. The

communication protocols can be broken down into:

SWIFTNet provides a basis for assuring business continuity and disaster recovery for the

infrastructure of mission-critical financial applications that cross institutional boundaries.

SWIFTNet is designed to satisfy institutional community requirements for interoperability of

mission-critical financial software solutions.

The communication protocols can be broken down into:

FIN

InterAct

FileAct

Browse


14/133

14 | P a g e

FIN

FIN is SWIFTs core messaging service. It enables financial institutions to exchange individual

structured financial messages securely and reliably. FIN is used by over 8,000 financial

institutions and their corporate customers worldwide to exchange 15 million messages per

day across a wide range of business areas within the banking and securities industries.

FIN works in store-and-forward mode, which makes it easy to exchange messages with a

large number of correspondents, many of whom may not be online at the time of

transmission. Store-and-forward removes the uncertainty and inconvenience of worrying

about whether or not your correspondents are online at the time you send the message.

Your message is delivered as soon as the recipient is ready to receive it. FIN provides an

ideal way to send individual instructions, confirmations and reports to large numbers of

correspondents, regardless of their geographical locations or time zones.

Payment Process Flow (Step-wise)

1. Customer Sends Payment Instruction to his Bank Branch

2. Branch forwards instruction to Bank SWIFT service branch

3. Customer branch sends a (Direct) Advice MT 103 - to the Beneficiary Bank

4. Service branch instructs the payment (bank-to-bank) to his Currency Correspondent

(Senders Correspondent)

5. Correspondent transfers funds to the Beneficiary Banks Currency Correspondent(typically through the local clearing in the instruction currency)

6. Beneficiary Banks Correspondent pays funds to the Beneficiary Bank

country/regional SWIFT service branch

7. SWIFT service branch credits funds to Beneficiary bank branchs books and sends a

credit advice

8. Beneficiary Bank branch credits the Beneficiary A/c and sends an advice to the

Beneficiary

9. Currency Correspondent sends an EOD Account Statement to the Beneficiary Bank

Service Branch


15/133

15 | P a g e

Standard FIN features

FIN includes the following key standard features:

SWIFTNet PKI security: FIN offers authentication and integrity control based on the

SWIFTNet PKI infrastructure. Closed user group control: Each FIN message is controlled for compliance with the

predefined message exchange and closed user group rules that determine which

users can send what type of messages to which other users. Non-compliant

messages are not delivered.

Message validation: FIN supports central message validation of a wide range of

SWIFT MT standards, which are used across a broad range of business areas within

the financial industry.

Non-repudiation: In case of dispute, SWIFT is able to confirm that a message

exchange did take place as claimed.

Relationship Management: Users can control the FIN traffic they receive from othersusing SWIFTs Relationship Management Application (RMA).

Optional FIN features

These can significantly improve your operational control over your business:

User-selectable priority: Messages can be flagged as urgent to allow for

appropriate processing by your correspondents.

Delivery notification: This provides confirmation that your correspondent receivedyour message.

Non-delivery warning: This informs you that a message remains undelivered after a

certain period of time.

Online retrievals: Users can retrieve SWIFTNet FIN messages they have exchanged

in the previous 124 days.

User broadcasts: Users can send broadcasts to all other FIN users, or to a group of

users.

FIN Copy: Selected FIN messages can be fully or partially copied to a central point (T-

Copy). In addition, their delivery to the intended destination can be made

conditional on approval by the central point (Y-copy). This feature is frequently used

in the context of highvalue payments clearing systems.

FINInform:Some or all FIN messages sent or received by an institutions subsidiary

or branch can also be fully or partially enabled to centrally process, or allow

monitoring of activities, outsourcing or regulatory reporting.


16/133

16 | P a g e

InterAct

InterAct offers different working modes to meet your specific needs:

Store-and-forward messaging:InterActs store-and-forward capability is designed

for messages destined for a large number of correspondents, many of whom may

not be online at the time of transmission. It removes the uncertainty and

inconvenience of worrying about whether or not your correspondents are online at

the time you send the message. The message is delivered as soon as the recipient isready to receive it. As a result, SWIFTNet InterAct provides an ideal way to send

individual instructions, confirmations and reports to large numbers of

correspondents, even in different time zones.

Real-time messaging: Real-time messaging offers an alternative to store-and

forward to correspondents who are online at the time of transmission, such as

market infrastructures or large correspondents expecting to receive an instruction or

confirmation and that do not need store-and-forward added-value features.

Real-time query and response: This is an interactive service typically used in the

context of workstation based online enquiry or reporting systems. It is often used in

conjunction with Browse.

Standard InterAct features

InterAct includes the following key standard features:

SWIFTNet PKI security: InterAct is secured with SWIFTNet PKI and offers message

authentication, encryption and integrity control.

Closed user group control: Each InterAct message is controlled for compliance with

predefined closed user group rules that determine which users can send messages

to which other users. Non-compliant messages are not delivered.

Message validation: InterAct supports central message validation of XML-basedSWIFT standards.


17/133

17 | P a g e

Advanced delivery control (store-and-forward mode): Interact offers a number of

messaging features to control traffic delivery.

Optional InterAct features

InterAct offers the following key optional features:

User-selectable priority:Messages can be flagged as urgent to allow for

appropriate processing by your correspondents.

Delivery notification (store-andforward mode): This provides confirmation that your

correspondent received your message.

Non-repudiation of emission and reception: In case of dispute, this allows SWIFT to

confirm that the message exchange did take place as claimed.


18/133

18 | P a g e

FileAct

FileAct enables financial institutions to transfer files in a secure and reliable manner. FileAct

provides a cost-effective way to transfer bulk files in different formats to your

correspondents, while leveraging the unparalleled security and reliability inherent in the

SWIFTNet platform.

Whether it is for bulk payments processing, transmission of cheque images, securities value-

added information and reporting, or other business areas such as central-bank reporting or

corporate-to-bank instructions and reporting, most financial institutions require the ability

to exchange files in a secure, reliable and cost-effective manner. FileAct allows you to doprecisely that. The benefits are significant and extend far beyond the realms of traditional

file transfer solutions.

FileAct offers different working modes to meet your specific needs:

Store-and-forward file transfer:FileActs store-and-forward capability removes the

uncertainty and inconvenience of worrying about whether or not your

correspondents are online at the time you transmit the file. The file is delivered as

soon as the recipient is ready to receive it. As a result, it provides an ideal way to

send files to large numbers of correspondents, some of which may be in different

time zones. Real-time file transfer: Real-time file transfer allows an institution to send files to

correspondents who are online at the time of transmission. It is an efficient and cost-

effective way to exchange files with market infrastructures or large institutions.

Real-time file download: This is an interactive service typically used to download

files from the system of a correspondent. It is often used to download files in the

context of workstation-based systems.

FileAct Header Copy: For selected files, SWIFT can copy the file header to a central

point (T-Copy). In addition, the file delivery to the intended destination can be made

conditional to an approval by the central point (Y-copy). This feature is typically used

in the context of payments clearing systems.


19/133

19 | P a g e

FileAct features that Files supported

Any character set

Any content structure

File size up to 250 Mbytes

File transfer security Based on SWIFTNet PKI (managed certificates)

Closed user group control

Encryption

Authentication control

Integrity control

Non-repudiation of emission and reception (optional)

Transfer reliability

Automatic handling of intermittent communication failures Monitoring of transfer progress and status

Delivery notification provides explicit confirmation of delivery by receiver (optional)

Throughput management and traffic prioritisation

Enhanced header

Dedicated optional header block to specify key business summary information (for

example, number of payments or total amount)

Allows file handling (such as routing) without having to open the file

Browse


20/133

20 | P a g e

Browse enables users to browse on financial online portals made available by financial

institutions and market infrastructures on SWIFTNet. It combines the user friendliness of

web technology with the security features offered by SWIFTNet.

Financial institutions and market infrastructures that make their web portals available on

SWIFTNet benefit from a more convenient and attractive delivery channel to their clients,while reducing costs and improving the security and reliability of their services.

Browse features

Browse includes the following key features:

Browser-based: Access to a Browse service is via a standard Internet browser (such

as Microsoft Internet Explorer) and the Alliance WebStation software. There is no

need to install any software or hardware from the provider of the online portal.

Browsing security: Browse exchanges are secured by the combined use of the

Secure Socket Layer protocol and SWIFTs secure IP network. InterAct and FileAct security: Sensitive business or security data exchanges such as

payment orders, confirmations, account balances, user IDs and passwords are

exchanged through InterAct or SWIFTNet FileAct. Such exchanges benefit directly

from all the features of these services, including their high security and reliability.

Their use is made invisible to the person browsing.

Closed user group control: Browse exchanges are only permitted within defined

closed user groups


21/133

21 | P a g e

SWIFT Addresses

SWIFT addresses are used to not only indicate the final destination of the message but to

also indicate parties within the individual message. It is the use of strictly codified addressesthat enables the automation of Straight through Processing in conjunction with the fixed tag

format of the messages themselves.

Bank Identifier Codes (BICs)

SWIFT network to have a BIC and these can therefore be used over other networks such as

Telex. SWIFT is, however, the recognized ISO (International Standards Organization) body

for assigning these.

The following shows the general format of a BIC address

AAAA BB CC (D) (EEE)

Bank Country Location LT Branch

The first four characters represent the Bank code, for example NWBK (NatWest), DEUT

(Deutsche Bank).

The next two characters represent the ISO Country code, for example GB (United Kingdom),

DE (Germany).

The next two characters are the location code with some larger financial centers such as

London and New York having two, 2L and 22, 33 and 3N respectively.

These characters, the first 8, represent the mandatory portions and commonly within the

body of a message this will be the normal format, for example NWBKGB2L (NatWest

London), DEUTDEFF (Deutsche Bank Frankfurt).

The presence of 0 (zero) in position 8 indicates that this is a test & training address. Test &

Training is a facility which SWIFT gives its users to test new releases without interfering with

live operations. When an organization first joins SWIFT they must spend two months

sending messages in test & training before they are allowed to go live. Optionally a three

character branch code can be added at the end of the address.

For example NWBKGB2LBIR might be the Birmingham branch. These codes are primarily

used for internal routing purposes within the bank, as the branches themselves do not have

direct connection. Usage is often more common in some countries than others such as the

heavy use by Italian banks.

The Logical Terminal ID in position 9 will be present in the header of the message and

identifies a logical channel connection to SWIFT. Some organizations may run more than 1

LT on the same CBT and these will be referred to as A, B, C, etc.

For example: NWBKGB2LA. These are not published in the BIC directory and so all addresses

within a message identifying the sender or other parties will not contain this character.


22/133

22 | P a g e

LTs will therefore always be padded out to 12 Characters by X's and SWIFT addresses are

therefore either 8 or 11 characters.

The presence of a 1 in position 8 denotes that this is not a SWIFT address but the

organization has requested that an ISO identifier be allocated to them.

For example NWBKGB21. Therefore, this address can be included in the body of a message

but you cannot send a message via SWIFT to them.

The presence of an X in position 8 denotes that the CBT which is processing traffic for this

address is not physically in the same country as the Country Code states.

IBAN (International Bank Account Number)

An IBAN or International Bank Account Number is a series of alphanumeric characters that

uniquely identifies a customers account held at a bank anywhere in the world.

Cross-border transactions introduce a further level of complexity above that of domestic

clearing, as there are many variations in the way countries undertake payment processing.

Since it is unrealistic to expect the payment Originator to understand the subtleties of

multiple domestic clearing systems, it is not surprising that error rates for international

payments are significant. These errors frequently lead to payments being rejected, resulting

in a negative impact on customer service and increased administration costs. The IBAN has

been introduced to help reduce problems with cross-border transactions by providing a

standard format for displaying and validating international bank account numbers.

An International Bank Account Number typically contains a two-character ISO country code,

two check digits for validation purposes followed by the domestic bank code and account

number.

Example of a UK IBAN:

The format of the IBAN helps to ensure that cross-border payments are processed correctly.

The country code indicates the country in which the IBAN was issued and also acts as a

reference to the structure of the domestic account number contained within the IBAN. In

addition the check digits validate the complete IBAN to ensure it has been entered correctly

and has not been corrupted.
http://www.experianidentityandfraud.com/glossary/iban-(international-bank-account-number).htmlhttp://www.experianidentityandfraud.com/glossary/originator.htmlhttp://www.experianidentityandfraud.com/glossary/originator.htmlhttp://www.experianidentityandfraud.com/glossary/iban-(international-bank-account-number).html


23/133

23 | P a g e

IBAN has helped to structure cross-border transactions, it is only part of the solution to

eliminating errors in payments. For example, it is quite feasible to generate a valid IBAN

containing invalid domestic details which would result in the payment being rejected. IBAN

validation is only one step in the process to correctly and efficiently route cross-border

payments.


24/133

24 | P a g e

Standards

SWIFT has become the industry standard for syntax in financial messages. Messages

formatted to SWIFT standards can be read by, and processed by, many well known financialprocessing systems, whether or not the message actually travelled over the SWIFT network.

SWIFT cooperates with international organizations for defining standards for message

format and content. SWIFT is also registration authority(RA) for the

following ISO standards:

ISO 9362: 1994 Banking telecommunication messages: Bank identifier codes

ISO 10383: 2003 Securities and related financial instruments: Codes for exchanges

and market identification (MIC)

ISO 13616: 2003 IBAN Registry

ISO 15022: 1999 Securities: Scheme for messages (Data Field Dictionary) (replacesISO 7775)

ISO 20022-1: 2004 and ISO 20022-2:2007 Financial services: UN Iversal Financial

Industry message scheme

SWIFT offers a range of standards to initiate, and to clear and settle financial institution

payments. A related set of standards is available to handle exceptions and investigations for

these payments, as well as standards that provide account related information exchanged

between an account owner and an account servicer.
http://en.wikipedia.org/wiki/ISOhttp://en.wikipedia.org/wiki/ISO_9362http://en.wikipedia.org/wiki/ISO_10383http://en.wikipedia.org/wiki/ISO_13616http://en.wikipedia.org/wiki/IBANhttp://en.wikipedia.org/wiki/ISO_15022http://en.wikipedia.org/wiki/ISO_20022http://en.wikipedia.org/wiki/ISO_20022http://en.wikipedia.org/wiki/ISO_15022http://en.wikipedia.org/wiki/IBANhttp://en.wikipedia.org/wiki/ISO_13616http://en.wikipedia.org/wiki/ISO_10383http://en.wikipedia.org/wiki/ISO_9362http://en.wikipedia.org/wiki/ISO


25/133

25 | P a g e

MT

In the MT portfolio for financial institutions, the MT 202 is the de facto standard used tocover customer credit transfers, and to settle payments resulting from other business

transactions such as securities and treasury transactions. Other Category 2 MTs are

available for cheque truncation, financial market debits and requests for transfers.

Common Group MTs can be used to handle queries, replies, rejects, returns and requests

for cancellations.

A set of Category 9 Cash Management MTs can be used by financial institutions to provide

information on financial institution accounts for cash management and reconciliation

purposes.

MX

ISO 20022 messages are available to execute financial institution credit transfers. Related

messages are available to communicate about status, returns, reversals and requests for

cancellations of the financial institution credit transfers.

ISO 20022 exceptions and investigations messages allow parties involved in the payment to

initiate queries and track replies related to the investigations.

An interactive set of MX messages for interbank account information and cash management

is available.


26/133

26 | P a g e

SWIFT Messages

SWIFT processes information (i.e., data, text, or commands) in the form of messages.

SWIFT initially offers two applications

1. General Purpose Application (GPA) which controls how users communicate within

SWIFT.

2. Financial Application (FIN) which controls the user to user messaging facilities within

SWIFT.

These together provide all of the messaging functions and facilities available to users.

Actual appearance of a SWIFT message (whether on screen or on paper) is dependent upon

how their Computer-based terminal (CBT) has been programmed and on any internal

processing of SWIFT messages carried out within their own organization.

A validation error in the application header, text or trailer block will result in a negative

acknowledgment (NAK) indicating the reason for rejection.

Each message received by the system is examined to determine whether it conforms to the

format specification for that message type.

The sequence in which the various parts of a SWIFT message are validated is as follows:

1. Basic header

2. Application header3. User header

4. Text

5. Trailers

At the first validation failure, the appropriate error procedure is carried out (either session

abortion or negative acknowledgment) and no further validation is performed on the

message.

Structure of a Message

All SWIFT messages conform to a defined block structure.

Each block of a message contains data of a particular type and is used for a particular

purpose.

Each block of message begins and ends with a curly bracket (or brace) character "{"

and "}" respectively.

All main blocks are numbered, and the block number followed by a colon (:) are

always the first characters within any block.

A typical SWIFT user-to-user message may consist of:

1: Basic Header Block


27/133

27 | P a g e

2: Application Header Block

3: User Header Block

4: Text Block

5: Trailers Block

Only block 1 (the Basic Header block) is mandatory for all messages. Blocks 2-5 are optional

and depend upon the nature of the message and on the application in which the message is

being sent or received.

Blocks 1, 2 and 3 relate to header information, block 4 contains the text of the message, and

block 5 contains trailer information.

Blocks 3, 4 and 5 may contain sub-blocks (i.e., blocks within blocks) or fields delimited by

field tags, depending on the nature of the message.

At the first validation failure, the appropriate error procedure is carried out (either session

abortion or negative acknowledgment) and no further validation is performed on the

message.

Length of a Message

The type of SWIFT message will determine the maximum length allowed for the particular

message. Individual transaction messages such as the 520 series of messages permit for a

maximum message length of 2000 bytes. Statement type messages such as the 950 or 570

series of messages permit a maximum of 10,000 bytes.

Presentation of a Message

Each main block is sub-divided into a number of fields and each field contains particular

information (e.g., date, time, LT address, session number, ISN, or a tag number followed by

the appropriate variable content).

All fields within header blocks 1 and 2 are of fixed length and are continuous - no field

separators are used.

In the case of the text of a user-to-user message, all message text within the Text block(block 4) begins with Carriage Return and Line Feed (CrLf) and ends with CrLf followed by a

hyphen (-). Each field within the text begins with a tag number followed by a colon,

followed by the appropriate variable content.

For the purpose of clarity within this manual, some message examples are shown here with

each block beginning a new line and with spaces separating the various fields within blocks.

The block separators "{" and "}" are also shown. The letters a,b,c,d, etc., are used in these

examples to identify the constituent parts of each block. An explanation of each part or

field is given for each example.


28/133

28 | P a g e

1. Basic Header Block

The basic header is given in block 1 of a SWIFT message. It is the only compulsory header

and appears on all user-to-user messages, system messages, system commands and

acknowledgments. The basic header provides the fundamental referencing of a particular

message within an application session of a particular LT.

The basic header has the same format for both input and output messages. However, the

information contained in the basic header is relative to the sender when the message is

input but relative to the receiver when the same message is output.

The following is an example of a basic input header, as it might appear at the beginning of a

user-to-user message input within the FIN application.

{1:F01BANKBEBBAXXX2222123456}

but for clarity the components are shown separately:

{1: F 01 BANKBEBBAXXX 2222 123456}

1: Block

Identifier

Block identifier for a basic header block is

always "1:".

F Application

Identifier

The application identifier identifies the

application within which the message is being

sent or received. The available options are:

F=FIN (all user-to-user and FIN system

messages)(used for ISITC)A=GPA (most GPA system messages and

commands)

L=GPA (certain GPA session control

commands, e.g., LOGIN, LOGIN

acknowledgments, ABORT)

01 Application

Protocol Data

Unit

Identifier

The Application Protocol Data Unit (APDU)

Identifier consists of two numeric characters. It

identifies the type of data that is being sent or

received and, in doing so, whether the messagewhich follows is one of the following:

User-to-user message

System message

Service message, e.g., a session control

command (such as SELECT)

Logical acknowledgment (such as

ACK/SAK/UAK).

BANKBEBBAXXX LT Address This 12-character SWIFT address, given in the

basic header block, is the address of thesending LT (for input messages) or of the


29/133

29 | P a g e

receiving the LT (for output messages), and

includes the branch code. In the basic header,

the Logical Terminal Code within the LT address

is specific to the LT that has established the

session in which the message is being

transmitted (i.e. the sending LT for input

messages or the receiving LT for output

messages).

A SWIFT address or BIC can be requested for

any financial institution, whether or not you are

a SWIFT member participant, by contacting

SWIFT administration. The SWIFT address

which will be assigned by SWIFT administration

is comprised of the following:

Bank Code 4

Characters

Country Code 2

Characters

Location Code 2

Characters

Logical Terminal Code 1 Character

Branch Code 3

Characters

2222 Session

Number

The session number identifies the session in

which the message was transmitted. Within

the basic header, the session number (four

digits) is the user's current GPA or FIN session

number. ("0000" - ISITC)

123456 Sequence

Number (ISN

or OSN)

The sequence number always consists of six

digits. It is the ISN of the sender's current input

session or the OSN of the receiver's current

output session. ("000001" - ISITC)


30/133

30 | P a g e

2. Application Header BlockThe application header of a SWIFT message provides information about the message itself.

The application header is given in block 2 of a SWIFT message. If differs according to

whether the message is a GPA or a FIN message and whether the application header is

attached to an input message or to a output message.

2: Block Identifier The block identifier for an application

header block is always "2:".

I Input/Output

Identifier

The input/output identifier consists of a single

letter - either "I" for an input message or "O"

for an output message.

100 Message Type The message type consists of three digits

which define the MT number of the message

being input. The example used above is for a

Customer Transfer (MT 100).

BANKDEFFXXXX Recipient's Address This address is the 12-character SWIFT address

of the recipient of the message, but with a

Logical Terminal Code of "X". If defines the

destination to which the message should be

sent.

The system will replace the "X" with a specific

Logical Terminal Code on delivery of the

message.

Institutions which are not part of the SWIFT

network will be assigned a Branch Code of BIC.

The branch code is mandatory and will be

validated. The default of "XXX" may be used,

as in the example above.

U Message Priority This character (used within FIN application

headers only) defines the priority by which a

message shall be delivered. The possible

values are:

S = System

U = Urgent

N = Normal

Message priority "S" must be used for user-to-

system messages: for user-to-user messages

either "U" or "N" may be used

3 Delivery

Monitoring

Delivery monitoring options apply only to FIN

user-to-user messages.The chosen option is expressed as a single


31/133

31 | P a g e

Application Header Input: For input messages, the application header describes the type

of message, whom it is for and how it should be sent. The following is an example of aninput application header, as it might appear at the top of a user-to-user message, input

within the FIN application:

digit:

1 = Non-Delivery Warning

2 = Delivery Notification

3 = Non-Delivery Warning and Delivery

Notification.

If the message has priority 'U' then the user

must request delivery monitoring option '1' or

'3'. If the message has priority 'N', the user can

request delivery monitoring option '2', or, by

leaving the option blank, no delivery

monitoring.

003 Obsolescence

Period

The obsolescence period defines the period of

time after which a Delayed Message (DLM)

trailer is added to a FIN user-to-user message

when the message is delivered. For urgent

priority messages, it is also the period of time

after which, if the message remains

undelivered, a Non-Delivery Warning is

generated. The values for the obsolescence

period are:

003 (15 minutes) for 'U' priority, and

020 (100 minutes) for 'N' priority.


32/133

32 | P a g e

{2: I 100 BANKDEFFXXXX U 3 003}

Application Header-Output: For output messages, the output application header defines the

type of message, who sent it (and when), and when it was delivered.

GPA output application headers are similar to their FIN equivalents except that, for GPA, the

message priority is not included.

The following is an example of an output application header, as it might appear at the top of

a user-to-user message output within the FIN Application:

{2: 0 100 1200 910103BANKBEBBAXXX2222123456 910103 1201 N}

2: Block Identifier The block identifier for an application

header block is always "2:".

0 Input/Output

Identifier

The input/output identifier consists of a single

letter - either "I" for an input message or "O" for

an output message.

100 Message Type The message type consists of three digits which

define the MT number of the message being

output. The example used above is for a

Customer Transfer (MT 100).

1200 Input Time The input time (HHMM) is expressed in the

sender's local time. If the message is a system

message, the input time is the time the message

was generated by the system, expressed in

Greenwich Mean Time. (GMT)

910103BANK

BEBBAXXX

2222123456

Message Input

Reference (MIR)

Every input message is assigned a unique

Message Input Reference (MIR). This is a string of

28 characters which consists of the date the

message was input (local to the sender), the

sender's LT identifier and branch code, the

sender's session number and sender's ISN. If the

output message is system-generated, the system

MIR will show a Pseudo-Logical Terminal (PLT)

address, e.g., SWFTXXXXXXXX, identifying as the

sender the particular suite of programs which

generated the message within the system. The

date given in the system MIR is the generation

date in GMT.


33/133

33 | P a g e

910103 Output Date The output date (YYMMDD) is the date local to

the receiver.

1201 Output Time The output time (HHMM) is expressed in the

receiver's local time.

N Message Priority The message priority, for FIN messages only, is

repeated in the FIN output application header.

("N" - ISITC default, no priority)

3. User Header BlockRequired for ISITC version controlISITC :International Securities Association for Institutional Trade Communications

The user header is an optional header available within the FIN application and is available

for user-to-user messages only. This header block is mandatory as it is utilized to identify

the version of the message standard applicable for processing and validating the particular

message to which the header applies. It also allows a user to provide his form of reference

for a particular message.

A user header can only be assigned by the sender of a message and, if assigned, will always

appear on the output message copy and on related system messages and

acknowledgments.

The user reference part of the user header may be used as one of the selection criteria in a

SWIFT retrieval.

The user header appears in block 3 of a SWIFT message. If used, at least one of the two

possible sub-blocks must be defined.

The following example shows the format of a user header:

{3: {113:9601} {108:abcdefgh12345678}}

3: Block

Identifier

The block identifier for a user header block

always has the value "3:".


34/133

34 | P a g e

{113:9601} ISITC Version

Identifier

A version/release represents a snapshot in time

of the status of the development and

maintenance efforts of ISITC as of a specified

date. Up to two releases per year may be

approved for implementation and are identified

by version control numbers. Tag 113 is used by

ISITC to identify the version of the standard that

applies to the message.

Version identifiers are four digits long and

identify the year the version was created (i.e.

1996 would be 96) as well as the version number

(01 or 02) as there are a maximum of two

versions of the standard per year.

{108:abcdefgh

12345678}

Message User

Reference

(MUR)

Tag 108 defines a free-format field in which users

may specify their own reference of up to 16

characters of all the permitted character set.

If an MUR is not specified, the TRN (from field 20: in the text of a user-to-user message) is

automatically copied into this field, but only on the system's storage media, and may be

used for retrieval of the messages if the alphabetic characters contained in the TRN were in

uppercase. The TRN will never be output as an MUR.


35/133

35 | P a g e

4. Text BlockThe text of a SWIFT message (where applicable) is given in block 4 of a SWIFT message. An

example of the text block in a typical FIN user-to-user message follows:

{4:

: 20: PAYREF- TB54302

: 32A:910103BEF1000000,

: 50: CUSTOMER NAME

AND ADDRESS

: 59:/123-456-789

BENEFICIARY NAME

AND ADDRESS

-}

In the text of user-to-user messages, CrLf is a mandatory delimiter. In those cases where

character type "a", "a", "a", or "a" is used in the field format description, the alphabetic

characters must be uppercase.

The text part of a GPA message or a FIN system message differs only in that each text field is

seen as a sub-block of block 4, with block delimiters at the beginning and end of each sub-

block. For example, the text block of a Non-Delivery Warning (MT 010) may appear as:

{4 :{ 106:910103BANKBEBBAXXX1221654321}

{108: ABCDEF}

{431:07}

{102:BANKUS33XXXX}

{104: U}}

(Note that the text block will be transmitted as a continuous string of characters withoutCrLf or blank characters inserted. In the above example, the sub-blocks have been shown

on separate lines for purpose of clarity.)

All Swift Text Messages have a maximum of 35 characters per line.

In the event that the necessary information spans more than one line, the current line must

end with a CrLf, and the subsequent line must begin with the "//" continuation character.

e.g. :35B:678901234567890123456789012345CrLf

//1234567890...


36/133

36 | P a g e

5. Trailers Block

General Trailers are added to a message for control purposes: or to indicate that special

circumstances apply to the handling of the message: or to convey special/additional

information. They may be added by the user or by the system.

Trailers always appear in block 5 of a SWIFT message. Each trailer appears as a separate sub-

block and is bounded by block delimiters. Each trailer begins with a three letter code,

followed by a colon, followed by the trailer information itself.

For example, block 5 of a user-to-user message, sent with an authentication trailer and

checksum trailer, may appear as:

{5 :{ MAC: 41720873} {CHK: 123456789ABC}}

SWIFT Character SetCBTs communicating with SWIFT use EBCDIC code. The character set is as follows:

a b c d e f g h i j k l m n o p q r s t u v w x y z

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

0 1 2 3 4 5 6 7 8 9 / - ? : ( ). , ' + {} Cr Lf Space

All alphabetic characters in all headers, and in text of user-to-system messages, must be in

upper case. The system does not recognize lower case letters as equivalent to upper case.

Although part of the character set, the curly brackets are only permitted as delimiters andcannot be used within the text of user-to-user message.

SWIFT Messages Type of Messages

MT1XX Customer transfers and cheques

MT2XX Financial institution transfers

MT3XX Treasury markets

MT4XX Collections & cash letters

MT5XX Securities

MT6XX Precious metals and syndications

MT7XX Documentary credits/guarantees

MT8XX Travellers cheques

MT9XX Cash management & customer status

MT0XX System Messages


37/133

37 | P a g e

Category 1Customer Payments & Cheques

MT MT Name Purpose

101 Request for Transfer Requests to debit a customers account held at

another institution

102 / 102+ Multiple Customer CreditTransfer

Conveys multiple payment instructions betweenfinancial institutions

103 / 103+

/ 103

REMIT

Single Customer Credit

Transfer

Instructs a funds transfer

104 Direct Debit and Request

for Debit Transfer

Message

Conveys direct debit instructions and requests for

direct debits between financial institutions

105 EDIFACT Envelope An envelope which conveys a 2k EDIFACT message

106 EDIFACT Envelope An envelope which conveys a 10k EDIFACT message

107 General Direct Message To order the debit of a debtor's account and to collect

payment from this account

110 Advice of Cheque(s) Advises or confirms the issuance of a cheque to the

drawee bank

111 Request for Stop

Payment of a Cheque

Requests the drawee bank to stop payment of a

cheque

112 Status of a Request for

Stop Payment of a

Cheque

Indicates action(s) taken in attempting to stop

payment of a cheque

121 Multiple Interbank FundsTransfer

Contains an EDIFACT FINPAY message

Category 2Financial Institution Transfers

MT MT Name Purpose

200 Financial Institution

Transfer for its Own

Account

Requests the movement of the Senders funds to its

account at another financial institution

201 Multiple Financial

Institution Transfer for

its Own Account

Multiple of the MT 200

202 General Financial

Institution Transfer

Requests the movement of funds between financial

institutions

203 Multiple General

Financial Institution

Transfer

Multiple of the MT 202

204 Financial Markets

Direct Debit Message

Claims funds from SWIFT member banks

205 Financial Institution

Transfer Execution

Further transmits a transfer request domestically


38/133

38 | P a g e

206 Cheque Truncation

Message

Conveys information on one or more truncated

cheques in order to debit or obtain credit under usual

reserve

207 Request for Financial

Institution Transfer

Requests to debit an ordering financial institutions

account held at the receiving financial institution or the

account servicing financial institution

210 Notice to Receive Notifies the Receiver that it will receive funds for the

Senders account

256 Advice of Non-Payment

of Cheques

Informs the Sender of one or more previously sent MT

206s of non-payment of one or more truncated

cheques. It may also be used to specify dishonoured

items that result in reversing a previous payment

settlement

Category 3Treasury MarketsForeign Exchange, Money Markets & Derivatives

MT MT Name Purpose

300 Foreign Exchange

Confirmation

Confirms information agreed to in the buying/selling of

two currencies

303 Forex/Currency Option

Allocation Instruction

Instructs the allocation of a block trade (forex or

currency option)

304 Advice/Instruction of a

Third Party Deal

Advises of or instructs settlement of a third party

foreign exchange deal

305 Foreign Currency Option

Confirmation

Confirms information agreed to in the buying and

selling of vanilla options on currencies

306 Financial Markets Direct

Debit Message

Confirms information agreed to in the buying and

selling of exotic options on currencies

307 Advice/Instruction of a

Third Party FX Deal

Advises of or instructs settlement of a third party

foreign exchange deal

308 Instruction for a

Gross/Net Settlement of

Third Party FX Deals

Informs which deals done on behalf of a third party

area to be settled gross and which ones netted

320 Fixed Loan/Deposit

Confirmation

Confirms the terms of a contract relative to a fixed

loan/deposit transaction321 Instruction to Settle a

Third Party Loan/Deposit

Advises the trade details and instructs the settlement

of a fixed term loan/deposit done with a third party

financial institution

330 Call/Notice

Loan/Deposit

Confirmation

Confirms the terms of a contract relative to a

call/notice loan/deposit transaction

340 Forward Rate Agreement

Confirmation

Confirms the details of a forward rate agreement

341 Forward Rate Agreement

Settlement Confirmation

Confirms the settlement details of a forward rate

agreement


39/133

39 | P a g e

350 Advice of Loan/Deposit

Interest Payment

Advises of a loan/deposit interest payment

360 Single Currency Interest Rate

Derivative Confirmation

Confirms the details of a single currency interest

rate derivative swap, cap, collar or floor

361 Cross Currency Interest

Rate Swap Confirmation

Confirms the details of a cross currency interest rate

swap transaction

362 Interest Rate

Reset/Advice of Payment

Confirms or advises the reset rates of the floating

interest rate(s) in a single or cross-currency interest

rate derivative transaction and/or the payment of

interest at the end of an interest period

364 Single Currency Interest

Rate DerivativeTermination/Recouponing

Confirmation

Confirms the details of the partial or full termination or

recouponing of a single currency interest rate swap,cap, collar or floor

365 Cross Currency Interest

Rate Swap

Termination/Recouponing

Confirmation

Confirms the details of the partial or full termination or

recouponing of a cross, currency interest rate swap

380 Foreign Exchange Order Orders to purchase or sell a specific amount of a

certain currency

381 Foreign Exchange Order

Confirmation

Confirms the execution of a FX Order Previously sent

Category 4Collection & Cash Letters

MT MT Name Purpose

400 Advice of Payment Advises of a payment under a collection or part

thereof. It also handles the settlement of proceeds

405 Clean Collection Conveys instructions to obtain payment or acceptance

against specified conditions. The message is used forclean collections only and supports financial

documents such as accepted and non-accepted bills of

exchange and promissory notes

410 Acknowledgement Acknowledges receipt of a collection. It also specifies if

the collecting bank does not intend to act in

accordance with the collection instruction

412 Advice of Acceptance Informs the remitting bank of the acceptance of one or

more drafts under one collection instruction

416 Advice of Non-

Payment/Non-Acceptance

Advises of the non-payment or non-acceptance under

a


40/133

40 | P a g e

420 Tracer Enquires about documents dent for collection

422 Advice of Fate and

Request for Instructions

Advises the remitting bank of the fate of one or more

collection documents; usually accompanied by one or

more questions or requests

430 Amendment of

Instructions

Amends collection instructions

450 Cash Letter Credit Advice Confirms that the face amount of cash letter(s)

received has been credited under usual reserve

(subject to final payment)

455 Cash Letter Credit

Adjustment Advice

Advises the account owner of adjustments made to its

account (related to a previous credit for a cash letter)

456 Advice of Dishonour Advises the account owner that financial document(s)

included in the cash letter have been dishonoured for

reasons specified in the advice

Category 5Securities Markets

MT MT Name Purpose

500 Instruction to Register Instructs the registration, deregistration or re-

registration of a financial instrument at the

registration provider

501 Confirmation of

Registration or Modification

Confirms the registration, deregistration or re-

registration of a beneficial owner or shareholderwith the registration provider

502 Order to Buy or Sell Instructs the purchase or sale of a given quantity of

a specified financial instrument under specified

conditions

503 Collateral Claim Requests new or additional collateral, or the return

or recall of collateral

504 Collateral Proposal Proposes new or additional collateral

505 Collateral Substitution Proposes or requests the substitution of collateral

held

506 Collateral and Exposure

Statement

Provides the details of the valuation of both the

collateral and the exposure

507 Collateral Status and

Processing Advice

Advises the status of a collateral claim, a collateral

proposal, or a proposal/request for collateral

substitution

508 Intra-Position Advice Reports on the movement of securities within the

holding

509 Trade Status Message Provides information on the status of a previously

executed trade

510 Registration Status andProcessing Advice Advises the status of a registration instruction ormodification


41/133

41 | P a g e

513 Client Advice of Execution Provides brief and early information about a

securities deal, e.g., a block trade that is to be

allocated before final confirmation

514 Trade Allocation Instruction Instructs the allocation of a block trade

515 Client Confirmation of

Purchase or Sale

Provides a detailed accounting of financial

instruments purchased or sold by the Sender on

behalf or the Receiver or its client. It may also

convey the payment details of the purchase or sale.

It may also be sent by, or via an ETC service provider

516 Securities Loan

Confirmation

Confirms the details of a securities loan, including

collateral arrangements. It may also confirm the

details of a partial recall or return of securities

previously out on loan

517 Trade Confirmation

Affirmation

Positively affirms the details of a previously received

confirmation/contract note518 Market-Side Securities

Trade Confirmation

Confirms the details of a trade and where

necessary, its settlement to a trading counterparty

519 Modification of Client

Details

Instructs the modification of client details at the

registration provider

524 Intra-Position Instruction Instructs the movement of securities within the

holding

526 General Securities

Lending/Borrowing

Message

Requests the borrowing of securities or notifies the

return or recall of securities previously out on loan.

It may also be used to list securities avaliable for

lending527 Tri-party Collateral

Instruction

Performs a specific action on a collateral

management transaction

528 ETC Client-Side Settlement

Instruction

Sent by an ETC service provider, it communicates

early settlement information to a custodian or

clearing agent about a client-side trade

529 ETC Market-Side Settlement

Instruction

Sent by ETC service provider, it communicates early

settlement information to a custodian or clearing

agent about a market-side trade

530 Transaction Processing

Command

Requests the modification of a processing indicator

or other non-matching information.

535 Statement of Holdings Reports at a specified time, the quantity and

identification of securities and other holdings which

the account servicer holds for the account owner

536 Statement of Transactions Provides details of increases and decreases of

holdings which occurred during a specified period

537 Statement of Pending

Transaction

Provides details of pending increases and decreases

of holdings at a specified time

538 Statement of Intra-Position

Advices

Provides details of increases and decreases in

securities within the holding during a specifiedperiod


42/133

42 | P a g e

540 Receive Free Instructs a receipt of financial instruments free of

payment. It may also be used to request a

cancellation or pre-advise an instruction

541 Receive Against Payment Instructs a receipt of financial instruments against



542 Deliver Free Instructs a delivery of financial instruments free of



543 Deliver Against Payment Instructs a delivery of financial instruments against



544 Receive Free Confirmation Confirms a receipt of financial instruments free of

payment. It may also be used to cancel or reverse a

confirmation545 Receive Against Payment

Confirmation

Confirms a receipt of financial instruments against


confirmation

546 Deliver Free Confirmation Confirms a delivery of financial instruments free of


confirmation

547 Deliver Against Payment

Confirmation

Confirms a delivery of financial instruments against


confirmation

548 Settlement Status andProcessing Advice

Advises the status of a settlement instruction orreplies to a cancellation request

549 Request for

Settlement/Status Advice

Requests a statement or a status message

558 Triparty Collateral Status

and Processing Advice

Provides validation results and status advice re

collateral instructions and proposed collateral

movements

559 Paying Agents Claim Claims reimbursement of income or redemption

proceeds, or a combination of both

564 Corporate Action

Notification

Provides an account owner with details of a

corporate action event and the choices available to

the account owner. It also provides the account

owner with details on the impact a corporate action

event will have on a safekeeping or cash account,

eg, entitlement calculation


Instruction

Instructs the custodian on the investment decision

made by an account owner relative to a corporate

action event


Confirmation

Confirms to the account owner that securities

and/or cash have been credited/debited to an

account as a result of a corporate action event


43/133

43 | P a g e

567 Corporate Action Status and

Processing Advice

Indicates the status, or a change in status, of a

corporate action-related transaction previously

instructed by, or executed on behalf of, the account

owner

568 Corporate Action Narrative Provides complex instructions or narrative details

relating to a corporate action event

569 Triparty Collateral and

Exposure Statement

Provides the details of the valuation of both the

collateral and the exposure

574 IRS 1441 NRA-IRS Beneficial

Owners List

Provides owner or pooled income information for a

period of time arranged between the intermediary

and the withholding agent

574 IRS 1441 NRA-Form W8-

BEN

Certifies the foreign status of a beneficial owner for

United States tax withholding

575 Report of Combined Activity Reports on all securities and cash activity for a given

combination of safekeeping and cash accounts576 Statement of Open Orders Provides details of orders to buy or to sell financial

instruments, as at a specified date, which have been

accepted by the Sender, but which have not yet

been executed

577 Statement of Numbers Provides certificates numbers of securities

578 Settlement Allegement Advises the account owner that a counterparty has

alleged a settlement instruction on the account

owners account

579 Certificate Numbers Replaces or supplements the certificate numbers

field in a primary message, eg, MT 577581 Collateral Adjustment

Message

Claims or notifies a change in the amount of

collateral held against securities out on loan or for

other reasons

582 Reimbursements Claim or

Advice

Claims reimbursement of funds paid on behalf of

the Receiver or of securities received which are due

to the Sender. It may also advise that funds and/or

securities have or will be remitted by the Sender in

favour of the Receiver

584 Statement of ETC Pending

Trades

Provides statuses and details of executed trades

which are not yet matched nor affirmed

586 Statement of Settlement

Allegements

Provides details of pending settlement allegements

587 Depositary Receipt

Instruction

Instructs the issuance or release of a depositary

receipt from/to ordinary shares, or the conversion

from one type of depositary receipt to another

588 Depositary Receipt

Confirmation

Confirms the issuance or release of a depositary

receipt from/to ordinary shares, or the conversion

from one type of depositary receipt to another

589 Depositary Receipt Statusand Processing Advice

Advises the status, or change in status, of adepositary receipt


44/133

44 | P a g e

Category 6Treasury MarketsPrecious Metals

MT MT Name Purpose

600 Precious Metal TradeConfirmation

Confirms the details of a precious metal trade andits settlement

601 Precious Metal Option

Confirmation

Confirms the details of a precious metal option

contract

604 Precious Metal

Transfer/Delivery Order

Instructs the Receiver to transfer by book-entry, or

physically deliver, a specified type and quantity of

precious metal to a specified party

605 Precious Metal Notice to

Receive

Notifies the Receiver of an impending book-entry

transfer or physical delivery of a specified type and

quantity of precious metal

606 Precious Metal Debit Advice Advises the Receiver of a debit entry to a specifiedmetal account

607 Precious Metal Credit

Advice

Advises the Receiver of a credit entry to a specified

metal account

608 Statement of a Metal

Account

Provides the details of all bookings to a metal

account

609 Statement of Metal

Contracts

Identifies all outstanding metal contracts, as at a

specified date for which confirmations have been

exchanged

643 Notice of

Drawdown/Renewal

Provides notice of the Borrower(s) request for

drawdown(s)/renewal(s) on a given date

644 Advice of Rate and Amount

Fixing

Specifies the interest rate and, if applicable, the

exchange rate, for the next interest period

645 Notice of Fee Due Specifies flat and variable fees, related to one

Facility, due to the Receiver

646 Payment of Principal and/or

of Interest

Advises of payments and/or prepayments of

principal and/or of interest with the same value

date, but not related to any subsequent drawing or

renewal

649 General Syndicated FacilityMessage Provides for communications related to syndicatedfacilities for which no specific message has been

defined

Category 7Documentary Credits & Guarantees

MT MT Name Purpose

700 Issue of a Documentary

Credit

Indicates the terms and conditions of a documentary

credit

701 Issue of a Documentary

Credit

Continuation of an MT 700 for fields 45a, 46a and 47a


45/133

45 | P a g e

705 Pre-Advice of a

Documentary Credit

Provides brief advice of a documentary credit for which

full details will follow

707 Amendment to a

Documentary Credit

Informs the Receiver of amendments to the terms and

conditions of a documentary credit

710 Advice of a Third Banks

Documentary Credit

Advises the Receiver of the terms and conditions of a

documentary credit

711 Advice of a Third Banks

Documentary Credit

Continuation of an MT 710

swift finaldoc

Documents