This module generates the payment messages and enables the additionally required information for payment messages to be entered.

• Depending on the payment message, the user is able to record additional intermediate parties by loading the names of parties from the address database or by temporarily recording them for the transaction to be finalized.
• Below the address information on the parties, a field is available for entry of the account number. In these fields, either an account number or an IBAN can be entered.
  • The IBAN (International Banking Account Number) is a standardized notation for bank account numbers to simplify the automation of international payments within the clearing clearing systems. The exact structure and length of the IBAN number is country-specific, but each IBAN begins with the double-digit ISO country code and a double-digit checksum. This is followed by a maximum of 30 digits for the account identification, which may consist of letters and/or numbers. One element of the account identification is the clearing code.
  • When selecting, for whom the entry of an account is also possible, a search for suitable parties can be triggered by entering a (partial) IBAN by clicking the icon. The selection is made via the country identification and the clearing code of the party derived from the IBAN. The application verifies the length and checksum of the IBAN for correctness.

The required Payment Messages for the respective Clearing System will be created automatically, depending on what payment type (“Disposition” code in table 3 of the SETMOD Settlement panel) was selected.

* In the DTA format if this has been appropriately configured in the application

The following messages are generated when payments (i.e. credits) are made by third-party banks (i.e. where the disposition code is 'PAC' or 'TGC').

A precondition for the respective disposition code and the associated clearing path are the necessary booking accounts.

• NO (Nostro accounts) or LO (Loro accounts or current accounts) for correspondent banking payments.
• BD (Target2 RTGS clearing account) for RTGS payments in the Euro-System or via the European Central Bank or national central banks.

As far as the content of the messages is concerned, messages are related as below

• Similar to MT 202/400/756 + 202, in Tag :53: is always the sender's correspondent bank as recipient of the MT 202.

Difference to Swift MT:

• Different to Swift MT with Target2 / T2 RTGS only the “serial/ one message” method is allowed.
• Reason: Each message being sent through Target2 RTGS, will be booked by the Target2 RTGS clearing system.

• The T2 RTGS directory only contains banks that can be reached via the T2 RTGS system.
• It can be accessed via Info T2 RTGS directory .
• If a T2 RTGS credit transfer is to be sent to a financial institution, its “T2 RTGS Agent” must be entered as “Receiving Bank (RTGS Addressee BIC)” and it's “T2 RTGS Account Holder (RTGS Account BIC)” must be entered in the static data of the institution T2_RTGS_IDs

The currently usable CBPR+ payment messages support at least all mandatory fields. This was ensured through XSD checks and through Swift's CBPR+ Readiness Portal.

Some newly introduced elements, such as the very detailed address, were not implemented. They wont be needed in traditional trade finance business as usually the business relationship is already established via existing accounts and thus these details are not needed for compliance checks either.

Mentioning the Settlement Method is mandatory in CBPR+ messages as it specifies the details on how the settlement of the transaction between the instructing agent and instructed agent is completed. The application populates this value automatically and therefore the user is not required to worry about choosing the correct method. Below are the applicable codes of settlement method used to settle the credit transfer instruction which is only applicable for disposition code ‘PAC’.

To be used, when settlement is done through a cover payment. It is used for indirect payment with two messages. For example,

• pacs.008 message will be sent to the Beneficiary's bank with settlement method as “COVE” and pacs.009COV message will be sent to the nostro correspondent bank with settlement method as “INDA”
• pacs.009ADV (advice) message is sent to the Beneficiary's bank with settlement method as “COVE” plus a pacs.009CORE message will be sent to the nostro correspondent bank with “INDA”.

To be used when the settlement is done by the agent instructed to execute the payment instruction. That is, when the accounts “Served by” party in the transaction Maintaining Accounts is equal to the party receiving this message (with whom the bank using the application maintains a nostro account).

This could be used for both, a (direct) payment with one message (ex: a single pacs.008) or an indirect two payment Cover method (e.g. pacs.008 and pacs.009COV) and when the credit account is a nostro account.

• 2-payment cover method (pacs.008 with pacs.009COV): When a pacs.008 message is sent to the beneficiary's bank with settlement method as “COVE”, the pacs.009COV message sent to our nostro correspondent bank will use the settlement method “INDA”.

• 2-payment cover method (pacs.009ADV with pacs.009CORE): Where pacs.009ADV message sent to the beneficiary's bank with settlement method as “COVE”. The pacs.009CORE message sent to our nostro correspondent bank will use the settlement method “INDA”.

• 1-payment serial method (single pacs.008): Since this message will be received by our nostro bank, the settlement method will be “INDA”.

• 1-payment serial method (single pacs.009CORE): Since this message will also be received by our nostro bank, the settlement method will be “INDA”.

Not used in the application as the disposition code DAC is used then, which does not generate payment messages.