The MT 202 COV is a General Use message, that is, no registration in a Message User Group is necessary to send and receive this message.
The message contains a mandatory sequence to include information on an underlying customer credit transfer and has a maximum message length of 10,000 characters.
Important!
To trigger the MT 202 COV format validation, the user header of the message (block 3) is mandatory and must contain the code COV in the validation flag field 119 ({3:{119:COV}}).
MT 202 COV Scope
This message is sent by or on behalf of the ordering institution directly, or through correspondent(s), to the financial institution of the beneficiary institution. All parties to the financial institution transfer (sequence A) must be financial institutions.
It must only be used to order the movement of funds related to an underlying customer credit transfer that was sent with the cover method.
The MT 202 COV must not be used for any other interbank transfer. For these transfers the MT 202 must be used.
MT 202 COV Format Specifications
The MT 202 COV consists of two sequences:
Sequence A General Information is a single occurrence sequence and contains information on the financial institution transfer between the ordering institution and beneficiary institution.
Sequence B Underlying Customer Credit Transfer Details is a single occurrence sequence and is used to provide details on an individual underlying customer credit transfer that was sent with the cover method.
Status
Tag
Field Name
Content/Options
No.
Mandatory Sequence A General Information
M
20
Transaction Reference Number
16x
1
M
21
Related Reference
16x
2
—–>
O
13C
Time Indication
/8c/4!n1!x4!n
3
—–|
M
32A
Value Date, Currency Code, Amount
6!n3!a15d
4
O
52a
Ordering Institution
A or D
5
O
53a
Sender’s Correspondent
A, B, or D
6
O
54a
Receiver’s Correspondent
A, B, or D
7
O
56a
Intermediary
A or D
8
O
57a
Account With Institution
A, B, or D
9
M
58a
Beneficiary Institution
A or D
10
O
72
Sender to Receiver Information
6*35x
11
End of Sequence A General Information
Mandatory Sequence B Underlying Customer Credit Transfer Details
M
50a
Ordering Customer
A, F, or K
12
O
52a
Ordering Institution
A or D
13
O
56a
Intermediary Institution
A, C, or D
14
O
57a
Account With Institution
A, B, C, or D
15
M
59a
Beneficiary Customer
No letter option, A, or F
16
O
70
Remittance Information
4*35x
17
O
72
Sender to Receiver Information
6*35x
18
O
33B
Currency/Instructed Amount
3!a15d
19
End of Sequence B Underlying Customer Credit Transfer Details
MT 202 COV Network Validated Rules
C1 If field 56a is present in sequence A, then field 57a must also be present in sequence A (Error code(s): C81).
C2 If field 56a is present in sequence B, then field 57a must also be present in sequence B (Error code(s): C68).
MT 202 COV Usage Rules
All parties to the financial institution transfer (Sequence A) must be financial institutions.
The transfer of funds between the ordering institution and the beneficiary institution is always related to an underlying customer credit transfer. Field 21 must refer to the underlying transaction.
The MT 202 COV must not be used to convey customer credit transfer instructions; it is used to order the movement of funds related to an underlying customer credit transfer that was sent with the cover method.
Where an inward MT 202 COV results in an onward MT 202 COV or MT 205 COV, the reference from field 21 of the inward message must be passed on unchanged in field 21 of the onward message.
The MT 202 COV must not be forwarded to the beneficiary financial institution for reporting purposes.
MT 202 COV Market Practices
Guidelines for the use of the message have been published by the Payments Market Practice Group (PMPG).
For more details, see the market practice document Guidelines for use of the MT 202 COV on http://www.pmpg.info.
sent by a financial institution to another financial institution.
sent by a corporate customer to a financial institution.
sent by a financial institution to a corporate customer.
It is used to request information or clarification relating to a previous SWIFT or non-SWIFT message or to one or more transactions contained therein.
A query may also be sent to request that an amendment be made to a previous message, except in those cases where a specific message, or facility within a message, has been provided for this purpose in the related category, for example, MT 707, AMEND in field 22 of the MT 300.
The category digit of the MT n95 Queries must be:
If related to a SWIFT message, the category digit of the related message.
If not related to a SWIFT message, the category digit which best describes the business purpose of the message.
For use of messages in the corporate-to-bank environment, see the MT message implementation guide and the message matrix for corporate customers available on http://www.swift.com.
MT n95 Format Specifications
Status
Tag
Field Name
Content/Options
No.
M
20
Transaction Reference Number
16x
1
M
21
Related Reference
16x
2
M
75
Queries
6*35x
3
O
77A
Narrative
20*35x
4
O
11a
MT and Date of the Original Message
R or S
5
O
79
Narrative Description of the Message to Which the Query Relates
35*50x
6
O
Copy of at least the Mandatory Fields of the Original Message
Copy of fields
7
MT n95 Network Validated Rules
C1 Either field 79 or a ‘Copy of at least the mandatory fields of the message to which the query relates’, but not both, may be present in the message (Error code(s): C31).
MT n95 Usage Rules
The MT n95 should not be used to enquire about the fate of documents sent for collection. The MT 420 is intended for this purpose.
All queries that relate to the same initial message, should refer to that initial message in field 21 of this message.
The message to which the MT n95 Queries is related may be quoted in part or in full.
The MT n95 Queries always requires a response, preferably by an MT n96 Answers.
The use of the MT n95 in association with the MT 105 EDIFACT Envelope must be in accordance with the specific guidelines detailed in the appropriate volume of the EDIFACT Message Implementation Guides (MIGs).
Alliance Web Platform is the framework that hosts browser-based graphical user interfaces(GUI) of the Alliance portfolio. It offers a consistent end-user interface to the functionality managed by the Alliance servers. Alliance Web Platform runs in an application server environment, enabling centralised deployment of the software.
The SWIFTAlliance Gateway (SAG) is an interface product for SWIFTNet. It incorporates all the functionality of the SWIFTNet Link. Additionally, it provides several different connectivity and usability features for SWIFTNet users, providing solutions to a variety of system integration problems.
The SAG supports several different modes of operation. One of these, the strict SWIFTNet Link Mode, is particularly relevant to the FileAct and InterAct adapters for SWIFT. In strict SWIFTNet Link Mode, the SAG presents a messaging interface that is functionally equivalent to the SWIFTNet Link interface as it is described throughout this guide.
The SAG serves as a message concentrator. It receives messages from various other applications and passes them through SWIFTNet. It receives these messages through host adapters, including a WebSphere MQ host adapter, which enables business applications running on a variety of different types of computing platforms to pass messages through SWIFTNet.
You can set up multiple calendars for a given year. This enables logical terminals to have their own calendar, which can be useful if the LTs are located in different countries, with different working days or public holidays.
If multiple calendars have been defined, then the available calendars are displayed when the Calendar application is started. This list also shows which Calendar is currently set as the default. You can use the Calendar application to create additional calendars. You have to set up a calendar if you want users to be able to schedule Alliance Access processes to occur automatically.
Alliance Access users can only schedule processes if the operator profiles allow them to do so. After you create your calendar, you must modify the appropriate profiles. For example, you may modify a profile so that operators can use the Message File application to schedule message archiving. Once you have created a calendar and modified the profiles, any users with the appropriate profiles can schedule processes.
Contents.
The Calendar application enables you to create, modify, or remove calendars for the current year, the next year, or both.
For each year in the calendar, you can assign one of the following day profiles:
Normal Working Day
Peak Working Day
Holiday
Weekend.
How Scheduling Works
At the start of each day (midnight), Alliance Access checks the calendar and determines which day types apply to the current day. For example, today may be the First Working Day of Week and the First Working Day of Month. Alliance Access then checks to see whether any operations are scheduled for these day types. If an operation is scheduled, then Alliance Access carries it out at the specified time, unless the server is running in housekeeping mode. The schedule is also rebuilt after each restart of the server. If the restart occurs between the earliest and latest start times of an event, then that event is started automatically.
Processes that Can be Scheduled to Occur Automatically
Overview
You can schedule the following functions to occur automatically:
archive the Event Journal
archive the Message File
Back up the archives of the Event Journal and the Message File
remove archives
activate and de-activate the emission and reception profiles in the SWIFTNet Interface application
install CIF Update files
stop and restart the Alliance Access servers
Perform a FIN Select and logout from SWIFT
back up Alliance Access data to disk
import and export RMA authorisations (for more information, see the Relationship Management Application User Guide).
For information about the permissions required to schedule these functions, see the System Management Guide
This multiple message is sent by a drawer bank, or a bank acting on behalf of the drawer bank to the bank on which a/several cheque(s) has been drawn (the drawee bank). It is used to advise the drawee bank, or confirm to an enquiring bank, the details concerning the cheque(s) referred to in the message.
MT 110 Format Specifications
Status
Tag
Field Name
Content/Options
No.
M
20
Sender’s Reference
16x
1
O
53a
Sender’s Correspondent
A, B, or D
2
O
54a
Receiver’s Correspondent
A, B, or D
3
O
72
Sender to Receiver Information
6*35x
4
—–>
M
21
Cheque Number
16x
5
M
30
Date of Issue
6!n
6
M
32a
Amount
A or B
7
O
52a
Drawer Bank
A, B, or D
8
M
59
Payee
[/34x] 4*35x
9
—–|
MT 110 Network Validated Rules
C1 The repetitive sequence must not be present more than ten times (Error code(s): T10).
C2 The currency code in the amount field 32a must be the same for all occurrences of this field in the message (Error code(s): C02).
This field specifies the reference assigned by the Sender to unambiguously identify the message.
Network Validated Rules
This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26).
Usage Rules
This reference must be quoted in any related confirmation or statement, for example, MT 900, 910 and/or 950.
When the cover method is used for a customer credit transfer, this reference must be quoted unchanged in field 21 of the related MT 202 COV.
Example
:20:Ref254
MT 103: (3) Field 23B: Bank Operation Code
Format
Option B
4!c
(Type)
Presence
Mandatory
Definition
This field identifies the type of operation.
Codes
One of the following codes must be used (Error code(s): T36):
CRED
Normal credit transfer
This message contains a credit transfer where there is no SWIFT Service Level involved.
CRTS
Test message
This message contains a credit transfer for test purposes.
SPAY
SWIFTPay
This message contains a credit transfer to be processed according to the SWIFTPay Service Level.
SPRI
Priority
This message contains a credit transfer to be processed according to the Priority Service Level.
SSTD
Standard
This message contains a credit transfer to be processed according to the Standard Service Level.
Usage Rules
The code CRTS should not be used on the FIN network.
Example
:23B:CRED
MT 103: (6) Field 32A: Value Date/Currency/Interbank Settled Amount
Format
Option A
6!n3!a15d
(Date)(Currency)(Amount)
Presence
Mandatory
Definition
This field specifies the value date, the currency and the settlement amount. The settlement amount is the amount to be booked/reconciled at interbank level.
Network Validated Rules
Date must be a valid date expressed as YYMMDD (Error code(s): T50).
Currency must be a valid ISO 4217 currency code (Error code(s): T52).
The integer part of Amount must contain at least one digit. A decimal comma is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43).
The codes XAU, XAG, XPD and XPT are not allowed, as these are codes for commodities for which the category 6 commodities messages must be used (Error code(s): C08).
Example
:32A:981209USD1000,00
MT 103: (9) Field 50a: Ordering Customer
Format
Option A
[/34x] 4!a2!a2!c[3!c]
(Account) (Identifier Code)
Option F
35x 4*35x
(Party Identifier) (Name and Address)
Option K
[/34x] 4*35x
(Account) (Name and Address)
In option F, the following line formats must be used (Error code(s): T54):
Line 1 (subfield Party Identifier)
/34x
(Account)
Lines 2-5 (subfield Name and Address)
1!n/33x
(Number)(Details)
Or
Line 1 (subfield Party Identifier)
4!a/2!a/27x
(Code)(Country Code)(Identifier)
Lines 2-5 (subfield Name and Address)
1!n/33x
(Number)(Details)
Presence
Mandatory
Definition
This field specifies the customer ordering the transaction.
Network Validated Rules
Identifier Code must be a registered BIC (Error code(s): T27, T28, T29, T45).
In option F, subfield 1 (Party Identifier) used with the (Code)(Country Code)(Identifier) format: Country Code must be a valid ISO country code (Error code(s): T73).
In option F, subfield 2 (Name and Address):
The first line must start with number 1 (Error code(s): T56).
Numbers must appear in numerical order (Error code(s): T56).
Number 2 must not be used without number 3 (Error code(s): T56).
The first occurrence of number 3 must be followed by a valid ISO country code (Error code(s): T73).
Number 4 must not be used without number 5 and vice versa (Error code(s): T56).
Number 4 must be followed by a valid date in the format YYYYMMDD and this date, local to the sender, must not be later than the date on which the message is successfully sent to SWIFT (Error code(s): T50).
Numbers 5, 6 and 7 must be followed by a valid ISO country code (Error code(s): T73), a slash ‘/’ and additional Details (Error code(s): T56).
Numbers 4, 5, 6, 7 and 8 must not be repeated (Error code(s): T56).
The use of number 8 is only allowed in the following instances (Error code(s): T56):
to continue information on the Identifier of the ordering customer provided in subfield 1 (Party Identifier) used with the (Code)(Country Code)(Identifier) format.
to continue information on the Customer Identification Number provided in subfield 2 (Name and Address) following number 6.
to continue information on the National Identity Number provided in subfield 2 (Name and Address) following number 7.
Usage Rules
If the account number of the ordering customer is known, it must be stated in Account.
In option F, subfield 2 (Name and Address): Numbers 1, 2 and 3 may be repeated.
In option F, subfield 2 (Name and Address): if number 2 is present, the first occurrence of number 3 must include the town in additional details.
In option F, subfield 1 (Party Identifier) used with the (Code)(Country Code)(Identifier) format: if additional space is required for providing the Identifier of the ordering customer, one of the following options must be used:
First option (preferred): Identify the ordering customer with a different identifier where the length is not an issue.
Second option: Continue the information in subfield 2 (Name and Address) using number 8.
In option F, subfield 2 (Name and Address): if additional space is required for providing the Customer Identification Number (number 6) or the National Identity Number (number 7) of the ordering customer, one of the following options must be used:
First option (preferred): Identify the ordering customer with a different identifier where the length is not an issue.
Second option: Continue the information in subfield 2 (Name and Address) using number 8.
Example
Option A
:50A:/293456-1254349-82
VISTUS31
Option F – Example 1
:50F:/12345678
1/SMITH JOHN
2/299, PARK AVENUE
3/US/NEW YORK, NY 10017
Option F – Example 2
:50F:/BE30001216371411
1/PHILIPS MARK
4/19720830
5/BE/BRUSSELS
Option F – Example 3
:50F:DRLC/BE/BRUSSELS/NB0949042
1/DUPONT JACQUES
2/HIGH STREET 6, APT 6C
3/BE/BRUSSELS
Option F – Example 4
:50F:NIDN/DE/121231234342
1/MANN GEORG
6/DE/ABC BANK/1234578293
Option F – Example 5
:50F:CUST/DE/ABC BANK/123456789/8-123456
1/MANN GEORG
2/LOW STREET 7
3/DE/FRANKFURT
8/7890
MT 103: (17) Field 59a: Beneficiary Customer
Format
No letter option
[/34x] 4*35x
(Account) (Name and Address)
Option A
[/34x] 4!a2!a2!c[3!c]
(Account) (Identifier Code)
Option F
[/34x] 4*(1!n/33x)
(Account) (Number)(Name and Address Details)
Presence
Mandatory
Definition
This field specifies the customer which will be paid.
Codes
In option F, Number must contain one of the following values (Error code(s): T56):
1
Name of the Beneficiary Customer
The number followed by a slash, ‘/’ must be followed by the name of the beneficiary customer.
2
Address Line
The number followed by a slash, ‘/’ must be followed by an address line (Address Line can be used to provide for example, street name and number, building name or post office box number).
3
Country and Town
The first occurrence of number 3 must be followed by a slash, ‘/’, the ISO country code and, optionally, additional details that are preceded by a slash ‘/’.Other occurrence(s) of number 3 must be followed by a slash ‘/’ and the continuation of additional details.Additional details can contain town, which can be complemented by postal code (for example zip) and country subdivision (for example, state, province, or county). The country code and town should, preferably, indicate the country and town of residence, as provided by the ordering customer.
Codes
Account may contain one of the following codes, preceded by a double slash ‘//’:
CH
6!n
CHIPS Universal Identifier
Network Validated Rules
Identifier Code must be a registered BIC (Error code(s): T27, T28, T29, T45).
In option F, for subfields (Number)(Name and Address Details):
The first line must start with number 1 (Error code(s): T56).
Numbers must appear in numerical order (Error code(s): T56).
Number 2 must not be used without number 3 (Error code(s): T56).
The first occurrence of number 3 must be followed by a valid ISO country code (Error code(s): T73).
Usage Rules
At least the name or the BIC of the beneficiary customer is mandatory.
If a non-financial institution BIC is specified, it must be meaningful for the financial institution that services the account for the beneficiary customer.
If the account number of the beneficiary customer is known, it must be stated in Account.
In option F:
line numbers may be repeated
if number 2 is present, the first occurrence of number 3 must include the town in the additional details
This field specifies the rules the credit is subject to.
Codes
One of the following codes must be used in Applicable Rules (Error code(s): T59)
EUCP LATEST VERSION
The credit is subject to the version of the Supplement of the ICC Uniform Customs and Practice for Documentary Credits for Electronic Presentations, International Chamber of Commerce, Paris, France, which is in effect on the date of issue.
EUCPURR LATEST VERSION
The credit is subject to the version of the Supplement of the ICC Uniform Customs and Practice for Documentary Credits for Electronic Presentations, International Chamber of Commerce, Paris, France, which is in effect on the date of issue. The reimbursement is subject to the version of the Uniform Rules for Bank-to-Bank Reimbursements, International Chamber of Commerce, Paris, France, which is in effect on the date of issue.
ISP LATEST VERSION
The standby letter of credit is subject to the version of the ICC International Standby Practices, International Chamber of Commerce, Paris, France, which is in effect on the date of issue.
OTHR
The credit is subject to any other rules.
UCP LATEST VERSION
The credit is subject to the version of the ICC Uniform Customs and Practice for Documentary Credits, International Chamber of Commerce, Paris, France, which is in effect on the date of issue.
UCPURR LATEST VERSION
The credit is subject to the version of the ICC Uniform Customs and Practice for Documentary Credits, International Chamber of Commerce, Paris, France, which is in effect on the date of issue. The reimbursement is subject to the version of the Uniform Rules for Bank-to-Bank Reimbursements under documentary credits, International Chamber of Commerce, Paris, France, which is in effect on the date of issue.
Network Validated Rules
Subfield 2 of field 40E, that is, “/”35x, is only allowed when subfield 1 of this field consists of OTHR (Error code(s): D81).
MT 700: (9) Field 50: Applicant
Format
4*35x
(Name and Address)
Presence
Mandatory
Definition
This field specifies the party on behalf of which the documentary credit is being issued.
MT 700: (11) Field 32B: Currency Code, Amount
Format
Option B
3!a15d
(Currency)(Amount)
Presence
Mandatory
Definition
This field contains the currency code and amount of the documentary credit.
Network Validated Rules
Currency must be a valid ISO 4217 currency code (Error code(s): T52).
The integer part of Amount must contain at least one digit. The decimal comma ‘,’ is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43).
Usage Rules
Special information relative to the amount of the credit must be specified in field 39A Percentage Credit Amount Tolerance, field 39B Maximum Credit Amount or field 39C Additional Amounts Covered.
MT 700: (15) Field 41a: Available With … By …
Format
Option A
4!a2!a2!c[3!c] 14x
(Identifier Code) (Code)
Option D
4*35x 14x
(Name and Address) (Code)
Presence
Mandatory
Definition
This field identifies the bank with which the credit is available (the place for presentation) and an indication of how the credit is available.
Codes
In option A or D, Code must contain one of the following codes (Error code(s): T68)
BY ACCEPTANCE
BY DEF PAYMENT
BY MIXED PYMT
BY NEGOTIATION
BY PAYMENT
Network Validated Rules
Identifier Code must be a registered financial institution BIC (Error code(s): T27, T28, T29, T45).
Identifier Code must be a financial institution BIC. This error code applies to all types of BICs referenced in a FIN message including connected BICs, non-connected BICs, Masters, Synonyms, Live destinations and Test & Training destinations (Error code(s): C05).
Usage Rules
For credits subject to eUCP:
If presentation of both electronic records and paper documents is allowed, the place for presentation of the electronic records (that is, the electronic address to which presentation must be made) as well as the place for presentation of the paper documents must be specified in field 47A and not in this field.
If presentation of only electronic records is allowed, the place for presentation of the electronic records (that is, the electronic address to which presentation must be made) must be specified in field 47A and not in this field.
If the credit is to be freely negotiable by any bank, option D must be used with the phrase Any bank in … (city or country). If the credit is to be freely negotiable by any bank anywhere in the world, an indication of country is not required.
When Code contains either BY DEF PAYMENT or BY MIXED PYMT, the specific details of the payment terms must be specified in field 42P and 42M respectively.
When Code contains BY PAYMENT, this should be understood to mean payment at sight.
MT 700: (33) Field 49: Confirmation Instructions
Format
7!x
(Instruction)
Presence
Mandatory
Definition
This field contains confirmation instructions for the Receiver.
Codes
One of the following codes must be used (Error code(s): T67):
CONFIRM
The Receiver is requested to confirm the credit
MAY ADD
The Receiver may add its confirmation to the credit
WITHOUT
The Receiver is not requested to confirm the credit
This field contains a reference to the related transaction
Codes
If the Sender is not the originator of the transaction and no related reference is received, the code NONREF must be used in this field.
Network Validated Rules
This field must not start or end with a slash ‘/’ and must not contain two consecutive slashes ‘//’ (Error code(s): T26).
Usage Rules
This field will contain a reference to the related transaction which is meaningful to the beneficiary institution, for example, the common reference in an MT 300 Foreign Exchange Confirmation, field 21 of an MT 202 General Financial Institution Transfer, an MT 205 Financial Institution Transfer Execution or an MT 400 Advice of Payment.
MT 202: (4) Field 32A: Value Date, Currency Code, Amount
Format
Option A
6!n3!a15d
(Date)(Currency)(Amount)
Presence
Mandatory
Definition
This field specifies the value date, currency and amount to be transferred.
Network Validated Rules
Date must be a valid date expressed as YYMMDD (Error code(s): T50).
Currency must be a valid ISO 4217 currency code (Error code(s): T52).
The integer part of Amount must contain at least one digit. A decimal comma is mandatory and is included in the maximum length. The number of digits following the comma must not exceed the maximum number allowed for the specified currency (Error code(s): C03, T40, T43).
The codes XAU, XAG, XPD and XPT are not allowed, as these are codes for commodities for which the category 6 commodities messages must be used (Error code(s): C08).
MT 202: (5) Field 52a: Ordering Institution
Format
Option A
[/1!a][/34x] 4!a2!a2!c[3!c]
(Party Identifier) (Identifier Code)
Option D
[/1!a][/34x] 4*35x
(Party Identifier) (Name and Address)
Presence
Optional
Definition
This field specifies the ordering financial institution when other than the Sender of the message.
Codes
In option A, Party Identifier may be used to indicate a national clearing system code.
The following codes may be used, preceded by a double slash ‘//’:
AT
5!n
Austrian Bankleitzahl
AU
6!n
Australian Bank State Branch (BSB) Code
BL
8!n
German Bankleitzahl
CC
9!n
Canadian Payments Association Payment Routing Number
CN
12..14n
China National Advanced Payment System (CNAPS) Code
ES
8..9n
Spanish Domestic Interbanking Code
FW
without 9 digit code
Pay by Fedwire
GR
7!n
HEBIC (Hellenic Bank Identification Code)
HK
3!n
Bank Code of Hong Kong
IE
6!n
Irish National Clearing Code (NSC)
IN
11!c
Indian Financial System Code (IFSC)
IT
10!n
Italian Domestic Identification Code
PL
8!n
Polish National Clearing Code (KNR)
PT
8!n
Portuguese National Clearing Code
SC
6!n
UK Domestic Sort Code
Codes
In option D, Party Identifier may be used to indicate a national clearing system code.
The following codes may be used, preceded by a double slash ‘//’:
AT
5!n
Austrian Bankleitzahl
AU
6!n
Australian Bank State Branch (BSB) Code
BL
8!n
German Bankleitzahl
CC
9!n
Canadian Payments Association Payment Routing Number
CH
6!n
CHIPS Universal Identifier
CN
12..14n
China National Advanced Payment System (CNAPS) Code
CP
4!n
CHIPS Participant Identifier
ES
8..9n
Spanish Domestic Interbanking Code
FW
9!n
Fedwire Routing Number
GR
7!n
HEBIC (Hellenic Bank Identification Code)
HK
3!n
Bank Code of Hong Kong
IE
6!n
Irish National Clearing Code (NSC)
IN
11!c
Indian Financial System Code (IFSC)
IT
10!n
Italian Domestic Identification Code
PL
8!n
Polish National Clearing Code (KNR)
PT
8!n
Portuguese National Clearing Code
RU
9!n
Russian Central Bank Identification Code
SC
6!n
UK Domestic Sort Code
SW
3..5n
Swiss Clearing Code (BC code)
SW
6!n
Swiss Clearing Code (SIC code)
Network Validated Rules
Identifier Code must be a registered financial institution BIC (Error code(s): T27, T28, T29, T45).
Identifier Code must be a financial institution BIC. This error code applies to all types of BICs referenced in a FIN message including connected BICs, non-connected BICs, Masters, Synonyms, Live destinations and Test & Training destinations (Error code(s): C05).
Usage Rules
When the Sender of an initial MT 202 is also the ordering institution, that is, this field is not used, that Sender will be identified in this field in any subsequent messages as the ordering institution.
This field must be forwarded to the beneficiary institution.
The coded information contained in field 52a must be meaningful to the Receiver of the message.
Option A is the preferred option.
Option D should only be used when the ordering financial institution has no BIC.
MT 202: (10) Field 58a: Beneficiary Institution
Format
Option A
[/1!a][/34x] 4!a2!a2!c[3!c]
(Party Identifier) (Identifier Code)
Option D
[/1!a][/34x] 4*35x
(Party Identifier) (Name and Address)
Presence
Mandatory
Definition
This field specifies the financial institution which has been designated by the ordering institution as the ultimate recipient of the funds being transferred.
Codes
In option A, Party Identifier may be used to indicate a national clearing system code.
The following codes may be used, preceded by a double slash ‘//’:
AT
5!n
Austrian Bankleitzahl
AU
6!n
Australian Bank State Branch (BSB) Code
BL
8!n
German Bankleitzahl
CC
9!n
Canadian Payments Association Payment Routing Number
CN
12..14n
China National Advanced Payment System (CNAPS) Code
ES
8..9n
Spanish Domestic Interbanking Code
FW
without 9 digit code
Pay by Fedwire
GR
7!n
HEBIC (Hellenic Bank Identification Code)
HK
3!n
Bank Code of Hong Kong
IE
6!n
Irish National Clearing Code (NSC)
IN
11!c
Indian Financial System Code (IFSC)
IT
10!n
Italian Domestic Identification Code
PL
8!n
Polish National Clearing Code (KNR)
PT
8!n
Portuguese National Clearing Code
RT
Pay by Real Time Gross Settlement
SC
6!n
UK Domestic Sort Code
ZA
6!n
South African National Clearing Code
Codes
In option D, Party Identifier may be used to indicate a national clearing system code.
The following codes may be used, preceded by a double slash ‘//’:
AT
5!n
Austrian Bankleitzahl
AU
6!n
Australian Bank State Branch (BSB) Code
BL
8!n
German Bankleitzahl
CC
9!n
Canadian Payments Association Payment Routing Number
CH
6!n
CHIPS Universal Identifier
CN
12..14n
China National Advanced Payment System (CNAPS) Code
CP
4!n
CHIPS Participant Identifier
ES
8..9n
Spanish Domestic Interbanking Code
FW
9!n
Fedwire Routing Number
GR
7!n
HEBIC (Hellenic Bank Identification Code)
HK
3!n
Bank Code of Hong Kong
IE
6!n
Irish National Clearing Code (NSC)
IN
11!c
Indian Financial System Code (IFSC)
IT
10!n
Italian Domestic Identification Code
PL
8!n
Polish National Clearing Code (KNR)
PT
8!n
Portuguese National Clearing Code
RT
Pay by Real Time Gross Settlement
RU
9!n
Russian Central Bank Identification Code
SC
6!n
UK Domestic Sort Code
SW
3..5n
Swiss Clearing Code (BC code)
SW
6!n
Swiss Clearing Code (SIC code)
ZA
6!n
South African National Clearing Code
Network Validated Rules
Identifier Code must be a registered financial institution BIC (Error code(s): T27, T28, T29, T45).
Identifier Code must be a financial institution BIC. This error code applies to all types of BICs referenced in a FIN message including connected BICs, non-connected BICs, Masters, Synonyms, Live destinations and Test & Training destinations (Error code(s): C05).
Usage Rules
When the Sender instructs the Receiver to either credit one of several accounts owned by the Sender at an institution specified in field 57a, or transfer funds between two accounts owned by the Sender and serviced by the Receiver, option A must be used to specify the account to be credited and the name of the Sender.
It is strongly recommended that when clearing payments take precedence over book transfer and book transfer is requested, Party Identifier be used to specify the account of the beneficiary.
When one of the codes //FW (with or without the 9-digit number), //AU, //CP, //IN or //RT is used, it should appear only once and in the first of the fields 56a, 57a and 58a of the payment instruction.
When it is necessary that an incoming SWIFT payment be made to the party in this field via Fedwire, US banks require that the code //FW appears in the optional Party Identifier.
When it is necessary that an incoming SWIFT payment be made to the party in this field via real-time gross settlement (RTGS), the code //RT should appear in the optional Party Identifier.
The code //RT is binding for the Receiver. If it is used with option A, it must not be followed by any other information. If it is used with option D, it may be followed by another domestic clearing code.
Option A must be used whenever possible.
Option D must only be used in exceptional circumstances: when the party cannot be identified by a financial institution BIC, when there is a need to be able to specify a name and address, for example, due to regulatory considerations or when there is a bilateral agreement between the Sender and the Receiver permitting its use.
When qualified by a clearing system code or an account number, the use of option D will enable the automated processing of the instruction(s) by the Receiver.
SWIFT Financial Application (FIN) messages. They have the following structure: {1: Basic Header Block} {2: Application Header Block} {3: User Header Block} {4: Text Block or body} {5: Trailer Block}These five SWIFT message blocks include header information, the body of the message, and a trailer. All blocks have the same basic format:{
n:…}The curly braces ({}) indicate the beginning and end of a block. n is the block identifier, in this case a single integer between 1 and 5. Each block identifier is associated with a particular part of the message. There is no carriage return or line feed (CRLF) between blocks.Blocks 3, 4, and 5 may contain sub-blocks or fields delimited by field tags. Block 3 is optional. Many applications, however, populate block 3 with a reference number so that when SWIFT returns the acknowledgement, it can be used for reconciliation purposes.
Note:For further information on SWIFT message blocks, see Chapter 2 of the SWIFT User Handbook FIN System Messages Document.
{1: Basic Header Block}The basic header block is fixed-length and continuous with no field delimiters. It has the following format:{1: F 01 BANKBEBB 2222 123456}(a) (b) (c) (d) (e) (f)a)1: = Block ID (always 1)b)Application ID as follows:· F = FIN (financial application)· A = GPA (general purpose application)· L = GPA (for logins, and so on)c)Service ID as follows:· 01 = FIN/GPA· 21 = ACK/NAKd)BANKBEBB = Logical terminal (LT) address. It is fixed at 12 characters; it must not have X in position 9.e)2222 = Session number. It is generated by the user’s computer and is padded with zeros.f)123456 = Sequence number that is generated by the user’s computer. It is padded with zeros.
{2: Application Header Block}There are two types of application headers: Input and Output. Both are fixed-length and continuous with no field delimiters.The input (to SWIFT) structure is as follows:{2: I 100 BANKDEFFXXXX U 3 003}(a) (b) (c) (d) (e) (f) (g)a)2: = Block ID (always 2)b)I = Inputc)100 = Message typed)BANKDEFFXXXX = Receiver’s address with X in position 9/ It is padded with Xs if no branch is required.e)U = the message priority as follows:· S = System· N = Normal· U = Urgentf)3 = Delivery monitoring field is as follows:· 1 = Non delivery warning (MT010)· 2 = Delivery notification (MT011)· 3 = Both valid = U1 or U3, N2 or Ng)003 = Obsolescence period. It specifies when a non-delivery notification is generated as follows:· Valid for U = 003 (15 minutes)· Valid for N = 020 (100 minutes)The output (from SWIFT) structure is as follows: {2: O 100 1200 970103BANKBEBBAXXX2222123456 970103 1201 N}(a) (b) (c) (d) (e) (f) (g) (h)a)2: = Block ID (always 2)b)O = Outputc)100 = Message typed)1200 = Input time with respect to the sendere)The Message Input Reference (MIR), including input date, with Sender’s addressf)970103 = Output date with respect to Receiverg)1201 = Output time with respect to Receiverh)N = Message priority as follows:· S = System· N = Normal· U = Urgent
{3: User Header Block}This is an optional block and has the following structure:{3: {113:xxxx} {108:abcdefgh12345678} }(a) (b) ( c)a)3: = Block ID (always 3)b)113:xxxx = Optional banking priority codec)This is the Message User Reference (MUR) used by applications for reconciliation with ACK.
Note:Other tags exist for this block. They include tags (such as 119, which can contain the code ISITC on an MT521) that may force additional code word and formatting rules to validate the body of the message as laid down by ISITC (Industry Standardization for Institutional Trade Communication). For further information, see All Things SWIFT: the SWIFT User Handbook.
{4: Text Block or body}This block is where the actual message content is specified and is what most users see. Generally the other blocks are stripped off before presentation. The format, which is variable length and requires use of CRLF as a field delimiter, is as follows:{4:CRLF:20:PAYREFTB54302 CRLF:32A:970103BEF1000000,CRLF:50:CUSTOMER NAME CRLFAND ADDRESS CRLF:59:/123-456-789 CRLFBENEFICIARY NAME CRLFAND ADDRESS CRLF-}The symbol CRLF is a mandatory delimiter in block 4. The example above is of type MT100 (Customer Transfer) with only the mandatory fields completed. It is an example of the format of an ISO 7775 message structure. Block 4 fields must be in the order specified for the message type in the appropriate volume of the SWIFT User Handbook.The content of the text block is a collection of fields. For more on SWIFT fields, see
SWIFT field structure. Sometimes, the fields are logically grouped into sequences. Sequences can be mandatory or optional, and can repeat. Sequences also can be divided into subsequences. In addition, single fields and groups of consecutive fields can repeat. For example, sequences such as those in the SWIFT Tags 16R and 16S may have beginning and ending fields. Other sequences, such as Tag 15, have only a beginning field. In yet other message types, no specific tags mark the start or end of a field sequence.The format of block 4 field tags is::
nna:
nn = Numbers
a = Optional letter, which may be present on selected tagsFor example::20: = Transaction reference number:58A: = Beneficiary bankThe length of a field is as follows:
nn = Maximum length
nn! = Fixed-length
nn–
nn = Minimum and maximum length
nn * nn = Maimum number of lines times maximum line lengthThe format of the data is as follows:
n = Digits
d = Digits with decimal comma
h = Uppercase hexadecimal
a = Uppercase letters
c = Uppercase alphanumeric
e = Space
x = SWIFT character set
y = Uppercase level A ISO 9735 characters
z = SWIFT extended character setSome fields are defined as optional. If optional fields are not required in a specific message, do not include them because blank fields are not allowed in the message./,word = Characters “as is”[…] = Brackets indicate an optional elementFor example:4!c[/30x]This is a fixed 4 uppercase alphanumeric, optionally followed by a slash and up to 30 SWIFT characters.ISIN1!e12!cThis is a code word followed by a space and a 12 fixed uppercase alphanumeric.
Note:In some message types, certain fields are defined as conditional. For example, when a certain field is present, another field may change from optional to mandatory or forbidden. Certain fields may contain sub-fields, in which case there is no CRLF between them. Validation is not supported.Certain fields have different formats that depend on the option that is chosen. The option is designated by a letter after the tag number, for example::32A:000718GBP1000000,00Value Date, ISO Currency, and Amount:32B:GBP1000000,00ISO Currency and Amount
Note:The SWIFT standards for amount formats are: no thousand separators are allowed (10,000 is not allowed, but 10000 is allowed); use a comma (not a decimal point) for a decimal separator (1000,45 = one thousand and forty-five hundredths).:58A:NWBKGB2LBeneficiary SWIFT address:58D:NatWest BankBeneficiary full name and addressHead OfficeLondon
{5: Trailer Block}A message always ends in a trailer with the following format:{5: {MAC:12345678}{CHK:123456789ABC}This block is for SWIFT system use and contains a number of fields that are denoted by keywords such as the following:MACMessage Authentication Code calculated based on the entire contents of the message using a key that has been exchanged with the destination and a secret algorithm. Found on message categories 1,2,4,5,7,8, most 6s and 304.CHKChecksum calculated for all message types.PDEPossible Duplicate Emission added if user thinks the same message was sent previouslyDLMAdded by SWIFT if an urgent message (U) has not been delivered within 15 minutes, or a normal message (N) within 100 minutes.
Maryam's Blog 