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

Hardware Security Modules

Hardware Security Modules (HSMs) are tamper-resistant hardware devices that customers use
to safestore SWIFTNet Public Key Infrastructure (PKI) security profiles. The keys are generated
inside the HSM and stored encrypted in this device. SWIFT provides HSMs for use with
SWIFTNet PKI. The installation and configuration of the HSM is embedded in the SWIFTNet
Link. Access and use of the HSM is solely through the SWIFTNet Link .

HSM products

The following three HSM products store SWIFTNet PKI security profiles and are supported in
SWIFTNet Link:
• HSM token
a USB-based device which is supported in a Windows environment
• HSM card and card reader
a USB-based device that is supported in a Windows environment. It consists of an HSM card,
Cyberflex, and an HSM card reader for use with a smart card
• HSM box

A LAN-based device which is supported in a Windows, Sun Solaris or IBM AIX environment
An HSM card and an HSM token can store one SWIFTNet PKI security profile each. By default,
an HSM box can store up to 250 SWIFTNet PKI security profiles. Customers can order an
optional large certificate capacity license for their high-throughput class HSM boxes, this licence
allows customers to store up to 2500 SWIFTNet PKI security profiles.
The selection of the appropriate HSM is based on factors such as the SWIFTNet Link platform
type, the expected traffic volume, and the number of SWIFTNet PKI certificates. Users can
install multiples of the same type of HSM on a SWIFTNet Link.

Creation of FIN Messages Page

Page Description ‘Create FIN Message’

Sender Logical Terminal (Top Right)The logical terminal that you want the message to be sent from. You can only send a messagefrom a logical terminal that is licensed for your installation. The value selected in SenderLogical Terminal determines the message syntax version to use.FIN Category (Top Right)You can select a message category from the ones that are available. Each category containsonly the messages that you are allowed to create (as defined in your operator profile).NameThe message type.IdentifierThe internal name of the message type.•DescriptionText that explains the business purpose of the message type.
•VersionMessage Creation StepsTo create a new FIN user-to-user or system message:From the Creation menu, select FIN Message: New.•Select a logical terminal from the Sender Logical Terminal drop-down list.•Select the appropriate message category in the FIN Category drop-down list.•The list of message types available in the selected category appears.

Message Header•In the message header, the identity of the sender and the receiver of the message is specified•We also provide information regarding the priority of the message, as well as other details that are relevant for the particular message.Procedure for completing message header:•In the Sender part, select a unit from the Unit drop-down list. This is the unit to which the message is assigned.•The Sender Logical Terminal field shows the logical terminal that you have selected in the•Click Type to select the type of correspondent sending the message: Institution, Department, or Individual.•The Institution field displays the sender institution BIC8 corresponding to the logical terminal as a read-only value
Message Body•You enter the text of the message in the message body. The layout of the message body varies according to the structure of the message.•The fields that appear depend on the message type selected•Complete the fields in their displayed sequence. Some parts of the body can be collapsed to ease navigation.To complete the body:•Complete all mandatory fields.•Complete any optional fields as needed.
Validate Messages
•You can validate a message on demand at any time and correct any errors or warnings before trying to route or dispose it. Alliance Messenger indicates the fields that contain errors and warnings in a Validation Report.For example, if errors regarding the business relationship between sender and receiver are detected, text in the Validation Report informs you accordingly.  This is an important tool

SWIFTNET LINK: Features and Functions

Basic functionality
The basic functionality of SWIFTNet Link includes transport, formatting, security, and service
management. Through the SWIFTNet Link single-window concept, customers have a re-usable
access infrastructure to SWIFTNet messaging services.

Technical features

SWIFTNet Link has the following features:
• technical interoperability
• application programming interfaces (APIs)
• application programming interface functions
• availability options
• security management

The role of SWIFTNet Link in the SWIFTNet architecture
The diagram illustrates the 3-layer SWIFTNet architecture. SWIFTNet Link resides in the
communication level, which is level 2 of the network model.

What Is SWIFTNet Link?

Business software applications use the SWIFTNet Link (SNL) application programming interface (API) to access and use SWIFTNet services. The SNL is the mandatory network interface to SWIFTNet. SWIFTNet requires SNL for all external interfaces. The SNL also includes background processes that support messaging, security, and service management functions. The SNL is incorporated into SWIFTAlliance WebStation and SWIFTAlliance Gateway (SAG).

SNL establishes a loosely coupled client/server relationship between business application components. Instead of directly invoking methods or functions, the interaction is message-oriented: structured messages are passed between client and server. A business application designed for SWIFTNet services generally consists of a set of clients and servers. The same client or the same server process can be started multiple times. Note that you cannot predict to which process instance of the same application an incoming message request will be delivered. Multiple threads within a client process can invoke the SwCall API function. A server process can have multiple threads as well; however, only one thread can invoke SwCallback. Client and server processes cannot be combined in the same process.

SNL provides a set of transport-level features designed for high availability and high throughput environments. These features include:
 Load balancing
 Location transparency and routing, shielding application components from the underlying transport technology
 Transport-level authentication and confidentiality, packaged within SNL and provided transparently to the application
 Security functions by which business application software may establish end-to-end security (user application to user application), when required.

In terms of programming at the source code level using C++ or Java, there are only two functions: SwCall and SwCallback. SwCall is used by client applications to access server applications through SWIFTNet. SwCallback is used by server applications to respond to clients through SWIFTNet.
The SwCall and SwCallback functions access the functionality of SWIFTNet by passing structured XML messages to and from SWIFTNet. At run-time, SNL includes both software libraries — the code of which executes within the same address space as business application client or server processes — and independent processes (daemons or services), which run in their own address spaces. The software libraries are accessible through the SNL APIs.

%d bloggers like this: