SWIFT Envelopes
A document envelope consists of control information that enables organizations to effectively exchange messages. This information is added in headers and trailers to messages. Document envelopes are specific to the message protocol used. Creating document envelopes is necessary to use SWIFTNet with your trading partners.
SWIFTNet has only one level of envelope, which you must modify appropriately to reflect your information and your trading partner's information. Envelopes specify whether the message is inbound or outbound:
- The Inbound SWIFT envelope identifies messages that are received by IBM® Sterling B2B Integrator so they can be properly routed. Inbound envelopes also give you the option to translate messages when you choose to check messages for compliance. By choosing to translate messages from within the envelope, you can reduce message processing time because you do not need to specify a separate Translation service step in the business process. You need to create an Inbound SWIFT envelope to configure deenveloping information for MT or MX messages. See Inbound SWIFT envelope.
- The Outbound SWIFT envelope identifies messages so they can be sent to and received by trading partners. You need to configure an Outbound SWIFT envelope to configure enveloping information for MT or MX messages. See Outbound SWIFT envelope.
When you envelope an outbound SWIFTNet message, the SWIFTNet header and trailer are created. For an inbound message, the envelope contains the header information (the trailer information is a summary appended to the SWIFTNet data). The header types are MX or MT messages.
MT and MX messages are included within the Body element. MT messages are base-64 encoded and MX messages are XML.
Sterling B2B Integrator also enables you to use SWIFT XML Format 2, the envelope supported by SWIFT Alliance Access 6.
As part of SWIFTNet enveloping, the Sterling B2B Integrator uses code lists to validate the data. The Sterling B2B Integrator uses code pairs in code lists to identify items in transactions between two or more trading partners. A trading partner code list consists of one or many pairs of code values containing a sender code and a receiver code. Each code pair has one description and up to four additional codes relating to the pair. Code lists are dynamic and are stored in a database.
The SWIFT_FINMessageTypes code list is automatically installed with the Sterling B2B Integrator. This code list contains a list of valid SWIFT message types. The three-digit message number is entered for sender code and receiver code, and the description is set to SWIFT Message Type. However, you need to populate four additional code lists to perform SWIFTNet validations:
- SWIFT_Addresses—used to check the sender and receiver IDs within the message. This code list is shared with message authentication. The code list used is the same code list that is used for message validations. You will type the address in the Sender Code, Receiver Code, and Description parameters, and use the Text1 parameter to indicate the subtype of the address. The SWIFT_Addresses and SWIFT_BaseAddresses code lists are used to differentiate between bad base addresses and bad branch codes when necessary. The SWIFT_Addresses code list is also used for verification of those addresses that are contained within the body of a message. BIC and BEI addresses are validated against entries in the SWIFT_Addresses code list
- SWIFT_BaseAddresses—this is a list of the
8-character address (the BIC minus the branch code) that are valid
as part of a sender address when generating a message. You will type
the eight-digit code in the Sender Code, Receiver Code, and Description
parameters. The SWIFT_Addresses and SWIFT_BaseAddresses code lists
are used to differentiate between bad base addresses and bad branch
codes when necessary. Note: You only need to populate the SWIFT_BaseAddresses code list when you have enabled address verification. See Enabling and Disabling Address Verification.
- SWIFT_Currencies—this is a list of the valid currencies that can be used in a SWIFT message. You will use the Text1 parameter to indicate the maximum number of digits after the decimal point that the currency supports. Amount and Currency values are validated against ISO entries in the SWIFT_Currencies code list.
- SWIFT_Countries—this is a list of the valid countries that can be used as part of the address when generating a SWIFT message. IBAN values and Country codes are validated against entries in the SWIFT_Countries code list.
- SWIFT_IBANFormat—this is a list of specific
IBAN formats that countries may use. This code list is used with BICPlusIBAN
validation.
The details of this code list are as follows:
Note: A plus sign indicates those fields are concatenated together. Underscore and semi-colon characters act as delimiters and are added to the code list data.- Parameter
- Field Name (refers to the name defined in the SWIFT data files)
- SenderID
- IBAN Country Code 3
- ReceiverID
- IBAN Country Code 3
- Description
- IBAN Country Code 3
- Text1
- IBAN Country Code Position 4; IBAN Country Code Length 5
- Text2
- IBAN Check Digits Position 6; IBAN Check Digits Length 7
- Text3
- Bank Identifier Position 8; bank Identifier Length 9
- Text4
- Branch Identifier Position 10; branch Identifier Length 11
- Text5
- IBAN National ID Length 12;
- Text6
- Account Number Position 13; account Number Length 14
- Text7
- IBAN Total Length 15
- SWIFT_BICPlusIBAN and BICPlusIBAN—these
are lists of the clearing codes used for validating BICPlusIBAN combinations
and clearing codes. These lists replace the older BIC+ database (and
in the Sterling B2B Integrator,
the SWIFT_ClearingCodes code list). Depending on which application
you are using, you will use one of these lists. Financial institutions
can look up any missing BICs linked to the IBANs for every financial
institution in the 31 SEPA countries. They can also validate the IBANs
and BICs, including their relationship. Note: The BICPlusIBAN directory is a replacement for the BIC+ database.
The details of this code list are as follows:
Note: A plus sign indicates those fields are concatenated together. Underscore and semi-colon characters act as delimiters and are added to the code list data.- Parameter
- Field Name (refers to the name defined in the SWIFT data files)
- SenderID
- IBAN Country Code 19 + Unique IBAN National ID, or Clearing Code 21
- ReceiverID
- BIC Code 7 + Branch Code 8
- Description
- Institution Name 4
- Text1
- Parent Bank Code 15
- Text2
- IBAN BIC Code 11
- Text3
- IBAN Branch Code 12
- Text4
- Routing BIC Code 13
- Text5
- Routing Branch Code 14
- Text6
- Subtype Indicator 15
- Text7
- Service Codes 26
- Text8
- CHIPS UID 24
- SWIFT_SEPARouting—this contains the SEPA
Routing Directory. With the SEPA Routing Directory, banks sending
SEPA payments can verify whether the operational BICs of their correspondent
are SEPA-adherent and operationally ready for SEPA, and can verify
the channel through which they can be reached for routing payments.
Therefore, the SEPA Routing Directory provides the operational information
necessary to exchange SEPA payments with the institutions listed in
the EPC Register of Participants. As recommended by the EPC, the directory
only contains data related to adherent institutions whose reference
BIC is published in the EPC Register of Participants. The directory
contains information on receiving banks that are SEPA compliant and
shows the supported channels for each, across Clearing and Settlement
Mechanisms (CSMs), Automated Clearing Houses (ACHs), and intermediary
banks. The details of this code list are as follows: Note: A plus sign indicates those fields are concatenated together. Underscore and semi-colon characters act as delimiters and are added to the code list data.
- Parameter
- Description
- SenderID
- BIC Code 4 + Branch Code 5 _ Service Level 9 _ Scheme Instrument 10
- ReceiverID
- BIC Code 4 + Branch Code 5 _ Service Level 9 _ Scheme Instrument 10
- Description
- Institution Name 6
- Text1
- Branch Code 5
- Text2
- Service Level 9
- Text3
- Scheme Instrument 10
- Text4
- Country Code 8
- Text5
- Operational Readiness Date 12
- Text6
- Valid From; Valid To 18
- Text7
- Adherent Institution Flag 11
- Text8
- Intermediary Institution BIC 16
- Text9
- [Payment Channel Id 13 : Reachability Type 15: Preferred Channel Flag 14]0-n
- NISOLanguage—Language codes are validated against ISO entries in the NISOLanguage code list.
See Maintain the External Code Lists.
SWIFT codes list validations are applied to both SWIFT MT and MX messages for currencies, country codes, BIC/BEI addresses, and International Bank Account Number checksum validation (IBAN). The Sterling B2B Integrator allows you to define codes lists for currencies, countries, and BIC or BEI addresses (which are validated against the SWIFT_Addresses code list). IBAN data contains a country code that is validated against the SWIFT_Countries code list in the Sterling B2B Integrator, and additional IBAN validation is handled internally by the translator.
The validation of the SWIFT special functions <CUR>, <SWIFTBIC>, <NON-SWIFTBIC>, <CC>, and <IBAN> use these code lists. You must update and maintain these codes lists, as necessary.
For outbound SWIFTNet messages, you also need to configure the EDI Encoder service to include the proper values for the following parameters:
- AccepterLookupAlias
- ReceiverID
- SenderID
- ReceiverIDQual
- SenderIDQual
See Configuring the EDI Encoder Service for SWIFT Outbound Messages.