MT 202 COV General Financial Institution Transfer

MT 202 COV General Financial

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.
StatusTagField NameContent/OptionsNo.
Mandatory Sequence A General Information
M20Transaction Reference Number16x1
M21Related Reference16x2
—–>
O13CTime Indication/8c/4!n1!x4!n3
—–|
M32AValue Date, Currency Code, Amount6!n3!a15d4
O52aOrdering InstitutionA or D5
O53aSender’s CorrespondentA, B, or D6
O54aReceiver’s CorrespondentA, B, or D7
O56aIntermediaryA or D8
O57aAccount With InstitutionA, B, or D9
M58aBeneficiary InstitutionA or D10
O72Sender to Receiver Information6*35x11
End of Sequence A General Information
Mandatory Sequence B Underlying Customer Credit Transfer Details
M50aOrdering CustomerA, F, or K12
O52aOrdering InstitutionA or D13
O56aIntermediary InstitutionA, C, or D14
O57aAccount With InstitutionA, B, C, or D15
M59aBeneficiary CustomerNo letter option, A, or F16
O70Remittance Information4*35x17
O72Sender to Receiver Information6*35x18
O33BCurrency/Instructed Amount3!a15d19
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.

SWIFT Documentation
Created: 23-May-2016

 MT 202 COV General Financial Institution Transfer     

MT n95 Queries

This message type is:

  • 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

StatusTagField NameContent/OptionsNo.
M20Transaction Reference Number16x1
M21Related Reference16x2
M75Queries6*35x3
O77ANarrative20*35x4
O11aMT and Date of the Original MessageR or S5
O79Narrative Description of the Message to Which the Query Relates35*50x6
O Copy of at least the Mandatory Fields of the Original MessageCopy of fields7

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).

What is Alliance Web Platform?

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.

What Is the SWIFTAlliance Gateway?

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.

Working with Calendars in SWIFT

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

.

MT 110 Advice of Cheque(s)

MT 110 Scope

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

StatusTagField NameContent/OptionsNo.
M20Sender’s Reference16x1
O53aSender’s CorrespondentA, B, or D2
O54aReceiver’s CorrespondentA, B, or D3
O72Sender to Receiver Information6*35x4
—–>
M21Cheque Number16x5
M30Date of Issue6!n6
M32aAmountA or B7
O52aDrawer BankA, B, or D8
M59Payee[/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).

SWIFT Documentation

MT 103 Single Customer Credit Transfer – Explanation for some important fields

MT 103: (1) Field 20: Sender’s Reference

Format

16x

Presence

Mandatory

Definition

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 B4!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):

CREDNormal credit transferThis message contains a credit transfer where there is no SWIFT Service Level involved.
CRTSTest messageThis message contains a credit transfer for test purposes.
SPAYSWIFTPayThis message contains a credit transfer to be processed according to the SWIFTPay Service Level.
SPRIPriorityThis message contains a credit transfer to be processed according to the Priority Service Level.
SSTDStandardThis 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 A6!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 F35x
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:

  1. First option (preferred): Identify the ordering customer with a different identifier where the length is not an issue.
  2. 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:

  1. First option (preferred): Identify the ordering customer with a different identifier where the length is not an issue.
  2. 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):

1Name of the Beneficiary CustomerThe number followed by a slash, ‘/’ must be followed by the name of the beneficiary customer.
2Address LineThe 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).
3Country and TownThe 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 ‘//’:

CH6!nCHIPS 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

Example

No letter option

:59:/BE62510007547061

JOHANN WILLEMS

RUE JOSEPH II, 19

1040 BRUSSELS

Option F – Example 1

:59F:/BE30001216371411

1/MARK PHILIPS

2/HOOGSTRAAT 6, APT 6C

3/BE/BRUSSELS

Option F – Example 2

:59F:/12345678

1/DEPT OF PROMOTION OF SPICY FISH

1/CENTER FOR INTERNATIONALISATION

1/OF COMMERCE AND BUSINESS

3/CN

Option F – Example 3

:59F:1/JOHN SIMONS

2/3658 WITMER ROAD

3/US/POUGHKEEPSIE, NEW YORK 12602

3/DUTCHESS

MT 700 Issue of a Documentary Credit – Explansation of important fields

MT 700: (6) Field 40E: Applicable Rules

Format

Option E30x[/35x](Applicable Rules)(Narrative)

Presence

Mandatory

Definition

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 VERSIONThe 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 VERSIONThe 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 VERSIONThe 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.
OTHRThe credit is subject to any other rules.
UCP LATEST VERSIONThe 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 VERSIONThe 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 B3!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 A4!a2!a2!c[3!c]
14x
(Identifier Code)
(Code)
Option D4*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):

CONFIRMThe Receiver is requested to confirm the credit
MAY ADDThe Receiver may add its confirmation to the credit
WITHOUTThe Receiver is not requested to confirm the credit

MT 202 General Financial Institution Transfer – Explanation of important fields

MT 202: (2) Field 21: Related Reference

Format

16x

Presence

Mandatory

Definition

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 A6!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 ‘//’:

AT5!nAustrian Bankleitzahl
AU6!nAustralian Bank State Branch (BSB) Code
BL8!nGerman Bankleitzahl
CC9!nCanadian Payments Association Payment Routing Number
CN12..14nChina National Advanced Payment System (CNAPS) Code
ES8..9nSpanish Domestic Interbanking Code
FWwithout 9 digit codePay by Fedwire
GR7!nHEBIC (Hellenic Bank Identification Code)
HK3!nBank Code of Hong Kong
IE6!nIrish National Clearing Code (NSC)
IN11!cIndian Financial System Code (IFSC)
IT10!nItalian Domestic Identification Code
PL8!nPolish National Clearing Code (KNR)
PT8!nPortuguese National Clearing Code
SC6!nUK 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 ‘//’:

AT5!nAustrian Bankleitzahl
AU6!nAustralian Bank State Branch (BSB) Code
BL8!nGerman Bankleitzahl
CC9!nCanadian Payments Association Payment Routing Number
CH6!nCHIPS Universal Identifier
CN12..14nChina National Advanced Payment System (CNAPS) Code
CP4!nCHIPS Participant Identifier
ES8..9nSpanish Domestic Interbanking Code
FW9!nFedwire Routing Number
GR7!nHEBIC (Hellenic Bank Identification Code)
HK3!nBank Code of Hong Kong
IE6!nIrish National Clearing Code (NSC)
IN11!cIndian Financial System Code (IFSC)
IT10!nItalian Domestic Identification Code
PL8!nPolish National Clearing Code (KNR)
PT8!nPortuguese National Clearing Code
RU9!nRussian Central Bank Identification Code
SC6!nUK Domestic Sort Code
SW3..5nSwiss Clearing Code (BC code)
SW6!nSwiss 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 ‘//’:

AT5!nAustrian Bankleitzahl
AU6!nAustralian Bank State Branch (BSB) Code
BL8!nGerman Bankleitzahl
CC9!nCanadian Payments Association Payment Routing Number
CN12..14nChina National Advanced Payment System (CNAPS) Code
ES8..9nSpanish Domestic Interbanking Code
FWwithout 9 digit codePay by Fedwire
GR7!nHEBIC (Hellenic Bank Identification Code)
HK3!nBank Code of Hong Kong
IE6!nIrish National Clearing Code (NSC)
IN11!cIndian Financial System Code (IFSC)
IT10!nItalian Domestic Identification Code
PL8!nPolish National Clearing Code (KNR)
PT8!nPortuguese National Clearing Code
RT Pay by Real Time Gross Settlement
SC6!nUK Domestic Sort Code
ZA6!nSouth 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 ‘//’:

AT5!nAustrian Bankleitzahl
AU6!nAustralian Bank State Branch (BSB) Code
BL8!nGerman Bankleitzahl
CC9!nCanadian Payments Association Payment Routing Number
CH6!nCHIPS Universal Identifier
CN12..14nChina National Advanced Payment System (CNAPS) Code
CP4!nCHIPS Participant Identifier
ES8..9nSpanish Domestic Interbanking Code
FW9!nFedwire Routing Number
GR7!nHEBIC (Hellenic Bank Identification Code)
HK3!nBank Code of Hong Kong
IE6!nIrish National Clearing Code (NSC)
IN11!cIndian Financial System Code (IFSC)
IT10!nItalian Domestic Identification Code
PL8!nPolish National Clearing Code (KNR)
PT8!nPortuguese National Clearing Code
RT Pay by Real Time Gross Settlement
RU9!nRussian Central Bank Identification Code
SC6!nUK Domestic Sort Code
SW3..5nSwiss Clearing Code (BC code)
SW6!nSwiss Clearing Code (SIC code)
ZA6!nSouth 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 message block structure

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. 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:

= 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.

Copyright IBM Corp. 1997, 2004

%d bloggers like this: