This document provides a checklist which is strongly recommended to be used by financial institutions as a basis for setting up bilateral or multilateral agreements for the processing of crossborder customer payments, that is, Credit Transfers transmitted by MT 102 via FIN or FileAct.
It is recommended that all items listed be covered in the bilateral or multilateral agreements. In order to further facilitate the set up of these agreements, common procedures have been defined which financial institutions, if they wish, may override.
The checklist is not intended to provide an exhaustive list of items nor does SWIFT claim any responsibility for it.
Unless otherwise agreed, multiple payment transactions are either expressed in the currency of the sending or the receiving country. If financial institutions wish to accept third currencies this should be bilaterally agreed.
If financial institutions agree to define amount limits to the individual transactions, they should specify them per currency.
If the agreement allows for transactions above amounts to which specific requirements apply, for example, regulatory reporting requirements, these requirements and their formatting should be specified as well in the agreement.
Unless otherwise agreed, direct account relationship between the Sender and the Receiver will be used for the booking of the transactions exchanged. However if they wish, financial institutions may also bilaterally agree to include third reimbursement parties in the settlement.
Whatever the agreement, transactions contained in a same message will be booked in one single entry.
For each currency accepted, the amount limit, the account number(s) used for settlement, if other than the normal one(s), and/or the third reimbursement party(ies) involved, if any, can be indicated in the chart below:
 Currencies accepted |
Transaction amount limit |
Settlement account |
Third reimbursement institutions(s) if any |
|---|---|---|---|
| |
|
|
|
| |
|
|
|
Unless otherwise agreed, financial institutions will accept the charging options as defined and allowed for in the MT 102. If financial institutions wish to accept only one option, this should be bilaterally agreed.
Financial institutions which accept the OUR option should agree on and specify the transaction charges in the receiving country for 'on us' and if applicable 'not on us' payments.
These transaction charges can be an exact amount or formula (percentage) and cover the guarantee and processing of transactions which the Receiver provides to the Sender until the execution in the receiving country up to the posting to the beneficiary's account. The pricing of bank-customer services, for example, for the method of advice - for daily/weekly/monthly statement for instance, being different from institution to institution are considered not to be part of the charges.
| Charges due to: |
Type of payment: on us/not on us |
Charges per message: formula or exact amount |
Charges per transaction: formula or exact amount |
|---|---|---|---|
| |
|
|
|
| |
|
|
|
The above charges are preferably set for each trimester, if necessary semester. Changes to these charges should be announced one month before the end of the term.
The messages sent as from that implementation date, will be subject to the new tariffs of the Receiver.
Unless otherwise agreed, the pre-agreed charges will be included in the MTs 102 exchanged, as appropriate, for information and control purposes and this in a consistent manner.
Unless otherwise agreed, charges will always be expressed in the same currency as the transaction amount(s) and settlement amount of the message.
In case the charges amounts, due to the above rule, are quoted in a currency different to the one specified in the bilateral agreement, the exchange rate should be quoted in the message exchanged.
Unless otherwise agreed, financial institutions will separately indicate in the MT 102 the sum of charges due to the Sender and/or to the Receiver, as appropriate.
The amount settled between financial institutions with the value date specified includes at a minimum the sum of all transaction amounts. Whether the sum of charges due to the Sender and/or Receiver will also be included in the settlement amount, will depend on the agreed settlement procedure for charges. Regarding this procedure, financial institutions can agree that:
| Charges are settled with same value date as the sum of all transaction amounts and booked together |
|
| Charges are settled with same value date as the sum of all transaction amounts but booked separately |
|
| Charges are settled periodically (once ...) |
|
| Other |
|
Only when using the first or second option, the settlement amount will include the sum of charges.
Unless otherwise agreed, credit transfer transactions contained in the same MT 102 should be grouped as follows:
operations with same bank operation code
operations in same currency
operations with same settlement account/institution
operations with same value date
Financial institutions should agree whether only head office or also branches can be the Sender and/or Receiver of the MT 102 and whether FileAct and/or FIN will be used as transmission method:
| |
BIC Bank1 |
BIC Bank2 |
|---|---|---|
| Only head-office |
|
|
| Head office and all domestic branches |
|
|
| Head office and a limited number of domestic branches as listed: only list location code and branch code |
|
|
In case FileAct is selected, financial institutions should agree on the maximum size of the MT 102 and whether more than one MT 102 may be contained within the same FileAct message. Financial institutions should also decide whether an MT 102 can be split over two or more FileAct messages as this may have an operational impact.
| Maximum size of MT 102 |
Number of MT 102(s) per FileAct message |
MT 102 split over two or more FileAct messages |
|---|---|---|
| |
|
|
Financial institutions should agree on the timeframe needed by the Receiver to execute the payments accepted in its country. This timeframe starts counting as of an agreed cut-off time for receipt of incoming messages by the Receiver.
Messages received before cut-off time, will be settled on a pre-agreed day which is a (number of) day(s) following the day of receipt (day of receipt = D). For messages received after cut-off time, the settlement timeframe will be based on D+1.
D will also be the basis for calculating the execution dates (dates when the funds are available to the Beneficiary).
Date of receipt/acceptance = D
| |
Currency 1 |
Currency 2 |
|---|---|---|
| Receiver's cut-off time |
|
|
| Settlement timeframe |
D (+) |
D (+) |
| Execution timeframe for on/us payments (until funds are on the account of the Beneficiary) |
D (+) |
D (+) |
| Execution timeframe for not on/us payments (until funds are on the account of Beneficiary) |
D (+) |
D (+) |
Unless otherwise agreed, financial institutions will take as a basis for their controls/checks all security aspects of FIN or FileAct as well as the MT 102 message syntax and semantics as defined in the MT 102 message specifications.
In order to achieve straight-through processing of the MTs 102 exchanged, financial institutions should define checks and controls relating to the bilaterally agreed items.
Unless otherwise agreed, messages passing the checks and controls, are considered accepted and therefore irrevocable, that is, to be posted to the nostro/loro account. In FileAct, the positive Acknowledgement sent by the Receiver confirms acceptance of the message received. In FIN, no specific message is required.
If messages do not pass the checks/controls, they will be rejected (see the next checkpoint).
Proposed checks and controls, relating to the bilaterally agreed items, performed by the Receiver and their error codes:
| Control/Check |
Yes/No |
Error Code |
|---|---|---|
| Settlement amount |
|
|
| Value date |
|
|
| Sender |
|
|
| Currencies present |
|
|
| Bulking criteria used |
|
|
| Information present in field 72 |
|
|
| Bank operation code |
|
|
| Other |
|
|
Once the message is accepted, further checks are proposed to take place at transaction level. Only if transaction(s) pass the checks, will they be executed. If not, they will be rejected (see the next checkpoint).
Proposed checks and controls performed by the Receiver including error codes prior to the execution of the transactions:
| Control/Check |
Yes/No |
Error Code |
|---|---|---|
| Account number of beneficiary |
|
|
| Transaction amount |
|
|
| Beneficiary bank identification |
|
|
| Length of remittance data |
|
|
| Other |
|
|
For rejects due to a communication failure between the Sender and the Receiver, the existing FIN and FileAct rules apply.
Unless otherwise agreed, messages properly received but failing to pass the message level checks (as defined in the previous checkpoint) will be rejected by the Receiver without further processing. Financial institutions are recommended to use the MT 195 in FIN or the negative acknowledgement in FileAct to advise the rejection. The reject advice should contain at a minimum the reference of the rejected message and the error code(s). The maximum delay acceptable for the Receiver to notify the Sender and possible related charges should be bilaterally agreed.
Unless otherwise agreed, the notification returned to the Sender will exempt the Receiver from processing the message. The Sender will, after correction, resubmit the message.
The return to the originator of transactions being rejected after the message which contained them has been posted to a nostro/loro account (between the Sender and the Receiver), will cause a settlement. Unless otherwise agreed, this settlement will adhere to the following rules:
it should be in the same currency as the original transaction currency
it should take place at a bilaterally agreed value date
the original transaction amount should remain unchanged
the settlement should take place via the same account relationship
normal banking practice prevails.
Financial institutions should agree on a maximum of working days after receipt of the MT 102 for rejecting a transaction and on the charges applied.
The following chart provides details regarding the message/transaction rejects:
| |
Reject of message |
Reject of transaction |
|---|---|---|
| Maximum delay as from moment of receipt to advise the reject to Sender |
|
|
| Charges due to the reject |
|
|
Unless otherwise agreed, messages properly received and accepted are to be considered as irrevocable. Cancellation therefore should be the exception.
If however cancellations are accepted in the bilateral agreement, the following details should be agreed:
| |
BIC of Bank1 |
BIC of Bank2 |
|---|---|---|
| Acceptable delay for the Sender to request cancellation of message |
|
|
| Acceptable delay for acceptance and response by the Receiver to such request |
|
|
| Charges due to the Receiver of such request |
|
|
Financial institutions are proposed to send their request for cancellation by MT 192, for response by MT 196.
The possible interbank costs of the failure are supported by the Sender.
Unless otherwise agreed, financial institutions will use the most up-to-date version of the MT 102 for the transmission of their transactions.
Unless otherwise agreed, financial institutions will implement changes in the message specifications of the MT 102 according to the implementation dates as announced by SWIFT
A Sender who has not done the necessary modifications in time may not be able to correctly format the transactions concerned. In this case, the Receiver is not obliged to execute the transactions. Financial institutions should agree who is liable for any costs arising from the non-execution of these transactions. Unless otherwise agreed, the costs are to be supported by the Sender.
A Receiver who has not done the necessary modifications in time may not be able to process the transactions. The Receiver will remain responsible for executing the transactions. Financial institutions should agree who is liable for any costs arising from the non-execution of these transactions. Unless otherwise agreed, the costs are to be supported by the Receiver.
