Components of the iWay Integration Solution for SWIFT

In this section:

iWay business components used in the construction of a message flow for SWIFT messages include:


Top of page

x
Ebix

iWay Software provides various e-Business Information Exchange (Ebix) files used in conjunction with the iWay integration solutions. In iWay Service Manager, the iWay Integration Solution for SWIFT contains several Ebix files, one for each supported SWIFT FIN message.

An Ebix file for SWIFT FIN is named SWIFT_ccyy.ebx, where ccyy is the release year. For example, an Ebix file for the 2009 SWIFT FIN message is named SWIFT_2009.ebx.

For details on the supported SWIFT FIN messages, see Ebix-Supported Transaction Sets.

An Ebix is a collection of metadata that defines the structure of data. The Ebix supplied with the iWay Integration Solution for SWIFT defines the structure of supported SWIFT messages.

Each Ebix includes:


Top of page

x
Preparsers

A preparser is an iWay business component that converts incoming messages into processable documents.

Typically a preparser converts a non-XML document into XML format. The preparser for the iWay Integration Solution for SWIFT converts an incoming SWIFT message to XML format.

There are five preparsers that are provided with the iWay Integration Solution for SWIFT:

The following preparsers can be used in specific situations:


Top of page

x
Preemitter

A preemitter is a logical process that handles a document immediately before transmission.

Typically a preemitter is used to convert an XML document to non-XML format. The XML document is created from SWIFT input data in inbound processing. The iWay Integration Solution for SWIFT uses a preemitter in outbound processing to convert the XML-formatted SWIFT document to a SWIFT formatted document.

The XML structure must be compliant with the schema supplied in the Ebix.

There are two preemitters that are provided for the iWay Integration Solution for SWIFT:


Top of page

x
Validation Report Services

There are two validation report services that are provided with the iWay Integration Solution for SWIFT. The validation report that is returned is structured in XML format and indicates whether the inbound/outbound message is compliant with the SWIFT defined standards. When these validation report services are used, SWIFT structural and network validation is performed.


Top of page

x
iWay Service Manager Channel Configuration

This section provides sample use case iSM channel configurations.

Use Case

Attach Ebix?

iSM Components

Inbound processing with no SWIFT rules validation

Yes

Preparser: XDSWIFTPreParser (com.ibi.preparsers.XDSWIFTPreparser)

Inbound processing with SWIFT rules validation

Yes

Preparser: XDSWIFTPreParser (com.ibi.preparsers.XDSWIFTPreparser)

Service: XDSWIFTValidationReportAgent (com.ibi.agensts.XDSWIFTValidationReportAgent)

Outbound processing with no SWIFT rules validation

Yes

Preemitter: XDSWIFTPreEmitter (com.ibi.preemit.XDSWIFTPreEmitter)

Outbound processing with SWIFT rules validation

Yes

Service: XDIWAYSWIFTXXMLTransformAgent (com.ibi.agents.XDIWAYSWIFTXMLTransformAgent)

Service: SWIFTOutReportAgent (com.ibi.agents.SWIFTOutReportAgent)



x
SWIFT Message Structure

In the SWIFT message structure, blocks 3, 4 and 5 may contain sub-blocks or fields delimited by field tags. Block 3 is optional. Many applications, however, populate this with a reference number so that when the Acknowledgement is returned by SWIFT. it can be used for reconciliation purposes.



x
Basic Header Block

The basic header block has the following format:

{1:    F    01   BANKBEBB   2222   123456}
(a)   (b)  (c)   (d)        (e)    (f)

The basic header block has a fixed length and is continuous with no field separators:

a) Block ID - always '1:'
b) Application ID - F = FIN, A = GPA or L = GPA (logins, etc)
c) Service ID - 01 = FIN/GPA, 21 = ACK/NAK
d) LT address - 12 Characters, must not have 'X' in position 9
e) Session number - added by the CBT (Computer Based Terminal), padded with zeroes
f) Sequence number - added by the CBT (Computer Based Terminal), padded with zeroes


x
Application Header Block

The application header block has a different format depending on whether it is being sent to or from SWIFT.

The input structure (to SWIFT) is:

{2:    I     100    BANKDEFFXXXX    U       3       003}
(a)    (b)   (c)    (d)             (e)     (f)     (g)

This structure has a fixed length and is continuous with no field separators from user to SWIFT.

a) Block ID - always '2:'
b) I = Input
c) Message Type
d) Receivers address with X in position 9 and padded with X's if no branch
e) Message Priority - S = System, N = Normal, U = Urgent
f) Delivery Monitoring - 1 = Non Delivery Warning (MT010)
                         2 = Delivery Notification (MT011)
                         3 = Both Valid = U1 or U3, N2 or just N
g) Obsolescence Period - when a non delivery notification is generated
   Valid for U = 003 (15 minutes)
   Valid for N = 020 (100 minutes)

The output structure (from SWIFT) is:

{2:   O      100   1200   970103BANKBEBBAXXX2222123456   970103  1201   N}
(a)  (b)     (c)   (d)    (e)                            (f)     (g)   (h)

This structure has a fixed length and is continuous with no field separators from user to SWIFT.

a) Block ID - always '2:'
b) O = Output
c) Message Type
d) Input time with respect to the Sender
e) MIR with Senders address
f) Output date with respect to Receiver
g) Message priority


x
User Header Block

The user header block has the following structure:

{3:  {113:xxxx}  {108:abcdefgh12345678}     }
(a)  (b)         ( c)

This is an optional block and is similar in structure to system messages.

a) Block ID - always '3:'
b) Optional banking priority code
c) Message User Reference MUR used by applications for reconciliation with ACK

Other tags exist such as 119 which can contain the code ISITC on an MT521 or 523 providing the sender and receiver are registered to do so with SWIFT. This forces additional code word and formatting rules validation of the body of the message as laid down by ISITC (Industry Standardization for Institutional Trade Communication).

113--> 4 characters (SWIFT x Character Type)Banking Priority (HYnn)H- Highly Urgent, U- Urgent, N- NormalY- Request Receiving, N- Do Not Request Receivingnn- May or may not be used

108--> 16 characters (SWIFT x Character Type)MUR Message User Reference. (1234459898ABC)Used To Reconcile With ACK's

119--> 8 upper case characters or numbersBank User Defined



x
Text Block or Body

This block is where the actual MTnnn message is specified and is what most users will see. Generally the other blocks are stripped off before presentation. The format is as follows:

{4:<CrLf>
:20:123456
:25:123-456789
:28C:102
:60F:C020527EUR3723495,
:61:020528D1,2FBNK494935/DEV//67914
:61:020528D30,2NCHK78911//123464
:61:020528D250,NCHK67822//123460
:61:020528D450,S103494933/DEV//P064118
FAVOUR K. DESMID
:61:020528D500,NCH45633//123456
:61:020528D1058,47S103494931//3841188
FAVOUR H. F. JASSEN
:61:020528D2500,NCHK56728//123457
:61:020528D3840,S103494935//3841189
FAVOUR H. F. JANSSEN
:61:020528D5000,S20023/200516//47829
ORDER ROTTERDAM
:62F:C020528EUR3709865,13
-}

The symbol <CrLf> is a control character and represents Carriage Return/Line Feed (0D0A in ASCII hex, 0D25 in EBCDIC hex). It is a mandatory delimiter in block 4.

The example above is an MT950, Statement Of Cash. Fields specified are in accordance to the appropriate volume of the user handbook, there is one or more for each message category.

The format of field tags is:

:nna:
nn - numbers
a - optional letter which may be present on selected tags
eg - :20:  Transaction Reference Number
     :25: Account Identification
The length of a field is designated thus:
nn      -   maximum length
nn!     -   fixed length
nn-nn   -   minimum and maximum length
nn * nn -   max number of lines times max 
            line length

The format of the data is designated thus:

n      -   Digits
 d      -   Digits with decimal comma
 h      -   Uppercase hexadecimal
 a      -   Uppercase letters
 c      -   Uppercase alphanumeric
 e      -   Space
 x      -   S.W.I.F.T. character set
 y      -   Upper case level A ISO 9735 characters
 z      -   S.W.I.F.T. extended character set

Some fields are defined as optional and if not required they must not be present as no blank fields must be present in the message.

/,word  -   Characters as-is
 […]        -   optional element

For example:

4!c[/30x]   -   fixed 4 uppercase alphanumeric, optionally followed by a slash
                and up to 30 S.W.I.F.T. characters
ISIN1!e12!c -   code word followed by a space and fixed 12 uppercase alphanumerics

In some message types certain fields will be defined as conditional, i.e. if a certain field is present then 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.

Certain fields have different formats dependant on the option which is chosen, which is designated by a letter after the tag number, for example:

:32A:000718GBP1000000,00    Value Date, ISO Currency and Amount
:32B:GBP1000000,00          ISO Currency and Amount

It is important to note that the S.W.I.F.T. standards for Amount formats are, no thousand separators and a comma for a decimal separator.

:58A:NWBKGB2L               Beneficiary S.W.I.F.T. address
:58D:NatWest Bank           Beneficiary full name and address
Head Office
London

115--> 32 characters (SWIFT x Character Type)SWIFT x Character Types= 0-9,a-z, A-Z, /-?:().,'+



x
Trailer Block

A message always ends in a trailer with the following format:

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

It contains a number of fields that are denoted by keywords such as:


iWay Software