Solutions
SWIFT for Corporates
Standards MT Migration Guide
MT Migration 2009
Version 1.0
This document provides guidance for the November 2009 mandatory migration from the MT 103, Customer Credit
Transfer, to the MT 101, Request for Transfer, and from the MT 950, Statement Message, to the MT 940, Customer
Statement Message, on SCORE (Standardised Corporate Environment).
22 January 2009
Table of Contents
Table of Contents
Table of Contents ............................................................................................................................ 2 Preface ............................................................................................................................................. 4 1 Differences between MT 101 and MT 103 ............................................................................ 5 1.1 Scope and usage ....................................................................................................................5 1.2 Scenarios ................................................................................................................................5 1.3 Content ....................................................................................................................................6 2 Specific corporate functionality in MT 101 .......................................................................... 9 2.1 Possibility to combine multiple transactions in a single message, potentially resulting into a
single debit (field 21R) ............................................................................................................9 2.2 Possibility to chain multiple messages (field 28D) ................................................................13 2.3 Possibility to identify an instructing party (field 50a, Instructing Party) .................................16 2.4 Identification of the ordering customer’s account (field 50a, Ordering Customer) ...............21 2.5 Possibility to identify an institution, servicing the ordering customer’s account, other than the
receiver (field 52a) ................................................................................................................22 2.6 Identification of the requested execution date (field 30) .......................................................24 2.7 Possibility to provide an electronic signature (field 25) .........................................................24 2.8 Identification of an exchange rate and an F/X deal (field 21F) .............................................24 2.9 Possibility to provide corporate-specific instructions (codes in field 23E) ............................25 2.10 Different ways to instruct an amount (fields 32B and 33B) ...................................................28 2.11 Possibility to identify a separate charges account (field 25A) ..............................................29 3 How to handle MT 103 specific information in an MT 101 ................................................ 31 3.1 Ordering Institution (field 52a)...............................................................................................31 3.2 Time indications (field 13C) ..................................................................................................31 3.3 Pre-signed service level agreements (field 23B) ..................................................................31 3.4 Bank specific instructions (codes in field 23E) ......................................................................31 3.5 Regulatory reporting codes (field 26T)..................................................................................32 3.6 Value date (field 32A) ...........................................................................................................32 3.7 Correspondent banks (fields 53a, 54a and 55a)...................................................................32 3.8 Routing through an RTGS (codes in fields 56a and 57a) .....................................................33 3.9 Transparency about the instructed amount (field 33B) .........................................................33 3.10 Applied exchange rate (field 36) ...........................................................................................33 3.11 Charges information (fields 71F and 71G) ............................................................................33 3.12 Free format information to the receiver (field 72) ..................................................................33 3.13 Large remittance information (field 77T) ...............................................................................33 3.14 The resulting MT 103 to MT 101 conversion table ...............................................................34 4 Differences between MT 940 and MT 950 .......................................................................... 35 4.1 Scope and usage ..................................................................................................................35 4.2 Scenarios ..............................................................................................................................35 4.3 Content ..................................................................................................................................36 5 Specific corporate functionality in MT 940 ........................................................................ 37 5.1 Possibility to reply to an ad-hoc request for a statement (field 21) .......................................37 5.2 Possibility to specify additional information with each entry (field 86, 1st occurrence) .........37 5.3 Possibility to specify forward available balances (field 65) ...................................................37 Standards MT Migration Guide v1.0
22/01/2009
2
Table of Contents
5.4 Possibility to specify a generic block of additional information (field 86, 2nd occurrence) ....37 6 How to handle MT 950 specific information in an MT 940 ................................................ 38 7 Legal Notices ....................................................................................................................... 39 Standards MT Migration Guide v1.0
22/01/2009
3
Differences between MT 101 and MT 103
Preface
Background
In September 2006, the Board approved “FIN message routing rules for the new corporate
access model” (ER1004), which had been developed with the support of the Corporate
Access Group. The guiding principle for defining the FIN matrix for the new SCORE model
was to foster standardisation by
1.
selecting message types (MT) suitable for corporate to financial institution usage,
and
2.
phasing their activation based on market demand and availability of usage
guidelines.
The first release of SCORE was launched in January 2007. Given extensive usage of MT 101
and MT 103 at the time in MA-CUG between corporates and banks – both for the same
purpose (i.e. credit transfer initiation), ER1004 proposed to activate both MTs in SCORE.
Community feedback however indicated a preference to converge towards a single MT for
credit transfer initiation, i.e. MT 101, because this standard offers more corporate specific
functionalities.
In view of this, the Board approved "SCORE – Fine-tuning the FIN message routing rules”
(ER1012) in December 2006, which proposed to refine the SCORE FIN matrix by removing
the MT 103 and the MT 950 from SCORE, leaving the MT 101 and the MT 940 for payment
instructions and account reporting in a corporate to bank environment. Restricting to the
single correct message for each function will increase standardisation of both banks’ and
corporates’ applications.
Purpose of this document
This document provides guidance for the November 2009 mandatory migration
1.
from the MT 103, Customer Credit Transfer, to the MT 101, Request for Transfer,
and
2.
from the MT 950, Statement Message, to the MT 940, Customer Statement
Message.
It explains the differences in functionality between both types of messages and suggests an
approach on how to ease the migration.
Note
Participants in the SCORE service must switch to the MT 101 and MT 940, in
case that would not have been done yet. Where messages are exchanged
between a corporate and a financial institution in an MA-CUG, adherence to these
rules is recommended as well, but must not be assumed.
This guide is a migration guide. It is not a standards handbook, nor an implementation guide.
The detailed description of the MT standards can be obtained from the SWIFT User
Handbooks, Category Volumes. Additional rules and guidelines that have been agreed in the
SCORE environment can be found in the “SWIFT for Corporates - MT implementation guide”.
Document structure
This guide is structured as follows:
•
Section 1: differences between MT 101 and MT 103
•
Section 2: specific corporate functionality in MT 101
•
Section 3: how to handle MT 103 specific information in an MT 101
•
Section 4: differences between MT 940 and MT 950
•
Section 5: specific corporate functionality in MT 940
•
Section 6: how to handle MT 950 specific information in an MT 940
Wherever possible, business scenarios and examples are provided to best illustrate how the
standards must be used.
Standards MT Migration Guide v1.0
22/01/2009
4
Differences between MT 101 and MT 103
1 Differences between MT 101 and MT 103
1.1 Scope and usage
The MT 101 is always sent to the institution servicing the account of the debtor of the
transaction (except when used in relay). Whilst the MT 101 was originally developed to “just”
forward a corporate instruction between banks, the SCORE MT implementation guidelines
allow it now to be used from a corporate to its bank as well.
The MT 103 is subsequently sent by the institution servicing the account of the debtor to the
next party in the chain. It is a pure inter-bank customer credit transfer message.
A further difference is the multiplicity. The MT 103 contains a single transaction, whilst the
MT 101 is a multiple message, ie, can contain one or more transactions.
This difference in scope and usage is also reflected in the format and content of both
messages: the MT 101 supports functionality that is typical for a payment request from an
instructing party, whilst the MT 103 provides its users with functionality that is typically and
only required in an interbank scenario. Chapters 2 and 5 in this guide provide more detail.
1.2 Scenarios
1.2.1 MT 101 Request for Transfer
The account servicing bank can be the receiver of the message (see direct scenario), or can
be a party further in the payment chain (see relay scenario):
Direct scenario
A customer orders its bank to instruct a payment from its account with that bank:
The receiving bank debits the account and initiates a credit transfer (in its books or by
forwarding an MT102/103 or local credit transfer message).
Relay scenario
A customer orders its bank to instruct a payment from its account with a second bank:
The receiving bank forwards the MT 101 to the account servicing institution. This institution
will debit the customer’s account and initiate a credit transfer (in its books or by forwarding an
MT102/103 or local credit transfer message).
Standards MT Migration Guide v1.0
22/01/2009
5
Differences between MT 101 and MT 103
1.2.2 MT 103 Single Customer Credit Transfer
Interbank settlement
The interbank settlement of a customer credit transfer is typically done with an MT 103 or a
domestic equivalent message. The MT 103 supports a number of interbank settlement
scenarios (nostro-account, loro-account, RTGS, netting and clearing system, cover, ...). It is
not the goal of this guide to explain the details around these settlement scenarios.
1.3 Content
The below table compares the MT 101 with the MT 103. It identifies the differences and links
for each individual difference to a detailed explanation.
MT 101
MT 103
Remarks
20
Sender's Reference
16x
M
16x
M
Identical
21R
Customer Specified
Reference
16x
O
Not present
Specific corporate
functionality: see chapter 2.1
28D
Message Index/Total
5n/5n
M
Not present
Specific corporate
functionality: see chapter 2.2
50a
Instructing Party
C or L
O
Not present
Specific corporate
functionality: see chapter 2.3
50a
Ordering Customer
50a
Ordering Customer
F, G, or H
52a
Ordering Institution
Not present
52a
Account Servicing
Institution
A or C
O
Not present
51A
Sending Institution
[/1!a][/34x]
4!a2!a2!c[3!c
]
O
[/1!a][/34x]
4!a2!a2!c[3!c
]
30
Requested Execution
Date
6!n
M
Not present
Specific corporate
functionality: see chapter 2.6
25
Authorisation
35x
O
Not present
Specific corporate
functionality: see chapter 2.7
-----> Mandatory Repetitive Sequence B Transaction Details for
MT 101
Specific corporate
functionality: see chapter 2.1
A, F, or K
M
Specific corporate
functionality: see chapter 2.4
(A conditional rule mandates
the ordering customer in the
MT 101 in either sequence A
or sequence B.)
A or D
O
Specific bank functionality: see
chapter 3.1
O
Specific corporate
functionality: see chapter 2.5
O
Identical
21
Transaction Reference
16x
M
Not present
Only present in the MT 101
due to the multiple character of
the message. Used to identify
the individual transaction in a
batch.
21F
F/X Deal Reference
16x
O
Not present
Specific corporate
functionality: see chapter 2.8
Standards MT Migration Guide v1.0
22/01/2009
6
Differences between MT 101 and MT 103
----->
13C
Time Indication
Not present
/8c/4!n1!x4!n
O
Specific bank functionality: see
chapter 3.2
Bank Operation Code
Not present
4!c
M
Specific bank functionality: see
chapter 3.3
Instruction Code
4!c[/30x]
4!c[/30x]
O
Whilst the structure and name
of this field is identical in both
messages, its content and
usage differs. The specific
corporate functionality is
explained in chapter 2.9. The
specific bank functionality is
explained in chapter 3.4.
26T
Transaction Type Code
Not present
3!c
O
Specific bank functionality: see
chapter 3.5
32A
Value
Date/Currency/Interba
nk Settled Amount
Not present
6!n3!a15d
M
Specific bank functionality: see
chapter 3.6
32B
Currency/Transaction
Amount
3!a15d
M
Not present
Specific corporate
functionality: see chapter 2.10
50a
Instructing Party
C or L
O
Not present
Specific corporate
functionality: see chapter 2.3
50a
Ordering Customer
50a
Ordering Customer
F, G, or H
52a
Ordering Institution
Not present
52a
Account Servicing
Institution
A or C
53a
Sender's
Correspondent
Not present
A, B, or D
O
54a
Receiver's
Correspondent
Not present
A, B, or D
O
55a
Third Reimbursement
Institution
Not present
A, B, or D
O
56a
Intermediary
A, C, or D
A, C, or D
O
-----|
23B
----->
23E
O
-----|
Standards MT Migration Guide v1.0
A, F, or K
M
Specific corporate
functionality: see chapter 2.4
(A conditional rule mandates
the ordering customer in the
MT 101 in either sequence A
or sequence B.)
A or D
O
Specific bank functionality: see
chapter 3.1
O
O
O
Not present
22/01/2009
Specific corporate
functionality: see chapter 2.5
Specific bank functionality: see
chapter 3.7
This field is identical in both
messages, except for the code
//RT: see chapter 3.8.
7
Differences between MT 101 and MT 103
57a
Account With
Institution
A, B, C, or D
O
Although the MT 103 has an
additional format option for
this field, its usage is identical
in both messages, except for
the code //RT: see chapter 3.8.
57a
Account With
Institution
A, C, or D
O
59a
Beneficiary
No letter
option or A
M
No letter
option or A
M
Identical
70
Remittance
Information
4*35x
O
4*35x
O
Identical
77B
Regulatory Reporting
3*35x
O
3*35x
O
Identical
33B
Currency/Instructed
Amount
3!a15d
O
Specific bank functionality: see
chapter 3.9
33B
Currency/Original
Ordered Amount
3!a15d
O
71A
Details of Charges
3!a
M
3!a
25A
Charges Account
/34x
O
Not present
36
Exchange Rate
12d
O
12d
O
Although format and name of
the field are identical, the
interpretation in a corporate or
interbank space is slightly
different. For the specific
corporate functionality: see
chapter 2.8. The bank
functionality is explained in
chapter 3.10.
Sender's Charges
Not present
3!a15d
O
Specific bank functionality: see
chapter 3.11
71G
Receiver's Charges
Not present
3!a15d
O
Specific bank functionality: see
chapter 3.11
72
Sender to Receiver
Information
Not present
6*35x
O
Specific bank functionality: see
chapter 3.12
77T
Envelope Contents
Not present
9000z
O
Specific bank functionality: see
chapter 3.13
Specific corporate
functionality: see chapter 2.10
M
Identical
Specific corporate
functionality: see chapter 2.11
----->
71F
-----|
-----| End of Sequence B Transaction Details for MT 101
Standards MT Migration Guide v1.0
22/01/2009
8
Specific corporate functionality in MT 101
2 Specific corporate functionality in MT 101
This chapter explains item per item the specific corporate functionality in the MT 101, Request
for Transfer message. None of this functionality is available in the MT 103, Single Customer
Credit Transfer.
Each of the features is clarified with a real MT 101 business example. Except for chapters 2.3
and 2.5, the scenario for which this example is given is always the same. It is a ‘direct
scenario’ where the head office is the account owner and sends the MT 101 message on its
own behalf, as illustrated below:
2.1 Possibility to combine multiple transactions in a single message,
potentially resulting into a single debit (field 21R)
Compared to the MT103, the MT 101 is a multiple message. It allows for requesting multiple
credit transfers. When multiple transactions are batched into a single MT 101 message, it is
possible to request a single debit entry on the account. Furthermore, when the size limitation
to 10K of the SWIFTNet FIN messaging service is too limiting, it is possible to chain MT 101
messages together (see chapter 2.2).
Batching multiple transactions together is only possible when all transactions are in the same
currency and need to be executed on the same date.
When the Instructing Party (see chapter 2.3), the Ordering Customer (and his account – see
chapter 2.4) and/or the Account Servicing Institution (see chapter 2.5) are identical for all
individual transactions in the batch, they only have to be mentioned once in the generic
sequence A of the MT 101. If one of these parties differs in one or more of the transactions,
the party has to be identified in each single transaction in the repetitive sequence B of the MT
101.
When a field 21R, Customer Specified Reference, is present, the ordering customer requests
a single debit entry for the sum of the amounts of all transactions, even if these transactions
are chained in several messages. If the field is not used, all debit items are posted
individually, ie, one debit entry per transaction.
Example single payment
Narrative
PlantOil has concentrated its treasury cash management functions in its head office, PlantOil
Company (PLATUS33) in Los Angeles, California. Plantoil Company wants 118,982.05 USD
to be paid to Wung Lu Manufacturing at BBBBCNBJ (account number 60648929889) in
Beijing, China. As the transaction is in USD, PlantOil sends the MT 101 to its USD bank,
AAAAUS33. Its account to be debited with AAAAUS33 is 1234567891.
The resulting SWIFT message is:
Explanation
Format
Header
Sender
PLATUS33
Message Type
101
Receiver
AAAAUS33
Standards MT Migration Guide v1.0
22/01/2009
9
Specific corporate functionality in MT 101
Message text
Sequence A General Information
Sender’s Reference
:20:PLANT-12345
Message Index/Total
:28D:1/1
Ordering Customer
:50G:/1234567891
PLATUS33
Requested Execution Date
:30:090929
Repetitive Sequence B - Transaction Details
Transaction Reference
:21:TR1-PL
Currency/Transaction amount
:32B:USD118982,05
Account With Institution
:57A:BBBBCNBJ
Beneficiary
:59:/60648929889
WUNG LU MANUFACTURING
23 XIAN MEN WAI AVE
BEIJING
Details of charges
:71A:SHA
Example multiple payment
Narrative
PlantOil has concentrated its treasury cash management functions in its head office, PlantOil
Company (PLATUS33) in Los Angeles, California. As the transactions are in USD, PlantOil
sends the MT 101 to its USD bank, AAAAUS33. Its account to be debited with AAAAUS33 is
1234567891
Payment details
•
1st transaction for 118,982.05 USD to Wung Lu Manufacturing at BBBBCNBJ
(account number 60648929889) in Beijing, China.
•
2nd transaction for 50,000 USD, to Tristan Recording Studios at CCCCGB2L (account
0010499) in London, GB.
•
3rd transaction for 377,250 USD, to River Paper Company at DDDDUS33 (account
number 26351-38947) in San Francisco, CA, US.
Information flow
Scenario 1, resulting in a single debit entry
PlantOil would like to see 1 batched entry on its account for the different transactions.
The resulting SWIFT message is:
Standards MT Migration Guide v1.0
22/01/2009
10
Specific corporate functionality in MT 101
Explanation
Format
Header
Sender
PLATUS33
Message Type
101
Receiver
AAAAUS33
Message text
Sequence A General Information
Sender’s Reference
:20:PLANT-12345
Customer Specified Reference*
:21R:PLTOL101-56
Message Index/Total
:28D:1/1
Ordering Customer
:50G:/1234567891
PLATUS33
Requested Execution Date
:30:090929
Repetitive Sequence B - Transaction Details 1
Transaction Reference
:21:TR1-PL
Currency/Transaction amount
:32B:USD118982,05
Account With Institution
:57A:BBBBCNBJ
Beneficiary
:59:/60648929889
WUNG LU MANUFACTURING
23 XIAN MEN WAI AVE
BEIJING
Details of charges
:71A:SHA
Repetitive Sequence B - Transaction Details 2
Transaction Reference
:21:TR2-PL
Currency/Transaction amount
:32B:USD50000,
Account With Institution
:57A:CCCCGB2L
Beneficiary
:59:/0010499
TRISTAN RECORDING STUDIOS
35 SURREY ROAD
GB-BROMLEY, KENT
Details of charges
:71A:SHA
Repetitive Sequence B - Transaction Details 3
Transaction Reference
:21:TR3-PL
Currency/Transaction amount
:32B:USD377250,
Account With Institution
:57A:DDDDUS33
Beneficiary
:59:/26351-38947
RIVER PAPER COMPANY
37498 STONE ROAD
US - SAN RAMON, CA
Details of charges
:71A:SHA
Note
* = field 21R, Customer Specified Reference, is used to indicate that the customer
requests a single debit entry (batch booking) for all the transactions contained in
the MT 101.
Standards MT Migration Guide v1.0
22/01/2009
11
Specific corporate functionality in MT 101
Scenario 2, resulting in individual debit entries for each transaction
PlantOil would like to see separate entries on its account for the different transactions.
The resulting SWIFT message is:
Explanation
Format
Header
Sender
PLATUS33
Message Type
101
Receiver
AAAAUS33
Message text
Sequence A General Information
Sender’s Reference
:20:PLANT-12345
Message Index/Total
:28D:1/1
Ordering Customer
:50G:/1234567891
PLATUS33
Requested Execution Date
:30:090929
Repetitive Sequence B - Transaction Details 1
Transaction Reference
:21:TR1-PL
Currency/Transaction amount
:32B:USD118982,05
Account With Institution
:57A:BBBBCNBJ
Beneficiary
:59:/60648929889
WUNG LU MANUFACTURING
23 XIAN MEN WAI AVE
BEIJING
Details of charges
:71A:SHA
Repetitive Sequence B - Transaction Details 2
Transaction Reference
:21:TR2-PL
Currency/Transaction amount
:32B:USD50000,
Account With Institution
:57A:CCCCGB2L
Beneficiary
:59:/0010499
TRISTAN RECORDING STUDIOS
35 SURREY ROAD
GB-BROMLEY, KENT
Details of charges
:71A:SHA
Repetitive Sequence B - Transaction Details 3
Transaction Reference
:21:TR3-PL
Currency/Transaction amount
:32B:USD377250,
Account With Institution
:57A:DDDDUS33
Beneficiary
:59:/26351-38947
RIVER PAPER COMPANY
37498 STONE ROAD
US - SAN RAMON, CA
Details of charges
:71A:SHA
Standards MT Migration Guide v1.0
22/01/2009
12
Specific corporate functionality in MT 101
Note
The absence of field 21R, Customer Specified Reference, indicates that the
customer requests separate debit entries (individual bookings) for all the
transactions contained in the MT 101.
2.2 Possibility to chain multiple messages (field 28D)
The MT 101 allows to chain several messages together in order to work around the
SWIFTNet FIN message size limitation of 10K. By using field 28D, Message Index/Total, the
sender can indicate that a message is part of a chain and should be processed as such. The
Message Index and the Total allow the receiver to control the presence and the sequence of
each single transaction in the series of chained messages.
If several messages are chained together, all information in the generic sequence A must be
repeated and be identical for all messages of the chain (even the Sender’s Reference!)
If several messages are chained, and a Customer Specified Reference is present to request a
single debit entry (see chapter 2.1), all transactions of all chained messages must be in the
same currency.
For a single message, which is not part of a chain, field 28D, Message Index/Total, equals
“1/1”.
Example
Narrative
PlantOil has concentrated its treasury cash management functions in its head office, PlantOil
Company (PLATUS33) in Los Angeles, California. As the transactions are in USD, PlantOil
sends (the) MT 101(s) to its USD bank, AAAAUS33. Its account to be debited with
AAAAUS33 is 1234567891.
Payment details
•
1st transaction for 1,000 USD to Wung Lu Manufacturing at BBBBCNBJ (account
number 60648929889) in Beijing, China.
•
2nd transaction for 2,000 USD, to Tristan Recording Studios at CCCCGB2L (account
0010499) in London, GB.
•
....
•
nth transaction for 34,000 USD, to River Paper Company at DDDDUS33 (account
number 26351-38947) in San Francisco, CA, US.
Information flow
Standards MT Migration Guide v1.0
22/01/2009
13
Specific corporate functionality in MT 101
Scenario 1, where all n transactions fit into one single MT 101
The resulting SWIFT message is:
Explanation
Format
Header
Sender
PLATUS33
Message Type
101
Receiver
AAAAUS33
Message text
Sequence A General Information
Sender’s Reference
:20:PLANT-12345
Message Index/Total*
:28D:1/1
Ordering Customer**
:50G:/1234567891
PLATUS33
Requested Execution Date
:30:090929
Repetitive Sequence B - Transaction Details 1
Transaction Reference
:21:TR1-PL
Currency/Transaction amount
:32B:USD1000,
Account With Institution
:57A:BBBBCNBJ
Beneficiary
:59:/60648929889
WUNG LU MANUFACTURING
23 XIAN MEN WAI AVE
BEIJING
Details of charges
:71A:SHA
Repetitive Sequence B - Transaction Details 2
Transaction Reference
:21:TR2-PL
Currency/Transaction amount
:32B:USD2000,
Account With Institution
:57A:CCCCGB2L
Beneficiary
:59:/0010499
TRISTAN RECORDING STUDIOS
35 SURREY ROAD
GB-BROMLEY, KENT
Details of charges
:71A:SHA
...
Repetitive Sequence B - Transaction Details n
Transaction Reference
:21:TRn-PL
Currency/Transaction amount
:32B:USD34000,
Account With Institution
:57A:DDDDUS33
Beneficiary
:59:/26351-38947
RIVER PAPER COMPANY
37498 STONE ROAD
US - SAN RAMON, CA
Details of charges
:71A:SHA
Note
* = field 28D, Message Index/Total, indicates that the MT 101 is not part of a chain
of messages.
Standards MT Migration Guide v1.0
22/01/2009
14
Specific corporate functionality in MT 101
Scenario 2, where all n transactions do not fit into one single MT 101
The number of transactions (n) is too large to fit into one single MT 101 and requires x
messages.
The resulting SWIFT message 1 is:
Explanation
Format
Header
Sender
PLATUS33
Message Type
101
Receiver
AAAAUS33
Message text
Sequence A General Information
Sender’s Reference **
:20:PLANT-12345
Message Index/Total *
:28D:1/x
Ordering Customer
:50G:/1234567891
PLATUS33
Requested Execution Date
:30:090929
Repetitive Sequence B - Transaction Details 1
Transaction Reference
:21:TR1-PL
Currency/Transaction amount
:32B:USD1000,
Account With Institution
:57A:BBBBCNBJ
Beneficiary
:59:/60648929889
WUNG LU MANUFACTURING
23 XIAN MEN WAI AVE
BEIJING
Details of charges
:71A:SHA
Repetitive Sequence B - Transaction Details 2
Transaction Reference
:21:TR2-PL
Currency/Transaction amount
:32B:USD2000,
Account With Institution
:57A:CCCCGB2L
Beneficiary
:59:/0010499
TRISTAN RECORDING STUDIOS
35 SURREY ROAD
GB-BROMLEY, KENT
Details of charges
:71A:SHA
....
...
The resulting SWIFT message x is:
Explanation
Format
Header
Sender
PLATUS33
Message Type
101
Receiver
AAAAUS33
Standards MT Migration Guide v1.0
22/01/2009
15
Specific corporate functionality in MT 101
Message text
Sequence A General Information
Sender’s Reference **
:20:PLANT-12345
Message Index/Total *
:28D:x/x
Ordering Customer **
:50G:/1234567891
PLATUS33
Requested Execution Date **
:30:090929
...
Repetitive Sequence B - Transaction Details n
Transaction Reference
:21:TRn-PL
Currency/Transaction amount
:32B:USD34000,
Account With Institution
:57A:DDDDUS33
Beneficiary
:59:/26351-38947
RIVER PAPER COMPANY
37498 STONE ROAD
US - SAN RAMON, CA
Details of charges
:71A:SHA
Note
* = field 28D, Message Index/Total, indicates the position of the MT 101 in the
chain of x MT 101 messages.
Note
** = field 20, Sender’s Reference, as well as any other field in sequence A, must
be the same for all messages that are part of the chain.
2.3 Possibility to identify an instructing party (field 50a, Instructing
Party)
Besides the Ordering Customer, who is always the owner of the account to be debited, the
MT 101 allows to identify an additional party that instructs the payment. Identification of this
additional party may be important for the beneficiary customer of the transaction, in order to
identify the commercial counterparty it has been dealing with.
Typically, the instructing party is used to identify a subsidiary on whose behalf the account
owning head-office is requesting the payment. Or vice versa, the instructing party identifies
the head-office, who requests the payment on behalf of the account owning subsidiary. The
actual sender of the MT 101 might still be another entity.
Whether the MT 101 is sent by the account owner (Ordering Customer) or by another party
authorised to order the debit of the ordering customer’s account (Instructing Party),
agreements between the customer parties and the receiving bank must be in place.
If in a corporate to bank environment, the instructing party is the sender of the message, it is
preferably identified with its BEI in field 50C, Instructing Party.
If the ordering customer is also the instructing party, it must not be repeated in this field.
The following diagram shows which customer parties can be identified:
Standards MT Migration Guide v1.0
22/01/2009
16
Specific corporate functionality in MT 101
Note
In case 2 and 3, the actor ‘head-office’ can be one and the same as ‘payments
factory’ or ‘shared service centre’.
The roles illustrated in the diagram also apply to the relay scenario (see chapter
2.1).
The different scenarios are illustrated in the Business Examples section of the
“SWIFT for Corporates – Standards MT Message Implementation Guide”.
Example 1, Head office paying from own account on behalf of its subsidiary
Narrative
PlantOil has concentrated its treasury cash management functions in its head office, PlantOil
Company (PLATUS33) in Los Angeles, California. All wire transfer transactions ordered by
PlantOil’s subsidiaries – such as PlantOilAxim, PlantOilProductions – are sent by PlantOil
Company to its various banks, where PlantOil Company owns master concentration accounts.
On behalf of PlantOilAxim, Plantoil Company wants 118,982.05 USD to be paid to Wung Lu
Manufacturing at BBBBCNBJ (account number 60648929889) in Beijing, China. As the
transaction is in USD, PlantOil sends the MT 101 to its USD bank, AAAAUS33. Its account to
be debited with AAAAUS33 is 1234567891.
The resulting SWIFT message is:
Explanation
Format
Header
Sender*
Standards MT Migration Guide v1.0
PLATUS33
22/01/2009
17
Specific corporate functionality in MT 101
Message Type
101
Receiver
AAAAUS33
Message text
Sequence A General Information
Sender’s Reference
:20:PLANT-12345
Message Index/Total
:28D:1/1
Instructing Party**
:50L: PLANTOIL AXIM
Ordering Customer*
:50G:/1234567891
PLATUS33
Requested Execution Date
:30:090929
Repetitive Sequence B - Transaction Details 1
Transaction Reference
:21:TR1-PL
Currency/Transaction amount
:32B:USD118982,05
Account With Institution
:57A:BBBBCNBJ
Beneficiary
:59:/60648929889
WUNG LU MANUFACTURING
23 XIAN MEN WAI AVE
BEIJING
Remittance Information
:70:/INST/PLANTOIL AXIM
Details of charges
:71A:SHA
Note
* The head office sends the message and is also the account owner (Ordering
Customer)
Note
** PLATUS33 can also repeat the instructing party, PlantOil Axim, preceded by
code /INST/ in field 70 - as it is not possible to transport the dedicated Instructing
Party field in the interbank clearing and settlement part of the chain. As PlantOil
Axim is the original receiver of the invoice, this information may be useful to allow
reconciliation by the beneficiary customer.
Example 2, Head office paying from a subsidiary account
Narrative
Springs Inc head office (SPRNGB2L) wants to pay an invoice in GBP from its subsidiary’s
account. Both Springs Inc head office and Springs branch have accounts at the same bank
(AAAAGB2L). Springs Inc head office is authorised to make payments from the accounts of
its subsidiaries.
Springs Inc head office sends the MT 101 to AAAAGB2L, asking it to debit the account of
Springs Brighton branch (9876543).
The resulting SWIFT message is:
Explanation
Standards MT Migration Guide v1.0
Format
22/01/2009
18
Specific corporate functionality in MT 101
Header
Sender*
SPRNGB2L
Message Type
101
Receiver
AAAAGB2L
Message text
Sequence A General Information
Sender’s Reference
:20:SPRING-01
Message Index/Total
:28D:1/1
Instructing party**
:50C:SPRNGB2L
Ordering Customer
:50H:/9876543
SPRINGS BRANCH
LEICESTER AVENUE
GB-BRIGHTON
Requested Execution Date
:30:090929
Repetitive Sequence B - Transaction Details 1
Transaction Reference
:21:SPRING-01
Currency/Transaction amount
:32B:GBP1000,
Account With Institution
:57A:CCCCGB2L
Beneficiary
:59:/GB1111111
THOMPSON FACTORY
GB-LIVERPOOL
Remittance Information
:70:/INST/SPRNGB2L
Details of charges
:71A:SHA
Note
* The head office sends the message and is also the instructing party.
Note
** Springs Inc can also repeat itself, the instructing party, preceded by code /INST/
in this field - as it is not always possible to transport the dedicated Instructing
Party field in the interbank clearing and settlement part of the chain. As Springs
Inc was the receiver of the original invoice, this information may be useful to allow
reconciliation by the beneficiary customer.
Example 3, Shared service centre sending the payment instruction
A shared service centre or payments factory sends the MT 101 message; it is not the account
owner, nor the instructing party of the payment transactions as illustrated in the following
diagram:
Standards MT Migration Guide v1.0
22/01/2009
19
Specific corporate functionality in MT 101
Narrative
BioGen head office has concentrated its treasury cash management functions. It concentrates
all payments from its branches, BioGen France and BioGen Hong Kong, and owns master
concentration accounts at various banks across the world. In order to send its payment
instructions, it uses its shared service centre, BIOGNL2A. Appropriate agreements have been
put in place between BioGen head office, BIOGNL2A and the banks servicing the accounts
for BioGen.
As the transactions are in USD, BIOGNL2A will send the MT 101 to BioGen head office’s
USD bank, AAAAUS33, using BioGen account: 12345.
Payment details:
•
On behalf of BioGen France, for 30,000 USD to El Puerto Productions, Mexico, that
has account 11111 at BBBBMXMM.
•
On behalf of BioGen Hong Kong, for 20,000 USD, to BioWorld, New Jersey, US, that
has account 22222 at CCCCUS33.
The resulting SWIFT message is:
Explanation
Format
Header
Sender*
BIOGNL2A
Message Type
101
Receiver
AAAAUS33
Message text
Sequence A General Information
Sender’s Reference
:20:BIO-123
Message Index/Total
:28D:1/1
Ordering Customer*
:50H:/12345
BIOGEN US
CA-SAN FRANCISCO
Requested Execution Date
:30:090929
Repetitive Sequence B - Transaction Details 1
Transaction Reference
:21:TR1-BIOG
Currency/Transaction amount
:32B:USD30000,
Instructing Party*
:50L:BIOGEN FRANCE
Standards MT Migration Guide v1.0
22/01/2009
20
Specific corporate functionality in MT 101
Account With Institution
:57A:BBBBMXMM
Beneficiary
:59:/11111
EL PUERTO PRODUCTIONS
AVENIDA CORAL
MEXICO
Details of charges
:71A:SHA
Repetitive Sequence B - Transaction Details 2
Transaction Reference
:21:TR2-BIOG
Currency/Transaction amount
:32B:USD20000,
Instructing Party *
:50L: BIOGEN HONG KONG
Account With Institution
:57A:CCCCUS33
Beneficiary
:59:/22222
BIOWORLD
US-NEW JERSEY,NJ
Details of charges
:71A:SHA
Note
* The payments factory BIOGNL2A instructs payments from the account of the
head office BIOGEN US (Ordering Customer) on behalf of both subsidiaries.
2.4 Identification of the ordering customer’s account (field 50a,
Ordering Customer)
For the ordering customer’s account, there are two corporate specific functionalities in the
MT 101, which the MT 103 does not cater for:
1.
The identification of the ordering customer’s account is mandatory in the MT 101.
When requested to make a credit transfer, it is key for the servicing institution to be
instructed which account needs to be debited. When an inter-bank MT 103 payment
instruction is sent to the next party in the transaction chain, the ordering customer has not
necessarily been using an account. The transfer might have been initiated by a cash
deposit at the counter. In those cases, there is no account number to identify the
customer.
2.
Because the MT 101 is a multiple message, it is possible to identify different accounts
from which these transactions are to be debited. If that is the case, the field 50a, Ordering
Customer, has to be repeated in each sequence B, with the relevant account number for
each of the transactions. The field 50a, Ordering Customer in the generic sequence A is
not to be used in this scenario.
If in a corporate to bank environment, the ordering customer is also the sender of the
message, it is preferably identified with its BEI in field 50G, Ordering Customer.
Example
Narrative
PlantOil Company (PLATUS33) in Los Angeles, California sends two USD transactions in an
MT 101 to its USD bank, AAAAUS33. Both transactions are to be debited from different
accounts with AAAAUS33.
Payment details
•
1st transaction for 118,982.05 USD to Wung Lu Manufacturing at BBBBCNBJ
(account number 60648929889) in Beijing, China is to be debited from account
12345.
•
2nd transaction for 50,000 USD, to Tristan Recording Studios at CCCCGB2L (account
0010499) in London, GB is to be debited from account 67890.
The resulting SWIFT message is:
Standards MT Migration Guide v1.0
22/01/2009
21
Specific corporate functionality in MT 101
Explanation
Format
Header
Sender
PLATUS33
Message Type
101
Receiver
AAAAUS33
Message text
Sequence A General Information
Sender’s Reference
:20:PLANT-12345
Message Index/Total
:28D:1/1
Requested Execution Date
:30:090929
Repetitive Sequence B - Transaction Details 1
Transaction Reference
:21:TR1-PL
Currency/Transaction amount
:32B:USD118982,05
Ordering Customer*
:50G:/12345
PLATUS33
Account With Institution
:57A:BBBBCNBJ
Beneficiary
:59:/60648929889
WUNG LU MANUFACTURING
23 XIAN MEN WAI AVE
BEIJING
Details of charges
:71A:SHA
Repetitive Sequence B - Transaction Details 2
Transaction Reference
:21:TR2-PL
Currency/Transaction amount
:32B:USD50000,
Ordering Customer*
:50G:/67890
PLATUS33
Account With Institution
:57A:CCCCGB2L
Beneficiary
:59:/0010499
TRISTAN RECORDING STUDIOS
35 SURREY ROAD
GB-BROMLEY, KENT
Details of charges
:71A:SHA
Note
*.As 2 different account numbers belonging to PlantOil Company have to be used,
the ordering customer is identified in each of the transaction details sequences
with the relevant account number to be debited.
2.5 Possibility to identify an institution, servicing the ordering
customer’s account, other than the receiver (field 52a)
The sender of the MT 101 is never the account servicing institution, whether the message is
used in corporate to bank (direct or relay) scenario or in an inter-bank (relay) scenario. The
institution servicing the account of the ordering customer is by default the receiver of the MT
101. If this is not the case though (eg, the first MT 101 message in a relay scenario), the MT
101 offers the possibility to identify in field 52a, Account Servicing Institution, another
institution where the account is serviced.
Standards MT Migration Guide v1.0
22/01/2009
22
Specific corporate functionality in MT 101
In the majority of cases, in the corporate to bank environment, the receiver of the MT 101 is
also the institution servicing the account for the sending/ordering parties of the MT 101. In this
case, field 52a is not needed. If however, in a ‘relay’ scenario (see chapter 2.1), the
corporate is sending the MT 101 to its concentrating bank, which offers a multi-bank service
and will forward the MT 101 to the account servicing bank of the corporate, then this
institution needs to be identified in field 52a. This account servicing Institution may be a
branch or the head-office of the receiver, but in a relay scenario, it is often a complete
different institution. The necessary agreements always have to be in place between ordering
customer, account servicing institution and receiving institution to debit the account. The
identification should in any case be meaningful to the receiver, hence the limited number of
format possibilities for this field.
The field 52a, Ordering Institution, in the MT 103 has a complete different meaning. The field
52a in the MT 103 identifies the account servicing institution of the ordering customer through
which the credit transfer has originally been instructed. It is the first financial institution in the
credit transfer chain and is identified in the transaction in case a payment has to be returned.
Example
Narrative
Springs Inc head office (SPRNGB2L) is centralising all payments, and is authorised to use the
accounts of its branches. All instructions are given to Springs Inc’s main banker AAAAGB2L,
who takes care of forwarding the instructions to the different account servicing institutions.
A payment in euros is to be made. Springs Inc’s branch in Germany owns a EUR account
(DE34567890) with BBBBDEFF.
In this case, Springs Inc would send an MT 101 to AAAAGB2L and request AAAAGB2L to
forward the MT 101 to the German bank (BBBBDEFF).
Information flow
The resulting SWIFT message is:
Explanation
Format
Header
Sender
SPRNGB2L
Message Type
101
Receiver
AAAAGB2L
Message text
Sequence A General Information
Sender’s Reference
:20:SPRING-01
Message Index/Total
:28D:1/1
Instructing party*
:50C:SPRNGB2L
Standards MT Migration Guide v1.0
22/01/2009
23
Specific corporate functionality in MT 101
Ordering Customer*
:50H:/DE34567890
SPRINGS BRANCH
ZEIL 5
DE-FRANKFURT
Account Servicing Institution*
:52A:BBBBDEFF
Requested Execution Date
:30:090929
Repetitive Sequence B - Transaction Details 1
Transaction Reference
:21:SPRING-01
Currency/Transaction amount
:32B:EUR1000,
Account With Institution
:57A:DDDDDEFF
Beneficiary
:59:/DE12345678912345678912
MULLER
DE-FRANKFURT
Details of charges
:71A:SHA
Note
*. Upon receipt of this MT 101, AAAAGB2L will forward the same MT 101 to
BBBBDEFF. Upon receipt of the second MT 101, BBBBDEFF will debit the
account of Springs Branch, Frankfurt, and execute the payment.
2.6 Identification of the requested execution date (field 30)
Field 30 of the MT 101, Request for Transfer, contains the date that the ordering customer (or
the instructing party) is requesting the payment to be executed, ie, debited from ordering
customer’s account. Any other date (value date, beneficiary’s credit date, etc... ) is subject to
customer to bank agreements and service levels.
In case the MT 101 is batching multiple instructions together, the same requested execution
date applies to all instructions. A different execution date requires a new MT 101 message.
The similar date in the MT 103 (in field 32A) specifies the inter-bank value date, which is
always defined between a sending institution and the next party in the transaction chain, be it
a correspondent bank or a clearing system.
2.7 Possibility to provide an electronic signature (field 25)
Account servicing institutions often require ordering customers to provide additional security
features on their payment instructions. The field 25, Authorisation, in the MT 101 allows for
providing for instance an electronic signature.
2.8 Identification of an exchange rate and an F/X deal (field 21F)
Only when the Transaction Amount (field 32B) and the Instructed Amount (field 33B) are both
present and different from 0, the Ordering Customer/Instructing Party is allowed, even
obliged, to provide the Exchange Rate (field 36) and the F/X Deal Reference (field 21F).
In all other situations, it is forbidden to provide an Exchange Rate (field 36).
An F/X Deal (field 21F), without the Exchange Rate, may further be mentioned if:
1.
the customer instructs the payment of an equivalent amount by means of the code EQUI
in field 23E (see chapter 2.10), or
2.
a Transaction Amount (field 32B) is given without Instructed Amount (field 33B) or
Exchange Rate (field 36).
Standards MT Migration Guide v1.0
22/01/2009
24
Specific corporate functionality in MT 101
Compared to the MT103, where no F/X deal can be identified, the exchange rate in an
MT 101 is still to be applied by the bank. An exchange rate in an MT 103 has been applied to
the transaction already and is provided for information and transparency purposes only.
Example of a transaction with an instructed amount
Narrative
OneCapital has to pay an invoice of 10,000,000 JPY to the account of Harizumo
Manufacturing at BBBBJPJT (account number 60648929889) in Tokyo, Japan. They pay from
their USD account 1234567891 with CHASUS33. They agree with their account servicing
institution, CHASUS33, on an exchange rate of 107.833, resulting in an amount of 92,735.99
USD that will be debited from their USD account (not taking into account possible charges)
and reflected in the statement sent to them. This amount is therefore included as original
ordered amount. The amount and currency to be paid is quoted in transaction amount in the
MT 101. The reference for this F/X Deal is 2736ONCE44.
The resulting SWIFT message is:
Explanation
Format
Header
Sender
ONECUS44
Message Type
101
Receiver
CHASUS33
Message text
Sequence A General Information
Sender’s Reference
:20:AA87999BM
Message Index/Total
:28D:1/1
Ordering Customer
:50G:/1234567891
ONECUS44
Requested Execution Date
:30:090123
Repetitive Sequence B - Transaction Details 1
Transaction Reference
:21:TR1-ONECAP/4475
F/X Deal Reference
:21F: 2736ONEC44
Currency/Transaction amount
:32B:JPY10000000,
Account With Institution
:57A:BBBBJPJT
Beneficiary
:59:/60648929889
Harizumo Manufacturing
Currency/Original Ordered Amount
:33B: USD92735,99
Details of charges
:71A:SHA
Exchange Rate
:36:107,833
2.9 Possibility to provide corporate-specific instructions (codes in
field 23E)
The field 23E, Instruction Code, allows customers to provide in a structured and STP-able
manner the most common instructions to the receiver of the MT 101, Request for Transfer.
Although the field 23E is also present in the inter-bank MT 103, the available instruction
codes are often different in both messages. The following codes are only present in the MT
101:
Standards MT Migration Guide v1.0
22/01/2009
25
Specific corporate functionality in MT 101
Instruction Code
MT 101
MT 103
Remarks
CMSW
X
Cash Management instruction on the
ordering customer’s account. When these
codes are used, cash management
agreements between corporate and bank
apply, which may justify a zero transaction
amount in field 32B.
CMTO
X
CMZB
X
EQUI
X
This code request for the transfer of an
amount, equivalent to the value specified in
field 33B, Original Ordered Amount. It
mandates the Transaction Amount in field
32B to be zero (see chapter 2.10)
NETS
X
This code requests for routing through a
netting system. It therefore only triggers a
routing decision by the next party in the
transaction; it does not impact the content of
the next message; it does not have an
equivalent code in the MT 103.
OTHR
X
This code can be used to provide any
additional bilaterally agreed information
PHON
X
RTGS
X
This code requests for routing through a
RTGS, and therefore may trigger a routing
decision by the next party in the transaction.
If the request is honoured, the bank may use
the codes //RT or //FW in the consecutive
MT 103 to forward the instruction to the
right RTGS participant.
URGP
X
As specified in the MT Implementation
Guide for corporates, a bank must be able to
accept the code “URGP” to indicate a
payment with a priority of urgent, however
the specific usage and interpretation of this
and the other instruction codes depends on
the agreement between the sender and
receiver.
X
Is translated into PHOB(!) in the MT 103
Example of a transaction with an equivalent amount
Narrative
OneCapital has to pay 10,000,000 USD to the account of Harizumo Manufacturing at
BBBBJPJT (account number 60648929889) in Tokyo, Japan. Harizumo wants to receive the
money in Japanese Yen. OneCapital pays from their USD account 1234567891 with
CHASUS33.
The resulting SWIFT message is:
Explanation
Format
Header
Sender
ONECUS44
Message Type
101
Standards MT Migration Guide v1.0
22/01/2009
26
Specific corporate functionality in MT 101
Receiver
CHASUS33
Message text
Sequence A General Information
Sender’s Reference
:20:AA87999BM
Message Index/Total
:28D:1/1
Ordering Customer
:50G:/1234567891
ONECUS44
Requested Execution Date
:30:090123
Repetitive Sequence B - Transaction Details 1
Transaction Reference
:21:TR1-ONECAP/4475
Instruction Code*
:23E:EQUI
Currency/Transaction amount
:32B:JYP0,
Account With Institution
:57A:BBBBJPJT
Beneficiary
:59:/ 60648929889
Harizumo Manufacturing
Currency/Original Ordered Amount*
:33B:USD10000000,
Details of charges
:71A:SHA
Example of a zero-balancing transaction
Narrative
PlantOil has concentrated its treasury cash management functions in its head office, PlantOil
Company (PLATUS33) in Los Angeles, California. At the end of a day, Plantoil Company
wants to top its account 1234567891 with its bank AAAAUS33 to a pre-agreed threshold. The
concentrating account, to be credited, is 60648929889.
The resulting SWIFT message is:
Explanation
Format
Header
Sender
PLATUS33
Message Type
101
Receiver
AAAAUS33
Message text
Sequence A General Information
Sender’s Reference
:20:PLANT-12345
Message Index/Total
:28D:1/1
Ordering Customer
:50G:/1234567891
PLATUS33
Requested Execution Date
:30:090929
Repetitive Sequence B - Transaction Details
Transaction Reference
:21:TR1-PL
Instruction Code*
:23E:CMTO/USD1000000
Currency/Transaction amount
:32B:USD0,
Standards MT Migration Guide v1.0
22/01/2009
27
Specific corporate functionality in MT 101
Beneficiary
:59A:/60648929889
PLATUS33
Details of charges
:71A:SHA
Note
* The receiver of this message will top the account to 1MIO USD, ie, transfer
everything above this threshold from account 1234567891 to 60648929889.
2.10 Different ways to instruct an amount (fields 32B and 33B)
The MT 101 caters for two scenarios, which are typical in a corporate to bank environment:
1.
Cash management instructions: by specifying the relevant Instruction Code in field 23E
(CMSW, CMTO, CMZB), a corporate can request to sweep, top or zero balance its
account. In that case, pre-agreed service levels may apply and the corporate does not
necessarily have to specify the amount.
2.
Equivalent amount: by specifying the Instruction Code EQUI in field 23E, a corporate can
request to pay the equivalent of the Original Ordered Amount in field 33B, in the Currency
specified in field 32B. In that case, the Transaction Amount in field 32B has to equal 0
(zero). The currency codes in both amount fields always have to differ.
3.
EQUI is not to be used to pay an invoice in a different currency than the currency of the
account. In that scenario, the currency and amount of the invoice is just to be mentioned
as instructed amount. The bank will convert the amount into the currency of the account
before debiting the account. If pre-agreed between the corporate and the bank, the
instruction may contain the currency and amount to be debited from the account in field
33B. In so, the instruction must also specify the exchange rate used (in field 36) and the
related F/X deal (in field 21F). If the instruction does not contain the currency and
amount, it may still refer to a pre-agreed F/X deal in field 21F.
Note
Note: Users need to be aware that any amount specified in field 32B, Transaction
Amount, is subject for deduction of charges throughout the banking chain.
Depending on the charging method code, specified in field 71A, these charges
might be born by the ordering customer (potentially on a dedicated account – see
chapter 2.11) and/or by the beneficiary customer.
Example of a zero balancing transaction
See example 2 in chapter 2.9
Example of a transaction with an equivalent amount
See example 1 in chapter 2.9
Example of a transaction in a currency different from the currency of the account
See example in chapter 2.8
Example of a transaction in a currency different from the currency of the account
Narrative
OneCapital has to pay an invoice of 10,000,000 JPY to the account of Harizumo
Manufacturing at BBBBJPJT (account number 60648929889) in Tokyo, Japan. They pay from
their USD account 1234567891 with CHASUS33. They agree with their account servicing
institution, CHASUS33, on a fixed exchange rate. The reference for this F/X Deal is
2736ONCE44.
The resulting SWIFT message is:
Explanation
Format
Header
Sender
Standards MT Migration Guide v1.0
ONECUS44
22/01/2009
28
Specific corporate functionality in MT 101
Message Type
101
Receiver
CHASUS33
Message text
Sequence A General Information
Sender’s Reference
:20:AA87999BM
Message Index/Total
:28D:1/1
Ordering Customer
:50G:/1234567891
ONECUS44
Requested Execution Date
:30:090123
Repetitive Sequence B - Transaction Details 1
Transaction Reference
:21:TR1-ONECAP/4475
F/X Deal Reference
:21F: 2736ONEC44
Currency/Transaction amount
:32B:JPY10000000,
Account With Institution
:57A:BBBBJPJT
Beneficiary
:59:/60648929889
Harizumo Manufacturing
Details of charges
:71A:SHA
2.11 Possibility to identify a separate charges account (field 25A)
The MT 101 offers corporates the possibility to identify a separate account number to be used
to apply any transaction charges. When used, this account should be different from the debit
account of the ordering customer, specified in field 50a, Ordering Customer.
Example
Narrative
PlantOil has concentrated its treasury cash management functions in its head office, PlantOil
Company (PLATUS33) in Los Angeles, California. Plantoil Company wants 118,982.05 USD
to be paid to Wung Lu Manufacturing at BBBBCNBJ (account number 60648929889) in
Beijing, China. As the transaction is in USD, PlantOil sends the MT 101 to its USD bank,
AAAAUS33. Its account to be debited with AAAAUS33 is 1234567891. Any charges have to
be taken from the dedicated charges account 987654321.
The resulting SWIFT message is:
Explanation
Format
Header
Sender
PLATUS33
Message Type
101
Receiver
AAAAUS33
Message text
Sequence A General Information
Sender’s Reference
:20:PLANT-12345
Message Index/Total
:28D:1/1
Ordering Customer
:50G:/1234567891
PLATUS33
Requested Execution Date
:30:090929
Standards MT Migration Guide v1.0
22/01/2009
29
Specific corporate functionality in MT 101
Repetitive Sequence B - Transaction Details
Transaction Reference
:21:TR1-PL
Currency/Transaction amount
:32B:USD118982,05
Account With Institution
:57A:BBBBCNBJ
Beneficiary
:59:/60648929889
WUNG LU MANUFACTURING
23 XIAN MEN WAI AVE
BEIJING
Details of charges
:71A:SHA
Charges Account
:25A:/987654321
Standards MT Migration Guide v1.0
22/01/2009
30
How to handle MT 103 specific information in an MT 101
3 How to handle MT 103 specific information in an MT 101
For applications that migrate from the MT 103 to the MT 101, this chapter explains whether
and how to specify information that can be provided in an MT 103, and for which there is no
dedicated field in the MT 101. It also explains why certain information of the MT103 would be
absolutely redundant or misleading in a corporate to bank environment.
3.1 Ordering Institution (field 52a)
Since field 52a, ordering institution, in the MT 103 identifies the institution that services the
account of the ordering customer (in case that is different from the sender of the message),
there is no need to have this information in an MT 101. The receiver of the MT 101 (the
second MT 101 in case of a relay scenario) is always the “ordering institution” and will be
reflected as such in the inter-bank chain.
3.2 Time indications (field 13C)
The time indications in the MT 103 are very specifically used for the settlement of TARGET2
and CLS instructions. Therefore, there is no need to have this information in an MT 101.
3.3 Pre-signed service level agreements (field 23B)
The service levels identified in the MT 103 are agreements that are centrally registered by
SWIFT and that are contractually and multilaterally binding all subscribers to the service level.
The identification of the service level in the MT103 is necessary to identify which service level
applies to the individual instruction. Since there is only one type of service level agreement for
corporate to bank services, there is no need to have this information in an MT 101.
3.4 Bank specific instructions (codes in field 23E)
The Instruction Code allows customers to provide in a structured and STP-able manner the
most common instructions to the receiver of the MT 103. Although the Instruction Code field is
also present in the corporate-to-bank MT 101, it goes without saying that the available codes
are often different in both messages. The following codes are typical for interbank usage:
Instruction Code
MT 101
MT 103
Remarks
HOLD
X
Request the funds to be kept at the counter of
the beneficiary’s bank until the beneficiary
claims them with a valid identification.
There is no equivalent code in the MT 101.
PHOB
X
Requests to advise the beneficiary by phone.
Requesting to contact the beneficiary is done
in the MT 101 by the code PHON in field
23E.
PHOI
X
Requests to advise the intermediary bank by
phone.
It is not necessary for a corporate to instruct
its bank to contact one of the banks in the
transaction chain.
X
Requests to advise the beneficiary’s bank by
phone.
It is not necessary for a corporate to instruct
its bank to contact one of the banks in the
transaction chain.
The meaning of the code PHON in the
MT 101 is identical to the meaning of the
code PHOB in the MT 103
PHON
Standards MT Migration Guide v1.0
X
22/01/2009
31
How to handle MT 103 specific information in an MT 101
SDVA
X
Offering Same Day Value is part of a service
that a bank may offer to specific customers
for pre-defined instructions and fulfill preagreed conditions (eg, intracompany
payments identified by the code INTC in the
field 23E of the MT 101). It is therefore not
expected that a corporate may request for
Same Day Value per individual payment
instruction.
TELB
X
Requests to advise the beneficiary.
Requesting to contact the beneficiary is done
in the MT 101 by the code PHON in field
23E.
TELE
X
Requests to advise the beneficiary’s bank.
It is not necessary for a corporate to instruct
its bank to contact one of the banks in the
transaction chain.
TELI
X
Requests to advise the intermediary bank.
It is not necessary for a corporate to instruct
its bank to contact one of the banks in the
transaction chain.
3.5 Regulatory reporting codes (field 26T)
Some regulators offer their financial institution community a series of codes that can be used
to do their regulatory reporting. When a corporate is requested to provide information for the
regulators, the free format field 77B, which is available in both the MT 101 and MT 103, is to
be used.
3.6 Value date (field 32A)
The value date provided in an MT 103 is the effective value date that has been applied, or will
be applied to an amount of money that is exchanged between both banks. This is different
from a request for transfer, where any date would be a “requested” date, be it a requested
execution date like in the MT 101, or a requested debit value date like some banks offer as
part of their service level. Therefore, there is no need to have interbank value date information
in the MT 101.
3.7 Correspondent banks (fields 53a, 54a and 55a)
International payments can be made in two different ways:
•
Serial: each party in the payment transaction chain executes the payment instruction,
ie, posts an entry for the previous or the next party in the transaction chain in its
books, before forwarding the payment instruction to the next party in the chain until it
reaches the beneficiary. The MT 101 allows for specifying such an additional party in
the field 56a, Intermediary Institution. There are no “correspondent banks” present in
a serial scenario.
•
Cover: the ordering customer’s bank instructs the beneficiary’s bank to credit the
beneficiary, and informs this bank that their account with a correspondent will be
covered to do this credit transfer. This scenario is mostly used for payments in
currencies different from the currencies in the ordering or beneficiary’s countries. The
correspondent banks through which the cover payment is made are located abroad.
Which of both scenarios is used however, is the choice of the ordering customer’s bank and
depends on currencies, availability of liquidity, bank relationships, etc... Therefore, there is no
need to be able to identify correspondent cover banks in an MT 101.
Standards MT Migration Guide v1.0
22/01/2009
32
How to handle MT 103 specific information in an MT 101
3.8 Routing through an RTGS (codes in fields 56a and 57a)
The code //RT is available in an MT 103 to request a specific party in the chain to route a
payment through an RTGS system, most often an institution that offers as direct member of
that RTGS system its services to other banks.
A corporate can request a payment to be made through an RTGS system by using the code
RTGS in field 23E of the MT 101.
3.9 Transparency about the instructed amount (field 33B)
Compared to the “Original Ordered Amount” in the MT 101, the “Instructed Amount” in the MT
103 is purely for information purposes towards the beneficiary customer. Some jurisdictions
require the financial institutions to be transparent about the instructed amount, the applied
exchange rate and the charges that have been taken along the transaction chain. In an MT
101, the Original Ordered Amount might be present for more than just information, eg, for the
ordering of an equivalent amount (see chapter 2.10).
3.10 Applied exchange rate (field 36)
Compared to the “Exchange Rate” in the MT 101, the “Exchange Rate” in the MT 103 is
purely for information purposes towards the beneficiary customer. Some jurisdictions require
the financial institutions to be transparent about the instructed amount, the applied exchange
rate and the charges that have been taken along the transaction chain. In an MT101, the
Exchange Rate might be present for more than just information (see chapter 2.9).
3.11 Charges information (fields 71F and 71G)
Except for the instruction which charge method to use, there is no charges information
available in the MT 101. The “Sender’s Charges” in the MT 103 are purely for information
purposes towards the beneficiary customer. Some jurisdictions require the financial
institutions to be transparent about the instructed amount, the applied exchange rate and the
charges that have been taken along the transaction chain. The “Receiver’s Charges” inform
the receiving bank of the amount of money that has been added by the sending bank to the
transaction amount, in order for the receiver to execute the payment instruction.
3.12 Free format information to the receiver (field 72)
Whilst free format fields are present in most messages, it is well known that their use is
hampering Straight Through Processing. Free format fields require bilateral and/or multilateral
agreements. Newer standards therefore foresee dedicated fields for the most commonly used
functionality of the free format fields. The most commonly used functionality of field 72 has a
dedicated code or field in the MT 101. Any other bilaterally agreed instruction can follow the
code OTHR in field 23E in the MT 101.
Should there be any other requirement to transport a specific item of information, feel free to
contact the corporate representative at your nearest regional SWIFT office.
3.13 Large remittance information (field 77T)
An optional block of 9Kbyte of free format remittance information is available in one specific
variant of the MT 103 message. This option is not used a lot in practice, because such
amount of remittance information can hardly pass any domestic clearing system. Therefore,
the block has never been offered in an MT 101, Request for Transfer. Adding this functionality
to an international payment transaction chain would require financial institutions and clearing
systems to make so many changes that they preferred to consider this service as part of the
payment standard in XML (ISO 20022).
Standards MT Migration Guide v1.0
22/01/2009
33
How to handle MT 103 specific information in an MT 101
3.14 The resulting MT 103 to MT 101 conversion table
MT103
MT 101
S
R
S
R
20
13C
23B
20
21R
28D
50a
50a
52a
51A
30
25
23E
PHON
PHOB
TELB
26T
32A
33B
36
50a
51A
52a
53a
54a
55a
56a
21
21F
PHON
RTGS
OTHR
32B
50a
50a
52a
56a
57a
59a
70
77B
33B
71A
25A
36
//RT
57a
//RT
59a
70
71A
71F
71G
72
77B
77T
Standards MT Migration Guide v1.0
23E
22/01/2009
34
Differences between MT 940 and MT 950
4 Differences between MT 940 and MT 950
4.1 Scope and usage
In the bank-to-corporate environment, the ‘relay’ scenario is supported by the MT 940:
the forwarding institution forwards the MT 940 from the account servicing financial
institution to the corporate (the account owner, or the party authorised by the account
owner to receive the information).
In a bank-to-corporate environment however, the MT 940 is also to be used instead of
the MT 950 directly between the account servicing financial institution and the corporate
(the account owner, or the party authorised by the account owner to receive the
information).
In practice, this usage has been integrated already in a number of market practices. For
instance, the SEPA guidelines describe how to transport information about a SEPA
transfer in an account statement to the beneficiary. The guidelines specify to structure
the free format fields of the MT 940, because the MT 950 does not allow for including this
information.
4.2 Scenarios
4.2.1 MT 940 Customer Statement
As the MT 950 Statement message does not allow to transport the additional information that
typically needs to be reported on the entries of customer statements, the MT 940 is
recommended to be used in all situations as statement message towards corporate
customers, be it in a direct or a relay scenario.
4.2.2 MT 950 Statement
The MT 950, because of the limited possibilities to add additional information to the entries, is
only to be used for inter-bank reporting on nostro-vostro and clearing systems’ accounts.
Standards MT Migration Guide v1.0
22/01/2009
35
Differences between MT 940 and MT 950
4.3 Content
The below table compares the MT 940 with the MT 950. It identifies the differences and links
for each individual difference to a detailed explanation.
MT 940
MT 950
Remarks
20
Transaction Reference
Number
16x
M
16x
M
Identical
21
Related Reference
16x
O
Not present
25
Account Identification
35x
M
35x
M
Identical
28C
Statement
Number/Sequence
Number
5n[/5n]
M
5n[/5n]
M
Identical
60a
Opening Balance
F or M
M
F or M
M
Identical
61
Statement Line
6!n[4!n]2a[1!
a]15d1!a3!c1
6x[//16x]
[34x]
O
6!n[4!n]2a[1!
a]15d1!a3!c1
6x[//16x]
[34x]
O
Identical
86
Information to Account
Owner
6*65x
O
Not present
62a
Closing Balance
(Booked Funds)
F or M
M
F or M
M
Identical
64
Closing Available
Balance (Available
Funds)
1!a6!n3!a15d
O
1!a6!n3!a15d
O
Identical
Forward Available
Balance
1!a6!n3!a15d
O
Not present
Specific functionality: see
chapter 5.3
Information to Account
Owner
6*65x
O
Not present
Specific functionality: see
chapter 5.4
Specific functionality: see
chapter 5.1
----->
Specific functionality: see
chapter 5.2
-----|
----->
65
-----|
86
Standards MT Migration Guide v1.0
22/01/2009
36
Specific corporate functionality in MT 940
5 Specific corporate functionality in MT 940
Since there is no new functionality in the MT 940 that typically relates to the migration from
the MT 950 to the MT 940, we refer for business examples on the correct use of the fields of
the MT 940 in a corporate environment to the SWIFT User Handbook as well as the SWIFT
for corporate - MT Implementation Guide.
5.1 Possibility to reply to an ad-hoc request for a statement (field 21)
Whilst the MT 920, Request Message, is used very little in the corporate environment so far,
the MT 940 allows for referring to such a message when the MT 940 is sent, ad hoc, on
request of the account owner.
5.2 Possibility to specify additional information with each entry
(field 86, 1st occurrence)
Compared to the MT 950, the MT 940 allows for providing additional information for each
entry on the account statement in a field 86 that is repeated together with each entry line.
Typically in a corporate environment, this field will contain remittance information used to
reconcile an incoming credit item with the related invoice. Remittance information is to be
preceded by the code /REMI/.
Besides the detailed description how to specify the remittance information, the User
Handbook explains how to identify the following additional information in this entry:
•
original currency and amount,
•
charges deducted from the transaction amount,
•
exchange rate applied to the transaction,
•
identification of the customer, ordering the transaction,
•
free format information, formatted as in the payment instruction that resulted in the
entry.
5.3 Possibility to specify forward available balances (field 65)
When taking into account the differences between value date and booking date for the
individual entries, the resulting balances on the account often differ. The MT 940 offers the
possibility to specify, besides the end-of-day booked balance, a forward available balance per
day.
5.4 Possibility to specify a generic block of additional information
(field 86, 2nd occurrence)
Compared to the MT 950, the MT 940 allows for providing a generic block of additional
information for the whole statement.
The MT implementation guidelines for SCORE contain a recommendation how in a relay
scenario, a forwarding bank should include the BIC of the account servicing institution in this
field 86 using the code /ORSD/.
Standards MT Migration Guide v1.0
22/01/2009
37
How to handle MT 950 specific information in an MT 940
6 How to handle MT 950 specific information in an MT 940
Unlike for the migration from the MT 103 to the MT 101, there is no need to have a chapter for
the migration MT 950 to the MT 940.
Since the MT 950, Statement Message, is a complete subset of the MT940, customer
Statement Message, there is no functionality in the MT 950 for which a workaround needs to
be provided. Everything an MT 950 can report, can be reported in the same way in an
MT 940.
Standards MT Migration Guide v1.0
22/01/2009
38
Legal Notices
7 Legal Notices
Copyright
SWIFT © 2009. All rights reserved.
You may copy this publication within your organisation. Any such copy must include these legal notices.
Confidentiality
This publication contains SWIFT or third-party confidential information. Do not disclose this publication outside
your organisation without the prior written consent of SWIFT.
Disclaimer
The information in this publication may change from time to time. You must always refer to the latest available
version on www.swift.com.
Translations
The English version of SWIFT documentation is the only official and binding version.
Trademarks
SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: SWIFT, the
SWIFT logo, Sibos, SWIFTNet, SWIFTReady, and Accord. Other product, service, or company names in this
publication are trade names, trademarks, or registered trademarks of their respective owners.
Standards MT Migration Guide v1.0
22/01/2009
39