In this section: |
iWay business components used in the construction of a message flow for SWIFT messages include:
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:
The dictionaries from the Ebix are used to transform the structure of a document per SWIFT regulation.
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:
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:
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.
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) |
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.
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
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
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
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, /-?:().,'+
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 |