Friday, December 29, 2017

File Transfer : File components

File components
• The file transfer header The part of a file transfer request that contains information about the file transfer, such as destination, compression information, delivery type, and so on. The data file usually immediately follows the file transfer header.
• The data file The business content of a file transfer. Parties that receive file transfer headers only do not receive files.

Main file types
• Data file The file exchanged over SWIFTNet.
• Companion parameter file When sending a file using file transfer adapter, a companion parameter file travels along with the data file from the business application to the Alliance Gateway host that processes the data files. A companion parameter file can contain extra information, such as local authentication information, override values, and header information. When receiving a file, the file transfer adapter can generate a companion parameter file to include details contained in the file transfer request header.
• XML parameter file On the sender side, a business application generates an XML parameter file that contains arguments to pass to an FT command or a local transfer agent command.
• Generated XML parameter file Local transfer agent commands store output in generated XML parameter files. A business application that receives such a generated XML parameter file can analyse it to either accept or reject a file transfer request, or to perform additional processing of the transferred file.
• Report file A report file reports about the processing status of a data file
The table that follows gives an overview of the file transfer interface file exchange modes that are possible. The sections that follow provide more information about the exchange modes in this table.

File transfer interface

File transfer interface Alliance Gateway provides the file transfer interface to configure and manage licensed file transfer products: file transfer adapter and file transfer integrated. Both file transfer adapter and file transfer integrated can be present on the same instance of Alliance Gateway.

You can use the Alliance Gateway Administration interface that is available through Alliance Web Platform to access the file transfer interface.

File transfer adapter
File transfer adapter is a licensed product that automates file transfer between correspondents over SWIFTNet. The business application just has to make the file available on the Alliance Gateway host, and the file transfer interface automatically transfers the file over SWIFTNet, using file transfer adapter configuration data.

File transfer integrated
File transfer integrated is a licensed product that can be integrated with the business application through a third-party file transfer connecter: the business application or file transfer connecter can offer automation. To transfer a file over SWIFTNet, the business application must make the file available on the Alliance Gateway host, invoke a file transfer command (ft command), and pass all file transfer parameters to the ft command.

Real-time transfers
With real-time transfers, both parties must be connected to SWIFTNet at the same time. A connection is established between the sender and the receiver, and the file transfer software attempts to transfer the files from one party to the other through SWIFTNet.

Store-and-forward transfers
Sender and receiver do not require to be connected to SWIFTNet at the same time for a storeand-forward file transfer to succeed. The requester sends a file to SWIFT, where it is queued on a SWIFTNet store-and-forward system. When the receiver has acquired the queue, or if the queue was already acquired, then the SWIFT store-and-forward system delivers the files in the acquired queue. Queues are therefore specific to store-and-forward transfers. They are set up on the SWIFTNet store-and-forward system, where they store files from senders and queue the files that are
ready to be delivered to the receivers


Friday, December 22, 2017

MT 671 Standing Settlement Instruction Update Notification

The MT 671 Standing Settlement Instruction (SSI) Update Notification message is sent by SWIFT to an institution as a result of receiving an MT 670 Standing Settlement Instruction Update Notification Request. The MT 671 is created from the corresponding MT 670. The MT 671 is a notification of an SSI update from the party identified in the message as the Submitting Party to:
  • one or more institutions or
  • all institutions in one or more countries or
  • all institutions.
The MT 671 specifies standing cash settlement information for the account of the Submitting Party or on behalf of another party. The party and account information in the SSI is then used in FX confirmations, payments messages, etc.
The MT 671 is sent by SWIFT to one or more institutions as defined in the MT 670:



Thursday, December 21, 2017

MT 950 Statement Message

MT 950 Scope

This message type is sent by an account servicing institution to an account owner.
It is used to transmit detailed information about all entries, whether or not caused by a SWIFT message, booked to the account.

MT 950 Format Specifications

Status Tag Field Name Content/Options No.
M 20 Transaction Reference Number 16x 1
M 25 Account Identification 35x 2
M 28C Statement Number/Sequence Number 5n[/5n] 3
M 60a Opening Balance F or M 4
----->
O 61 Statement Line 6!n[4!n]2a[1!a]15d1!a3!c16x[//16x]
[34x]
5
-----|
M 62a Closing Balance (Booked Funds) F or M 6
O 64 Closing Available Balance (Available Funds) 1!a6!n3!a15d 7

MT 950 Network Validated Rules

  • C1 The first two characters of the three character currency code in fields 60a, 62a and 64 must be the same (Error code(s): C27).

MT 950 Usage Rules

  • Charges, interest and other adjustments may be referenced as follows:
    • By reference to a previous MT n90 Advice of Charges, Interest and Other Adjustments message (for information regarding the formatting of the MTn90, see Category n - Common Group Messages).
    • By original advice via this statement, under the following conditions:
      • The charges must be unambiguously identified with a single associated underlying transaction, for example, the account owner's reference of the original transaction.
      • The principal amount must be separately identified on the statement.
      • The required references must fit the constraints of the statement line.
  • It is important that amounts should be identical to those of related messages. Charges which are clearly indicated in another message concerning the same entry, or which form an integral part of another message, for example, proceeds of a collection, do not need to be specifically indicated in the statement. Deductions, for example, charges, above and beyond those previously accounted for in a related message shall appear separately with the appropriate code. They shall use the same reference for the account owner or other suitable reference if no reference for the account owner is available.
  • The account servicing institution must not 'bulk' separate transactions, charges, or charges with transactions. When booking multiple messages, individual transactions, for example, one entry per TRN (field 20), must be booked.
  • It is recommended that statements be sent daily, that is, at the end of each business day, when movement in the account has occurred. If no movement has occurred, that is, no entries have been posted, it is recommended that the statement frequency should be monthly, and that the maximum interval between statements should not exceed one year.
  • To facilitate manual reconciliation, it is recommended that statement entries be sorted by debits and credits and these by value date in ascending amounts.
  • Since the length of a SWIFT message is restricted to the maximum input message length, several messages may be required to accommodate all the information for one statement

MT 940 Customer Statement Message

This message type is:
  • sent by an account servicing institution (reporting institution) to a financial institution (concentrating institution), which has been authorised by the account owner to receive it.
  • sent by an account servicing institution (reporting institution) to a financial institution account owner.
  • sent by an account servicing institution to a non-financial institution account owner or party authorised by the account owner to receive the information.
  • sent by a concentrating institution to a non-financial institution account owner or party authorised by the account owner to receive the information.
It is used to transmit detailed information about all entries booked to the account.

MT 940 Format Specifications

Status Tag Field Name Content/Options No.
M 20 Transaction Reference Number 16x 1
O 21 Related Reference 16x 2
M 25a Account Identification No letter option or P 3
M 28C Statement Number/Sequence Number 5n[/5n] 4
M 60a Opening Balance F or M 5
----->
O 61 Statement Line 6!n[4!n]2a[1!a]15d1!a3!c16x[//16x]
[34x]
6
O 86 Information to Account Owner 6*65x 7
-----|
M 62a Closing Balance (Booked Funds) F or M 8
O 64 Closing Available Balance (Available Funds) 1!a6!n3!a15d 9
----->
O 65 Forward Available Balance 1!a6!n3!a15d 10
-----|
O 86 Information to Account Owner 6*65x 11

MT 940 Network Validated Rules

  • C1 If field 86 is present in any occurrence of the repetitive sequence, it must be preceded by a field 61. In addition, if field 86 is present, it must be present on the same page (message) of the statement as the related field 61 (Error code(s): C24).
  • C2 The first two characters of the three character currency code in fields 60a, 62a, 64 and 65 must be the same for all occurrences of these fields (Error code(s): C27).

MT 940 Usage Rules

  • This message should only be used if the account owner(s) have authorised the financial institutions to transmit such information. It must be used according to agreed criteria.
  • Financial institutions which receive this message must not use the information for their own purposes.
  • It is important that amounts be identical to those of the original transaction. For identification purposes, deductions, for example, charges above and beyond those previously accounted for, shall appear separately with the appropriate code. They shall use the same TRN as the original transaction, or other suitable reference if no TRN is available.
  • Since the length of a SWIFT message is restricted to the maximum input message length, several messages may be required to accommodate all the information for one statement.
SWIFT Documentation
Created: 23-May-2016

Alliance Access Monitoring

Alliance Access Monitoring provides operators with a consolidated view on situations which require attention and draws the operators' attention on abnormal situations from both the monitoring repository and the event log. This is achieved by providing operators with a consolidated list of exceptions and alarms. The list of exceptions and alarms allows operators to easily focus on the situations which require their attention. The entries in the list which are considered as abnormal situations are marked with a special colour. Abnormal situations include the monitored objects in exceptional state and alarms for action or alarms for information.

Monitored entities and events You can monitor activities that relate to Alliance Access and customise the view of monitored entities and events.
You can monitor the following entities and events:
Monitored element