ISO 20022/SWIFT inbound enveloping concepts

Inbound ISO 20022/SWIFT envelopes identify messages that are received by ITXA so that messages can be properly matched and routed.

An inbound ISO 20022/SWIFT envelope configures de-enveloping information for MT or MX messages. It also gives you the option to translate messages when messages are checked for compliance, reducing message processing time.

Envelope levels

ITXA supports the following levels of inbound envelopes for financial standards:
  • Bulk, an outer envelope at the Interchange (or message) level, for ISO 20022/SWIFT, SWIFT MX, ISO 20022, or SEPA.

    A bulk envelope is required to process a message that includes a business header (FIN, SAA XML Format 2, or ISO) around the message. A business header contains sender and receiver data, such as the sender reference that is used for reconciliation, send date, and so on.

    For SWIFT MT messages, the bulk envelope is mandatory and is the only envelope that applies.

    Business headers are also supported in Sterling B2B Integrator

  • ISO 20022 level

    ISO 20022 envelopes are supported for inbound processing and can be used whether or not business headers exist. This level applies to SWIFT MX, SEPA, or ISO 20022 messages.

    ISO 20022 envelopes are used for transaction splitting. The presence of a business header is used to narrow the list of candidate ISO 20022 envelopes, based on the presence of a sender ID and a receiver ID.

FIN and XML Format 2 envelope formats

Envelope formats are referred to as FIN or XML Format 2:
  • A FIN envelope applies to MT messages only.
  • An XML Format 2 (XML2) envelope designates an MX message. As used in ITXA, MX messages include SEPA or SWIFT ISO20022 messages that have an XML Format 2 header. That is, SEPA, ISO 20022, and MX messages are handled in an equivalent manner.

Matching

Matching refers to the process of selecting an envelope for a message based on the data that is extracted from that message. Depending on the envelope level, matching can be done on the Sender ID, Receiver ID, Message Type, and envelope type.

Matching on a SWIFT or SEPA bulk envelope is done on the sender and receiver ID information

Draft comment:
(what about message type and envelope level)
that is contained in the business header. If a bulk envelope is a match for the parameters that you have configured, you can use it to process the entire message (including compliance checking, routing it through drivers or error drivers, and other actions) based on the bulk envelope setting that matches the business header.

Matching on an ISO 20022 envelope is a two-part process:
  1. The first pass, on sender and receiver ID, results in a list of potential match candidates.
  2. If an accepter alias is configured, a second pass narrows the list of potential matches.

For examples, see De-enveloping scenarios.

If more than one envelope matches a message successfully, the envelope with the greatest number of matching criteria is matched to the message. If more than one envelope matches an equal number of criteria (for example, two envelopes match on four different criteria each), an ambiguous envelope condition is reported.

If a message contains a business header, the sender ID and receiver ID information is automatically supplied as matching criteria along with the message type (example: pain.001.001.003) to use to look up a matching inner envelope.

If there is no business header, there is no sender ID or receiver ID to apply. In this case, messages are matched to ISO 20022/SWIFT envelopes by message type. Because this matching can result in a large number of envelopes, you can filter potential matches further by specifying the AccepterLookupAlias parameter.

Draft comment:
The ISO 20022/SWIFT envelope is then matched on the data content of the message. That is, matching criteria from a matching envelope is used for lookup.

Use of the AccepterLookupAlias in matching

Terminology note: AccepterLookupAlias can be used for either Bulk and ISO 20022 envelopes. References to NoBulkLookAlias refer to the ISO 20022 envelope.

The AccepterLookupAlias can be used to avoid an ambiguous envelopes condition for Bulk envelopes where more than one envelope exists in the repository with matching sender/receiver IDs and message type.

The AccepterLookupAlias lookup alias definition is based on how you choose to group your envelopes together. For example, if you have a group of envelopes that you customarily use for messages that arrive from a certain branch office, you can define an alias for that particular group.

With the lookup alias defined and the parameter set, runtime behavior is different. Instead of obtaining all of the candidate envelopes for this message type, for example pain.001.001.003, ITXA select all of the candidate envelopes that match the message type and that have the alias set appropriately.

For example, you can define an envelope for Customer A. You would put customer_A as the alias, and you would set it for your host application.

Compliance checking

Draft comment:
When map can be rearranged, move up (in prominence) per Fritz.

A message or transaction is compliant when it passes either the WebSphere® Transformation Extender compliance check or schema checking.

There are three types of compliance checking:
  1. WTX Compliance Checking: This applies to the JVC component (for MT messages), or the compliance maps that are supplied by ITXA for SWIFT MX and SEPA messages.
  2. Custom schema checking: A schema that you supply and check into the repository.
  3. Custom compliance map: A map that you write that is used for a non-mandatory rule book (for example, Funds and Cash Management) but that is mandatory for your business practices.
You can check compliance at two different levels:
  1. On the message itself (the Interchange), which is handled by the settings in the Bulk envelope. Compliance check options in the Bulk envelope apply to the Interchange (message) itself.
  2. On each individual transaction, which is controlled by the matching ISO 20022 envelope.

    This can apply to transactions whether the transactions are split or not. (For example, where there is not an XML Format 2 header.)

    An ISO20022 envelope includes parameters for checking BIC addresses, checking SEPA parameters, or schema checking to match to an individual split transaction.

The option also exists to check compliance at both levels, although there is generally no need to do so. If you check at the Interchange level, checking at the transaction level is redundant.

Based on the level at which compliance checking is performed, you can accept the transaction, accept the interchange or message, or accept both. The overall status of the service is controlled by two parameters, at the bulk level and ISO 20022 envelope level, respectively: Accept non-compliant interchanges and Accept non-compliant transactions.

It is possible to accept noncompliant transactions, but still flag an error for a noncompliant interchange. Different combinations yield different results for the overall status, based on (1) the parameter combinations and (2) whether your data contains compliance errors. Some common scenarios are described in De-enveloping scenarios.

Whether or not transactions are split is also determined by the compliance status if the compliance check is done by the outer Bulk envelope. If no compliance check is done by the Bulk envelope, splitting still occurs if there are matching ISO 20022 envelopes. It is still possible to allow splitting to commence if the Bulk envelope detects errors with a compliance check by setting the parameter Split Transactions for Non-Compliant Interchanges.

Message and Transaction modes in ISO 20022 envelope processing

The ISO 20022 transaction processor has two modes: Message and Transaction. These modes determine whether individual transactions are persisted as separate documents, and use of these modes is based on whether transaction splitting is turned on.

By default, message mode takes precedence. If any ISO 20022 envelopes that match the message content do not have SplitTransactions set to Yes, the message is processed in Message mode. Message mode is also used when SEPA compliance checking is done, since the size of SEPA documents precludes transaction splitting.

Message mode also allows a customer to perform validation only (without transaction splitting) on a message that does not contain a business header. Message mode allows for one matching envelope only, which is used to process the entire message.

Transaction mode allows for multiple envelopes to be used in the splitting process. Therefore, it is possible to use different transform maps with individual split transactions if different envelopes match those respective split transactions. Likewise, since different envelopes can match individual transactions, it is possible to set up different validation and downstream routing criteria on a per-transaction basis.

Draft comment:
Fritz suggested that this section go to enveloping concepts.

Using wildcards in inbound envelopes

If a parameter value is "wildcarded" and represented by * (an asterisk), any value that is given for that parameter in the input document is considered a match. An empty value for a parameter means that the value must also be missing or empty for that parameter in the input document in order for a match to occur.

The Sender ID, Receiver ID, message type, and envelope format parameters can use wildcard values.