FileAct.
IFT.This section provides a checklist for MT 101 payments. It is strongly recommended that these guidelines be used by financial institutions as a basis for establishing bilateral or multilateral agreements for the processing of request for transfer payments, ie payments transmitted by MT 101 via FIN, or FileAct.
IFT.
It is also 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.
Bilateral Agreement 1:
Amends an existing agreement between the receiving financial institution and the ordering customer.
This agreement establishes the receiving financial institution's authorisation to accept and act upon ordering customer requested payment instructions received from the sending financial institution. Responsibility of effecting the actual movement of funds is an obligation of the receiving financial institution.
Bilateral Agreement 2:
Amends an existing (electronic payments link) agreement between the sending financial institution and the ordering customer.
This agreement must clarify the obligations of the sending financial institution, including ensuring the integrity of the message received from the ordering customer, and the monitoring of the delivery of the message to the receiving financial institution.
The agreement should also state that the liability of the sending financial institution is limited to the delivery of this message to the SWIFT network in a timely manner. In other words the sending financial institution is not liable for the actual payment.
Bilateral Agreement 3:
Establishes a bilateral agreement between financial institutions exchanging request for transfer messages.
This agreement, if necessary, should further clarify the inter-bank responsibilities of the financial institutions involved in the request for transfer payment flow.
Bilateral Agreement 4:
Establishes a bilateral agreement between the account servicing financial institution and the instructing party/ordering customer.
This agreement, when used, allows the account owner to authorise the account servicing financial institution to effect the transfers ordered by the ordering customer or instructing party.
When financial institutions agree to define amount limits on the individual transactions, their limits should be specified per currency.
When the agreement allows for transactions above amounts to which specific requirements apply, eg regulatory reporting requirements, these requirements and their associated formatting should also be specified in the agreement.
There are three charging options as defined for use in the MT 101, ie OUR, SHA, BEN.
These charges can be an exact amount or formula (percentage). The charges cover the guarantee and processing of transactions which the Receiver provides to the Sender, up to the transactions posting to the Beneficiary's account, or execution of payment to the beneficiary's account with institution. The pricing of incidental bank-customer services, eg the method of advice for daily/weekly/monthly statements, and their subsequent charging, which may differ from institution to institution, are not considered to be part of the charges.
| Charges due to |
Charges per message (*) |
Charges per transaction (*) |
|---|---|---|
| |
|
|
| |
|
|
| (*) formula or exact amount |
||
The sending financial institution and the receiving financial institution should agree on the time frame needed by the Receiver to execute the payments accepted in its country. This time frame starts as of an agreed upon cut-off time for receipt of incoming messages by the Receiver.
Messages received before the Receiver's cut-off time, will be settled on a pre-agreed upon day which is X number of days following the day of receipt D. For messages received after the Receiver's cut-off time, the settlement time frame will be based on D+1.
D will also be the basis for calculating the requested execution date, ie the date on which the ordering customer account is to be debited.
| |
Currency 1 |
Currency 2 |
|---|---|---|
| Receiver's cut-off time |
|
|
| Settlement time frame |
D (+) |
D (+) |
| Execution time frame for on/us payments (until funds are on account of Beneficiary) |
D (+) |
D (+) |
| Execution time frame for not on/us payments (until funds are on the account of Beneficiary) |
D (+) |
D (+) |
Explanation:
| D = |
Date of acceptance and receipt, meaning the message is received by Receiver before their cut-off time; |
| -or- |
|
| D = |
Date of receipt, and, D + 1 = date of acceptance, meaning the message was received after the Receiver's cut-off time on D. |
Unless otherwise agreed, financial institutions will take as a basis for their controls/checks all current security aspects of FIN or FileAct
In order to achieve straight-through processing of the MT 101s exchanged, financial institutions should define checks and controls related to the bilaterally agreed items.
Unless otherwise agreed/required, transactions passing the checks and controls are considered accepted and therefore irrevocable, ie to be posted to the ordering customer account at the Receiver. In FileAct,
If transactions do not pass the checks/controls, they will be rejected (see section 5 below).
Checks and controls performed by the Receiver, including error codes prior to the execution of the transactions:
| Checks/Controls |
Yes/No |
Error code |
|---|---|---|
| Transaction amount |
|
|
| Requested execution date |
|
|
| Validity of sending financial institution |
|
|
| Account number/validity of ordering customer |
|
|
| Currency present |
|
|
| Account number/identification of beneficiary |
|
|
| Remittance data (Length/Code) |
|
|
| Instructing code |
|
|
| Account balance |
|
|
| Credit limit |
|
|
| Other |
|
|
For rejects due to a communication failure between the Sender and the Receiver, the existing FIN and FileAct
Unless otherwise agreed, messages properly received but failing to pass the checks as defined in section 4 (see above) will be rejected by the Receiver without further processing.
When advising of the transaction/message rejection in FIN, financial institutions are recommended to use either the MT 195, or another message type which follow the SWIFT payment reject guidelines. InFileAct,
The reject advice should contain, at a minimum, the reference of the rejected transaction/message and the corresponding error code(s). The parties should bilaterally agree the maximum delay acceptable for the Receiver to notify the sending financial institution, as well as possible related charges.
Unless otherwise agreed, the notification that is returned to the Sender exempts the Receiver from processing the message. The sending financial institution will, after correction, resubmit the transaction/message.
The return of a rejected transaction/message to the sending financial institution after the transaction/message has been posted to an account of the ordering customer at 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 ordered transaction amount should remain unchanged
the settlement should take place via the same account relationship(s)
normal banking practice prevails.
All subscribers should agree on a maximum number of working days after receipt of the MT 101 for rejecting/returning a transaction/message, and on the associated charges to be applied.
The following chart provides details regarding the transaction/message reject/return:
| |
Reject |
Return |
|---|---|---|
| Maximum delay from moment of receipt to advice of the reject/return to Sender |
|
|
| Charges due to the reject/return |
|
|
A Reject occurs when the message and/or transaction has not yet been booked, ie, accounting has not yet taken place.
A Return occurs when the message and/or transaction has already been booked, ie, accounting has already taken place.
Unless otherwise agreed or required by law, 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 upon:
| |
Details |
|---|---|
| Acceptable delay for the ordering customer to request cancellation of message |
|
| Acceptable delay for acceptance and response by the Receiver to such a request |
|
| Charges due to the Receiver as a result of such a request |
|
It is recommended that request for cancellations be sent by MT 192 and responded to by MT 196.
