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


Thursday, November 9, 2017

How to test the next Standards Release in Future Mode on your Alliance Access or Alliance Entry

Description
Before the next Standards Release, SWIFT provides a test period during which you can try out the new syntax. You find the Specifics on the roll-outschedule of the Test and Training system for the next SWIFTStandards published on swift.com. How can you configure your Alliance Access or Alliance Entry to test with the different modes available?
Information
1. Login your Test and Training LT (must have the future message syntax assigned) 2. Send an APC 072 message choosing any of the following options for field 127:
FC: Full Function Mode, Current
Test and Training users can exchange messages with themselves or with any other Test and Training user with the current message syntax.In this mode, all normal usage restrictions apply, as on the live network.
FF: Full Function Mode, Future
Test and Training users can exchange messages with themselves or with any other Test and Training user with the future message syntax. Inthis mode, all normal usage restrictions apply, as on the live network.
LC: Local Test Mode, Current
 A Test and Training user can test with the FIN system only, it will use the current message syntax. A Test and Training user can receivemessage samples, or can send messages that are validated and that are stored, but that are not delivered.
LF: Local Test Mode, Future
 A Test and Training user can test with the FIN system only, it will use the future message syntax. A Test and Training user can receive message samples, or can send messages that are validated and that are stored, but that are not delivered. You can switch between the different available modes by sending an APC 072 message before the FIN Select. In that MT 072, you specify the exact mode that you want to use for your FIN session.3. Select your Test and Training LT choosing as Test Mode Selection,
Full Function Mode
or
Local Test Mode
depending on what you have selected on the APC 072 message. If you have selected


Local Test Mode
then you must not select any delivery subsets.
Important Note :You can receive an error code H30 (Message type does not exist for this application) when sending the MT 072 if you send the MT 072 after having logged and selected the logical terminal rather than having performed the login only.
Correct sequence is: login your Test and TrainingLT, send MT 072, select your Test and Training LT.If the LT gets interrupted, the reconnect will be done (if auto reconnect is enabled) using the same FIN session number and the LT remainstherefore in same mode (e.g. Full Future Mode) As soon as a Logout has been done or an Abort of the LT occurred, the LT is automatically back into the default mode, which is Full Currentmode.When you need to work in a different mode than Full Current mode, "automatic Select" usage is not appropriated as you need to getsystematically APC 072 message already sent and acked before the select FIN is sent. Use manual mode instead..When you exchange T&T FIN messages with your counterparties, make sure that the sender and receiver are both using the same FullFunction mode (either both current, either both future) as FIN maintains separate delivery queues for current-format and future-formatmessages.For more information about the available options for these test facilities, see the SWIFT
User Handbook, FIN Service Description, Test & Training
.Related information
Tip 1518163: How to request a message from the tank file (https://www2.swift.com/support/knowledgebase/tip/1518163)

Standard MT Release 2017 - Category 3 messages for NDF and NDO

The MT 300 is used to confirm trades in several FX products, including Non-Deliverable Forwards (NDF).  NDFs
are also supported by the MT 304 and Non-Deliverable Options (NDO) by the MT305.  As part of SR 2017, mandatory standards changes have been made to the way that NDFs and NDOs are supported in these messages.
NDFs and NDOs have long been supported using code-words in free format fields.
This has led to poor usage by many senders, which in-turn has caused operational and settlement overheads and risks.
Non-deliverable trades (MT 300, MT 304, MT 305): Addition of new fields to be used for nondeliverable trades
(NDF and NDO). These fields replace the existing use of codes in free format fields and from SR 2017 messages containing the codes will receive a NAK. OTC Derivatives (MT 300, MT 304, MT 305, MT 306, MT 340, MT 341, MTs 360 – 365):  
• Addition of optional field 35B in which an ISIN can be specified • Addition of several new reporting jurisdiction
codes MT 300 Foreign Exchange Confirmation and MT 304 Advice/Instruction of a Third Party Deal: Addition of an optional field for use in the context of market infrastructures, to allow the sender to specify the session or service in which the trade should
be processed.
MT 305 Foreign Currency Option Confirmation: Addition of text to clarify that for a nondeliverable option the
valuation date is the same is the expiry date.




Sunday, September 17, 2017

SWIFT gpi


MT 103 Single Customer Credit Transfer

The MT 103 is a General Use message, that is, no registration in a Message User Group (MUG) is necessary to send and receive this message. It allows the exchange of single customer credit transfers using all MT 103 fields, except field 77T (Envelope Contents). The MT 103 can be straight through processable if the message is properly formatted according to pre-agreed bilateral/multilateral rules.
Two variants of the MT 103 exist and these are document separately:
  1. The MT 103 STP is a general use message, that is, no registration in a MUG is necessary to send and receive this message. It allows for the exchange of single customer credit transfers using a network-validated, restricted set of fields and format options of the MT 103 to make it straight through processable.
  2. The MT 103 REMIT requires registration in the Extended Remittance Information MUG. This MUG allows its subscribers to exchange MT 103 REMIT messages with an extended amount of remittance information in the additional field 77T Envelope Contents. This remittance information may optionally be exchanged in a non-SWIFT format, such as EDIFACT or ANSI-X12.

MT 103 Guidelines

If the Sender and the Receiver wish to use their direct account relationship in the currency of the transfer, then the MT 103 message will contain the cover for the customer transfer as well as the payment details.
  • If the Sender and the Receiver have no direct account relationship in the currency of the transfer or do not wish to use their account relationship, then third banks will be involved to cover the transaction. The MT 103 contains only the payment details and the Sender must cover the customer transfer by sending an MT 202 COV General Financial Institution Transfer to a third bank. This payment method is called 'cover'.
  • Where more than two financial institutions are involved in the payment chain, and if the MT 103 is sent from one financial institution to the next financial institution in this chain, then the payment method is called 'serial'.
  • If the Receiver does not service an account for the beneficiary customer, and no account servicing institution is indicated, nor any alternative instructions given, then the Receiver will act upon the customer credit transfer instruction in an appropriate manner of its choice.
  • In order to allow better reconciliation by the beneficiary customer, the MT 103 supports full charges transparency and structured remittance information.
  • In order to allow better reconciliation by the Receiver, the MT 103 gives an unambiguous indication of the interbank amount booked by the Sender/to be booked by the Receiver.
  • The MT 103 gives the Sender the ability to identify in the message the level of service requested, that is, what service is expected from the Receiver for a particular payment, for example, SWIFTPay, Standard or Priority or any other bilaterally agreed service.
  • The message also allows for the inclusion of regulatory information in countries where regulatory reporting is requested.
  • Courtesy: SWIFT
  • Friday, February 24, 2017

    SWIFTNet Profiles


    SWIFTNet Profiles


    SWIFTNet Profiles
    Field
    Description
    Filtering criteria
    Ex
    Indicates if the emission or reception profile is in an exceptional state

    Type
    The type of SWIFTNet profile

    Name
    The emission profile or reception profile name

    Status
    The status of the profile
    These are the possible values:
    ·         Enabled
    ·         Disabled
    Mode
    Indicates the mode in which the emission profile or the reception profile is. In Alliance, there are two modes in which an emission profile or a reception profile can operate. The two modes of operation are Manual and Automatic. The automatic mode allows you to schedule operations. When the emission profile or the reception profile is operating in manual mode, none of the scheduled operations are activated.

    Session Status
    The session status of the emission profile or reception profile.
    These are the possible values:
    ·         Active: The profile has been activated and the session for this profile is in progress.
    ·         Inactive: The profile has been deactivated and the session is inactive.
    ·         Activating: The profile was inactive, the profile is in the process of being "activated".
    ·         Deactivating: The profile was active, but the session has been interrupted and the profile is in the process of being "deactivated".
    ·         Interrupted: The profile was active, but the session has been interrupted. The system attempts to resume the session automatically.
    Number of Messages
    The number of messages received or sent
    These are the possible values:
    ·         Received Messages > 0
    ·         Sent Messages > 0
    Urgent
    The number of urgent messages queued

    Normal
    The number of normal messages queued

    Sent
    The number of messages successfully sent in the current session

    Received
    The number of messages successfully received in the current session

    Connection
    The name of the current connection used for emission or reception

    Thursday, February 23, 2017

    Deleting an Authorisation

    This procedure provides instructions for deleting authorisations. You delete an authorisation by deleting an Authorisation to Send. On your correspondent's system, this action is recorded as the rejection of an authorisation.

    Users and permissions

    You can delete authorisations when the Delete Auth function is assigned to you in the Relationship Mgmt application.
    The following permissions restrict the business relationships that you can access:
    • Allowed/Prohibited Destination(s)
    • Allowed/Prohibited Service(s)

    Before you begin

    Before deleting a Test and Training Authorisation to Send, ensure that the Signing BICs are defined in the authorisation. The Relationship Management application displays a warning message if the Signing BICs are empty. For more information about specifying the Signing BICs for a Test and Training authorisation,

    To delete an Authorisation to Send:

    1. Select an authorisation that has the status "Enabled" or "Deleted".
      You can select the authorisation in the following windows:
      • Authorisation - Relationship Management
      • Authorisations
    2. From the Authorisation menu, select Delete.
      The Delete Authorisation to Send window appears.
      The Deletion Code is always xrma.003.4 - Record deleted.
    3. In the Reason for deletion field, explain why you are deleting the authorisation.
      Note
      If you are deleting an authorisation that has the status "Deleted", then the previous reason for deletion appears. You cannot edit the reason.
    4. If you need another user to approve the Delete action, then select the Needs delete approval option box.
      Note
      The Needs delete approval option box is selected and unavailable when you have the Bypass Approval permission set to "No" for the Delete Auth function.
    5. To delete the Authorisation to Send, click Delete.
      If the Needs delete approval option box is clear, then the Relationship Management application stores the authorisation with the status "Deleted". If you selected the Needs delete approval option box, then the Relationship Management application saves the authorisation with the status "Pending Delete Approval".
      Note
      After you delete the authorisation, the text in the Reason for Deletion field is no longer available for editing. However, the Delete button changes to the Resend Delete button and it remains available to allow you to re-send the Delete message in cases where a previous Delete message failed to reach your correspondent. This does not apply to an imported authorisation with the status "Deleted"
    6. Do you want to delete this Authorisation to Send?
      If yes, then click Delete.
      If the Needs delete approval option box is clear, then the Relationship Management application stores the authorisation with the status "Deleted". If you selected the Needs delete approval option box, then the Relationship Management application saves the authorisation with the status "Pending Delete Approval".
      If no, then click Cancel.
    Clicking Cancel leaves the Authorisation to Send unchanged, closes the Delete Authorisation to Send window, and displays either the Relationship Management window or Authorisations window.

    Rejecting an Authorisation

    Purpose

    This procedure provides instructions for rejecting an authorisation. You reject an authorisation by rejecting an Authorisation to Send.
    When your system receives an Authorisation to Send, the Relationship Management application determines whether it relates to an existing one. If it relates to an existing Authorisation to Send, then it assigns the status "Pending Accept" to it but does not change its external status. Keeping the same external status ensures that the existing authorisation stays active until an RMA operator accepts the modified authorisation, or rejects it. If it is a new Authorisation to Send, then the Relationship Management application assigns the status "Pending Accept" but leaves the external status empty.

    Users and permissions

    You can reject authorisations when the Reject Auth function is assigned to you in the Relationship Mgmt application.
    The following permissions restrict the business relationships that you can access:
    • Allowed/Prohibited Destination(s)
    • Allowed/Prohibited Service(s)

    To reject an Authorisation to Send:

    1. Select an authorisation that has the status "Pending Accept".
      You can select the authorisation in the following windows:
      • Pending Action - Relationship Management
      • Authorisation - Relationship Management
      • Authorisations
    2. From the Pending Action or Authorisation menu, select Reject.
      The Reject Authorisation to Send window appears.
      When the authorisation relates to an existing Authorisation to Send, the window shows an additional sentence, which starts with "This new authorisation replaces an existing authorisation".
    3. Select one of the following rejection codes:
      • xrma.003.1 - no business relation exists
      • xrma.003.3 - Unexpected permissions
      • xrma.003.5 - Insufficient
      • xrma.003.7 - Duplicate value in permissions
      • xrma.003.99 - Undefined
      Note
      If you are rejecting an authorisation that has the status "Rejected", then the window shows the previous rejection code. You cannot edit this code or the rejection reason, but you can re-send the rejection.
    4. If you entered the rejection code, xrma.003.99 - Undefined, then explain your reason for rejecting the authorisation in the Reject Reason field.
      If you select one of the other rejection codes, then the rejection reason is optional.
    5. If you need another user to approve the Reject action, then select the Needs reject approval option box.
      Note
      The Needs reject approval option box is selected and unavailable when you have the Bypass Approval permission set to "No" for the Reject Auth function.
    6. To reject the Authorisation to Send, click Reject.
      If the Needs reject approval option box is clear, then the Relationship Management application stores the authorisation with the status "Rejected". If you selected the Needs reject approval option box, then the Relationship Management application saves the authorisation with the status "Pending Reject Approval".
      Note
      After you reject the authorisation, the text in the Reject Reason field is no longer available for editing. However, the Reject button changes to the Resend Reject button and it remains available to allow you to re-send the Reject message in cases where a previous Reject message failed to reach your correspondent. This does not apply to an imported authorisation with the status "Rejected".
    Clicking Cancel leaves the Authorisation to Send unchanged, closes the Reject Authorisation to Send window, and displays either the Relationship Management window or the Authorisations window.

    Accepting an Authorisation

    Purpose

    This procedure provides instructions for accepting an authorisation. You accept an authorisation by accepting an Authorisation to Send.
    When your system receives an Authorisation to Send, the Relationship Management application determines whether it relates to an existing one. If it relates to an existing Authorisation to Send, then it assigns the status "Pending Accept" to it but does not change its external status. Keeping the same external status ensures that the existing authorisation stays active until an RMA operator accepts the modified authorisation, or rejects it. If it is a new Authorisation to Send, then the Relationship Management application assigns the status "Pending Accept" but leaves the external status empty.

    Users and permissions

    You can accept authorisations when the Accept Auth function is assigned to you in the Relationship Mgmt application.
    The following permissions restrict the business relationships that you can access:
    • Allowed/Prohibited Destination(s)
    • Allowed/Prohibited Service(s)

    To accept Authorisations to Send:

    1. Select an authorisation that has the status "Pending Accept".
      You can select the authorisation in the following windows:
      • Pending Action - Relationship Management
      • Authorisation - Relationship Management
      • Authorisations
    2. From the Pending Action or Authorisation menu, select Accept.
      The Accept Authorisation to Send window appears.
      When the authorisation relates to an existing Authorisation to Send, the window shows an additional sentence, which starts with "This new authorisation replaces an existing authorisation"
    3. If you need another user to approve the Accept action, then select the Needs accept approval option box.
      Note
      The Needs accept approval option box is selected and unavailable when you have the Bypass Approval permission set to "No" for the Accept Auth function.
    4. Do you want to accept this Authorisation to Send?
      If yes, click Accept.
      If the Needs accept approval option box is clear, then the Relationship Management application stores the authorisation with the status "Enabled". If you selected the Needs accept approval option box, then the Relationship Management application saves the authorisation with the status "Pending Accept Approval".
      If no, then click Cancel.
      The Relationship Management application leaves the Authorisation to Send unchanged. It closes the Accept Authorisation to Send window and displays either the Relationship Management window or the Authorisations window.

    Modifying an Authorisation

    This procedure provides instructions for modifying the details of an authorisation in the Authorisations window.
    Tip
    You can modify multiple authorisations simultaneously using the procedure for creating Authorisations to Receive.
    When you are creating new Authorisations to Receive, you can modify existing authorisations if you define the same service, Correspondent BIC, and list of Own BICs in the new authorisation as are defined in the existing authorisations. The Relationship Management application applies the same details to each of the selected authorisations.
    For more information about what happens to the authorisation after you have modified it. The same process occurs for modifying an active authorisation as for creating an authorisation.

    Scope of modifications

    In the Authorisations window, you can modify an Authorisation to Receive but you can only view or edit the comments of an Authorisation to Send.
    You cannot modify the following details of an authorisation:
    • service
    • Own BIC
    • Correspondent BICs
    • status

    Users and permissions

    You can modify authorisations when the Modify Auth function is assigned to you in the Relationship Mgmt application.
    The following permissions restrict the business relationships that you can access:
    • Allowed/Prohibited Destination(s)
    • Allowed/Prohibited Service(s)

    Before you begin

    This procedure assumes that you are familiar with the layout and the information displayed in the Authorisations window.
    If you close the Authorisations window by clicking the Close icon, Icon, then a warning appears. Select the appropriate action. The buttons in the warning dialog box have the following functions:
    • OK closes the window without saving the changes that you made.
    • Cancel returns to the Authorisations window and displays the changes that you made.
    • Help displays help about the task.

    To modify authorisation details:

    1. Select an authorisation in the Authorisation - Relationship Management window.
    2. Select Open from the Authorisation menu.
      The Authorisations window appears.
    3. To modify the Signing BICs for Test and Training authorisations.
    4. To add or edit comments, click Open comments window in the main window and add the comments for the authorisation.
    5. Select the Authorisation to Receive tab, and then edit the authorisation details in the New Authorisation pane.
      Note
      The New Authorisation pane does not show message or request types that the relevant standard no longer supports.
    6. From the Authorisation menu, select Modify to save the changes.
      If you are modifying a Test and Training authorisation and a Signing BIC for Test and Training is not defined, then a warning message appears. Define the Signing BIC for Test and Training a
      The Modify Authorisation to Receive dialog box appears.
    7. To save the authorisation for future editing
      Select Draft
      The Relationship Management application saves the authorisation with the preparation status "Draft".
      If the authorisation is already active, then it stays active, and gains the preparation status "Draft" in addition to its external status.
      To activate the new version of the authorisation to make it the Current version
      Select Enabled
      This option is available if your user profile has Bypass Approval set to "Yes" for the Modify Auth function.
      The Relationship Management application saves the authorisation with external status, "Enabled", and activates it so that it becomes the Current authorisation.
      To have another user approve the new version of the authorisation
      Select Pending Approval
      The Relationship Management application saves the authorisation with the preparation status, "Pending Approval", which requires another user to approve it.
      If the authorisation is already active, then it stays active, and gains the preparation status "Pending Approval" in addition to its external status.
    8. Click OK.

    Revoking an Authorisation

    This procedure provides instructions for revoking authorisations. You revoke an authorisation by revoking an Authorisation to Receive.
    For more information about what happens to the authorisation after you have revoked it.

    Users and permissions

    You can revoke authorisations when the Revoke Auth function is assigned to you in the Relationship Mgmt application.
    The following permissions restrict the business relationships that you can access:
    • Allowed/Prohibited Destination(s)
    • Allowed/Prohibited Service(s)

    To revoke Authorisations to Receive:

    1. Select the authorisation that you want to revoke.
      You can select the authorisation in the following windows:
      • Authorisation - Relationship Management
      • Authorisations
    2. From the Authorisation menu, select Revoke.
      The Revoke Authorisation to Receive window appears.
      If a Signing BIC for Test and Training is not defined, then a warning message appears. Define the Signing BIC for Test and Training.
    3. If you need another user to approve the Revoke action, then select the Needs revocation approval option box.
    4. Click Revoke.
      If the Needs revocation approval option box is clear, then the Relationship Management application stores the authorisation with the status "Revoked". If you selected the Needs revocation approval option box, then the Relationship Management application stores the authorisation with the status "Pending Revoke Approval".
      Your correspondent must acknowledge the revocation action.

    Tuesday, February 21, 2017

    RMA : Creating an Authorisation

    Purpose

    The procedure explains how to create an authorisation by creating an Authorisation to Receive, and to create authorisations using an existing authorisation. An Authorisation to Receive is the authorisation that you (Own BIC) send to a correspondent (Correspondent BIC) to enable that correspondent to send messages to you.
    If you create an authorisation using an existing one, then the Relationship Management application uses the values of the existing authorisation as default values for the new authorisation. You can keep those values or modify them if necessary.
    RMA Plus enables you to define a granular authorisation which specifies the types of messages within a service that a correspondent can send you. This capability is defined by the service and the available granularity levels for a service are defined in the application service profile. A non-granular authorisation covers all types of messages.
    For more information about what happens to the authorisation after you have created it,
    For more information about creating an authorisation for Test and Training,

    Using an existing authorisation

    When you base a new authorisation on an existing one, the New Authorisation to Receive Details window shows the same details as in the existing one. You can use those details, or modify them if necessary.
    The comments from the existing authorisation are not included, so you can enter new comments for the new authorisation.

    Users and permissions

    You can create authorisations when the Create Auth function is assigned to you in the Relationship Mgmt application.
    The following permissions restrict the business relationships that you can access:
    • Allowed/Prohibited Destination(s)
    • Allowed/Prohibited Service(s)

    Before you begin

    When you are creating a granular authorisation for RMA Plus, ensure that Own BICs are approved as candidates for granular authorisations.

    To create an Authorisation to Receive:

    1. To create an authorisation without basing it on an existing one, select New or New (granular) from the Authorisation menu.
      To create an authorisation based on an existing authorisation, open an authorisation and view its details in the Authorisations window. Then, select New As or New As (granular) from the Authorisation menu.
      If the existing authorisation has a preparation status, then the new authorisation is based on the authorisation in preparation rather than the active authorisation. Also, if you view an Authorisation to Send or an Authorisation to Receive, then the new authorisation is based on the authorisation that is being viewed.
      The New Authorisation to Receive window appears.
      The Available list displays the BICs for which you have permission to create an authorisation.
      For granular authorisations, the list shows only the BICs that are approved as candidates for granular authorisations, and for which you have permission to create an authorisation.
    2. Select the service to which the authorisation will apply.
      The list of services contains the live services (including the associated Test and Training !p service) that require authorisations and which are specified in the application service profile. You can select another service by selecting the Other option from the Services list and then, selecting the service name and optionally, entering an environment identifier.
      Authorisations that are based on an existing one show the same service as the existing authorisation.
    3. Select the licensed BIC8s for which you want to create authorisations.
      Tip
      Selecting several BICs in this field generates an Authorisation to Receive for each BIC8. Each authorisation has the same validity period and comments, if any are specified.
    4. Type the BIC8 of the Correspondent BIC.
      This gives permission to the Correspondent BIC to send messages to the Own BICs in the Selected list.
      If the BIC and Bank file is already installed, then the first 35 characters of the Correspondent's BIC expansion appear automatically beside the Correspondent BIC.
    5. Click Continue.
    6. If an authorisation exists for the business relationship, then the New Authorisation to Receive window appears.
      In this case, select an action by clicking one of the following buttons:
      • Modify - Apply the authorisation details to all the selected Own BICs.
        (This action modifies the authorisation details of those BICs.)
      • Skip - Leave the existing authorisations for the selected BICs unchanged, and create new authorisations for the remaining BICs.
      • Cancel - Display the New Authorisation to Receive window, where you can change the list of Selected Own BICs, or cancel the task.
      If no authorisation exists for the service, Correspondent BIC, and Own BICs that you selected, then the New Authorisation to Receive Details window appears.
      Note
      When you base a new authorisation on an existing one, the New Authorisation to Receive Details window shows the same details as in the existing one. You can use those details, or modify them if necessary.
      The comments from the existing authorisation are not included, so you can enter new comments for the new authorisation.
    7. To specify a validity period for the authorisation after it becomes active, select the option box Timebound Authorisation In the New Authorisation to Receive Details window. Then, specify the date range in the Valid from and Valid until fields.
      Valid dates are between 01 January 2006 and 31 December 2037, inclusive.
      The dates are stored in Greenwich Mean Time (GMT), with their times set to 00:00:01 and 23:59:59. The format of the date is defined by the Date configuration parameter in the System Management application.
    8. For a granular authorisation, specify the types of messages that may be transmitted between both parties. The available granularity levels for a service are defined in the application service profile.
    9. Enter comments about the authorisation (optional).
    10. From the Authorisation menu, select Add.
      The Add Authorisation to Receive dialog box appears.
      Assign one of the following statuses to the authorisation:
      • Draft - Save the authorisation for future editing.
        The Relationship Management application saves the authorisation with the preparation status "Draft". If the authorisation exists and is active, then it stays active and gains the preparation status "Draft" in addition to its external status.
      • Enabled - Activate the new version of the authorisation to make it the Current version.
        This option is available if your user profile has Bypass Approval set to "Yes" for the Create Auth function.
        The Relationship Management application saves the authorisation with external status, "Enabled", and activates it so that it becomes the Current authorisation. The date on which the authorisation becomes active is the Issued Date, and it is stored and displayed in GMT.
      • Pending Approval - Request approval for the new version of the authorisation.
        The Relationship Management application saves the authorisation with the preparation status, "Pending Approval", which requires another user to approve it. If the authorisation exists and is active, then it stays active and gains the preparation status "Pending Approval" in addition to its external status.
    11. Click OK.

    Monday, February 20, 2017

    Alliance Relationship Management

    Alliance Access provides the Alliance Relationship Management to help you manage business
    relationships with counterparties through authorisations that are sent as XML messages over
    the RMA service.

    You can use the Alliance Relationship Management to help you manage the authorisations for
    exchanging FIN, InterAct, and FileAct messages.

    While the SWIFTNet Public Key Infrastructure (PKI) authenticates messages, the RMA service
    is essential to ensure that the exchange of authenticated messages complies with the
    agreements of established business relationships.

    Manage authorisations

    You can create, modify, delete, revoke, accept, and reject the authorisations for exchanging
    FIN, InterAct, and FileAct messages. It also possible to implement the 4-eyes principle for
    managing authorisations, which dictates that at least two users must witness a certain action, or
    the outcome of that action.

    It is possible to create an authorisation for multiple BIC8s in a single operation.
    You can easily search for authorisations using search criteria, including authorisations with
    "anomalies" (unilateral relationships). You can also search for authorisations that have actions
    pending on them.

    You can view a current and new authorisation side-by-side in the Alliance Relationship
    Management, which allows you to compare easily two versions of an authorisation to identify
    the differences. In addition, you can add comments to an authorisation for your benefit. These
    comments are stored locally, and are not exchanged with your correspondent.
    RMA Plus licensed option

    RMA Plus (61:RMA PLUS) is a licensed option that extends the basic application by providing
    the ability to create authorisations with additional granularity for message types. Therefore, it
    provides you with more control over the types of messages that a correspondent can send to
    your organisation.

    The application service profile of the service specifies the available granularity levels for the FIN
    services and for all other InterAct and FileAct services. For the FIN service, you can authorise
    the sending of messages by message type. For the other services, you can authorise the
    sending of messages by request type patterns.

    Exchange queries and answers with correspondents
    You can send and receive a query and answer about a business relationship with the
    counterparty in that relationship.
    You can search for queries and answers easily using search criteria.

    Administer authorisations
    You can export and import all authorisations (for FIN, InterAct, and FileAct) automatically or
    manually, and also generate of a report that provides details about the results. You can also
    export automatically only the authorisations that have been changed.

    Saturday, February 18, 2017

    SWIFT File transfer licences

    SWIFT File transfer licences
    File transfer interface provides two distinct licences, FT-Adapter and FT-Integrated, which are represented as licence options:
    • The file transfer adapter licence option 61:FTA enables the automatic transfer and reception of files.
    • The file transfer integrated licence option 60:FTI enables the transfer and reception of files triggered by application-generated commands.

    Tuesday, February 14, 2017

    About Alliance Gateway

    Alliance Gateway is a modular software package that is installed on top of the SWIFTNet Link
    software, and is designed to enable application-to-application communication. Using the
    SWIFTNet interactive services InterAct and FileAct, messages and files are typically exchanged
    between a customer application (client) and a central application (server) over the Secure IP
    Network.


    Monday, February 6, 2017

    Queues and Routing

    A queue is where Alliance Access stores message instances.
    A routing point is where message transformation takes place in Alliance Access.
    Routing points consist of these elements:

    • a queue where messages are stored
    • a message processing function
    • a set of routing rules.

    An exit point is a special routing point that Alliance Access uses to route message instances to
    external applications (message partners). The system configures generic exit points to allow
    default processing of all kinds of messages by default, but operators can define their own exit
    point for specific routing purposes. In addition to these exit points, operators can also create
    user-defined queues for other needs.

    Additional queues are sometimes also available while installing the ADK component. Those
    queues are considered as ADK queues.

    Messages are routed and processed in Alliance Access until they reach their final destination.
    The processing of messages takes place at "routing points" where the messages are stored in
    queues. These can be divided into system queues and user-defined queues and exit points.
    Associated with a routing point is a Message Processing Function (MPF) which typically
    fetches, processes and then routes (according to the routing rules associated with the routing
    point) the messages in the queue at the routing point.

    Each routing point queue can be controlled by holding or releasing it to stop and start the flow of
    messages. Queue thresholds can be set to generate warnings when the number of messages
    in a queue reaches a specified level. Also, if a message is older than the maximum message
    age limit that is set, then the queue is put in an exceptional state and an event (by default
    configured as an alarm) is logged.